This post is in a response to a question I saw yet again on the Technet forums today. This question is in no way unusual—in the course of developing SharePoint workflows, many of us eventually ask "how can I fire off a slew of Tasks all at once?" The answer, after some research, is always to use the Replicator activity.
The Replicator activity can be described as a "foreach loop for workflow." It's not that simple, but the gist of it is: if you have a list of things (let's hypothetically say, SharePoint Workflow Tasks), you can run parallel Workflow threads for each item in the list, without knowing in advance how many items you'll want to replicate. See, I even used the words "for each" in the description.
There are some workflow concepts that don't easily translate to traditional "imperative" languages, at least not in my vocabulary. Read up elsewhere on the Replicator task if you're interested in digging deeper.
ASIDE: If you're researching this topic, I highly recommend you look at the Approval workflow example in the MOSS SDK. I've searched, trust me, and the Approval workflow example is as good as it gets.
So far, so good, right? Unfortunately, there's a twist!
I'll preface this with a disclaimer: I'm not a Workflow mega-expert (maybe I am by now, but as of 2007-09-19, I have not yet been awarded the "mega" rank). If you, dear reader, happen to know a better solution, by all means leave me a comment.
Back to the twist: you can't replicate SharePoint Workflow Tasks inside of a State Machine Workflow if you need to wire up multiple events. If you want to study that last sentence for a while, feel free; I'll be here waiting…and, we're back!
The specific problem you'll inevitably run into may be found in the collision of the following conflicting requirements:
Putting these statements together: if you're creating a useful workflow involving Workflow Tasks, you'll require two (or more) events. All these events must go inside a Replicator activity in order to, um, "replicate" them. This Replicator, in turn, must be embedded (and yet cannot be embedded) in a single state in the state machine.
Let's sum up with bullet points:
Any advice and all alternate solutions are greatly appreciated. Besides idle curiosity, I have encountered this problem myself and would love to keep "my precious" state machine intact. There's still time!
This is a problem you may encounter in many walks of life. Specifically, you may encounter this problem in the many walks of life that involve programming with all of a) multiple events, b) composite activities, and c) state machine workflows.
This can happen to you!
And while I have no idea what goes into building an extensible workflow engine, may I humblly submit the following suggestion: can we embed state machines inside state machines? While this sounds crazy (AND THIS IDEA IS, IN FACT, CRAZY), allow me a defense:
b, blockquote@cite, strong
© Copyright 2013, Peter Seale