In this webinar we showcase how you can execute Exception Handling mechanisms to address the following scenarios:

1. Tech Failures Fixable With Retries (video timestamp: 10:30 - 14:29)

To mitigate technical failures fixable with retries the obvious solution is to configure failing tasks to automatically retry a specified number of times before actually going into an exception state. This approach will usually solve most issues where the problem can be avoided by simply re-running the failed step in the integration.

2. Tech Failures: Not-Fixable With Retries (video timestamp: 14:35 - 21:43)

These types of errors will not “fix-themselves” no matter how many times you try to retry the failing part of the integration.

So, in this case of a specific task failing due to incorrect credentials or otherwise changed configuration such as updated interfaces or APIs, the only real option is to identify the error situation and raise an alert and apply a fix to the problematic area.

3. Process Failures (video timestamp: 21:47 - 25:33)

Sometimes you might want to end a process in a failure by design and possibly raising an alert in these situations. This typically means that you are expecting some data or functionality to behave in a certain way and when it doesn’t, you stop the process and raise an error. A good example of such a use case could be, for example, a database query returning no values matching your search criteria or receiving too many values.

4. Tech Failures With a Backup Plan (video timestamp 25:34 - 29:43)

In some cases you might have a situation in which if a task fails, you want to try an alternative approach such as using a Staging Database instead of Production, if the Production database is down. In these situations you can catch the error like in Tech Failures: Not-Fixable With Retries, but instead of sending an alert you want to preform a compensatory action and still resume the process.

5. Erroneous Data (video timestamp 29:45 - 37:53)

In many cases, the most common exception situations are those where the data you are processing is faulty or incorrect in some way. The most efficient ways to mitigate this is to implement your low-code references with nullable operators and default values, or to validate your data before processing and raise an alert is the data is incorrect.

6. Silence Monitoring Errors (video timestamp 37:57 - 42:53)

You might experience situations where the integrations themselves are working as they should and no exceptions are present, but the underlining use-case is still not being fulfilled. These typically mean that you for e.g. process incoming orders as files, but do not receive any orders meaning there is nothing to fail in the integration. Here we should use Monitoring Rules to our advantage to detect situations where the error is, why nothing happens or something happens too much or takes too long.

Did this answer your question?