Monitor Tools in SAP PI

Monitoring Tools in SAP PI 17/02/2010

SAP Hi Tech Rajasekaran Sivalingam [email protected] & Karthi Sivaprakasam [email protected]

Monitoring Tools in SAP XI/PI

Contents 1. Introduction..............................................................................................................3 2. Integration Engine Monitoring...............................................................................4 3. SMQ2 –Inbound queue processing.........................................................................8 3.1 Synchronous RFC ..............................................................................................8 3.2 Transactional RFC (tRFC) ...............................................................................8 3.3 Queued RFC (qRFC) .........................................................................................8 4. IDoc Monitoring.....................................................................................................11 5. Runtime Work Bench (RWB)...............................................................................13 Features...................................................................................................................13 Message monitoring ...............................................................................................13 6. Summary.................................................................................................................19 7. References ...............................................................................................................19

Internal Use

2


1. Introduction XI connects various application systems in different platforms via XML messaging. XI uses SAP-specific implementation of the SOAP protocol. Message from one application system to other system flows through an integration server.

Fig: XI Message flow

The Integration Server comprises three engines: •

•

•

Business Process Engine: Integration server of SAP XI also contains BPE for supporting cross component Business process management (ccBPM) .This component takes care of the running and persistency of cross component Integration processes. Integration Engine: IE executes the integration logic of Integration Builder. Messages in XI are passed through a series of pipeline steps that belong to XI Pipeline as shown in the below screen. Adapter Engine : Adapter engine Converts XML and HTTP based messages to/from specific protocols as configured with Target/Source system.

Fig: Pipeline Steps

Internal Use

3


There are few possibilities in which the message can get stuck in any of the below components: • • •

Integration Engine Adapter Engine and Business process Engine

This document concentrates only on Integration and Adapter engine monitoring tools.

2. Integration Engine Monitoring T-code: SXMB_MONI SXMB_MONI is used for monitoring the XML message flow in the Integration Engine in ABAP stack. Its main use is for monitoring and correcting the XML message depending on the error message.

Fig:Tx SXMB_MONI

1. Double click ‘Monitor for Processed XML Messages’ and the following screen appears.

Internal Use

4


Fig: Selection Criteria for processing the XML message

XML Messages can be retrieved based upon selection criteria as listed, 1. From Status Group drop-down, select the status of the appropriate XML messages (Schedule, Application error, System error etc,). Status option is used to select or filter the XML messages based on the selection criteria. 2. In the Standard Selection Criteria tab, enter appropriate time period in the given fields. XML Messages can also be searched by entering the sender, receiver and their respective interfaces in the corresponding fields. 3. In the Advanced Selection Criteria tab, enter the XML message ID and search for a particular message and its status. XML Messages can also be searched by entering the Date values/logical Pipeline ID/ Queue ID in their corresponding fields.

Internal Use

5


Common status of the XML message:

The various status in processing the XML Messages are 1.

Application Error

2.

System Error

3.

Schedule Message

Application Error -

An Application error happens when the XML-message from the inbound service interface is processed in the receiver BO (ex. INVOICE). An exception occurs due to the improper information in the input message or master data not maintained properly, or due to Leading zeros issues or the BO instance locked by other transactions. System Error -

System error occurs due to the failure of messages in pipeline steps, improper / incomplete configuration, the target system not reachable or an authorization issue. Schedule Message-

Scheduled message occurs due to the following: 1 2 3

the bgrfc / qrfc queues that get blocked Further flow of erroneous messages in the same bgrfc / qrfc queues If the bgRFC scheduler is inactive or due to authorizations issue or dump.

Restart -

To reschedule XML messages with errors, select the corresponding line (only possible for messages with error status) and then choose Restart . The corresponding message is restarted (only if the error is rectified). It is only possible to reschedule asynchronous XML messages with errors. It’s possible to restart the messages in bulk by using the report RSXMB_RESTART_MESSAGES, and based on the selection criteria.

Cancel -

It is used to cancel the System/Application error. It’s also possible to cancel the messages in bulk by using the report RSXMB_CANCEL_MESSAGES and based on the selection criteria.

Internal Use

6


Payload

The payload contains the actual contents (business data) of a message. Error messages can be tracked using this payload. On both the sender and receiver side, it is possible to access the payload of a message. It contains two sections •

•

Header data (which contains details of the sender, receiver, business scoping information and so on) Transactional data (which contains customer transactional data)

Payload of the XML message can be downloaded from SXMB_MONI for further analysis of the actual input data and also for testing the mapping in ESR mapping tool and so on. Payload of the message can be viewed in TX-sxmb_moni as shown in the figure below.

Fig: Payload in sxmb_moni

Internal Use

7


3. SMQ2 –Inbound queue processing Asynchronous XI Message flow between two applications would be using the XI queues for the following purposes 1. To persist the XI messages temporarily 2. Where the response is not needed for the sending application immediately 3. EOIO queues are mainly used for serializing the business document flow based on business logic 3.1 Synchronous RFC

The first version of RFC is synchronous RFC (sRFC). This type of RFC executes the function call based on synchronous communication, which means that the systems involved must both be available at the time the call is made. Quality of Service for synchronous RFC is Best Effort (BE). 3.2 Transactional RFC (tRFC)

Transactional RFC (tRFC,) is an asynchronous communication method that executes the called function module in the RFC server only once. Quality of Service for Transactional RFC is EOIO (Exactly once In order).The remote system need not be available at the time when the RFC client program is executing a tRFC. tRFC is always used if a function is executed as a Logical Unit of Work (LUW). Within a LUW, all calls are: 1. Executed in the order in which they are called 2. Executed in the same program context in the target system 3. Run as a single transaction: they are either committed or rolled back as a unit. Disadvantages of tRFC

1. tRFC processes all LUWs independent of one another. Due to the amount of activated tRFC processes, this procedure can reduce performance significantly in both the sender and the target systems. 2. In addition, the sequence of LUWs defined in the application cannot be kept. Therefore, there is no guarantee that the transactions are executed in the sequence dictated by the application. The only guarantee is that all LUWs are transferred sooner or later. 3.3 Queued RFC (qRFC)

To guarantee that multiple LUWs are processed in the order specified by the application, tRFC can be serialized using queues (inbound and outbound queues). This type of RFC is called queued RFC (qRFC).

Internal Use

8


qRFC is therefore an extension of tRFC. It transfers an LUW (transaction) only if it has no predecessors (in reference to the sequence defined in different application programs) in the participating queues. Quality of Service for Queued RFC is Exactly Once In order (EOIO)/ Exactly once (EO). The qRFC queues can be monitored by the following ways: • • •

Transaction SMQ2 Transaction RZ20 -> Alert in CCMS -> QRFC queues Transaction SXMB_MONI -> Messages -> Click the queue name in the Queue ID column.

Example:

Consider the example scenario below in which the qRFC queues gets locked. If you get messages stuck in SMQ2, it is because of an error message that is locking the queue. Steps to be followed for processing the message: --------------------------------------------------1. Go to sxmb_moni -> Filter out the scheduled message -> Click the Queue ID. It will show the blocked queues.

Fig: qRFC Monitor

Internal Use

9


2. Double click the Queue ID- XBTS0005.

Fig: qRFC Monitor

3. Click the Unlock Button in the picture as shown below, to process the XML message stuck in the queue.

Fig: qRFC Monitor

4. Now you can see the change in the status of the XML message in the SXMB_MONI.

Fig: Processed XML Messages

Internal Use

10


4. IDoc Monitoring An IDoc Intermediate Document IDoc is a standard data structure for electronic data interchange (EDI). IDocs are used for the data interchange between SAP systems as well as between an SAP system and an external system. IDocs serve as the vehicle for data transfer in SAP’s Application Link Enabling (ALE) system. The contents, structure, sender, receiver, and current status of the IDoc are defined in the IDoc header.

Fig: Idoc flow Diagram

IDoc adapter is needed to connect SAP components (or external systems) to the Integration Server using IDoc communication. The IDoc adapter resides on the ABAP stack of the integration server and hence no Sender Agreement is necessary in order to setup the sender adapter. The IDoc adapter converts the IDocs to IDoc XML format so that they can be processed by the Integration server pipeline. It is also possible to transfer XML received by the Integration Server in IDoc format to connected systems. The Integration Server must convert the received XML to IDoc XML, and then transfer this IDoc XML to the IDoc adapter. The IDoc adapter converts the IDoc XML to native IDoc format and sends the IDoc to the receiver system identified in technical routing using the standard IDoc interface. The IDoc adapter can also call external subsystems. Essentially, the IDoc adapter comprises two parts, namely: 1. Inbound adapter at the Integration Server inbound channel 2. Outbound adapter at the Integration Server outbound channel.

Internal Use

11


1

The inbound adapter converts an IDoc to IDoc XML. It starts the Integration Server and then transfers the IDoc XML message.

2

The outbound adapter converts IDoc XML to IDoc format and transfers the IDoc to an SAP component or an external system (subsystem).

There are various selection criteria for selecting XML Messages in IDoc adapter.. Using IDoc adapters, we can only have asynchronous (tRFC) processing. Apart from using Runtime Workbench and transaction SXMB_MONI, IDoc messages can be monitored using transaction IDX5. XML Messages in the IDoc Adapter

Idoc XML messages in the IDoc adapter can be chosen as follows: Choose IDoc Monitor (Tx: IDX5). •

•

Select an XML message by specifying the time and date the message was created, or by entering a specific message GUID.

•

Specify your selection criteria in the group box IDoc.

•

Choose Execute.

Selection Criteria: Selection Criterion

Entry

System ID

Name of port in IDoc adapter

IDoc Object

Name of a customer enhancement or IDoc basic type Direction of IDoc transfer

Direction

The system sorts and lists the XML messages according to the time they were created. Messages were routed through as IDocs are listed together and are identified by the same message ID (GUID). Besides the specified selection criteria, the system also displays the following information: Display

Meaning

Client

Client in sender or receiver SAP component

Reference Number

IDoc reference number in IDoc adapter

Transaction ID

Transaction ID in IDoc adapter

Internal Use

12


5. Runtime Work Bench (RWB) Runtime Workbench is the central tool for accessing XI monitoring. The Runtime Workbench gives the option of navigating to the monitoring functions of the Integration Engine, as well as integration with the Computing Center Management System (CCMS), and the Process Monitoring Infrastructure (PMI) of SAP. RWB resides on the Java Stack and allows monitoring the flow of messages via the Adapter Engine (on Java Stack). Features

Central XI monitoring offers the following options: Component monitoring Message monitoring End-to-end monitoring Performance monitoring Index administration Alert configuration and Cache monitoring • • • • • • •

Login into the RWB using the URL: http://SID:port /rwb/index.jsp

In this document we have dealt with the message monitoring tool and their functionalities are listed as follows. Message monitoring

Message monitoring has the following functions: ●

Display and manage messages

●

Search for messages using the index

●

Filter displayed messages by a particular criteria

●

Configure the message display

●

Edit messages

Internal Use

13


The function of message monitoring is to search for all messages that were received or sent in the selected component, and the status of the messages where errors occurred during processing. The Integration Server component comprises both the central Integration Engine and the central Adapter Engine. 1. To get an overview of the current status of message processing, choose Database (Overview) and select the required component. 2. To select archived messages, choose Archive and select the required component. 3. Select an indexed component to perform an index-based message search (see Message Search Using Index).To do this, choose Index and select the required component.

Fig: Message Monitoring in RWB

In this section we have dealt with the Adapter Engine component. 1. Go to the ‘Message Monitoring’ tab and then select ‘Database’ from one drilldown and ‘Adapter Engine SID’ from the other drilldown. 2. Filter out the error messages for the required dates.

Fig: Message Monitoring in RWB

Internal Use

14


3. It will list out all the error messages as shown in the following screenshot.

Fig: Message Monitoring Error Message

4. Click on ‘Details’ to view the detailed information of the error message. It will show the error details as shown in the screenshot below

Fig: Detailed Error Message Display Tool

Internal Use

15


•

•

Message data -The message data provides all the available information about a message in the form of a table. Audit log -This option displays the audit log for the selected message by default.

Fig: Audit Log •

Message content-For XI messages, the version of a message is displayed, as well as the envelope or payload for this version.

Fig: Message Content

Internal Use

16


This describes the different tabs available in the Message monitoring screenand their uses.

Fig: Message Monitoring Tabs

•

Message Editor

Message Editor is used to edit a message and is used only for asynchronous messages with errors that can be restarted. Message editor can be called only with sufficient authorization. •

Referencing Messages

Referencing Messages are used for selecting messages that reference a specific message. •

Referenced Messages

Referenced messages are used for selecting messages that are referenced by a specific message. •

Resend or Repeat

It is used for processing messages with errors. To process the several messages simultaneously, choose Multiple Selection On. •

Cancel

It is used for cancelling the processing of messages with errors. To cancel several messages simultaneously, choose Multiple Selection On.

Internal Use

17


•

Error Log

It is used for displaying the log entries for messages that were not generated at the Adapter Engine inbound channel and thus not persisted. The error log provides information about messages that were received using adapters, but that have not reached the Adapter Engine. •

Advance Search criteria

It is used to search the error/process messages with different selection criteria’s such as Sender, Receiver, Sender/Receiver Interfaces, Message ID, Error category and so on as shown in the fig,.

Fig: Advance Selection criteria tab

Internal Use

18


6. Summary This document provides an overview about Monitoring the message flow (with regard to throughput) and the analysis and further processing of non-processed messages (status tracking) with the use of various monitoring tools such as Integration Engine monitoring, Idoc monitoring, Runtime workbench monitoring and so on.

7. References The following URL’s have been used while preparing this document. http://www.sdn.sap.com/ http://www.service.sap.com/

Internal Use

19

Monitor Tools in SAP PI

Recommend Documents