| Table of Contents | ||
|---|---|---|
|
Data Description
The pi_messages event is used in SAP to monitor PI/PO messages used for SAP integration scenarios.
...
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 |
scenarioidentifier | [comma separated list of scenario identifiers] | filter on scenario identifier | dir://ICO/5f885c3c58d83304944014a2a72194c0 |
Configuration
...
Tracking PO Messages that fail after retrying or timing out when using the onlyfaultymessages filter
In some cases, PO messages do not immediately fail. Instead, they may go through multiple retry attempts before eventually being marked with a systemError status (typically after 15 minutes by default).
Because PO messages are tracked from their original start time until they ultimately fail, the PowerConnect agent keeps an active record of these "in-flight" messages in its cache. This allows it to accurately query the message status, as the SAP PO message queries rely on the start time. However, when using the onlyfaultymessages filter, messages currently in retry (with a waiting status) may be filtered out because the filter only retrieves messages marked as systemError.
To avoid missing retrying messages, you have two options:
If using PowerConnect Java 7.3.0 or Higher
Set the "lag" in the PO Message extractor to match the PO message timeout duration (e.g. 15 minutes). This delay ensures that by the time PowerConnect Java collects the data, messages will have completed their status transitions (e.g.,waiting→systemErrororsuccess).
Using Advanced Filters with the Exclude Feature
Track messages in thewaitingstatus and retain only those that ultimately fail. This method allows you to see messages that were in retry and subsequently encountered an error:<PIFilters><PIFilter><status>waiting</status><payload>false</payload><logs>false</logs><excludes><status>success</status></excludes></PIFilter></PIFilters>
In the above filter messages with a status of waiting will be collected, stored in the inflight cache and tracked.
When the final status is set any messages that were successful will be removed by the exclude filter.
Notice we do not use the onlyfaultymessages filter here because this would not match the messages in waiting status.
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 minuteinterval | 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 |
Interval (ms) | How frequently the message collection runs | Yes | 60000 |
Max payload size (KB) | Max size of the payload to collect, this avoids collecting huge payloads that may causes performance issues in the SAP system or target analytics platform | No | 10240 |
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 |
PO Message Connection Type | Determine the method (WS or EJB) used to collect PO messages. Do not change without consulting support. | No | WS |
Splunk Event
The event will look different depending on the configuration options specified, but here is an example in Splunk:
...