MuleSoft from Start: A Beginner’s Guide — Session 6: Debug the Mule App in Anypoint Studio

In the last session, we modified our newly created Mule project to follow best practices like having a specific file for Global Elements or creating properties files per environment.

In this week’s session, we reviewed how to implement the articles logic, created a Postman collection with its local+dev environments, and learned how to debug our Mule application.

Note: The links and notes from the session have been added to the GitHub repository for you to follow through with what I’m doing in the video. You can find both recordings (the complete and the shorter one) at the end of the post.

Homework from the last session

You can see the full list of changes I did for this solution in this Pull Request or read the step-by-step here. The homework was to:

• Create new Mule Configuration Files to keep each resources’ logic separate from the main maxines-blog-api.xml file. Like so:

• Add sub-flows inside these new config files instead of flows. For example:

• Reference these new sub-flows from the main flows from the APIKit router. Like so:

• Finish creating the logic for the articles resource (happy path).

• Improve the code to avoid duplicating the same code (like we do with the Retrieve connector named GET articles) -- this helps to prevent human error.

Postman collection

We ended up starting a Postman collection to keep all our basic requests to be able to test this API. We created the following requests:

We also created two different environments in Postman to be able to switch between local and dev (once we deploy the application to CloudHub).

You can download this collection we generated here.

Debugging a Mule app

It is important you learn how to debug your Mule application so you can see the flow of the app running step by step. It is also useful to understand better how your Mule message is being transformed in every component.

You can debug by adding a breakpoint to any component — this means the application will pause running in the spot where you put the breakpoint so you can advance and see step by step.

And instead of running the application, click on debug.

Make sure you change your perspective to be able to see the debugging windows.

Once the app has been started (you can confirm in the Console), you can send a request and see where it stops.

In the Mule Debugger window, you will be able to see a preview of the Mule message and other properties.

You can use the Evaluate DataWeave Expression window to run some DataWeave code and see a preview of the output without affecting the rest of the running application.

You can use the debugger control buttons at the top-right to be able to step into/out of or continue running the application.

Finally, you can change perspectives using the top-right buttons to change from development and debug views.

Recordings

Finally, here are the two recordings you can find about this session.

• The complete video on Twitch
• The edited/clean/shorter version on YouTube

Here you can find the shorter version from YouTube:

And here you can find the complete video from Twitch:

Please let me know if you have any comments, suggestions, or just general feedback for me!