Skip to main content
Skip table of contents

PI/PO Messages

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

image-20241031-003434.png

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

image-20241031-002950.png

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

scenarioidentifier

[comma separated list of scenario identifiers]

filter on scenario identifier

dir://ICO/5f885c3c58d83304944014a2a72194c0

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., waitingsystemError or success).

    image-20241030-213326.png

  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.

image-20241031-002259.png

Name

Description

Restart of PowerConnect Required?

Default

Max number of messages per interval

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:

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.