Exploring Error Handling in MuleSoft

Error Handling in MuleSoft - Part 1 : Session 15

Estimated read time: 1:20

Summary

In this session of Salesforce Apex Hours, we dive into the fundamentals of error handling in Mule 4, providing a comprehensive guide on managing errors effectively within your MuleSoft projects. The session elaborates on handling errors at project and flow levels, focusing on error handlers like 'On Error Continue' and 'On Error Propagate'. It demonstrates how error handling in real-time projects is crucial and often more time-consuming than handling success paths. The session wraps up with hands-on examples to solidify the concepts discussed.

Highlights

Error handling is crucial for managing exceptions in MuleSoft projects. ✨
Session breakdown includes handling errors at different levels, and grasping key error handler functions. 💪
Learn about default and global error handlers, and their role in Mule 4 projects. 🌍
Mule identifies errors based on type, which helps route messages correctly in error handlers. 📡
Hands-on examples are provided to solidify theoretical concepts. 🖐️

Key Takeaways

Understanding Mule 4's error handling can significantly streamline your development process. 🚀
Error handling in real-time projects often requires more time than success path management. ⏳
Mule 4 simplifies error handling with default handlers and customizable options. 🛠️
Always check if the error type is handled in your error handling blocks. 🔍
Utilize the 'On Error Continue' and 'On Error Propagate' handlers for effective error management. 💡

Overview

Error handling in Mule 4 is a cornerstone for managing exceptions in your MuleSoft projects effectively. This session introduces key concepts of error management, stressing the significance of handling various types of errors that might occur during real-time operations. The presentation emphasizes the need for simplifying the content to make it digestible within an hour.

The session outlines various levels at which errors can be handled in Mule, from project to flow level. It discusses the use of default error handlers, global error handlers, and explores specific error handling functions like 'On Error Continue' and 'On Error Propagate'. These tools are invaluable for defining how exceptions should be managed across different layers of an application.

We delve into practical examples, demonstrating the real-world application of these concepts. By following structured rules for error handling, developers can ensure a robust error management strategy. The session also touches on creating error objects under different scenarios, and how MuleSoft environments can automatically detect potential errors.

This session not only explains the theoretical aspects of error handling in Mule 4 but also provides step-by-step hands-on examples. These demonstrations help in cementing the concepts covered, preparing developers to adeptly handle errors in their own projects.

Chapters

00:00 - 00:30: Introduction The introduction chapter welcomes viewers to the first session of error handling in Mule 4, particularly focused on Salesforce developers. It outlines the session's aim to cover error handling within a one-hour timeframe, emphasizing the importance of understanding the topic. The instructors express the possibility of extending to a two-session format if necessary, to ensure comprehensive coverage. The focus remains on delivering content effectively within the time limit.
00:30 - 01:00: Agenda and Recap of Previous Session The chapter titled 'Agenda and Recap of Previous Session' begins with the speaker expressing their intention to explain concepts simply using their 'three rules of error Handler'. There is an anticipation of a follow-up session depending on the day's progress. The agenda includes a recap of the previous session and a focus on error handling. In reviewing the last session, the discussion was on Salesforce integration part two, specifically on update and upsert functionalities. The summary notably cuts off at a point suggesting something was not completed or left in a state of suspense.
01:00 - 01:30: Importance of Error Handling in MuleSoft The chapter titled 'Importance of Error Handling in MuleSoft' begins with the acknowledgment that dealing with errors is crucial in real-time projects. While achieving success in specific projects might seem straightforward, the challenges primarily arise due to various types of errors encountered in real-time scenarios. Thus, error handling becomes a significant focus in development work, especially using platforms like MuleSoft. The discussion hints at the complexity and necessity of adept error management to ensure smooth project execution.
01:30 - 02:00: Understanding Errors and Exception Handling Chapter: Understanding Errors and Exception Handling This chapter explains the process of managing errors and exceptions in MuleSoft's Mule 4, highlighting its simplicity compared to Mule 3. The discussion begins by noting the greater time required for coding error handling versus the success path. Mule 4 offers improved tools for error management, such as the error Handler in the Mule palette, which includes connectors like on error continue and on error propagate.
02:00 - 03:00: Mule Exception Handling Levels The chapter titled 'Mule Exception Handling Levels' discusses the concept of errors in the context of programming and data processing. It starts with a general definition of an error as an unexpected event that occurs during processing, where the outcome does not match the expectation. Examples provided include executing queries in Salesforce or making database select statements where the actual result differs from what was expected, leading to an exception or error. The chapter likely goes on to explore various levels of exception handling in MuleSoft.
03:00 - 06:00: Error Types and Error Objects in MuleSoft The chapter discusses different types of errors and their handling in MuleSoft. It defines an error as a situation where a program does not get a successful response, leading to an exception. Exception handling involves dealing with these errors, such as a database connectivity issue when executing a select statement. The chapter emphasizes the importance of processing and responding to such exceptions to ensure smooth program execution.
06:00 - 13:00: The Three Rules for Understanding Error Handling The chapter titled 'The Three Rules for Understanding Error Handling' discusses various levels at which message exceptions can be handled in Mule. It mentions that exceptions can be managed at the project or application level by utilizing the default error handler if no specific error handler is provided. The importance of understanding these concepts is emphasized through a combination of slides and hands-on experience, aiming to simplify the understanding of error handling mechanisms in Mule.
13:00 - 18:30: Example 1: Default Error Handling The chapter discusses the error handling mechanisms provided by Mule, specifically focusing on the default error handler available at the project or application level.
18:30 - 24:30: Example 2: On Error Propagate The chapter discusses exceptional handling in programming, specifically focusing on three types of connectors: 'on error continue,' 'on error propagate,' and 'raise error.' It emphasizes understanding these three concepts as crucial for smooth error handling. The speaker aims to simplify these concepts for better comprehension. The discussion begins with 'on error continue' and 'on error propagate,' exploring their behavior in various scenarios.
24:30 - 32:00: Example 3: On Error Continue In this chapter titled 'Example 3: On Error Continue,' the speaker discusses the importance of hands-on practice in understanding how to manage errors. They mention a specific scope called 'triscope' that will be demonstrated in future sessions. The focal point of the discussion is how to handle errors within flows, emphasizing that understanding this aspect is crucial.
32:00 - 45:00: Complex Scenarios with Flow References This chapter focuses on managing complex scenarios in MuleSoft applications, particularly with respect to error handling within flow references. It begins by revisiting the concept of the Mule event, which consists of a Mule message and accompanying variables. The discussion emphasizes that a Mule event also includes an error object, although this isn't prominently featured in the official documentation. The chapter highlights the crucial point that an error object is only created when an error occurs within the flow. This lays the groundwork for exploring how to effectively manage and reference these errors in complex flow scenarios.
45:00 - 47:00: Conclusion and Next Steps The chapter discusses the various properties within an error object, emphasizing its multiple fields such as 'description' and 'error type'. It notes that understanding the error type is crucial, as it is a combination of a namespace and an identifier. The chapter suggests the significance of recognizing error types using examples, like authentication errors, to better understand and handle errors in programming.

Error Handling in MuleSoft - Part 1 : Session 15 Transcription

00:00 - 00:30 hello Apex s viewers welcome back to our sessions moft for Salesforce developers and this is our first session for moft error handling in mule 4 so I will try to see if we can cover everything in 1 hour session because we try to limit it to 1 hour if not we will make it two sessions the aim is for you to understand things so for that we are limiting the content of the of each session limiting to 1 hour so please this is really important session error handling mu for is really important and
00:30 - 01:00 I will try to explain uh things in really easy manner with my three rules of error Handler that I have created hope you will like this session again we will see how much we can try and we will see whether we will have session two or not without wasting time our agenda is recap of previous session and next we will start with error handling and uh coming to the recap of previous session we have seen the Salesforce integration part two where we have seen update upsert it's not up
01:00 - 01:30 upset I'm upset with that so it's upset just a typ yep so update upset query platform events right and today we will be going to discuss about error handling folks this is really important in realtime projects because success SPS are always very easy it's just one thing but we have different kinds of errors that that will be generated during our real-time projects so to handle them how to handle them is a big thing here so most of the development work usually um
01:30 - 02:00 success path takes less time but handling the errors will take more time when you code it all right so and um mule 4 does uh simplifies this error handling in mule 4 mule 3 was bit typical but you don't have to worry about mule 3 anymore so let's get started with error handling so this is how we have in our mule pallet error Handler okay we see these four connectors basically error Handler on error continue on error propagate and
02:00 - 02:30 raise error okay so basically what is an error right in in general terms error is nothing but whenever there is an exception that occurs or when like when an unexpected event happens while processing your processing you are expecting something but you got something else that is an exception right that is an error for example you are trying to get a query you know trying to query a Salesforce query uh or you know database select statement you're trying to do and you got some
02:30 - 03:00 different error instead of getting a success respond so that is an exception that is an error right and exception handling is nothing but how we are processing and responding to the exceptions when a computer program runs like for example there is a database connectivity issue that is an error we you are trying to get information from database select statement but eventually it ended up with connectivity issue of database so how you are handling those kind of scenarios is nothing but exceptional exception handling or error
03:00 - 03:30 handling okay in mule we can handle the message exception at different different levels okay again I will go by both slides and uh handson but these slides are really important because I try to simplify the things so I told you right mule exceptions can be uh handled at different levels so the first one is at project level your application Level using default error Handler if you're not providing any error Handler
03:30 - 04:00 specifically by default mules mule provides default error Handler okay and another one is at app level but if you trying to provide a customized Global error Handler yes then it will be handled at Global error Handler if you're not providing anything it will go to default error Handler and these two are at project level or application Level then within project within application we have different flows isn't it we have different flows so at flow level
04:00 - 04:30 exceptional handling we use three different kinds of connectors on error continue on error propagate raise error if you are uh if you are good with these three on error continue on error propagate and raise error your error handling is smooth and you will if you understand the concept of on error continue on error propagate and raise error then you are good trust me so I tried to simplify those things okay first we'll discuss about on error continue and on error propagate and how it behaves at various
04:30 - 05:00 levels that is the challenge here okay for that if you try to do some Hands-On you don't need anyone to explain things right so I'll try to do that for you and um within within flow or at process level there is another scope called triscope probably that I will show in uh coming uh sessions so yep and uh Whenever there is an error occurred in a flow this is really important guys Whenever there is an
05:00 - 05:30 error occurred in a flow an error object is created remember we are talking uh about U you remember when we are discussing about mu event I told mu event again I'm reiterating mu event is a combination of mule message plus variables plus I told like though in the official documentation they don't show the error object and all but mule event also contains error object only when error occurs okay so whenever there is an error an error object is created and
05:30 - 06:00 it contains many properties within error object it contains many properties for example error. description error do error type Etc I will show you in the real time uh this thing but error object the whole objects has many fields one of them is desri description and the other one is error type we have more now this point is very important error type is combination of a name space and identifier example for example if you have some authentication error then it
06:00 - 06:30 will give HTTP colon unauthorized okay HTTP colon unauthorized and um and H2 col unauthorized and what is called as namespace and what is called as identifier right Nam space here is called HTTP this is just an example but I'm trying to show what is called as Nam space and identifier is called as unauthorized so the red whatever is highlighted in red text is nam space that means the word left to the colon is
06:30 - 07:00 the namespace and right is the identifier and the combination combination of namespace and identifier is called as error type this is very very very important because in handson we'll always talk about error type error type error type and also whenever I say Nam space it is the first block right you know HTTP for example here and whenever say identifier I will say unauthorized here like for example right and mule identifies based on the error typ type and then routes to respective
07:00 - 07:30 blocks that are placed in the error Handler so the only thing that is that the error handling is message is being routed is based upon the error type that's why the error type is really important that's why I have elaborated this error type all right now we all know when we discussed differences between flow subflow and private flow we came to know that subflow doesn't have error handling scope okay then what happens so it is just the flow and a
07:30 - 08:00 private flow where you can place this on error propagate and on error continue inside the error handling block because subflow cannot have error handling okay so flow and private flow if you keep there is a place where we can keep on error propagate and on error continue that place is called error handling you must have seen already in our you know previous sessions there is error handling uh area but we never used it because we have error handling session so there are only two connectors that we
08:00 - 08:30 can place on error propagate and on error continue either it is a propagate or continue mule executes all components within that block this is important statement okay either it is on error propagate or on error continue whatever you keep inside error handling block inside the on error propagate or on error continue it executes all the components if you have three loggers in the error handling it will execute all three loggers okay remember the error will
08:30 - 09:00 route to the error handling only if it identifies that error type of that error is handled which means if you're not uh if it doesn't identify the error type then it will go to default error handling if you're are not mentioning the type of error is not mentioned in your error error Handler block then it will go to default error handling all right so the whenever I'm highlighting with some different text color right red or green or any other color those are
09:00 - 09:30 important points because guys uh when it comes to certification exams you will be getting probably more than five to seven questions on error handling so if you follow my rules it will be very easy for you to crack the examination or for that matters even in your realtime projects okay how to identify the error types how to do that do you have to do any coding and all no moft is very much uh you mule 4 has like this excellent feature of identifying
09:30 - 10:00 the types of errors that can occur within the Flow by just looking at what kind of connectors that are placed in that flow right how if you see this screenshot in my flow you can see different connectors there is HTTP requestor connector there is database connector right when when you drag and drop something on error propagate or on ER or continue and when you click on search automatically here on the screen it is showing what what kind of errors
10:00 - 10:30 that it can occur you can see database bad syntax database connectivity or HTTP bad request based on the connect as moft itself is very uh smart enough to detect the kind of errors that can that you that it can produce you don't have to you know search for it all right so now comes the actual fun three rules of understanding error error handling these are the rules okay these are the rules just framed by me and uh this is
10:30 - 11:00 just to make you understand this error handling concept more easier okay if you follow these rules yes you can understand almost 95% and the rest 5% if you do your hands on you can get it all right and uh this is not official these rules are not officially created by moft it is just by me so okay any mistakes happens please apologize all right so let's go with the three rules to understand and then we will go with the handsome rule rule one okay I keep
11:00 - 11:30 insisting rule one rule two rule three in every scenario I will show you in the form of pictures okay then we will go in the realtime handson part rule one is very simple see if anything is present in the error handling okay let me go quickly to my anyo studio I will try to create a new project file new mu project error handling let me create a
11:30 - 12:00 new project here we'll go step by step okay let me drag a flow for example here so this is error handling whatever you are seeing here right this block is error handling you must have seen in many many times during our Hands-On session so error handling that's what my first point says like see if anything is present in the error handling okay if there are on error propagate and on error continue blocks see that if that particular error type
12:00 - 12:30 is handled that is our next Point okay first see if there is anything present in the error handling second if even if there is even if there are any on error propagate or on error continue blocks you should see if that particular error type is handled okay even if it is on error propagate onor continue is present but that error type has to be handled okay if not in above two scenarios first of all if there is nothing present or even if on eror propagate and continue
12:30 - 13:00 are present but the error type is not handled in these two scenarios mule will use default error handling mule will use default error handling and if your flow is not called by any other flow that means for example when it comes to subf flow or private flow isn't it if your flow is not called see first things someone will call your API when it comes to http when it comes to apis someone will be calling your apis in all the Hands-On sessions what we have done we
13:00 - 13:30 have called using Postman correct let's consider Postman tool as the caller okay if your flow and you're calling HTTP listener okay HTTP listener go with flow flow reference and flow reference will take you to multiple subflows and all right so those private flow private flows are subflows if your flow is not called by any other flow then it will display default value that is set in error response and gives status code AS file 00 bad default if nothing is set
13:30 - 14:00 manually I will show you this in our real time scenario what is this error response and everything okay but if you called if your flow is called by any other flow then it will raise that error to the calling flow whoever is calling you it will be raised to that particular flow we will see in the handson because this is just the theoretical part you won't be understand excuse me all right so rule one clear so rule two where is simple if some error handling is present
14:00 - 14:30 in that particular flow and error type is handled that means it is s condition for rule one okay what happens to that then check whether it is on error continue or on error propagate that is very important okay so H eror continue and Order propagate check whether it is on continue or onor propagate in both the cases mule will execute all the components within that block okay we
14:30 - 15:00 will execute all the components within that block next follow the rule three which is very important and very simple okay so rule two is if some error handling is present or not in that particular flow an error type is handled yes condition for rule one and then check whether it is on error continue or propagate and then it will execute all the components within those blocks next is follow the rule three rule three is if the error is handled using on error propagate it will
15:00 - 15:30 raise an error back to the calling flow okay if the error is handled using propagate propagate name itself is propagating again to the calling flow if the error is handled using on error continue it will not raise an error to back to the calling flow rather it continues to the next processor after the flow reference and continues further but it will not continue to the other process within the flow where the error is handled this is very important and I
15:30 - 16:00 will show you in the real time case all right again continuation to rule three suppose you have only one single flow okay there is only one single flow and then on error propagate and on error continue behaves the same way because there is no caller flow right and instead of on instead on error continue gives 200 and on error proper gives 500 status guys remember on error continue the name itself saying it's saying that on error and continue that means you
16:00 - 16:30 know that there is an error but you still want to continue and give a success response because as I said even if it's onor continue it will not go to the next processor of within the same flow when the error is handled all right remember this point is really really important on error continue will continue only to the next processor of the calling flow but not on the same flow okay let's see an example very quickly imagine that this is a flow okay imagine
16:30 - 17:00 that this is a flow for example let's talk about weather API that we used right earlier to call using HTTP requestor so imagine that you have a listener here you have a set set variable then HTTP requestor and some other connectors after that okay so in this case we will identify okay so imagine that you got a connectivity issue that's why I'm on my right side if you see when you are in a debug word that error is nothing but the error object and within error object you can see multiple description error type Etc
17:00 - 17:30 now here on my screen you can see that error type is HTTP connectivity okay HTTP connectivity right so HTTP connectivity is the error now that is the error type and HTTP is the name space and connectivity is the identifier now let's go with the rule one rule one is see if something is present in our error handling yes something is present that is on error continue okay not only that you have to
17:30 - 18:00 also check like whether that particular type is handled or not here our type is HTTP connectivity which we got but whatever is coded here right that is HTTP not found right this is HTTP connectivity the error which we got and whatever we have coded is HTTP not found so our rule one is breaking so what will happen rule one rule and L is breaking when rule one is a no then what we said like it will go to default error Handler
18:00 - 18:30 and it will show whatever is there in whatever is set in the HTTP listener error response so this will give default error message okay default error message with 500 status all right this is so this is failing at rule one itself right let's see example two now this is my okay in all these times please consider that we are getting HTTP connectivity issue only okay all the times we are using the same for this example all
18:30 - 19:00 right now rule one see if anything is present in error handling yes it is present on error continue see whether his the error type is handled here yes it is handled because the type is HTTP connectivity rule one is done very good next what is Rule two what is Rule two see whether it is honor or continue or on error propagate in our case it is on error continue okay what I have said if it is only a single flow here you have a
19:00 - 19:30 single flow you don't have any flow reference or nothing right it will just call it okay uh so on eror continue yes what will happen Okay on eror continue will continue first it will first it will try to execute all the components within the error handling block so what is the uh component that is there in error handling block transform message within on eror continue you see transform message me and the value that is set in the transform message is error handled
19:30 - 20:00 in main flow so rule three who is calling this flow it's nothing it is just the listener probably it is called by the postman right or someone else so no it is not being called by any other flow so what will happen this part whatever is this part whatever part is there after this HTTP requester it will not execute that's what I told like in a on error continue it it will execute only to the next processor by the calling flow not on the same flow so what will
20:00 - 20:30 happen it will go to http request there is an error that is occurred that is HTTP connectivity issue then it will go to error handling there is HTTP connectivity there is a transform message and that will execute this and then it will not execute all three blocks so and I told you right if it is on error continue it will give 200 okay and whatever payload is the latest one that it will print here in our case the latest payload value is error handled in main flow that is there in error
20:30 - 21:00 handling okay so the output would be the payload will be error handling in main flow with 200 status got it coming to error handling example three so here see we have two different flows this is now interesting this is more interesting right we have two different flows the first one is the main flow because we have a listener okay so in this scenario we are getting an error in our private flow this the
21:00 - 21:30 below one is a private flow because it doesn't have a source and this private flow is being called by the flow reference now please imagine that this rule one rule two rule three will apply to each flow okay you have to do this rule one rule two rule three in the each flow I will show you in the handson but try to understand the rules here so very first rule as usual the error is ur occurring in the private flow Okay so the first rule is uh whether this
21:30 - 22:00 particular error is handled first of all is there anything in the error handling yes on error propagate is there this time and uh is the error type handled if the type is any that means the type is handled the error is handled it because any type of error can be accepted yes it is handled then what it will do it will execute rule one is completed rule two is irrespective of error propagate or ER continue it will execute all the components which are present in the inside the error propagator or error
22:00 - 22:30 continue which means here in our case the transform message whatever is there in here the payload value is set to error handled in private flow one okay now what what is the next step rule two I told you this is error propagate it will execute next rule three check whether this particular flow is being called by any other flow yes here you can see with using this flow reference this is calling that one okay now our latest payload is error handled in private flow one and our rule three I
22:30 - 23:00 told if it is on error propagate it will go it will not go it will not go to the very next connector of here like in our private flow it will not go to the calling private flow or something it will raise an error to the calling flow again you have to start rule one rule two rule three for this calling flow rule one again on error continue yes okay on error continue is there and error type is HTTP connectivity yes it is handled so rule one is good rule two
23:00 - 23:30 it will execute all the components within that on error continue now so which is like error handled in main flow so now the previous payload was error handled in private flow one now the error handled in main flow will be the latest one and see again rule three check if this particular flow is being called by any other flow here no one is calling because this is the main flow so it will not go to this part whatever is there this success in main flow set payout it will never execute this part and our latest value as it is on error
23:30 - 24:00 continue the status code will be 200 and the latest payload value will be error handled in main flow all right so these are the three simple examples that you can uh three simple rules that you can use to understand the concept of on error propagate and on error continue and we will be going to see handson soon let's get back to our Hands-On part let's get our hands dirty so far you have seen these three rules on slides
24:00 - 24:30 and we have seen how to go it so let me keep this slide first let's go with the first example so that you will understand in a uh better way so for that to replicate the same thing please understand that I am dragging and dropping the listener here and I keep saying like right uh whenever default error messages or whatever is set in the error response so in the listener when you create a configuration there is a tab this is by default you will see you can keep like error one for now okay
24:30 - 25:00 the path as error one there is a field called responses so this tab is really really really important guys whatever is set in the error response there are two response this is the success response and this is the failure response so the listener will determine what needs to be passed to the caller okay here by default the response is payload so whatever payload is set at the last point for the success scenarios it will give that payload and um can you see
25:00 - 25:30 here in the error response what is the body here it is the error do error description and output text plane which means any error when when there is an error that is occurred okay and uh uh if if it is on error propagate then it will go into this section and whatever you are setting inside the body that will be the base so here whenever there is on error propagate it is error do error dot description that it will display and if it is on error continue it is it will
25:30 - 26:00 always you are saying like on error continue which means even if there is an error just continue and consider it as success so it will go into this part so this response tab is really really important all right so listener I have dragged end up what is their set variable this is not really important but just to show that there are some connectors so like fruit I'll say apple just this is for demo purpose and and I will keep HTTP requester okay HTTP requester now in
26:00 - 26:30 this case I need to create an error right I need to create an error so what I will do I'll just create a new configuration and give some dummy URL like you know XYZ dog.com so that it will give a connectivity issue right and then what a transform message here okay so here what I'm doing is I will keep like application
26:30 - 27:00 Json success and in in your real time uh you know certification exam and all they will not show you each and every connector right because the code is too long so whatever they are naming it here right whatever they are naming it here you should consider that okay this is the part which was set here okay by looking at this display name same with set variable also whenever you see in any certificate exam if you see something like display name as Apple
27:00 - 27:30 because they won't show you all these screens so when you see apple here that means you need to consider that set variable is the uh the value that is set in the set variable is Apple all right so yep that is done and keep a logger if you want at the end put a logger like payload all right so now first even before pH keeping anything here in error handing let's debug and see what it will
27:30 - 28:00 give okay I'll give a debugger Point here let's go step by step no hurries in learning this uh error handling take your time but you have to do Hands-On practice okay in this if you if you try to understand this three rules it will be very easy for you during the handson I will try to show that okay don't worry about it
28:00 - 28:30 we'll go step by step it will be easy then we can build multiple flows and see how it behaves accordingly
28:30 - 29:00 all right my application is deployed now now what I'll do is let me put it here all right so error one this is the flow name let me send the request here the request is coming here go next let's wait till the error is created okay yes the error is created immediately error object is created this is what I have shown you in this example right Whenever there is an error it will create a error object right so error object is created and error object has
29:00 - 29:30 multiple Fields like description detail description error type which is one of them so error type you can see identifier and Nam space Nam space is HTTP and identifier is the connectivity this one is really important for us to I told you right in here in one of them so remember the error will continue to error handling only if it identifies the error type of that Handler okay now rule one is see if something is
29:30 - 30:00 present okay rule one itself is failing there is nothing present in the error Handler that's what our rule one right where is our rule one see if anything is present if not then mule will use default error handling that's why when it is default error handling it will print whatever you are setting in the responses okay in the error response it will go to Output explain error do description so in our case when error is raised what is error this is this is error go to X+ Y what is error do
30:00 - 30:30 description you don't have to type every time here because you can see header. description is HTTP get on blah blah blah blah blah the urri provided must contain a scheme whatever is there right so that description is nothing but this one so this it will print and the status code will be 500 all right status code will be 500 so because rule one is failing it will go to default error Handler I told you right this is what error. description and this is 500
30:30 - 31:00 status so for everything you should be seeing both uh for everything you should be seeing both uh uh like uh what do you say the UR you know the status code and payload that is really important all right next thing what's next uh this is one scenario now what if you
31:00 - 31:30 keep on error propagate okay on error propagate there is on eror propagate you can search it drag and drop I told you right whenever you're draging dropping if you click on this search button it will immediately show you a list of errors that these connectors can generate because I am using HTTP requester in my component you can see uh you know different types of errors that are handled right so now instead of HTTP so if you click HTTP connectivity it will come here okay but
31:30 - 32:00 I don't want to use that one now I wanted to use different because I wanted to show you something transform message drag and drop and keep something like error in error occurred in main flow this is the payload that I wanted to set okay error a in main flow so what it will happen we will see whether it will
32:00 - 32:30 go inside this honor propagate or not we will see so see whether it is deployed or not yes it is deployed let's run it again so
32:30 - 33:00 rule one again rule one let's this rues surprise when there is an error yes rule one see if anything is present here in the error handling yes it is present but there is another condition I told see if that particular type is handled the error type is handled this one this point so what is the error type that you got HTTP connectivity but what you are coding here bad request
33:00 - 33:30 correct right so it will not go inside this still rule one is failing that's why it will not come here it will execute and give the same issue here now see the drama I will try to change this bad request to H I'm I'm I cannot I there is no need for me to change I can just add connectivity also okay now you can see HTTP connectivity is being handled here let me save
33:30 - 34:00 it and let me run it right the application is started send the request again now this type rule one rule one is see if anything is present in the error handling yes on error propagate is present rule two is see if that sorry within rule one you see whether that
34:00 - 34:30 particular error type is handled here it is HTTP connectivity and in the type you are handling HTTP connectivity now if you go it will come into this block okay this is how error is handled there is an error occurred and it is getting handled in this transform message okay what is Rule two irrespective of on error propagate or continue it will execute all the components within this block so so there is only one component so it will So currently this will change into the
34:30 - 35:00 payload okay whatever payload is there here okay you think it will print this one okay but we will see what it is doing it is still printing the error dot description why I told you right whatever is there in the listener responses tab whatever you are setting here in the error responses error. description is the body right that will only display okay but whenever you generate these flows using raml by default it will show payload so now what
35:00 - 35:30 I am doing I'm trying to modify this error response body to payload so that it will print whatever the latest payad is there it will print error occurred in main flow so this is really really important whenever someone asks you in the interview questions or certification exam you have to be cautious what is set in the responses tab here that is more important now I am send setting both error and success payload to payload now you see the magic send
35:30 - 36:00 it okay let me resume this first and I wanted to add one more connector into my on error propagate so that I wanted to show you that it will execute all the components within this log okay
36:00 - 36:30 all right so this is one now it is deployed let me send the request again there is an error there will be an error that is occurred okay rule one see if anything is present yes it is present and the type is handled because HTTP connectivity is there and it will execute all the components here two components it will execute and what is the latest payload now error occurred in main flow now according to our rules
36:30 - 37:00 rule three if it is on error propagate rule three is if it is on error propagate it will if there is if this flow is being called by any other flow it will raise an error to the calling flow but in this case is there anyone who is calling our flow using flow reference no it is just the Pol Postman so it will raise this error to this Postman itself so it will not execute this transform message and this loger all right so if you go to next it is raising an error to this call caller so
37:00 - 37:30 you can see now error occurred in main flow with 500 status all right and uh what happens if we use on error continue on error continue here you can add multiple you know on error propagates and continue but for now I don't want to confuse you with all this I can show you in the next session what happens if we have two things in one point now I am using error continue remember guys one more thing if if
37:30 - 38:00 you're typing like this and selecting HTTP connectivity or if you are not giving anything by default it will take it will accept all the conditions here okay if you're not defining anything in your on error continue if you're not defining anything in the type which means it by default it accepts all kind of errors all right so let me run now this is on error continue scenario next error is raised rule one see if
38:00 - 38:30 there is anything in the error handling block yes it is there so it will go irrespective of continue or propagate first don't forget don't forget about this it will execute all the components within that error handling block this this done now check whether it is on error continue or on error propagate it is on error continue on error continue I told it behaves the same way like propagate it will never go to the next message of the calling flow okay of the of the same flow it will go to the calling flow right so this time this
38:30 - 39:00 success and this logger will not execute rather as you said that this on error continue you are considering as a success it will go to the payload body here in the in the listener responses tab it will go here and status code is nothing so it will give 200 okay that is the difference between on error propagate and on error continue now what I will do is I will try to give you one more example by keeping them in two different flows what will happen when it
39:00 - 39:30 is on error continue and on error propagate let me drag and drop this request separately okay let me put a flow okay drag and drop this request here HTTP requester you can drag and drop here and call this flow using on error
39:30 - 40:00 propagate so first what I will do I'll keep this everything let let me keep this on error continue here we can do some drama over here so I'm going to use this flow reference to call this private flow this one okay now what will happen here in this error handling in this error handling let me put transform message here okay and then on error on error
40:00 - 40:30 propagate over here okay and just copy another transform message here and just keep error occurred in private flow okay and keep another logger I just want I'm just keeping multiple connectors so that you can understand how it goes from one place to another
40:30 - 41:00 okay please do handson along with me okay save it and it will redeploy and now we will see how it behaves when there are in two two sides okay okay okay the application is deployed now now let me run
41:00 - 41:30 this so step one okay now we are using flow reference it will go to this flow okay error occurred same follow rule one rule 2 rule three for this private flow rule one see if anything is present here yes it is present whether error type is handled or not as we are not mentioning anything it will go inside because we are not mentioning any error type it will consider as okay now next thing is execute all the components here and this what is the
41:30 - 42:00 latest payload now error occurred in private flow what is Rule three if it is on error propagate and if this flow is called by any other flow that's what I have written here in rule three right okay it will raise an error back raise as an error back to the calling flow now your question should come whether it will go to this transformation message or not this transfer message or not no it will not go here okay it will go to
42:00 - 42:30 the calling flow so it will raise as an error to the flow reference so if you see next now it is going to flow reference now you should apply all these three rules again because you can see an error here and see the error type error type is still HTTP connectivity right now rule one again see if anything is present here or not yes it is present on error continue see whether error type is handled or not as we didn't mention anything by default you should consider that it is handled so it will go inside
42:30 - 43:00 this you will see error occurred in main for you'll execute this again what is the third rule whether this again whether this particular flow is being called by any other flow no this is listener so this is the main flow now this is being called by Postman so it will go this is on error continue so it will consider as success 200 as it is not called by any other flow it will not execute this one and it will not execute in the same flow if if if this was on
43:00 - 43:30 error continue it would have come here okay so go next you can see error occurred in main flow clear everyone 200 and error occord in main flow this is how it behaves when you're calling using flow reference how it will raise to the calling flows let me give some perfect value for this as well um success in private flow okay now tell me if I keep
43:30 - 44:00 on error continue here here okay if I'm keeping on error continue here and removing the on error propagate do you think that when it raise an error will it raise an error to the calling flow and it will it will execute here or not we will see okay once it is deployed we can see it is deployed now see the fun so if
44:00 - 44:30 you understand these three rules again and again it is very simple just like it's like a riddle okay so let's see whether so going to flow reference it is having a error that error type is HTTP connectivity rule one see if anything is present and error type is handled yes something is present so it will go inside execute all the components as it is on error continue it will not go to
44:30 - 45:00 the next connector of the same flow this is I'm trying to insist everyone please try to understand if it is honored continue it will not go to the next connector of the same flow rather it will go to the next connector of the calling flow this one that is what we have mentioned in on error continue it will not raise an error back to the calling flow but it will continue the next processor after the flow reference and continue to further process it okay
45:00 - 45:30 but it will not continue to the other process in the same flow same flow where the error handle error is handled right which what I'm trying to say here is it will never go into this transform message no matter what if you have 100 connector of HTTP requester it will never go here that it will go to the calling flow it will not raise an error because you are saying like error occurred it is handled so it will consider that whatever block you have done in the private block it will
45:30 - 46:00 consider as the success and see where it is going it is going to the this is what I mentioned okay it will continue to the next processor okay it will continue to the next processor of the after the flow reference because what is happening here is you are saying there is an error occurred but you handled it already and saying that it is Success so it is going to this place it will now not go into this on error continue block because you are not raising it as an error okay no rule one rule two rule three here is
46:00 - 46:30 going as if nothing happened this flow reference behaves like as if nothing happens here because it is on error continue smoothly it will execute the next processor and you will get success 200 clear very simple even if you keep on error continue or on eror propagate doesn't matter everyone so this is how you can apply rule one rule to rule three of error handling and these are the small examples that I have tried to show you
46:30 - 47:00 here as we are running out of time I would like you to practice all these three scenarios and next scenario we will try to learn about raise error okay this is typical topic important topic try to understand two more handson it will be very easy thank you everyone and uh see you in our next session