ALM Coffee I – with tp and the evil overtakers

How the ABAP transport system works

Since SAP launched the ABAP transport system with R/3 in 1992, there has been some confusion about how it actually works.

The amendment

An open, modifiable change request (transport request, TR) is nothing more than a bill of materials. The automatic recording of changes adds the keys of the changed objects (artifacts now) to a few tables (see view E071V and table E071K), but not the objects themselves. The main program ID is “R3TR”, it has over 1000 different objects, some of which contain their own special locks during transport or even turn the transport system upside down (for example, generate “Condition Techniques” tables in the target system) – I don’t envy the developers of the tp!

By the way, the abbreviations “LIMU” and “TABU” go back to glorious R/2 times: SAPLIMU was the assembler program for workbench objects and SAPTABU was the PG that maintained the SAP.ATAB, the generic table file.

Therefore, the change date of an open TR is purely documentary and has no technical significance. And the locks ensure that any further changes are not recorded in any other TR.

It only gets exciting when you release a TR. The operating system program tp is called, which copies the objects in the currently active or current version to a file on disk with the help of the program R3trans according to the keys. The TR can no longer be changed and two time stamps are set(SAP always does everything twice)

By the way, the TR Export History exists, it is just very well hidden: Transaction STMS_QUEUES

From now on, such a TR is a time bomb, because it contains the objects as they were at the time of export. The longer you wait with the import into the subsequent system, the more dangerous it becomes. Because the iron rule applies: the import sequence must be identical to the export sequence. Otherwise there is a risk of so-called overtakers (SAP also refers to this as a “downgrade”), i.e. newer TRs with the same objects that were imported before the older TR. If the older TR is imported at some point, it will overwrite the newer one with its older version.

Rarely do you want that.

How does tp really work?

An import consists of many individual steps: Roughly speaking, the parts list is imported, then (we concentrate on workbench TRs, they are more exciting) the DDIC objects are imported and generated, then the main import takes place, and finally the objects are syntactically checked and generated as part of the after-import methods.

You can see this very clearly in the transport history: STMS_IMPORT -> Menu -> Goto -> Import History. If you go to the Import History menu -> Extras -> Personal Settings and activate the “Display All Import Steps” flag in the settings pop-up:

then you can see the individual steps and their return code:

If you click on the small letters with the cursor, you will see a brief description of the step in the message bar. The most interesting are “H Dictionary Import” and “I Main Import”. The total return code in the “simple”, summarized history list is a calculated code that is not stored anywhere. Only the individual steps have a return code. This calculated total RC is then entered into the import queue by tp.

Many people now think that if tp several TRs at the same time that it then performs these import steps for each TR individually in the order of the import queue, as if you were to select each TR individually and import it separately.

But that is not the case.

What the tp does when importing several TRs at once is actually the other way round. It first imports the parts list for all TRs in one call, then imports the DDIC objects and generates them for all TRs in the list, then performs the main import for all TRs and finally performs the syntax check and generation for all TRs.

And: All these steps are only carried out if they are new. If they have already been executed, they are skipped for the respective TR.

The decisive advantage of this technique is that if a TR with RC=8 is “red“, it is automatically still available for import.

This is set via the tp parameter REPEATONERROR (STMS_DOM -> Selection System)

If you now deliver a correction transport, you must import both the faulty and the new TR at the same time in the same step. tp will only carry out all steps (parts list, DDIC, main import) for the new one, as they have already been carried out for the faulty old one. The new TR will overwrite objects from the older version with the hopefully corrected version. As the last step (syntax check and generation) has not yet been successfully carried out for the old TR, it will be carried out later and the old TR will (hopefully) become “green“.

And remember: The ChaRM (and therefore also Focused Build) automatically ensures this correct behavior.

Have fun understanding the theory in your system and see you at the next coffee party.