How can a "fork" (parallel split) pattern be implemented in a WF state machine wor
By "fork", I mean from within a root state machine workflow, how can I initiate 2 or more state machine subworkflows, have the state machine subworkflows execute in parallel and
a) have the parallel state machine subworkflows join or synchronize later in the root state machine workflow? ...or
b) not have the parallel state machine subworkflows join or synchronize later in the root state machine workflow (i.e. have each subflow complete independently)?
a:) An InvokeWorkflowActivity and somewhere in the root state machine workflow a (synchronizing) custom activity waiting for a message in a WorkflowQueue; the invoked workflow can post the message in this queue by using a workflowQueuing service.
b:) I guess the InvokeWorkflowActivity provides this.
Serge
Serge,
Thanks for the quick reply ("faster than FedEx") and for highlighting the InvokeWorkflowActivity.
However, I'm hoping there would be more direct support in WF for a key workflow principle such as fork. (http://www.bpmn.org/Documents/Notations%20and%20Workflow%20Patterns.pdf is a good reference for the fork (aka parallel split) pattern used in BPMN as well as UML 2.0 - specifically refer to Figures 3 thru 6.)
Although InvokeWorkflowActivity can be used to simulate fork-like behavior, it can't be done without designing, implementing, tracking and cross-correlating multiple different, individual WF workflows (and from a hosting perspective, creates the need for a tracking infrastructure for managing multiple WF workflow instances needed to implement the most simple parallel split pattern).
If InvokeWorkflowActivity is the best/only approach, the lack of direct support for fork (parallel split pattern) is a major WF design flaw.
Michael Herman
Parallelspace Corporation
p.s. Steve Danielson [Microsoft] posted a InvokeWorkflowActivity state machine workflow sample here: http://blogs.msdn.com/sdanie/archive/2006/06/23/644366.aspx.
Hi Michael,
To implement (B), you would need only to use 2 InvokeWorkflow activities. InvokeWorkflowActivity will complete and pass execution to the next activity as soon as the targetted workflow is started. By default they will run to completion independently. To implement (A), you would need to some additional work. After starting the child workflow(s), you could implement the join by waiting for an event signalling the completion of the workflow. If you had multiple workflows, you could wait using a parallel activity or a CAG activity, and when all spawned workflows are complete then you could continue execution of the parallel workflow. You are correct in that there is no built in "fork and join" construct, but it is not too difficult to implement using the constructs that I describe. The blog posting to which you refer has an example that uses only 1 child workflow but it could be easily modified to handle multiple child workflows.
However, one thing to point out, is that a single Workflow executes on a single thread, and when it gets to a parallel activity it executes the branches sequentially from left to right. However, if any time during the execution of that branch an EventDriven activity is executed, such as a Delay or a HandleExternalEvent, then execution will move to the next branch and continue either until the next delay, or all branches except for the current one have completed). It will then wait for that event before the parallel activity is completed. So if one branch of the parallel is longer running, for example waiting on an external event, this will not block the whole activity, just the current branch.
However, in a State Machine Workflow, you cannot branch and execute multiple states simultaneously, but you could have parallel activities inside a single state that use the method that I describe above. If you need multiple states executing, then invoking child state workflow would be the way to go.
I will pass your feeback along to the product group as well.
Thanks
Steve Danielson [Microsoft]
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm
Are there any restrictions on the StateMachineWorkflowActivity invoked by InvokeWorkflowActivity?
...in particular, are there any issues having InvokeWorkflowActivity invoke an instance of the same workflow it is being invoked from? ...i.e. can the child workflow created by InvokeWorkflowActivity use the same as the parent workflow?
Tom Lake's CustomInvokeWorkflowActivity sample (http://blogs.msdn.com/tomlake/archive/2006/07/14/666287.aspx) turns out to be a good design/pattern for creating a ForkOneWorkflowActivity.
I've been able to invoke the same worflow (parent workflow) as a child workflow of the parent. I've also been able to use a sequence of ForkOneWorkflowActivity's to fork the same workflow several times.
Michael.
