MuleSoft Debugger and Breakpoints
The Anypoint Studio Debugger lets you pause a running flow at any point, inspect the message payload, attributes, and variables, and step through components one at a time. Debugging shows you exactly what data looks like at each stage of processing — far more useful than reading log files when tracking down tricky bugs.
How the Debugger Works
When you run your application in debug mode, Anypoint Studio connects to the Mule Runtime in debug mode. When the flow reaches a component marked with a breakpoint, execution pauses. The Studio UI shows the current payload, variables, and attributes. You can then step to the next component, continue to the next breakpoint, or stop execution.
Debug Session Flow
Developer sets breakpoint on [Transform Message] component
│
▼
Developer runs app in Debug mode (F11 or Debug As → Mule Application)
│
▼
HTTP request arrives at [HTTP Listener]
│ execution continues normally
▼
[Logger: "Request received"] ← runs normally
│
▼
[Transform Message] ◄──── BREAKPOINT HIT — execution PAUSES here
│
│ Studio shows:
│ payload = { "name": "Alice", "amount": "250" }
│ attributes.method = "POST"
│ attributes.queryParams = {}
│ variables = {}
│
│ Developer inspects, then presses "Step Over"
▼
[Database: Insert] ← executes next
Setting Breakpoints
To set a breakpoint in Anypoint Studio, double-click on the component in the canvas. A small red dot appears on the component indicating a breakpoint is set. Double-click again to remove the breakpoint.
You can also right-click a component and select Toggle Breakpoint. All breakpoints appear in the Breakpoints panel in the Debug perspective.
Components Where Breakpoints Are Useful
BEFORE Transform Message: → See the raw input data before transformation → Check if payload structure matches what DataWeave expects AFTER Transform Message: → See the transformed output → Verify the mapping produced the expected result BEFORE Database connector: → Inspect the query parameters about to be sent → Verify variable values used in the SQL AFTER Choice Router: → Confirm the correct route was taken → Check the condition evaluated as expected INSIDE Error Handler: → Inspect the error object: error.errorType, error.description → Verify the error response payload is correct
Running in Debug Mode
Instead of Run As → Mule Application, use Debug As → Mule Application. Studio switches to the Debug perspective automatically when a breakpoint is hit. The application runs normally until the first breakpoint.
The Debug Perspective
When a breakpoint is hit, Studio switches to the Debug perspective. This perspective has several panels:
Debug Perspective Layout
┌──────────────────┬──────────────────────────────────────────┐
│ Debug Panel │ │
│ [Suspended at │ Canvas │
│ Transform Msg] │ [HTTP Listener] │
│ │ [Logger] │
│ Stack: │ [Transform Message] ◄── RED DOT (paused)│
│ createOrderFlow │ [Database] │
│ → Transform Msg │ [HTTP Response] │
└──────────────────┴──────────────────────────────────────────┘
┌────────────────────────────────────────────────────────────┐
│ Mule Debugger Panel │
│ │
│ Payload: │
│ { "name": "Alice", "product": "Pen", "qty": 5 } │
│ │
│ Attributes: │
│ method: POST │
│ path: /orders │
│ headers: { Content-Type: application/json } │
│ │
│ Variables: │
│ correlationId: "abc-123-xyz" │
└────────────────────────────────────────────────────────────┘
Debugger Controls
Use the toolbar buttons in the Debug perspective to control execution:
- Resume (F8): Continue running until the next breakpoint or end of flow.
- Step Over (F6): Execute the current component and pause at the next one.
- Step Into (F5): If the current component calls a subflow, step into it and pause at its first component.
- Step Return (F7): Run the rest of the current subflow and return to the caller.
- Terminate (red square): Stop the application completely.
Inspecting DataWeave Expressions in the Debugger
In the Mule Debugger panel, you can evaluate DataWeave expressions live against the current message. Type any DataWeave expression in the expression field and press Enter to see the result without running the full transform.
Live expression evaluation in debugger (while paused):
Expression: payload.name
Result: "Alice"
Expression: sizeOf(payload.items)
Result: 3
Expression: payload.items[0].price * 1.08
Result: 1.62
Expression: payload.items filter (i) -> i.price > 10
Result: [{ "name": "Book", "price": 12.0 }]
Conditional Breakpoints
A conditional breakpoint only pauses execution when a specific DataWeave expression evaluates to true. This is invaluable for batch processing where you want to stop only on a specific failing record.
Conditional Breakpoint Setup: Right-click the breakpoint dot → "Breakpoint Properties" Enable: "Conditional Breakpoint" Condition: payload.customerId == "CUST-PROBLEM-99" Effect: The debugger ignores this breakpoint for all records EXCEPT the one with customerId = "CUST-PROBLEM-99". The flow pauses only for that specific record.
Remote Debugging
You can debug a Mule application deployed on a remote server — a staging environment or even CloudHub (with caution). Start the remote Mule runtime with the debug port open, then connect from Studio using Debug As → Remote Mule Application. Enter the remote server's host and debug port (default 5005).
Start remote Mule with debug port: ./mule -debug -debugHost 0.0.0.0 -debugPort 5005 Connect from Studio: Debug As → Remote Mule Application Host: staging-server.mycompany.com Port: 5005 → Studio connects, breakpoints work on the remote app
Debugging vs Logging
Use the debugger for complex issues where you need to step through logic interactively. Use Logger components for less complex issues where you just need to see values at key points. The Logger approach works in all environments including production. The debugger only works when you can connect a Studio session to the running application. In production, rely on structured logging and Anypoint Monitoring rather than the interactive debugger.