Message Monitoring on Service Operation level

Introduction

Service Interfaces in the Enterprise Services Builder can support multiple Service Operations. The Process Integration system will calculate the correct Operation for a message during the Interface Determination step in the message processing pipeline, based on the message type and content.

The monitoring tools in the PI system only provide monitoring functionality at Service Interface level. It’s not possible to see the which Operation was used for a message. Furthermore, the Operation is not written to the message. It’s very hard to determine to which Operation a message relates, in case the Service Interface contains multiple Operations.

This was changed with the SAP Note 2243337. So please make sure to update your Adapter Engine to this patch level before trying the below steps yourself. The Operation and Message Type are now included in the Dynamic Header data of the message. This blog describes how this can be used for monitoring purposes.

Example Scenario

The required steps are illustrated with the help of an example scenario. It’s a scenario that uses two Message Types and a Service Interface with two Service Operations in the Enterprise Services Builder (Integration Repository). In this demo scenario we have one Service Interface to order and cancel tickets for an event. That means, the Interface will contain two operations. The scenario contains the following objects:

The scenario defines the two Message Types TicketOder and TicketCancel as request/source message types. They are mapped with Message Mappings to the respective target message types Oder and Cancel. The TicketOrder and TicketCancel Message types are very simple XMLs that just contain few elements for this demo purpose. We just wanted to have two different message types and use them later in two different Service Operations.

The request Service Interface TicketInterface contains two operations: TicketOrderOperation and TicketCancelOperation which use the two different message types.

The rest of the objects in the scenario are not really interresting and are only required to complete the scenario so that we can actually send a message through it. To finish the configuration it also contains a simple File-to-File scenario with Integrated Configuration in the Integration Directory, without any special configuration.

New Data in PI Message SOAP Envelope

With the changes from SAP Note 2243337 the Message Type and source Service Operation are now inserted into the DynamicConfiguration header of the message during the Interface Determination step. Before the changes, it would not have this information available at all in the message data. The new entries are in the SOAP Envelope of the PI message in the DynamicConfiguration part. The following screenshot shows one example message for each of the two message types TicketOrder and TicketCancel we defined. The entries in the DynamicConfiguration are highlighted. As you can see the TicketOrder message used the TicketOrderOperation and the TicketCancel message used the TicketCancelOperation.

TicketOrder Message:

TicketCancel Message:

The new XML elements are:

• SourceMessageType: The name of the Message Type. This relates to the Message Type object that was created in the Enterprise Services Builder
• SourceMessageTypeNS: The namespace of the scenario from the Enterprise Services Builder
• InterfaceFromOperation: The name of the Service Operation from the Service Interface

All three elements use the namespace http://sap.com/xi/XI/Message/30/routing which is important to remember for the next steps.

Monitor the Operation and Message Type

The Service Operation and Message Type data in the DynamicConfiguration as such is not yet very helpful in the monitoring tools. It’s only visible in the full message content display. To make it useful, the User Defined Search (UDS) can be used to index the fields and have them available as search criteria in the Message Monitor. The UDS fields and values can then also appear as own table columns in the message list and used for sorting and filtering.

Please note: UDS won’t work per default for synchronous messages. It only works if logging with payload is enabled for the synchronous scenario.

So first new UDS filters and data extractors have to be defined in the PIMON User-Defined Search Configuration. We create one new filter and name it TestDemoScenario (the name doesn’t matter) for this ticket scenario (please also make sure the filter is Active!) The filter defines the PI scenario (Sender-Receiver-Interface) that we want to index.

After the filter you have to create search criteria to define which data to extract from the messages. Now it has to extract the new fields from the DynamicConfiguration. For this purpose, the search criteria has to be of type Custom Dynamic Header and it has to contain the name and namespace of the new XML elements.

The name of the search criteria can freely be choosen. This name is later the name that we have to use in the Message Monitor. Here the name Operation was choosen, because this describes exactly the data. It’s possible to also add the other XML elements for SourceMessageType and SourceMessageTypeNS as search criteria, if this data is also interresting for monitoring purposes (but it’s not required to add them, if the only the Operation is interesting).

After finishing the UDS configuration, new messages will now be indexed and the data is extracted from them. It’s possible to see the data in the PIMON Message Monitor. When searching, please switch to the Advanced search filter and make sure to select the User-Defined Search Criteria. Now add the search criteria in the list and give the value * (star). This is required, because if UDS attributes are part of the search filter, then it will add a new column in the search result message list. The following screenshot shows how it should look like with the parameter Operation = *. Of course, it’s also possible to add the other search criteria (MessageType = *, MsgTypeNS = *) if desired. The important parts are highlighted in the picture:

The message list now contains a column Attribute ‘Operation’ and it shows the Service Operation of each message.

I hope this article can help you to fulfill the request to monitor and search for the Service Operations. Please leave a comment if I can improve anything or if there are open questions.

—