Spawned Contexts - Replicator, While, State, EventHandlers, and CAG

re: Spawned Contexts - Replicator, While, State, EventHandlers, and CAG

SKovour — Fri, 05 May 2006 02:11:49 GMT

First of all I have to appreciate the pain you have taken to explain about execution context. Your blog helped me to understand signficance of execution context and what is difference between template activity and activity in context activity (Before reading this blog, I am not able to understand why I am getting an exeception from ExecuteActivity with a message that my activity is not in the context). However now I am more in dielamma, as I am not sure WWF capabilities can help me to solve the problem I am planning to resolve.

I am doing a feasability study to see whether WWF can solve our workflow issue in the doamin of medical imaging applications. We would like to model serveral clinical image processing blocks as activities as elements in pipe line pattern. Specifically we are wondering whether you can modify sequence activity for example to a behavior similar to a pipe line element. One of the challenging requirements (with respective to using WWF) is, properties of piple line elements can be modifable by hosting applicaiton and in that case it is expected that piple line starting from the segment whose properties are modified, need to be re-executed. And this can happend several times in course of workflow. I am not really sure how I model this control behaviour in a custom activity that is derived from composite activity.

Any help on this is highly appreciated. I am not sure whether Microsoft officially supporting WWF through technical consultancy.

-Sathya

re: Spawned Contexts - Replicator, While, State, EventHandlers, and CAG

ntalbert — Fri, 19 May 2006 21:22:20 GMT

SKovour,

Your scenario is an interesting one and it is definitely one which can enabled by Windows Workflow Foundation (WF). While I'm not going to provide an exact solution for your scenario, I will get you started with some potential architectures for getting the behavior you desire.

The Root Activity
The pipeline container activity needs to support the more generic concept of being able to interrupt the current work to arbitrarily go back and start over from some point. This, surprisingly enough, should be pretty easy to implement.

First, the activity could create a queue at execution time to which it will subscribe for QueueItemAvailable. The handler will expect that the item passed on the queue is the name of the next activity that should be executed. The logic for the QueueItemAvailable handler might look something like this (psuedo-code):

ActivityExecutionContext context = (ActivityExecutionContext)sender;
string nextName = (string)q.Dequeue();

Assert(context.ExecutionContextManager.Contexts.Count <= 1, "Should only have at most one child executing.");

if (context.ExecutionContextManager.Contexts.Count > 0)
{
AEC childContext = context.ExecutionContextManager.Contexts[0];
if (childContext.Activity.ExecutionStatus == ActivityExecutionStatus.Executing)
childContext.CancelActivity(childContext.Activity);
}

this.SetNextIndex(this.EnableActivities.IndexOf(this.Activities[nextName]));

The logic for the Activity.Closed handler might look like:

// Complete the context for the closed activity

if (NextIndexToExecute >= this.EnabledActivities.Count)
{
context.CloseActivity();
return;
}

AEC childContext = context.ExecutionContextManager.CreateExecutionContext(this.EnabledActivities[NextIndexToExecute]);
childContext.Activity.Closed += OnActivityClosed;
childContext.ExecuteActivity(childContext.Activity);

this.SetNextIndex(NextIndexToExecute + 1);

Now, there are probably some logic bugs in the above code that need to be ironed out (is there a race between an event coming in and an activity closing which could cause the "rework" not to occur?), but the idea is that some external event can cause cancellation and an activity's execution logic can be written to have a dynamically decided "next child to execute".

Updating the Pipeline Components
WF already has a mechanism for adding and removing components at runtime (the WorkflowChanges dynamic update capabilities). You could simply piggyback on these and have a change a pipeline component be a remove followed by an add. This would require a little more engineering in some places (you'd have to cancel the child first if you were trying to remove an executing one), but would probably be one of the easier approaches. Note that this will also have a performance implication because every dynamic change is persisted with the workflow's instance. That is to say that if you remove 30 activities and add 30 activities then your persistence footprint will now include a record for each removal and each addition.

An alternate solution is to implement a generic "property update" capability either on the Root activity (the pipeline container described above) or on the base pipeline component class. This could be implemented as a queue onto which the host places some path to be updated and some value to to assign. Because of requirements around the state of an activity and event delivery (events are only delivered to non-Initialized, non-Closed activities), you'd probably want to implement this on the root. So, for example, the queue item available handler for this queue might look like:

PropertyUpdate update = q.Dequeue();
Activity act = this.Activities[update.ActivityName];
PropertyInfo pInfo = act.GetType().GetPropertyInfo(update.PropertyName);
pInfo.SetValue(update.NewValue);

Example Host Usage
WorkflowInstance wi = wr.GetWorkflow(wfGuid);
wi.EnqueueItem("UpdateQueue", new PropertyUpdate("SomeActivity", "SomeProperty", 5), null, null);
wi.EnqueueItem("StartRework", "SomeActivity", null, null);

Note that if the pipeline container activity is the one listening for UpdateQueue then it can be smart enough to start the rework from the earliest activity that is updated. You'll also probably want to be able to "batch" updates seeing as you might change one or more components at a time (and several properties on each) but don't necessarily want that to translate into the work being restarted that many times.

Conclusion
This is just a quick, first guess solution, but with a little work I think it could get you well along the path. I'm sure that there are requirements of yours which will conflict with some of the examples given above, but the point is that you can do pretty much anything you can imagine with WF.

WF Serialization Part One and a half

Jon Flanders' Blog — Thu, 08 Jun 2006 21:26:48 GMT

My Gripes with Windows Workflow

K. Scott Allen — Fri, 18 Aug 2006 06:04:17 GMT

Brian Noyes' post "Understanding Windows Workflow and its complexities" has me thinking.
I know a few...

re: Spawned Contexts - Replicator, While, State, EventHandlers, and CAG

Howard Richards — Mon, 25 Sep 2006 12:32:59 GMT

Am I hitting something to do with ExecutionContext here? I am trying to subclass StateActivity. I created an event that I raise during the first EXECUTE method - but if the workflow event code modifies DependencyProperties, the values don't seem to be visible to the subclass code?

e.g.
Protected Overrides Function Execute(ByVal executionContext As System.Workflow.ComponentModel.ActivityExecutionContext) As System.Workflow.ComponentModel.ActivityExecutionStatus
'raise event
Mybase.RaiseEvent(StateSubclass.InitializeTask, Me, EventArgs.Empty)
'cannot access values set by event handler here?
' console.WriteLine("Value is " & me.someProperty)
Mybase.Execute(executionContext)
End Sub

re: Spawned Contexts - Replicator, While, State, EventHandlers, and CAG

ntalbert — Tue, 26 Sep 2006 00:35:49 GMT

Yes, you most likely are hitting something to do with execution contexts. My guess would be that your event handler for InitializeTask is NOT accessing the activity by casting the sender argument, but instead is accessing some field on the workflow which represents the activity.

If that is the case (you are NOT using sender) then the problem you are seeing is that the handler is changing the template activity and not the current instance. State machine starts each state in a new execution context, so the template activity is never actually executed.

Let me know if you are still having issues.

Implementing the N of M Pattern in WF

Matt W's Windows Workflow Place — Wed, 27 Jun 2007 03:38:34 GMT

The second in my series of alternate execution patterns ( part 1 ) I recently worked with a customer

re: Spawned Contexts - Replicator, While, State, EventHandlers, and CAG

john.muller — Fri, 29 Jun 2007 08:05:01 GMT

Hi. Very nice post, thanks.

I have been using the AEC and was wondering about performance. As a result I thought it to be a good idea to execute any 'first' branch within the default AEC and any subsequent branches within new child AEC's. Is my assumption correct that I might be gaining anything using this solution (next to a bit more complicated logic to manage these AEC's)?

My initial assumption was that creating new child AEC's incur a bit of a performance hit - firstly, the actual code to create a new instance has to incur a tiny performance hit, and secondly persisting these workflows + their associated AEC's has to incur a performance hit (I think).

So, I guess the question is two-fold :). Is my assumption correct, and do I gain anything using the aforementioned solution.

Thanks.

re: Spawned Contexts - Replicator, While, State, EventHandlers, and CAG

ntalbert — Tue, 03 Jul 2007 23:03:28 GMT

john.muller, you will be unable to do what you are attempting. The activity execution state machine terminates in the Closed state. This means that once you execute an activity it cannot ever be executed again. This includes trying to execute it in a new context.

By spawning a new context with an activity which has not yet executed, you are cloning an Initialized activity. Attempting to do so with a Closed activity will simply give you a clone of a Closed activity - we'll throw an exception preventing you from doing this.

Note that creating contexts is definitely a costly operation. If you need to squeeze every last bit of perf out then unrolling loops will give you a noticable gain.

Zen and the Art of Information Management » SharePoint Workflow: Replicator (to be continued)

Mon, 30 Jul 2007 04:20:02 GMT

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

re: Spawned Contexts - Replicator, While, State, EventHandlers, and CAG

lcorneliussen — Tue, 04 Sep 2007 19:10:12 GMT

Hello,

how can i access the right activity from within a declarative condition? And how inside the Excecute-Event of an activity.

I would like to make the conditions react directly on activity properties, because my workflow ist just a xml definition and its base class should only have a really limited set of properties.

It would be awesome if you still watch the comments on this blog.

Tanks,

Lars (originally from Germany, but now in Mexico)

re: Spawned Contexts - Replicator, While, State, EventHandlers, and CAG

ilohraphael — Tue, 06 Nov 2007 17:45:58 GMT

Hello Nate,

I was wondering if you've got any pointers on how to use the replicator activity in a state machine workflow. I've tried using the WssTaskActivity but that keeps throw some exceptions about the number of activities contained that implement the IEventActivity.

Any ideas will be welcomed.

Regards,

Raphael.

re: Spawned Contexts - Replicator, While, State, EventHandlers, and CAG

ntalbert — Tue, 06 Nov 2007 20:59:52 GMT

Lars, unfortunately I can't be much help for your scenario as I'm wholly unversed in declarative workflows and pretty unfamiliar with the syntax for our rules. That said, the WF forums are a great place for these types of questions. The forums are very active these days: http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=122&SiteID=1

Sorry I couldn't be more help directly ... and sorry about the late reply.

re: Spawned Contexts - Replicator, While, State, EventHandlers, and CAG

ntalbert — Tue, 06 Nov 2007 21:06:08 GMT

Raphael, the short version is that you cannot use replicator in a state machine in the manner that you are trying to use it. State machine is very strict about being composed only of States. Each state, in turn, either contains more states or events. Events MUST start with IEventActivities and must not contain IEventActivities anywhere else in their flow.

The benefit of these restrictions is that the state machine can guarantee that all events in a state are atomic (you will never get part of the event's work done while another event is running), it can guarantee mutual exclusion between the events in a state (only one will fire at a time), and it can guarantee that events are largely CPU bound.

Replicator is designed to be used with sequential style workflows and allows for easy management of multiple, similar, tasks such as the WssTaskActivity. If you want to do the same thing in StateMachine then you need to approach the problem from a completely different standpoint. Instead of replicating the task that everyone should do, you need to view it as a state where you create all of the tasks, a state where you wait for all of the tasks to complete (or be updated, etc), and finally a state where you do your final set of work.

re: Spawned Contexts - Replicator, While, State, EventHandlers, and CAG

Frederick Morrison — Thu, 08 Nov 2007 02:18:26 GMT

You say that we cannot use the Replicator in a state machine workflow. Instead, you say we have to program in a completely different manner. Please provide a link to an example to back up what you say. I'll give $500 dollars to the first person who provides a real example of a state machine workflow that creates an unknown-until-run-time set of parallel tasks based upon InfoPath task forms, all of which have to finish before the state of the workflow can move forward to the next state. I have a feeling that my money is pretty safe.

re: Spawned Contexts - Replicator, While, State, EventHandlers, and CAG

ntalbert — Thu, 08 Nov 2007 04:13:02 GMT

Frederick, I'm not terribly familiar with the WssTaskActivity (and the other Sharepoint activities) and I was definitely speaking from a theoretical point of view - when you want to replicate things which have some sort of receive in them inside of a state machine you have to separate the receive into its own event handler.

For questions of how to make use of WssTaskActivity in scenarios where the list of users is dynamic I'll redirect you to the Sharepoint Workflow forums: http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=1207&SiteID=1

Thanks to Lexis Nexis!

Kirk Allen Evans's Blog — Wed, 30 Apr 2008 14:39:23 GMT

We are about to start a great day showing technologies like .NET 3.5, Visual Studio 2008, and SharePoint

Exploring Workflow Foundation Part 1: Custom Activities « Hungry for Knowledge

Sun, 13 Jul 2008 21:59:37 GMT

PingBack from http://sdesmedt.wordpress.com/2008/07/13/exploring-workflow-foundation-part-1-custom-activities/

Commonality - Spawned Contexts and Activity Binding

Commonality - Spawned Contexts and Activity Binding — Wed, 10 Sep 2008 05:53:01 GMT

PingBack from http://www.winterdom.com/weblog/2006/05/04/SpawnedContextsAndActivityBinding.aspx

Exploring Workflow Foundation Part 4: Custom Composite Activities « Hungry for Knowledge

Sun, 05 Oct 2008 15:27:00 GMT

PingBack from http://sdesmedt.wordpress.com/2008/10/05/exploring-workflow-foundation-part-4-custom-composite-activities/

Child Activity

Child Activity — Wed, 17 Dec 2008 13:50:58 GMT

PingBack from http://www.baby-parenting.com/family/child_activity.html

re: Spawned Contexts - Replicator, While, State, EventHandlers, and CAG

heman_1978 — Mon, 19 Jan 2009 14:12:36 GMT

Hi,

We are developing an application using Windows workflow and InformixV7.x version. I have got by batch service and Persistence servivce working perfectly. But we would like to have a feature where in if a workflow instance and the application objects associated with that workflow is in process by a user then the other users should not be able to modify it.

We are using ASP.NET 2.0 for implementing this application and the Runtime is created as an application level object and the persistence service is created and initialized at application on start itself.

Also we would like to have the locking based on Application IDs rather than arbitrary GUID.

What do you suggest ?

1) Do some modification (if so please tell us the modification) to persistence service and get this done

2) Handle the application as part of application objects retrieval and persistence.

Please help us in this regard

re: Spawned Contexts - Replicator, While, State, EventHandlers, and CAG

ntalbert — Tue, 20 Jan 2009 21:09:09 GMT

heman, that type of integration scenario is a bit out of scope of this blog. I'd suggest you post the same information on the MSDN WF forum (http://social.msdn.microsoft.com/forums/en-US/windowsworkflowfoundation/threads/). These forums are actively monitored by the product team and should be the quickest route to a solution.

Advanced Workflow Enabling Tricky Scenarios Spawned Contexts | Insomnia Cure

Advanced Workflow Enabling Tricky Scenarios Spawned Contexts | Insomnia Cure — Tue, 09 Jun 2009 01:19:01 GMT

PingBack from http://insomniacuresite.info/story.php?id=4108

Advanced Workflow Enabling Tricky Scenarios Spawned Contexts | Cellulite Creams

Advanced Workflow Enabling Tricky Scenarios Spawned Contexts | Cellulite Creams — Wed, 10 Jun 2009 04:45:01 GMT

PingBack from http://cellulitecreamsite.info/story.php?id=398

Advanced Workflow Enabling Tricky Scenarios Spawned Contexts | Quick Diets

Advanced Workflow Enabling Tricky Scenarios Spawned Contexts | Quick Diets — Wed, 10 Jun 2009 06:35:22 GMT

PingBack from http://quickdietsite.info/story.php?id=751

Advanced Workflow Enabling Tricky Scenarios Spawned Contexts | debt solutions

Advanced Workflow Enabling Tricky Scenarios Spawned Contexts | debt solutions — Fri, 19 Jun 2009 19:36:10 GMT

PingBack from http://debtsolutionsnow.info/story.php?id=3912