The document provides details about an upcoming MuleSoft Surat Meetup event on AsyncAPI, error handling plugins, circuit breaker policies, and canary deployments. It includes the date, time, speakers, and agenda. The event will be recorded and uploaded within 24 hours. Attendees are encouraged to provide feedback through a form. The speaker, Jitendra Bafna, is introduced with his background and expertise in API and integration technologies including MuleSoft, AWS, and OCI. Demonstrations will be provided on using Async APIs, an event error handler plugin, a circuit breaker policy, and canary deployments in MuleSoft. A Q&A session will conclude the event.

1. MuleSoft Surat Meetup Group
AsyncAPI, Error Handler Plugin,
Circuit Breaker, Canary Deployment
Date – 30th Dec 2021
Time – 22: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 & Answers Tab.
Make it more Interactive!!!
Give us feedback! Rate this meetup session by filling feedback form at the end of the day.
We Love Feedbacks!!! Its Bread & Butter for Meetup.
Housekeeping
3

4. Organizers
4
Nitish Jain
Jitendra Bafna

5. Speakers
5
Jitendra Bafna
Senior Solution Architect III
EPAM Systems
➢ Overall 14 years of experience in API and Integration Technologies.
➢ TOGAF 9.2 Certified.
➢ MuleSoft Ambassador and Surat/Nashik MuleSoft Meetup Leader
➢ Published overall 300+ YouTube Videos and 150+ Articles on MuleSoft
and Anypoint Platform.
➢ Expertise in setting up MuleSoft platform includes Hybrid
Implementation, CloudHub (Anypoint VPC, VPN and DLB), Customer
Hosted Mule Runtime (Clustering and Server Group).
➢ Expertise in Application Integration using API Led Connectivity and
Event Driven Architecture.
➢ Expertise in Integration with various systems like Salesforce, NetSuite
ERP, Snowflake, Databases, SAP,
➢ Define Integration and migration strategy and roadmap includes
migrating from on premise to CloudHub, migrating to higher version of
Mule Runtime etc.
➢ Expertise in AWS, OCI.

6. 6
Agenda
Introduction
Async API
Error Handler Plugin
Circuit Breaker Policy
Canary Deployment
Trivia Quiz

7. AsyncAPI/Event
Driven
Architecture
With the release of the AsyncAPI, Event Driven Architecture supported in the
Anypoint Platform. You can publish Async API specification to customers,
partners and developer.

8. AsyncAPI in
Anypoint Platform
AsyncAPI supported by following product in the Anypoint Platform.
Stage Product Additional Information
Design API Designer You can create an AsyncAPI specification or import one from Anypoint
Exchange.
Publish Anypoint Exchange You can add non-managed instances to your AsyncAPI asset in Anypoint
Exchange.
Developers can now design event-driven APIs using AsyncAPI specification — a protocol-
agnostic human and machine-readable format — to unlock and expose events in the
enterprise.
AsyncAPI makes it easy to work with event-driven architecture by separating the API into
three layers:
• Events: Message or data to be shared with other services
• Channels: Destination of the message to be sent or received
• Transport: Technology that transports the message, such as RabbitMQ, Kafka, or
Anypoint MQ

9. Benefits of
AsyncAPI in
Anypoint
Exchange

10. Demonstration - Async API

11. Event Error
Handler
This custom error handler plugin allows a single module to process error messages from
multiple types:
• Error types default to mule. (HTTP, APIKIT, Connectors based, etc)
• custom error types as defined by raise error component.
• Un-clutter exceptions both in UI and XML
• User can change the custom error message (for multiple errors) in the UI rather than in
the XML.
• Users intending to use other error types should put them on on-error-propagate or on-
error-continue prior to using this module.
• No specific error type is required for this module. It can parse any error types.
• Propagate errors from sys/prc layer back to exp layer, cementing error propagation
across layers.
• To propagate the errors, ensure the appropriate variable name is referenced in the
previous error section.
• Support for Mule error components to be factored into the error message based on
boolean fields.
• Using Mule Error components will give very prescriptive error messages.
• Support for debug log package: org.mulesoft.modules.errorhandler
Link - https://github.com/mulesoft-catalyst/error-handler-plugin

12. Demonstration – Event Error Handler

13. Circuit Breaker
Policy
This is a custom policy that implements a lightweight Circuit Breaker pattern for Mule 4. By
applying this policy to your API, you would be able to:
• Define an error threshold giving your API the flexibility to fail as many times as you
define before tripping the circuit
• Define a retry period after which the protected API should allow incoming requests
• Set the circuit to HALF-OPEN state after the threshold is reached and service is still not
functional
• Perform a dynamic exception handling

14. Circuit Breaker
Policy

15. Circuit Breaker
Policy
Parameter Purpose
Failure Threshold
maximum number of errors allowed before tripping the circuit (putting it
in OPEN state)
Retry Period
number of seconds the pattern will wait before trying to reach depedent
components (underlying APIs) when a new request is received
Evaluate the error object to trigger the circuit?
- Checkbox - Select this option if the underlying application propagates
the error object. E.g. applications not handling errors or raising custom
ones on error handling strategies
Exceptions Array
a comma separated string containing the exception types that are
expected to trip the circuit. Example: "MULE:COMPOSITE_ROUTING,
HTTP:UNAUTHORIZED, MULE:EXPRESSION"
Evaluate the HTTP response to trigger the circuit?
- Checkbox - Select this option to evaluate the HTTP response (status
code). Check this option if evaluate error object option is unchecked.
HTTP Codes Array
Specify all the HTTP codes that can trip the circuit. The default value is
500 (Internal Server Error). Expect a comma separated string.
Example: "500, 401". Double quotes are required but spaces between
types are not.
Override Object Store settings?
- Checkbox - Select this option to override default OS settings. Defaut
OS will use persistent OS, with 1 hour entry TTL.
Object Store's entry TTL The entry timeout. Default value is 1 (hour).
Object Store's entry TTL unit
The time unit. Default value is "HOURS". You can choose one of the
listed options based
on https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/TimeU
nit.html

16. Demonstration – Circuit Breaker
Policy

17. Canary
Deployment Policy
A custom policy to perform canary releases, intercepting the incoming calls and deciding
which implementation URL to route the call to. Applying this policy to your API or proxy you
would be able to:
• Define an array of endpoints, with their weights
• Enable session stickiness (TO-DO), to keep record of previous redirections based on a
customizable header
• Capture metrics for the incoming events
• Get the stored metrics

18. Canary
Deployment Policy

19. Demonstration – Canary Deployment
Policy

20. Q & A Session

21. Thank you