The transports you will be creating will be released and "moved" through the landscape. Transports can overtake each other or left out completely (which is the start phase of an overtaking transport) if not managed properly. So what is an overtaking transport ? When a transport is released, it can be imported into each system in the landscape. If we have 2 transport requests for the same object (a report) and only the second transport is imported, the latest version of the report is made available...

Thus there is no reason to also import the first transport. However if e.g. text elements or other related objects were made available on the first transport, one may wish to import the first transport anyway. That's the situation with "Overtaking transports". In effect, the changes that were done to the report between 1st and 2nd transport request are "undone" when the second transport is imported. Solution? Simply re-import the second transport, which will put everything back in it's place.

Sequence of importing transports is of paramount importance. When done the wrong way around - there is no way of predicting what will happen: software will become available in a state is has never been in before. 

When a developer creates a report, he/she often doesn’t even realize the number of objects that are “also involved” on the transport. The transport system takes care of it, so the developer doesn't need to. A report is not just a report, it can be split up in several includes, it can also have screens and texts, all objects that compose a report. So the idea that a transport about a report holds the whole report is simply wrong. Bringing transports to a system in an out of sequence manner effectively introduces new software that was never tried anywhere else and it was also never meant to be. Having a landscape with multiple systems will help catch transport problems, but importing transports should not introduce new problems.

Import sequence

So what sequence should be used ? Simple and effective: the date and time the object was released in the development system. That is the sequence it was build in and that is also the sequence in which SAP has protected the objects being edited E.g. someone changes a report for which a transport request is created. If another developer attempts to change the same report, a task is added to this same transport request OR the change is not possible. The transport request number could also be used as sequence key - however, it is possible to create a transport request and leave it open (not released) for a very long time. Hence the more reliable way to determine transport request sequence is the release date and time, which can be found on table E070 fields AS4DATE and AS4TIME (only for released transports (TRSTATUS=R).

Missed and overtaken transports

So how can these be found ? Check out the transport logs for all transports that involve the object you are following. To find these requests (3 methods):

• Free text search - Assuming your transport description followed a naming convention, simply check the content of the E07T table (transport request text table) for descriptions matching the item in focus.
• Version history - For an obvious object like a report or include thereof, you can find the involved transport requests by looking up “Version history” SE38 editor => Utilities => Versions => Version management. This will list the transports involved (yes: in the required sequence too).
• Objects in requests - Another way to determine which transport requests belong together is using the “Objects in requests” functionality on SE10 => Goto => Objects in requests, fill in the object type and the object you are looking for. For reports and includes, the version history method is easier (e.g. and include becomes LIMU REPS instead of R3TR PROG).

With the list of related transports, check the Import date/time for the system you are checking in the request log. When there are multiple imports (re-imports), the last date and time is to be used. These 2 sets of dates/times are very different, but they should be in the same sequence. Missing trandsports will also show. The basis team has many reports that could help out here as well. I found this method explained strange behaviour of the technical objects I had delivered.

When you find a small gap or oventaken transport, simply solve the issue by requesting the basis team to re-import the transports involved in the correct sequence. All transport requests following the faulty one should also be re-imported - to avoid new overtakes.

When you do find a big mess in the transport sequence, simply solve the issue with a transport of copies. Create a new transport with type "Transport of copies" and incorporate all transports that were sequenced wrongly in there. This merges all transports into a single transport, and all latest versions of all possible objects will be used. Effectively melting them all together resolves missed and overtaken transports. There. Done.

• Prev
• Next