Overview
WebSphere Business Monitor 6.0 monitors business processes at runtime by
monitoring event-emitting runtime engines. Only applications that are running on
WebSphere Process Server Version 6.0.1 are currently supported.
1、WBM通过监控event-emitting runtime engines来监控business processes at runtime。
2、WBM在一个model的基础上，通过收集events来计算KPIS
3、WBM能够通知用户，并且可以启动关联动作( alert, e-mail, cell phone, pager, and service invocation)
4、Models 是利用Business Measures editor建立的，可以指定measuring points and event filters，定义measurements, their correlations, and sources of the business data。 对每个model ，都可以指定KPIS ，event emission points, event filters, event composition rules, and situations 以便在runtime触发特定的动作。
Modeler to Monitor Closed
This data can be compared to the simulations that were performed in the
Modeler and hence, optimize the “as-is” business process model toward a more
efficient “to-be” model.
WebSphere Business Monitor architecture overview
Overview of WebSphere Business Monitor 6.0 internal components
Here is a list of the internal components:
_ Monitor server—Receives events, handles monitoring-context instances,
and stores and persists runtime and historical metrics and KPI values of those
instances.
_ Dashboards—Display the monitored data. They provide a predefined set of
views that can be customized to support different representations of data and
offer enhanced data analysis.
Schema generator—Generates database scripts to be used for creating
databases tables in state, runtime, and historical databases. These
databases contain the business measures models data. The schema
generator also generates the DB2 Cube Views™ metadata description of the
historical database and generates the metadata mappings for the replication
manager.
_ Databases—Provide the Monitor server with information for event
processing. They also provide the dashboard client with information for
populating views. Information is transferred across the databases through
another monitor component, the replication manager.
_ Adaptive action manager— Provides different types of business responses
resulting from situations expressed within the incoming events.
Overview of WebSphere Business Monitor 6.0 external components
Here is the list of the external components:
_ Business measures editor (BME)—It is used to create the business
measures model that defines what should be monitored, for example,
monitoring contexts, key performance indicators, metrics, and business
situations.
_ Common event infrastructure (CEI)—Provides event management by
receiving events from event sources and transferring them to the event
consumers that have expressed interest in those events.
_ DB2 Alphablox and DB2 Cube Views—Provide enhanced data analysis for
dashboards.
Monitor and CEI Topology
Monitor 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.
_ The event entries of the running processes. The event entry is the event data
that is received for updating a specific business measures group.
Runtime database
The Runtime database is similar in structure to the State database. It receives
replicated information from the State database about the current status of all
running processes as well as the final status of recently completed or failed
processes. This information is used by Monitor dashboards. The Runtime
database is also used by the Adaptive Action Manager to store alert notifications.
There is only one Runtime database per Monitor installation.
The information in the Runtime database is replicated from the State database.
The Runtime database stores:
_ Alert notifications sent by the Adaptive Action Manager to the dashboards
_ Process instance data
_ Metrics values
The Runtime database is used by the Monitor dashboards. The dashboards
retrieve the running or recently completed instances data required to populate
the views from the Runtime database. The dashboard views use the Runtime
database for analytical purposes, so it is optimized for query processing and
aggregate query processing.
All completed instances remain in the Runtime database for 24 hours and are
deleted afterwards. 24 hours is the default retention policy which can be modified
as part of the data movement service configuration.
History database
The History database stores all completed and running process instances. It is
used by the dashboards for enhanced data analysis using DB2 Alphablox. There
is only one History database per Monitor installation. The data in the History
database is never deleted.
The History database stores all completed and running process instances. It is
used by the dashboards for enhanced data analysis using DB2 Alphablox. There
is only one History database per Monitor installation. The data in the History
database is never deleted.
The History database should only contain two years worth of historical data. This
is one of Monitor product requirements. As mentioned before, the historical data
is never deleted automatically, so the DBA is responsible for deleting the data
that is greater than two years old.
The History database stores the information regarding long-running instances as
well as completed instances. This information is stored as star schemas rather
than in the flat transactional forms used in the State and Runtime databases. The
History database is optimized for aggregated and long running queries. It is used
by DB2 Alphablox in dashboards views to provide advanced multidimensional
reports.
The information in the History database is replicated from the Runtime database.
The History database contains dynamic tables that are created according to the
deployed business measures model. The schema generator generates the
History database schema, which is used to create dynamic tables, and Cube
Views definitions.
The History database is used by the Monitor dashboards. The dashboards
retrieve the data required to populate some views from the History database. For
example, the Reports view focuses on analyzing data extracted from the History
database.
Software Rquerments
