Workflow Logic Explained

AutoMate BPA Server was designed with the ability to describe business processes in a repeatable, reli­able manner using intuitive logical constructs. When people can "see" logic, they immediately understand it. This greatly improves communication and collaboration, which is essential when designing business processes that help employees function more effectively and efficiently. Consequently, AutoMate BPA Server provides a number of ways to express and incorporate logic into automated business pro­cesses.

The most common and familiar method of imbedding logic into a process is within a task. There are a variety of AutoMate actions that incorporate logic into a task, many of which are located in the "Flow" action group of the Task Builder. The most commonly used logic actions are the "If" actions, which all work in generally the same manner - they evaluate a specified condition (for example, whether a text file is present on c:\), and if that condition is true, the steps between the "If" step and its corresponding "Else" or "End If" steps are exe­cuted. This method is useful for imbedding detailed logic that business workers and colleagues don't really need to see or understand.

With the advent of AutoMate BPA Server, automation developers have a new layer of logic they can add to processes at the Workflow level. This logic is highly visual and should be reserved for key process splits, junctions, and decisions that business users and colleagues need to see and understand. Otherwise, if too much logic is put into the workflow, it can become cluttered and unreadable - exactly opposite of what workflow logic is designed to do.

Workflow logic is expressed with a combination of Arrows, the Evaluation object, Conditions, and even Tasks. The arrow objects are the glue that binds all the other objects together and makes a workflow a cohesive unit. There are three types of arrows (Result, Success, and Failure), and at first glance, these all seem pretty self-explanatory. However, arrows can behave differently depending on which object is their parent (i.e. which object they stem from). They don't simply connect two objects together, but they have fundamental meaning as well.

To get a better understanding of arrow behavior, and to learn the do's and don'ts of arrows, learning by exam­ple is the best approach. The following cases will illustrate the basics of incorporating workflow logic into an automated processes. Result arrows are always dashed blue, Success arrows are green, and Failure arrows are red.

In CASE 1 through CASE 5, we will examine arrow behavior when the arrows stem from the Evaluation object. CASE 6 through CASE 10 deal with arrow behavior when the arrows stem from Conditions. And the balance of cases deals with arrow behavior associated with Tasks.

 

CASE 1:

Here the Evaluation Object is 3=4. We all know this is not true, so what should happen in the following workflow?

Downstream Flow:

1.   Failure arrow proceeds to Task 2

2.   False arrow proceeds to Task 4

All other paths stop. Tasks 1, 3, and 5 do not execute.

Explanation:

The expression 3=4 evaluates to False. Evaluation objects treat a True Result as a Success and a False Result as a Failure. Consequently, the path will follow both the False Result arrow and the Failure arrow.

Best Practice:

To avoid confusion, always use the Result arrow to stem from Evaluation objects. The Result arrow provides all the functionality you will need, plus it is clearer than using Success or Failure arrows for evaluation objects.

 

CASE 2:

Here the Evaluation Object is 4=4. We all know this is true, so what should happen in the following work­flow?

Downstream Flow:

1.   Success arrow proceeds to Task 1

2.   True arrow proceeds to Task 3

All other paths stop. Tasks 2, 4, and 5 do not execute.

Explanation:

The expression 4=4 resolves to True. Evaluation objects treat a True Results a Success, and a False Result as a Failure. Consequently, the path will follow both the True Result arrow and the Success arrow.

 

CASE 3:

Here the Evaluation Object is set to the value of myVariable. The item myVariable is the name of a shared variable defined within the workflow. This variable is populated with the value of 5. What should happen in the following workflow?

Downstream Flow:

1.   5 arrow proceeds to Task 5

All other paths stop. Tasks 1, 2, 3, and 4 do not execute.

Explanation:

The evaluation object returned 5. Only a Result arrow with a corresponding value of 5 will execute.

 

CASE 4:

Here the Evaluation Object is set to the value of myVariable. The item myVariable is the name of a shared variable defined within the workflow. Unlike case 3, this time the variable has a value of 3. What should happen in the following workflow?

Downstream Flow:

All paths stop. No tasks execute, but the workflow does not fail. It completes successfully.

Explanation:

The evaluation object returned 3, which is not equivalent to Success, True, 5, Failure, or False.

 

CASE 5:

Here the Evaluation Object is 4=*+/=4. The syntax of this expression is wrong. It cannot be resolved to any value. What should happen in the following workflow?

Downstream Flow:

All paths stop. No tasks execute, and the Workflow fails. It does not complete successfully.

Explanation:

The expression 4=*+/=4 is a code syntax error. The Workflow should fail and stop.

Arrows stemming from Condition object function similarly to the way they function with the Evaluation object. It is important to know that Conditions cannot fail in their execution. Conditions can resolve to False or 0 and therefore proceed down a Failure arrow path, but they cannot fail in their execution. For example, a File Condition object waiting indefinitely for a text file to appear on C:\ cannot fail to see a new text file appear, and at the same time, be aware that it failed to see the new text file appear.

 

CASE 6:

Here the Condition Object is "Wait indefinitely for C:\*.txt". In other words, the File condition will wait indefinitely for a text file to appear in C:\. This is done by setting the Behavior tab of the File condition to Wait for condition and Indefinitely. What should happen when a text file eventually arrives in C:\?

Downstream Flow:

1.   Success arrow proceeds to Task 1

2.   True arrow proceeds to Task 3

All other paths stop. Tasks 2, 4, and 5 do not execute.

Explanation:

The Condition resolves to True. Consequently, the path will follow both the True Result arrow and the Suc­cess arrow.

 

CASE 7:

Here the Condition Object is "Wait for a text file to appear on C:\, Time-out after 10 seconds of wait­ing". This is done by setting the Behavior tab of the File condition to Time-out after 10 seconds. What should happen when a text file doesn't arrive in C:\ after the condition has been active for 10 seconds?

Downstream Flow:

1.   Failure arrow proceeds to Task 2

2.   False arrow proceeds to Task 4

All other paths stop. Tasks 1, 3, and 5 do not execute.

Explanation:

The Condition resolves to False. Consequently, the path will follow both the False Result arrow and the Failure arrow.

 

CASE 8:

Here the Condition Object is "Wait for a text file to appear on C:\, Time-out after 10 seconds of wait­ing". This is done by setting the Behavior tab of the File condition to Time-out after 10 seconds. What should happen when a text file arrives in C:\ within 10 seconds?

Downstream Flow:

1.   Success arrow proceeds to Task 1

2.   True arrow to proceeds Task 3

All other paths stop.  Tasks 2, 4, and 5 do not execute.

Explanation:

The Condition resolves to True. Consequently, the path will follow both the True Result arrow and the Suc­cess arrow.

 

CASE 9:

Here, the Condition Object is "Does C:\*.txt exist". This is done by setting the Behavior tab of the File condition to Don't wait, execute immediately. What should happen if a text file is present on C:\?

Downstream Flow:

1.   Success arrow proceeds to Task 1

2.   True arrow proceeds to Task 3

All other paths stop. Tasks 2, 4, and 5 do not execute.

Explanation:

The Condition resolves to True. Consequently, the path will follow both the True Result arrow and the Suc­cess arrow.

 

CASE 10:

Here, the Condition Object is "Does C:\*.txt exist". This is done by setting the Behavior tab of the File condition to Don't wait, execute immediately. What should happen if a text file is not present on C:\?

Downstream Flow:

1.   Failure arrow proceeds to Task 2

2.   False arrow proceeds to Task 4

All other paths stop. Tasks 1, 3, and 5 do not execute.

Explanation:

The Condition resolves to False. Consequently, the path will follow both the False Result arrow and the Failure arrow.

 

CASE 11:

Here the Task Object fails during execution. What should happen in the following workflow?

Downstream Flow:

1.   Failure arrow proceeds to Task 2

2.   False arrow proceeds to Task 4

All other paths stop. Tasks 1, 3, and 5 do not execute.

Explanation:

The Task results in a Failure and can only proceed down a Failure arrow path.

 

CASE 12:

Here the Task Object executes completely and successfully. What should happen in the following workflow?

Downstream Flow:

1.   Success arrow to Task 1

2.   True arrow to Task 3

All other paths stop. Tasks 2, 4, and 5 do not execute.

Explanation:

The Task completed successfully, and proceeds down both the Success and True arrow paths.

See Also

About Workflows

Building a Workflow