Using Decisions to Determine the Next Step in a Workflow

When a process is completed, the simple success or failure of a process is not always enough to determine the next step to take in a workflow. Decision processes can be used to compare process exit codes, parameters, and other values to provide additional control over the next step to take in a workflow. You can also use decision processes to check for the existence of a file or folder, as well as if the file or folder is empty.

To add a decision process to your workflow, from the Connectors and processes pane, select the Decision icon, and then click in the workflow area. A decision process is created in the workflow, as shown in the image below.

To Compare Parameters, Constants, and Exit Codes

1. Select the option Parameter/Exit Code Comparison.
2. Select to use a parameter or an exit code as the first item for the comparison:
   • Parameter or constant: Select this option to provide a parameter or constant for comparison. You must type the parameter name or the constant value.
   • Previous process exit code: Select this option to use the exit code of the previous process in the comparison. Using the exit code of a process allows you to determine in greater detail why a process was successful or unsuccessful. This allows you to take more specific action to troubleshoot potential problems in a workflow.

   For example, if you attempt to execute a Command Manager script as part of a workflow, this type of process can fail for various reasons. If the process fails with an exit code equal to four, this indicates that a connection could not be made to perform the script. For this exit code, a decision process could lead to a process to start Intelligence Server. However, if the process fails with an exit code equal to six, this indicates that the script has a syntax error. For this exit code, a decision process could lead to an exit process, so the workflow could be ended and the Command Manager script could be manually reviewed for syntax errors.

3. From the Comparison operator drop-down list, select the operator for the comparison.
4. In the Comparison item 2 field, type a value. It is common to type a constant value to compare a parameter or exit code to.

5. In the Output parameters area, you can specify a parameter in the Previous process exit code drop-down list. The parameter specified is updated with the value of the exit code from the process that was completed just before the decision process. You can use this technique if you need multiple decision processes to determine the next course of action, which is described in Using Multiple Decision Processes to Troubleshoot a Workflow below.

   If you do not need to use the exit code from the previous process later in the workflow, you can leave the Previous process exit code drop-down list blank.

To Check for the Existence of a File or Folder

1. Select the option File/Directory Check.
2. In File/Directory Path, type the path to the file or directory to check. You can also click the folder icon to browse to and select a file or directory.
3. From the File/Directory Check Condition drop-down list, select one of the following options:
   • Exists: Select this option to check only if the file or directory exists. The decision process returns as true if the file or directory can be found.
   • Exists and not empty: Select this option to check if the file or directory exists, and if the file or directory is empty. For files, this check verifies that some information is in the file. For directories, this check verifies whether any other files or folders are in the directory. The decision process returns as true if the file or directory exists, and the file or directory has some type of content available.

Using Multiple Decision Processes to Troubleshoot a Workflow

When you are creating a workflow, you can use multiple decision processes to take more specific action on process exit codes and troubleshoot potential problems in a workflow.

When a process in a workflow is completed, it can either be a success or failure. Additionally, certain processes can fail for multiple reasons. Although a single decision process can determine if a process was a success or failure, you need to use multiple decision processes to qualify how a process failed. By qualifying why a process failed, you can more accurately troubleshoot the process and, in some cases, even take action in the workflow itself to fix the problem.

For example, if you attempt to execute a Command Manager script as part of a workflow, this type of process can fail for various reasons. If the process fails with an exit code equal to four, this indicates that a connection could not be made to perform the script. For this exit code, a decision process could lead to a process to start Intelligence Server. However, if the process fails with an exit code equal to six, this indicates that the script has a syntax error. For this exit code, a decision process could lead to an exit process, so the workflow could be ended and the Command Manager script could be manually reviewed for syntax errors. T troubleshooting scenario is shown in the workflow below.

The first decision process (labeled as Success or failure?) can determine whether the Command Manager script was a success or a failure. Additionally, this decision process uses the Previous process exit code to store the exit code for the Command Manager script process into a parameter called Decision. You must use the Previous process exit code to store the exit code for the original Command Manager process so that this exit code can be used in the other decision processes.

In a chain of multiple-decision processes, you should use the Previous process exit code option only in the first decision process. This is because once this exit code is stored in a parameter, you can then reuse that parameter in later decision processes as a comparison item. If you were to mistakenly include the same parameter in the Previous process exit code option for one of the later decision processes, the parameter would be updated to have the exit code of the previous decision process. This would then overwrite the original exit code, which would prevent you from comparing the original exit code in the later decision processes.

If the script was a success, the first decision process allows the workflow to continue. If the script fails, a second decision process is started. This second decision process (labeled as Failed to connect to Intelligence Server?) uses the value previously stored in the Decision parameter to determine if the exit code is equal to four. With an exit code equal to four, this decision process can attempt to start Intelligence Server and then attempt to run the Command Manager script again. If this second decision process fails, which means the exit code is not equal to four, a third decision process (labeled as Script syntax error?) is started.

This third decision process again uses the value that was stored in the Decision parameter by the first decision process to determine if the exit code is equal to six. With an exit code equal to six, this decision process can send an email to a someone to review the Command Manager script for syntax errors, and it can attach the script to the email. Once the email is sent, the workflow is exited. If this final decision process fails, that means the Command Manager script failed for another reason. In this case, the workflow is exited for additional troubleshooting.

When using multiple decision processes to qualify the resolution of a previous process, be aware that as long as you store the original exit code in a parameter, you can use as many decision processes as necessary.

Additionally, this technique of using multiple decision processes is a good practice for processes that are important to the overall success or failure of a workflow. However, using this technique for every process in a workflow could cause the workflow to become overly complex and difficult to create and follow. For example, processes that send emails likely do not require involved troubleshooting in the workflow itself, but a process that attempts to start Intelligence Server may benefit from including potential troubleshooting steps.