As an SAP customer, we have lots of small development topics (change requests) every year. Most of the change requests are tested and then transported into the production system within a short time frame. However, there are always some change requests which are abandoned for various reasons. Periodically, my colleagues in the Basis (administration) Team create a list of these “long running changes”, and ask the developers to either release them or rolling them back (revert the objects to the original state, as in the productive system. This is unpleasant work for both the Basis colleagues and the developers.
To avoid this, we implemented a little report that automatically reverts the development and customizing objects in selected open transports to the state that they have in the production system.
It does this by creating a “mirror transport” in the production system.
Two pieces of coding are needed:
- An RFC function module in the production system, which is called with the object list, and adds them to the open transport of copies
- A small report for the development system, which performs some checks, creates backup versions of the objects, and then calls the function module
I attach the coding in “new” 7.40 SP08 syntax as text files. Of course, it can be rewritten to work on older ABAP versions as well. The function module logic is implemented in a local class, so the text file consists of 3 parts. In addition to the code, one message has to be created for the function module – see comment in code. There are 330 lines of code in total.
Besides executing the report, 4 manual steps are necessary. The sequence is:
- Manually: Create an empty "transport of copies" in the production system (P system), to use as a mirror transport. Target = development system + client (if you do not enter a target system, no transport file is created!)
- Using the new report (executed in the development system), fill the "mirror transport" in the P system automatically, based on a list of open transports (from the selection screen). The report also releases all transport tasks that are not yet released, checks if any of the objects in the transports have inactive versions (because these would not be overwritten in step 4), and creates versions of all objects
- Manually: Release the mirror transport in the P system. Ignore the warning message "Not all objects could be identified due to missing object catalog entry".
- Manually: Import the mirror transport into the Development system. You have to choose the "Overwrite originals" option (and if there are any modifications
- Manually: Release and transport the original transport requests
Known limitation: The report does not work for customizing if source and target client differ.
Disclaimer: I have tested the process and code in our own systems, but of course I cannot guarantee that it is bug-free, works as specified, etc.
Also, I do not have experience how this might work in complex landscapes with several development systems. (My first assumption is, that it does not introduce any additional risks or complexity.)
Update history:
29.06.2016: language edit: decommission --> roll back
Warning concerning "overwrite objects in repairs", later removed because of updated code
30.06.2016: sentence about complex landscapes in disclaimer
04.07.2016: Code updated with check for inactive objects
07.07.2016: Code updated according to Daniel Klein's feedback. Limitation regarding customizing / different clients mentioned.