How's that for a title? The driver for this post is that I'm training a lot of folks right now on using WF to build workflows, and when we cover correlation, the example we use has two branches in a parallel activity where we correlate within each branch. The question inevitably comes up about how to do this dynamically, where the number of "branches" is driven by data. So, I whipped up this example that uses code from the Microsoft Windows Workflow Foundation Labs (Beta 2) to showcase the Replicator Activity and the Conditioned Activity Group (CAG). These two activities provide for richer models of business rule or data driven replication using correlation.
In order to enable my example, I have created a composite activity that wraps up the voting behavior found in the communications lab. This gives me a reusable component that I can then use in multiple places in my workflow, and it also gives me the ability to set properties on the set of activities (now my single composite activity) for each instance. For example, one of the key properties I can set is the alias, or name, of the user who should vote. In addition, I can define events at the composite activity that my workflow can listen for and handle. This allows my workflow to take action when a voter approves or rejects a ballot. Finally, I define a correlation token within the activity and set the parent activity to the composite activity itself. This provides the context in which my correlation token is valid and is the key to allowing me to correlate within each activity. Note that it is not required that you do this in a composite activity, the parent activity for your correlation token can be a sequence or some other container. Finally, I added a property to my workflow called Aliases of type List<string> which holds the data for my workflow. I pass in this data from program.cs via parameters to the workflow.
In my workflow, I have two main activities, the first is a replicator which shows how to use this activity to do data driven correlated activities, and the second is the Conditioned Activity Group which allows you to use rules/conditions to determine what branches of activities to run, and when I am done running them.
The replicator activity in my example has the InitialData property bound to the workflow property for aliases, so I am going to run whatever activities are in the replicator as many times as I have items of data. I also need to pass that data to each instance of the voting activity before it is executed (specifically, the alias it should use). I use the Child_init event on the replicator to set the alias based on the current data item. The current data item lets me get the current item in my collection of data and I can then use that to configure the currently executing activity or set of activities. I also set the execution type property on my replicator to indicate if I want all the branches to run in parallel, or in sequence. Very powerful option!
For the CAG, I have included two voting activities, and bound their aliases to two different instances of input data on the workflow. I've done this using indexed values from the List<string> property. When dealing with a CAG, you have to set the "when" property on each branch of execution which indicates the rule or code to determine if the particular branch should execute. On the CAG itself, you provide a "Until" property that likewise specifies code or rules, but these provide the condition under which execution should stop. So, the CAG will continue running (foreach/while style looping) until the "Until" condition is met. On each interation, it will use the "when" condition on each activity branch to determine whether it should run that branch. So you get replication, but with rules to guide it. You get a lot more than that, but this is a simple example.
When you run the program, it might help to disable one activity and focus on the output by the other. Running the replicator will give you three vote dialogs, each with the appropriate users name, and the console will appropriately log their votes. We correlate the response back into the workflow on each instance of the votingactivity. When you run the CAG, you'll see that the first time through, both voting activities will run. Until you vote "yes" on one of the items, the CAG will continue to run and use the "when" condition to determine which activity branches to run. Play around with your voting and notice what happens if you continue to vote no with one person for a few rounds, then vote yes.
The final thing to notice is that we have a need to catch the situation, with our CAG, where someone voted yes, but the other person has not yet responded. If we don't deal with this scenario, when the second person votes, they will get an exception. We use the WorkflowQueueInfo data from the workflow instance to query the workflow and see if it is waiting for any responses. If it is not, then we gracefully exist instead of trying to raise the event. If it is, then we go ahead and raise the event. This is one way you can attempt to avoid the EventDeliveryFailedException.
Hopefully these examples will prove useful for someone. I plan to do my best at creating more examples to share. As always, feedback is welcomed. You can get the code
here.
Subscribe