Articles

Workflow Design - Spider Workflow

 

A number of people have asked me to explain the 'Spider Workflow' approach to workflow design, so I thought it would be best to blog about it. So here goes... 



1. Introduction
There are a number of design cases in workflow solutions, where the 'order of steps' is now known or cannot be determined at design time. An example of this is where certain steps might occur more than once (eg: a specific manager needs to keep reviewing a document until conditions have been met), or where the user is involved in determining the next step of flow of events (eg: A user might wish to route a document directly to the regional manager (instead of the departmental manager).

Frequently during these types of solutions, the workflow designer attempts to solve this by linking each workflow step to each of the possible next steps in the process. This, however, can result in a very complex spaghetti workflow process with lines linking everywhere. There, in order to clean up this 'ad hoc' style workflow, one of the possible solutions is the 'Spider Workflow' approach.

2. Spider Workflow Approach
Spider Workflow is a workflow design approach in which the workflow gets handled by a central 'router' hub step, and a number of single 'spoke' steps. Using this approach, the workflow design is centered around an 'intelligent' central hub step, that determines which step (or steps) the workflow should route to next. (The spider workflow design could also (probably more accurately) be described as a 'hub-and-spoke' design). During the workflow runtime, the process will get routed from one spoke to another, until a specific condition (flag) is met such that the workflow is complete. In this manner, any spoke can follow a previous one (even the same spoke more than once if required).

 

3. How is it Built (Refer to the attached diagram below)
Referring to the diagram, the spider workflow is implementing using the Routing Step as the central hub. This is an activity that contains a single Server Event that evaluates data in order to set an 'Outcome' data field. Each line that emerges from the Routing Step contains a simple line rule that checks the value of 'Outcome' to establish whether it needs to be followed or not. (Example: the line that runs from Routing Step to Manager Approval could have a line rule that checks whether "Outcome==Manager Approval", and if yes, the Manager Approval would be the next step.

This can continue indefinitely until an 'exit condition' is met (depending on the solution). An example of this would be (referring to the diagram) the process might need to continue, once all of the 4 parties (Manager, Finance, Regional Manager and the CEO) have approved a specific doc. In this case the Routing Step would evaluate the Approval data fields, and if all 4 of them are set to 'Approved', then it would simply set the Outcome to 'Continue' (and potentially this would make the process continue to the Process Continues step)

4. Spider in Action (An Example)
Lets take a look at this in action. The originator might submit a new 'Policy Doc' and the process starts. By default the process has been built that if the user doesn't specify who this should be routed to next, it follows a default order (Manager -> Regional -> Finance -> CEO). Therefore, the doc gets routed to the 'Manager Approval' step.

The Manager takes a look but feels that the policy is too expensive, so he/she specify on their UI that the task must get routed to 'Finance Review' next. The Routing Step evaluates the data fields set by the Manager, and routes the task to the 'Finance Review' step.

The Finance team are happy with the doc, so they approve it, but do not specify a specific next step. The 'Routing Step' checks the default order, notices that the Manager has already approved, and the next default person is the Regional Manager, so then it gets routed to the Regional Manager.

The Regional Manager is happy with the doc, but he/she sees from the process history that the Manager routed it directly to Finance with some concerns. Therefore, the Regional Manager adds some additional comments, and routes it back to the Manager to review the doc.

The Manager gets the doc (for the 2nd time), sees the approval history and comments, and is now happy with the doc, and approves it again. The Routing Step now determines that the only person that has now seen the document is the CEO, so it gets routed to CEO Approval.

The CEO has a look, sees everyone else is happy with the doc, and approves it.

At this point, the process reaches a specific condition where the 'Routing Step' evaluates all the requirements and establishes that everyone that needs to approve the doc has already done so, so the workflow is routed to 'Process Continues' (where the doc might be uploaded to SharePoint, and the originator notified etc etc).

This is just a simple run-through of a single instance, however, it should be apparent that this process can be approved in any order, and number of times, all dependant on the conditions coded into the 'Routing Step' server event.


5. Extending the Design
This design can be taken a lot further than the simple scenario painted above.

5.1 Multiple Concurrent States
It is relatively easy to extend this solution to allow multiple concurrent steps in the workflow. There is no reason why this document cannot be reviewed by the Regional Manager and by Finance at the same time. One simple needs to add additional code/flags so that the Routing Step knows what to do in these circumstances. Fundamentally the process can get as complex as required, and the exit condition will always be 'if all confitions have been met, the process can continue'

5.2 IPC
Extending the design further, the spoke steps could be IPC (Inter Process Calls) to sub-processes. The only downside is access to the data, where the 'call-by-value' data passing to the child process means that child processes can only get/set their local copy of data fields that only get bubbled up to the parent upon completion of the child process. One can work around this problem by using SmartObjects that can be accessed from anywhere.

5.3 Mixed Model
The spider workflow is not an absolute workflow design. Any workflow process could at any stage include a 'spider-style' section, and it can therefore be used in a mixed model with classic (sequential) workflows, or even with other spider workflows (eg: where a spoke is effectively a hub for a sub-region). It all depends on the scenario.


6. Conclusion
To some degree, the 'Spider Workflow' approach has been over-hyped as the silver bullet for ad-hoc workflow. Basically this just a logical approach for flexible workflow design, that is very hard to report on (due to the vast number of activity (specifically routing step) instances) which makes it more difficult to measure the metrics of the solution.

Authored by Olaf Wagner

Published Tuesday, July 10, 2007 8:09 PM by chrisg

Comments

 

marcol888 said:

Hi Chris, you mentioned a diagram in section 3. Is it attached to this article or I need to download it separately?

Thanks

July 15, 2007 8:10 PM
 

gouldjw said:

Um, yeah.  Looking for the "attached diagram".  This looks exactly like what I need to do!

July 18, 2007 4:15 PM
 

chrisg said:

http://k2underground.com/blogs/adriaanandolaf/attachment/15807.ashx

July 20, 2007 3:37 PM
 

ChrisOC said:

Great approach, never actually thouht of it to be called a "spider workflow" - but that's what it is !

My current workflow project has a number of "cycle events" - which I term a "bounce" between two people, back-and-forth - until both have said OK.    

I'd just used the "old" way of looking at it - rather than the more windows workflow "state machine" metaphor.    And - yep, a bit of spaghetti on my process !

Thanks Chris - good article.

August 16, 2007 4:47 PM
 

ChrisOC said:

Another comment - re: 5.2

I've got some IPC processes that update values in the PARENT process while the CHILD process is still running.

(1)  When starting the IPC - just need to pass the ProcessID of the PARENT

(2)  Within the child process - can then use some K2ROM code to "inject" the required values back into the parent process (done within a web service actually)

-------------------------------

SourceCode.K2ROM.Connection connK2 = new SourceCode.K2ROM.Connection();

//create connection to K2 - and open process instance

connK2.Open(AppSettings.Get("K2.Server"));

//open the specific process (parent)

SourceCode.K2ROM.ProcessInstance procK2 = connK2.OpenProcessInstance(ParentProcessId);

//now update the value/s within the process

procK2.DataFields[ProcessVariable].Value = ProcessValue;

procK2.Update();

-------------------------------

Is there a better way to update a value with a parent process ?    (other than having to wait for the CHILD process to finish)...?

NB. This is for K2.NET 2003 - not sure if this would work, or can be done better in Black Pearl (SmartObjects ?)

August 16, 2007 4:58 PM
 

Adriano said:

Hi ChrisOC -did you come up with a better way?

November 15, 2007 12:52 PM
Anonymous comments are disabled

About chrisg

I am responsible for community development for SourceCode. I have been in technology for over 14 years mainly in infrastructure and security. I absolutely love technology especially new stuff and gadgets.