Skip to Content
Author's profile photo Martin English

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 ….

dp1adm 1> cd /usr/sap/trans
dp1adm 2> ls cofiles/*909775*
dp1adm 3> ls data/*909775* data/R909775.DP1
dp1adm 4> more cofiles/K909775.DP1

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

dp1adm 4> more cofiles/K909775.DP1
CSCMXE       K /ZMILEDEV/ 1   0  19   0   0   0   0   0   0  19  46C   .  0   0   0   0   0 200
#/1/                          A   G   D   U   R   C   _   M   Z RELE EX.  _   _   _   _   _ CLI
DP1 f 0000 20100420181706 devhost       dp1adm
QP1.200<0000 20100422181716 devhost       dp1adm
DP1.200 E 0000 20100422181716 devhost       dp1adm
dp1adm 5>

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.

dp1adm 5> cd /usr/sap/trans
dp1adm 6> SAPCAR -cvf DP1K909775.SAR cofiles/K909775.DP1 data/R909775.DP1
a cofiles/K909775.DP1
a data/R909775.DP1
dp1adm 7> ls -la DP1K909775.SAR
-rw-r–r–   1 dp1adm   sapsys        40531 Apr 23 16:05 DP1K909775.SAR
dp1adm 8>

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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Paul Hardy
      Paul Hardy
      Do a search for this on the SDN site.
      Author's profile photo Kenneth Moore
      Kenneth Moore
      SAPLink is buggy and does not work for all objects.  Fixes are slow.  If this works better, I'm all for it.
      Author's profile photo Martin English
      Martin English
      Blog Post Author
      Moving stuff via the CTS / TMS method has the advantage that anything that can be transported (Authorisation profiles through to ABAP objects) can be moved using the method detailed above.

      The disadvantage is that you need access to the Operating System command line.  This almost always means a BASIS person's involvement, even when moving stuff from Development.

      Author's profile photo Martin English
      Martin English
      Blog Post Author
      Hi Paul,
      Interestingly, compared to the other comment, when I have used SAPLINK , I never had any problems with it.  Two issues I HAVE had with it are:
      * compatibility with older (2.x and some 3.x) releases of SAP - they're still out there and still running production !!
      * Governance issues - On several implementations, the Governance team wanted testing and QA done before we could implement SAPLINK, as it was (probably correctly) determined to be a BASIS / Administration tool.  In these cases, it's easier to use standard SAP functionality 🙂