Table of Contents
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.
Configuration hints
- Use the surveillance table to adjust the monitoring settings:
- Thresholds
- Severity
- Filters
First collection window
- 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
0to 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.
Per-occurrence alarm
- 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.
Send metadata
- 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
Surveillance table
| Parameter | Description |
|---|---|
| Active | Use this field to activate or deactivate a line of configuration. |
| Client | A filter to match only messages of a given client. See the note below. |
| Location | Defines the location of the messages to look for: CONSUMER, PROVIDER, or ANY. |
| Adapter type | A filter to match only messages exchanged through a given adapter type. |
| Status | Define the type of status to look for. See the status mapping below. |
| Status code | A filter to match only messages with a particular numeric status code, such as 114. |
| Sending party | A filter to match only messages from a given sending party. |
| Sending interface | A filter to match only messages from a given sending interface. |
| Receiving party | A filter to match only messages for a given receiving party. |
| Receiving interface | A filter to match only messages for a given receiving interface. |
| Max messages | The threshold for the maximum number of messages matching the filters. An alarm is sent when the count is above this value, so 0 alarms on the first matching message. |
| Severity | The severity of the alarm. |
| enable Alarm | If checked, this line of surveillance will be used for alarm generation. |
| enable QOS | If checked, this line of surveillance will be used for metric generation. |
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.
Status mapping
- 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.
| Group | Code | Status |
|---|---|---|
| ERROR | 114 | System Error |
| ERROR | 117 | Application Error |
| DISTRIBUTION_ERROR | 111 | At Least One Distribution Was Unsuccessful |
| WAITING | 102 | Released for Processing |
| WAITING | 112 | Event Created |
| WAITING | 130 | Waiting for Transport Confirmation |
| WAITING | 131 | Waiting for Collection |
| SUCCESS | 103 | Processed Successfully |
| SUCCESS | 110 | Event Distributed Successfully |
| SUCCESS | 132 | Mapping Executed Successfully |
| OTHER | 118 | Transfer to External Application |
| OTHER | 119 | Manually Changed |
| OTHER | 121 | Manually Cancelled |
| OTHER | 122 | TU&C/C (annulled compensate message) |
| OTHER | 133 | Isolated Web Service |
Adapter type and location mapping
| Adapter type | Description |
|---|---|
| PLAIN_SOAP | Plain SOAP |
| GROUPWARE | Groupware |
| MAPPING | Mapping |
| EVENTING | Eventing |
| STANDARD_WEBSERVICE | Standard web service |
| SHORTCUT | Shortcut |
| INTEGRATION_SERVER | Integration server |
| RFC | RFC |
| Location | Description |
|---|---|
| CONSUMER | The message was sent by this system |
| PROVIDER | The message was received by this system |
Alarm content
- 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_ERRLOGand 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.
Examples
Example 1
| Active | Client | Location | Adapter type | Status | Status code | Sending party | Sending interface | Receiving party | Receiving interface | Max messages | Severity | enable Alarm | enable QOS |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| true | * | ANY | ANY | ERROR | * | * | * | * | * | 0 | MAJOR | true | true |
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.
Example 2
| Active | Client | Location | Adapter type | Status | Status code | Sending party | Sending interface | Receiving party | Receiving interface | Max messages | Severity | enable Alarm | enable QOS |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| true | * | CONSUMER | PLAIN_SOAP | ERROR | 114 | * | MI_O_AS_PUT_EXTERNAL | * | * | 10 | WARNING | true | false |
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.
Generated metrics
| metricId | metricUnit | metricTarget | metricDescription |
|---|---|---|---|
| SRT_MESSAGES_COUNT | Messages | [CLIENT][STATUS][LOCATION][ADAPTER_TYPE][SENDER_PARTY][SENDER_INTERFACE][RECEIVER_PARTY][RECEIVER_INTERFACE] | Sends the number of web service messages matching the filter, split by each distinct combination of the target fields. |
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.