Introduction

Programming complex business applications using 3GL languages like ABAP require a lot of time. The applications tend to be large and difficult to maintain.

Most ABAP programs could be grouped into specific application types; e.g., data load programs, standard and ALV reports, BSP applications, inbound/outbound proxies for WebServices and PI/XI system, conversion programs, data mapping programs to name the few. When developing programs of the same type; e.g., ALV reports, you could use one program as a pattern, copy it over and make required changes to get another application of the same type. Even so the structure of programs of the same type are similar, the required changes are often substantial and spread out all over the source code making the modification tedious and prone to errors.

The described process could be automated. Rather than coping programs and then make the required changes by hand, a set of tools could be developed and then used for developing programs of the same type. Depending on the program type, different set of tools might be helpful to make programming more efficient. The following tools might be useful:

• Code Generators could convert the programs templates and application scripts to ready to use programs saving a lot of development effort
• Program Templates could be used to speed up the development of the new program. They could be used by program generators as skeletons for the final program.
• Script Templates could be used to speed up the development of the event handling or screen scripts. Instead of starting coding events with empty editor, document or spreadsheet page, a script template specific to event type could be copied to editor window or desktop application upon clicking on Create button to make script development easier.
• Cockpits/IDEs are useful for organizing the development effort. Rather than programming everything from SE38, SE80 or desktop application environment, a specialized Cockpit/IDE could help creating application scripts, program templates, generating  the final application source code, testing applications and managing the development process
• 4GL Script Languages are useful to minimize the amount of ABAP code to be developed. Rather than developing complex programs using ABAP only, one can design application type dependent event or screen scripts syntax and then define application with scripts rather than ABAP code. The build in parsers in Cockpit and/or Runtime Engine could interpret the scripts and combine them with program templates minimizing time required to develop the same application the traditional way using ABAP programming only. The scripts could be maintained manually or within Cockpits/IDEs as text in SE38 Editor, EDITOR-CALL, SAP Editor Control or document in desktop application; e.g., MS Excel.
• Runtime Engines could be used to interpret application dependent scripts that require minimal development time
• Standard Programs could be used to trigger Runtime Engines that would execute application dependent scripts.

The tools mentioned above are components of Rapid Development Environment - RDE - for applications of specific type. These applications are created by developing 4GL scripts that usually define application screens and how application should respond to certain events; e.g., data initialization, click on button, data record pattern matching, etc. All other details of the application could be handled automatically by cockpits, templates, code generators and runtime engines.

For complex applications, the application scripts and code generators or runtime engines provide the most efficient development approach. For simple applications or for the marketing purposes, the Script Builder tools can be added on top of scripts. The Script Builders might provide nicely looking environment utilizing graphics, table based definitions as well as drag-and-drop technologies that are slick and very efficient for simple applications but cumbersome to use for complex ones. The Builders' applications should be always designed on top of scripts allowing the power users to opt out of Builders and use Editors instead. If both the Builders and the Editors are implemented, they should be available in parallel; e.g., at a click on the toggle button.

Depending on application type, you could develop the appropriate set of custom tools, test them and then reuse them over and over when developing the custom applications. Using application type specific tools could speedup the development process by order of magnitude and sometimes even as much as 100 times.

When designing script syntax, think about simplicity of its use by application developers. Each class of applications should have the set of its own script formats - specifically designed for applications to be used for. Simplicity of using it is very important. Otherwise, you would not have savings in the development time.

In most cases you would not want to use XML based scripts. Even, so XML format might be appealing because availability of XML parsers, XML is not that user friendly - it is too verbose. It is very useful for machine processing but for humans, even so it is readable, it contains too many details and too little essence.

Opting out of XML format for proprietary format - the best suited to define problem within specific application type/class - adds the time required to develop script parser. But you would develop parser once when building tools and you would not have to worry about it anymore. With XML based scripts you can use XML parsers, but still, it is quite cumbersome to get data out of XML and interpret it in your program.

As a final touch of a complete set of toolset you might add XML layer for persistence data storage. But user should be always faced with much simpler script text format. The conversion from and to XML format could a part of a mature application class toolbox.

RDE - Rapid Development Environment Model and Its Components

The superset of Rapid Development Environment tools representing comprehensive RDE Model is shown on the following diagram:

Its components are marked with numbers 1 to 10. Depending on application type, the subset of components and links might be used for specific RDE implementation.

Let us analyze RDE components and their relations:

• The RDE Cockpit/IDE (1) allows managing the development process. In particular it allows creation of Screen Scripts (3) - if any - from script templates (2). Upon clicking on Create button a Screen Script Template (2) is copied to editor window and then modified by programmer to create a new script.
• The 4GL Screen Script (3) defines the application screen. Its content describes the layout of screen components; e.g., tables, trees, toolbars... etc; and their attributes. The screen syntax should allow defining screen in minimum editor space and its keywords should resemble attributes of components being defined; e.g., JUST for justification attribute of table column defined in FIELDCATALOG table. There is no need to include in script all attributes - only these that matter.
• The responses to events; e.g., user clicking on button, data record being matched by import program, ... etc; could be defined in Event Handling scripts (4). The event scripts could use 4GL syntax or could be defined as ABAP Forms or Function Modules with pre-determined signatures and names. The names could be dynamically derived from application name, screen name, event type, function code and called dynamically by Rubtime engine (5).
• The Cockpit/IDE (1) could start the Standard Application (6). The Standard Application (6) will call Runtime Engine (5) that would load 4GL Screen Script (3) and Event Scripts (4) to run the application in test mode without generating and saving its ABAP code. It Standard Application (6) would generate Program Output (7).
• The Cockpit/IDE (1) could also call the Code Generator (8) application that would generate Application ABAP Code from Application Attributes; e.g., Selection Screen Parameters, Select Options defined in Initialization Event Script (4) and Program Template (9).  The 4GL Screen Script (3) could be translated into corresponding ABAP code or could be interpreted dynamically at runtime. If Event Handling (4) is defined in 4GL scripts, the Code Generator (8) would generate out of it the ABAP code. If Event Handling is defined as ABAP Forms or Function Modules, they will be called dynamically by Generated Application (10).
• Generated Applications (10) could be executed independently of Cockpit/IDE (1). If there are any dynamic elements to be interpreted at the runtime, the Runtime Engine (5) will be called to perform this task. The Generated Application (10) will create the same Program Output (7) as he Standard Application (6). The Standard Application (6) might use the test data defined in Event Handling (4) 4GL Script rather than real data. The Generated Application (10) would use the real data supplied by user on the Selection Screen.
• The Cockpit/IDE (1) is not essential for generation or execution of RDE based applications. Its essential components; i.e., 4GL Screen Scripts and ABAP Form, FM or 4GL Event Handlers could be managed manually in SE38 Editor. However, having Cockpit/IDE (1) as part of RDE greatly improves its quality.

What's Next

This whitepaper presents the principals of RDE design. The subsequent whitepapers that will be published in the near future will show concrete examples of RDE in use:

Accelerating ABAP Development - Part II - Defining Screens in TAB Delimited Spreadsheet Files - for SAP Controls Technology based applications

Accelerating ABAP Development - Part III - SAP Controls Extended Framework - for SAP Controls Technology based applications

Accelerating ABAP Development - Part IV - ZSQL - for generating complete ABAP applications from SQL statement or Function Module signature

The above mentioned whitepapers will include screen shots, sample 4GL scripts and ABAP code to illustrate the RDE concepts.