GM Interface Monitoring and Error Handling

Version 1.0

Table Contents
1 Monitoring........................................................................................................................4 1.1 Interface Monitoring in PI........................................................................................4 1.1.1 Monitoring at Adapter Engine in PI...................................................................5 1.1.2 Monitoring at Integration Engine in PI..............................................................6 1.1.3 Other areas to monitor in PI...............................................................................7 ICM Monitoring ............................................................................................................7 Proxy Monitoring...........................................................................................................7 Gateway Monitoring......................................................................................................7 Outgoing tRFC (Transactional RFC) Calls Monitoring............................................7 Queue Monitoring..........................................................................................................7 Simple Performance Monitoring....................................................................................7 Packaging Monitoring with XMSPKSTATMON.........................................................7 1.2 Monitoring in ECC...................................................................................................8 Proxy Monitoring...........................................................................................................8 Outgoing tRFC (Transactional RFC) Calls Monitoring............................................8 qRFC (Queued RFC) Monitoring..................................................................................8 ICM Monitoring ............................................................................................................8 Gateway Monitoring......................................................................................................9 Packaging Monitoring with XMSPKSTATMON.........................................................9 1.3 PI Monitoring with CCMS........................................................................................9 1.4 Interface Monitoring with CCMS...........................................................................14 1.4.1 ALE/IDOC Monitoring....................................................................................15 1.4.2 tRFC (Transactional RFC) and qRFC (Queued RFC).....................................18 1.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.......................................................................22 2 Error Handling................................................................................................................23 2.1 File to Proxy (Inbound)...........................................................................................23 2.2 File to IDOC (Inbound)..........................................................................................24 2.3 File to File (Inbound)..............................................................................................25 2.4 SOAP to Proxy........................................................................................................26 2.5 SOAP to BAPI/RFC...............................................................................................27 2.6 Outbound Interfaces................................................................................................28 2.7 Error Resolution Process.........................................................................................28 2.8 Reprocessing of Errors............................................................................................30 2.8.1 IDOC................................................................................................................30 2.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 Version .1.0 GM Confidential

02/04/2011

GM PI Design and Development Guideline Page 2 of 35 Version .1.0 GM Confidential

02/04/2011

Document Control
Author(s) Team Comments KJ Min

Version 1.0 1.1 1.2 1.3 1.4 1.5

Revision Date 3/15/2011 3/17/2011 3/20/2011 3/22/2011 3/23/2011 3/24/2011

Author KJ Min KJ Min KJ Min KJ Min KJ Min KJ Min

Revision Description Integration Pattern draft Design Process draft Monitoring draft Monitoring revision Error Handling draft Error Handling revision

Approval by

Role

Approval Date

Approval Signature

GM PI Design and Development Guideline Page 3 of 35 Version .1.0 GM Confidential

02/04/2011

1 Monitoring
The purpose of this section is to address specifically the monitoring of the interfaces in PI, in the backend systems and 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 and Solution 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 various components 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 are available to monitor the operation of PI 4. Interface Monitoring with CCMS in the backend provides the monitoring capabilities on the interfaces using CCMS Alert Monitors 5. 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 using Business 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).

GM PI Design and Development Guideline Page 4 of 35 Version .1.0 GM Confidential

02/04/2011

Within PI, a message is transferred and persisted through a number of areas, each with monitoring 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 includes functions 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 messages exchanged between applications. The Integration Engine, as a runtime component of 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 are executed. 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 their respective 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 or ultimately sent from PI to target systems.
GM PI Design and Development Guideline Page 5 of 35 Version .1.0 GM Confidential 02/04/2011

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 Adapter Framework, 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 Process engine) 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 by the 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 Runtime Workbench.
GM PI Design and Development Guideline Page 6 of 35 Version .1.0 GM Confidential 02/04/2011

1.1.3 Other areas to monitor in PI

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 the Exchange 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 in this 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 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.
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. This can eventually lead to the necessity of adding additional hardware resources to ensure that the KPIs (Key Performance Indicators) are still met.
Packaging Monitoring with 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 the aggregation interval.
GM PI Design and Development Guideline Page 7 of 35 Version .1.0 GM Confidential 02/04/2011

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 the backend system. You can monitor the status of all the IDOC based interfaces using transaction WE02.
Proxy Monitoring

All the messages exchanged using XI adapter (Proxy) is monitored with SXMB_MONI 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 Technical Routing, 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 the Exchange Infrastructure. You can monitor ICM with transaction SMICM

GM PI Design and Development Guideline Page 8 of 35 Version .1.0 GM Confidential

02/04/2011

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 Monitoring with 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 the aggregation interval. Monitoring with AlertMonitor (CCMS)

1.3 PI Monitoring with CCMS

The 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 the Business 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 provides information 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 Monitor Templates and select the template Exchange Infrastructure.
GM PI Design and Development Guideline Page 9 of 35 Version .1.0 GM Confidential 02/04/2011

The Runtime Workbench also gives you the option of navigating directly to the CCMS Alert 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 a component 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
GM PI Design and Development Guideline Page 10 of 35 Version .1.0 GM Confidential 02/04/2011

view, double-click an alert. This browser displays all alerts that have not yet been analyzed in a flat hierarchy. The Current status view explains the functions of the alert monitor Exchange Infrastructure for the following components: ABAP components

qRFC queues

GM PI Design and Development Guideline Page 11 of 35 Version .1.0 GM Confidential

02/04/2011

 Java components

GM PI Design and Development Guideline Page 12 of 35 Version .1.0 GM Confidential

02/04/2011

 Business Process Engine

GM PI Design and Development Guideline Page 13 of 35 Version .1.0 GM Confidential

02/04/2011

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 errors for each Adapter Engine. Current number of messages in processing for 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. These monitors collect the data based upon the predefined Methods and collects the statistical data. 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)
GM PI Design and Development Guideline Page 14 of 35 Version .1.0 GM Confidential 02/04/2011

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 system o 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.
GM PI Design and Development Guideline Page 15 of 35 Version .1.0 GM Confidential 02/04/2011

The alert monitor gives you an overview of the following SAP System performance attributes 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 selection options 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: Monitoring IDoc 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

GM PI Design and Development Guideline Page 16 of 35 Version .1.0 GM Confidential

02/04/2011

You can identify the current status by the performance values and status messages recently 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.

GM PI Design and Development Guideline Page 17 of 35 Version .1.0 GM Confidential

02/04/2011

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 all the 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
GM PI Design and Development Guideline Page 18 of 35 Version .1.0 GM Confidential 02/04/2011

not become active within a certain amount of time, the call is scheduled as a background job. Although tRFC significantly improves the reliability of the data transfer, it also has disadvantages. This method does not ensure that the sequence of LUWs specified in the application 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 was created, 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 is executed, 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 is assigned a queue name determined by the application. qRFC with Inbound Queue Serialization of the incoming RFC calls from other systems is also possible. This ensures that incoming calls are always executed in the order of their arrival. This serialization of incoming calls also limits the maximum load on the target server caused by RFC. You can monitor these calls using the Alert Monitor.

GM PI Design and Development Guideline Page 19 of 35 Version .1.0 GM Confidential

02/04/2011

Using the Transactional RFC and Queued RFC subtree, you can quickly detect errors and blocked queues (in the context of transactional RFC and queued RFCs). The corresponding 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 SAP CCMS 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 Communications monitor of the SAP CCMS Monitor Templates monitor set.

Monitored Objects in the Transaction RFC and Queued RFC Subtree 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 enough servers in the RFC server group). Alerts are generated if the number of calls with errors exceeds the threshold value.

GM PI Design and Development Guideline Page 20 of 35 Version .1.0 GM Confidential

02/04/2011

 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 error message means that the affected queue cannot be processed and that all other calls for the 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 generated for an error, irrespective of how often the error is reported in the monitoring architecture. This means that you do not need to react to multiple notifications of the same problem. If you delete or complete an alert, a new alert can be generated if a queue 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 that are 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 relevant managed 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, you can 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 the managed 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
GM PI Design and Development Guideline Page 21 of 35 Version .1.0 GM Confidential 02/04/2011

the alert thresholds directly in SAP Solution Manager, overwriting the values in the local CCMS. This means that all the CCMS monitors related to the interfaces mentioned above, in the Interface Monitoring with the CCMS section can be all monitored CENTRALLY in Solution 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 the customizing 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 or central (CEN) CCMS of the relevant managed system. The data is collected for the monitoring types of business process monitoring in contrast to 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 based upon 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 the Central 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 every 15 minutes to gather the statistics and you can check whether the system has created the monitor object in the CCMS Monitoring Sets (transaction: RZ20) view.

GM PI Design and Development Guideline Page 22 of 35 Version .1.0 GM Confidential

02/04/2011

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 and Solution 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 SAP Step 1. In the source system (usually Legacy) while generating the interface data Step 2. During transmission from source system to PI Step 3. During message processing in the PI Step 4. During message transmission from PI to the backend SAP system Step 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 data Step 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 system Step 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)

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

In File to Proxy 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 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 source system. 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 the drop 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 Runtime Workbench for the file adapter and the proxy 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 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 All the messages exchanged using XI adapter (Proxy) is monitored with SXMB_MONI 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 All the messages exchanged using XI adapter (Proxy) is monitored with SXMB_MONI 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 PI and processed using IDOC in the backend system.
GM PI Design and Development Guideline Page 24 of 35 Version .1.0 GM Confidential 02/04/2011

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 source system. 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 the drop 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 Runtime Workbench for the file adapter and the IDOC 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 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 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 outbound queue only. Step 5. In the backend SAP system while posting the data generated from the legacy 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 inbound queue.

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 this file
GM PI Design and Development Guideline Page 25 of 35 Version .1.0 GM Confidential 02/04/2011

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 source system. 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 the drop 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 Runtime Workbench for the file 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 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 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 file system is full or cannot be found. Step 5. In the backend SAP system while posting the data generated from the legacy 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 define various 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. Step 1. In the source system (usually Legacy) while generating the interface data
GM PI Design and Development Guideline Page 26 of 35 Version .1.0 GM Confidential 02/04/2011

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. 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 Runtime 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 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 All the messages exchanged using XI adapter (Proxy) is monitored with SXMB_MONI 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 All the messages exchanged using XI adapter (Proxy) is monitored with SXMB_MONI transaction. 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. 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 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.

GM PI Design and Development Guideline Page 27 of 35 Version .1.0 GM Confidential

02/04/2011

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 Runtime Workbench for the SOAP adapter and the RFC 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 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 All the messages exchanged using RFC/BAPI is further monitored with transaction SM58 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 to monitor the outbound queue for SM58 Step 5. In the backend SAP system while posting the data generated from the legacy system 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 the message 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 being used, 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 appropriate transaction 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_MONI iii. For RFC, SM58, SMQ2 iv. For File, SM37
GM PI Design and Development Guideline Page 28 of 35 Version .1.0 GM Confidential 02/04/2011

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. In this 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, SAP SCM)
Error in Summary Report Transaction
IDOC - WE02 / Proxy- SXMB_MONI

Source Data Issue Data Errors Configuration or Design Issue Master Data 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 Correct Master Data and re-process the Message again in ECC

R: Source System

R: Sustain Team

R: Business User

Programming Errors Technical Errors

Programming exception raised Exception raised for Timeout / Tables Space full / other infrastructure error

Correct programming correction and reprocess the message

R: Sustain Team

Correct infrastructure error and re-process the message

R: Sustain Team

Authorization Errors Missing Data Transaction

SM58 SMQ1 / SMQ2

Access Issue while posting the message

Correct the authorization error and re-process the message

R: Sustain Team

Queue Issue

Infrastructure/ Basis Error

Correct the infrastructure issue and re-process the message again

R: Sustain Team

Batch Job Background Job Monitoring

(TWS / SM37)

Batch job failed

Evaluate the reason

Send an alert or route to the correct user for issue resolution

R: Sustain Team

GM PI Design and Development Guideline Page 29 of 35 Version .1.0 GM Confidential

02/04/2011

Error Resolution Process in the SAP PI during transmission

Error in Summary Report 1) RWB / NWA Integration Server OR 2) Transaction SXMB_MONI

Data Validation Errors

Source Data Issue Routing or Value Mapping Issue Issue in Receiver Determ. Interface Determ. Call Adapter Mapping exception raised Exception raised for Timeout / Tables Space full / other / Receiver System down/ infrastructure error Service users locked / Authorization changed Check the Communication channel and sufficient access to read/write in receiver system Infrastructure/ Basis Error

Correct Source Data and then resend the message from Source System Correct Routing or Value Mapping data and then reprocess the message again in PI cc. Route the issue to functional team Correct the PI Configuration and reprocess the message in SAP PI

R: Source System

R: Business User

Configuration Errors

R: Sustain team

Programming Errors

Correct mapping /programming and reprocess the message

R: Sustain Team

Technical Errors

Correct the issue and re-process the message

R: Sustain Team

Authorization /Service Errors Missing Data Adapter 1) RWB NWA Monitor Adapter Missing Data Transaction SM58 SMQ1 / SMQ2 Others RWB /NWA Monitoring for - Component - Cache - Performance Authorization Error / Access Issue

Correct the issue and re-process the message

R: Sustain Team

Resolve communication failure and reprocess the message from RWB in Adapter monitoring

R: Sustain Team

Queue Issue

Correct the infrastructure /basis issue

R: Sustain Team

Issue in PI Components / Cache / Performance

Infrastructure/ Basis Error

Correct the cache or other infrastructure issue and reprocess the message

R: Sustain Team

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 Reprocessing A) Manual Transactions Step 1- Go to Transaction BD87.
GM PI Design and Development Guideline Page 30 of 35 Version .1.0 GM Confidential 02/04/2011

Step 2 - Enter IDOC Number and/or Message Type and/or time interval for which you 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 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) 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 environment Transaction 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 Transactions Step 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-process Step 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 creation of alert messages for errors during message processing. This can be used to alert a support group on errors that need to be fixed.
GM PI Design and Development Guideline Page 31 of 35 Version .1.0 GM Confidential 02/04/2011

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 store information about the affected sender and receiver system and interface. Dynamic Alerts- Alert categories with dynamic text are directly invoked by ccBPM. The alert 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 also as 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 Acknowledgment (B) Application Acknowledgment

Gives information about the arrival of the request message at the final receiver

2.8.2.1.1.1.1.1.2

Gives information about the execution of the application in the receiver system

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 type permanent or transient.
GM PI Design and Development Guideline Page 32 of 35 Version .1.0 GM Confidential 02/04/2011

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 messages are 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 in the 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 PI Design and Development Guideline Page 33 of 35 Version .1.0 GM Confidential

02/04/2011