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

IDOC

XID_112
IDoc Adapter

IDoc Adapter
IDOC ALEAUD
Integration
Server
IDOC
B6M_000 ALEAUD U6D_700

ALEAUD
XID_113

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

Techn. Adapter

IDoc Adapter

http IDOC/tRFC
Integration
3rd Party Adapter Server
Application Engine
http XIA_100 ALEAUD XIA_113

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- 23 -
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:messa
ges.

- 24 -
3. Call transaction SXMB_MONI to
display the XI message.

The Message Class

ApplicationMessage indicates
that the acknowledgment is of
request message type.

- 25 -
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 Inbound Main/MessageClass Ack/Status Ack/Category
(Sender) (Receiver)
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

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