I have been wondering from where to start and some time ago my colleague from my latest project asked me something that I thought was trivial question at start.
How can I see if the configuration edits that are inside the transport are deleted or added in the following systems?
I thought it’s not like this should be some kind o mystery, after all we modify those entries while adding them to the transport request, so naturally it should be visible somewhere for example in the transaction se01? Turns out I couldn’t be more wrong and so the quest begun…
Before we into the details lets talk about how are transports structured in SAP systems. All objects that are added, modified or deleted in the tables or packages (programs/ function modules etc.) are gather in either customizing or workbench change request. However all of those changes no matter which type, are recorded in few tables – E070 – header, E071 positions and others (and some others we won’t be going through today), which brings us to the question that started this whole post. Where can we see, how will be the modification of the entries carried out on the following systems? For workbench object it is a bit easier since there is the Object function flag which determines that behavior, but for the customizing it will be “K” which doesn’t say too much outright.
Making this long story short, it could be found literally nowhere as far as I knew. Everything that is added by modifying the table ends up as a line in the standard table E071K, without any kind of information if it will be deleted or added, so how exactly does the following system know what to do? The answer is hidden in something most of the people won’t normally look at – the export log.
Inside it, in the summary section as shown below, is the solution to our initial problem. It turns out that actually at the moment of the release of a transport request, the entries are being checked with the current state of the database to determine which of them should be added or deleted in the following systems. If the key exist in the database table it is exported, if it doesn’t DELETE command is added to the row. Thanks to this we are able to do several changes to the same line in the table, on one customizing transport request and not think how it will be done in the next landscape system.
Moreover with this behavior we actually get additional functionality for free. If you for some reason have different data in the configuration table that was changed, the transport request will act in a different way on every system it is imported, making sure that all of them in the end are aligned, meaning it will add (modify if that key exist) or delete the record with provided key if it is present.