Start of Content Area

Background documentation Filters  Locate the document in its SAP Library structure

You must ensure that alerts are triggered in relevant situations only. If too many alerts are generated, the responsible user may overlook the alerts that are actually relevant. A large volume of alerts can also impair system performance. Therefore, you must ensure that adequate filters are applied to the alerts and the events on which they are based.

Time

To keep the system load to a minimum, you must make sure that events are filtered as early as possible when you implement the scenario variant milestone monitoring.

The following figure shows the possible times for filtering events and alerts:

This graphic is explained in the accompanying text

Time 1: Filter in the application

The application can use conditions or be programmed to filter events.

The advantage of this alternative is that the maximum possible amount of data is available for determining relevance. Furthermore, filtering in the application involves no significant extra system load. However, you define the conditions for filtering in the application and cannot manage them centrally.

Time 2: Filter in event linkage

In the event linkage, you can define conditions on the data of the underlying BOR or ABAP OO object. In a scenario variant where alerts are published directly, you define in the event linkage that a particular event triggers an alert directly in the Alert Framework. In a scenario variant for monitoring process milestones, you define in the event linkage that a particular event generates an event message using a message proxy. A monitoring process is subscribed to this event message. By using corresponding conditions, you can filter the events so that only significant events trigger an alert or generate an event message.

Compared with Time 1, condition management is much more central, but the communication costs are higher.

Time 3: Filter in the message proxy

In a scenario variant where a monitoring process subscribes to events, a message proxy uses the event to generate an XML message. This message is then processed by the monitoring process. You assign the message proxy to the event in the event linkage. You can use programming methods to define filter conditions in the message proxy.

Compared with the first two alternatives, condition management is more central. However, the communication costs are higher and less data is available for the filter conditions.

Time 4: Filter in the receiver determination

In a scenario variant where a monitoring process subscribes to events, you can define conditions in the receiver determination. These conditions can filter the event messages that are delivered to a monitoring process.

You must only use this option for existing communication scenarios. The communication costs in this case are very high, since the Integration Server is used for filtering. The Integration Server is the central resource and you must keep system load to a minimum.

 

End of Content Area