1. technology and computing
2. internet technology
3. email

How-to Guide
SAP NetWeaver 2004s
How To…
Handle
Acknowledgments 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
ALEAUD
IDoc Adapter
B6M_000
IDoc Adapter
IDOC
Integration
Server
U6D_700
ALEAUD
XID_112
IDOC
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
Integration
Server
Adapter
Engine
http
XIA_100
IDoc Adapter
Techn. Adapter
3rd Party
Application
http
IDOC/tRFC
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:sapcom: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.
39
39
40
39
41
IDoc Status
Outbound
Inbound
(Sender)
(Receiver)
50
56, others
68
51
52, 53
XI Acknowledgment Status
Main/MessageClass
Ack/Status
Ack/Category
SystemAck
SystemAck
SystemAck
ApplicationAck
ApplicationAck
OK
Error
Error
Error
OK
Permanent
Transient
Permanent
Transient
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