So what does Workflow give me? Seriously!!
It gives you a way to write your procedural code, so it looks like a flowchart. Almost like model driven development (or development driven model?). And on top of it, it gives you a number of other things such as persistence, serialization etc.
Could you “get by” before Workflow? Absolutely.
But workflow gives you a much better architecture to model your flow driven applications (sequential or state machines), so they are much more maintainable going forward. Workflow truly embodies “A picture is worth a thousand words”. I am pretty techie, but I admit – a flowchart or graphical image just gels a lot better in my head than trying to decipher a concoction of C# splattered over a number of .cs files on a weary afternoon after a huge cheeseburger. And then a fellow geek tries to explain me the structure of the C# files he came up with, and 2 hours later my head is full of goat cheese.
So workflow is good. Workflow good. Workflow friend.
So over the past few days I’ve been babbling about Workflow. I first talked about,
What is Windows Workflow Foundation? Which was some nice theory, but incomplete without a Hello world example. I then started talking about CompositeActivities: Workflow activities that contain one or more child activities and in that post I alluded to ActivityExecutionContext, saying “I’ll be talkin’ about that seriously I will”. But then I started talking about Transaction support in Workflow foundation followed by a simple workflow example in SharePoint 2007.
Well, as it turns out, before I could talk about ActivityExecutionContext, I had to talk about ActivityExecutionStatus, and seriously – I couldn’t do that without giving a context to the various statuses insided the ActivityExecutionStatus enumeration.
The workflow runtime will allow you to run and host activities that you wrote – along with activities that shipped with the framework. The activities and runtime relate to each other through a state machine, in which the ActivityExecutionStatus enumeration plays a key role.
Each activity at a given time is at an ActivityExecutionStatus. These are Initialized, Executing, Cancelling, Faulting, Compensating and Closed. In the examples I have covered so far, Initialized, Executing and Closed are quite clear.
So one ActivityExecutionStatus transition could be –
Initialized --> Executing --> Closed.
The others are a bit funnier, and as I talk about Compensation in transactions in workflow, and faulting and cancelling workflows, I will find the following diagram incredibly helpful.
So in the above diagram, the red arrows denote final transitions. Obviously the next question is, how can the ActivityExecutionStatus for a particular activity change? Well, it can be changed by the Workflow runtime, or by a parent activity, or by the activity itself.
The activity itself can change the ActivityExecutionStatus using one of the following virtual methods in the Activity abstract base class.
void Initialize(IServiceProvider provider)
ActivityExecutionStatus Execute(ActivityExecutionContext aec)
ActivityExecutionStatus HandleFault(ActivityExecutionContext aec)
ActivityExecutionStatus Cancel(ActivityExecutionContext aec)
If in case your activity is compensatable (i.e. supports compensation *DUH*) it will need to implement the ICompensatableActivity interface, in which case you get yet another method –
Compensation, for now, is about undoing an already completed transaction. This is invaluable when you do not want long running transactions to block resources exclusively. So you essentially implement the “rollback” portion yourself. Except it isn’t exactly like rollback, since you released resources you have to write extra checking logic in the compensation.
Okay good, so now with this ActivityExecutionStatus covered, and the various transitions it can go through, next I will be talking about Compensating Transactions, Faults and Cancelling workflows in WF (among other things).