IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Developing monitor models

Create monitor models

To create a monitor model in the Monitor Model editor, you first create a business monitoring project and then create a monitor model. The monitor model contains a monitor details model, key performance indicator (KPI) model, dimensional model, visual model, and event model.

The following steps provide an overview of the procedure for creating a monitor model:

Procedure

1. In the Business Monitoring perspective, create a business monitoring project in the Project Explorer view. See Create business monitoring projects.

   Select other projects to reference from this project as a source of event definitions. Event definitions can be in XML Schema Definition (XSD), Web Services Description Language (WSDL), or Common Base Event files.

   If you are monitoring an event source other than a Process Server application, first import the event definitions that describe the events that are emitted by the runtime system to be monitored. Once those event definitions are available, you can create a monitor model with inbound events for each of these definitions and further refine your monitor model to extract the relevant information from the events as they arrive at run time.

2. Create or import a monitor model (.mm file). The new monitor model is shown in the Project Explorer view, along with the imported event definitions.

   WebSphere Business Modeler can be used to create a preliminary monitor model with high-level information (such as KPIs and business-relevant metrics) and process diagrams that can be viewed in Business Space. See Importing monitor models from IBM WebSphere Business Modeler.

   Integration Designer can be used to generate a monitor model with low-level information such as event definitions, inbound events, and correlation expressions.

   See Generate monitor models

3. Define the monitor details model as follows:
   1. Define monitoring contexts. Decide on the number and structure of the monitoring contexts required. In general, start with one monitoring context and create more as the need arises during modeling. See Defining monitoring contexts.
   2. Define inbound events and associate them with the event parts or event definitions that you added in step 1. See Defining inbound events for monitoring contexts.
   3. Define keys for the monitoring contexts. Determine the piece or pieces of information that characterize the monitored entity that a monitoring context is associated with, and define its keys so that they can hold these identifiers.

      For example, a monitoring context for an approval process might be characterized by the workflow engine's process instance identifier and a monitoring context for order tracking might be characterized by an order number. See Defining keys.

   4. To identify events of interest and associate them with the correct monitoring context instances, complete the filter conditions and correlation expressions for the inbound events. See Defining inbound events for monitoring contexts.

   5. To detect any special conditions relevant to the business domain, define triggers. You can specify when the trigger condition is evaluated. The trigger will fire when the condition evaluates to true.

   6. To process information from the events, define metrics, counters, and stopwatches. Define when counters and stopwatches are updated, and add the expressions used to calculate metric values. See Defining metrics.
   7. Define outbound events if required. Outbound events can be received by any event-processing application, or an outbound event from one monitoring context can be an inbound event to another monitoring context or to a KPI context. Outbound events can also be received by the Monitor action services to generate alerts, or you might find it more convenient to create alerts directly in the dashboards. Based on each trigger that can cause the outbound event to be sent, specify the values to assign to each event attribute. See Defining outbound events for monitoring contexts.
4. Define the KPI model by creating a KPI context and then creating KPI definitions. Specify the initial targets and ranges to affect the display options in the dashboard. Select whether each KPI is based on a metric and aggregation function or on a calculation based on other KPIs. See Defining key performance indicators (KPIs).

5. If you plan to perform dimensional analysis, define the dimensional model to aggregate information across monitoring context instances. See Defining dimensional models.

• Tools for monitor model editing
  The IBM Business Monitor development toolkit provides the tools for creating monitor models for use with IBM Business Monitor. Monitor models are XML documents that specify how information should be extracted from Common Base Events at run time and collected, combined, and stored for representation on a dashboard.
• Setting the business calendar type
  Business calendar types, such as a Gregorian calendar or Hijri (Islamic) calendar, provide an environment for your business calendar functions. Business calendar types are set on the Preferences page.
• Create business monitoring projects
  Before you create or import a monitor model, create a business monitoring project. Business monitoring projects are shown in the Project Explorer view. Each business monitoring project can contain monitor models, event definitions, and Scalable Vector Graphics (SVG) files. Files with the extension .mm are categorized as monitor models, and files with the extensions .xsd (XML Schema Definition), .wsdl (Web Services Description Language), or .cbe (Common Base Event) are categorized as event definitions.
• Defining monitor models
  The monitor model is the top-level container. Except for event type definitions and Scalable Vector Graphics (SVG) diagrams, it contains all the parts that will go into Business Monitor: the monitor details model, the key performance indicator (KPI) model, the dimensional model, the event model, and the visual model.
• Defining monitor details models
  The monitor details model contains the monitoring context definitions, which are containers for inbound event definitions (or event subscriptions), outbound event definitions (that is, events to be sent), and definitions for metrics, stopwatches, counters, and triggers.
• Defining KPI models
  The key performance indicator (KPI) model defines KPI contexts, which group KPIs with their associated triggers and events. To send outbound events based on the value of the KPI relative to its target or ranges, create triggers and outbound events in the KPI context.
• Defining dimensional models
  When you define a monitoring context, an associated cube definition is created automatically. On the Dimensional Model page, you can add measures, dimensions, and dimension levels to the cube.
• Tips and techniques for writing expressions
  Use the following tips and techniques when writing XML Path Language (XPath) expressions for metric and outbound event values, trigger conditions, inbound event filters, and so on.
• Authoring XPath functions
  XML Path Language (XPath) expressions are widely used in monitor model programming to define maps, trigger conditions, filters, correlation predicates, and default values. User-defined XPath functions can be implemented as specially annotated Java™ methods. You can use these XPath functions in the same way you would use any built-in XPath function within an expression. You can develop user-defined XPath functions through a Java project in Rational Application Developer or Integration Designer.
• Importing monitor models from IBM WebSphere Business Modeler
  

  You can optionally start your monitor model by importing a monitor model from WebSphere Business Modeler. The monitor model can contain business-relevant key performance indicators (KPIs), metrics, and measures as well as Scalable Vector Graphics (SVG) diagrams of the process or processes.

• Generate monitor models
  To monitor applications, you can generate monitor models from applications that are created in Integration Designer. You can also add application elements from an application to a monitor model at any time, which means that you can refine your monitor model alongside the application. Monitoring constructs can be added to the model as new pieces are added to the application.
• Manage event definitions
  The runtime environment emits events. You create an inbound event for each event definition that corresponds to an event that you want to monitor. You further refine your monitor model to extract the relevant data from the events as they arrive at run time. You might also define outbound events to send alerts or to communicate between models. You can refer to event definitions in another project or import event definitions from the file system into the monitor model project.
• Defining the visual model
  

  You can associate a Scalable Vector Graphics (SVG) diagram with a monitoring context or key performance indicator (KPI) context.

  You can then annotate these diagrams in the Monitor Model editor so that they are dynamically updated at run time. Each diagram is associated with a set of shapes and a set of actions describing how and when the diagram will be modified based on the values of metrics (in a monitoring context) or KPIs (in a KPI context). The actions include color changes and text displays based on the values, as well as hyperlinks from areas of the diagram so that you can navigate to other diagrams.

• Combining or merging monitor models
  

  You can choose to combine two unrelated models or have them communicate through events. You can also merge an updated or changed model with an earlier version.

• Create new monitor model versions
  

  If you have an existing monitor model that monitors an existing application and business process, you can create a new version of the monitor model to monitor the application regardless of whether the application and business process are currently versioned.

• Sharing assets
  When you want to share the BPM artifacts created, store them in a central repository that you and others can browse.

  For example, you want to be able to find and reuse the approved version of a process model even if someone else created it. With the asset repository, you can do just that.

Developing monitor models

Related information:

Manually authoring a monitor model