Alerts and Actions

If monitor detects an event that should be made known to a user, it can use the concept called "Situation Events".

Action processing is managed by the WAS application called "IBM_WBM_ACTIONSERVICES".

Action Service templates

When a situation event occurs, it can be serviced by of one of three possible types of action:

These are defined in the WAS Admin Console:

Notification Templates

The notification template describes HOW we wish to notify someone when a business situation happens. These notifications are available in four distinct types:

They all use the same format of template. Core within the template are places where we can define what the "Subject" and "Body" of the notification will be composed from. Think of this as describing WHAT the user will see when the notification is made.

When creating a new template definition, it looks as follows:

Both the "Subject" and "Body" properties can use meta code to describe data. The meta code can be:

Let us look at an example of this:

Consider an outbound event definition that looks as follows:

Notice specifically the addition of an event property called "Amount" that is populated from a Monitor Model metric. This means that when this event is published, it will also contain event specific data.

In our template, we can refer to the value of that property via the meta string:


With these concepts in mind, let us now see if we can put some of them together. Consider a scenario where you want to be informed of a high value sale on your dashboard. This is an example of an alert.

The first thing we will want to do is to create a "template" used by Monitor's action services subsystem. This template describes "what" we want to happen when a situation such as a high value sale is detected.

Templates can be added, viewed or deleted from the WAS admin console at:

Applications > Monitor Services > Monitor Action Services > Template Definitions > Notifications

Within the template definition, we have choices of what type of action service to built. We will concentrate on the "Dashboard Alert".

The template describes what shall be the content of the Subject and Body.

Once the template has been built, we have an abstract definition of what the user might see if a business situation is encountered but we have not yet said "which" events will result in the creation of such an alert. That is where the next part comes in. What we now do is bind a "Business Situation Event" (a technical thing) with the template that defines what should happen when that technical thing is detected. We again perform this task through the IBM WAS Admin Console.

Applications > Monitor Services > Installed Situation Event Bindings

Within this area, we can add, view and delete the bindings/relationships between events and templates. The administration user interface here is a little confusing so let us take some time. When we first visit the link, we will see an empty table that looks as follows:

If we click the New button to create a new entry, we are presented with the following screen:

The first thing we need to do is enter the value for the "Situation event name". This is the technical part that is the "key" in the data that says "Hey... an event has happened that I want you to tell someone about!". Once we enter a value here, we must hit the Apply button before we can go further.

Once done, we can now define the association between THIS event and a template that describes how we want to inform the user. Clicking the Add button opens a new screen. Within this screen we get to provide a name for our binding association and finally, the ability to specify which action template to use to handle the event.

The result will be:

That sure is a lot of indirections!! The way to interpret this important page is as follows:

"When a business situation event of type 'HighValueSale' happens, then execute the alert service described by the template called 'Not1'. This binding is known by the name of 'My Alert' and it so happens that the template type if an 'AlertHandler'".

With all this in place, we now think about how an event is generated by the monitor model. What we do is create an instance of an "Outbound Event"

During creation, we have the option to check the box labeled "Configure this event to be processes by IBM Business Monitor action services". It this that defines this event as the source of an alert. The outbound event must also be associated with a Monitor Model trigger to determine when the event should be fired.

Because we checked the box that said this was a monitor action event, the payload of the event has been partially filled in for us. Among its properties is one called "BusinessSituationName". This property is very important. This is the key used to determine which template to invoke. This maps to the "Situation event name" defined in a previous WAS admin panel.

Page 2

No Comments
Back to top