Transporting ABAP Objects from one Landscape to Another
This is something that I learnt early on in my BASIS career. However, just the other day, I found out it wasn’t common knowledge in our office, so I thought it might be something worth spreading.
Underlying the ABAP Change and Transport System or Transport Management System is a series of directories or folders at the operating system level. The top level directory is usually /usr/sap/trans (or X:\usr\sap\trans for a Windows implementation – I will use the UNIX naming convention, as thats what the screen shots will be from).
Note – Because /usr/sap/trans is usally available to all systems in a Landscape, it can be come a dumping ground for various files and folders (Support Stacks, Kernel Upgrades etc) – these are the ones that I’ve covered up
When transport requests are released, they are written to this folder. A basic Transport Request with a number DP1K909775, created in system DP1 and then released will generate two files under the /usr/sap/trans directory ….
One file contains the control data to be used by the CTS / TMS for subsequent steps in the change management process. You can examine this file using the more command or notepad (or any editor appropriate for your Operating System).
The file(s) in the /usr/sap/trans/data directory contains (amongst other things) the binary data that makes up your objects.
You may find it useful to use SAPCAR to compress the Operating System files into one file. This makes it easier to move the complete Transport across machine and system boundaries because you are only managing one file.
Move or copy the SAR file to /usr/sap/trans in your target landscape. Use either transaction SPAM (via the SAP GUI) or SAPCAR -xvf (via the command line) to extract the contents into the appropriate directories, then go into TMS and add the transport into the target landscape, usually with a target system of the Development system.
Once the transport is in the new Landscape, then import it into the appropriate system. From then on, it can be treated like any other Transport request.
Useful Tips and Tricks (in no particular order)
- The *.SAR file generated by the SAPCAR execution above can be decompressed and the files can be loaded into the appropriate directories by using transaction SPAM in client 000,
- When using SAPCAR as shown above, make sure you include ALL the files for the particular transport from /usr/sap/trans/data,
- You can include the files for more than one transport request in one *.SAR file, if this makes selecting the objects to copied any easier,
- If you don’t want the transport imported into the next system of the originating landscape, delete it from the import queue of the next system.
This functionality can be useful in so many ways, such as copying common programs across all the Development systems in your landscapes, or for transporting workbench or configuration changes from landscape to landscape. A common example is where a global organisation uses a template methodology (where every site has the same base configuration and repository, plus local additions). Changes are sent out, in transport form, from ‘Head Office’ as SAR files.