Event page: https://meetups.mulesoft.com/events/details/mulesoft-edmonton-presents-mule-4-error-handling-and-logging/

1. © Bits In Glass. All rights reserved.
Mule 4 Error Handling and Logging
Edmonton Meetup
Thu, Oct 29, 1:00 PM (MDT)

2. © Bits In Glass. All rights reserved.
Agenda
1. Introduction and House keeping - Jimmy
2. Introduce the Scenario
3. Error Handling Basics
4. Advanced Error Handling Topics
5. Avoiding Error
6. Redelivery Policy and Reconnection Strategies
7. Error Summary and Questions
8. Logging
9. Logging Summary and Quests
10. Announce Winners

3. © Bits In Glass. All rights reserved.
Quiz and Swag
•At 3 Points in the presentation there will be a quiz
•Quiz will be on the material just covered
•Post answers in the chat
•First correct answer will win a prize
•Winners will be announced at the end

4. © Bits In Glass. All rights reserved.
The Presenter : Eric Carsted
•Director of Technology and Principal Architect of the Integration
Practice at Bits In Glass(BiG)
•Leads the BiG architecture team and responsible for QA of BiG’s
projects.
•36 years in the industry with 25 years in an architecture role at
companies such as Sun Microsystems (Chief Enterprise Architect),
IBM (Industry Architect Oil and Gas)
•Chief IT Architect for two construction projects; a refinery and SAGD
Oilsands facility.
•Chief Architect for Enterprise Integration for major airline enabling
the Passenger Reservation and Departure Control Systems migration.
•Extensive experience in Cloud and On-premise Data Centers,
Enterprise Infrastructure, and complex integration with Camel, IBM
WebSphere ESB, Mulesoft, TIBCO, Informatica, IOT, SCADA, and
OSIsoft PI.

5. © Bits In Glass. All rights reserved.
Goals of this Meetup
•Demystify Mule 4 Error Handling
•Expose Scenarios for Error Handling that you can implement today
•Liberate you with tips to avoid Errors
•Investigate Redelivery Policy and Reconnection Strategies
•Verify your work with negative testing
•Empower your logging so you can trouble shoot faster
•Recommend a payload logging solution
•Yeet some goodies
•Main GOAL : Improve your Mule 4 DELIVERY and bring some joy to
2020.

6. © Bits In Glass. All rights reserved.
Error Handling in context of a Scenario

7. © Bits In Glass. All rights reserved.
Error Handling Complexity Based on Pattern

8. © Bits In Glass. All rights reserved.
Error Handling Basics
•Error categories (System Errors, Messaging Errors)
•Error Data Type
• Tip : set vars.reasonPhrase to error.description
• Tip : set vars.statusCode based on error.Type
Field Description Selector Expression
Description A description of the problem. #[error.description]
Detailed
Description
A description of the problem, which can be the same or more
extensive than the description.
#[error.detailedDescription]
Type
A type, used to characterize the problem and allow for routing
within an error handler.
#[error.errorType]
Cause The underlying Java Throwable that resulted in the failure. #[error.cause]
Message An optional Mule message about the problem. #[error.errorMessage]
Child Errors
An optional collection of inner errors, used by elements like
Scatter-Gather to provide aggregated route errors.
#[error.childErrors]

9. © Bits In Glass. All rights reserved.
Error Types (Hierarchies)
•Mule errors have a namespace (such as HTTP: and FILE:) and
identifier (such as NOT_FOUND), and they belong to a hierarchy of
error types.

10. © Bits In Glass. All rights reserved.
Examples of Namespace and Identifiers Based
on Context of the Scope
Default HTTP JMS

11. © Bits In Glass. All rights reserved.
Basics 2 - Which Error Handler will be used
Default Error Handling
By default, unhandled messaging errors are logged and propagated. When a flow is processing a
Mule message that raises an error, the normal execution of the flow stops, and the process
transfers to the flow’s default error handler, which propagates the error.
On-Error Component (Propagate, Continue) and flow behavior
▪ Continue: Execute On-Error Scope ->Terminate Current Scope -> Return Success to Parent Scope
▪ Propagate: Execute On-Error Scope -> Terminate Current Scope -> Return Error to Parent Scope.
* Terminate Parent Scope
Global Error Handlers
A global error handler can be useful if you want more than one flow or Try
scope to handle errors in the same way. You can create reuse configurations by
providing a reference to an error handler flow
•Time to show some examples in Studio

12. © Bits In Glass. All rights reserved.
Additional Error Topics
Error Mapping
In each operation of your flow, you can map the possible error types to a
custom error type of your choosing. You can use these custom error types
to differentiate where an error occurred in your flow.
Raise Error Component
This core component generates a Mule error, as if a failure had occurred,
which allows you to customize its description and type. Use this
component to only raise:
• Core runtime errors, such as MULE:SECURITY, MULE:CONNECTIVITY, etc.
• Custom error types.
• You cannot raise an error from another connector or module like
FILE:FILE_NOT_FOUND, JSON:INVALID_SCHEMA. You cannot use a connector’s
existing namespace.

13. © Bits In Glass. All rights reserved.
Additional Error Topics - Continued
Additional differences between Continue and Propagate
•Your payload is not available in On-Continue
•You cannot set a payload within On-Continue
•Payload in On-Propagate is the state of the payload prior to executing
the connector
Other Notes
•If you need to access information in the payload after On-Continue,
store it in a variable
•There is nowhere to access the statusCode returned by a connector. You
need to determine your statusCode yourself based on error.errorType
•Subflows do not have an error Scope

14. © Bits In Glass. All rights reserved.
Reconnection Strategies
Default connection behavior
• When an operation in a Mule application fails to connect to an external server,
the default behavior is for the operation to fail immediately and return a
connectivity error.
Override the Default behavior
• You can configure a reconnection strategy for an operation either by modifying
the operation properties or by modifying the configuration of the global
element for the operation.
Reconnection Strategies
• None: Is the default behavior, which immediately returns a connectivity error if
the attempt to connect is unsuccessful
• Standard: (reconnect) Sets the number of reconnection attempts and the
interval at which to execute them before returning a connectivity error
• Forever: (reconnect-forever) Attempts to reconnect continually at a given
interval

15. © Bits In Glass. All rights reserved.
Redelivery Policy
Redelivery Policy
• A redelivery policy is a filter that helps you conserve resources by limiting the number
of times the Mule runtime engine (Mule) executes messages that generate errors.
Redelivery Policy Behavior
• When you add a redelivery policy to a flow’s source, Mule evaluates the received data
before it executes the flow’s components. If a message delivery fails a specified
number of times, the redelivery policy prevents the flow from processing the received
data.
How the Redelivery Policy Works
• Each time the source receives a new message, Mule identifies the message by
generating its key.
• If the processing flow causes an exception, Mule increments the counter associated
with the message key. When the counter reaches a value greater than the configured
maxRedeliveryCount value, Mule throws a MULE:REDELIVERY_EXHAUSTED error.
• If the processing flow does not cause an exception, its counter is reset.

16. © Bits In Glass. All rights reserved.
Avoiding Errors
Validation
• Passing clean data to your components will greatly reduce the number of errors you
encounter at run time. (Sure thing Captain Obvious!)
Inbound Data Validation: Use RAML Validation in your API SPECS
• Field: Type, Required, Enumerated Values, Assign Default Values to missing fields
• For Strings: Pattern, Min and Max Length
• For Numbers: Min and Max Value, Format
• For Arrays: Unique Items, Min and Max Items
• For Files: File Type, Min and Max Length
• Tip: Route file and db xfers through an HTTP Endpoint with API Spec to validate data
Outbound Data Validation
• Not Provided by Mulesoft
• Bits in Glass has built an Outbound Data Validator that uses API Spec that we use
during Development to improve code quality. We turn it off in higher environments

17. © Bits In Glass. All rights reserved.
Avoiding Errors - Continued
Idempotent Message Validator
The Idempotent Message Validator ensures that only unique messages continue through a
flow’s execution by checking the unique ID of the incoming message. Use incoming attribute
of the Mule message as an ID, or compute the ID by configuring a DataWeave expression.
Use the DataWeave Crypto functions to compute hashes (SHA, MD5) from the data. Throws
MULE:DUPLICATE_MESSAGE
Avoid Code Errors by Testing
• Negative Testing – Exercise all error handling if possible, build dummy endpoints
that throw every error type.
• MUnits
• Test Recorder in Studio to Create Munits
• End to End Testing
• Consistency between Environments (From Dev to Prod)
• Unit Testing with Postman, SOAPUI, etc
• Regression test suite

18. © Bits In Glass. All rights reserved.
Error Summary and Questions
Final Thoughts on Error Handling
•Handling Errors takes time and thought – Budget ~30% of the total
development effort for it, more if you must handle business errors.
•Handle errors for every major interaction with component and systems.
Let the default error handler take care of the rest, you probably can’t do
much about it anyway.
•Validate your data and test your handling routines
•Use reasonable Reconnection and Redelivery Policies
Questions?

19. © Bits In Glass. All rights reserved.
Logging
Why Log?
What is my system doing? How can I figure out what went wrong and what were the
conditions at the time of the error? What information do I need while developing and
testing? What do I need in Production? Logging has been, and still is the #1 go to
solution.
Mule Logging
Every app that you build in Studio comes with its own log4j2.xml file. The log contains
information about any errors raised in the app (unless you have app logic to handle those
errors). It also contains anything you want to explicitly log, if you build the logic in the app.
Logger Component
A Core component helps you monitor and debug your Mule application by logging
important information such as error messages, status notifications, payloads, and so on.
You can add a Logger anywhere in a flow, and you can configure it to log a string that you
specify, the output of a DataWeave expression you write, or any combination of strings
and expressions.

20. © Bits In Glass. All rights reserved.
Guidance on Logging
Where should you log in flows
▪ Start and end of every Flow
▪ Start and end of large piece of logic
▪ Before and after transformations (optional)
▪ Before and after interaction with an external system
▪ On Error
What to Log – Subjective but
▪ Mule application and system info and info about external systems being called.
▪ Inbound transaction ID
▪ End to end flow correlation ID
▪ External system Transaction ID
▪ Lapse Time at end or after the above mentioned locations
▪ Key data you may need to tract down root cause in outside systems.
Use Log Levels and Categories

21. © Bits In Glass. All rights reserved.
JSON Logger Module
Author : Andres Ramirez
What is it?
A generic JSON Logger module which is considered a drop-in replacement of the existing Logger
component.
How to Use it?
Customize the output JSON log by defining a matching JSON Schema. Once satisfied with the JSON
schema, all of the module’s code can be dynamically re-generated by building and packaging the
module. The outcome will be a new JSON logger module that developers can install in Anypoint Studio
and leverage from the palette like any other component.
Learn More!
https://blogs.mulesoft.com/dev/mule-dev/logging-in-mule-using-json-logger-module/
https://blogs.mulesoft.com/dev/anypoint-platform-dev/json-logging-mule-4/

22. © Bits In Glass. All rights reserved.
Example JSON Logs

23. © Bits In Glass. All rights reserved.
Notifications
•Notifications, although not directly part of error handling or
logging, it is part of the overall error event management.
•May only want to Notify on certain errors
•Execute Notifications from the On-Error Scope
•Make sure you don’t become a Spammer by sending too many
notification to the point your email server gets block
•Getting the lists of interested parties is the hardest part

24. © Bits In Glass. All rights reserved.
Payload Logging
Problem Statement
• Sometimes you need the entire message to End-to-End trouble shoot
messages and Mulesoft doesn’t provide a mechanism to persist message data.
• Mule logs are not the Answer
• Truncation of large messages
• No guaranty log messages will be persisted at high volume
• Size of the logs reduces log retention
• Data privacy
Bits in Glass Offering
• A payload logging solution that used JMS to asynchronously move messages to
a data store of choice. Provides meta data, clear text, encrypted, or a
combination of both.
• Contact BiG Sales for more information.

25. © Bits In Glass. All rights reserved.
Logging Summary and Questions
•Logging is necessary
•Modern tooling (JSON Logging) can make the job easier and
provide more information and better results
•Notify those in the need to know know with notifications
•If payload logging is required, there are options but nothing out of
the box
Questions?

26. © Bits In Glass. All rights reserved.
Who is Bits In Glass?
When you need it done right get the experts in MuleSoft
✔ Trusted enterprise implementation services
✔ Centre for enablement consulting
✔ Expert architecture consulting that accelerates development
✔ Augmented in-house development for program scalability
✔ Ongoing Anypoint application maintenance and support