How-to Guide SAP NetWeaver 2004s

How To… Handle Acknowledg-ments for IDoc Version 1.00 – Sept 2006 Applicable Releases: SAP NetWeaver 2004s End-to-End Process Integration Enabling Application-to-Application Processes

© Copyright 2006 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 -

1 Scenarios This guide deals with the processing of acknowledgment messages for IDoc scenarios via SAP XI. The following scenarios are considered:

1.1 Scenario 1: IDoc - XI - IDoc

IntegrationServer

U6D_700

IDOC ALEAUD

IDOC

IDOC

ALEAUD

ALEAUD

XID_112

XID_113

IDoc A

dapter

IDoc A

dapterB6M_000

A sender SAP system sends an IDoc message to SAP XI. SAP XI passes the message to a receiver SAP system via IDoc adapter. Once the IDoc has been received, an ALEAUDIT IDoc is generated, and sent back to SAP XI. In SAP XI, the ALEAUDIT IDoc is converted into an acknowledgment. SAP XI sends back the acknowledgment to the sender system via IDoc adapter where it is converted into an ALEAUDIT IDoc.

1.2 Scenario 2: External System - XI - IDoc

Integration Server

XIA_100

IDOC/tRFC

ALEAUD

IDoc A

dapter XIA_113

3rd PartyApplication

AdapterEngine

Techn. Adapter

http

http

An external sender system sends a message to SAP XI via its adapter engine. SAP XI passes the message to a receiver SAP system via IDoc adapter. Once the IDoc has been received, an ALEAUDIT IDoc is generated, and sent back to SAP XI. In general, technical sender adapters are not able to request acknowledgments (except for industry speak adapters). So, the acknowledgment won't be passed back to the sender system. Instead, the ALEAUDIT IDoc has to be converted into an XI request message in order to be accepted by the sender system.

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.

- 2 -

• 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:

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

To change the default request setting, the corresponding message type has to be maintained in an exception table. Prior to SAP NetWeaver '04s Exchange Infrastructure SPS09, the exception table has to be explicitly edited. As of SAP NetWeaver '04s Exchange Infrastructure SPS09, a program is provided to configure the acknowledgment requests (see chapter 3.4).

As stated above, technical sender adapters do not request any acknowledgments. In this case, the ALEAUDIT IDoc has to be converted to an XI request message before sent back to the sender of the original message. The sending of acknowledgments as XI request messages is supported as of SAP NetWeaver '04s Exchange Infrastructure SPS09 (see chapter 6).

Note that the resulting XI request message is a new message, and does not refer to the original request message sent by the external sender system. The message monitoring is not able to determine the link to the original message.

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).

- 3 -

3 Configure Scenario 1: IDoc - XI - IDoc

3.1 Configure ALE Audit in the Receiver System

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

2. Call 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. Call transaction SM59 to maintain the RFC destination U6D_700 pointing to the Integration Server.

- 4 -

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

5. Call 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.

- 5 -

7. Configure sending of confirmations. Call transaction RBDSTATE to create the variant SAP_AUDIT_SEND for program RBDSTATE.

8. Schedule a background job in the receiver system to periodically send the audit data to the sender system. Call transaction SM36 to define a job referring to program RBDSTATE, and variant SAP_AUDIT_SEND.

- 6 -

3.2 Configure 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.

For acknowledgments, no routing rules are required; you only have to define a receiver communication channel. If there are several communication channels of adapter type IDoc, the channel starting with Ack is used.

- 7 -

3.3 Configure the Integration Server (Optional)

1. Call transaction SXMB_ADM (Integration Engine - Configuration) to obtain system error acknowledgments from pipeline services of the Integration Server. 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.

- 8 -

3.4 Configure Acknowledgment Requests (Optional)

1. Prior to SAP NetWeaver '04s Exchange Infrastructure SPS09: If you want to suppress any kind of acknowledgment for a specific message type, maintain table IDXNOALE. Call transaction SE16, and specify port, client of the sender, and message type.

2. As of SAP NetWeaver '04s Exchange Infrastructure SPS09: Call transaction SE38, and run program IDX_NOALE. Specify Sender Port, and Sender Client. Choose either Request Acknowledgment or Do Not Request Acknowledgment. If necessary, define exceptions.

3. Call transaction SE16 to check entries in table IDXNOALE.

- 9 -

4. Call transaction SXMB_MONI to display the XI messages. 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.

- 10 -

4 Message Monitoring Aspects

1. Call transaction SXMB_MONI (Integration Engine - Monitoring Monitor for Processed XML Messages) to display the XI 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 at the right hand, 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.

- 11 -

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.

- 12 -

5 Scenario 1: Case Studies

5.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.

- 13 -

4. Sender – Inbound: Within the IDoc adapter, an IDoc of message type ALEAUD is created and sent to the sender system. Call 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 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.

- 14 -

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 mapping table in the appendix).

- 15 -

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.

- 16 -

5.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).

- 17 -

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

5. Message monitoring on the Integration Server: An acknowledgment is created 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.

- 18 -

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: An acknowledgment is created 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).

- 19 -

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: An acknowledgment is created 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).

- 20 -

5.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: An acknowledgment is created with message class ApplicationAck, status Error, and category transient.

- 21 -

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: An acknowledgment is created 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).

- 22 -

5.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.

- 23 -

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.

- 24 -

6 Configure Scenario 2: ALEAUDIT as request message

1. In the Integration Server, call transaction SE38, and run program IDX_ALEREQUEST to process IDocs with message type ALEAUD as XI request message. Enter Sender Port, Sender Client, Partner Number, Partner Type, and Partner Role.

For the Partner Number, you can use wildcards.

2. In Integration Directory, configure routing of interface ALEAUD.ALEAUD01, namespace urn:sap-com:document:sap:idoc:messages.

- 25 -

3. Call transaction SXMB_MONI to display the XI message. The Message Class ApplicationMessage indicates that the acknowledgment is of request message type.

- 26 -

7 Appendix

7.1 Mapping IDoc Status – XI Acknowledgment Status The IDoc status 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 call 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