5.11    Message Alerting

SAP PO has a feature to alert concerned users and administrators when technical problems occur in the server available in its platform. Message alerting is based on defining alert rules. An alert rule in SAP PO helps configure the rules, circumstances, and conditions under which an alert needs to be created. Most of the time, these conditions define a technical error. Messages going through the integration layer of SAP PO are checked against the conditions defined in the alert rulesets. If a match is found, then an alert is generated and triggered. These triggers are sent to interested administrators, users, and applications. You might need to define multiple alert rules to enable sending different types of technical errors to different interested parties.

5.11.1    Alert Rule Overview

An alert rule contains the following main information:

• Integration Directory objects, such as communication components, parties, ICOs, and configuration scenarios
• The impacted runtime components and systems, including integration server(s) and business systems
• Message statutes, enabling you to choose what type of message statuses you want your alert rule to report on
• List of subscribed applications (called alert consumers) that have registered to consume the alerts of the rule

Figure 5.31 shows a summarized illustration of process steps involved when dealing with message alerting. SAP PO also provides an API that allows you to write external custom applications to consume the alerts generated in SAP PO.

In SAP PO, you can use either component-based message alerting or “classic” message-based alerting (available only in the ABAP stack). We’ll focus on the recent component-based message alerting because it’s more suited for a Java-only installation.

To support this alert mechanism, SAP PO includes an alerting infrastructure that uses the following components:

• A central configuration in which users can create alert rules. The alert rules need to be configured for each SAP PI domain; the created alert configurations are in the Integration Directory.
• A local alert engine is present in each SAP PI runtime component and AAE. The alerts triggered by the local alert engine are stored in a local alert store.
• Applications interested in consuming the generated alerts are also referred to as alert consumers. Alert consumers can read alerts from the local alert store and send notifications via email, fax, or SMS. The alert store contains a substore for each registered alert consumer, so each consumer reads alerts from its own alert inbox.
  

  Figure 5.31    Process Flow and Components of Rule Alerts

It’s also possible to configure SAP Solution Manager as an alert consumer, which means the alerts generated in SAP PO will be present in SAP Solution Manager. The advantage of doing this lies in SAP Solution Manager’s central monitoring capabilities. SAP Solution Manager has a well-integrated solution to deal with alerts generated by SAP PO, and it can read, aggregate, and display the alerts in a web-based user interface.

An alert rule object can be accessed in the Integration Directory and points to other Integration Directory objects that are included in its configuration. For the configured alert rule to start sending alerts, it needs to be activated. After activation, a runtime version is created, and the evaluation of conditions starts.

With SAP PO, we no longer need the alert rule based on the ABAP stack that used to be in the older version of SAP PI. It’s now based on a Java stack and leverages the AEX.

Note

The alert rule only concerns the SAP PI or the AEX part of SAP PO. SAP BPM processes aren’t taken into account by the alert rules.

You can create as many alerts as you wish. It’s important to note, however, that SAP PO has a special type of alert rule generally referred to as the default rule. It doesn’t exist by default and needs to be created (we explain this in Section 5.11.2). Its creation requires taking into consideration the following special set of rules and behaviors:

• During the creation of the default alert rule, the name DEFAULT_ALERTRULE is automatically used and is a read-only field. Note that the name needs to be exactly as shown here and is case sensitive.
• The default rule doesn’t have configuration objects assigned to it. It’s read-only, and you can’t add Integration Directory objects to it.
• The default rule will automatically apply to all messages, irrespective of their statuses.
• It’s possible to remove consumers to the default rule and select which runtime components will be affected by it.

When a default rule is present in your SAP PO installation, the alert engine will use it to evaluate all messages and create alerts. See Figure 5.32 for an alert rule configuration example.

An alert rule (nondefault alert) has the same behaviors as any configuration object and can be created, updated, deleted, and activated. Any change or update to an existing rule (such as the removal of affected configuration objects) will only take effect after the changes made have been activated using a part of the change list in the Integration Directory. You might wonder what will happen to consumer applications after a rule is deleted; luckily, there is a mechanism in place to inform all consumers after the activation of the deletion.

Now that you’re familiar with the basic notions of alert rules, the next few sections will explore how to perform actions such as their creation and deletion.

Figure 5.32    Process Flow of Alert Rules and Their Components

5.11.2    Creating an Alert Rule

There are two ways to create and maintain an alert rule: via the SAP NetWeaver Administrator or via the Integration Builder.

Via the SAP NetWeaver Administrator

To create a new rule via the SAP NetWeaver Administrator, follow these steps:

1. Log in to SAP NetWeaver Administrator, and navigate to the SOA tab. Select the Monitoring tab, and click on Message Alert Configuration.
2. Click on the New button on the top-left side of the toolbar.
3. You’ll see a menu from which you can choose either Alert Rule or Default Alert Rule. Note that both Alert Rule and Default Alert Rule are rules bound to specific messages or interfaces as follows:
   • The default alert rule is unique and is automatically created with the standard name DEFAULT_ALERTRULE. Furthermore, the name and description can’t be changed. Also note that you can’t freely assign configuration objects to the default alert rule, and it applies to all message statuses. However, you can specify runtime components and add consumers.
   • When creating an alert rule, you’re given carte blanche to define the name and description to suit your needs. As opposed to the default alert rule, an alert rule is meant to be more specific.
4. From the General tab, give a name and description to your rule. Additionally, fill in the following fields:
   • Enabled
     Set whether the alert should be enabled right away. You can disable an alert at any point by changing this value. Enabling the alert is an important step because only when it’s enabled can it be activated or deployed to runtime.
   • Payload in Alert
     Set to enabled or disabled depending on whether you want the payload (actual XML message) to be included in the alert or not. Enabling the payload requires (as a prerequisite) the user-defined search capability to be configured.
   • Severity
     Specify the severity of the alert (Low, Medium, High, or Very High).
   Note that it’s not possible to change the name or description for the default alert rule.
5. In the Message Header Rules tab, click on the Add button to include the Integration Directory configuration objects in your rule. You’ll see another submenu with different Integration Directory categories (Party, Integration Flow, Service Interface, Integration Flow, etc.). After selecting a particular category, you’ll see a pop-up in which you can select the actual object. Note that this tab is read-only for the default alert rule.
6. In the Components tab, you can select the runtime components to be affected by the alert rule.
7. In the Message Statuses tab, you can select which types of errors should trigger an alert. The error statuses are grouped and categorized by components. This is an extensive list, containing categories such as Channel, Adapter Type, Runtime, Validation, Virus Scan, and so on. Make your selections per your requirements.
8. Save your settings.
9. After saving, you can check the consistency of your rule. The alert rule will be internally tested to check for errors. In there are errors, you’ll see a message at the top of the page
10. Activate the rule. After activation, the rule will be pushed to the different runtimes. The activation is an asynchronous process. After a successful activation, the rule becomes green. The status of the rule activation can be further checked in the General tab of the alert rule.

Note

An alert rule must contain at least one Integration Directory configuration object.

After selecting an entry in the Message Header Rules tab, you can click on the Show Message Header Rules button to see directory objects that have been added to the rules. These are the objects that alerts will be generated on.

Be aware that all the alert rules created in SAP NetWeaver Administrator are also available from the Integration Directory.

Via the Integration Directory

To create an alert in the Integration Directory, follow these steps:

1. Launch the Integration Directory from the SAP PO landing page.
2. Right-click under the Alert Rule section, and click New.
3. From here, follow steps 3 to 10 as described for the SAP NetWeaver Administrator.

See Figure 5.33 for an example of what an alert rule looks like in the Integration Directory.

Figure 5.33    Alert Rule View from the Integration Directory

5.11.3    Editing or Deleting a Rule

Based on your situation, you might need to change an existing rule or completely remove it. To update or delete existing alert rules from the SAP NetWeaver Administrator or the Integration Directory, follow these steps:

1. From the SAP NetWeaver Administrator, navigate to SOA • Monitoring, and click on the Message Alert Configuration link.
2. The screen that appears provides a list of all existing alert rules. From this list, select the desired rule, and click on the Edit or Delete button.

From the Integration Directory, the alert rule can be updated or deleted like any other configuration object.