Contact Free trial Login

Breakpoints

You can add breakpoints to your message processors so that the Studio debugger stops the execution of your flow at that particular processor. You can later inspect the content of the message as it exists at that point in the flow.

A breakpoint stops the execution of the flow when the message reaches it. You can also configure a breakpoint to execute when a specific condition in the message is met, or whenever an error occurs. See the types of breakpoints below for more details.

Default Breakpoints

When you add a breakpoint, Studio enables the breakpoint by default.

To add a default breakpoint, right-click a message processor and select Add Breakpoint:

add breakpoint

To disable the breakpoint, right-click the message processor and select Disable Breakpoint:

disable breakpoint

Although the breakpoint is disabled, Studio does not delete it. In the canvas, the breakpoint’s corresponding event processor displays a gray circle instead of a red circle:

disabled breakpoint

When you have many breakpoints, you can use the Mule Breakpoints view in the Mule Debug perspective. The Mule Breakpoints view lists all the message processors that have breakpoints and indicates with a check mark all the breakpoints that are enabled. You can select and unselect the check marks to enable or disable the breakpoints you need:

breakpoint activation

When you run your application in debug mode, Studio stops the flow execution at the breakpoint you added, enabling you to inspect the message’s content in the Mule Debugger view.

Conditional Breakpoints

A conditional breakpoint activates when a predefined condition evaluates to true when Studio executes the event processor with the breakpoint. You define the condition using a DataWeave expression.

To add a conditional breakpoint:

  1. Right-click the message processor and select Add Breakpoint:

    add breakpoint
  2. In the Mule Breakpoints view, select the breakpoint to which you want to add a condition, and select Conditional at the bottom:

    set confitional breakpoint
  3. Enter the condition that must be met for the breakpoint to be activated.
    For example, the following expression activates the breakpoint if the method used in the request is GET:

    attributes.method == "GET"

You don’t need to stop the application’s execution to change the condition.

Error Breakpoints

Enabling error breakpoints causes any event processor in the application to become a breakpoint if it throws an error. Studio stops the flow execution whenever an error occurs. The Mule Debugger view displays the content of the message as it exists at that point in the flow that the error occurred.

Error breakpoints are enabled by default.

You can’t add specific error breakpoints to stop the flow execution when a specific error occurs.

To disable error breakpoints, select the Disable error breakpoints (to set error breakpoints 55f71) button in the Mule Breakpoints view:

disable error breakpoint

Temporarily Mute Breakpoints

You can activate the Mute Breakpoints option in the Mule Breakpoints view to temporarily disable the debugger from stopping at your enabled breakpoints:

mute breakpoints

By default, muting your breakpoints also disables the error breakpoints. You can configure this behavior in Preferences > Anypoint Studio > Debugger by unselecting the Mute Breakpoints disables Error Breakpoints check mark:

mute disable error breakpoints

Was this article helpful?

💙 Thanks for your feedback!

Edit on GitHub