Working with Breakpoints
Breakpoints are stopping points used for debugging processes. You can set breakpoints on process steps. You cannot set breakpoints on pools, swimlanes, notes, annotations, gateways, or boundary events. These are not steps, and they do not run.
You can set breakpoints on the following step types:
Activities: task, subprocess, and call activity steps
Start events: None Start, Message Start, and Signal Start
Intermediate events: None Intermediate, Message Intermediate, and Signal Intermediate
End events: None End, Message End, Signal End, Error End, and Terminate End
Boundary events: Timer boundary events, both interrupting and non-interrupting. Timer boundary events support breakpoints and can be eligible steps.
Note: Other boundary events (message, error, signal) do not support breakpoints, and cannot be eligible steps. If you step over a message, error, or signal event, debugger stops on the step after it.
Breakpoints are visible in all perspectives. Once you set a breakpoint, you can enable, disable, or remove it using the context (right-click) menu in the process editor. You can also use the Breakpoints view to enable and disable a breakpoint, remove one or more breakpoints, and skip all breakpoints.
You can set, enable, disable, or remove breakpoints at any time before or during debugging. The active process in the editor is automatically updated. The process debugger evaluates breakpoint information immediately prior to executing a step. Breakpoint settings are stored in the workspace, and persist across Designer sessions.
You can use breakpoints to help debug looped call activities and BPMN subprocesses. For example, you can set a breakpoint inside of a BPMN Subprocess (not on the subprocess step itself). When you reach the breakpoint, the process debugger opens the BPMN Subprocess and stops there. You can then click Run/Resume to loop around once and stop at that breakpoint again. Finally, from the inside of a looped BPMN Subprocess step, click Step Out to complete all remaining iterations of the loop and stop at the next step.
The process debugger does not stop on an intermediate start step (a receive step, for example) unless you set a breakpoint on it. If a process thread starts from an intermediate start step, the debugger runs through the thread to its completion by default if no breakpoint is set on the start step.
While you are stopped at a breakpoint, you can select the step in the Trace view and review the data in the Pipeline Data view. Click any of the enabled buttons in the Trace view to resume your debugging session.
When you set and enable a breakpoint on a subprocess or call activity step, the process debugger stops before entering the step, but it does not stop before exiting the step. You cannot set or enable a breakpoint at the end of a subprocess or call activity.
When you step over a child process (of a call activity step) in the course of debugging its parent process, and the child process contains an enabled breakpoint, the process debugger opens the child process in a new process editor tab and stops at the breakpoint. The Trace view and the process editor reflect the current step status.