Professional Documents
Culture Documents
e
SAP NetWeaver 7.0 (2004s)
How To
Send Multiple
IDocs Within
One XI
Message
Version 1.00 September 2007
Applicable Releases:
SAP NetWeaver 7.0 (2004s) and below
End-to-End Process Integration
Enabling Application-to-Application Processes
1 Business Scenario
You want to send IDocs from an SAP system based on SAP Basis 6.20 or above to SAP
NetWeaver Usage Type Process Integration (SAP PI, formerly known as SAP XI). The
receiving application wants all IDocs to be collected in one large message, for example,
one XML file. In particular, this applies for systems which only process data in a batch.
Usually, when IDocs are collected and sent within one LUW to the Integration Server, the
IDocs are split up, leading to one XI message for each IDoc. Therefore, the standard
IDoc-PI scenario does not support the business scenario specified above. With SAP
NetWeaver 7.0 SPS13, PI has introduced message packaging for inbound processes,
mainly for reasons of performance improvement. But each IDoc is still mapped
separately, not leading, for instance, to one large target XML file. However, many
customers require that all single messages are collected together.
This business requirement often applies for typical ECC master data distribution
processes using IDocs like MATMAS, DEBMAS, CREMAS, or COSMAS. Very often, the
receiving application wants one large file containing all master data records. It is less
suited for transactional processes like sales orders where you want to monitor and
commit each transaction separately.
2 Introduction
When setting up an outbound scenario on the ECC side, in addition to maintaining the
distribution model (transaction code BD64 or optionally NAST) and the partner profiles
(transaction code WE20), you also have to define the IDoc port (transaction code
WE21). Port type RFC is normally used for PI. However, you could also use port type
XML-HTTP or XML-File. By choosing the XML-HTTP port type, IDocs are sent out using
HTTP in one XML message containing multiple IDocs. With the XML-File port type, the
ALE layer creates the IDocs directly in one single file in their XML representation. In both
cases you have to select the respective option in the partner profile to collect the IDocs.
Report RSEOUT00 is executed to send the IDocs. The number of IDocs in a file is
specified by the parameter Maximum number of IDocs in the program RSEOUT00.
Here, it is important to choose an appropriate number for the IDocs that are to be
exported in one message. This depends greatly on the message size for the single IDoc.
It can be large for small objects like cost center, and must be smaller for larger objects
like materials. If the message becomes too large, high levels of memory and time
consumption are needed for extraction on ECC side, as well as in the mapping within PI.
An optimum has to be found which is case-specific. For materials, for instance, sending
only client-level data, we found out that bundling approximately 2500 IDocs leads to an
optimal throughput.
If you want to use the XML-HTTP port type to send out the IDoc in its XML format, you
need an Internet service that carries the HTTP request containing the XML-IDoc in the
body. For PI, this service is provided by the plain HTTP adapter.
When you use the XML-File port type, you can freely choose the directory and name of
the generated file. In addition, you can specify a function module like
EDI_PATH_CREATE_MESTYP_DOCNUM which dynamically creates a different file
name for each package that you send out.
-1-
For the XML-file port type, the IDoc created is similar to the normal imported IDoc
schema except that the IDoc tag has multiple occurrences (see Appendix). It is similar to
the 1:N IDocs outbound mapping solution (see SAP Note 814393).
Pros
Aside from the possibility to create one large XML message, you can improve the
throughput by bundling single IDocs for PI using the XML-HTTP port type on the
outbound side and the plain HTTP adapter on the inbound side. You do not need any file
share between the Integration Server and the ECC and so on for this purpose.
If you work under a new ECC project including migration, you have the advantage that
you specify the sending system in the URL. So , aside from business systems, you can
also use a business service without an SLD entry in PI. In this case, you do not need to
change the sender system when transporting through the landscapes. You can also
reuse the same sending system in different clients etc. This is of advantage when you
have multiple test clients for integration, performance, and dry runs.
3.2
Cons
End-to-end monitoring is not possible within PI for either the XML-HTTP or XML-File port
types.
IDoc tunneling is not supported as the inbound message comes through the plain HTTP
adapter.
The HTTP URL in the SM59 destination is restricted to 255 characters. This could even
be less for older releases. However this should not be a restriction for the typical IDoc
namespace and interface names. You can also define your own interface using the
modified IDoc WSDL (which includes maxOccurs=unbounded for the IDOC tag) as the
message type.
IDoc tracking via transaction code IDX5 is not possible. In order to correlate the XI
message to the IDoc, you have to scan all IDoc control segments in the XI message to
find the corresponding IDocs.
ALEAUDIT and application acknowledgements are not supported either.
Since no technical acknowledgements are sent back, the error status is set to 02 for
IDocs where communication is interrupted while they are sent to PI. Since it is not clear
whether these IDocs have reached PI or not, they cannot be restarted. So, you have to
manually verify that the IDocs have reached PI and have to resend them in case they
have not. For this reason, this approach is not suited for transactional data transfer.
However, according to SAP Note 857321, such IDocs can also be sent again.
The serialization and ordering of objects is very restricted. PI only guarantees ExactlyOnce-In-Order between large messages if you specify EOIO as the quality of service.
However, EOIO within the file is not guaranteed. The effect is minimized, since different
changes on the same object will, for example, create two change pointers at different
-2-
times. But in a night job, when the changes are extracted, the material is only sent out in
one IDoc that covers all changes up to the extraction time. Therefore packaging is best
suited in a batch scenario where you send all changes in a night job.
When copying back a productive client to a test system, you have to change the RFC
destination to point to the correct PI. In our case, this means that in addition to the server
IP address, you also have to change the URL where the names of the sending services
are contained. They differ in different landscapes.
-3-
4.1
-4-
-5-
4.2
-6-
Behavior in MDM
Syndicator
Possible Use
minOccurs=0
minOccurs=1
maxOccurs=unbounded
-7-
-8-
www.sdn.sap.com/irj/sdn/howtoguides