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.
Ref:
