This component catches hanging paths in a model and triggers its own path. A hanging path is any unhandled output path. A hanging path can come from any component with an output path.
There are three Hanging Path Trigger components:
| Component |
Description |
| Hanging Path Trigger |
Catches any hanging path in its own model |
| Hanging Path Trigger by Components |
Catches hanging paths from a user-defined list of components in the model |
| Hanging Path Trigger by Path |
Catches hanging paths of a certain name (for example, "OK" or "Cancel") |
Example
Webform Survey Data Capture
Scenario: A company launches a Webform survey for their customers to fill out. Because the survey is somewhat lengthy, the company knows that some users will only fill out a few fields and then leave the survey. In order to preserve whatever data was
entered, the workflow process is set up to capture all entered data, even if the user cancels the form.
Process: This process is created as a Webforms project type. Here's what it looks like:
A series of Form Builder components comprise the Webform survey. Notice that none of the "Cancel" output paths are handled; that is, they have no outbound connection. Usually, if the components were set up like this they would all be invalid because they have hanging paths. The Hanging Path Trigger component makes the model valid because it catches any hanging path. This example uses the basic Hanging Path Trigger component. It could use the Hanging Path Trigger by Components version (set to watch the Form Builder components for hanging paths) or the Hanging Path Trigger by Path version (set to watch the "Cancel" output path).
The main reason for using the Hanging Path Trigger component is to avoid unneccesary paths cluttering the workspace. In this simple example, attaching all the "Cancel" outcome paths to the Variables Exist component is not difficult. On the other hand, in a much larger workflow process, it may be very difficult. The Hanging Path Trigger component provides a tidy alternative to messy outcome paths.
Of course, the desired outcome is that all users would complete the survey, and enter data in all of the fields. If this happens, the Upload data to database component saves the data in a database. However, many users probably will not have tha patience to complete the survey, and will cancel before finishing.
When a user cancels before finishing the survey, the Hanging Path Trigger is invoked. When this happens, the process data retrieved in the forms is invisible to the new path, because it is not downstream from the Form Builder components. A Variables Exist component solves this problem by locating and exposing all available data in the process.
NOTE: When the Hanging Path Trigger is invoked, your process loses access to all its data. As in the current example, use a Variables Exist component (or alternative) to expose process data to the new stream.
Other components in this example
- Form Builder
- Custom component
This component was created with the Integration engine. For more information on the Integration Engine, see the Workflow Solution Administrator's Guide.
www.altiris.com/support/documentation.aspx
- Variables Exist
Extra notes
The Hanging Path Trigger component is similar to the Exception Trigger component.
The difference between the components is that one handles errors (exceptions) while the other handles normal execution (outcome paths). The Hanging Path Trigger component helps you create a more cleanly-designed workflow, while the Exception Trigger component helps you create a more stable workflow.
Other usage idea