Recently I have noticed that many people are willing to know how to move certain objects between systems which are not RFC connected. I must admit that this was a pain in my neck for a quite a time. I was trying out different tools found in net, some of which might be worth to be recommended, but there was no universal one for all kinds of cases I had. Anyway, thanks to my colleagues I learned an easy way it can be done. I would like to share that with you.
It's all about transports
A transport request, or TRQ for short, is a well known to us a way for moving objects between DEV->QUA->PROD systems. It turns out that we can use the same transports to move our already released objects to external SAP system, which is not connected to ours.
As you might already noticed, I used a term "already released". This is a prerequisite in order to export our data. Another one is that we need to have authorization to transaction STMS in our target system and be able to perform an Import activity there (this is an authorization object _S_CTS_ADMIN_).
If we are not sure about that, we can ask our Basis Guru or look for it ourselves in our authorization profile. I will not investigate it here as this is not a part of this blog (you can also simply try it if you are not convinced). Another authorization issue to be considered are tcodes CG3Y and CG3Zwhich are used for download Application Server files to PC (from source system) and upload them back (to target system).
I was told by Thomas Jung that in NetWeaver 7.02 tcodes CG3Y and CG3Z don't exist. I am working on ECC 5.0 and ECC 6.0 and here I don't face any problems. However, if you encounter any issues with those tcodes, you can still write some basic ABAP program to accomplish this task. Multiple of examples can be found in SCN covering this topic. For uploading local file we can also follow this wiki
Once we have ensured we are fulfilling above requirements, we can start.
As an example I chose a transport which contains different kinds of Repository objects, in order to prove that this technique can be applied to any dev object. Please don't pay attention to Polish descriptions, as it is of no significance here.
What does transport name stands for
Transport name consists of 3-letter system ID, 1 letter K which denotes so called cofile and 6-digit number. In our case CD1 is system ID, K stays unchanged, while 921487 is a transport number.
Each time you release a TRQ, system creates two files for it, which reside on Application Server. These are:
- cofile - which is a metadate of a TRQ
- data file - a content of TRQ itself
Files of these types receive a unique name for each TRQ. They are placed in following Unix directories:
where XXX is our system ID i.e. CD1, PD1, HHD, NSP, EDO etc.
In order we could move our data to external system, all we need is to get those files and copy them on target Application Server. Once it's done, we include those imported objects to a newly created TRQ on destination SAP system. But let's go through this step by step.
Exploring application server data
This step can be skipped but for sake of clarity I decided to write about this too.
To check existence of files stored on Application Server we will use tcode AL11. Depending on SAP version, system directories will be presented either as classical list or in ALV.
->We browse by double click to one of below directories to reach above paths. It doesn't matter which one, as they all store our files.
-> With find function we can identify our file. Please pay attention to giving correct name.
...this is our cofile
...and data file
As we found appropriate files on the server we can now export them.
Exporting/importing transport files
For this we shall use two tcodes (CG3Y for exporting to PC files and CG3Z for importing them back to different SAP system).
-> Go to CG3Y. System suggests to export file as *.DAT. Please change its extensions to your system ID. In our example we use *.CD1.
-> export cofile
-> ...and data file
-> Now log on the target system and repeat that with transaction CG3Z. Please copy them to the same directories, but note that fields are provided in reversed order.
-> import cofile
->...and data file
Creating a request to import data in target system
-> Run SMTS transaction and choose destination system. For consistency reason you should import your data to DEV system and then use standard path of distribution to subsequent systems (DEV->QUA->PROD). Below I chose the first one.
->From menu bar choose:
-> ...and type in original name of transport (so the system can match appropriate files on Application Server). Make sure you provided Development Client for Target Client field
As we have done this, we can see that our request is queued up.
-> Select it and choose from menu bar
Now system asks when this activity should be performed. As we all care about time, choosing Immediate is the one we should go for.
On next tab page we can choose how the import should be run (synchronously or asynchronously). I will not explain here the difference in both, as this is not a topic for this blog. Please leave it as it is set and accept further screen.
If the import succeeded we will see a check box next to our transport in queue.
Matching imported data with a new transport
Now as we have our data correctly imported, we only need to create a new transport and attach previously imported data (in form of a request) to the transport.
For this I want you to run SE10 and choose create button placed on the top left corner.
-> choose Workbench request
-> ...and using context menu choose Include objects
Now we need to do actual matching. Type in a request name which holds our imported data (original name).
If everything worked out, we should be having our objects seen in target system, so we have achieved our desired result.
The last thing we should do is to delete this Unclassified task which is automatically provided during transport creation. Using context menu we can easily get rid of it.
These easy activities allows us to move various Repository objects such as Function Groups, Screens, Reports, Classes, Smartforms, Tables and all kind of similar objects between SAP systems. Of course different naming conventions in target system should be considered. Objects names, however, can be changed using context menu in SE80. One restriction for this all export/import process is authorization, which if we are missing we can't really overcome this. All in all these activities can also be performed by our Basis team, at least we know now how they do the magic