Skip to Content

Step by Step Instruction on How to Transfer Request to External System

·  Go to transaction SE80. Navigate appropriate package or program. Under the object name, you can see Programs, Includes, Transactions, Dictionary Objects and many others. Select suitable object which you want to transport to another system. Right click then Other Functions then Write Transport Entry. Then you should take request with type Transport of Copies and put other objects you want, inside of it too.

Note : If you have table in your transport request, you should check custom fields in data elements. If you have any, take them in your request too by doing the same process.


· Go to transaction SE09. Select Transport of Copies checkbox and click Display button. Find your transport request and release it by pressing F9. If you did not specify target system. Double-Click to your request. Select Properites tab and specify your target system. You can select your present system because you do not have to move request to another client in your system.



· Go to transaction AL11. Find your DIR_TRANS directory.


· Go to transaction CG3Y. To get header and data of your transport request, write source file on application server path by combining DIR_TRANS directory and your request number for each attribute of the request. Target file on front end is for suitable place in your desktop to save header and data of your request. According to my example, my request number is QRTK924709. My path should be like this ;

For header of request :

Source file on application server :   \\DTYQRT\sapmnt\trans\cofiles\K924709.QRT

Target file on front end                :    c:\temp\K924709.QRT

For data of request :

Source file on application server :   \\DTYQRT\sapmnt\trans\data\R924709.QRT

Target file on front end                :    c:\temp\R924709.QRT

Note : You can do it without using CG3Y. This FM do the same operation ARCHIVFILE_SERVER_TO_CLIENT



· We saved request in our system, so we need to import request into external system. Login to external system. Go to transaction AL11 and find external system DIR_TRANS directory.


· Go to transaction CG3Z. Then import header and data of your request into external system. According to my example, my request number is QRTK924709. My path should be like this ;

For header of request :

Source file on front end                 :   c:\temp\K924709.QRT

Target file on application server     :   \\DTYHANA\sapmnt\trans\cofiles\K924709.QRT

For data of request :

Source file on front end                  :   c:\temp\R924709.QRT

Target file on application server     :   \\DTYHANA\sapmnt\trans\data\R924709.QRT

Note : You can do it without using CG3Z. This FM do the same operation ARCHIVFILE_CLIENT_TO_SERVER



· Go to transaction STMS. Click Import Overview button and double-click to appropriate queue which you want to import the request.. Then, from the Menu bar click Extras then Other Requests then Add. Write your request number and click Continue. In our example, we should write QRTK924709 into transport request box. Then refresh the page, you will see that your request in the list.


· Finally, you should import the request. While importing, you can click Ignore Invalid Component Version checkbox to prevent system conflicts. If you do not have missing object or variable in your request, you are going to import it without error. If you have error, you should do the same operations for missing object.


You must be Logged on to comment or reply to a post.
  • Why would you want to do it this way rather than using the "transport target system/group" of the standard CTS?

    I just don't see the advantage.

    • It can be useful when you want to transport big developments or full packages between systems not connected between them.

      My previous customer got some projects developed by Polish consultants and then they sent the CR files all over the different systems (usually a system for country) to import them.

      You can do asking BASIS team (which does this) or you can actually do it yourself once you receive the file.

      • We did it too at one of my previous employers, and i never liked the process.

        It can be useful when you want to transport big developments or full packages between systems not connected between them

        Well then they should be connected via transport paths  😉 justsaying

        I don't want to criticize the process at your previous customer without knowing the SAP landscape. I have worked in projects with muliple dev teams spread across the globe, never saw manual handling of co/data- files 😳

        If you are a SAP add-on provider, things can be a lil' bit different. You may want to transfer the objects transports as co/data -files; if you don't want to license SAP-AAK.



        • The problem with my previous customer is that they are a multinational company with about 20-30 different sap systems (Just the Asian one got about 50k users with 20 different clients) each one with its own path Dev-Tst-Prd

          The only way to share a common code required from World HQ  was (and i think is still) to follow what this article explains.

          If you got any suggestion/experience to share, i'll be MORE THAN HAPPY to hear (and share with my poor previous contacts which each time DIE on this kind of process) 😀

        • It is for data exchange between systems that are not connected with each other just like Simone said. Also, if you are using this technique, you should not have solid name standard in your destination system. Then it might not be a best way to data exchange between different systems, but I had to use it once and thought that maybe it can be useful for others.


        • We used it in a similar situation to what Simone described. Our company was a holding with several disjointed SAP installations and I happened to be the only full time ABAPer worldwide. 🙂 So when a request came in from the new company owners to create some corporate interface programs I had to write the ABAP reports in "my" system, then get the transport files and email them to other teams to put in their systems. It was a one-off task, all systems are hosted by different providers, belong to different branches, etc. Even if a transport path was possible technically it'd never be allowed for political reasons.

          I do agree that this is neither best practice or even convenient / secure process. It's just a desperate workaround, nothing more. Not sure this deserves a designated blog, all information is already available on SCN to those who search. Even if well-intended, the educational effort seems a bit misguided here, unfortunately.

      • Create a local transport of copies. Release the transport. Copy the transport files to the new system. Import.

        That's simple.

        The complexity of this document revolves in how to copy files to and from the presentation server, and that is why I've given it a "poor" review.

        CG3Y doesn't exist in every SAP system. The FM is a better contender, as that is part of Basis. I'm not sure many customers would be happy with people willy nilly exporting and importing things. It's smacks to me of a way of getting around normal protections.   Usually Basis have to be involved - people with officially access to the application server file system.

        I work with clients with huge system landscapes. If you need to have something transferred, you ask Basis to move the files around - though mostly there are transport paths available.

        • Security is more than just authorization and a bunch of people saying "no you can't do that" 🙂

          The real reason for not doing this is the same logic as there is behind setting up authorization and processes to have the actual transport  performed by someone else, and to route normal transports via a Change Control board etc.

          Nominally at least, there is some kind of control and segregation of duties, preventing you from doing something like hardcoding a "send 10 tonne of steel to the evil in-laws front lawn" (my first R3 job was at a steel works).


  • How many more blogs are needed on the same subject? Here are the TOC blogs (with screenshots et all) just from the top of the list:

    Blog about manually importing transports:

    Plenty of information already available on SCN, one just needs to search.

      • If I only have a few things to add then I usually simply post a comment in the existing blog / document. This helps the other SCN members who search since they won't need to look at two different documents and wonder how are they different and which one do they follow.

        Or if I chose to write my own content then I'd at least post the links to the existing blog/document and clearly state how my post is different or what it adds.