The document summarizes a presentation on Mule 4 exception handling and Munit. It covers error handling in Mule 4 including system errors, messaging errors, and the error hierarchy. It also discusses default error handling, creating error handlers, and differences between error handling in Mule 3 and 4. The presentation includes a demo of error handling and introduces Munit for testing Mule applications with capabilities like mocking and validating processors.

1. [23rd July 2020]
Mule 4 Exception Handling and Munit
[Vancouver-Canada]

2. All contents © MuleSoft Inc. 2
• Introductions
• Error Handling
• Munit
• Q&A
• What’s next
Agenda

3. All contents © MuleSoft Inc. 3
Presenters, Organizers and You
Yashwant Palkar

4. Mule 4 Error Handling

5. All contents © MuleSoft Inc.
Mule Error Types
Errors that occur in Mule belong to one of following two major categories:
 System Errors
 Mule throws system error when an exception occurs at the system level and no
mule event is involved.
 A system error handlers manages exceptions that occur
 During application startup
 When a connection to an external system fails
 When a system error occurs, Mule sends an error notification to registered
listeners, logs the error, and if the error is caused by a connection failure, executes
a reconnection strategy.
 Messaging Errors
 Mule throws a messaging error (a Mule error) whenever a problem occurs within a
flow of a Mule app, where Mule events and the messages they contain are
processed
 You can handle these messaging error with
 Default Error Handling
 On Error Components
 This is built in error component inside flow.
 You can have any number of components to process error.

6. All contents © MuleSoft Inc.
Mule Error Hierarchy
 Any: Error type that matches all error types that occur in a Flow and can be handled. This type does not
include errors that occur on the source.
 Transformation: This involves Mule Runtime internal transformations and not DataWeave
transformations.
 Expression: indicate an error occurred while evaluating Dataweave expression
 Validation: indicates validation error occurred
 Duplicate Message: indicates a validation error regarding a message being processed twice
 Connectivity: indicates that there was problem establish a connection
 Routing: indicates an error occurred while routing a message
 Security: indicates a security error occurred, like invalid credentials being received or an expired
token being used.
 Client_Security: indicates an external entity produced an error
 Server_Security: indicates a security error enforced by the Mule Runtime
 Critical: Indicates a severe error occurred. These errors cannot be handled.
 Overload: indicates a problem of overloading occurred and the execution was rejected.
 Fatal_JVM_Error: indicates that fatal error occurred such as overflow

7. All contents © MuleSoft Inc.
Default Error Handling
 This is laziest way of handling error
 If you don’t handle any error Mule will handle in its own way
 What is Mule way to handle error?
 When a flow is processing a Mule message that raises an error, the normal
execution of the flow stops
 Transfer to default error handler
 Propagates the error
Following example is for default error handling

8. All contents © MuleSoft Inc.
Creating Error Handlers
 Error handlers can be added to
 Application level – (Global Error Handler)
 A Flow level
 A Processor level(try scope)

9. All contents © MuleSoft Inc.
Adding Error Handling scopes
 Error handlers can contain one or more error handling scopes
 On Error Propagate
 All processors in this error handling scope are executed
 At end of the scope
 The rest of flow that threw the error is not
executed
 Error is rethrown up to next level and handled
there
 The HTTP listener returns an error response
 On Error Continue
 All processors in this error handling scope are executed
 At end of the scope
 The rest of flow that threw the error is not
executed
 The event is passed to next level as if the flow
execution has completed successfully
 The HTTP listener returns an successful response

10. All contents © MuleSoft Inc.
Mule 3 vs Mule 4 Error Handling
Mule 3 Mule 4
• Missing error handling at processor level • Using “try” scope processor level error
handling can be achieved
• Error handling is not possible at sub flow
level
• Error handling at subflow level can be done
using “try” scope
• Catch exception strategy can be used to
avoid propagating exception to parent flow
• On error continue process errors and doesn’t
propagates error
• Rollback strategy handles errors that occur
in a flow that involve a transaction
• Transaction are possible using try scope
• Choice exception strategy catches and
evaluates a type or content of exception.
• Error handler with on-error components can
have multiple exception strategy
• Custom errors can be raised with groovy
script or Java code
• Custom error can be raised using Raise
error.
• Custom error mapping is not possible • Custom error mapping of existing exception
is possible and it allows granular error
handling

11. Demo

12. MUnit

13. All contents © MuleSoft Inc.
MUnit is
• Integrated with Anypoint Studio, allowing you to create, design and run MUnit tests just
like you would Mule applications
• It provides a full suite of integration and unit test capabilities
• Integrated with Maven for integration with your continuous deployment

14. All contents © MuleSoft Inc.
MUnit capabilities
• Create individual test cases by writing Mule Code
• Minimize manual testing
• Mock Processors
• Verify Processors calls
• Spy Processors
• Enable or ignore test cases
• Visual coverage in Studio
• Integrate with CICD
• Generate coverage reports

15. All contents © MuleSoft Inc.
MUnit Modules
Munit Munit Tools
• Munit is divided in 2 sub modules
• Munit
• MUnit Tools
• Each Module has its own dependency

16. All contents © MuleSoft Inc.
MUnit Test Scope
• Behavior Scope
• Meant to set all precondition executing the test logic
• Mocks and Spies goes here
• Execution Scope
• Meant to have testing logic that waits for all processes to finish before executing the
next scope
• Run flows in this section
• Validation Scope
• Meant to have all validations regarding result of the execution scope
• Assertions and verifications go here

17. All contents © MuleSoft Inc.
MUnit Consists
• Set Event
• This message processor is normally used at the beginning of an
MUnit test, to define the first message to send to the flow being
tested
• Mock When
• The Mock When processor allows you to mock an event processor
when it matches the defined name and attributes.
• Spy
• This processor allows you to spy what happens before and after
an event processor is called.
• Assert That
• This event processor allows you to validate the state of Mule
event’s content. This processor uses a set of Dataweave functions
called Munit matchers to define in an expression

18. Demo

19. Q&A

20. All contents © MuleSoft Inc.
Take a stand !
20
• Nominate yourself for
the next meetup speaker
and suggest a topic as
well.

21. All contents © MuleSoft Inc. 21
• Share:
– Invite your network to join: https://meetups.mulesoft.com/vancouver/
• Feedback:
– Contact your organizers to suggest topics
– Contact MuleSoft at meetup@mulesoft.com for ways to improve the program
– Your feedback is fuel for us
• Our next meetup:
– Date: Aug End/early Sept
– Location: Virtual
– Topic: TBD
What’s next

22. See you next time
Please send topic suggestions to the organizer