Transport Checking Tool (Object level)

[former_member206575]

Introduction

Source (GitHub): Transport Checking Tool (Object level).

This tool is a Local program, available as a SAPLINK nugget or as an AbapGit package. AbapGit is recommended, because SAPLINK is no longer maintained. There is no need to transport it to any other environment than Development. Installation is simple. Import the nugget with SAPLink and activate the Report, Report Texts and the Menu (CUAD). That's it.

The program checks transports on Object level. A variety of validations is performed to check if it is safe to move transports from the test environment to the next environment (most likely production).

It does not make changes to the database, but runs as a straightforward report. The only thing the program can create, is transport documentation, but only if the user decides to do so. What the program aims to do is to highlight possible risks, allowing the user to add or remove transports and eventually produce a list of transport requests that can be moved to production with minimal or no conflicts.

Why this program?

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. Cleaning 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 when creating transports and organizes them properly 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, and it turns out that it must be moved as well),


• Objects use Data Dictonary objects that already exist in Development and Acceptance, but NOT in production, and these are not included in the transport list (which will cause dumps in porduction),


• After the list has been transported, different versions could be active in Production and Acceptance if the transport sequence was different.

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 Github: Transport Checking Tool (Object level).

Possible Limitations

This tool was written to be used in SAP ERP. The Transport Checking Tool uses Data Dictionary objects that existed in the system it was developed in. Of course, which DDIC types exist can be release dependant. All the Data Dictionary objects that I have used, should be available in the system the Transport Checking Tool is imported in. If not, a programmer will have to modify the program to correct this.

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,


• Activate the DDIC check,


• 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).

Example

When a warning is given, the user can click on the warning icon. Let's have a look at the example displayed below:



There is a warning (yellow triangle, stating that there is a previous version that is not in your list. Double-clicking on the icon will display the following popup:



Here you can see which transport was missed and it also becomes clear why. Another user changed this object as well. And now it becomes interesting. There are two options:

1. You decide to add the transport to your list (click Okay). The other user's transport is added to the list.


2. You decide to go ahead without adding the transport (click Cancel). The list remains the same.

By clicking on the Okay icon, the selected transport will be added to your list. It would be nice if at this point you contact the user first, to ask if his transport can go to production or not (for obvious reasons, I hope). The transport of the other user will most likely contain other objects too...

But also if you choose NOT to add the transport you will still need to communicate the situation. The reason why you should communicate in the latter case, is that by moving only your transport, the changes of the other user made to this object will be transported with it. And if the other user later decides to move his changes, yours will be overwritten. Note that if the other user checks his transport list, he will see an error icon with the message that a newer version will be overwritten. The reason for that error message will be you...

The golden rule here is to COMMUNICATE.

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.

Conclusion

In the end, the real trick is to be careful in the beginning. Check before releasing transports in the Development system. Organize them properly and try to think ahead. This prevents a lot of problems. But even so, it will always be necessary to check the transports that go to the Production system before actually moving them.

To do this, a transport checking tool will come in handy.

Still, keep in mind that the responsibility for the transports lies with the developers and the functional consultants who created them and who added the objects to them. They will have the best understanding of what was changed and why.

There isn't a tool that can take away that responsibility and there isn't a tool that a user can execute to analyze the problems and that comes with a 'Fix errors' button...