There are times in a project when you have to copy an existing solution from one system to another. Or you develop a solution in a sandbox instance, that has no connectivity to other systems in the landscape. Or even you simply develop a scenario similar to the one you have already implemented in the past, and want to reuse previous experiences. In all these situations, finally, with your developments ready, you want to start testing and realize that you need some test message for that purpose. With Proxy interfaces your task is easier, because you can copy-paste an XML message directly into the testing tool. But what about IDoc-based connections?
Let us assume a model situation. You have system A, where certain IDoc inbound solution is up and running, and system B, where you are expected to develop a similar one, in particular, based on the same IDoc message. System B is a sandbox, and therefore is not (yet) connected to any other tools over RFC (i.e. PI or system A). You just finished your developments and now want to test, but have no test IDoc message for that purpose. What you can do is create a test IDoc with the test tool (t-code WE19), but this can be extremely time consuming, especially with IDocs with multiple segments, complex structures or mass loads. So why not just copy an example IDoc from system A? With no RFC connection (and ALE settings) between systems A and B it might not be that simple, but still you can use this small trick to save yourself from a few minutes or hours spent on writing data into IDoc.
At high level, the process is as follows:
IDoc in system A -> file in AL11 of system A -> file on your desktop -> file in AL11 of system B -> IDoc in system B -> your highly desirable test 🙂
Let’s have a closer look at each of those steps.
Step 1. System A. Export IDoc to file in AL11
There are two possible ways to export an IDoc to a file. You could create an IDoc port of type File (WE21), then outbound your IDoc to that port to have it written to a file. But you can also use a little trick that will help you avoid doing any ALE configuration. For that purpose, enter transaction WE19, put your source IDoc number, choose the “Inbound file” option, type a file path and name (on SAP server!), make sure to unmark the “Start IDoc inbound processing of file immediately” and confirm. As a result, the file will be written to a file on SAP server.
It is important to notice that this action will result in another IDoc being created in the system, in status 68 “Error – no further processing” “Pattern IDoc written to database. Not defined for processing”.
Step 2. System A. Copy file from SAP server to your local station
In most cases, you can do this using transaction CG3Y:
However, this transaction is not available in some systems like PI or CRM. In such case, you can execute Function Module ARCHIVFILE_SERVER_TO_CLIENT instead:
Step 3. System B. Upload file from your local station to server
Similar to previous step, you can use transaction CG3Z (whenever available) or Function Module ARCHIVFILE_CLIENT_TO_SERVER.
Step 4. System B. Process IDoc from file
The final step is simply to process your IDoc from file, using standard transaction WE19 and pointing your newly created file as a payload source.
I hope some of you will find this information useful. Personally, I already had a few situations when this saved me a lot of manual work and helped me streamline my testing.