Copying test IDocs from another system

Posted by Grzegorz Glowacki in Process Integration (PI) & SOA Middleware on Feb 11, 2014 2:01:41
PM

inShare1

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:
Il faut utiliser plutôt ce format

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.