Hey Muleys,
I believe that this article on Error Handling in Mule 4 will definitely help you to understand the core concept of On-Error Propagate and On-Error-Continue.
- Error Handling :
An exception occurs when an unexpected event happens while processing. Exception handling is the process of responding to exceptions when a computer program runs.
In Mule we can handle the message exception at different level.
- At Project level using Default error handler
- At Project level using Custom Global error handler
- At Flow level in exception handling using On Error Continue and On Error Propagate, Raise Error
- With in Flow or at processor level using try scope
Whenever there is an error occurred in a Flow, an error Object is created . It contains many properties . Eg : error.description , error.errorType etc
errorType is combination of Namespace and Identifier :
Eg : HTTP:UNAUTHORIZED
Here :
namespace = HTTP
Identifier = UNAUTHORIZED
Mule identifies based on error Type and then route to respective blocks that are placed in Error Handler.
Let’s discuss what is On Error Propagate and On Error Continue in detail:
As we know the differences between flow , sub-flow and private flow, Sub-Flow doesn’t have Error Handling scope . So it's just Flow and a Private flow which has Error-handling block and can be placed On-Error-Propagate and On-Error-Continue.
Either it is Propagate or Continue, Mule Executes all the components within those blocks
Remember : The error will route to error-handling only if it identifies that the errorType occurred ,matches with what you have handled in Error-Handling
Also Mule 4 has one excellent feature of Identifying the types of errors that can occur within that flow by looking at what kind of connectors are placed in that particular flow.
You can see above that as we have Http-Request and Database , it has all kind of error types which are expected to come in error scenarios . Even you can find EXPRESSION error type as we have some Dataweave syntaxes in the flow.
It will be very easy to learn Error-handling on how Error-Propagate or Error-Continue works . We shall follow some set of rules to identify the flow of process. That way we can determine what is the result payload statusCode
Before going to learn about rules. We must not forget that , RAML based generated Http Listener has Error Response Body as “payload” as Default but manually dragged and drop Http Listeners has output text/plain - - - error.description as default. So change accordingly to your business requirements .
RULES
When an error occurred in any Flow :
Rule 1 : See if anything is present in Error-Handling . Even if there are on-error-propagate and on-error-continue blocks, see that if that particular errorType is handled. If NO, then Mule will use default Error Handling . Suppose 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 500 bad default if nothing is set manually. If your flow is called by any other flow, then it will RAISE as an error to the calling flow.
Rule 2 : If some Error Handling is present in that particular flow and errorType is handled (YES condition for RULE1) , then check whether it is On-Error-continue or On-Error-Propagate . In both the cases, Mule will execute all components within that block.
Rule 3 : After execution of all components . Now:
- If the error is handled using On-Error Propagate , it will raise an error back to the calling flow.
- If the error is handled using On-Error Continue , it will not raise an error back to the calling flow and continue to next processor after “flow-ref” and continues further process as it is. But it will not continue to other processors in the flow where error is handled.
- Suppose you have only single flow. Then On-error-propagate and On-error-Continue behaves same way, instead error-continues gives 200 status and error-propagate gives 500 status. Because as said , even if its error-continue, it will not go to next processor within the same flow.
- Always remember , this point is very important. On-error-Continue will continue only to next processor of calling flow but not in the same flow .
If you observe below flows. Suppose your error is handled in 2nd private flow and if there is on-error-continue, it will not execute logger in private flow 2, instead it will go to Set payload of private flow 1 which is actually calling private flow 2
If it is on-error-propagate , The error is raised back to the calling flow . And now flow Rule1 to Rule 3 again for that particular calling flow until final process is completed .
Simple tip is, whenever an error is raised back to calling flow, just go by the rules 1,2,3 again .
Let’s See some examples and check what is the output and status code of each one.
Consider that in all cases , default value for response in Http Listener in Error Response is set to #[payload] and all cases below raise error for errorType : HTTP:CONNECTIVITY
All cases have input payload as {name : “sravan lingam”}
===============================================================
EXAMPLES
Case 1: Let us assume we have only one flow. Lets follow rules
Rule1 : There’s something handled in Error-Handler. But errorType is not Matching with Handled errorType. So don’t care whether it’s error-continue or error-propagate. When errorType not matched, it will use default error handler by mule.
Actual errorType = HTTP:CONNECTIVITY
Handled errorType = HTTP:NOT_FOUND
As both doesn’t match and this is main flow and is not called by any flow,
It uses Mule’s default error-handling.
It will print the payload whatever is coming from input just before Http Request with status code 500
Final Response :
Response Body :
{name : “sravan lingam” }
Response status code : 500
===============================================================
Case 2: Let us assume we have only one flow. Lets follow rules
Rule1 : There’s something handled in Error-Handler. And errorType is Matching with Handled errorType.
Actual errorType = HTTP:CONNECTIVITY
Handled errorType = HTTP:CONNECTIVITY
As both are matching and this is main flow and is not called by any flow,
Rule 2 : The flow is using On-Error-Continue . It executes all components in this block. In this block we are setting payload in Transform message with value “Error Handled in Main flow”
Rule 3: According to point b and c in Rule 3, As it is On-error-continue , and the current flow is not called by any other flow , it will execute processors in Error-Continue and end the process with 200 status
It will not execute the components after Http-Request as this is main flow
It will print the payload whatever is set in Transform Message in Error-Continue
Final Response :
Response Body :
“Error Handled in Main flow”
Response status code : 200
===============================================================
Case 3: If we use On-error-Propagate in Case 2 instead of On-error-Continue ,Every rule is same but as its On-error-propagate , it will raise and error back to caller with status code 500
Final Response :
Response Body :
“Error Handled in Main flow”
Response status code : 500
===============================================================
Case 4: Let us assume we have 2 flows. Lets follow rules
Rule1 : There’s something handled in Error-Handler. And errorType is Matching with Handled errorType.
Actual errorType = HTTP:CONNECTIVITY
Handled errorType = ANY
ANY can handle anything
Rule 2 : The flow which has error (private flow 1 in this case) is using On-Error-Propagate . It executes all components in this block. In this block we are setting payload in Transform message with value “Error Handled in Private Flow 1”
Rule 3: According to Rule 3, As it is On-error-propagate , and the current flow is called by main flow , it will execute processors in Error-Propagate and raise error back to calling flow which is main flow.
Now ball is in Main flow court.
Now repeat the rules again for Main flow :
This is how it raised back error to main flow
Repeat rules:
Rule 1 : Matching error type exists
Rule 2 : On-error continue , executes transform message with payload “Error handled in main flow”, will not go to other components after flow-ref. As it is On-error Continue, and no other flow is calling the current flow, it will display latest payload with 200 status
Final Response :
Response Body :
“Error Handled in Main flow”
Response status code : 200
===============================================================
Case 5: Same as Case 4 except that error-continue is used in private flow 1
Rule1 : There’s something handled in Error-Handler. And errorType is Matching with Handled errorType.
Actual errorType = HTTP:CONNECTIVITY
Handled errorType = ANY
ANY can handle anything
Rule 2 : The flow which has error (private flow 1 in this case) is using On-Error-Continue. It executes all components in this block. In this block we are setting payload in Transform message with value “Error Handled in Private Flow 1”
Rule 3: According to Rule 3, As it is On-error-continue , and the current flow is called by main flow , it will execute processors in Error-continue ,doesn’t raise as error and go back to calling flow which is main flow . It executes all components after flow-ref and final payload will be displayed with 200 .
Final Response :
Response Body :
“Success in Main flow”
Response status code : 200
===============================================================
Simple! If you follow this set of rules, then you can easily understand the way that On-Error-Continue and On-Error Propagate works!
No comments:
Post a Comment