Some Facts About ABAP Compilation and Execution Process

Suppose I have a very small application called Z_TEST that contains these source lines :

REPORT Z_TEST.

PARAMETERS input(16) TYPE c DEFAULT ‘Hello, World’.

START-OF-SELECTION.
WRITE ‘Input was :’.
WRITE input.

When I choose to activate the application, in effect it will causes the ABAP system to compile the code :

The resulting compiled code, called the ABAP load, is stored in D010L of SAP System database. It is stored in the compressed form, consists of one of more block(s) :

For the above example, it consists of 1 block and compressed size of 5088 bytes.

Let’s examine more closely on activation process.

Actually there are two phase involved in the activation process, and I will call it parsing phase and generation phase. In the parsing phase, ABAP activation module will checks for syntax and generates or expand to appropriate instruction for each line of given source code.

For example, the statement “REPORT Z_TEST” will be expanded to :

Later on, the module will recursively process the expanded statement, in this case the file, it will find :

* ABAP-System Include for all programs
CONSTANTS space VALUE ‘ ‘ %_PREDEFINED.

Inside the source file, and each statement is again get expanded. This process continues on until all of program statement is already processed.

In the generation phase, the codes that is categorized as module will be registered in cg_trig records using proprietary format. Example of module includes SYSTEM-EXIT, MODULE, FORM, START-OF-SELECTION statements. In SAP terminology, this is called entry points/procedures.

You can view the number of generated modules using “Generation Limit” sub menu of “Check” context menu. It will shown as “entry points” in generation limit records :

There are other components that seems not shown in the ABAP generation limit dialog, which is called cg_cont or code label record. This record contains low level ABAP instruction, also in the form of proprietary format.

When the program is executed, the ABAP runtime process first will execute statements that is not associated to (i.e. inside) modules. In my particular cases, this involved the statements such as SYSTEM-EXIT and PERFORM (sy-xform) IN PROGRAM (sy-xprog).

After finished processing the above kind of statement, it will use another component called dynpro steps inside the dynpro record. This record is stored inside table D020L, also in compressed format.

The dynpro processor routine will steps into the dynpro record and after obtaining module index inside ab_dstep function, this index is used as the reference to entry points in cg_trig record.

How the module index is obtained ? This involves two steps. First, there are dynpro offset records returned after each call to dyGetFirstStep or dyGetNextStep.

In my version of ABAP, the offset information is located at offset 0x0B. This offset information is passed as one of the parameter of dyGetModuleNameByOffset function. The returned value consist of Module Name record, and its module index is located at offset 0x04.

To execute the actual low level ABAP routine, the first byte of the obtained cg_trig record is used as the reference to cg_cont to obtain corresponding low level routine.

Each user action will trigger another dynpro steps and the above whole process is repeated, until user logs off from SAP server 🙂

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: