Integration options

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
Integration options

If in addition to exporting monitor model files from WebSphere Business Modeler using the IBM Business Monitor development toolkit export option, you also exported a model from WebSphere Business Modeler to use as the basis for a Process Server application, you can complete the application in Integration Designer and then generate a monitor model. You then have several options for integrating the two models.
If you exported the monitor model or models from WebSphere Business Modeler using the IBM Integration Designer export option, the models are already integrated and this information is not applicable.
For detailed information on generating monitor models from applications, see Generate monitor models.
After you have generated a monitor model from your application, you have two monitor models:

High-level model. This is the business-level monitor model that you exported from WebSphere Business Modeler and then imported into the Monitor Model editor.
Low-level model. This is the IT-level monitor model that you generated from the Integration Designer application that implements the business process designed in WebSphere Business Modeler.

To develop a monitoring solution that makes use of the information in both these models, you have the following options for integrating the models:

Keep both monitor models and have them communicate through events.
Keep only the high-level monitor model and update it with runtime events.
Keep only the low-level monitor model and update it with business measures.

Option 1: High-level and low-level models communicate through events

If you select this option, both monitor models are kept and used in the solution. The two monitor models communicate through custom events that are sent by the low-level model and received by the high-level model. This option is the most flexible and as a result is also the most complicated.
The following table shows the advantages and disadvantages of this option.

Advantages Disadvantages
Limits the impact of changes to either the business measures or the underlying process implementation by affecting only the low-level or high-level model Requires the authoring of event definitions to serve as the communication vehicles between models
Maintains the link to the runtime application for the low-level model Takes time to develop and can result in seemingly unnecessary steps for simple cases
Supports comparing and merging to reconcile changes if you import a new version of the high-level model from WebSphere Business Modeler
Supports deployment configurations where the low-level and high-level models are separate or together
You can keep the monitor models in separate projects or combine them in one project (see Combining monitor models). For more details on this option, see Connecting low-level and high-level models.
If you exported the monitor model from WebSphere Business Modeler using the IBM Integration Designer export option and chose to generate two monitor models, one containing the business measures from WebSphere Business Modeler and the other containing the events from Integration Designer, the event for communicating between the models is created for you.

Option 2: High-level model is updated with runtime events

If you select this option, you keep only the high-level monitor model and update it with runtime events. This option is most useful when the low-level application is stable but the business measures requirements are changing. It is best to use this option only when there are a small number of events of interest that carry the majority of the information required.
With this option, you add inbound events of interest directly to the high-level monitor model produced by WebSphere Business Modeler, using New > Create from Application (see Adding application elements to monitor models).
You then copy and paste each of the events from the generated monitoring context into the top-level monitoring context.
You might need to adjust the generated filter condition and correlation expressions for some of the copied events. Typically you will be able to keep the filter condition, which is designed to isolate the given event from all of the other events that are emitted by the Process Server application. The correlation expression that is generated compares some or all of the ECSCurrentID, ECSParentID, and WBISESSION_ID values in the event to a key representing the module instance ID, process instance ID, activity instance ID, and so on. If you have created a key in the high-level model that does not correspond to any of these pieces of information, for example, by using an OrderID, you must modify the correlation expression of the copied event to compare the OrderID value in the monitoring context with the value contained in the event.
The following table shows the advantages and disadvantages of this option.

Advantages Disadvantages
Removes the need to create and manage any communication events to transmit information between monitoring contexts Removes the link between the monitor model and the application for the events that were copied and pasted. Refactoring changes in Integration Designer can no longer be automatically applied. The Synchronize with Application feature can no longer be used to keep the models synchronized.
Results in a simple monitor model that is easily understood Might require updating of the correlation predicate (and possibly filter condition) of the copied inbound event
Supports comparing and merging to reconcile changes if you import a new version of the high-level model from WebSphere Business Modeler

Option 3: Low-level model is updated with business measures

If you select this option, you keep only the low-level monitor model and update it with business measures. This option is most useful when the business measures requirements are stable, but the low-level application is changing. It is best to use this option only when there are a small number of business measures to be monitored.
You copy the metrics, KPIs, and anything in the dimensional model from the high-level model to the low-level model.
You specify tracking keys in the low-level model generated from Integration Designer for any business measures whose values are to be imported into WebSphere Business Modeler to update simulation attributes. You write your own tracking keys in the model (see Returning results to WebSphere Business Modeler using tracking keys).
The following table shows the advantages and disadvantages of this option.

Advantages Disadvantages
Removes the need to create and manage any communication events to transmit information between monitoring contexts Does not support comparing and merging to reconcile changes if you import a new version of the high-level model from WebSphere Business Modeler
Results in a simple monitor model that is easily understood You cannot copy and paste the contents of the visual model from the high-level model to the low-level model. (But you can cut and paste the SVG files.)
Maintains the link between the monitor model and the application, so you can still keep them synchronized using refactoring changes in Integration Designer and the Synchronize with Application feature in the Monitor Model editor.

Importing monitor models from IBM WebSphere Business Modeler

Advantages	Disadvantages
Limits the impact of changes to either the business measures or the underlying process implementation by affecting only the low-level or high-level model	Requires the authoring of event definitions to serve as the communication vehicles between models
Maintains the link to the runtime application for the low-level model	Takes time to develop and can result in seemingly unnecessary steps for simple cases
Supports comparing and merging to reconcile changes if you import a new version of the high-level model from WebSphere Business Modeler
Supports deployment configurations where the low-level and high-level models are separate or together

Advantages	Disadvantages
Removes the need to create and manage any communication events to transmit information between monitoring contexts	Removes the link between the monitor model and the application for the events that were copied and pasted. Refactoring changes in Integration Designer can no longer be automatically applied. The Synchronize with Application feature can no longer be used to keep the models synchronized.
Results in a simple monitor model that is easily understood	Might require updating of the correlation predicate (and possibly filter condition) of the copied inbound event
Supports comparing and merging to reconcile changes if you import a new version of the high-level model from WebSphere Business Modeler

Advantages	Disadvantages
Removes the need to create and manage any communication events to transmit information between monitoring contexts	Does not support comparing and merging to reconcile changes if you import a new version of the high-level model from WebSphere Business Modeler
Results in a simple monitor model that is easily understood	You cannot copy and paste the contents of the visual model from the high-level model to the low-level model. (But you can cut and paste the SVG files.)
Maintains the link between the monitor model and the application, so you can still keep them synchronized using refactoring changes in Integration Designer and the Synchronize with Application feature in the Monitor Model editor.