Archive for February, 2013

SharePoint 2010, implementing a finite state machine replete with loops

 

Most document approval processes, such as the one shown above involve some looping, more or less, but whether more or less, their traditional treatment as finite state machines is beyond implementation in SharePoint 2010 owing to the absence of a looping mechanism, i.e., there is no ‘loop’ action in the list of Workflow Actions.

That said, however, it is possible to implement work processes such as the above as simple finite state machines consisting of sequence of n steps, one for each of n possible states, where each step begins with an if test on the current state of the work process and ends with a ‘stop workflow’ action. That is, if the current process state equals the one being checked on, the workflow executes the desired actions, advances the process state to the next sequential state and terminates, otherwise it checks on the next possible state.

To achieve the effect of looping, as the workflow completes each step and is about to terminate, it sets a certain field (column) in the document library, known as the ‘continue’ field, thereby triggering an auxiliary workflow to begin execution. The auxiliary workflow’s sole task is, after pausing briefly, to trigger the main workflow and then terminate. It does this by resetting the ‘continue’ field. That is, both the main workflow and the auxiliary workflow are configured to execute whenever there is a change to a document in its associated library. That is, the two workflows take turns triggering each other and executing. Note: with each such triggering, the main workflow begins with step 1.

I am in the process of implementing a document approval process comprised of 40 states and numerous loops. Note, in an effort to simplify the logic of the workflow, I’ve had to come up with the concept of the ‘if-state’.  The logic of an if-state parallels the logic of an ordinary state, i.e., it begins by checking the current process state before deciding whether to do the work proscribed by that state or not. And the proscribed work for an if-state is simply to decide which of two states is the correct succeeding state. This may strike the reader as pointless and silly, but the real payoff occurs when you have several (as many as 6 in the current implementation) if-states following each other in sequence which would result in a confusing morass of ‘if-else-if’s if you didn’t resort to some device like the if-state.

Here is some sample code that possibly does a better job of explaining what I’ve done:

Step 4b—CAmayBeAssigned (if state)

If Current Item:State equals CAmayBeAssigned

Log Step 4b(CAmayBeAssigned) commences to the workflow history list

If Current Item:isCAassigned equals yes

(actions associated with this state)

Set State to PossibleComplianceIssue

Else if Current Item:isCAassigned equals no

Set State to AssignCA

then log State is set to [%Current Item:State%] to the workflow history list

then set Continue to yes

then Stop the workflow and log Step 4b is stopping

 Step 4c–AssignCA

If Current Item:State equals AssignCA

Log Step 4c(AssignCA) commences to the workflow history list

(actions associated with this state)

then Set State to ScanToMakePDF

then Log State is set to [%Current Item:State%] to workflow history list

then Set Continue to yes

then Stop the workflow and log Step 4c is stopping

 

No Comments