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