Professional Documents
Culture Documents
Standards and Issues For Error Handling in Workflows
Standards and Issues For Error Handling in Workflows
1. 2. 3. 4. 5.
A workflow that contains a stand-alone session task. A workflow that contains concurrent session tasks. A workflow that contains sequential session tasks. A workflow that contains concurrent worklet tasks (with session tasks in each). A workflow that contains sequential worklet tasks (with session tasks in each).
If the task within the workflow fails, the workflow will show a status of Succeeded and the task will show a status of Failed. The Successful status by the workflow is misleading as it indicates that the workflow was successful in executing, NOT THAT THE TASK WITHIN WAS SUCCESSFUL IN RUNNING! This presents a major problem with a scheduling tool as the workflows status is returned as Successful, possibly causing the error to be missed, especially if other error handling is not performed in the task (i.e. post-session e-mail notification, etc.).
If either or both tasks within the workflow fail, the workflow will show a status of Succeeded and the task/s will show a status of Failed. Again, the Successful status by the workflow is misleading as it indicates that the workflow was successful in executing, NOT THAT THE TASKS WITHIN WERE SUCCESSFUL IN RUNNING! This presents a major problem with a scheduling tool as the workflows status is returned as Successful, possibly causing the error to be missed, especially if other error handling is not performed in the tasks (i.e. post-session email notification, etc.).
If either or both tasks within the workflow fail, the workflow will show a status of Succeeded and the task/s will show a status of Failed. Additionally, if the first session task were to fail without the error handling in the connector, the second session task would run, once the first session completed unsuccessfully. In this instance, there are two problems: one, the workflow returns a status of Succeeded while a session task within is unsuccessful; and two, the second session task should not begin to run if the first of the sequential tasks fail. Again, the Successful status by the workflow is misleading as it indicates that the workflow was successful in executing. This again presents a major problem with a scheduling tool as the workflows status is returned as Successful, possibly causing the error to be missed, especially if other error handling is not performed in the tasks (i.e. postsession e-mail notification, etc.).
2. Part one of the solution ensures that the workflows status is returned correctly. However, it does not
prevent the second of the sequential session tasks from running (if the first one failed in the sequence). In order to prevent the second and subsequent tasks from running once the first has failed (in this example), an expression needs to be added to the connector between the tasks which passes a status and only allows the next session task to start if the previous succeeded. The expression can be entered by double-clicking on the connector ($PrevTaskStatus = SUCCEEDED is shown below (left)). The picture to the right shows the workflow with the expression in the connector between the sequential session tasks.
With this scenario, if any tasks fail within the worklet, the worklet will show a status of Succeeded (as it is the parent of the tasks within it). Moreover, if the worklets both succeed, the overall workflow (parent of the worklets) will succeed (even though tasks within worklets have failed!). Additionally, even if all the session tasks within the
worklets have the box checked Fail parent if this task fails and the worklets themselves do not have this box checked, the overall workflow will still report a status of Succeeded since the worklet did not force the parent to fail.
With this scenario, there are at least three issues to be considered: 1. If any tasks fail within the worklet/s, the worklet/s will show a status of Succeeded (as it is the parent of the tasks within it). Moreover, if the worklets both succeed, the overall workflow (parent of the worklets) will succeed (even though tasks within worklets have failed!). 2. If all the session tasks (within the worklets) have the box checked Fail parent if this task fails and the worklets themselves do not have this box checked, the overall workflow will still report a status of Succeeded since the worklet/s did not force the parent to fail. 3. The final issue is in regards to the fact that the worklets are sequential and do not have error handling within the connectors to prevent the subsequent worklet from running if the previous one does not succeed.
would be raised for the attention of the proper staff to rectify the problem. NOTE: DO NOT USE THE CHECKBOX Fail parent if this task does not run. This option only fails the workflow or worklet in the event that the session task or worklet does not run. If it runs (even though it fails), the workflows status is still Succeeded. 2. Part one of the solution ensures that the workflow and worklet/s status is returned correctly. However, it does not prevent subsequent sequential worklets from running (if the first one failed in the sequence). In order to prevent the second and subsequent worklets from running once the first has failed (in this example), an expression needs to be added to the connector between the worklets that passes a status and only allows the next session task to start if the previous succeeded. The expression can be entered by double-clicking on the connector ($Status = SUCCEEDED is shown below (left)). The picture to the right shows the workflow with the expression in the connector between the sequential worklets.