Using Conditions to Enhance Workflow Operations

by marjo martinez, in Tech Talk, posted 1/5/09

In AutoMate BPA Server 7, conditions, formerly known as triggers, are objects that can initiate the execution of workflows or tasks based on system and application events that occur in your network. The evolution from triggers to conditions is mainly due to workflows which have been introduced in BPA Server 7. Conditions are much more powerful than triggers because - in addition to initiating workflow execution - they can also provide conditional decision-making at the workflow level.

The conditions in AutoMate BPA Server 7 enable a workflow's path to branch depending on whether or not a particular system or application event has transpired. Additionally, conditions can give a workflow the ability to wait (by suspending its execution) until a specified event takes place. Such capabilities can be managed and controlled in the properties of any condition under the Behavior tab (as shown in Figure 1-1).

Figure 1-1 - Behavior Tab Properties of a File Condition


This article will supply details in regards to the various behavioral properties of an AutoMate condition, as well as provide information on how to properly manipulate these properties in order to allow sophisticated conditional decision-making in workflows.

 

Condition Behavior - Overview

All available conditions in AutoMate BPA Server 7 possess a Behavior tab which includes variety of options that dictate how a given condition will behave. These options tell the workflow whether or not to wait for a particular event to occur. If the workflow is instructed to wait, other options are available that tell it how long, and optionally, how often to wait for the specified event to occur. The Behavior tab options are identical in every condition. A condition's Behavior tab properties can be accessed from within the Workflow Designer (WFD) by double-clicking on it or right-clicking the condition and selecting Edit from the right-click menu. A dialog showing the properties of that condition will appear. Simply navigate to the Behavior tab to access its behavioral properties. Alternatively, conditions can be accessed from the Repository in Server Management Console (SMC). Here, you can select the desired condition from the Conditions folder and clicking the Edit button, or right-clicking the condition and selecting Edit from the right-click menu, then navigating to the Behavior tab. Behavior Options A condition's Behavior tab contains two main options to select from:

  1. Wait for condition - Indicates that the system will wait for the specified condition to occur before proceeding.
  2. Don't wait, execute immediately - Indicates that the system will not wait. Instead, it will evaluate whether the specified condition is true or false, and then proceed directly after. When the option labeled Wait for condition is selected, the following sub-options become available:
  • Indefinitely - This option tells the system to wait indefinitely for the specified condition to be met. The system will wait for as long as it needs to until the condition occurs.
  • Timeout after - This option tells the system to wait for a certain amount of time for the condition to be met. If the specified condition is not met within the amount of time specified, a timeout occurs.
  • Ignore pre-existing condition - This option tells the system to ignore corresponding conditions that exist before the specified condition is executed. For example, a Window condition set to monitor for an Internet Explorer window to appear is located in the middle of a workflow. If an Internet Explorer window already exists on the system when the workflow reaches the Window condition, it will ignore the currently open Internet Explorer window and wait for another instance of Internet Explorer to appear before following the assigned wait instructions.
  • Trigger after the condition has been met - This option tells the system to continue waiting until the condition has been met the specified amount of times. For example if the same Window condition is set to trigger after the condition has been met 3 times, it will wait for 3 new instances of the Internet Explorer window to appear on the system before following the assigned wait instructions.

 

Setting Behavior Options

A condition can be used to trigger the start of a workflow only under certain circumstances. First, the condition cannot include a parent object. In other words, the specific condition needs to be the first object within the workflow, and therefore, no flow control arrows from previous tasks, events, conditions or other objects can be pointing to it. Second, the condition's Behavior tab option labeled Wait for condition must be selected (as opposed to the option labeled Don't wait, execute immediately). This allows the system to wait for the specified event or condition to occur. When the option Wait for condition is selected in conjunction with the sub-option Indefinitely, the system will wait an indefinite period of time for the event or condition to occur. For example, the beginning of a workflow can contain a File condition to wait for File X to exist in Folder Y and automatically execute Task A when such an event occurs, as shown in Figure 1-2. This is the most common behavior for setting a condition to act as a trigger. NOTE: The default Behavior tab options of a newly created condition are automatically set to Wait for condition and Indefinitely.

Figure 1-2 - File Condition Used as a Trigger

A condition can also be set to trigger the start of a workflow or task after a particular event has transpired a certain amount of times. This can be performed by enabling the option Trigger after the condition has been met and selecting the amount of times the condition should occur before the trigger becomes active. For instance, a Process condition can be set as the first object in a workflow to monitor for the Notepad.exe process to start a total of 3 times before triggering the execution of Task A, as illustrated in Figure 1-3.

Figure 1-3 Process Condition Used as a Trigger

Note that when a workflow containing a trigger is executed manually, for example, by clicking the Run button in Workflow Designer, the initial condition (which acts as a trigger) is ignored. This feature enables developers to test their workflows in Workflow Designers without having to wait for or manufacture triggering conditions. However, all other conditions that may exist in the workflow will execute as normal. To set a condition to wait for a specific event to transpire in the middle of a workflow (i.e. when it is not the first item in the workflow), select the option labeled Wait for condition along with the sub-option Timeout After and enter the desired amount of time for the condition to wait. In this case, the workflow will proceed if the chosen condition is met within the time specified. If it is not met, a timeout occurs. For example, a Window condition can be used in the middle of a workflow to wait for the Internet Explorer window to appear before proceeding to Task B. If Internet Explorer does not appear within 1 minute from the time the workflow arrived at this condition, a timeout will occur, as shown in Figure 1-4. The sub-option Wait Indefinitely can be selected, however, the workflow will wait forever if the specified condition never occurs.

Figure 1-4 - Window Condition Used as a Wait Element

A condition can be set to delay an active workflow until a particular event has occurred a specific number of times by enabling the option Trigger after the condition has been met and selecting the amount of times the event should occur before the workflow continues. Additionally, a condition can determine the direction of a workflow depending on the outcome as a result of the wait. For example, a Window condition can be used in the middle of a workflow to wait for the Internet Explorer window to appear a total of 3 times within 3 minutes. If this occurs, the condition returns "True" and therefore follows the Success flow control arrow to Task B. If Internet Explorer does not appear 3 times within 3 minutes, the condition returns "False" and therefore proceeds to the Failure arrow pointing to task C. This is illustrated in Figure 1-5.

Figure 1-5 - Window Condition Used to Wait for IE to Appear 3 Times

A condition can also be used as an "If" statement in the middle of a workflow. This can be accomplished by selecting the Behavior tab option labeled Don't wait, execute immediately. When this option is selected, the system will not wait but rather, it will evaluate the specified condition immediately, and then proceed. For example, a File condition that resides in the middle of a workflow can be used to evaluate if File A exists in Folder B. If so, the condition is successful and therefore proceeds to the Success flow control arrow pointing to Task C. If not, the condition fails and continues to the Failure arrow which points to Task D. This is illustrated in Figure 1-6.

Figure 1-6 - Condition Used as an "If" statement

 

Conclusion

Conditions replace triggers in BPA Server 7 for the simple fact that these objects are much more powerful in BPA Server. Conditions can influence workflows in a number of ways. They can be used at the beginning of a workflow as a "triggering condition" (a condition which starts a workflow), but also at any point inside the workflow to cause it to wait for a condition occur as well as decide which path a workflow should take depending on event(s) that may or may not transpire.