Supply Chain Management Blogs by Members
Learn about SAP SCM software from firsthand experiences of community members. Share your own post and join the conversation about supply chain management.
cancel
Showing results for 
Search instead for 
Did you mean: 
martin_E
Active Contributor
0 Kudos

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*
cofiles/K909775.DP1
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.

4 Comments
Labels in this area