Management Summary: Don’t think, just let the ChaRM machine run! 

There is a decades-long conflict between the way SAP ABAP transports are conceived and the way SAP customers want to handle them. ChaRM tries to enforce the SAP standard with gentle pressure, but has become more flexible over the years in line with customer requirements. However, this opens up treacherous traps into which SAP customers can stumble. 

Here I would like to shed light on the conflict and uncover the most dangerous traps. 

The ABAP transport system

Do not intervene manually

Developers and customizers have been struggling with ABAP Change and Transport System (CTS). for more than 30 years, as long as R/3 has been around.

They see themselves as craftsmen or even artists and think in terms of individual changes, which they lovingly work on for a long time. When the artfully crafted workpiece is finally finished, it is packed into a transport, and this individual transport is then transferred to the production system like a package so that it can be imported by the Operating team – straight away, of course. 

But unfortunately for the artists, the CTS follows an industrial paradigm: the CTS is like an assembly line in which everything, but really everything, that is automatically recorded onto the conveyor belt must be transported into the production system in the same order. 

Ideally, this is done automatically with ChaRM. 

Attribution I Cory M. Grenier, CC BY-SA 2.0, via Wikimedia Commons

This is because SAP, as a software manufacturer, has developed the CTS for its own purposes. The main objective of the CTS is a consistent transport landscape. A transport landscape is only consistent if development, QA, possibly PreProd and production have the same software version.

Therefore, the golden rule to avoid chaos is: no manual intervention!

The golden rule

So the main rule is: export order == import order

The transport order – a hybrid

During development and customizing, the CTS collects every change in transport requests. Only the keys of the changed objects are recorded, not the objects themselves, i.e. the content.

This is important to understand, because it is therefore irrelevant in which order the transport requests are created, just as it is irrelevant in which order the objects are recorded – as long as the transport request is modifiable. 

Only when the transport request is released (exported) does the system (kernel programs tp and R3trans) read the database using those keys and save the read content in an archive file at operating system level. 

This means that the exported content has frozen the status it had at the time of export. 

A released transport request is therefore simultaneously a collection of keys in the database and an unchangeable archive at operating system level. 

A released transport request can therefore no longer be modified. 

If the objects are changed again later in the development system, the same keys are recorded in a new transport request. Upon release (export), this newer transport archive file will contain the latest version of the objects. 

Downgrade And Overtaker 

As each transport request has time-dependent content, it is crucial that the older transport request is imported first and the newer one afterwards. 

Downgrade protection attempts to enforce precisely this conveyor belt sequence by preventing the later import of the older transport request. Overwriting the newer version of an object with an older one is called a downgrade; the older transport request has thus overtaken the newer one. 

With a little help from my ChaRM

I have already explored the benefits of introducing ChaRM in this blog. Here too, the more you stubbornly let the machine belt run – without manual intervention! – the better you live. 

But fiddling around in the assembly line is not always the cause of annoyance and stress. Well-intentioned but inadequate architecture is also sufficient. 

It becomes problematic if, on the one hand, you want to separate project and maintenance cleanly, but on the other hand you ignore the recommendations of this blog series and force both project and maintenance into a single system landscape because you are afraid of the costs of additional SAP ABAP systems. 

Everything looks neat and tidy on the presentation slides, but in practice it massively clashes. 

What is happening here? 

As both have their own cycle and their own task list, their transports belong to different CTS projects; there is no joint import, as ChaRM only imports per cycle and not across cycles. 

Maintenance corrections usually go into production much faster than the slow, phase-controlled project changes. 

Attribution  II Radosław Drożdżewski (Zwiadowca21), CC BY-SA 4.0, via Wikimedia Commons

Therefore, if the same object is changed both by the project work and by an error correction in maintenance, it can easily happen that a maintenance transport overtakes the project transports that have only been imported into the test system but not yet into the production system. 

Here we have a nice real-life example. An important customer class for sales was changed by five different developers within the scope of three change documents: 

TR	Export	Import QA	Import PreProd	Owner	Change	Status	CTS Project
DEVK922007	23.07.24 12:51	23.07.24 17:10	23.07.24 17:16	USR1	602542	TR to Retesting	DEV_P03
DEVK922158	30.07.24 12:54	30.07.24 17:10	30.07.24 17:16	USR2	602542	TR to Retesting	DEV_P03
DEVK922389	14.08.24 14:49	14.08.24 17:11	–	USR3	851879	Being Corrected	DEV_P05
DEVK922591	14.08.24 17:01	14.08.24 17:01	14.08.24 17:16	USR1	602542	TR to Retesting	DEV_P03
DEVK922725	16.08.24 11:18	16.08.24 12:11	16.08.24 12:16	USR4	602542	TR to Retesting	DEV_P03
DEVK921089	19.08.24 18:01	19.08.24 18:01	19.08.24 18:31	USR5	602490	TR to Retesting	DEV_P03

Blue fontcolor: project (DEV_P03), red fontcolor maintenance (DEV_P05), which coexist in a 4-system landscape. The table clearly shows how the older maintenance transport DEVK922389, which belongs to a different cycle, has overwritten the more recent project transport DEVK922591. 

There were also dependencies between the transports; the maintenance transport contained the implementation of a method to which later project transports referred. Result: RC=8. 

And since maintenance and project are interlinked like a zipper, it is not possible to establish a proper sequence for the go-live. A situation to tear your hair out! 

Attribution  III Caravaggio, Public domain, via Wikimedia Commons

In such chaotic cases, only the “fountain of youth method” remains. 

Two of the three change documents, one for maintenance and one for project, were reset in status so that two transport requests could be created, one within the maintenance cycle, the other within the project cycle. 

The parts list of all involved transport requests was copied into both transports and they were released practically simultaneously; both were then set live on the same weekend. Since both transports contained the identical latest status on release, and since both transports were the latest and last in the import queue of the production system, their order was now irrelevant. 

Unfortunately, this only works if you act so quickly that no other changes have already been made to the objects that would first require a tester approval. 

Conclusion:

Never, never ever run a maintenance cycle and a project cycle in one and the same transport landscape, but either use the preliminary functionality for work items for corrections, or establish two transport landscapes with retrofit. 

Excursus: Decoupling transports

Attribution V Uri-Levy, CC BY-SA 3.0, via Wikimedia Commons

A favourite sport of developers and customizers is the cheerful rearrangement of their work packages, i.e. their change documents. 

New change documents are created, old ones should be deleted, but this is not possible, so they should at least be withdrawn. However, this only works if these change documents have no or only empty transport requests. 

However, if the change document has transport requests that are not empty, these must be reassigned beforehand. 

Reassignment of a changeable transport

There is no direct drag&drop reassignment. 

First you have to decouple the transport request from its change document, only then can you assign it to the other change document. 

Both activities are hidden in the “More” menu of the Transport Management block:

These actions are more visible in Focused Build:

Decoupling Transport Request 

After the decoupling, the transport disappeared from the ChaRM administration. It has also lost its connection to the CTS project. However, a trace of the past relationship still remains (in addition to the ID of the old change document in the short text):

Assign transport order

We link the lone transport to an Urgent Change that belongs to a different cycle. The transport is now assigned a new, different CTS project: 

And the ChaRM administration now lists the transport under the Urgent Change task list: 

If you have activated the BAdI /TMWFLOW/ASSIGN_TRANS_DESC_UPD (IMG “BAdI: Change Description after Assign Transport Request to Change Document”), the ID of the new change document is entered in the transport request short text, see SAP Note 2849745 «Rename transport request when reassigning to a new change» 

Decoupling a released transport

Spoiler: It does not work.

By default, this action is only offered in the “Development” status, in all other statuses the menu entry is inactive: 

We are clever and change the customizing to allow the action for status E0009 “TestedOK” after all: 

And it does work!

However, since this activity is extremely popular, I have written the report /BLUWRKS/TRANSPORT_DELETE, which frees change documents from transport requests that have already been released: 

E voila:

The change document can now finally be withdrawn. 

This report is selling like hot cakes (Semmeln), as we would say here in Munich. 

By the way, in task lists with Central CTS you can also reassign transport requests that have already been released, but cCTS is quite slow and therefore unpopular.