IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Developing monitor models > Create monitor models > Importing monitor models from IBM WebSphere Business Modeler

Results of importing monitor models exported from WebSphere Business Modeler

When you export monitor models from WebSphere Business Modeler, a monitor model is created for each top-level process. Each monitor model contains a root element that contains some elements of the monitor details model, dimensional model, KPI model, visual model, and event model.

There are three types of export you can do through WebSphere Business Modeler:

• Export the monitor model separately using the IBM Business Monitor development toolkit (.mm)
• Export the monitor model along with a Process Server application using the IBM Integration Designer export option, creating one monitor model for each process
• Export the monitor model along with a Process Server application using the IBM Integration Designer export option, creating two monitor models for each process, a high-level model and a low-level model.

Monitor details model

Regardless of which export option you chose, the following elements are created in each monitor model:

• A monitoring context for each of the following elements:

  • The top-level process
  • Each loop node in the process
  • Each local subprocess node in the process

  Each monitoring context is associated with a Scalable Vector Graphics (SVG) representation of the process, loop, or subprocess diagram.

• A metric for each instance metric that is defined in the Business Measures view in WebSphere Business Modeler.

• A metric for each data filter that is selected for a key performance indicator (KPI) in WebSphere Business Modeler (unless already created).

• A trigger for each alert on a metric that is specified in the monitor model. Outbound events that cause alerts can only be sent based on triggers.

Dimensional model

A cube is created for each monitoring context. The cube contains the following additional items specified for the given monitoring context:

• A measure for each aggregate metric that is defined in the Business Measures view in WebSphere Business Modeler.

• A dimension for each dimension specified in WebSphere Business Modeler, with a single dimension level of the same name.

If a measure is created to track a real-life value to return to WebSphere Business Modeler. the measure contains a tracking key to identify how this piece of information should be added to the WebSphere Business Modeler model when it is returned. (If you need to create your own tracking key, see Returning results to WebSphere Business Modeler using tracking keys.)

KPI model

Within each monitor model, the following elements are created:

• A single KPI context.

• A KPI for each KPI defined in the Business Measures view in WebSphere Business Modeler. The target, range, and time period information are taken from the KPI definition. (The time information will not be active until you add a valid metric.)

• A trigger for each alert on a KPI that is specified in the monitor model. Outbound events that cause alerts can only be sent based on triggers.

Visual model

A visualization is created for each monitoring context and the single KPI context. Each visualization contains an <import> reference to a Scalable Vector Graphics (SVG) diagram (in a separate SVG file) that is also produced on export.

The SVG diagram associated with each monitoring context consists of the WebSphere Business Modeler process diagram for the process, local subprocess, or loop. The SVG diagram associated with the KPI context consists of the WebSphere Business Modeler process diagram for the process.

Any diagrams that contain a local subprocess or loop node are configured so that the shape representing the plus (+) sign on the node will link to the visualization associated with that node, so that a dashboard user can click the diagram and drill down into process diagram elements.

The individual SVG elements that are created to represent single conceptual units in the process diagram (such as a task node with its labels) are collected into shape sets. Each shape set has a name and an ID that is associated with the monitor model namespace. Each shape set can be associated with actions describing how the diagram will be modified at run time (see Defining the visual model).

Event model

If you did not choose the IBM Integration Designer export option, an empty event model is created. To add events, you can export the corresponding Business Process Execution Language (BPEL) process from WebSphere Business Modeler. Then either import the events from the BPEL process into your model, or generate a monitor model from the BPEL process and create event definitions that carry the specific information required by the WebSphere Business Modeler monitor model.

Additional elements created for Integration Designer implementation

If you exported the monitor model along with a Process Server application, using the IBM Integration Designer export option, additional elements are created. In addition to all the elements already described, the following elements are also created:

• Inbound event definitions for the events that will be monitored in the Process Server application
• Monitoring elements required to apply the templates for any instance metrics that were based on predefined business measure templates in WebSphere Business Modeler
• Metrics implemented with expressions that define their values based on information from the Process Server application
• Keys for each monitoring context using the process and activity IDs

If you chose to create two monitor models, one containing the business measures (the high-level model) and the other containing the events from Integration Designer, the two models communicate through an event that is sent from the low-level model to the high level model. The following elements are created to support this communication:

• In the low-level model (which receives the events from Integration Designer):
  • Communication Event - the outbound event that is sent to communicate with the high-level model. This event is created for each process, loop, and subprocess.
  • Communication Update Trigger - the trigger that causes the outbound event to be sent whenever any of the relevant metrics change as the Process Server application runs. This trigger is created for each process, loop, and subprocess.
  • Recurring Update Trigger - the trigger that fires every minute to retrieve the values of stopwatches and send those values to the high-level model. This trigger is only created if a stopwatch is required (for example, for tracking the working duration of the process or an activity). This trigger is created for each process, loop, and subprocess.
  • Event Sequence counter - the counter that gives each Communication Event a sequence number to help the high-level model receive the events in the correct order

• In the high-level model (containing the business measures from WebSphere Business Modeler):
  • Communication Event - the inbound event that receives the event from the low-level model
  • Termination Trigger - the trigger that terminates the high-level monitoring context when the Communication Event indicates that the process instance has terminated

If a nested monitoring context is created to monitor the individual activities within a process, all metrics relating to the business measures defined in WebSphere Business Modeler for that activity appear twice in the monitor model: once in the nested (activity) monitoring context and again in the parent (process) monitoring context. This duplication ensures that any measures at the activity level are created in the cube at the process level, so that dimensional analysis of the process and its activities can be done together in the Business Monitor dashboards.

Importing monitor models from IBM WebSphere Business Modeler