ABAP Mentor

Overview

SAP stores your ABAP code in the database. But what does it actually mean? Let me explain this on an example.

You Create a New ABAP Program

It all starts with that you create a new ABAP program. In parallel, the system creates a lock on the Application Server for this ABAP program with your user id. Then you start typing the source code.

It's a really simple program. It adds two numbers and prints out their results.

Z_ABAP_DEMO

      REPORT z_abap_demo.

      DATA(result) = 3 + 2.
      WRITE result.
    

This program only exists on the Application Server in the main memory, since you have not saved it yet.

ABAP Workbench: The Big Picture (Sneak Preview)

This is a sneak preview of the course, ABAP Workbench: The Big Picture on Pluralsight. If you want to be informed about the release date and other useful content in this topic, just sign up!

You Save The ABAP Program

Once you save the program, the system automatically places the source code into the database. More precisely, the system places your code into the database table, called REPOSRC. So, there is a table in the database, called REPOSRC, into which the system inserts a new record.

REPOSRC

A new record for your newly created ABAP program, called, Z_ABAP_DEMO. Of course in inactive version first. But that's not the point. The point is the system places your source code into a simple table field.

No, you are wrong. This is your source code, but in a compressed format.

It is actually compressed using a so-called Lempel-Ziv and Huffman compression method. So, if you want, you can write a simple decompression tool, and decompress this value. That would result this source code above.

But of course, it's not necessary. The ABAP Editor does it for you. Whenever you open this ABAP program using the ABAP Editor, the system reads this row from the REPOSRC table. Then decompress the content of this field, and display it for you.

Okay. What happens next?

You Activate The ABAP Program

Yes. If you're ready, you activate your code. With this activation, the system changes the status of your program from inactive to active in the REPOSRC table.

REPOSRC

And... In parallel, it translates your ABAP code to a so-called platform-independent byte code by the ABAP compiler.

ABAP Byte Code

...
21 L ccgi CB 0000 0003 0000 0002
25 S WRIB 01 0000
26 S WRIT 00 001B
27 S WRIB 00 0000
28 S ---- 00 0000
29 N xper 16 0DB9 001C 001D
31 S PERP 80 0001
...

And places this byte code into another table, named REPOLOAD.

REPOLOAD

So, the system inserts a new record with this generated byte code into this table. Also in a compressed format. So, this platform-independent byte code and your ABAP source code are also independent from any operating systems.

Whenever you modify this source code in the ABAP Editor and then save the changes, the system will update the corresponding row in the REPOSRC table.

And whenever you activate these changes, the system re-generates the platform-independent byte code and updates the corresponding row in the REPOLOAD table.

Why do we need two forms of the same ABAP code?

On the one hand, whenever you display or edit this ABAP source code for example with the ABAP Editor, the system will read and update the corresponding row in the REPOSRC table.

So, the first form is for development purposes.

On the other hand, the ABAP byte code is loaded and interpreted by the ABAP Runtime Environment when you execute the ABAP program.

So, the second form is for runtime purposes.

Develop, Activate and Run

Alright. Let's see this example once again in one piece.

Summary

So, as you could see the ABAP Source Code and also the ABAP Byte Code are both platform independent.

The system only translates the byte code to operating system-specific machine language commands at the last stage, at runtime.

This makes ABAP operating system independent programming language.

If you liked it, please share it! Thanks!