Building Monitor models using the Model Editor

The Monitor Model editor is heavily dependent on XPath expressions.

It uses a number of namespaces. The common prefixes for these namespaces are show below as well as their expanded values. The expanded values are needed when building models that have data types of QName.

|| |Prefix|Namespace| |mon|| |wle|| |bpmn|| |bpmnx||

See also:

Monitor Process Start event

When a Process instance is started, an event is generated. The mon:kind has the value bpmnx:PROCESS_STARTED. An example of the event is shown below:

<mon:monitorEvent ...> <mon:eventPointData> <mon:kind mon:version="2010-11-11">bpmnx:PROCESS_STARTED</mon:kind> … <mon:model mon:type="wle:processApplication"> <mon:name>ProcessAppName</mon:name> … </mon:model>

Something is wrong here. Using just this algorithm below, we would capture ALL Process Starts not just the ones we are interested in modeling.

A suitable Monitor Model inbound event definition would have:

|| |Event Type Details| |- - - | || |Filter Condition| |xs:string(PROCESS_STARTED_Event/EventPointData/mon:kind) = '{}PROCESS_STARTED'| || |Correlation Expression| |PROCESS_STARTED_Event/EventPointData/mon:correlation/wle:starting-process-instance = piid|

Here we assume that the key for the MC is called piid and is configured:

|| |Key Value Expressions| |PROCESS_STARTED_Event/EventPointData/mon:correlation/wle:starting-process-instance|

Correlating BPMN process events


Monitor Tracking point data

When a tracking point is reached in a BPD, a bpmnx:EVENT_THROWN is generated.

The body of the event contains the name of the tracking group plus the values of the tracking group parts.

Here is an example of the event edited for clarity:

<mon:monitorEvent> <mon:eventPointData> <mon:kind mon:version="2010-11-11">bpmnx:EVENT_THROWN</mon:kind> <mon:time mon:of="occurrence">2011-07-03T11:40:52.778-05:00</mon:time> <ibm:sequenceId>0000000007</ibm:sequenceId> <mon:model mon:type="bpmn:intermediateThrowEvent" mon:id="bpdid:56d35..." mon:version="2064.d9d1e..."> **<**mon:name>Untitled1</mon:name> <mon:instance mon:id="4"></mon:instance> </mon:model> … </mon:eventPointData> <mon:applicationData> <wle:tracking-point wle:time="2011-07-03T11:40:52.779-05:00" wle:name="Untitled1" wle:id="ded130..." wle:version="2064.d9d1e3..." wle:groupName="sale2" wle:groupId="18e915..." wle:groupVersion="2064.d9d1e3..."> <wle:tracked-field wle:name="usState" wle:id="09d4da..." wle:type="xs:string">TX</wle:tracked-field> <wle:tracked-field wle:name="saleDate" wle:id="08365..." wle:type="xs:dateTime">2011-07-22T05:00:00.00Z</wle:tracked-field> </wle:tracking-point> </mon:applicationData> </mon:monitorEvent>

The XPath to get a named tracking data field is:


Here is a suggested set of inbound event details.

|| |Event Type Details| |- - -

      • | || |Filter Condition| |xs:string(TRACKING_GROUP_name/EventPointData/mon:kind) = '{}EVENT_THROWN' and xs:string(TRACKING_GROUP_name/EventPointData/mon:model[1]/@mon:type) = '{}intermediateThrowEvent' and TRACKING_GROUP_Sale2/TrackingPoint/@wle:groupName = 'name'| || |Correlation Expression| |TRACKING_GROUP_name/EventPointData/mon:correlation/wle:starting-process-instance = piid|

The way to read this inbound event is that it is the tracking group we are looking for if all of the following are true:

A metric can then be populate from the Inbound event with the expression:

|| |Metric Value Expressions| |TRACKING_GROUP_name/TrackingPoint/wle:tracked-field[@wle:name = 'field']|

Take care not to populate fields when there is no data present. One solution is to create a trigger from the inbound event and associate a condition with that trigger so that it only fires if the field is present. We can then use the trigger as the indicator that a metric should be updated.

See also:

Closing the Monitoring Context

When a BPD completes, it should close the associated monitoring context. The completion of the process is detected by an event having mon:kind set to bpmnx:PROCESS_COMPLETED. An example fragment of the data is shown next:

<mon:monitorEvent ...> <mon:eventPointData> <mon:kind mon:version="2010-11-11">bpmnx:PROCESS_COMPLETED</mon:kind> …

Example monitoring definitions:

|| |Event Type Details| |- - - | || |Filter Condition| |xs:string(PROCESS_COMPLETED_Event/EventPointData/mon:kind) = '{}PROCESS_COMPLETED'| || |Correlation Expression| |PROCESS_COMPLETED_Event/EventPointData/mon:correlation/wle:starting-process-instance = piid|

A Trigger is required to close the context:

|| |Trigger Sources| |Source: PROCESS_COMPLETED Event| || |Trigger Condition| |N/A|

Removing monitor 'Problems' view errors and warnings

By default, the Monitor Model editor shows warnings in the Problems view. These messages are not needed.

When building Monitor models, a series of superfluous warning messages are logged in the Problems view. These messages can distract from more significant issues. These warnings can be disabled in ID through:

Window > Preferences > Java > Compiler > Errors/Warnings

From there, switch the relevant types of warning from "Warning" to "Ignore" and the messages/warnings are removed.

Code style

Potential programming problems

Deprecated and restricted API

Unnecessary code


The generated J2EE projects can also cause warnings to be written. These can also be switched off. In ID go to

Window > Preferences > Validation

From there, switch off (uncheck) the entries next to:

Page 5

No Comments
Back to top