This document summarizes an online meetup about error handling with MuleSoft. There are two types of errors: system errors and messaging errors. Errors can be handled at different levels including the application level, flow level, and processor level using different scopes like on error propagate and on error continue. Error mapping allows customizing error handling by routing errors to the appropriate error handler. The meetup included demonstrations and a Q&A section.

1. Error Handling With MuleSoft
Engineering Student MuleSoft Meetup Group
June 18, 2022
11:00 IST (GMT+05:30)

2. Safe Harbour Statement
● Both the speaker and the host are organizing this meet-up in individual capacity only. We are
not representing our companies here.
● This presentation is strictly for learning purposes only. Organizer/Presenter do not hold any
responsibility that same solution will work for your business requirements.
● This presentation is not meant for any promotional activities.
2

3. A recording of this meetup will be uploaded to events page within 24 hours.
Questions can be submitted/asked at any time in the Chat/Questions & AnswersTab.
Make it more Interactive!!!
Give us feedback! Rate this meetup session by filling feedback form at the end of theday.
We Love Feedbacks!!! Its Bread & Butter for Meetup.
Housekeeping
3

4. Online Engineering Student Group: Meetup
4
Organizer(s)

5. 5
Ankita Mishra
●11+ years of Experience in Training, Testing and Customer
Support .
●Working as Manager-Technical Training at Apisero Inc
●MuleSoft Certified Developer and Platform Architect.
Speaker

6. Agenda
● Errors and its types
● Handling Errors at different levels
- Application
- Flow
- Processor
● Error Handling Scopes
- On Error Propagate
- On Error Continue
● Error Mapping
● Wrap Up - Q&A

7. Errors and its Types
(with Demonstration)

8. ❖ An 'error' is a deviation from accuracy or correctness.
❖ Error Handling is a process to detect each error, report it to the user, and then make some
recovery strategy to handle the error.
❖ There are 2 types of errors:
➔ System Errors
➔ Messaging Errors
8
What is an Error?

9. 9
System Errors
● System Errors:
➢ Thrown at the system level and involve no event.
➢ Occur during application start-up or when a connection to an external system fails.
➢ Non-configurable, but logs the error and for connections, executes any
reconnection strategy

10. 10
Messaging Errors
● Messaging Errors:
➢ Thrown when a problem occurs within a flow and involves a mule event.
➢ Normal flow execution stops and the event is passed to an error handler (if one is
defined)
➢ By default, unhandled errors are
logged and propagated
➢ Subflows cannot have their
own error handlers

11. 11
More about Errors
❖ When an error is thrown, an error object is created
❖ Two of its properties include
➢ error.description – a string
➢ error.errorType – an object
● Error types are identified by a namespace and an identifier – HTTP:UNAUTHORIZED,
HTTP:CONNECTIVITY, MULE: EXPRESSION

12. 12
More about Errors
Each error type has a parent
❖ HTTP:UNAUTHORIZED has MULE:CLIENT_SECURITY as the parent, which has
MULE:SECURITY as the parent
❖ The error type ANY is the most general parent

13. 13
HTTP Listeners - Response
● By default, for a success response
❖ The payload
❖ A status code of 200
● By default, for an error response
❖ The error description
❖ A status code of 500
● We can override these values for an HTTP Listener as per the requirement

14. Handling Errors at different levels
(With Demonstration)

15. 15
Levels of Handling Errors
Error handlers can be added to
● An application (outside of any flows)
● A flow
● A selection of one or more event processors

16. 16
Handling Errors at Application Level
● We need to add the error handler outside a flow
● It is recommended to put the error handler in the global configuration file
● Specify this handler to be the application’s default error handler

17. 17
Handling Errors at Flow Level
● If a flow has an error handler
❖ The error is handled by the first error scope whose condition evaluates to true.
❖ If no scope conditions are true, the error is handled by the Mule default error handler
❖ NOT any scope in an application’s global default handler
● If a flow does not have an error handler
❖ The error is handled by a scope in an application’s default error handler.
❖ Else it is handled by the Mule default error handler

18. 18
Handling Errors at Processor Level
❖ For more fine grain error handling of
elements within a flow, we use the Try scope
❖ Any number of processors can be added
to a Try scope
❖ The Try scope has its own error handling section
to which one or or more error scopes can be added

19. Error Handling Scopes
(with Demonstration)

20. 20
On Error Propagate
❖ The rest of the flow that threw the error is not executed any further.
❖ Control goes to the error handler where all processors in the error handling scope
are executed
❖ At the end of the scope
➢ The error is thrown up to the next level and handled there
➢ An HTTP Listener returns an error response

21. 21
On Error Continue
❖ The rest of the flow that threw the error is not executed any further.
❖ Control goes to the error handler where all processors in the error handling scope
are executed
❖ At the end of the scope
➢ The event is passed up to the next level as if the flow execution had
completed successfully
➢ An HTTP Listener returns the success response

22. Error Mapping
(with Demonstration)

23. 23
Error Mapping
● Mule 4 now also allows for mapping default errors to custom ones
● Mapping enables us to customize error handling by routing errors to the
appropriate error handler
● In each operation of the flow, we can map the possible error types to a
custom error type as per the requirement.
● These custom error types help us to differentiate where an error occurred in
the flow otherwise it would be difficult to identify the source of the error in the
Mule application logs
● It is advised to define namespaces related to the particular Mule app name or
context and do NOT use existing connector namespace

24. 24
Error Mapping

25. Q & A

26. Take a stand !
18
●Nominate yourself for the next meetup speaker and suggest a topic as well.

27. 20
● Share:
○ Tweet using the hashtag #MuleSoftMeetups
○ Invite your network to join: https://meetups.mulesoft.com/engineering-student-
group/
● Feedback:
○ Fill out the survey feedback and suggest topics for upcoming events
○ Contact MuleSoft at meetups@mulesoft.com for ways to improve the program
What’s next?

28. Quiz Time
Get ready to WIN a Special Gift from MuleSoft Community

29. 29
● In case of On error Continue, what should be default response of http listener?
a) Status Code: 200, body: error.description
b) Status Code: 500, body: error.description
c) Status Code: 200, body: payload
d) Status Code: 500, body: payload
Q1

30. 30
● In case of On error Continue, what should be default response of http listener?
a) Status Code: 200, body: error.description
b) Status Code: 500, body: error.description
c) Status Code: 200, body: payload
d) Status Code: 500, body: payload
Q1

31. 31
● SubFlows can have error handler scopes at flow level?
a) True
b) False
Q2

32. 32
● SubFlows can have error handler scopes at flow level?
a) True
b) False
Q2

33. 33
● Validation error comes under which parent?
a) Critical
b) General
c) Any
d) Connectivity
Q3

34. 34
● Validation error comes under which parent?
a) Critical
b) General
c) Any
d) Connectivity
Q3

35. Thank you