Introducing the Monitor Model
To provide business level monitoring, IT systems must produce data that is recorded. We can imagine a system producing an event that a sale has occurred. The event data may be described as XML, character delimited, COBOL copybook or some other format of data. This is the concrete representation of the data. It may be stored in files or database tables. However, this is too low-level for our purposes. What we really want to do is record the conceptual information. We want to have a model of the data under consideration and have the real world physical data be used to populate the notion of our model.
Let us try and make this real. Imagine we wish to answer the question "What was the average value of an order?" To be able to answer this, we need to record the value of each order as it is encountered. An order may be taken by a variety of sources. For example, a web site may result in an order or a phone call to a CSR. Each of these may result in an event, possibly in a different format, indicating that an order has been made. However the order is received, all of them indicate an order. This leads us to the notion of a "an order" as a logical entity separate from the physical data. The set of logical entities in aggregate are described as a model. The model describes:
The overview then of how Business Monitor is used is that a developer builds a Monitor Model (MM) describing the metrics that they would like to work with. Next the developer will map the real incoming data to those metrics describing when and how they are populated.
Monitor models are created and edited in an Eclipse Perspective that can be found in IID.
Before building a model, a monitor project must be constructed. A simple wizard is presented into which the name of the new monitor project can be supplied.
Once created, the project holds a number of folders. The one of interest to us right now is Monitor Models.
The wizard for creating the Monitor Model is also very simple.
Once created, the Monitor Model editor is opened. It is within this editor that the vast majority of monitor model definitions are performed.
A monitoring context is part of the Monitor Model. A context defines a set of metrics and other attributes that are related together through a common thread. For example, if a sales order has a description of what is being ordered, a price and an actual shipped date, it may be that this data is not generated at one time. For example, when the order is first received, we know what is being ordered and how much it is selling for but it is some time later that we know the date of actual shipment. If the data that describes this sale arrives in pieces over time then we need to ensure that the distinct pieces are contextually related to each other. It is the Monitoring Context that allows us to group together these properties. As subsequent events arrive which belong to the same monitoring context, the model for that instance is updated with the new information.
Within a Monitoring Context one or more fields must be flagged as key fields. It is the key fields that provide the identity of the context.
Key fields show up in the monitor model with a key icon beside them
The properties of the key details look as follows:
A core aspect of the key is the XPath expression used to set its value.
The Inbound event monitor model definition describes an external event that is to be recognized by this monitor model. An inbound event is external data that physically arrives at Business Monitor. The data has to be in XML format. The inbound event conforms to an XML Schema Definition (XSD) that is used to map the incoming data.
The event data descriptions are described through either CEI or through XSDs created in another section.
When an event is received, all monitoring context are given the opportunity to work with the event. The mandatory
Filter Condition executes an XPath expression against the received data. If the expression evaluates to true, then the event will be handled by this model, otherwise the model will ignore the event as though it had never happened.
Once an event is determined to be appropriate for this model, the next question becomes one of which instance of the model should the event be delivered? Here an expression is supplied that is used to match the data in the event against a specific instance of the monitor model context. Rules then govern what to do in each of the possible circumstances where zero, one or may instances are found.
The Metric definition defines a specific data item that can be used by dashboard designers for populating those dashboards. The Metrics are the logical entities of the model that we eventually wish to populate with data received contained within externally published events that are received by the Inbound Event.
Each Metric definition has an
ID and a
ID is the unique value maintained for the metric. The
Name is a human readable annotation for the metric.
Each of the metrics has an associated data type. The allowable data types are:
Within the metric definition is the ability to supply an expression that will be used to populate the metric from an incoming piece of data.
The Stop watch is a timer that can be started, stopped or reset. Initially, it is not counting but when an event or a trigger arrives, it can be told to start. Other events and triggers can be used to stop or reset it.
A trigger is an indication that something has happened. Specifically, a trigger can occur when a metric's value changes, another trigger fires, an inbound event arrives or a clock timer fires. Let us call this the trigger's source event.
In addition to the source event, there is an optional expression which can be evaluated. The outcome of this expression is either true or false. If no expression is supplied, the trigger will fire every time the source event occurs. If an expression is supplied, then when the source event happens, the expression will be evaluated. Only if the expression results in a true value, will the trigger actually fire.
A boolean attribute on the trigger is available called "Trigger is repeatable". This indicates whether or not the trigger may fire more than once for this monitoring context.
If is set to true (checked), then the trigger will fire every time its source event happens. If a condition is also supplied, then obviously the trigger will only fire if the condition is also true.
If the repeatable flag is set to false, then if there is no condition supplied, the trigger will fire once and once only. If a condition is supplied, it will fire the first time a source event happens and the condition is true and will not fire again until the condition becomes false and then true once more.
Another attribute of the trigger is called "Terminate monitoring context". If this flag is set to true then when the trigger fires, this is the indication that the monitoring context is no longer needed and the monitoring context will be flagged as "closed".
As mentioned previously, the source event that can cause a trigger to fire can be a time base. The trigger definition for time events has three possible options.
The first is a recurring evaluation. This is an interval of time after which the trigger condition will be evaluated (if one is supplied) and the trigger will fire. If the trigger is flagged as repeatable, the interval will be repeated otherwise it will be a one-off fire.
The second option is a specific time evaluation. This is a one-time trigger that will happen on the date/time specified.
The third option is a daily evaluation which will fire at a specific time of the day each day that the monitoring context is open.
Monitor not only has the ability to receive events for processing, it has the ability to publish events for others to consume. One of the core consumers of this is the notification mechanism. Within a monitor model we can define "Outbound Event" definitions which declare when an outbound event should be fired and what it may contain.
When created, we get to name the event and also define
In the creation wizard, we can define that this is an event that will be destined for the Monitor action services and what trigger will be used to cause the event to be emitted.
Commonly we define a value for the "
BusinessSituationName" which will be used as the key for the type of action service to be performed: