About Process Debugging

When you debug a process model, you can inspect the way it behaves with real data, and see how that data behaves as it travels through the process. You can control your navigation through process steps, and see the progress of those steps, including errors. You can choose to debug a process in two ways:

Based on the process design and the input data, Designer identifies the next eligible step or steps to run. When there are multiple eligible steps, you can select the one to execute next. You can also take the default step, which is selected by the debugger and outlined in the process editor.

You control the debugging session with the buttons on the Trace view toolbar. Step navigation buttons allow you to select the way in which you want to interact with steps: step in, step over, and step out. For more information, see Navigating Steps during Debugging and About the Trace View.

The process editor displays debug status symbols that reflect this progress, and the views in the Process Debug perspective provide additional supporting functionality, as described in the following table:

Process Debugging View	Description
Trace view	The Trace view displays details of each step in a debugging session in a tabular form and contains a toolbar you use to control the session in the active process editor tab. You can select a row that corresponds to a step in the Trace view to inspect the corresponding pipeline data output in the Pipeline Data view. You can also view and capture exception data. See About the Trace View.
Pipeline Data view	The Pipeline Data view displays the pipeline data associated with the output of the process step selected in the Trace view. You can expand the information to see more details of the data from the pipeline for the selected step, enabling you to troubleshoot the process at the step level. You can also copy the pipeline of one or more steps. See About the Pipeline Data View.
Breakpoints view	The Breakpoints view displays all breakpoints in your workspace. It also allows you to manipulate breakpoints. See About the Breakpoints View.

The process debugger requires that your process start with a minimum of one receive step with an Integration Server document type input. Multiple receive steps, using correlation to join the process, and multiple input documents are also supported. For more information, refer to Debugging an Intermediate Receive Step.

Note:
When you debug a process whose receive step trigger uses the JMS or EDA (deprecated) protocol, Designer checks the Integration Server used by the receive step to ensure the connection alias exists and is enabled, before attempting to debug the process.

The process debugger requires an enabled process. Designer does not automatically enable uploaded processes, but you can set a Build and Upload preference to automatically enable a process. For more information, see About Enabling Processes. You can also set a Process Debug preference to automatically enable a process being debugged, and optionally to automatically disable it again when you have finished debugging. For more information, see Configuring Process Debug Preferences and Configuring Build and Upload Preferences.

When you start debugging a process, Designer can prompt you to enter data input for the receive step or steps. You can save entered data in XML form for reuse, save different versions of the data, and load the XML from a file in subsequent sessions.

Symbol	Step status
	Completed
	Eligible All eligible steps are marked with this symbol. You can select the next step to run when you step through the process. This includes the default step, which is outlined in the editor and also in the list of eligible steps. Alternatively, you can run all the steps without making any choices. Timer boundary events, both interrupting and non-interrupting, 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. For more information, see Navigating Steps during Debugging.
	Running
	Waiting
	Interrupted
	Failed or canceled