How To Monitor Industry-Speak Scenarios

SAP NetWeaver How-To Guide
How To... Monitor Industry-Speak Scenarios
Applicable Releases: SAP NetWeaver Process Integration 7.1
Topic Area: SOA Middleware Capability: Service Bus
Version 1.1 April 2008
Copyright 2008 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, Informix, i5/OS, POWER, POWER5, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation. Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated 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. Disclaimer Some components of this product are based on Java. Any code change in these components may cause unpredictable and severe malfunctions and is therefore expressively prohibited, as is any decompilation of these components. Any Java Source Code delivered with this product is only to be used by SAPs Support Services and may not be modified or altered in any way.
Document History
Document Version 1.10 1.00 Description Update for PI 7.1 First official release of this guide
Typographic Conventions
Type Style Example Text Description Words or characters quoted from the screen. These include field names, screen titles, pushbuttons labels, menu names, menu paths, and menu options. Cross-references to other documentation Example text Emphasized words or phrases in body text, graphic titles, and table titles File and directory names and their paths, messages, names of variables and parameters, source text, and names of installation, upgrade and database tools. User entry texts. These are words or characters that you enter in the system exactly as they appear in the documentation. Variable user entry. Angle brackets indicate that you replace these words and characters with appropriate entries to make entries in the system. Keys on the keyboard, for example, F2 or ENTER.
Icons
Icon Description Caution Note or Important Example Recommendation or Tip
Example text
Example text
<Example text>
EXAMPLE TEXT
Table of Contents
1. 2. Business Scenario............................................................................................................... 1 Background Information..................................................................................................... 2 2.1 2.2 2.3 2.4 2.5 3. 4. Component Monitoring ................................................................................................. 3 Message Monitoring ..................................................................................................... 3 End-to-End Monitoring.................................................................................................. 3 Alerting.......................................................................................................................... 3 Acknowledgments ........................................................................................................ 5
Test Landscape.................................................................................................................... 6 Best Practices ...................................................................................................................... 8 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 Industry-Standard-Specific Configuration Steps .......................................................... 8 Good Day Scenario 1: Strong Receipt Acknowledgment (Single-Action PIP) ........... 12 Good Day Scenario 2: Weak Receipt Acknowledgment (Single-Action PIP) ............ 16 Good Day Scenario 3: Secure Communication (Single-Action PIP) .......................... 18 Good Day Scenario 4: End-to-End Monitoring (Single-Action PIP) ........................... 23 Bad Day Scenario 1: System Error in Integration Server (Single-Action PIP) ........... 27 Bad Day Scenario 2: Time to Acknowledge Fails (Single-Action PIP)....................... 30 Bad Day Scenario 3: Validation Fails Due to Mismatch in Partner Agreement (Single-Action PIP) ..................................................................................................... 32 Bad Day Scenario 4: Security Verification Fails (Single-Action PIP) ......................... 35
4.10 Bad Day Scenario 5: Time to Perform Fails (Two-Action PIP)................................... 38 4.11 Bad Day Scenario 6: XML Validation Fails (Single-Action PIP) ................................. 40
1.
Business Scenario
Several industry standard organizations have been founded by companies within the same business sector in order to define industry-wide and open standards for their business processes, mainly focusing on their business-to-business (B2B) processes. These standards include RosettaNet for the high tech industry, CIDX (Chemical Industry Data Exchange) for the chemical industry, PIDX (Petroleum Industry Data Exchange) for the oil and gas industry, and UCCNet (Uniform Code Council) for the consumer products and retail industry. The RosettaNet standard, like other vertical standards, defines collaborative business processes between supply chain trading partners. The RosettaNet Implementation Framework (RNIF) specifies standardized message exchange at transport, routing, packaging, and transaction level. Business processes between trading partners are based on Partner Interface Processes (PIP). PIPs are system-to-system XML-based dialogs. Each PIP includes a business document, and specifies the choreography of the business transaction dialog (BTD). There are two message types: RosettaNet action message: contains business content, for example purchase order data. RosettaNet signal message: acknowledgment/exception sent in response to an action message.
PIPs do not describe complex business processes, but rather a simple, transactional exchange of business documents that could be either: Single-action: one-way notification Two-action: request and confirmation
In addition to the document itself, PIPs specify the partner business roles (for example, buyer, seller, initiator, responder), activities between roles, the sequence of documents that are exchanged, timeouts, retry mechanisms, security settings (signature, encryption, non-repudiation of receipt, of origin, and of content) and so on.
September 2008
2.

Background Information
RNIF adapters for the high tech industry, based on RosettaNet protocol RNIF 1.1 and RNIF 2.0 CIDX adapter for the chemical industry, based on RNIF 1.1 protocol
The B2B adapters provided by SAP NetWeaver Process Integration (SAP PI) follow the industryspecific standards based on the industry they are aligned to:
For more information about the RNIF adapter and CIDX adapter, see SAP Help Portal at help.sap.com SAP NetWeaver SAP NetWeaver PI/Mobile 7.1 SAP NetWeaver Process Integration 7.1 SAP NetWeaver Process Integration Library IT Scenarios at a Glance Enabling Business-toBusiness Processes. Scroll down to section Further Information Development, and enter the SAP NetWeaver Developer's Guide under Enabling Business-to-Business Processes. Go to Tasks Designing B2B Processes. Here you find links pointing to Configuring the RNIF Adapter and Configuring the CIDX Adapter sections. For more information about the configuration of the related business packages, see the corresponding configuration guides. You can find the configuration guide for the RosettaNet business package on SAP Service Marketplace at service.sap.com/ibc Industry Solutions SAP for HighTech Order to Invoice RosettaNet. You can find the configuration guide for the CIDX business package on SAP Service Marketplace at service.sap.com/ibc Industry Solutions SAP for Chemicals Order to Invoice. According to the RosettaNet specification, the respective XML document must comply with its corresponding schema. As of SAP PI 7.1, XML validation allows you to check the structure of the message payload against its schema. Both the RNIF protocol and the CIDX protocol require that the sender is informed asynchronously about an XML validation error. So, the validation has to be done in the sender adapter. For more details about XML validation, see SAP Help Portal at help.sap.com SAP NetWeaver SAP NetWeaver PI/Mobile 7.1 SAP NetWeaver Process Integration 7.1 SAP NetWeaver Process Integration Library Function-Oriented View Process Integration Integration Engine Processing XML Messages XML Validation. This How-to Guide deals with the monitoring concepts that are available for the industry standard adapters within SAP NetWeaver Process Integration. The different monitoring concepts are described in relation to the RNIF 1.1 protocol. However, the concepts are also applicable to RNIF 2.0 and CIDX. The following monitoring mechanisms are adopted in SAP PI: Component monitoring Message monitoring End-to-end monitoring Alerting Acknowledgments
This chapter provides a brief introduction to the different monitoring tools, focusing in particular on the monitoring of the RNIF adapters. For more information about the monitoring functions of SAP PI in general, see the documentation on SAP Help Portal at help.sap.com SAP NetWeaver SAP NetWeaver PI/Mobile 7.1 SAP NetWeaver Process Integration 7.1 SAP NetWeaver Process Integration Library Administrators Guide Technical Operations for SAP NetWeaver Administration of SAP NetWeaver Systems PI (Process Integration) Monitoring.
September 2008
2.1
Component Monitoring
Component monitoring can be accessed using either the NetWeaver Administrator for PI (NWAPI) or the Runtime Workbench (RWB). It enables you to display an overview of the status of each component of SAP PI. For the Adapter Engines, you can launch the Communication Channel Monitor, which provides an overview of the status of the individual adapters and communication channels. Here, you can check whether the configured RNIF adapters work properly.
2.2
Message Monitoring
Both RWB and NWAPI provide central access to all message monitoring tools, for example for the Integration Server of SAP PI, Integration Engines of SAP Web Application Server based application systems, and Adapter Engines. It allows you to study the messages in detail in order to find errors that occurred during message processing. For the Adapter Engine, the following type of information is displayed in the detail view of the message monitoring: Message Data: Displays all relevant message header information. Message Content: Displays envelope and payload of selected message. Message Audit: Displays a detailed list of the individual steps carried out during message processing. Message Security: Displays the security agreements as well as the certificates used (only when handling message-level security or communication-level security). Adapter Details: Displays the RosettaNet transaction trace (only for messages that have been processed by the RNIF adapter). End-to-End: Opens the end-to-end monitoring instance view of the selected message (only if respective data exists).
2.3
End-to-End Monitoring
End-to-end monitoring allows you to trace the complete message flow, from start to end. It displays the status of each message processing step within the individual components that the message went through. It is based on the Process Monitoring Infrastructure (PMI) shipped by the SAP Web Application Server. For the RNIF adapters, a set of agents is invoked, for example adapter inbound agent, adapter outbound agent, ID mapping agent, status agent. These agents pass the relevant monitoring data to PMI.
2.4
Alerting
Alerts are used to notify users about critical situations, so that immediate and timely action can be taken. Message-based alerting is embedded within both the RWB and NWAPI, and is based on the Alert Framework that is shipped by the SAP Web Application Server. By defining alerting rules, you can restrict the alerts to be triggered depending on message header properties, or the component where the error occurs. For example, you can define a specific alert category for errors that occur during processing within RNIF adapters only. By default, the alerts are routed to the alert inbox. In addition, they can be sent to various other delivery channels, such as e-mail or cell phone.
September 2008
With respect to industry standard adapters, alerts are triggered for various scenarios, which are discussed here. In general, whenever a business transaction dialog fails, an alert is raised. The following use cases exist:
Use case System receives exception
Comments System receives an exception for an action message that is sent to its partner. On the partner side, the processing of the action message fails, and the partner system sends an exception instead of a receipt acknowledgment to the initiating system. Possible reason for failure: Validation fails. System sends an exception for a failed action message that is sent by a partner. Possible reason for failure: Any error in action message, system error or application error during further processing in Integration Server. System receives a notification of failure (NOF) due to a failure in message processing on the partner side. After the system sent an action message to its partner, a receipt acknowledgment was received, but followed by an NOF. Possible reason: Action or response message processing failed. The time to acknowledge receipt criterion has not been met. Partner system fails to send a receipt acknowledgment for the action message sent by the system. The specified number of retries is exceeded, so the BTD fails. Applicable for singleaction notification, and two-action request and confirmation. The time to perform criterion has not been met. System receives a receipt acknowledgment, but no response message. Partner system fails to send a confirmation/response. The specified time to wait for a response is exceeded, so the BTD fails, and an exception is raised. Possible reasons: System tries to send an action message, but the necessary certificates for signing could not be found in key store. System sends signed action message, but receipt acknowledgment has no signature. System sends signed action message, but certificate is invalid. Response could not be correlated to action message.
Supported by RNIF/CIDX
System sends exception
RNIF/CIDX
System receives NOF
RNIF
Time to acknowledge fails
RNIF/CIDX
Time to perform fails (Two-action only)
RNIF
Security failure
RNIF/CIDX
Correlation (Two-action only)
RNIF
September 2008
The information that is included with the alert enables easy identification of the message and the type of error. In addition to the standard parameters like message GUID and header information, the following industry-speak-specific information is provided: Parameter SXMS_TO_ADAPTER_TYPE SXMS_TO_ADAPTER_ERRTXT SXMS_AF_ERRVAL1 SXMS_AF_ERRVAL2 SXMS_AF_ERRVAL3 SXMS_AF_ERRVAL4 SXMS_AF_ERRVAL5 SXMS_AF_ERRVAL6 SXMS_AF_ERRVAL7 SXMS_AF_ERRVAL8 Description Adapter type (here: RNIF) Adapter error text Message ID of initiating action message Message tracking ID Document ID of action message Time stamp of action message Process instance ID of action message Message ID of exception signal message Message ID of NOF Process ID of NOF
2.5

Acknowledgments
An acknowledgment replies to an asynchronous request message in order to inform the sender about the status of the message processing. There are four different types of acknowledgments: System acknowledgment: Sent back when the request message arrives at the final receiver. System error acknowledgment: Sent back when a system error occurs during message processing within SAP PI. Application acknowledgment: Sent back when the request 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 RosettaNet notation, acknowledgments are called RosettaNet signal messages. The following signal types exist: Positive signal message:
{
Receipt acknowledgment: Partner considers action to be valid, both structurally and syntactically. Also, to track reliability of delivery, and for non-repudiation purposes. Acceptance acknowledgment: Sent when partner accepts message to be processed in his backend. However, this does not indicate success or failure of message processing (supported by RNIF 1.1 only)
Negative signal message:

{
Receipt acknowledgment exception: Partner considers action to be invalid either structurally or syntactically (supported by RNIF 1.1 only). Acceptance acknowledgment exception: Partner does not accept action for processing in backend (supported by RNIF 1.1 only). General exception: Any other error not mentioned above.
September 2008
In general, the sender of the request message has to explicitly specify which type of acknowledgment is requested. For the industry standard adapters, you have to configure the receipt acknowledgment mode in the sender communication channel. The following types of acknowledgments are requested depending on the mode: Strong mode:
{ { {
System acknowledgment System error acknowledgment Application error acknowledgment
Weak mode:
{ {
System error acknowledgment Application error acknowledgment
3.
Test Landscape
For the test runs, two Adapter Engines communicate with each other using the RosettaNet protocol, hence simulating B2B transaction between two RosettaNet-compliant trading partners. The central Adapter Engine acts as the initiator, a non-central Adapter Engine as the responder. Two scenarios are considered: PIP0C1: Asynchronous Test Notification PIP0C2: Asynchronous Test Request/Confirmation
Single-Action PIP: PIP0C1 Asynchronous Test Notification

Initiator * (RNIF) Responder * (RNIF) XI IS Responder Business System
RNIF::Request XI::Request Request Message XI::Ack RNIF::ReceiptAck
* Initiator: Central AE Responder: Non-Central AE
September 2008
Two-Action PIP: PIP0C2 Asynchronous Test Request/Confirmation

Initiator * (RNIF) Responder * (RNIF) XI IS Responder Business System
RNIF::Request XI::Request Request Message XI::Ack RNIF::ReceiptAck Confirm Message XI::Confirm RNIF::Confirm RNIF::ReceiptAck
* Initiator: Central AE Responder: Non-Central AE
September 2008
4.
4.1
...
Best Practices
Industry-Standard-Specific Configuration Steps
The following examples demonstrate some industry-standard-specific configuration steps based on the single-action PIP PIP0C1. The partner roles are initiator and responder. 1. Start the Integration Builder (Configuration). Create new communication parties (shortened to: parties) for the trading partners involved in the collaboration process. For each party, maintain Alternative Identifiers to uniquely identify the party across company boundaries. Here, Dun & Bradstreet Corporation is used as the agency, and DUNS number as the scheme. Create a new service for the party. The service name has to comply with the following notation: PIP<PIP Code>_<PIP Version>_<Partner Role> Example PIP0C1_R0102_Responder
2.
Create a communication channel by importing a communication channel template. It is part of the business package for RosettaNet.
September 2008
3.
For the receiver communication channel, select template PIP0C1_R0102_Responder_Receive_AsynchronousTestNotificationAction_11.
4. The message-protocol-specific information and PIP information is specified automatically according to the template chosen.
September 2008
5. You only have to maintain the transport parameters and authentication. Switch to tab Target, and specify the following parameters: URL (under Transport Parameters): Specify the URL that points to the responder service that the action message is sent to. User Name/Password (under Authentication): Specify the corresponding user name and password. Here, the non-central Adapter Engine is addressed.
6. For the sender communication channel, select template PIP0C1_R0102_Initiator_Send_AsynchronousTestNotificationAction_11.
September 2008
10
7. The message-protocol-specific information and PIP information is specified automatically according to the template chosen.
8. You only have to maintain the transport parameters and authentication. Switch to tab Source, and specify the following parameters: URL (under Transport Parameters): Specify the URL that points to the initiator service. User Name/Password (under Authentication): The settings are required for sending the signal message to the sender service. Here, the central Adapter Engine is addressed.
September 2008
11
4.2
Good Day Scenario 1: Strong Receipt Acknowledgment (Single-Action PIP)

XI Reliable Messaging Header contains request for Sys Ack, Sys Error Ack, and App Error Ack
Initiator (RNIF)
Responder (RNIF Adapter)
XI IS
Business System
RNIF::Request XI::Request Request Message XI::SysAck RNIF::ReceiptAck
Upon successful delivery of XI message, IS sends Sys Ack to adapter

...
1. In the Integration Builder (Configuration), maintain the sender communication channel. Set the Receipt Acknowledgment mode to Strong.
September 2008
12
2. During runtime, the RNIF Adapter determines the partners service name for an incoming action message based on the corresponding header fields of the service header. The name is built according to the naming convention mentioned above (see chapter 4.1 [page 8]).
3. Start Message Monitoring (transaction SXMB_MONI), and display the request message. For the incoming action message, the globally unique identifier (here the DUNS number) is mapped to the internal party name using the Alternative Identifiers (normalization). The Reliable Messaging header segment shows which acknowledgment types are requested. For strong receipt acknowledgment, these are: System ack System error ack Application error ack
September 2008
13
4. Launch the RWB (optionally NWAPI), and go to Message Monitoring for the non-central Adapter Engine. The messages are exchanged in the following sequence: Inbound action message Outbound XI message Inbound XI acknowledgment Outbound signal message (receipt acknowledgment)
5. Choose Details to display the Audit Log of the action message.
September 2008
14
6. Switch to the Adapter Details tab page to display the RosettaNet transaction details, a list of all processed messages involved in the BTD, and the RosettaNet transaction trace.
September 2008
15
4.3
Good Day Scenario 2: Weak Receipt Acknowledgment (Single-Action PIP)

Responder (RNIF Adapter) XI IS Business System
Initiator (RNIF)
RNIF::Request XI::Request RNIF::ReceiptAck Request Message
XI Reliable Messaging Header contains request for Sys Error Ack, and App Error Ack
...
1. In the Integration Builder (Configuration), maintain the sender communication channel. Set the Receipt Acknowledgment mode to Weak.
2. Start Message Monitoring (transaction code SXMB_MONI), and display the request message. According to the Reliable Messaging header segment, the following acknowledgments are requested for weak receipt acknowledgment: System error ack Application error ack
September 2008
16
3. Start the RWB, and go to Message Monitoring for the non-central Adapter Engine. The messages are exchanged in the following sequence: Inbound action message Outbound XI message Outbound signal message (receipt acknowledgment)
September 2008
17
4.4
...
Good Day Scenario 3: Secure Communication (Single-Action PIP)

Maintain the message security policy parameters in the receiver communication channel (under Security Policy). You can specify the following security policies: Sign the action message Sign the signal message Non-repudiation of receipt acknowledgment, and of origin and content
1. Start the Integration Builder (Configuration).
2. Maintain the message security policy parameters in the sender communication channel.
September 2008
18
3. In the receiver agreement, specify the security settings Maintain the trust model. For Trust Model, select direct. In this case, the partners certificate is directly validated against the certificate in the J2EE key store. Under Current Certificate for Signing, maintain the following parameters: Algorithm (SHA-1 and MD5 are supported, here SHA-1 is selected). Keystore View. Keystore Entry (here, enter the name of the initiators private key).
Under Partner Certificate for Signing, maintain the following parameters: Keystore View. Keystore Entry (here, enter the name of the partners public key).
September 2008
19
4. In the sender agreement, specify the security settings. Maintain the trust model (see previous step). Under Current Certificate for Signing, maintain the following parameters: Algorithm (SHA-1 and MD5 are supported, here SHA-1 is selected). Keystore View. Keystore Entry (here, enter the name of the responders private key).
Under Partner Certificate for Signing, maintain the following parameters: Keystore View. Keystore Entry (here, enter the name of the initiators public key).
5. Start the RWB, and go to Message Monitoring for the central Adapter Engine. Select the action message, and choose Details. The Audit Log indicates that the action message was signed using the private key of the initiator.
September 2008
20
6. Switch to the Message Security tab page. The Message Security Monitor shows the details about the RNIF security agreements, and the certificate used.
7. Go to Message Monitoring for the non-central Adapter Engine, select the action message, and choose Details. The Audit Log indicates that the action message was verified using the public key of the initiator.
8. Analogously to the action message, you can monitor the security settings of the signal message. The signal message is signed using the responders private key.
September 2008
21
9. The signal message is verified using the responders public key.
10. The Message Security Monitor shows the details about the certificate used.
September 2008
22
4.5
Good Day Scenario 4: End-to-End Monitoring (Single-Action PIP)
To describe end-to-end monitoring, the figure below depicts a message that is sent from SAP ERP via SAP PI and the RNIF adapter of the central Adapter Engine, to the RNIF adapter of the non-central Adapter Engine.
Initiator (SAP ERP) Integration Server RNIF adapter (Central AE) RNIF adapter (Non-Central AE)
XI::Request XI::Request RNIF::Request RNIF::ReceiptAck
...
1. Start the RWB, and go to End-to-End Monitoring. Select the respective message. This takes you to the Instance View where detailed information about an instance (here a message) is provided both in table form and graphically. The request message is sent from the SAP ERP system to SAP PI using the ABAP proxy runtime. The PMI inbound agent tracks the message coming into the local Integration Engine of SAP ERP. It is called immediately after a message is received. Thereafter, the message is sent to the Integration Server.
September 2008
23
2. After the request message comes into the Integration Server, the receiver is determined, and the message is transferred to the central Adapter Engine for further processing.
3. In the central Adapter Engine, the incoming message is tracked, followed by a channel determination, and an ID mapping. The ID mapping agent tracks any change of the message ID. It is called immediately after the message ID is changed, in this case after the conversion from an XI message to an RNIF message. Finally, the status agent tracks the status of the message processing. In this case, it is stated that the message was successfully delivered.
September 2008
24
4. Select a process step. This opens the attribute display where detailed information about the selected process step is displayed. Here, the details for the channel determination step are displayed. To access further analysis tools, choose the tool icon next to the message ID. This starts Message Monitoring.
5. The outbound agent tracks the sending of a message. It is called before a message is sent out of the adapter. In the example, it is stated that the action message has been sent out of the RNIF adapter.
6. In the RNIF adapter of the non-central Adapter Engine, the inbound agent is invoked to track the incoming of the action message.
September 2008
25
7. The ID mapping is tracked while the RNIF message is converted to an XI message, and the XI message is sent to the PI resource adapter.
8. In the RNIF adapter of the central Adapter Engine, the inbound agent is invoked to track the incoming of the signal message.
September 2008
26
4.6
Bad Day Scenario 1: System Error in Integration Server (Single-Action PIP)
An error occurs in the Integration Server (for example, no receiver could be determined), so a transient system error acknowledgment is sent back. After the message has been canceled, a permanent system error acknowledgment is sent back to the initiator of the action message.
XI Reliable Messaging Header contains request for Sys Ack, Sys Error Ack, and App Error Ack
Initiator (RNIF)
Responder (RNIF Adapter)
XI IS
Business System
RNIF::Request XI::Request Delivery of XI Message fails
XI::SysErrorAck (transient) XI::SysErrorAck (permanent) RNIF::Exception In XI, message turns to final error state
Alert
...
Alert
1. Start Message Monitoring for the non-central Adapter Engine in the RWB, and display the adapter details. The RosettaNet transaction trace indicates that two XI system error acknowledgments were sent from the Integration Server to the non-central Adapter Engine. When the permanent system error acknowledgment arrives, an RNIF exception signal is sent back to the initiator.
September 2008
27
2. Go to Message Monitoring for the central Adapter Engine in the RWB, and display the adapter details. A general exception signal was sent from the responder to the initiator, and a corresponding alert was raised.
3. In RWB, start your Alert Inbox. An alert was raised by the sender of the general exception, that is, the RNIF adapter of the noncentral Adapter Engine.
September 2008
28
4. An alert was raised by the receiver of the general exception, that is, the RNIF adapter of the central Adapter Engine.
5. The RNIF adapter forwards the RNIF exception as an XI system error acknowledgment, as can be seen in Message Monitoring (transaction code SXMB_MONI).
September 2008
29
4.7
Bad Day Scenario 2: Time to Acknowledge Fails (Single-Action PIP)
The initiator sends an action message to the trading partner, but the delivery of the corresponding receipt acknowledgment fails.
XI IS Initiator (RNIF Adapter) Responder (RNIF)
XI::Request RNIF::Request No delivery of ReceiptAck
retry RNIF::Request retry RNIF::Request retry RNIF::Request
Alert
...
1. Start the Integration Builder (Configuration), and maintain the Number of Retries, and the Time to Acknowledge Receipt. In the receiver communication channel, under Message Exchange Controls, maintain the following parameters: Time to Acknowledge Receipt: Indicates the time by which the acknowledgment of receipt signal must be returned Number of Retries: Indicates how often the action message is retransmitted before the adapter receives a signal from the partner.
In this example, for test purposes the action message should be resent every 2 minutes as long as a receipt acknowledgment has not been received, up to maximum of 3 times.
September 2008
30
2. Go to Message Monitoring for the central Adapter Engine in the RWB, and display the adapter details. The RosettaNet Transaction Trace indicates that the acknowledgment period expired, and that the action message was resent to the partner. Finally, the maximum number of retries exceeded, and a corresponding alert was raised.
3. In RWB, start your Alert Inbox. An alert was raised by the initiator of the action message, that is, the RNIF adapter of the central Adapter Engine.
September 2008
31
4.8
Bad Day Scenario 3: Validation Fails Due to Mismatch in Partner Agreement (Single-Action PIP)
The initiator sends an action message to the trading partner, but the validation of the message against the sender agreement of the partner fails.
Initiator (RNIF) Responder (RNIF adapter)
RNIF::Request RNIF::Exception Mismatch in contents of partner agreement
Alert
...
Alert
1. Go to Message Monitoring for the central Adapter Engine in the RWB, and display the adapter details. The RosettaNet Transaction Trace indicates that a general exception signal was sent from the responder to the initiator, and that a corresponding alert was raised.
September 2008
32
2. Enter Message Monitoring (transaction code SXMB_MONI), and display the details of the XI system error acknowledgment. The Error header segment indicates that an error occurred during reading or validation of an RNIF action message.
September 2008
33
5. The general exception contains details about the reason for the validation failure. In general, the incoming action message is validated against the following parameters in the sender communication channel: Process name Transaction name Requesting action Code Version Current role Partner role
September 2008
34
4.9
Bad Day Scenario 4: Security Verification Fails (Single-Action PIP)
The initiator sends a signed action message to the trading partner, but the signature verification fails on the partner side.
RNIF::Request RNIF::Exception Signature verification fails
Alert
...
Alert
1. Launch the RWB, and go to Message Monitoring for the non-central Adapter Engine. Select the action message, and choose Details. The Audit Log indicates that the signature verification failed because the action message was signed with a different key.
2. Go to Message Monitoring for the central Adapter Engine, and display the adapter details. The RosettaNet Transaction Trace indicates that a general exception signal was sent to the initiator, and that a corresponding alert was raised.
September 2008
35
3. The general exception contains details about the reason for failure.
September 2008
36
September 2008
37
4.10 Bad Day Scenario 5: Time to Perform Fails (TwoAction PIP)

The initiator sends an action message to the trading partner who fails to return a confirmation in time.
XI IS Initiator (RNIF Adapter) Responder (RNIF)
XI::Request RNIF::Request RNIF::ReceiptAck XI::Ack No delivery of Confirm Message
Alert
...
1. Start the Integration Builder (Configuration). In the receiver communication channel, under Message Exchange Controls, maintain the following parameters: Number of Retries Time to Acknowledge Receipt Time to Perform: Indicates the time by which the response message in a twoaction PIP must be returned.
In this example, for test purposes the partner that received the action message has to send a confirmation within 5 minutes. Otherwise, the BTD fails.
September 2008
38
2. Go to Message Monitoring for the central Adapter Engine in the RWB, and display the adapter details. The RosettaNet Transaction Trace indicates that the time to perform expired while waiting for a response action message, and that a corresponding alert was raised.
September 2008
39
4.11 Bad Day Scenario 6: XML Validation Fails (SingleAction PIP)

The initiator sends an action message to the trading partner, but the XML validation fails on the partner side. The partner returns an exception to the initiator.
RNIF::Request RNIF::Exception Payload does not comply with schema
Alert
...
Alert
1. In the Integration Builder (Configuration), maintain the sender agreement. Set the Schema Validation to Validation by Adapter.
2. Launch the RWB, and go to Message Monitoring for the central Adapter Engine. Select the action message, and choose Details. Switch to tab Adapter Details. The RosettaNet Transaction Trace indicates that a general exception signal was sent to the initiator.
September 2008
40
3. Select the general exception message, and choose Details. The Audit Log indicates that the XML validation failed.
4. In RWB, start your Alert Inbox. An alert was raised indicating that an XML validation error occured.
September 2008
41
www.sdn.sap.com/irj/sdn/howtoguides

How To Monitor Industry-Speak Scenarios

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

How To Monitor Industry-Speak Scenarios

Uploaded by

Copyright:

Available Formats

SAP NetWeaver How-To Guide

How To... Monitor Industry-Speak Scenarios

Applicable Releases: SAP NetWeaver Process Integration 7.1

Topic Area: SOA Middleware Capability: Service Bus

Version 1.1 April 2008

How To... Monitor Industry-Speak Scenarios

How To... Monitor Industry-Speak Scenarios

How To... Monitor Industry-Speak Scenarios

How To... Monitor Industry-Speak Scenarios

Use case System receives exception

System sends exception

System receives NOF

Time to acknowledge fails

Time to perform fails (Two-action only)

Correlation (Two-action only)

How To... Monitor Industry-Speak Scenarios

Negative signal message:

How To... Monitor Industry-Speak Scenarios

System acknowledgment System error acknowledgment Application error acknowledgment

System error acknowledgment Application error acknowledgment

Single-Action PIP: PIP0C1 Asynchronous Test Notification

RNIF::Request XI::Request Request Message XI::Ack RNIF::ReceiptAck

* Initiator: Central AE Responder: Non-Central AE

How To... Monitor Industry-Speak Scenarios

Two-Action PIP: PIP0C2 Asynchronous Test Request/Confirmation

* Initiator: Central AE Responder: Non-Central AE

How To... Monitor Industry-Speak Scenarios

How To... Monitor Industry-Speak Scenarios

For the receiver communication channel, select template PIP0C1_R0102_Responder_Receive_AsynchronousTestNotificationAction_11.

How To... Monitor Industry-Speak Scenarios

6. For the sender communication channel, select template PIP0C1_R0102_Initiator_Send_AsynchronousTestNotificationAction_11.

How To... Monitor Industry-Speak Scenarios

How To... Monitor Industry-Speak Scenarios

Good Day Scenario 1: Strong Receipt Acknowledgment (Single-Action PIP)

Responder (RNIF Adapter)

RNIF::Request XI::Request Request Message XI::SysAck RNIF::ReceiptAck

Upon successful delivery of XI message, IS sends Sys Ack to adapter

How To... Monitor Industry-Speak Scenarios

How To... Monitor Industry-Speak Scenarios

5. Choose Details to display the Audit Log of the action message.

How To... Monitor Industry-Speak Scenarios

How To... Monitor Industry-Speak Scenarios

Good Day Scenario 2: Weak Receipt Acknowledgment (Single-Action PIP)

RNIF::Request XI::Request RNIF::ReceiptAck Request Message

How To... Monitor Industry-Speak Scenarios

How To... Monitor Industry-Speak Scenarios

Good Day Scenario 3: Secure Communication (Single-Action PIP)

1. Start the Integration Builder (Configuration).

How To... Monitor Industry-Speak Scenarios

How To... Monitor Industry-Speak Scenarios

How To... Monitor Industry-Speak Scenarios

How To... Monitor Industry-Speak Scenarios

9. The signal message is verified using the responders public key.

How To... Monitor Industry-Speak Scenarios

Good Day Scenario 4: End-to-End Monitoring (Single-Action PIP)

XI::Request XI::Request RNIF::Request RNIF::ReceiptAck

How To... Monitor Industry-Speak Scenarios

How To... Monitor Industry-Speak Scenarios

How To... Monitor Industry-Speak Scenarios

How To... Monitor Industry-Speak Scenarios

Bad Day Scenario 1: System Error in Integration Server (Single-Action PIP)

Responder (RNIF Adapter)

RNIF::Request XI::Request Delivery of XI Message fails