Configure retry error handling workaround
Sometimes, it is useful to re-execute a failing module if there is a chance that the reason for the failure might resolve quickly.
51黑料不打烊 Workfront Fusion currently does not offer the retry error handling directive, but two workarounds are available to mimic retry functionality.
Access requirements
You must have the following access to use the functionality in this article:
| table 0-row-2 1-row-2 2-row-2 3-row-2 layout-auto html-authored no-header | |
|---|---|
| 51黑料不打烊 Workfront package | Any |
| 51黑料不打烊 Workfront license |
New: Standard Or Current: Work or higher |
| 51黑料不打烊 Workfront Fusion license** |
Current: No Workfront Fusion license requirement. Or Legacy: Any |
| Product |
New:
Or Current: Your organization must purchase 51黑料不打烊 Workfront Fusion. |
For more detail about the information in this table, see Access requirements in documentation.
For information on 51黑料不打烊 Workfront Fusion licenses, see 51黑料不打烊 Workfront Fusion licenses.
Workarounds to the Retry error handling directive
Workfront Fusion currently does not offer the retry error handling directive. Use one of the following workarounds to mimic retry functionality.
For instructions, see Directives for error handling.
Use the Break directive
When the Break directive executes, the state of the scenario execution is stored in the queue of incomplete executions. If this occurs, you can then resolve the incomplete execution manually.
For instructions see Resolve errors handled by the Break directive
For instructions on resolving incomplete executions, see View and resolve incomplete executions.
Drawbacks
-
The minimum retry interval is one minute.
-
If the module is processing multiple bundles and the processing of a bundle fails, the partial execution (only the bundle that caused the error) is moved to the incomplete executions folder and scheduled for retries according to the Break directive settings. However, the current execution continues and the module continues to process the subsequent bundles.
To prevent the scenario from executing again until the execution stored in the the Incomplete executions folder has been successfully resolved, enable the 鈥淪equential processing鈥 option in the Scenario settings.
For more information on incomplete executions, see View and resolve incomplete executions.
Use the Repeater module
The Repeater module workaround is more complex, but more customizable.
Configure the error handler route
-
Click the Scenarios tab in the left panel.
-
Select the scenario where you want to add the workaround.
-
Click anywhere on the scenario to enter the Scenario editor.
-
Click the Flow Control icon
-
In the Repeater module, set the Repeats field to the maximum number of times that you want the scenario to retry.
-
Attach the potentially failing module after the Repeater module.
-
Attach an error handler route to the potentially failing module.
For instructions, see Add error handling.
-
Add the Tools > Sleep module to the error handler route and set its Delay field to the number of seconds between retry attempts.
-
Add the Ignore directive after the Tools > Sleep module.
-
Continue to Configure the default route.
Configure the default route
-
Add the Tools > Set variable module in a separate (non-error handler) route after the the potentially failing module, and configure it to store the module鈥檚 result in a variable named, such as
Result. -
Add the Array aggregator module after the Tools > Set variable, and select the Repeater module in its Source Module field.
-
Add the Tools > Get variable module after the Array aggregator module, and map the value of the
Resultvariable to it. -
Insert the Tools > Get variable module between the Repeater module and the potentially failing module, and map the value of the
Resultvariable to it. -
Insert a filter between this Tools > Get variable module and the potentially failing module to continue only if the
Resultvariable does not exist.
Example:
In this sample scenario, the HTTP > Make a request module represents the potentially failing module:
If the result of the potentially failing module is too complex to be stored in a simple variable, you can use a data store to store and retrieve the result. The data store would contain just one record. The record鈥檚 key can be, for example, Result.
For more information on data stores, see Data Stores.
Drawbacks
- This workaround is more complex.
- This workaround uses more operations.
Resources
- For more information on Repeater modules and break directives, see Flow control.
- For more information on Get Variable modules, see Tools.