SRT message monitoring

This monitor is dedicated to the monitoring of SOAP runtime web service messages.
It provides a monitoring equivalent to transaction SRT_MONI.
It will look for messages created since the last check and match them against your rules,

depending on the client, the location, the adapter type, the status and the interfaces involved.

• Use the surveillance table to adjust the monitoring settings:
  • Thresholds
  • Severity
  • Filters

• On its very first run the monitor has no previous check to start from, so this window defines how far back it reaches.
• Afterwards the monitor only collects messages created since the previous run, whatever this field says.
• Set 0 to collect the whole table on the first run. Use with care, see the note below.
• Changing this value re-baselines the monitor: the stored position is dropped and the next run collects from the new window again. This is the supported way to make the monitor forget where it was.

Note: CREATED_AT is not indexed on SRT_MMASTER. A wide first collection window results in a full table scan on the SAP system, and can return a very large number of messages. Start with a narrow window on a productive system.

• This option allows to tune the volume of alarms that will be generated:
  • If enabled, you will receive one alarm per web service message, with details.
  • If disabled, you will only get one alarm per rule, if the count of messages matching the filter is above the threshold.

• If enabled, this parameter will send collected messages as metadata to the configured plugins/integrations
• It can usually be retrieved as logs or tabular data within the corresponding integrations
• All collected messages are sent, not only those matching a surveillance rule

Note: RFC_READ_TABLE performs a client-dependent read, so the monitor only ever receives messages of the client the connector logs on to. The Client filter is applied to those messages, which means it can only match all of them or none of them. To monitor a second client, create a second connector.

• The Status field selects a group of states, and Status code narrows the selection within that group.
• Leave Status code at * to keep the whole group.

• The alarm message contains the status and its code, the client, the route, the adapter type, the location and the creation time.
• When the message is in error, the readable error text is read from SRT_UTIL_ERRLOG and appended, together with the message class and number.
• A field that SAP does not fill is displayed as -. This is normal for the parties, which are only used in B2B scenarios, and for the receiving interface of a CONSUMER message.

Note: SRT_UTIL_ERRLOG is usually kept for a much shorter retention than SRT_MMASTER. Messages in error that are older than that retention are still reported, but carry no error text.

Effect: Sends a MAJOR alarm for each web service message found in a System Error or Application Error status, and sends the message count as a metric.

Effect: Sends a WARNING alarm if more than 10 messages sent by interface MI_O_AS_PUT_EXTERNAL over Plain SOAP are found in System Error status. No metric is generated for this rule.

Note: One series is created per distinct combination of the target fields actually seen during a run. The number of series therefore follows the traffic on the monitored system rather than the monitor configuration. On a system exchanging with many interfaces or partners, this can produce a large number of series in the receiving integration.

Note: A maximum of 5000 messages is read per run. If that cap is reached, the remaining messages are not read and are not reported: RFC_READ_TABLE returns rows in no defined order, so the messages skipped are an arbitrary subset. This normally only happens on a first collection with a wide window. Reduce the first collection window, or schedule the monitor more frequently.