Defining a Monitoring Process 

Use

A monitoring process is a special kind of integration process that you use as part of Business Activity Monitoring (BAM). You use a monitoring process to monitor the milestones in a business process. The business process can be distributed across multiple applications. When a milestone is reached, the applications each publish events, to which a central monitoring process is subscribed.

In monitoring processes you can define that alerts are triggered if particular events occur or deadlines are missed. Furthermore, you can define conditions for creating alerts. You can also include information shipped by Business Intelligence in the conditions, for example, whether a customer is an A customer (“Gold Customer”).

Only use monitoring processes to monitor events from applications. Do not use a monitoring process to monitor events from other monitoring processes. These kinds of monitoring process hierarchies are not supported. 

Typical Structure

A monitoring process usually comprises the following elements:

●      One event message that starts the process

●      Further event messages that the process subscribes to by means of correlations.

●      Conditions that evaluate the events and create corresponding alerts

You can group together recurring sequences in step groups. Doing so makes it easier for you to define monitoring processes and improves the clarity of the monitoring processes.

See Defining a Step Group

Procedure

       1.      Create a monitoring process.

See: Creating a New Object.

Define and Correlate Event Messages

       2.      Define a starting receive step that waits for the event message that is to start the monitoring process.

See: Starting an Integration Process.

If various different event messages are able to start the monitoring process, define a starting receive step for each one.

See: Example: Multiple Process-Starting Receive Steps

       3.      Define a correlation for the event messages that the monitoring process is to subscribe to.

See:

Correlating Messages

Checklist: Making Correct Use of Correlations

       4.      To receive the remaining event messages in the monitoring process, insert the relevant receive steps in the process definition.

Each of these receive steps must use an activated correlation. A receive step can in turn activate a correlation.

Query Data from Business Intelligence

       5.      To query data from Business Intelligence, use a transformation step that calls a parameterized mapping.

See: Transformation Step

You can use the result in a condition and make further processing dependent on the result.

Defining a Condition

       6.      Define conditions for filtering the events and for triggering alerts:

Insert a switch and for each branch define the relevant condition and the action that is to be executed when the condition is satisfied.

See Defining a Condition

Monitoring Deadlines and Triggering Alerts

You can define the following types of deadline monitoring with the following type of alerting:

●      If the process does not receive a particular event message within a given period, it triggers an appropriate alert and continues to wait for the event message.

●      If the process does not receive a particular event message within a given period, it triggers an appropriate alert and continues processing.

Define an Alert – Process Continues to Wait

...

       1.      Insert a block at the required position in the monitoring process.

       2.      In the branch for normal processing, insert a receive step that is to receive the required event message.

       3.      Insert a deadline monitoring branch for the block and define the required deadline.

       4.      Insert a control step that is to trigger an alert.

Define an Alert – Processing Continues

...

       1.      Define a container element Flag of type xsd:string.

       2.      Insert a fork and for the number of branches to be processed, enter 1.

       3.      In one of the branches, insert a receive step that is to wait for the event message.

       4.      Insert a wait step in the other branch and define how long the wait step is to wait.

       5.      After the wait step insert a control step that assigns the value X to the container element Flag.

You can query the value of this container element in a later step to determine which branch of the fork was processed at runtime.

       6.      Insert a switch after the fork and define the required reaction for each branch.

For example, you could insert a control step to trigger an alert.

See: Triggering an Alert in an Integration Process