IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Developing monitor models > Debugging monitor models

Stepping through a running monitor model

In the debugger, you can set a breakpoint and then follow each of the steps as an event is processed and the monitor model runs.

Before starting the debugger, you must have a Monitor test environment server running in your development and test environment, either on Integration Designer or Rational Application Developer. The monitor model must have no errors in the Problems view.

You do not need to generate Java EE projects for the monitor model being debugged nor add the projects to the server.

To step through the monitor model:


Procedure

  1. Set a breakpoint or click Use Step Filters so that you can watch an event being processed.

    • To set a breakpoint, in the Detailed Steps list, right-click the left margin of the processing step in the Detailed Steps list where you want a breakpoint, and click Toggle Breakpoint.

      For example, set a breakpoint on the Evaluate filter condition step of the inbound event definition that your inbound event is expected to match. A breakpoint marker (

      ) is displayed in the left margin beside the step.

    • Alternatively, click Use Step Filters

      . If this button is clicked, the debugger suspends the processing flow whenever it reaches a correlation step. This step occurs after an event passes the filter and when it might result in the creation of a new monitoring context or the delivery of the event to one or more monitoring context instances or a KPI context instance.

  2. Emit an event. (See Sending events to the debugger for instructions.) The processing of the event is suspended at the first breakpoint, for example, at the filter condition evaluation step of the first inbound event definition.

    Remember: Processing happens sequentially. Processing starts with the filter condition for the first event definition, proceeds to the second event definition, and so on. Regardless of whether it satisfies the filter condition of one event definition, each incoming event is checked against all event definitions.

  3. Click Step Into

    or press F5 to evaluate the filter condition.

    • If the filter condition evaluates to false, the rest of the steps are skipped, and processing continues with the next inbound event definition.

    • If the filter condition evaluates to true, processing continues with the next step in the list of detailed steps.

  4. Click Step Into

    or press F5 to evaluate the correlation expression, which might result in the delivery of the event to one or more monitoring context instances or to a KPI context instance. If no matching instance is found, either because the event is the first event that is processed or because it failed to correlate with an existing instance, and the current inbound event definition is set to create an instance in this case, then a new instance is created and receives the event.

    • If the event is not delivered to any instances, the rest of the detailed steps are skipped, and processing continues with the next inbound event definition. Processing of the event is suspended at the filter evaluation step of the next inbound event definition. Return to Step 3.

    • If the event is delivered to at least one instance, continue with the next step.

  5. Continue to step through the detailed event processing steps for each instance that was identified as a receiver for the current event by correlation processing. At any time, you can click Resume

    or press F8 to let the processing continue to completion or until it reaches the next breakpoint.

  6. In the Variables view, inspect the content of the incoming event, and any metrics, KPIs, or measures in the monitoring context, KPI context, or cube that is currently updated.
    Metrics, KPIs, and measures are only visible after their values have been set.

    If the inbound event definition includes event parts, remember that the event part ID is a shortcut for a longer path referencing a part of the event. The event part ID is used in expressions throughout your monitor model to reference this event part. As expressions are evaluated, the path consisting of the inbound event definition ID and the event part ID (for example, myInboundEventDefinition/myEventPartID) is replaced by the full path to the event part (for example, cbe:CommonBaseEvent/wbi:event) as defined in the Event parts table of the inbound event definition.

    For example, if you have the following inbound event called CheckCustLevelENTRY with three event part definitions 

    <eventPart displayName="BaseData" id="BaseData" 
           path="cbe:CommonBaseEvent/wbi:event" type="wbi:Event"/>
<eventPart displayName="BPELData" id="BPELData" 
           path="cbe:CommonBaseEvent/wbi:event/wbi:eventPointData" 
           type="bpc:BPC.BFM.ACTIVITY.MESSAGE"/>
<eventPart displayName="Input" id="Input" 
           path="cbe:CommonBaseEvent/wbi:event/wbi:applicationData/
           wbi:content[@wbi:name='Input']/wbi:value" type="bo:TradeInfo"/>
    then CheckCustLevelENTRY/BPELData maps to cbe:CommonBaseEvent/wbi:event/wbi:eventPointData, which is the path you use to navigate the event content in the Variables view.

  7. In the Instances view, inspect any triggers. For a trigger, this view shows a field called <triggerID>_lastEvaluation, which holds the result of its last evaluation in this monitoring context. A non-repeatable trigger fires only when this value changes from false to true. A repeatable trigger ignores the outcome of any previous evaluations and so does not use this value.

    For a time-based trigger, the Instances view also shows a <triggerID>_nextEvaluation field, which holds the next time that the trigger will be evaluated. Each time an evaluation is performed, the evaluation time interval is added to this time value, which then shows the next time that an evaluation is due.


What to do next

After you have completed the detailed steps that update an instance, processing continues with the next inbound event definition. Each incoming event is checked against all event definitions in the model, which happens at run time. Rather than stepping into each step along the way, you can perform Step Over or Step Return actions. See Toolbar icons.

When the debugger encounters an event that it cannot correlate with a monitoring context instance, and the inbound event definition specifies Retry or Treat as error for no matching instances, you see a message in the monitor model debugger console indicating that the event is being sent to the retry queue (in the first case) or the error queue (in the second case). See "Working with event queues" for more information.

If you have an active monitoring context that sends outbound events, you can inspect the contents of the outbound events in the Variables view. To understand how outbound events are sent, see "Event flow."

Debugging monitor models