For every project, there might occur exceptions with or without one’s notice. So you need to identify, categorize and handle those exceptions as they deviate from project success. Moreover there is a default exception strategy that is adhered to all Mule applications implicitly. The default exception strategy is to automatically rollback any pending transaction.
Before delving into exceptional handling in depth, we should first understand what types of exceptions can occur, as well as the three basic questions that a developer must ask when designing exception handlers.
Become a Mulesoft Certified professional by learning Mulesoft online course from hkrtrainings!
Because not all modes of transportation support transnationality, this question is crucial before designing exception handlers.
Transactions are not supported by file or HTTP. As a result, if an exception occurs in these cases, we must deal with it manually.
Transactions are supported by databases. In this case, when designing exception handlers, we must keep in mind that database transactions can automatically rollback (if required).
In the situation of REST APIs, we must remember that they must return the correct HTTP status codes. For example, 404 for a resource that could not be found.
We must consider the Message exchange pattern when designing exception handlers. Message patterns can be synchronous (request-reply) or asynchronous (fire-forget).
The synchronous message pattern is based on the request-response format, which means that it will wait for a response and will be blocked until a response is returned or a timeout occurs.
The asynchronous message model is predicated on the fire-forget format, which means that the requests will be processed eventually.
[Realted Article: mule message structure]
The exception will be handled based on its type, which is a very simple rule. It is critical to understand whether the exception is the result of a system/technical problem or a business problem.
An exception caused by a system/technical problem (such as a network outage) should be handled automatically by a retry mechanism.
On the other hand, an exception caused by a business issue (such as invalid data) should not be resolved using the retry mechanism because retrying without addressing the underlying cause is pointless.
Because we understand not all exceptions are the same, it is critical to categorize the exceptions. At a high level, exceptions can be divided into two categories:
Exceptions in Business:
The most common causes of business exceptions are incorrect data or incorrect process flow. These types of exceptions are typically irretrievable, so configuring a rollback is not recommended.Even using a replay method would be pointless because retrying is useless unless the underlying cause is addressed. To handle such exceptions, storage should be halted instantly and the exception returned as a response to a dead letter queue. An alert should be sent to the operations as well.
Non business Exceptions:
The most common causes of non-business exceptions are system or technical issues. These types of exceptions are retriable in nature, so it's a good idea to set up a retry mechanism to handle them.
Mule has the five exception handling strategies listed below.
Mule appears to apply this strategic plan implicitly to Mule flows. It can handle all of the exceptions in our flow, but it can be overridden by including a catch, Choice, or Rollback exception strategy.This exception strategy will roll back any pending transactions while also logging any exceptions. One important feature of this exception strategy is that it will also log the exception if no transaction exists.
Mule uses this as the default strategy when an error occurs in the flow. We are unable to configure AnyPoint Studio.
What should be done if there is no possible solution to correct the error? A solution is to use the Rollback Exception Strategy, which will roll back the transaction while also sending a message to the parent flow's inbound connector to reprocess the message. When we need to reprocess a message, this strategy comes in handy.
This strategy captures all exceptions thrown within the parent flow. By processing all exceptions thrown by the parent flow, it overrides Mule's default exception strategy. We can use a catch exception strategy to prevent exceptions from spreading to inbound connectors and parent flows.This strategy also guarantees that when an exception occurs, a transaction processed by the flow is not rolled back.
If you'd like to manage the exception based on the content of the message, the choice exception strategy is the best option. This exception strategy will function as follows:
There would be multiple exception strategies, such as Catch or Rollback, defined within the choice exception strategy. If no strategy is defined under this exception strategy, the msg is routed to the default exception strategy. It never commits, rolls back, or consumes anything.
This is a generic exception strategy represented in a separate configuration file. If a message throws an exception, the error handling parameters defined in such a global catch, rollback, or choice exception strategy will be used. It never performs any commit, rollback, or consume actions, just like the choice exception strategy.
In the above blog post we had discussed the exception handling and types of exception handling strategies in the mule. HAd any doubts please drop your queries in the comments section.
Other Related Blogs:
Batch starts on 5th Dec 2021, Weekend batch
Batch starts on 9th Dec 2021, Weekday batch
Batch starts on 13th Dec 2021, Weekday batch