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:
- Static content with a structure that is the same for every event emitted by a given kind of component.
For example, every Business Process Execution Language (BPEL) process emits information such as processTemplateName and processTemplateValidFrom. The structure of this information is defined by predefined XML Schema Definition (XSD) files.
- Dynamic content that is determined by the objects or data flowing through the system. This information is typed by user-defined XSDs available in Integration Designer. Only certain events can contain this information, which is often called the business payload. (See Events that can carry business payload for further information.) When you are generating a monitor model from an application, these events are shown with a
flag and package icon, and events that can never carry business information are shown with a
flag icon. When an inbound event is based on an event that carries business payload, an event part that describes the type of the business payload is created within the inbound event in the monitor model.
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:
- Your BPEL process is not marked as long-running.
- Your BPEL process is marked as long-running, but you set Automatically delete the process after completion to No.
- You know that your process is not going to be restarted once it exits.
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:
- SCA events
- WBI.SCA.MethodInvocation.ENTRY
- WBI.SCA.MethodInvocation.EXIT
- WBI.SCA.MethodInvocation.FAILURE
- BPEL events
- BPC.BFM.PROCESS.EVENT
- BPC.BFM.ACTIVITY.MESSAGE
- BPC.BFM.VARIABLE.STATUS
- Human task events
- BPC.HTM.TASK.MESSAGE
- Business rule group events
- WBI.BR.ENTRY
- WBI.BR.EXIT
- WBI.BR.SelectionKeyExtracted
- Selector events
- WBI.SEL.ENTRY
- WBI.SEL.EXIT
- WBI.SEL.SelectionKeyExtracted
- Interface map events
- WBI.MEDIATION.OperationBinding.ENTRY
- WBI.MEDIATION.OperationBinding.EXIT
- WBI.MEDIATION.OperationBinding.FAILURE
- WBI.MEDIATION.ParameterMediation.ENTRY
- WBI.MEDIATION.ParameterMediation.EXIT
- WBI.MEDIATION.ParameterMediation.FAILURE
- Business Object (BO) map events
- WBI.MAP.ENTRY
- WBI.MAP.EXIT
- WBI.MAP.FAILURE
- WBI.MAP.Transformation.ENTRY
- WBI.MAP.Transformation.EXIT
- WBI.MAP.Transformation.FAILURE
- Message flow (MFC) events
- WESB.ESBEventMediation.CUSTOM
- Activity events inside all components
- ActivityEventEmitter.CUSTOM
- Business State Machine
- none
Generate monitor models from applications located in the workspace