IBM BPM, V8.0.1, All platforms > Authoring services in Integration Designer > Developing monitor models > Debugging monitor models
Manage breakpoints
At a breakpoint, the processing flow is suspended so that you can see the effects of each low-level step from this point on. Click the Step Into icon on the toolbar or press F5 to proceed in single-step mode, or click the Resume icon to resume uninterrupted processing until another breakpoint is reached, or until all events in the input queue have been processed.
You can turn breakpoints on and off while the debugger is running.
For example, you can add breakpoints if you determine you need to view additional event processing after you have started debugging the model.
Where you set breakpoints depends on the problem you are debugging.
- No monitoring context instances are being created.
- In the High-Level Steps list, find the event definition for the event that you expect to create new monitoring context instances.
Set a breakpoint on the Evaluate filter condition in the Detailed Steps list. When you send the event to the debugger, you can check to see if the event is satisfying the event filter condition.
If not, then that is why no instance was created, and either the filter expression or the event content must be modified. If the event satisfies the filter condition, but correlation processing does not create a new instance, then either the correlation setting for no match is not set to "create new instance," or there is already an instance that matches the event.
- A trigger does not fire.
- In the Detailed Steps list, set a breakpoint at the detailed step
representing the trigger evaluation, and also at the Evaluate
filter condition step that precedes it. Processing any
event will be suspended at the filter step, and you can find out if the event that should cause the trigger to fire is blocked here already.
If not, you can advance to the next breakpoint and look at the event and context instance data that is used in the trigger condition. If the condition evaluates to false, then either that data, or the condition itself, must be corrected. If the trigger is non-repeatable, the cause might also be that it fired already. It will fire again only after its condition evaluates to false at least once.
- To set a breakpoint, right-click the left margin of the processing step in the Detailed Steps list where you want a breakpoint, and click Toggle
Breakpoint, or just double-click the margin. After you have set a breakpoint, a breakpoint marker (
) is displayed in the left margin beside the step.
- To turn off a breakpoint without removing it, right-click the breakpoint marker, and click Disable Breakpoint.
- To make a breakpoint active again, right-click the breakpoint marker, and click Enable Breakpoint.
- To remove a breakpoint, right-click the breakpoint marker, and click Toggle Breakpoint
The Breakpoints view displays all the breakpoints you have set. Breakpoints that have been set for other executable files in your workspace, such as Java™ programs, are also visible in this view but have no effect while you are debugging a monitor model. You might want to use the View menu (
) on the toolbar of the Breakpoints view to group the breakpoints in different ways (by files, projects, and so on) to make the list of breakpoints more manageable.
You can remove, disable, or enable individual breakpoints in this view. You can also remove or skip all breakpoints.
By default, the debugger pauses
at every KPI context and cube with measures even though no breakpoints
are set in the Breakpoints pane. Click Use Step Filters 
to turn this feature on or off.