Issues and Standards for Error Handling within Workflows in PowerCenter 7.1.

3
Prepared by Kevin Gillenwater - 9/18/03 (Updated 10/6/04*)
(Updated 10/2005)

Background:

Issues have been raised regarding the correct handling of errors in workflow sessions, connectors, and worklets.
This document clarifies the standards that should be followed in the development of new workflows for eventual
propagation to the Production environment. Additionally, workflows that are in the current Development and QA
environments should be reviewed to ensure that they meet the standards. This document is intended to be used in
most scenarios, but is not all inclusive of the error handling that may be done in a workflow.

The central issues surround connector, session and worklet error handling. For purposes of this document, and in
the attempt to minimize confusion, five scenarios are presented with the issue being raised and the standard that
should be followed when dealing with each. The scenarios are:

1. A workflow that contains a stand-alone session task.

2. A workflow that contains concurrent session tasks.
3. A workflow that contains sequential session tasks.
4. A workflow that contains concurrent worklet tasks (with session tasks in each).
5. A workflow that contains sequential worklet tasks (with session tasks in each).

Scenario 1: Workflow containing a stand-alone session task

The below picture depicts a workflow containing a stand-alone session task. Note below that the session does not
have any of the properties checked under the ‘General’ tab for error handling.

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 workflow’s 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.).
Scenario 1: Standard and Solution
The box ‘Fail parent if this task fails’ should be checked to correct the above Scenario. With this box checked, if
the individual task were to fail, the workflow’s status would be returned as ‘Failed’. The workflow is the parent of
the session task. In this event, the scheduling tool would receive a status of ‘Failure’ and appropriate alerts 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 in the event that the session task does
not run. If it runs (even though it fails), the workflow’s status is still ‘Succeeded’.

Scenario 2: Workflow containing concurrent session tasks

The below picture depicts a workflow containing concurrent session tasks. Note that the sessions do not have any of
the properties checked under the ‘General’ tab for error handling.

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 workflow’s 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 e-
mail notification, etc.).

Scenario 2: Standard and Solution

The box ‘Fail parent if this task fails’ should be checked in all session tasks to correct the above scenario. With this
box checked, if task/s were to fail, the workflow’s status would be returned as ‘Failed’. The workflow is the parent
of the session tasks. In this event, the scheduling tool would receive a status of ‘Failure’ and appropriate alerts
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 in the event that the
session task does not run. If it runs (even though it fails), the workflow’s status is still ‘Succeeded’.

2
Scenario 3: Workflow containing sequential session tasks
The below picture depicts a workflow containing sequential session tasks. Note that the sessions do not have any of
the properties checked under the ‘General’ tab for error handling, nor is there any error handling in the Connector
between the sequential session tasks.

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 workflow’s 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 e-mail notification, etc.).

Scenario 3: Standard and Solution

Two standards/ solutions should be followed in this scenario:
1. The box ‘Fail parent if this task fails’ should be checked in all session tasks to correct the above scenario.
With this box checked, if a task were to fail, the workflow’s status would be returned as ‘Failed’. The
workflow is the parent of the session tasks. In this event, the scheduling tool would receive a status of
‘Failure’ and appropriate alerts 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 in the event that the session task does not run. If it runs (even though it fails), the
workflow’s status is still ‘Succeeded’.

3
 2. Part one of the solution ensures that the workflow’s 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.

Scenario 4: Workflow containing concurrent worklets

The below picture depicts a workflow containing concurrent worklets. For purposes of this scenario, the assumption
will be made that the session tasks within each worklet are concurrent. Note that neither the worklets, nor the
session tasks within each worklet have any of the properties checked under the ‘General’ tab for error handling.

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

4
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.

Scenario 4: Standard and Solution

The box ‘Fail parent if this task fails’ should be checked in all session tasks within each worklet AND for all
worklets themselves to correct the above scenario. With this box checked, if task/s were to fail, the worklet/s status
would be returned as ‘Failed’. In return, once the worklet/s failed, the workflow would be forced to fail. In this
event, the scheduling tool would receive a status of ‘Failure’ and appropriate alerts 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 workflow’s status is still ‘Succeeded’.

Scenario 5: Workflow containing sequential worklets

The below picture depicts a workflow containing sequential worklets. For purposes of this scenario, the assumption
will be made that the session tasks within each worklet are concurrent. Note that the worklets, nor the session tasks
within each worklet, have any of the properties checked under the ‘General’ tab for error handling. Additionally,
there is no error handling in the Connector between the sequential worklets.

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.

Scenario 5: Standard and Solution

Two standards/ solutions should be followed in this scenario:
1. The box ‘Fail parent if this task fails’ should be checked in all session tasks within each worklet AND for
all worklets themselves to correct the above scenario. With this box checked, if task/s were to fail, the
worklet/s status would be returned as ‘Failed’. In return, once the worklet/s failed, the workflow would be
forced to fail. In this event, the scheduling tool would receive a status of ‘Failure’ and appropriate alerts
5
 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 workflow’s 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.