24
How-to Guide SAP NetWeaver ‘04 How To… Handle Acknowledg- ments for IDoc Version 1.00 – August 2004 Applicable Releases: SAP NetWeaver ’04 SAP Exchange Infrastructure 3.0

How To… Handle Acknowledg- ments for IDoc · IDoc. Select the adapter type IDoc, the RFC destination B6M_000, the port SAPB6M, and the appropriate SAP release. No routing rules

  • Upload
    others

  • View
    69

  • Download
    6

Embed Size (px)

Citation preview

How-to Guide SAP NetWeaver ‘04

How To… Handle Acknowledg-ments for IDoc Version 1.00 – August 2004 Applicable Releases: SAP NetWeaver ’04 SAP Exchange Infrastructure 3.0

© Copyright 2004 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, SAP NetWeaver, 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 -

1 Scenario

This guide deals with the processing of acknowledgment messages for IDoc-XI-IDoc scenarios. The following scenario is considered:

B6M_000

IDocs

XID_113

IDocs

IntegrationServer

U6D_700

SYIDOC ALEAUDXID_112

IDocs

SYIDOC

SYIDOC

ALEAUD

ALEAUD

2 Introduction

For asynchronous messages, an acknowledgment informs the sender about the status of message processing. There are four types of acknowledgment:

• System acknowledgment: sent back when the request arrives at the final receiver. • System error acknowledgment: sent back when a system error occurs during message processing

within SAP XI. • Application acknowledgment: sent back when the message is successfully processed within the

receiver application. • Application error acknowledgment: sent back when an error occurs during message processing

within the receiver application. In general, acknowledgments have to be requested explicitly by the sender. However, this does not apply to IDocs. The following acknowledgments are sent back by default, unless the corresponding message type is maintained in an exception table (see chapter 3.4):

• System error acknowledgment • Application acknowledgment • Application error acknowledgment.

IDocs only return acknowledgments if the receiver is configured for using ALE audit (see chapter 3.1). ALE audit is only possible for IDocs of type logical system (LS).

- 2 -

3 The Step-by-Step Solution

3.1 Configure ALE Audit in the Receiver System

1. Use transaction BD54 to maintain the logical system B6MCLNT000 (sender service).

2. Use transaction BD64 to maintain a distribution model for ALE audit. Select the sender CLNT113, the receiver B6MCLNT000, and the message type ALEAUD. You have the option of selecting a specific message type as a filter object.

3. Use transaction SM59 to maintain the RFC destination U6D_700 to the Integration Server.

- 3 -

4. Use transaction WE21 to create the tRFC Port SAPU6D using the corresponding RFC destination.

5. Use transaction WE20 to maintain the partner profile for the logical partner B6MCLNT000.

6. Select the message type ALEAUD as

outbound parameter and the receiver port SAPU6D.

- 4 -

7. Define the sending of confirmations. Use transaction RBDSTATE to create the variant SAP_AUDIT_SEND for report RBDSTATE.

8. Schedule a background job in the receiver system to periodically send back the audit data to the sender system. Use transaction SM36 to define a job using RBDSTATE and variant SAP_AUDIT_SEND.

- 5 -

3.2 Configure the Routing for Acknowledgments

1. In the Integration Directory, create a communication channel of adapter type IDoc. Select the adapter type IDoc, the RFC destination B6M_000, the port SAPB6M, and the appropriate SAP release. No routing rules are required for acknowledgments; you only have to define a communication channel. If there are several communication channels of adapter type IDoc, the channel starting with Ack is used.

- 6 -

3.3 Message Monitoring Aspects

1. Use transaction SXMB_MONI (Integration Engine - Monitoring Monitor for Processed XML Messages) to display the message. Information about requesting acknowledgments is displayed in the ReliableMessaging message header section.

2. The Main message header section contains the message class, the message ID of the acknowledgment, and the reference to the request message. In the example, the message class is ApplicationAck. Since the status within the Ack message header section is Error, the acknowledgment is of type Application Error Acknowledgment.

3. The Ack message header section contains the status and the category of the acknowledgment, for example, the status OK or Error and the category transient or permanent.

- 7 -

4. The HopList message header section records the path from the original sender to the final receiver in order to route acknowledgement messages back. The request message hop list is copied to the header of the acknowledgment message.

5. For both application and system errors, the Err message header section describes error details. Once you have corrected the error, you can restart the request message.

- 8 -

3.4 Configure the Integration Server (Optional)

1. Use transaction SXMB_ADM (Integration Engine - Configuration) to obtain system error acknowledgments from pipeline services of the Integration Server and maintain the specific configuration parameter ACK_SYSTEM_FAILURE of the RUNTIME category. Whenever a system error occurs within the Integration Server, a system error acknowledgment is sent back to the sender.

2. If you want to suppress any kind of acknowledgment, maintain the IDXNOALE table: specify the port, the client of the sender, and the message type.

3. The upper figure on the right shows that the first message requests an acknowledgment. Once you have maintained the exception table, an acknowledgment will no longer be requested (see the Ack. Status column of the second message). The lower figure shows the ReliableMessaging message header section of the second message. All attributes indicating an acknowledgment request have disappeared, that is, their values are set to false.

- 9 -

4 Case Studies

4.1 Case Study 1: System Error Within the Integration Server

1. Problem: The RFC destination in the communication channel is not valid.

2. Message monitoring on the Integration Server: A system error occurs in the Adapter Engine. It is displayed in the message monitoring.

3. Message monitoring on the Integration Server: An acknowledgment with the message class SystemAck, the status Error, and the category transient is created and sent back to the sender system.

- 10 -

4. Sender – Inbound Within the IDoc adapter, an IDoc of message type ALEAUD is created and sent to the sender system. Use transaction WE05 to display the inbound IDoc. The IDoc ALEAUD refers to the original request IDoc. Among other things, it contains the status 56 and an error text (see the mapping table in the appendix).

5. Sender – Outbound The status of the request IDoc is updated; the current status is 39, indicating that the IDoc is in the target system. Here, the XI system is the target system. Note that the current status shows a green light even though an error occurs.

6. If you double-click the current status, the status record is displayed with information about the error.

- 11 -

7. Message monitoring on the Integration Server: Once you have fixed the problem that caused the system error, the request message is restarted.

8. Receiver – Inbound The current status of the request IDoc is 53, indicating that the IDoc is successfully posted to the application within the receiver system.

9. Receiver – Outbound An ALE audit IDoc is created, referring to the request IDoc.

10. Message monitoring on the Integration Server: Within the IDoc adapter, a positive acknowledgment is created and sent to the sender system. The message class is ApplicationAck, the status is OK, and the category is permanent (see the mapping table in the appendix).

- 12 -

11. Sender – Outbound The status of the request IDoc is updated; the current status is 41, indicating that the application document is created in the target system. Status 41 is final.

- 13 -

4.2 Case Study 2: System Error in Receiver System

1. Receiver – Partner Profiles Problem: An inbound parameter is missing.

2. Sender – Outbound The current status of the request IDoc is 12.

3. Receiver – Inbound The current status of the request IDoc is 56, indicating that an IDoc with errors is added (partner profile inbound not available).

- 14 -

4. Receiver – Outbound ALE audit sends back status 56 for the request IDoc.

5. Message monitoring on the Integration Server: An acknowledgment with message class SystemAck, status Error, and category transient.

6. Sender – Outbound Update of request IDoc; the current status is 39.

7. Receiver – Partner Profiles Option 1: Fixing the problem. Add an inbound partner profile and reschedule the IDoc.

- 15 -

8. Receiver – Inbound The current status of the request IDoc is 53.

9. Receiver – Outbound ALE audit sends back status 53 for the request IDoc.

10. Message monitoring on the Integration Server: Acknowledgment with message class ApplicationAck, status OK, and category permanent.

11. Sender – Outbound The status of the request IDoc is updated, the current status is 41 (final).

- 16 -

12. Receiver Option 2: The problem could not be fixed. Instead, a permanent system error occurs.

13. Receiver – Outbound ALE audit sends back status 68: error – no further processing.

14. Message monitoring on the Integration Server: Acknowledgment with message class SystemAck, status Error, and category permanent.

15. Sender – Outbound The status of the request IDoc is updated, the current status is 40, indicating that an application document is not created in the target system (final).

- 17 -

4.3 Case Study 3: Application Error

1. Receiver – Inbound The IDoc is posted to the receiver, but an application error occurs. The current status of request IDoc is 51, indicating that no application document is posted.

2. Receiver – Outbound ALE audit sends back status 51.

3. Message monitoring on the Integration Server: Acknowledgment with message class ApplicationAck, status Error, and category transient.

- 18 -

4. Sender – Outbound The status of the request IDoc is updated; the current status is 39.

5. Receiver – Outbound The application problem is solved. ALE audit sends back status 53.

6. Message monitoring on the Integration Server: Acknowledgment with message class ApplicationAck, status OK, and category permanent.

7. Sender – Outbound The status of the request IDoc is updated, the current status is 41 (final).

- 19 -

4.4 Case Study 4: Multiple Receivers (Branching)

1. Receiver XID_113 – Inbound The IDoc is posted successfully to the receiver, the current status of the request IDoc is 53.

2. Receiver XID_112 – Inbound The IDoc is posted to the receiver, but a system error occurs, and the current status of the request IDoc is 56.

3. Message monitoring on the Integration Server: The receiver XID_113 first sends a positive acknowledgment with message class ApplicationAck, status OK, and category permanent.

- 20 -

4. Message monitoring on the Integration Server: The receiver XID_112 afterwards sends a negative acknowledgment with message class SystemAck, status Error, and category transient.

5. Sender – Outbound Regardless of the order in which acknowledgments are sent to or arrive in the sender system, the positive acknowledgment of the receiver XID_113 results in final status 41 for the request IDoc. Note that once the IDoc has a final status, it will no longer be updated, even though a negative acknowledgment of a second receiver arrives. Hence, ALE does not reflect branch messages.

- 21 -

5 Appendix

5.1 Mapping IDoc Status – XI Acknowledgment Status The IDoc statuses are categorized into status groups (qualifications). The status of the IDoc at the outbound side is updated depending on the status group that the IDoc status at the inbound side belongs to. You can use transaction WE47 (Status Maintenance) to change the assignment between status and status group. The mapping table below shows how the IDoc status (inbound and outbound) and the XI acknowledgment status are related to each other. It is assumed that the IDoc status is assigned to the status groups according to the SAP default settings. The mapping table is valid unless this assignment is changed.

IDoc Status XI Acknowledgment Status Outbound (Sender) Inbound (Receiver) Main/MessageClass Ack/Status Ack/Category 39 50 SystemAck OK Permanent 39 56, others SystemAck Error Transient 40 68 SystemAck Error Permanent 39 51 ApplicationAck Error Transient 41 52, 53 ApplicationAck OK Permanent

Legend: 39 IDoc is in the target system 40 Application document is not created in target system 41 Application document is created in target system 50 IDoc is added 51 Application document is not posted 52 Application document is not fully posted 53 Application document is posted 56 IDoc with errors is added 68 Error – No further processing

www.sdn.sap.com/irj/sdn/howtoguides