GM Interface Monitoring and Error Handling (Early Draft)

7/22/2019 GM Interface Monitoring and Error Handling (Early Draft)

1/34

GM Interface Monitoring and Error Handling

Version 1.0


2/34

Table Contents

1 Monitoring........................................................................................................................4

1.1 Interface Monitoring in PI........................................................................................41.1.1 Monitoring at Adapter Engine in PI...................................................................51.1.2 Monitoring at Integration Engine in PI..............................................................6

1.1.3 Other areas to monitor in PI...............................................................................7

ICM Monitoring ............................................................................................................7

Proxy Monitoring...........................................................................................................7Gateway Monitoring......................................................................................................7

Outgoing tRFC (Transactional RFC) Calls Monitoring............................................7

Queue Monitoring..........................................................................................................7Simple Performance Monitoring....................................................................................7

Packaging Monitoring with XMSPKSTATMON.........................................................7

1.2 Monitoring in ECC...................................................................................................8Proxy Monitoring...........................................................................................................8

Outgoing tRFC (Transactional RFC) Calls Monitoring............................................8

qRFC (Queued RFC) Monitoring..................................................................................8

ICM Monitoring ............................................................................................................8Gateway Monitoring......................................................................................................9

Packaging Monitoring with XMSPKSTATMON.........................................................9

1.3 PI Monitoring with CCMS........................................................................................91.4 Interface Monitoring with CCMS...........................................................................14

1.4.1 ALE/IDOC Monitoring....................................................................................15

1.4.2 tRFC (Transactional RFC) and qRFC (Queued RFC).....................................181.5 Interface Monitoring with Solution Manager 7.0...................................................21

1.5.1 Central CCMS Monitoring in SAP Solution Manager....................................21

1.5.2 Interface Monitoring with BPM.......................................................................222 Error Handling................................................................................................................23

2.1 File to Proxy (Inbound)...........................................................................................23

2.2 File to IDOC (Inbound)..........................................................................................24

2.3 File to File (Inbound)..............................................................................................252.4 SOAP to Proxy........................................................................................................26

2.5 SOAP to BAPI/RFC...............................................................................................27

2.6 Outbound Interfaces................................................................................................282.7 Error Resolution Process.........................................................................................28

2.8 Reprocessing of Errors............................................................................................30

2.8.1 IDOC................................................................................................................302.8.2 Proxy................................................................................................................31

3.6.1 Usage of Alerting.............................................................................................31

3.6.2 Usage of Acknowledgment Messages.............................................................32

Error Handling and Monitoring...................................................................................33

GM PI Design and Development Guideline Page 1 of 35 02/04/2011Version .1.0 GM Confidential


3/34



4/34

Document Control

Author(s) KJ Min

Team

Comments

Version RevisionDate

Author Revision Description

1.0 3/15/2011 KJ Min Integration Pattern draft

1.1 3/17/2011 KJ Min Design Process draft

1.2 3/20/2011 KJ Min Monitoring draft1.3 3/22/2011 KJ Min Monitoring revision

1.4 3/23/2011 KJ Min Error Handling draft

1.5 3/24/2011 KJ Min Error Handling revision

Approval by Role ApprovalDate

Approval Signature



5/34

1 MonitoringThe purpose of this section is to

address specifically the monitoring of the interfaces in PI, in the backend systemsand in the Solution Manager.

covers the different components that are important to interface operation and how

these components can be monitored

covers the Alert Monitors that are available from SAP to monitor the interfaces

and what statistics are collected through these Alert Monitors in CCMS andSolution Manager

provides the interface monitoring capability using Solution Manager

In order to do that, the section is broken down into the following sub-sections:

1. Interface Monitoring in PI provides the capability and tools to monitor variouscomponents in SAP PI

2. Monitoring in the backend systems provides the capability and tools to

monitor various components in the backend systems (ECC, SRM, CRM, )

3. PI Monitoring with CCMS provides the CCMS Alert Monitors that areavailable to monitor the operation of PI

4. Interface Monitoring with CCMS in the backend provides the monitoring

capabilities on the interfaces using CCMS Alert Monitors5. Central CCMS Monitoring in Solution Manager Central Monitoring of

CCMS related to the interfaces in Solution Manager

6. Interface Monitoring with BPM (Business Process Monitoring) in Solution

Manager provides specific information on the interface monitoring usingBusiness Process Engine in Solution Manager

1.1 Interface Monitoring in PI

SAP PI consists of the following functional components: Integration Builder, Integration

Repository, Integration Directory, Integration Server, Integration Engine, Business

Process Engine, Adapter Engine, Runtime Workbench (RWB) and System Landscape

Directory (SLD).



6/34

Within PI, a message is transferred and persisted through a number of areas, each withmonitoring tools. A message moving through PI will / can go through the following areas

in sequence:

Adapter Engine:A runtime component for resource adapters for integrating applications

and systems. The Adapter Engine contains the Adapter Framework, which includesfunctions for messaging, queuing, security, and connectivity to the Integration Server.You can use this framework to connect your own resource adapters or those of partners.

Integration Engine: Integration Engine enables you to process XML messagesexchanged between applications. The Integration Engine, as a runtime componentof SAP Exchange Infrastructure, has the task of receiving, processing, and

forwarding XML messages. During message processing, collaboration

agreements are evaluated, the receivers are determined, and mapping activities areexecuted. Integration Engine is responsible for the mapping / transformation of

the message contents from source to target format and routing the message to the

target system.

1.1.1 Monitoring at Adapter Engine in PI

The adapter engine status is monitored to ensure the messages are transferred to theirrespective interfaces properly in the Runtime Workbench (Message Monitoring ->

Adapter Engine)

Monitoring in the Adapter Engine is comprised of two areas: Adapter and Adapter

Messages. It is within the Adapter Engine that messages are initially received by PI orultimately sent from PI to target systems.



7/34

Adapter Monitor

The adapter status is monitored to ensure the adapters are connecting to their respective

systems properly to allow the pulling / pushing of messages to and from the respective

systems with the Runtime Workbench (Component Monitoring -> Adapter Engine ->Adapter Monitoring)

Adapter Messages

Every message that runs into an error in the Adapter Framework and/or the Integration

Server Pipeline gets persisted. In this way it is possible to monitor errors and to restart

erroneous messages (asynchronous messages only). Both, the IS pipeline and the AdapterFramework, have retry mechanisms, but after the retries are done and the error still

persists, it becomes necessary to analyze the underlying problem

For messages initially received by an adapter (and prior to transfer to the Integration

Engine) or ready to be transferred to the adapter (after the Integration / Business Processengine) are monitored in the following manner.

Good morning (Message Overview) Page for Adapter Engine in the PI Integration

Builder (Java Stack) Runtime Workbench (Message Monitoring -> Adapter

Engine):

The message overview gives you an overview of message processing during a specific

time period. This time period begins with the receipt of the message.

1.1.2 Monitoring at Integration Engine in PI

Once messages are passed on from the Adapter Engine they are ready for processing bythe Integration Engine for transformation. For Integration Engine monitoring there are

two approaches possible, showing similar information but with a different front end.

They are:

1. ABAP Stack Monitoring with SXI_MONITOR

2. Java Stack Monitoring with Runtime Workbench in the Integration Builder (Java

Stack) (Message Monitoring -> Integration Engine)

Integration Monitoring

The integration status is monitored to ensure the messages are transformed properly

within PI and processed completely and pushed by the Sending interface in the Runtime

Workbench

Message monitoring Integration Engine

The integration status is monitored to ensure the messages are transformed properly

within PI and processed completely and pushed by the Sending interface in the RuntimeWorkbench.



8/34

1.1.3 Other areas to monitor in PI

ICM Monitoring

ICM (Internet Connection Manager) is the Internet Communication Manager. It isresponsible for all incoming and outgoing HTTP calls and thus of high importance for theExchange Infrastructure. You can monitor ICM with transaction SMICM

Proxy Monitoring

All the messages exchanged using XI adapter (Proxy) is monitored with SXMB_MONI

transaction

Gateway Monitoring

PI mainly uses the gateway of the Web Application Server to communicate with the J2EE

Engine. At the gateway, several programs of the J2EE Engine are registered.

Outgoing tRFC (Transactional RFC) Calls Monitoring

All the messages going through Idoc Adapter in PI are monitored in transaction in SM58

in ABAP integration engine. You will find any errors related to outgoing tRFC calls inthis transaction

Queue Monitoring

Queues (qRFC inbound queues) are the core of the Integration Server. Within

queues all messages are processed, including the Logical Routing, the Technical

Routing, the Mapping and the call of the appropriate adapter. Queues are thus aneuralgic point for the XI: either if they are blocked or if they dont process fastenough. Log in to your Integration Server, call transaction SMQ2 and execute.

Outbound queues (qRFC outbound queses) are monitoring in transaction in

SMQ1 in Integration Server.

Simple Performance Monitoring

The health of an XI system can be monitored indirectly by watching the throughput of

your messages. Also, it tells you if your developers or application people have increased

the number of messages or added an interface without informing the basis group. Thiscan eventually lead to the necessity of adding additional hardware resources to ensure

that the KPIs (Key Performance Indicators) are still met.

Packaging Monitoringwith XMSPKSTATMON

To monitor packages, you use transaction XMSPKSTATMON. It allows you to filter thestart and end times, all the queues, a pattern search or any specific queue and the

aggregation interval.



9/34

Monitoring with the CCMS Alert Monitor

For Monitoring with the CCMS, please refer to the section XXXX.

1.2 Monitoring in ECC

Within SAP ECC, the majority of interfaces are triggered via Proxy, IDocs and

BAPI/RFC. IDocs by nature are persisted to the database in SAP for review, modification

and resubmission. These can be centrally monitored as described later.

SAP IDOC Monitoring

All the interfaces using IDOC adapter will be processed in WE02 transaction in thebackend system. You can monitor the status of all the IDOC based interfaces using

transaction WE02.

Proxy Monitoring


transaction

Outgoing tRFC (Transactional RFC) Calls Monitoring

All the messages going through Idoc Adapter in PI are monitored in transaction in SM58

in ABAP integration engine. You will find any errors related to outgoing tRFC calls in

this transaction

qRFC (Queued RFC) Monitoring

Queues (qRFC inbound queues) are the core of the Integration Server. Within

queues all messages are processed, including the Logical Routing, the TechnicalRouting, the Mapping and the call of the appropriate adapter. Queues are thus a

neuralgic point for the XI: either if they are blocked or if they dont process fast

enough. Log in to your Integration Server, call transaction SMQ2 and execute.

Outbound queues (qRFC outbound queses) are monitoring in transaction in

SMQ1 in Integration Server.

ICM Monitoring

ICM (Internet Connection Manager) is the Internet Communication Manager. It is

responsible for all incoming and outgoing HTTP calls and thus of high importance for theExchange Infrastructure. You can monitor ICM with transaction SMICM



10/34

Gateway Monitoring

PI mainly uses the gateway of the Web Application Server to communicate with the J2EE

Engine. At the gateway, several programs of the J2EE Engine are registered.

Packaging Monitoringwith XMSPKSTATMON

To monitor packages, you use transaction XMSPKSTATMON. It allows you to filter the

start and end times, all the queues, a pattern search or any specific queue and theaggregation interval.

Monitoring with AlertMonitor (CCMS)

1.3 PI Monitoring with CCMSThe SAP Computing Center Management System (CCMS) provides a special alert

monitor for SAP Exchange Infrastructure.

You use this alert monitor to monitor the ABAP and Java components (including theBusiness Process Engine) of your Exchange Infrastructure centrally, and to identify

different categories of system errors and application errors in the various interfaces and

interface namespaces of the components involved.

Besides the information on the monitored components, the alert monitor also providesinformation on the qRFC queues relevant for SAP Exchange Infrastructure. These

guarantee that XML messages are processed exactly once and, if necessary,

chronologically in Exchange Infrastructure.

The CCMS Alert Monitor has the following advantages:

Automated, central monitoring that does not require any administration tasks,

except where alerts occur.

Proactive monitoring by means of alerts that are triggered as soon as a particular

threshold value is not reached, or is exceeded

Support for problem solving through predefined analysis functions, which you

can use to remove the cause of an alert in a particular component.

CCMS Alert Monitoring is not part of SAP Exchange Infrastructure but a part of the SAP

NetWeaver Application Server.

IYou can call the CCMS Alert Monitor for Exchange Infrastructure by calling transaction

CCMS Monitoring (RZ20). In this monitor, expand the node SAP CCMS MonitorTemplates and select the template Exchange Infrastructure.



11/34

The Runtime Workbench also gives you the option of navigating directly to the CCMSAlert Monitor for the Exchange Infrastructure. To do this, go to Component Monitoring

and choose CCMS.

Alerts are a central element of monitoring. They report malfunctions quickly and reliably,

for example, when a particular threshold value is exceeded or not reached, or acomponent is inactive for a specific length of time. The alerts are assigned different

colors to make them easier to read (yellow for a warning and red for a problem) as well

as a numeric value indicating the severity of the malfunction. There are two views for

displaying the data:

In the Current status view, you can see the tree structure of your monitor and

monitor the current values of your monitoring attributes. If you want to analyze an

alert, double-click the relevant monitoring tree element. The Open alerts view enables you to check what has happened in the system

since the last check. In this view, you can check whether yellow or red alerts

(warnings or problems) have occurred. To navigate to the Alert Browser from this

http://help.sap.com/saphelp_nw70/helpdata/en/7a/1268c12feb5146a4430552bf478f30/content.htmhttp://help.sap.com/saphelp_nw70/helpdata/en/25/9c2f3ffed33d67e10000000a114084/content.htmhttp://help.sap.com/saphelp_nw70/helpdata/en/25/9c2f3ffed33d67e10000000a114084/content.htmhttp://help.sap.com/saphelp_nw70/helpdata/en/7a/1268c12feb5146a4430552bf478f30/content.htm


12/34

view, double-click an alert. This browser displays all alerts that have not yet beenanalyzed in a flat hierarchy.

The Current status view explains the functions of the alert monitorExchangeInfrastructure for the following components:

ABAP components

qRFC queues

http://help.sap.com/saphelp_nw70/helpdata/en/06/16493f9dfe0804e10000000a114084/content.htmhttp://help.sap.com/saphelp_nw70/helpdata/en/f7/2c4b3f53275003e10000000a114084/content.htmhttp://help.sap.com/saphelp_nw70/helpdata/en/06/16493f9dfe0804e10000000a114084/content.htmhttp://help.sap.com/saphelp_nw70/helpdata/en/f7/2c4b3f53275003e10000000a114084/content.htm


13/34

Java components

http://help.sap.com/saphelp_nw70/helpdata/en/7a/2d4b3f53275003e10000000a114084/content.htmhttp://help.sap.com/saphelp_nw70/helpdata/en/7a/2d4b3f53275003e10000000a114084/content.htm


14/34

Business Process Engine

http://help.sap.com/saphelp_nw70/helpdata/en/77/74a340fa432b54e10000000a1550b0/content.htmhttp://help.sap.com/saphelp_nw70/helpdata/en/77/74a340fa432b54e10000000a1550b0/content.htm


15/34

In addition to this component view, you can also change the configuration so that you can

display the following information:

Open alerts from the alert categories defined for PI.

Adapter-specific processing errorsfor each Adapter Engine.

Current number of messages in processingfor each Adapter Engine

1.4 Interface Monitoring with CCMS

With the CCMS, you can monitor the certain type of interfaces, namely ALE/IDOC,

tRFC, qRFC and Proxy, based upon CCMS Alert Monitor provided by SAP. Thesemonitors collect the data based upon the predefined Methods and collects the statisticaldata. Based upon the configurable predefined threshold value, CCMS can trigger

different responses.

Email

SNMP trap (typically used by other monitoring software)

Text message (by using a third party text message service)

http://help.sap.com/saphelp_nw70/helpdata/en/44/35781dba154cc4e10000000a11466f/content.htmhttp://help.sap.com/saphelp_nw70/helpdata/en/7f/af52427aa00b5fe10000000a155106/content.htmhttp://help.sap.com/saphelp_nw70/helpdata/en/7f/af52427aa00b5fe10000000a155106/content.htmhttp://help.sap.com/saphelp_nw70/helpdata/en/45/e32b64f87c6f74e10000000a1553f6/content.htmhttp://help.sap.com/saphelp_nw70/helpdata/en/45/e32b64f87c6f74e10000000a1553f6/content.htmhttp://help.sap.com/saphelp_nw70/helpdata/en/44/35781dba154cc4e10000000a11466f/content.htmhttp://help.sap.com/saphelp_nw70/helpdata/en/7f/af52427aa00b5fe10000000a155106/content.htmhttp://help.sap.com/saphelp_nw70/helpdata/en/45/e32b64f87c6f74e10000000a1553f6/content.htm


16/34

The predefined monitors from SAP related to interfaces are:

ALE/IDOC Monitoring

o Open Change Pointers

o Outbound: IDoc generated

o Outbound: IDoc ready for dispatch

o Outbound: IDoc in external system

o Outbound: IDoc dispatched

o Outbound: Error in IDoc interface

o Outbound: Error in external system

o Outbound: IDoc with delete flag

o

Outbound: IDoc processing in target systemo tRFC Queue: remote calls waiting

o Inbound: IDoc generated

o Inbound: IDoc transferred to application

o Inbound: IDoc transferred to dialog

o Inbound: Application document posted

o Inbound: Error in IDoc interface

o Inbound: Error in application

o Inbound: IDoc with delete flag

Transactional RFC and Queued RFC

o ARFCSSTATE: Outbound tRFC Calls

o ARFCRSTATE: Inbound tRFC/qRFC Calls

o Outbound Queues

o Inbound Queues

o QIN Schedulers: Errors

o QOUT Schedulers: Errors

ABAP Proxy

o SXMBAppCount: Total Number of Waiting Messages

o SXMBAppWtime: Wait Time Threshold Value

1.4.1 ALE/IDOC Monitoring

With the CCMS ALE/IDOC Alert Monitor you can monitor several R/3 Systems in an

ALE integrated system.



17/34

The alert monitor gives you an overview of the following SAP System performanceattributes which are important for ALE:

In order to do that, you can define ALE/IDOC monitoring objects in the IMG(transaction SALE Set-Up System Monitoring Central Monitoring of all

Systems ALE Monitor Objects or alternatively, in transaction BDMO

For analysis purposes, ALE monitoring objects form a group of associated selectionoptions based on IDoc attributes.

Individual objects are assigned values based on the current system status and the

assignment of selection options from IDoc attributes.

You can check the current status and the open alerts of your SAP system in two ways.

1. In ALE Administration choose:MonitoringIDoc Display

Monitor in CCMS (BDMONIC3).

2. Alternatively, if you set up your Alert Monitor, in CCMS

Monitoring, if you have defined the appropriate Monitoring

Tree Element



18/34

You can identify the current status by the performance values and status messagesrecently forwarded to the alert monitor. Older alerts that are still open (not yet processed)

are not included in the color coding.

By double-clicking in Alert Monitor, for instance, Inbound: Error in application, you

can drill-down into the IDOC List screen (below) for detailed analysis.



19/34

The alert monitor passes the highest alert level in the monitoring tree to the highest node.For example, if the node with the name of your SAP System is green, this means that allthe components in the monitoring tree of this system have a green status. All is OK.

1.4.2 tRFC (Transactional RFC) and qRFC (Queued RFC)

Transactional RFC and Queued RFC are variants of the Remote Function Call that make

the data transfer between different systems more reliable and more secure.

Transactional RFC guarantees the following attributes:

The call is executed exactly once in the target system.

Calls that belong to a Logical Unit of Work (LUW) are either completely

executed, or not executed at all.

If the target system is not available when the call is made, the call remains in the local

wait queue. The calling dialog program can, however, proceed. If the target system does



20/34

not become active within a certain amount of time, the call is scheduled as a backgroundjob.

Although tRFC significantly improves the reliability of the data transfer, it also hasdisadvantages. This method does not ensure that the sequence of LUWs specified in theapplication is observed. However, there is a guarantee that all LUWs will be transferred

at some point.

qRFC with Outbound Queue

To offset this disadvantage, a serialization of tRFC is performed using wait queues. It is

called queued RFC (qRFC). With this serialization, an outbound queue for tRFC wascreated, which is therefore referred to as qRFC with outbound queue. The main features

of qRFC are as follows:

A LUW is only transferred if it has no predecessor (in reference to the sequence

defined in the applications) in the participating queues. After a qRFC transaction isexecuted, the system attempts to start the next qRFC transaction in the sequence from

the queue.

A queue name and a queue counter are required fore each qRFC transaction for

queue administration. Each tRFC call that is to be processed chronologically isassigned a queue name determined by the application.

qRFC with Inbound Queue

Serialization of the incoming RFC calls from other systems is also possible. This ensuresthat incoming calls are always executed in the order of their arrival. This serialization ofincoming calls also limits the maximum load on the target server caused by RFC.

You can monitor these calls using the Alert Monitor.



21/34

Using the Transactional RFC and Queued RFCsubtree, you can quickly detect errors

and blocked queues (in the context of transactional RFC and queued RFCs). Thecorresponding special monitors with which you can quickly eliminate the cause of the

error are set as analysis methods. To do this, in the Communications monitor of the SAPCCMS Monitor Templates monitor set, there is a Transactional RFC and Queued RFC

subtree. These functions automatically become active at the start of the system; you can,

however, maintain and extend the functions. The subtree is in the Communicationsmonitor of the SAP CCMS Monitor Templates monitor set.

Monitored Objects in the Transaction RFC and Queued RFCSubtree

The number of outbound transactional RFC calls that could not be processed due

to errors is reported. These errors include data transfer errors (the target server is not

reached), execution errors in the target server, or resource errors (there are not enoughservers in the RFC server group). Alerts are generated if the number of calls with

errors exceeds the threshold value.



22/34

The number of inbound calls from transactional and queued RFCs that are

waiting for processing is reported. An alert is generated if the number of waiting calls

exceeds the threshold value.

Error messages for inbound and outbound qRFC queues are reported. An errormessage means that the affected queue cannot be processed and that all other calls forthe queue must wait until the error is corrected. The following applies here:

By default, a red alert is generated for every queue error. Only one alert is generatedfor an error, irrespective of how often the error is reported in the monitoringarchitecture. This means that you do not need to react to multiple notifications of thesame problem. If you delete or complete an alert, a new alert can be generated if aqueue error occurs.

The errors are grouped by client; all clients are monitored for queue errors.

Transfer and execution errors for inbound and outbound RFC schedulers are

reported. The monitoring tree for inbound schedulers also reports about queues thatare not registered for processing. Calls to these inbound queues are not executed until

the queues are registered.

1.5 Interface Monitoring with Solution Manager 7.0

1.5.1 Central CCMS Monitoring in SAP Solution Manager

Business process monitoring (including interface monitoring) in SAP Solution Manager

uses the Computing Center Management System (CCMS) (transaction RZ20)

architecture. This means that alerts that occur in the local CCMS are passed to SAP

Solution Manager via RFC connections between SAP Solution Manager and the relevantmanaged systems. The system shows these alerts in a graphic or in the individual

sessions. You can also handle the alerts centrally, without having to switch to the local

CCMS of the managed systems.

In contrast to the local CCMS of each managed system of SAP Solution Manager, youcan identify the alerts from multiple systems of a solution landscape in a graphical

overview in SAP Solution Manager. This is the view of a central CCMS (CEN). You can

also monitor non-SAP systems in a central CCMS (CEN) of a managed system.

The graphical display in SAP Solution Manager helps you easily access the individual

alerts of all systems in a solution. You can go to the local or central CCMS of themanaged systems at any time.

The system proposes the most important alerts in the CCMS monitor collection,according to SAP experience, and their alert thresholds, for each system in the solution,

in the system monitoring Session. You can activate or deactivate these alerts. The

connection between the local CCMS and SAP Solution Manager allows you to maintain



23/34

the alert thresholds directly in SAP Solution Manager, overwriting the values in the localCCMS.

This means that all the CCMS monitors related to the interfaces mentioned above, in theInterface Monitoring with the CCMS section can be all monitored CENTRALLY inSolution Manager

1.5.2 Interface Monitoring with BPM

In addition to the Central CCMS monitoring in Solution manager, with the Business

Process MONITORING session in SAP Solution Manager, you can activate thecustomizing for each business process in your solution. A monitoring tree element (MTE)

or a monitor collection (BPM of multiple monitoring objects) is created in the local orcentral (CEN) CCMS of the relevant managed system.

The data is collected for the monitoring types of business process monitoring in contrastto system monitoring, as follows:

Once you have created a solution and created interfaces between your business processes

in the Solution Directory, you can set up monitoring of interfaces, the following interface

technologies are supported as of Solution Manager 7.0

ALE/IDOC/EDI

qRFC

1.5.2.1 Interfaces using ALE/IDOC

You can set up interface monitor objects for the interfaces using ALE/IDOC in basedupon the message type in transaction BDMO,ALE/CCMS Monitoring Objects

(transaction: BDMO)

The monitor objects for outgoing (from the sender system) and incoming (to the recipient system)interfaces are created in the same way first in the managed system and then accessed by theCentral Monitoring in Solution Manager.

The monitor object name is valid for both the incoming and outgoing interfaces, if both sides are

to be monitored.

By default the job SAP_CCMS_MONI_BATCH_DP is restarted by the system automatically every15 minutes to gather the statistics and you can check whether the system has created themonitor object in the CCMS Monitoring Sets (transaction: RZ20) view.



24/34

1.5.2.2 qRFC interface

You can create the monitor object in the managed system with transaction RZ21,

Monitoring: Attributes and Methods in your managed system by going into

choose Techn. Infrastructure -> Configure QRFC Monitoring.

You can create a QRFC monitor with the following attributes to be monitored by CCMS andSolution Manager based upon the queue name

SMQ1: Outgoing interface

SMQ2: Incoming interface

2 Error Handling

Interface error can take place at each of the following stage.

Inbound to SAPStep 1. In the source system (usually Legacy) while generating the

interface data

Step 2. During transmission from source system to PIStep 3. During message processing in the PI

Step 4. During message transmission from PI to the backend SAP

systemStep 5. In the backend SAP system while posting the data generated

from the legacy system

Outbound from SAP

Step 1. In the backend SAP system while generating the interface data

that will be transmitted to the target system (usually Legacy)

while generating the interface dataStep 2. During transmission from backend SAP system to PI

Step 3. During message processing in the PI

Step 4. During message transmission from PI to the target systemStep 5. In the target system while posting the data generated from the

backend SAP system

The detection of the error depends upon the type of the message used and the system in

which error takes place. The resolution process of the error depends on the type of error,

the type of the message used and the system in which error takes place

2.1 File to Proxy (Inbound)



25/34

In File to Proxy scenario, the source system (mostly Legacy) generates a file for theinterface data and transmits the file to a common drop zone that will be picked up by PI

and processed using Proxy in the backend system.

Step 1. In the source system (usually Legacy) while generating the interface data

This step can be monitored with the tools and the processes available in the sourcesystem. If the source system has a capability to trigger an alert in case of an error, this can

be used to detect the error.

In addition, PI File/FTP adapter can be used to check if the expected file exists in thedrop zone and an alert can be triggered in case the expected file doesnt exist which

indicates the error in the soruce system.

Step 2. During transmission from source system to PI and Step 3. During message

processing in the PI

This step will be monitored in the adapter message monitoring with the RuntimeWorkbench for the file adapter and the proxy adapter.

Every message that runs into an error in the Adapter Framework and/or the IntegrationServer Pipeline gets persisted. In this way it is possible to monitor errors and to restart

erroneous messages (asynchronous messages only). Both, the IS pipeline and the Adapter

Framework, have retry mechanisms, but after the retries are done and the error still

persists, it becomes necessary to analyze the underlying problem

Step 4. During message transmission from PI to the backend SAP system


transaction. Since the message is outbound from PI to the backend system, you need to

monitor the outbound queue.

Step 5. In the backend SAP system while posting the data generated from the legacy

system


transaction. Since the message is inbound from PI to the backend system, you need to

monitor the inbound queue.

2.2 File to IDOC (Inbound)

In File to IDOC scenario, the source system (mostly Legacy) generates a file for the

interface data and transmits the file to a common drop zone that will be picked up by PIand processed using IDOC in the backend system.



26/34








This step will be monitored in the adapter message monitoring with the Runtime

Workbench for the file adapter and the IDOC adapter.



Framework, have retry mechanisms, but after the retries are done and the error stillpersists, it becomes necessary to analyze the underlying problem


All the messages exchanged using IDOC is monitored with WE02 transaction. Since the

message is outbound from PI to the backend system, you need to monitor the outboundqueue only.


system

All the messages exchanged using IDOC is monitored with WE02 transaction. Since the

message is inbound from PI to the backend system, you need to monitor the inboundqueue.

2.3 File to File (Inbound)

In File to File scenario, the source system (mostly Legacy) generates a file for the

interface data and transmits the file to a common drop zone that will be picked up by PI

and passed on to the backend system for processing. A background job is scheduled in

the backend system to pick up this file and to call an appropriate program to process thisfile



27/34









Workbench for the file adapter..





The file adapter in PI will be used to monitor the transmission of this file and can trigger

an alert if the transmission fails due to the network error or system error when the filesystem is full or cannot be found.


system

The result of the background job will be monitored using the SM37 and the solution like

TWS can be used to trigger an alert when the background job files. You can also definevarious actions using TWS such as re-run the job automatically in case of a failure and

send an email alert.

2.4 SOAP to Proxy

In SOAP to Proxy scenario, the source system (mostly Legacy) sends a SOAP message

for the interface data to PI and XI adapter will convert the SOAP message and send a

proxy message to be processed in the backend system.




28/34

This step can be monitored with the tools and the processes available in the source

system while generating and transmitting a SOAP to PI . If the source system has a

capability to trigger an alert in case of an error, this can be used to detect the error.




Workbench for the SOAP adapter and the XI adapter.

Every message that runs into an error in the Adapter Framework and/or the Integration

Server Pipeline gets persisted. In this way it is possible to monitor errors and to restart




All the messages exchanged using XI adapter (Proxy) is monitored with SXMB_MONItransaction. Since the message is outbound from PI to the backend system, you need to

monitor the outbound queue.

Step 5. In the backend SAP system while posting the data generated from the legacysystem

All the messages exchanged using XI adapter (Proxy) is monitored with SXMB_MONItransaction. Since the message is inbound from PI to the backend system, you need to

monitor the inbound queue.

2.5 SOAP to BAPI/RFC

In SOAP to BAPI/RFC scenario, the source system (mostly Legacy) sends a SOAP

message for the interface data to PI and XI adapter will convert the SOAP message and

send a proxy message to be processed in the backend system.


This step can be monitored with the tools and the processes available in the source

system while generating and transmitting a SOAP to PI . If the source system has a

capability to trigger an alert in case of an error, this can be used to detect the error.



29/34

Step 2. During transmission from source system to PI and Step 3. During messageprocessing in the PI

This step will be monitored in the adapter message monitoring with the RuntimeWorkbench for the SOAP adapter and the RFC adapter.





All the messages exchanged using RFC/BAPI is further monitored with transactionSM58 and SMQ1 depending upon the type of RFC used, namely, tRFC and qRFC

respectively. Since the message is outbound from PI to the backend system, you need tomonitor the outbound queue for SM58

Step 5. In the backend SAP system while posting the data generated from the legacysystem

All the messages exchanged using RFC is monitored with transaction SM58 and SMQ2

depending upon the type of RFC used, namely, tRFC and qRFC respectively. Since themessage is outbound from PI to the backend system, you need to monitor the inbound

queue for SM58

2.6 Outbound Interfaces

For the outbound interfaces, the same process takes place with the type of adapter beingused, but in a reverse order. All the steps are monitored with the same transaction and

same alert mechanisms are triggered.

2.7 Error Resolution Process

Once an error is detected for an interface, the details will be found in an appropriatetransaction depending upon the message type and the system as summarized earlier.

The details of these errors are found

i. For IDOC, WE02

ii. For Proxy, SXMB_MONIiii. For RFC, SM58, SMQ2

iv. For File, SM37



30/34

The following decision tree will be used for resolution process.

If the root cause is in the target system, the defect in the target system should be corrected

and the existing message can be reprocessed.

If the root cause is in the souce system, the defect in the source system should be

corrected and the new message needs to be generated and then subsequently processed. Inthis case, the old message cannot be used and needs to be deleted or archived.

If the root cause happends during the transmission due to the system error, for instance,adapter, integration engine, or system outage, the same message can be used for

processing once the error is corrected.

Error Resoultion Process in the backend systems (SAP ECC, SAP SRM, SAP CRM, SAPSCM)


TransactionIDOC -WE02 /Proxy- SXMB_MONI

Data Errors

Source Data Issue

Configuration or

Design Issue

Correct Source Data and

then resend the message from Source System

Correct Configuration or Design Issue and

then reprocess the message again in ECC

R: Source System

Master Data IssueCorrect Master Data and re-process the

Message again in ECC

Programming

Errors

Programming

exception raised

Correct programming correction and

reprocess the message

Technical

Errors

Exception raised

for Timeout /

Tables Space full

/ other

infrastructure error

Correct infrastructure error and re-process

the message

Authorization

Errors

Access Issue

while posting

the message

Correct the authorization error and

re-process the message

TransactionSM58

SMQ1 / SMQ2

Queue IssueInfrastructure/

Basis ErrorCorrect the infrastructure issue and re-process

the message again

Error in

Summary Report

Missing Data

Background Job

Monitoring(TWS / SM37)

Batch job

failed

Evaluate the

reasonSend an alert or route to the correct user

for issue resolution

Batch Job

R: Sustain Team

R: Business User

R: Sustain Team

R: Sustain Team

R: Sustain Team

R: Sustain Team

R: Sustain Team


31/34

Error Resolution Process in the SAP PI during transmission

2.8 Reprocessing of Errors

Once the error is corrected, the following process will be used to re-process the message.

2.8.1 IDOC

For IDOC, use WE02 Transaction

For IDOC ReprocessingA) Manual Transactions

Step 1- Go to Transaction BD87.


1) RWB / NWA Integration Server

OR2) TransactionSXMB_MONI

Data ValidationErrors

Source Data Issue

Routing or ValueMapping Issue

Correct Source Data andthen resend the message from Source System

Correct Routing or Value Mapping data andthen reprocess the message again in PI

cc. Route the issue to functional team

R: Source System

ConfigurationErrors

Issue in Receiver Determ.Interface Determ.

Call Adapter

Correct the PI Configuration and reprocess themessage in SAP PI

ProgrammingErrors

Mappingexception raised

Correct mapping /programming and reprocessthe message

TechnicalErrors

Exception raisedfor Timeout /

Tables Space full/ other / Receiver

System down/infrastructure error

Correct the issue and re-process the message

Authorization

/Service Errors

Service userslocked /

Authorizationchanged

Correct the issue and re-process the message

Error in Summary

Report

RWB /NWAMonitoring for

- Component- Cache- Performance

Issue in PIComponents /

Cache /

Performance

Infrastructure/Basis Error

Correct the cache or other infrastructure issue andreprocess the message

Others

1) RWB NWA

Monitor Adapter

Authorization

Error /Access Issue

Check theCommunication

channel andsufficient accessto read/write in

receiver system

Resolve communication failure and reprocess themessage from RWB in Adapter monitoring

Missing Data -Adapter

TransactionSM58

SMQ1 / SMQ2

Queue IssueInfrastructure/

Basis ErrorCorrect the infrastructure /basis issue

Missing Data

R: Business User

R: Sustain team

R: Sustain Team

R: Sustain Team

R: Sustain Team

R: Sustain Team

R: Sustain Team

R: Sustain Team


32/34

Step 2 - Enter IDOC Number and/or Message Type and/or time interval for whichyou want to look the IDOC to re-process

Step 3 - Select Inbound / Outbound Processing Message type Select IDOC

which has the Error Click on Process button (inbound) or Execute LUW F6(outbound). The subsequent screen will give the status of the IDOC and whetherit processed successfully or not. If there is continued error, it will provide the

reason and correct the configuration/master data and then reprocess again.

B) Reports (Batch/Manual)RBDAGAIN Process outbound IDOCs with Errors

RBDAGAIE Reprocessing of edited IDOCs

RBDAGAI2 - Reprocessing of IDOCs after ALE Input Error

For IDOC Editing

IDOCs can be changed manually but this should not be done in production

environmentTransaction WE02 Double click on page icon for selected segment Data

Record Change Save

Then reprocess the IDOC in transaction BD87

2.8.2 Proxy

For Proxy message, use SXMB_MONI Transaction

For Proxy Message Reprocessing,

A) Manual TransactionsStep 1- Go to Transaction SXMB_MONI.

Step 2 - Enter Message Interface Name and/or time interval for which you want to

look the Proxy message to re-processStep 3 - Select messages with error and then click on Restart Button. The

subsequent screen will give the status of the proxy and whether it

processed successfully or not. If there is continued error, it will provide the

reason and correct the configuration/master data and then reprocess again.

B) Reports (Batch/Manual)RSXMB_RESTART_MESSAGES - Restart Messages with Errors

3.6.1 Usage of Alerting

The Alert Framework available within SAP NetWeaver is used in PI to allow the creationof alert messages for errors during message processing. This can be used to alert a

support group on errors that need to be fixed.



33/34

In general two types of alert categories can be configured:

Static Alerts- These alert categories are used to catch alerts created by the PI Integration

and Adapter Engines. They contain corresponding container variables, which storeinformation about the affected sender and receiver system and interface.

Dynamic Alerts- Alert categories with dynamic text are directly invoked by ccBPM. Thealert text is directly defined by the ccBPM logic and should always contain the

Integration Scenario ID and further meaningful information on the failed message.

Alerts can be addressed to different people depending on the definition of the alert

category. Because the usage of fixed recipients as well as roles for receivers introduces

the risk that people will accidentally receive alerts they are not interested in, the usage of

both is discouraged.

Instead subscription authorizations should be used, allowing people with the according

authorizations to subscribe to alerts they are interested in.

If a user has subscribed to an alert category and a message generates an error, an alert

will be created and the user will receive the alert in his alert inbox and if configured alsoas email, pager message or facsimile. The additional communication method can be

personalized by each individual user, taking factory calendars and time dependent

delivery as well as the definition of substitutes into account.

Each Integration Scenario should make use of the alerting functionality within PI and

have at least one alert category configured.

3.6.2 Usage of Acknowledgment Messages

Acknowledgment messages (ACK) inform the sender of an asynchronous message about

the result of the processing of the message. There are two types of ACKs depending on

the requested information by the sender:

2.8.2.1.1.1.1.1.1 (A) System/ Transport AcknowledgmentGives information about the arrival of the request message at the finalreceiver

2.8.2.1.1.1.1.1.2 (B) Application AcknowledgmentGives information about the execution of the application in the receiversystem

There are two possible statuses an ACK can have: a positive status for success and a

negative status for failure of processing. Furthermore an ACK can be of category typepermanent or transient.



34/34

Transient ACKs are normally used for negative ACKs that have been generated due to

errors that can be resolved so that a successful message processing can still be reached.

Permanent ACKs are normally generated for final message states, either when messagesare cancelled manually due to errors, or if messages have been processed successfully.

Although ACKs are a good way to inform the sender about the status of the message inthe receiver system, they should only be used if really necessary as ACK processing will

have an impact on the performance of the overall integration scenario. In general ACKs

will add an overhead of about 20% to any scenario.

Error Handling and Monitoring

3.1

GM Interface Monitoring and Error Handling (Early Draft)

Documents

Transcript of GM Interface Monitoring and Error Handling (Early Draft)