MuleSoft Surat Virtual Meetup#31 - Async API, Process Error, Circuit Breaker and Canary Deployment
1 like809 views
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.
Ad
More Related Content
What's hot (20)
Similar to MuleSoft Surat Virtual Meetup#31 - Async API, Process Error, Circuit Breaker and Canary Deployment (20)
Ad
More from Jitendra Bafna (20)
Ad
Recently uploaded (20)
MuleSoft Surat Virtual Meetup#31 - Async API, Process Error, Circuit Breaker and Canary Deployment
- 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
- 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
- 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
- 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
- 19. Demonstration – Canary Deployment Policy
- 20. Q & A Session
- 21. Thank you