Moving Forward with the On Demand Real-time Enterprise

Chapter 4. IBM technologies supporting real-time 201

The adaptive action manager performs two types of actions: notification actions

and service invocation actions:

򐂰 Notification actions take the form of e-mail, SMS, pager message, or a

dashboard alert.

򐂰 Service invocation actions invoke a Web service, or a BPEL process through

a Web service invocation.

The adaptive action manager parses the received situation event and selects an

appropriate action by looking up the action in the action catalog database, where

action-related information and binding information are stored. If the appropriate

action is a dashboard alert, the action manager extracts the data needed for the

creation of the alert-notification record from the received situation event and

inserts this record in the WebSphere Business Monitor Runtime database. The

record is collected by the Alerts view in a dashboard. The adaptive action

manager uses LDAP as the user-registry for user notifications.

4.4.5 Databases

The data architecture of Monitor V6 has been optimized for both transaction

processing data stores as well as data marts for reporting, analytics and

business intelligence.

Simply stated, the Monitor V6 is responsible for its own data store to handle data

required for the monitoring operation: instances of running monitoring contexts

and metric values. The performance is optimized by dividing the data store into

different databases, each being optimized for specific types of DB access

operations.

DB2 replication services are responsible for moving state data to the historical

data store at configurable replication intervals. This fundamentally separates the

transaction processing data store from the historical data store for

high-performance event processing.

Data analysis can then be performed on the historical data, made available by

introducing DB2 Cube Views and accessing cubes from DB2 Alphablox

interface, which is the visualization module.

The database topology for the Monitor Server and Dashboard Server in a given

server environment may vary, for example:

򐂰 The Monitor Server runs on its own machine with the State and Repository

databases.

򐂰 The Monitor Dashboard runs on a separate machine using WebSphere

Application Server and Portal Server with the Runtime and History databases.

202 Moving Forward with the On Demand Real-time Enterprise

This setup is done for performance reasons. However, you may want the

Repository database on the Dashboard Server because the Monitor Server only

uses the Repository database at the time that you import a model. However the

Dashboard Server uses it frequently when configuring and displaying the

dashboards.

The Monitor uses a number of databases to store event information. Here is a

short description of the databases.

Repository database

The Repository database contains the metadata describing the currently

deployed business measures models as well as information about the other

Monitor databases. The Repository database contains the history of the

deployed models. There is only one Repository database per Monitor installation.

The Repository database is used by the Launchpad, which populates it with the

database attributes for the State, Runtime, and Historical databases. These

attributes are the database name, database schema, and host names of the

database server. They are used by the other Monitor components to access the

State, Runtime, and Historical databases at runtime. The Repository database is

also populated during the import of the business measures model.

State database

The State database stores information about running instances. This information

includes metrics, business measures, and key performance indicators (KPIs)

values. It is optimized for heavy transaction workloads. There is only one State

database per Monitor installation.

Each process instance requires two tables in the State database to store metrics,

business measures, and KPIs. The structure of these tables is as dynamic as the

structure of the process instance. Each business measure is represented by a

separate column in one of the two tables. Depending on the options selected

during the building of the business measures models, much or all of the

information in the State database is replicated to the Runtime database.

The State database is used by Monitor server. At runtime, the Monitor server

inserts, retrieves, and updates the information of processes instances that reside

in the State database, according to the processed events.

The State database stores the following information:

򐂰 Information about business measures groups, which is a part of the data in

the imported business measures models.

򐂰 The running process instances that are created while the Monitor is running.