Page Comparison

Data Description

The pi_messages event is used in SAP to monitor PI/PO messages used for SAP integration scenarios.

...

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.

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.

...

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.

...

The xml configuration elements are detailed as follows:

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:

1. 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 → systemError or success).
   

   Image Added

2. Using Advanced Filters with the Exclude Feature
   Track messages in the waiting status 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.

...

Splunk Event

The event will look different depending on the configuration options specified, but here is an example in Splunk:

[insert screenshot]

Field Mapping

...

Field

...

Description

...

Unit of Measure

...