Engineering Student MuleSoft Meetup#5 - Error Handling With MuleSoft
0 likes473 views
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.
Engineering Student MuleSoft Meetup#5 - Error Handling With MuleSoft
- 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
- 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 [email protected] 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