Understanding ParallelActivity in Windows Workflow

Noticias externas — Wed, 12 Sep 2007 15:13:41 GMT

You might think that the ParallelActivity in Windows Workflow Foundation is misnamed. At the very least

Understanding ParallelActivity in Windows Workflow

Kirk Allen Evans' Blog — Wed, 12 Sep 2007 15:05:13 GMT

You might think that the ParallelActivity in Windows Workflow Foundation is misnamed. At the very least,

re: Parallelism in Windows Workflow Foundation (WF)

chakshushah — Thu, 09 Aug 2007 15:09:13 GMT

Is it possible to create this bug-tracking workflow - Sequential workflow on the fly? My workflow designer is hosted on Web.

Zen and the Art of Information Management » SharePoint Workflow: When Parallel is Serial

Mon, 30 Jul 2007 04:19:51 GMT

PingBack from http://www.kcdholdings.com/blog/?p=75

Use Workflow to Invoke Web Services in Parallel

Kirk Allen Evans' Blog — Tue, 03 Jul 2007 16:50:24 GMT

.style1 { color: black; } The very first time I saw Windows Workflow Foundation (WF), I slapped together

Rientranza delle chiamate in WF

Paolo Pialorsi — Wed, 07 Feb 2007 01:21:36 GMT

In questi giorni, a seguito di una consulenza su WF, ho potutoverificare in dettaglio alcuni aspetti

Parallelism in Windows Workflow Foundation

Living in a World of Connected Systems — Thu, 06 Jul 2006 21:10:37 GMT

re: Parallelism in Windows Workflow Foundation (WF)

fanse — Wed, 26 Apr 2006 09:24:10 GMT

ntalbert,Thanks for your so detailed answer,I have thought for a long time,but I never noticed Replcator activity.Now I will model this workflow use state machine workflow,about sequential workflow,because the rejected document will be re edited or re submitted,I fell a little difficult modelling it using Sequential workflow.Thanks again in my heart.

re: Parallelism in Windows Workflow Foundation (WF)

ntalbert — Tue, 25 Apr 2006 22:45:47 GMT

Fanse, you have several options for design here, so let me enumerate a couple and discuss the relative pros and cons.

First, let me clarify the scenario which these solutions will target. This way the comment will still have value (hopefully) even if my details do not match completely with yours.

Scenario:

There is a single workflow instance which manages the approval of a document. When the document is submitted, the workflow is started and the document is in the Submitted state. An unknown number of people will be asked to review the document (based on roles, arbitrary rules, some database - this is not important). A Rejected or Delayed answer from any one person will put the document in the Rejected state and end the workflow. If all reviewers return Approved then the document will be in the Approved state and the workflow will end. (These conditions which cause the workflow to end will be discussed later.)

State Machine Solution:

This solution models the workflow based on the states of the document. As such, there will be four states - Submitted, Approved, Rejected, and Completed. The fourth state is a trigger for the workflow to complete ... we will revisit this later.

The Submitted state will have a state initialization handler which calculates the list of approvers and then notifies them that they must approve the document. How do we notify them? Well, maybe you want to model this as a SendEmailActivity or maybe it is a call to a local service through a CallExternalMethodActivity or possibly it is a custom activity which calls some custom runtime service to add entries to a database. The important thing is this is an implementation detail which we don't need to delve into right now.

Submitted: StateInitialization
<Code Name="CreateApproversList" />
<Replicator Name="ForEachApprover" InitialChildData=ActivityBind("createdApproversList")>
<CreateTask Name="NotifyApprover"/>
</Replicator>

The Submitted state will also have an event called ApproverResponseReceived. Once again, the nature of this event is not important - it might be a HandleExternalEventActivity or it might be a custom activity based on queues. We'll assume that the data delivered by the event is the name of the approval and the response (Approved, Rejected, Delayed). When this event is raised we will check the response and if it is Rejected or Delayed we will move the state machine to the Rejected state. If it is Approved then we will remove the approver's name from our list. If our list is now empty then we move to the Approved state otherwise we stay in the current state.

Submitted: ApproverResponseReceived
<ReceiveResponse/>
<IfElse>
<Branch1 (Response==Rejected || Response==Delayed)>
<SetState State="Rejected"/>
</Branch1>
<Branch2>
<Code Name="RemoveApproverFromList"/>
<IfElse>
<Branch1 (createdApproversList.Count == 0)>
<SetState State="Approved"/>
</Branch1>
</IfElse>
</Branch2>
</IfElse>

The Approved and Rejected states both notify the host of the result (or set an appropriate outbound parameter) and then move to the Completed state which causes the workflow to exit.

Benefits:

This solution has the benefit of mapping directly to how you thought of your problem. The workflow will be in a state corresponding to the document state. Additionally, if you want to allow resubmission of the document from the Rejected state then it would be a simple task to add a new event handler to Rejected which transitions the workflow back to the Submitted state.

Drawbacks:

This solution does not, however, have nice handling of the approvers. Imagine that we wanted to do something more complex with the approvers such as allow them to delegate the task, remove themselves from the list, or have specific flow based on their inputs. It could all be modeled with event handlers in the state machine which all pass the approver's name as a parameter but this is not as nice as the Sequential Solution which we will show below.

Sequential Solution:

We'll start in the same place with a CodeActivity which generates the list of approvers. This will then be fed to a Replicator which, this time, contains a more complex child which will run instances in parallel.

The Replicator's child will be responsible for handling the entire interaction with one approver. In our case this is simply to notify the approver of the waiting task and then wait for the approver's response. We will make use of the ExternalDataExchangeService correlation features to map an inbound event to the correct HandleExternalEventActivity. This is necessary now that we are running multiple instances of the same event in parallel.

The skeleton workflow:

<Sequence>
<Code Name="CreateApproversList" />
<Replicator ExecutionType=Parallel InitialChildData=ActivityBind("createdApproversList")>
<Sequence>
<CallExternalMethodActivity InterfaceType="IApproverTask" MethodName="CreateApproverTask" CorrelationToken="token1"/>
<HandleExternalEventActivity InterfaceType="IApproverTask" EventName="TaskCompleted" CorrelationToken="token1"/>
</Sequence>
</Replicator>
</Sequence>

The IApproverTask interface might look something like:

[DataExchangeService]
[CorrelationParameter("approverName")]
public interface IApproverTask
{
[CorrelationInitializer]
void CreateApproverTask(string approverName, TaskData data);
[CorrelationAlias("approverName", "e.ApproverName")]
event EventHandler<TaskCompletedEventArgs> TaskCompleted;
}

I'm going to assume that the ExternalDataExchangeService and its related attributes, activities, and correlation features are understood. If this is not the case you can find more data on these in the help files and samples.

Last, but not least, let's mention the Replicator's various events and its UntilCondition. We'll specify a ChildInitialized handler which will be responsible for setting the ApproverName on the CallExternalMethodActivity. We'll also specify a ChildCompleted handler which, in the case of a rejection or delay, will set the workflow's output variable to be Rejected. Finally, the UntilCondition will be set to return replicatorInstance.AllChildrenComplete || result == Rejected.

Benefits:

If the interaction with an approver is made more complex it will be a simple matter to model the interaction in the replicator's child sequence. Note that you can now think of the problem as the interaction with a single approver instead of as a generic interaction with many approvers. From a flow point of view, this is much easier to follow the logic: Create an approvers list, for each approver we notify of the task and wait for completion, and we short circuit the logic and complete if a Rejected/Delayed response is returned.

Drawbacks:

Unless you want to implement your own correlation your hand is forced in the choice of communications: ExternalDataExchangeService is the way to go here. And while modeling the interaction is simpler, providing the "loop" will be a little less natural - we'd have a while loop which checked the result property for Approved. Finally, while we are modeling flow in a more readable fashion we are no longer modeling the state of our document like we were with the State Machine.

Conclusion:

These are just two solutions and there are likely to be countless others. These have also been somewhat simplified for the purposes of illustration - we've gone into detail of the workflows but haven't gone into the details of the system existing just outside the workflow. Hopefully this will get you started with some ways to approach the problem. If you have any questions, check the docs and samples first and then feel free to ask.

re: Parallelism in Windows Workflow Foundation (WF)

fanse — Tue, 25 Apr 2006 11:44:11 GMT

I am working with a document approval workflow,when a document is created,the owner will choose several departments to get aprrove.only after all these approvers have done the approve action,the document 's state can be changed to approved,if one of the approvers reject it,the document's state will be changed to rejected.If one of the approvers delay the action,the document's state will be changed to rejected too.How can i desin this workflow use wwf?
I have thought for a long time,but have no answer,can you help me ?