Getting started Community Training Tutorials Documentation APIs, AI & Tools
After implementing your API flows, validate that the application behaves as expected before writing automated tests. In this section, you run the project locally and use the debugger to trace request execution and error routing.
Before testing your API, start the Mule application locally to verify the implementation works as designed.
Open the american-flights-api-main flow.
Click the Listener element.
On the Connection Config field, click Edit Connection (
).
Verify the values and update them if necessary:
| Field Name | Field Value |
|---|---|
Host |
|
Port |
|
Open the Run and Debug panel.
Click the
(Run and Debug) icon in the activity bar.
Use the keyboard shortcuts:
Mac: Cmd+Shift+d
Windows: Ctrl+Shift+d
Select View > Run.
In the top menu, ensure Run Mule Application is selected and click Start Debugging (
).
Wait for the application to deploy. You see deployment messages in the Output panel.
When deployment is complete, you see a message similar to:
**********************************************************************
* - - + APPLICATION + - - * - - + STATUS + - - *
**********************************************************************
* american-flights-api-implementation-1.0.0 * DEPLOYED *
**********************************************************************
In your REST client (such as Advanced REST Client), test your API endpoints:
Send GET http://localhost:8081/api/flights and verify a 200 response with flight data.
Send GET http://localhost:8081/api/flights/AA123 and verify a 200 response with data for flight with "ID": 1.
Send GET http://localhost:8081/api/flights/123 and verify a 400 response from your API specification’s path parameter validation.
In Anypoint Code Builder, click Stop (
) in the debug bar.
== Understand the Debugger
The built-in debugger in Anypoint Code Builder helps you understand how your Mule application processes requests, inspect variable values at runtime, and trace error-handling paths.
Breakpoints pause execution at specific components in your flow, so you can inspect the current state of the message payload, attributes, and variables. There are two types of breakpoints:
Component Breakpoint: Pauses execution before a specific component executes (such as a Transform Message or Database Select operation).
Error Breakpoint: Pauses execution when an error occurs, allowing you to inspect the error object.
When the application running in debug mode reaches a component with a breakpoint, execution pauses and the IDE highlights the current component with a yellow border.
The Debug panel opens automatically, showing the current values of Mule variables, message attributes, payload, and the flow execution path leading to the current breakpoint.
Set breakpoints in your application to pause execution and evaluate values at runtime.
With your application stopped, open the get:\flights\(flightId):american-flights-api-config flow.
Right-click the Flight by ID Database Select operation.
Select Add Breakpoint from the context menu.
A red dot appears on the component, indicating an active breakpoint.
Add a breakpoint on the Transform Flight component after the database query to inspect the payload.
Click the Run and Debug icon in the activity bar.
Ensure Debug Mule Application is selected in the dropdown.
Click the Start Debugging button (green play icon).
Wait for the application to deploy in debug mode.
After your application starts running in debug mode, send a GET request from your REST client to your local application:
http://localhost:8081/api/flights/AA123
The execution pauses at the Flight by ID breakpoint.
In the Variables section of the Debug panel, expand Mule Message > Payload.
At this point, the message is empty because the query to the database hasn’t executed.
Expand Mule Message > Attributes to see HTTP request information:
uriParams.flightId: The flight ID from the URL.
headers: HTTP headers.
method: HTTP method (GET, POST, and so on).
Expand Variables to see Mule variables created by Transform Message components:
flightCodeMap: The flight code mapping.
dbFlightId: The database ID for the flight.
To evaluate a DataWeave expression, in the Debug panel, locate the Watch section.
Click Add Expression to add a watch expression.
If the button doesn’t show, collapse and expand the Watch section so it shows again.
Enter a DataWeave expression, such as:
attributes.uriParams.flightId
Press Enter.
The IDE evaluates the expression and displays the result.
Click Step Over (or press F10) to continue the execution.
Execution stops at the Transform Flight component.
Expand Mule Message > Payload.
Notice that now the message contains the results from the database query.
Click Disconnect (SHIFT+F5) (
) to finish debugging.
To understand how your API handles errors, debug the validation and error-handling logic.
Set breakpoints on:
The Choice router in get:\flights\(flightId):american-flights-api-config.
The Raise Error component inside the When path.
Start debugging and send an invalid request in your REST client:
GET http://localhost:8081/api/flights/AA999
The execution pauses at the Choice router.
In Variables, inspect dbFlightId (should be null because AA999 isn’t in the mapping).
Click Step Over (F10).
Execution moves to the When path and pauses at Raise Error.
Click Step Over (F10).
Execution pauses at the On Error Propagate handler for VALIDATION:FLIGHT_NOT_FOUND:
In Parameters, verify:
type: VALIDATION:FLIGHT_NOT_FOUND
description: "Flight code AA999 not found in our system"
Click Continue (F5) to complete the error response.
Once your application behaves as expected, add automated tests in Test the American Flights API with MUnit.