How To… Send Multiple IDocs Within One XI

How-to Guide
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
© Copyright 2007 SAP AG. All rights reserved.
No part of this publication may be reproduced or
transmitted in any form or for any purpose without the
express permission of SAP AG. The information
contained herein may be changed without prior notice.
Some software products marketed by SAP AG and its
distributors contain proprietary software components of
other software vendors.
Microsoft, Windows, Outlook, and PowerPoint are
registered trademarks of Microsoft Corporation.
IBM, DB2, DB2 Universal Database, OS/2, Parallel
Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400,
iSeries, pSeries, xSeries, zSeries, z/OS, AFP, Intelligent
Miner, WebSphere, Netfinity, Tivoli, and Informix are
trademarks or registered trademarks of IBM Corporation
in the United States and/or other countries.
Oracle is a registered trademark of Oracle Corporation.
UNIX, X/Open, OSF/1, and Motif are registered
trademarks of the Open Group.
Citrix, ICA, Program Neighborhood, MetaFrame,
WinFrame, VideoFrame, and MultiWin are trademarks
or registered trademarks of Citrix Systems, Inc.
HTML, XML, XHTML and W3C are trademarks or
®
registered trademarks of W3C , World Wide Web
Consortium, Massachusetts Institute of Technology.
Java is a registered trademark of Sun Microsystems, Inc.
JavaScript is a registered trademark of Sun Microsystems,
Inc., used under license for technology invented and
implemented by Netscape.
MaxDB is a trademark of MySQL AB, Sweden.
SAP, R/3, mySAP, mySAP.com, xApps, xApp, and other
SAP products and services mentioned herein as well as
their respective logos are trademarks or registered
trademarks of SAP AG in Germany and in several other
countries all over the world. All other product and
service names mentioned are the trademarks of their
respective companies. Data
contained in this document serves informational
purposes only. National product specifications may vary.
These materials are subject to change without notice.
These materials are provided by SAP AG and its affiliated
companies ("SAP Group") for informational purposes
only, without representation or warranty of any
kind, and SAP Group shall not be liable for errors or
omissions with respect to the materials. The only
warranties for SAP Group products and services are those
that are set forth in the express warranty statements
accompanying such products and services, if any.
Nothing herein should be construed as constituting an
additional warranty.
These materials are provided “as is” without a warranty
of any kind, either express or implied, including but not
limited to, the implied warranties of merchantability,
fitness for a particular purpose, or non-infringement.
SAP shall not be liable for damages of any kind including
without limitation direct, special, indirect, or
consequential damages that may result from the use of
these materials.
SAP does not warrant the accuracy or completeness of
the information, text, graphics, links or other items
contained within these materials. SAP has no control
over the information that you may access through the
use of hot links contained in these materials and does not
endorse your use of third party web pages nor provide
any warranty whatsoever relating to third party web
pages.
SAP NetWeaver “How-to” Guides are intended to
simplify the product implementation. While specific
product features and procedures typically are explained
in a practical business context, it is not implied that those
features and procedures are the only approach in solving
a specific business problem using SAP NetWeaver. Should
you wish to receive additional information, clarification
or support, please refer to SAP Consulting.
Any software coding and/or code lines / strings (“Code”)
included in this documentation are only examples and
are not intended to be used in a productive system
environment. The Code is only intended better explain
and visualize the syntax and phrasing rules of certain
coding. SAP does not warrant the correctness and
completeness of the Code given herein, and SAP shall
not be liable for errors or damages caused by the usage of
the Code, except if such damages were caused by SAP
intentionally or grossly negligent.
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).
3 Pros and Cons
3.1
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 The Step By Step Solution
The following pages show where to change settings in ECC in order to package IDocs in
one XML.
4.1
XML-HTTP Outbound Settings
1. Call transaction code SM59 and
specify an RFC destination of type H
(HTTP Connection to R/3 System).
Specify the path prefix as follows:
/sap/xi/adapter_plain/
?namespace=< your namespace>
&interface=<IDoc_Type>
&service=<Sender System>
&qos=EO (or EOIO).
2. Call transaction code WE21 and
create a port of type XML-HTTP.
Specify the previously created RFC
destination.
-4-
3. Call transaction code WE20. For
each partner profile, refer to the
previously created receiver port.
Choose Collect IDocs.
Call transaction code BD64 and
create the respective distribution
model (not shown here).
4. After the creation of the IDocs,
execute report RSEOUT00.
To determine the package size,
specify the maximum number of
IDocs. You also have to specify the
message type.
-5-
4.2
XML-File Outbound Settings
5. Call transaction code WE21.
Create a new port of type XML-File.
Specify either the physical or the
logical directory where the file
should be placed. In the case of
MDM this should be a file share on
the MDM Import Server.
Do not specify the file name directly;
instead choose the function module
EDI_PATH*, for example,
EDI_PATH_CREATE_MESTYP_DO
CNUM.
6. Call transaction code WE20. For
each partner profile, refer to the
previously created receiver port.
Choose Collect IDocs.
Call transaction code BD64 and
create the respective distribution
model (not shown here).
After the creation of the IDocs,
execute report RSEOUT00.
-6-
5 Appendix: Mass IDocs
When you upload the standard schema of an IDoc, you have to modify it. When
referencing the element IDoc, the occurrence has to be changed from maxOccurs=”1” to
maxOccurs=”unbounded”, as explained in SAP Note 814393.
Option
Behavior in MDM
Syndicator
Possible Use
minOccurs=”0”
The destination node is
not a required node and
therefore the block will
not appear if no data
exists for the node in
question.
Within most repositories there is a
great deal of attributes associated
with taxonomies. Most likely you will
only want to view the attributes that
apply to the node being exported;
you can achieve this by specifying
this option.
minOccurs=”1”
The destination node is
required and the block will
therefore always appear,
even if there is no data.
maxOccurs=”unbounded”
To export multi-valued fields.
This specifies that there
will be as many as N
destination nodes and
that this will enable the
Syndicator to export
multiple blocks for a multivalued field.
-7-
-8-
www.sdn.sap.com/irj/sdn/howtoguides