Transport Checking Tool (on Object level)

Did you ever get the request to ‘quickly check the transport list’ two days before Go-Live?

Only to discover that the list has hundreds of transports with thousands of objects?

And after going through the first few transports you find out that the list is a mess. Checking one object will indicate other transports that are not in the list, or transports that are ‘not needed anymore’ but with changes that were never rolled back, or emergency transports already in production... Etc. etc.

So how do you check the list? You know that there is no way that this list of transports can go to production without issues. Clearing up the mess is impossible, takes too long or is too costly.

There will be issues, but which? How serious will they be?

The next question you’ll get is ‘What is the risk?’. Do you dare to answer ‘The system could go KABOOOM’?

Yes, most issues can be prevented if the responsible user is careful in creating transports and organizing them before releasing them. However, nobody’s perfect. Mistakes will be made and corners will be cut. When the pressure from above increases, strict rules suddenly become flexible.

Some possible risks:

• Loss of functionality in production (if a newer transport is overwritten),
• Moving untested code to production (if an older transport exists for the same object, that is not included in the transport list),
• Objects use DDIC objects that are in Development and Acceptance, but NOT in production (causing dumps),
• Different versions are active in Production and Acceptance.

In the past I ran into this problem. I had to check a list of transports for a project that lasted over a year. Multiple developers worked on it and each delivered a list of transports. This I had to check… I encountered so many problems that I decided to write a small program that would check for older and newer transports of all objects used and then give warnings. The program was far from perfect, but it did the trick. The project from hell went live with only minor issues. That was several years ago. Since that time the program has grown. More checks and functions were implemented.

I do not have the illusion that it is perfect. I tried to make it as flexible as possible, but there is always room for improvement.

But if there are people who may have use for a tool like this, they can check it out and download it from SAP Code Exchange: https://cw.sdn.sap.com/cw/groups/ztct. It is a local program, available as a SAPLINK nugget, that only has program text and documentation.

It does not make changes to the database, but runs as a straightforward report. The only thing the program can create, is transport documentation, if the user decides to do so.

I would also like to take the opportunity to point out that there are other initiatives. For example the Transport request dependencies analyzer (https://cw.sdn.sap.com/cw/groups/transport-request-sequencer).

You can find that and other projects related to Transport Checking here:  https://cw.sdn.sap.com/cw/codex/projects#/?tags=transport.

Description of the Tool

Below is a short description of the tool, input, output and functionality. For more detailed information, please have a look at the User Manual on Code Exchange.

Selection Screen

This is what the selection screen looks like:

Output

This screenshot is an example of the output.

Interesting is the Application toolbar, which has buttons to:

• Recheck selected rows,
• Add transports conflicting with selected rows,
• Add a single transport,
• Add another saved file (merge lists),
• Remove selected transports (if you select one row, all rows for that transport will be removed)
• Mark a transport that is in Production for Re-transport,
• Jump to the next relevant Conflict,
• Build a simple list (on header level, unique transport numbers only, no Object information).

Transport sequence: order and disorder

The order in which the transports should be moved to production is the order in which they were imported in the Acceptance environment.

This guarantees that the versions in Production will be the same as the versions in Acceptance at the time the User Acceptance Test was performed and signed off.

Determining the transport order is straightforward enough. The complicating factor will be other transports in acceptance, containing one or more objects that are the same as objects in your list.

These conflicting transports may belong to other projects or other people. Maybe those transports cannot yet go to production (code is untested) or may already have been transported to production (as emergency transports).

In general it is not the process to determine the transport sequence that will cause problems, but other transports that will cause disruptions to your list.

Preventing that these issues and risks arise is always better than trying to solve them. It all starts with a good understanding of which objects should be grouped together in the same transport and which objects should be transported separately.

The Developer or Functional consultant should always be very alert for these considerations.

As a rule, User-Exits should always be transported separately. The same rule would apply for DDIC elements that can/will be used in multiple objects.

Other considerations would be if the complete function group needs to be transported or only a single function. Should the complete Class be transported or only the implementation of a method? Should the complete program (including texts and documentation) be transported or only the Report code?

Keeping the transport list clean and simple may prevent a lot of hair-pulling later on. 

Risks when transporting to Production

When transports are moved to production, there are several possible risks. The chance, severity and impact of issues on the system will increase with the number of transports involved and the number of objects in these transports.

Other complicating factors are the number of developers working on the same project, the runtime of the project, developers working on the same objects, transports being moved in case of production issues (disrupting the alignment) etc. etc.

Frequent problems encountered when NOT using a transport checking tool are described in the next two paragraphs.

Objects overwrite newer versions already in Production

Result: loss of recent changes/functionality.

Objects go to Production with previous versions in Acceptance

Result: unwanted (or even incorrect) changes go to Production without being signed off.
Code can also contain data elements that are not yet in production. The used/required data elements might exist in Acceptance, in another transport, but not yet in Production. When developing and testing there will be no syntax error. There will be no warning at all because the data element exists in Development and Acceptance. Only after the transport to production has been done, dumps will occur.