IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Developing monitor models > Create monitor models > Generate monitor models > Generate from applications in the workspace

Results of generating monitor models from IBM BPM Advanced and WebSphere Enterprise Service Bus applications

Events that are emitted from IBM BPM Advanced and WebSphere Enterprise Service Bus applications contain both static and dynamic content.

The events are made up of the following types of content:

For each inbound event, the correlation expression determines the monitoring context instances to which the event will be delivered. When you generate models at the module level, the correlation expression uses the session ID to keep track of instances. Each event has a session ID so that it can be tied back to the module instance. Different components use different types of correlation. For BPEL components, you can track each instance and even each activity instance separately. Other kinds of components, however, do not have that level of correlation.

For example, all business rules emit the session ID but no other differentiating information, so you cannot differentiate between two invocations of the same business rule based on an ID value.

The filter for each inbound event contains information that uniquely identifies the event and associates it with a particular event source. For SCA events, the filter condition is based on the name of the operation and the event nature.

For example, you might be interested in an inbound event when the check credit operation is called and the event nature is ENTRY, which means the check credit interface started. For BPEL events, the filter condition is based on the process template name and, if the process has a valid from field defined, this field is also referenced in the filter. Events emitted by BPEL activities also use the ID for the activity as part of the filter condition.


Terminating your monitoring context when monitoring BPEL applications

The generated monitor model is configured to terminate when the DELETED event arrives rather than when the EXIT event arrives, because a process instance can be restarted after it has exited.

BPEL processes are often set up to delete as soon as they have exited, in which case the events occur one after the other. For a long-running BPEL process, the default setting is Automatically delete the process after completion, which sends both events.

However, if this behavior is not what you want, you can identify the event that signals when a process instance is terminated and add a trigger to terminate the process when the event arrives.

In the following situations, it might be better to use the EXIT event rather than the DELETED event to terminate your monitoring context:

Either edit the trigger that has Terminate monitoring context selected and add the EXIT event to the table of trigger sources, or create a new trigger that fires when an EXIT event arrives and select the Terminate monitoring context check box.


Inbound events generated from WebSphere ESB applications

When you are generating models from WebSphere ESB applications, you can select templates and events at the SCA level that work as previously described. Beyond that level, you will see an event for each event emitter primitive that you use in your mediation flow.

The information that comes from the event emitter primitive is based on the XPath expression that you write in the root attribute of the event emitter primitive on the Details properties page. See "Event Emitter mediation primitives" in the WebSphere Enterprise Service Bus information center for more information.


Events that can carry business payload

Business payload is dynamic content that is determined by the objects or data flowing through the system. The following events can carry business payload:

Generate monitor models from applications located in the workspace