Understand error handling directives

Transcript

For tool tip number three, know that there are five error handling directives which can be classified into two categories: directives which allow your scenario to continue executing and directives which stop your execution. Let’s first review the three directives that continue the scenario execution. The Resume directive will substitute a mapped input for a module with a different value and then continues through the scenario. The Ignore directive will well ignore the error with that specific bundle. The Break directive allows you to store the error as an incomplete execution on the scenario with options to retry or fix the bundle with the error. There are settings on the break directive which allow you to specify the number of times a bundle should be given another chance and the time in between tries before logging the run as an incomplete execution. This directive may be useful for situations where a third party platform experiences timeout errors. You may decide to use the sleep module in conjunction with the break directive on an error handling path to avoid multiple bundles running into the timeout error, pausing the processing of bundles for a specified amount of time. Now, there is one more type of error handling that you wouldn’t consider a directive. When choosing to add error handling to a specific module, you can use a module or create a path of multiple modules to execute on a bundle when an error occurs. Using this method might be helpful when wanting to log the errors in the table or return a response to a connection or user that an error has occurred with the data sent through your scenario. To understand the directives which stop your execution, let’s first review how scenarios are run. Fusion is a transactional system similar to relational databases. Each scenario execution starts with the initialization phase, continues with at least one cycle composed of the operation and commit or rollback phases and ends with the finalization phase. When you use the rollback directive, the scenario execution is stopped immediately and a rollback phase is started on all the modules in an attempt to revert them all to their initial state. Some modules do not support rollback and operations performed by these modules can’t be taken back. Scenario deactivation will typically happen after the specified number of errors occurs. Going back to tool tip number one on knowing the defaults, the rollback directive is actually the default behavior if no error handler route is attached to a module and you aren’t storing incomplete executions. For the commit directive, your scenario execution is stopped immediately and a commit phase is started on all modules meaning that fusion will send information to all the services involved in the operation phase about its success. You’ll notice that in the execution history, this will be viewed as a successful execution. It will be a rare case that you use this commit directive and it’ll typically be tied at the end of your scenario when you don’t care to track the error that has occurred. Tool tip number four and your last for right now is that you should use one of the error handling directives when working with iterator and aggregator bundles. Errors that do occur with these iteration aggregation combinations will be treated as breaking errors where a single bundle error will stop the execution of unprocessed bundles. In legacy fusion, using directives within iteration and aggregation combinations would be similar to the list function for each ignore errors. -