Figure 2 Condition Editor for IfElse Activities

The final branch in an IfElse activity can lack a condition. In this case, it will work as the Else branch of the IF workflow statement.

The second way to specify a condition is through ad hoc code. In this case, you enter a method name and double-click (or press Enter), and VSTA will be launched with a new method named as specified returning a bool.  Edit this code as appropriate to return the appropriate condition value.  You can also select an existing condition method from the drop-down.

IfElse activities can be nested to express complex logic, but the design of the logic remains hardcoded in the workflow. This is good and bad at the same time. It’s a good thing because it allows you to design the workflow exactly as you want and integrate it with the rest of the activities. It’s a bad thing when you need to create a set of rules to initialize portions of the workflow’s state. Having a bunch of IfElse activities only to assign values to internal members of the workflow is clearly overkill.

You should use a combination of IfElse activities when you really need to control the flow of the workflow and orchestrate various blocks of the work. If what you need is just a sequence of programmatic If statements with simple code attached to branches, then you’re better off using a Policy activity. A Policy activity is a collection of rules. The code associated with each rule, though, is limited to setting a property on a workflow or calling a workflow method or a static method on types in referenced assemblies.

The activity is associated with a sorted collection of rules that you define through the editor. Each rule has a priority and an Active property. The combination of the two properties determines whether the rule should be evaluated and with which priority. In addition, a rule must specify a reevaluation behavior—Always (default) or Never. If set to Always, the rule is reevaluated as needed, otherwise it is evaluated only the first time and never changes whatever happens to the workflow’s state.

Instead, the rule set as a whole is subject to forward chaining. Simply put, forward chaining refers to the ability of the actions of one rule to cause other dependent rules to be reevaluated. For example, an action that updates the value of a field that another rule tests requires a reevaluation of the involved rules (unless reevaluation is disabled on the rule).

There are three types of forward chaining.

Implicit chaining indicates that the runtime engine will figure out which fields are modified by some actions and automatically reevaluate them. This mechanism succeeds as long as actions work on properties explicitly. What if you have an action like the following:

IF this.MinimumLength <= 8 THEN RefreshInternalState()

Who knows what the RefreshInternalState method is going to do? The method might touch on workflow properties that are involved with other rules in the policy activity. By using attributes on the method declaration, you can explicitly indicate the behavior of the method:

<RuleWrite(”PasswordLevel”)>
Public Sub RefreshInternalState( )
    Me.PasswordLevel = 1
End Sub

The RuleWrite attribute indicates that the method is going to modify the specified property; likewise, the RuleRead attribute indicates that the method reads from the specified properties. In this way, unequivocal information is provided to the runtime engine to keep the rule set in sync.

Finally, you can write actions that explicitly call out updates on involved properties. Here’s an example:

IF this.MinimumLength <= 8 THEN
    RefreshInternalState()
    Update(”PasswordLevel”)

The Update method in the rule action orders the reevaluation of all rules that include the specified property.

NOTE In Blue Integrator, only methods defined in Visual Studio for Applications for which you have specified the BlueIntegrator.Workflow.MethodVisible attribute will be available for use within the Rule editor.  Note also that you cannot define Properties in Visual Studio for Applications for use in the Rule editor.

Loops and Repeated Activities

The native set of activities provides classic While activity as well as a Replicator activity that has some points in common with a classic For loop. The While activity accepts a condition and evaluates it at the beginning of each iteration. If the condition is true, the activity runs the specified child activity and repeats until the condition becomes false. Note that a single activity is permitted in the body of the While. For this reason, you might want to use a composite activity (that is, an activity that contains other activities) such as Sequence or Parallel to execute multiple activities in the loop. (The term “interleaved” is probably more appropriate than “parallel” here. There is no true concurrency going on with the Parallel activity, only interleavings within the same thread.)

Similar to a Foreach statement, the Replicator activity creates and executes a given number of instances of the specified child activity. You can specify only one child activity, but using composite or custom activities is allowed. You can’t control the number of iterations through a declarative property. Instead, you write a handler for the Initialized event and populate the CurrentChildData collection with initialization data for each of the desired instances:

Public Sub Replicator1_Initialized()
   Console.WriteLine(”Initializing …”)
   Activities.replicator1.CurrentChildData.Add(”You are #1”)
   Activities.replicator1.CurrentChildData.Add(”You are #2”)
   Activities.replicator1.CurrentChildData.Add(”You are #3”)
End Sub

To set the Initialized handler, enter a handler name for the Initialised event property and double click.  Note how activities are referenced from VSTA with an Activities. prefix.

The preceding code snippet orders three instances of the child activity of the Replicator, each initialized with a given string. Note that if you leave the CurrentChildData collection empty, the Replicator won’t run any child activity and is limited to firing top-level events such as Initialized and Completed. You can initialize child activities using an object (not necessarily a string), including instances of custom classes. The Replicator also includes events to signal initialization and completion of each child activity. By default, child instances run in sequence; by setting the ExecutionType property, though, you can opt for a parallel execution. When a parallel execution is requested, all child activity instances get created before the replicator starts and executes on parallel threads. When working in sequential mode, the next activity is instantiated only when the previous has finished.

If no global condition is set through the UntilCondition property, the Replicator ends when all replicates have completed; otherwise, the activity terminates when the UntilCondition is true. Note, though, that the activity will hang if all the child activities have completed and the UntilCondition property evaluates to false; the Replicator never loops through the child activities like in a While loop. The UntilCondition is evaluated after the global initialization of the activity, after each child activity has completed, and after all included activities have completed. If, at any time, the condition evaluates to true, the Replicator will exit immediately.

You can mix together conditional execution and loops in the ConditionedActivityGroup (CAG) activity. The CAG contains a number of child activities (possibly composite activities) and runs them until a global condition is met. Basically, a CAG combines the behavior of While and IfElse activities. Its internal logic is expressed by the following pseudocode:

While condition
   If child1.WhenCondition Then child1.Execute
   If child2.WhenCondition Then child2.Execute
    :
   If childN.WhenCondition Then childN.Execute
End While

Each child activity has a WhenCondition property. Based on the evaluation of the specified condition, the activity is run or skipped in the current iteration. Note, though, that if the child activity has no WhenCondition set, it is executed only the first time and skipped for all subsequent iterations. All conditions are evaluated whenever required based state change dependencies.

The CAG activity terminates after the UntilCondition returns true and immediately cancels any currently executing activities. If no condition is specified, CAG completes when no child activities are running either because they have no condition set or the condition evaluates to false.

Synchronization Blocks

A sequential workflow that has no interleaved activities doesn’t bother about serializing access to shared members. However, operation is different when a Parallel activity is used with two or more sequences running in an interleaved manner. Take a look at Figure 3. The While activity contains a Sequence block which, in turn, chains Parallel and Code activities. Internally, the Parallel activity has four different blocks, each performing a mathematical operation on a number defined as a member of the workflow class. The four branches in the Parallel activity execute in an interleaved manner. (There is only one thread in a workflow instance at any one time. That thread switches back and forth between the branches of the Parallel activity.) What about cross-task synchronization? By default, each piece of code running inside any of the child activities will perform a direct access to the shared member.