Data Description
The pi_messages event is used in SAP to monitor PI/PO messages used for SAP integration scenarios.
Potential Use Cases
This event could be used in the following scenarios:
Alert on message failures
Use data from the message payload in integration monitoring scenarios to quantify business impact
Understand if messages are in a holding status for an extended period of time
Correlate message data to iDocs or SXMB_MONI integration components for an SAP ABAP system
PowerConnect Administrative Console Configuration
By default if the PI Monitoring Plugin is enabled it will use the Simple Filter configuration which will collect all messages including their logs and payload. The simple filter can be tuned further as detailed in the Simple Filters section below.
For more advanced filtering involving multiple filter sets a xml configuration can be provided which is detailed in the Advanced Filters section below.
The PI Message Monitoring plugin also automatically tracks long running PI Messages which may span multiple collection intervals.
Simple Filters
Simple filters work on individual PI message fields. If more than one filter is set, a logical AND is applied to the filters. By default a value of NOT_CONFIGURED represents a wildcard so for example if the Receiver Name filter is set to NOT_CONFIGURED the filter will match any Receiver Name in the PI Messages. Simple filters also allow the collection for PI Message payloads and logs.
To persist the changes to the Simple Filters hit the Save button.
Name | Description | Accepted Values | Restart of PowerConnect Required | Default |
|---|---|---|---|---|
Direction | Filter on Sender or Receiver direction | OUTBOUND, INBOUND | No | NOT_CONFIGURED |
Only Faulty Messages | Track only PI messages that experience an error | true, false | No | false |
Receiver Name | Filter on Receiver name | Any string | No | NOT_CONFIGURED |
Receiver Party | Filter on Receiver party | Any string | No | NOT_CONFIGURED |
Sender Name | Filter on Sender name | Any string | No | NOT_CONFIGURED |
Sender Party | Filter on Sender Party | Any string | No | NOT_CONFIGURED |
Status | Filter on status of PI message | success, toBeDelivered, waiting, holding, delivering, systemError, canceled | No | NOT_CONFIGURED |
Message Type | Filter on PI message type | Any string | No | NOT_CONFIGURED |
Interface Name | Filter on Interface name | Any string | No | NOT_CONFIGURED |
Interface Namespace | Filter on Interface namespace | Any string | No | NOT_CONFIGURED |
Collect message logs | Enables or disables PI message log collection | true, false | No | true |
Collect message payload | Enables or disables PI message payload collection | true, false | No | true |
Collect payload version | Specifies payload version to collect | all, latest | No | latest |
Advanced Filter
Advanced filters should be used where simple field filters are insufficient for the use case. For example consider the following scenario. You have 15 PI Receivers and you are only interested in collecting PI message meta data from 2 of them. However if any PI message from the 2 Receivers has errored during processing, you would also like to collect the payload and logs for those errored PI messages.
This scenario can be implemented using Advanced Filters. The Advanced Filters are configured using an XML configuration file. The XML file can contain multiple filters, each with their own set of field filters along with the ability to enable payload and log collection per filter.
As an example let’s say the 2 Receivers from our scenario above are named rec_1 and rec_2. The XML to cater for the scenario would be as follows:
Note the ommission of any field filter means it takes it’s default value.
To apply this XML configuration save the file then click the Choose file button. Then select and open the XML file you just saved. The new filters will then be applied. Note that Advanced Filters override the Simple XML filters.
To export the configuration press the Export XML link.
To clear the Advanced Filters and revert back to using Simple Filters press the Clear button.
The xml configuration elements are detailed as follows:
Element Name | Accepted Values | Description | Example |
|---|---|---|---|
direction | INBOUND, OUTBOUND | filter on direction of pi message | INBOUND |
interfacename | Any string | filter on interface name of pi message | testinterface |
namespace | Any string | filter on namespace of pi message | testnamespace |
messagetype | Any string | filter on type of pi message | send |
onlyfaultymessages | true, false | track only pi messages that experience an error | |
receivername | Any string | filter on receiver name of pi message | testreceiver |
receiverparty | Any string | filter on receiver party of pi message | testparty |
sendername | Any string | filter on status of pi message | testsender |
senderparty | Any string | collect staged payload of pi message | testparty |
status | success, toBeDelivered, waiting, holding, delivering, systemError, canceled | filter on status of pi message | systemError |
payload | true, false | collect specific version(s) of staged pi message payload | |
logs | true, false | collect logged payload of pi message | |
payloadversion | all, latest, [comma separated list of versions] | collect specific version(s) of staged pi message payload | 1,4 |
payloadlog | true, false | collect logged payload of pi message | |
payloadlogversion | [comma separated list of versions] | collect specific version(s) of logged pi message payload | 0,1 |
Configuration
This section of the PI Message Monitor configuration deals with general configuration settings which apply globally.
Name | Description | Restart of PowerConnect Required? | Default |
|---|---|---|---|
Max number of messages per minute | Sets the limit on the number of messages the PI Monitoring plugin will collect per run per filter (per SAP instance) if you have 2 instances, and this is set to the default (100) then the agent will collect 100 messages per instance equal to 200 messages maximum across the entire instance. | No | 100 |
In-flight message cache size | Sets the limit on the number of in-flight PI messages the PI Monitoring plugin will track | Yes | 1000 |
In-flight message cache expiry (hours) | Defines how long in hours the in-flight PI messages will be kept in the cache before being removed | Yes | 24 |
Splunk Event
The event will look different depending on the configuration options specified, but here is an example in Splunk:
Field Mapping
Field | Description | Unit of Measure |
|---|---|---|
application_component | Application component | String |
connection_name | Connection name | String |
direction | Sender or Receiver direction | String |
duration | Message duration | Number (miliseconds) |
end_time | Latest status update time for the message | YYYY-mm-ddTHH:MM:SSZ |
event_type | pi_message | String |
instance_id | Server node | Number |
integration_scenario | Integration scenario | String |
linecount | Number | |
message_id | Message ID | String |
message_key | String | |
parent_id | String | |
payload | Message payload | String (XML) |
pid | Process ID | String |
punct | String | |
qos | The message Quality of Service. BE (Best Effort), EO (Exactly Once), and EOIO (Exactly Once in Order) are valid inputs | String |
receiver_interface | Receiver interface and namespace | String |
receiver_name | Receiver component name | String |
receiver_namespace | Receiver namespace | String |
receiver_party | Receiver party name | String |
sap_system_name | SAP SID | String |
sender_interface | Sender interface and namespace | String |
sender_name | Sender component name | String |
sender_namespace | Sender namespace | String |
sender_party | Sender party name | String |
size | Message size | Number (bytes) |
start_time | Initial send time | YYYY-mm-ddTHH:MM:SSZ |
status | Message status | String |
system_type | Type of SAP system | String |
version | Message version | Number |