How to Monitor Industry-Speak Scenarios

7/27/2019 How to Monitor Industry-Speak Scenarios

1/47

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


2/47

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 withrespect 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 consequentialdamages 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 apractical 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 ofthe 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.


3/47

Document History

Document Version Description

1.10 Update for PI 7.11.00 First official release of this guide


4/47

Typographic Conventions

Type Style Descript ion

Example Text Words or characters quotedfrom 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

Exampl e text File and directory names and

their paths, messages,

names of variables and

parameters, source text, and

names of installation,

upgrade and database tools.

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

EXAMPLE TEXT Keys on the keyboard, forexample, F2 orENTER.

Icons

Icon Description

CautionNote or Important

Example

Recommendation or Tip


5/47

Table of Contents

1. Business Scenario...............................................................................................................12. Background Informat ion .....................................................................................................2

2.1 Component Monitoring.................................................................................................32.2 Message Monitoring.....................................................................................................32.3 End-to-End Monitoring..................................................................................................32.4 Alerting..........................................................................................................................32.5 Acknowledgments ........................................................................................................5

3. Test Landscape....................................................................................................................64. Best Practices ......................................................................................................................8

4.1 Industry-Standard-Specific Configuration Steps ..........................................................84.2 Good Day Scenario 1: Strong Receipt Acknowledgment (Single-Action PIP)........... 124.3 Good Day Scenario 2: Weak Receipt Acknowledgment (Single-Action PIP) ............ 164.4 Good Day Scenario 3: Secure Communication (Single-Action PIP)..........................184.5 Good Day Scenario 4: End-to-End Monitoring (Single-Action PIP) ...........................234.6 Bad Day Scenario 1: System Error in Integration Server (Single-Action PIP) ........... 274.7 Bad Day Scenario 2: Time to Acknowledge Fails (Single-Action PIP).......................304.8 Bad Day Scenario 3: Validation Fails Due to Mismatch in Partner Agreement

(Single-Action PIP) .....................................................................................................324.9 Bad Day Scenario 4: Security Verification Fails (Single-Action PIP) .........................354.10 Bad Day Scenario 5: Time to Perform Fails (Two-Action PIP)................................... 384.11 Bad Day Scenario 6: XML Validation Fails (Single-Action PIP).................................40


6/47

How To... Monitor Industry-Speak Scenarios

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 1


7/47


2. Background Information

The B2B adapters provided by SAP NetWeaver Process Integration (SAP PI) follow the industry-

specific standards based on the industry they are aligned to:

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

For more information about the RNIF adapter and CIDX adapter, see SAP Help Portal at help.sap.com

SAP NetWeaverSAP NetWeaver PI/Mobile 7.1 SAP NetWeaver Process Integration 7.1

SAP NetWeaver Process Integration Library IT Scenarios at a Glance Enabling Business-to-

Business Processes. Scroll down to section Further Information Development, and enter the SAP

NetWeaver Developer's Guide under Enabling Business-to-Business Processes. Go toTasks

Designing B2B Processes. Here you find links pointing to Configuring the RNIF Adapterand

Configuring the CIDX Adaptersections.

For more information about the configuration of the related business packages, see the correspondingconfiguration 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 inthe sender adapter.

For more details about XML validation, see SAP Help Portal at help.sap.comSAP 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.comSAP NetWeaverSAP

NetWeaver PI/Mobile 7.1 SAP NetWeaver Process Integration 7.1 SAP NetWeaver Process

Integration Library Administrators Guide Technical Operations for SAP NetWeaverAdministration of SAP NetWeaver Systems PI (Process Integration) Monitoring.

September 2008 2


8/47


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


9/47


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 Comments Supported by

System receives exception 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.

RNIF/CIDX

System sends exception 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 duringfurther processing in Integration Server.

RNIF/CIDX

System receives NOF 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.

RNIF

Time to acknowledge fails The time to acknowledge receipt criterion has not

been met. Partner system fails to send a receiptacknowledgment for the action message sent by the

system. The specified number of retries is

exceeded, so the BTD fails. Applicable for single-

action notification, and two-action request and

confirmation.

RNIF/CIDX

Time to perform fails

(Two-action only)

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.

RNIF

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

RNIF/CIDX

Correlation

(Two-action only)

Response could not be correlated to action

message.

RNIF

September 2008 4


10/47


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 Description

SXMS_TO_ADAPTER_TYPE Adapter type (here: RNIF)

SXMS_TO_ADAPTER_ERRTXT Adapter error text

SXMS_AF_ERRVAL1 Message ID of initiating action message

SXMS_AF_ERRVAL2 Message tracking ID

SXMS_AF_ERRVAL3 Document ID of action message

SXMS_AF_ERRVAL4 Time stamp of action message

SXMS_AF_ERRVAL5 Process instance ID of action message

SXMS_AF_ERRVAL6 Message ID of exception signal message

SXMS_AF_ERRVAL7 Message ID of NOF

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


11/47


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 LandscapeFor 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 Notif ication

RNIF::Request

XI::Request

Initiator *

(RNIF)

Responder *

(RNIF)XI IS

Responder

Business System

Request Message

RNIF::ReceiptAck

XI::Ack

Initiator: Central AE

Responder: Non-Central AE

* Initiator: Central AE


*

September 2008 6


12/47


Two-Action PIP: PIP0C2 Asynchronous Test Request/Confi rmation

RNIF::Request

XI::Request

Initiator *

(RNIF)

Responder *

(RNIF)XI IS

Responder

Business System

Request Message

RNIF::ReceiptAck

XI::Ack

Initiator: Central AE


* Initiator: Central AE


*

Confirm Message

XI::Confirm

RNIF::Confirm

RNIF::ReceiptAck

September 2008 7


13/47


4. Best Practices

4.1 Industry-Standard-Specific Configuration StepsThe 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 thecollaboration process.

For each party, maintainAlternative Identifiers to uniquely identify the party across companyboundaries. Here, Dun & Bradstreet Corporation is used as the agency, and DUNS number asthe scheme.

Create a new service for the party. The service name has to comply with the following notation:

PIP__

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 8


14/47


3. For the receiver communication channel, select templatePIP0C1_R0102_Responder_Receive_AsynchronousTestNotificationAction_11 .

4. The message-protocol-specific information and PIP information is specified automatically

according to the template chosen.

September 2008 9


15/47


5. You only have to maintain the transport parameters and authentication. Switch to tab Target,

and specify the following parameters:

URL (underTransport Parameters): Specify the URL that points to the responder

service that the action message is sent to.

User Name/Password (underAuthentication): Specify the corresponding user

name and password. Here, the non-central Adapter Engine is addressed.

6. For the sender communication channel, select templatePIP0C1_R0102_Initiator_Send_AsynchronousTestNotificationAction_11 .

September 2008 10


16/47


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 (underTransport Parameters): Specify the URL that points to the initiator

service.

User Name/Password (underAuthentication): The settings are required for

sending the signal message to the sender service. Here, the central Adapter

Engine is addressed.

September 2008 11


17/47


4.2 Good Day Scenario 1: Strong Receipt

Acknowledgment (Single-Action PIP)

RNIF::Request

XI::Request

Initiator

(RNIF)

Responder

(RNIF Adapter)XI IS

Business

System

Request Message

RNIF::ReceiptAck

XI::SysAck

XI Reliable Messaging Header

contains request for Sys Ack,

Sys Error Ack, and App Error Ack

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


18/47


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 (transactionSXMB_MONI), and display the request message.

For the incoming action message, the globally unique identifier (here the DUNS number) ismapped to the internal party name using theAlternative 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


19/47


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 theAudit Log of the action message.

September 2008 14


20/47


6. Switch to theAdapter 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


21/47


4.3 Good Day Scenario 2: Weak Receipt

Acknowledgment (Single-Action PIP)

RNIF::Request

XI::Request

Initiator

(RNIF)

Responder

(RNIF Adapter)XI IS

Business

System

Request Message

RNIF::ReceiptAck


contains request for


...

1. In the Integration Builder (Configuration), maintain the sender communication channel.

Set the Receipt Acknowledgment mode toWeak.

2. Start Message Monitoring (transaction code SXMB_MONI), and display the request message.According to the Reliable Messaging header segment, the following acknowledgments arerequested for weak receipt acknowledgment:

System error ack

Application error ack

September 2008 16


22/47


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


23/47


4.4 Good Day Scenario 3: Secure Communication

(Single-Action PIP)...


Maintain the message security policy parameters in the receiver communication channel (underSecurity 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

2. Maintain the message security policy parameters in the sender communication channel.

September 2008 18


24/47


3. In the receiver agreement, specify the security settings

Maintain the trust model. For Trust Model, selectdirect. In this case, the partners certificateis 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


25/47


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.

TheAudit Log indicates that the action message was signed using the private key of theinitiator.

September 2008 20


26/47


6. Switch to theMessage Security tab page.

The Message Security Monitorshows the details about the RNIF security agreements, and thecertificate used.

7. Go to Message Monitoring for the non-central Adapter Engine, select the action message, and

choose Details.

TheAudit 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


27/47


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


28/47


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.

XI::Request

XI::Request

Initiator

(SAP ERP)

Integration

Server

RNIF adapter

(Central AE)

RNIF adapter

(Non-Central AE)

RNIF::ReceiptAck

RNIF::Request

...

1. Start the RWB, and go to End-to-End Monitoring.

Select the respective message. This takes you to the Instance View where detailed informationabout 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 proxyruntime. 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 sentto the Integration Server.

September 2008 23


29/47


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

Finally, the status agent tracks the status of the message processing. In this case, it is statedthat the message was successfully delivered.

September 2008 24


30/47


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 analysistools, 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 outof 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


31/47


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


32/47


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.

RNIF::Request

XI::Request

Initiator

(RNIF)

Responder

(RNIF Adapter)XI IS

Business

System

Delivery of XI

Message fails

RNIF::Exception

XI::SysErrorAck

(transient)


contains request for Sys Ack,


XI::SysErrorAck

(permanent)

In XI, message turns to

final error state

AlertAlertAlertAlert

...

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 weresent from the Integration Server to the non-central Adapter Engine. When the permanentsystem error acknowledgment arrives, an RNIF exception signal is sent back to the initiator.

September 2008 27


33/47


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 correspondingalert was raised.

3. In RWB, start yourAlert Inbox.

An alert was raised by the sender of the general exception, that is, the RNIF adapter of the non-central Adapter Engine.

September 2008 28


34/47


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


35/47


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 correspondingreceipt acknowledgment fails.

XI::Request

RNIF::Request

XI ISInitiator

(RNIF Adapter)

Responder

(RNIF)

retry RNIF::Request

No delivery of

ReceiptAck

retry RNIF::Request

retry RNIF::Request

AlertAlert

...

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 thefollowing 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 aslong as a receipt acknowledgment has not been received, up to maximum of3 times.

September 2008 30


36/47



details.

The RosettaNet Transaction Trace indicates that the acknowledgment period expired, and thatthe action message was resent to the partner. Finally, the maximum number of retries

exceeded, and a corresponding alert was raised.


An alert was raised by the initiator of the action message, that is, the RNIF adapter of thecentral Adapter Engine.

September 2008 31


37/47


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.

RNIF::Request

Initiator

(RNIF)

Responder

(RNIF adapter)

RNIF::Exception

Mismatch in contents ofpartner agreement

AlertAlert AlertAlert

...


details.

The RosettaNet Transaction Trace indicates that a general exception signal was sent from theresponder to the initiator, and that a corresponding alert was raised.

September 2008 32


38/47


39/47




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 thesender communication channel:

Process name

Transaction name

Requesting action

Code

Version

Current role

Partner role

September 2008 34


40/47


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 failson the partner side.

RNIF::Request

Initiator

(RNIF)

Responder

(RNIF adapter)

RNIF::Exception

Signature

verification fails

AlertAlert AlertAlert

...

1. Launch the RWB, and go to Message Monitoring for the non-central Adapter Engine.

Select the action message, and choose Details.

TheAudit Log indicates that the signature verification failed because the action message wassigned 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 theinitiator, and that a corresponding alert was raised.

September 2008 35


41/47


3. The general exception contains details about the reason for failure.

4. In RWB, start yourAlert Inbox.An alert was raised by the sender of the general exception, that is, the RNIF adapter of the non-central Adapter Engine.

September 2008 36


42/47




September 2008 37


43/47


September 2008 38

4.10Bad Day Scenario 5: Time to Perform Fails (Two-

Action PIP)

The initiator sends an action message to the trading partner who fails to return a confirmation in time.

XI::Request

RNIF::Request

XI ISInitiator

(RNIF Adapter)

Responder

(RNIF)

AlertAlert

RNIF::ReceiptAck

XI::Ack No delivery of

Confirm Message

...


In the receiver communication channel, under Message Exchange Controls, maintain thefollowing parameters:

Number of Retries

Time to Acknowledge Receipt

Time to Perform: Indicates the time by which the response message in a two-

action PIP must be returned.

In this example, for test purposes the partner that received the action message has to send aconfirmation within 5 minutes. Otherwise, the BTD fails.


44/47



details.

The RosettaNet Transaction Trace indicates that the time to perform expired while waiting for aresponse action message, and that a corresponding alert was raised.

September 2008 39


45/47


4.11Bad Day Scenario 6: XML Validation Fails (Single-

Action 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

Initiator

(RNIF)

Responder

(RNIF adapter)

RNIF::Exception

Payload does not

comply with schema

AlertAlert AlertAlert ...

1. In the Integration Builder (Configuration), maintain the sender agreement.

Set the Schema Validation toValidation 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 tabAdapter Details.

The RosettaNet Transaction Trace indicates that a general exception signal was sent to theinitiator.

September 2008 40


46/47


3. Select the general exception message, and choose Details.

TheAudit Log indicates that the XML validation failed.


An alert was raised indicating that an XML validation error occured.

September 2008 41


47/47

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

Documents

How to Monitor Industry-Speak Scenarios