SharePoint workflow solution (2): WF state machine in SharePoint

In the previous article, we mentioned that Sharepoint is a workflow platform that encapsulates event-driven interfaces on top of the WF workflow engine. SharePoint expands many activities on WF, among them, there are three common activities closely related to WF: onworkflowactivated, createtask, and ontaskchanged.

A simple SharePoint Sequential stream.

 

Onworkflowactivated: responds to the Event initiated by the process.
Createtask: generate a Sharepoint task.
Ontaskchanged: the event in which the task is changed.

There can be only one onworkflowactivated in a process; there can be any number of createtask and ontaskchanged, but they must be paired;

Many SharePoint workflow solutions make createtask and ontaskchanged a custom activity in sequential flow mode, and then use the automatic copy function of replicatoractivity to allow multiple users to simultaneously approve the event. This method is simple, but the Sequential stream does not support rollback. When a rollback is required, it can only be simulated by whileactivity, and the process becomes complicated.

A simple SharePoint state machine

The process includes three statuses: Start, approve, and finish. You can roll back between statuses by adding other statuses.

Onworkflowactivated and setstateactivity are included in the response to the startup event.
Createtask is included in "add approver"
Ontaskchanged and setstateactivity are included in the "response approval event ".

Each stateactivity of WF can only contain one stateinitializationactivity, which is used to add approvers and implement initialized business logic. Multiple eventdrivenactivities can be contained to respond to multiple approval events at the same time and implement the business logic after approval. The first control of eventdrivenactivity must be handleexternaleventactivity (the base class of ontaskchanged ).

We can see that in the state machine, createtask and ontaskchanged must still be paired, but their locations are separated. createtask is in stateinitalizationactivity, and ontaskchanged is in eventdrivenactivity.

SharePoint state machine that can be simultaneously approved by multiple people

If multiple users need to approve the request at the same time, add multiple createtask in stateinitializationactivity, and add multiple eventdriven in stateactivity.

"Add approver" includes createtask of A and createtask of B.
The ontaskchanged of A is included in the "response to a's approval event.
The "response to B's approval event" contains B's ontaskchanged.

To add more approvers, and so on.

Problems with SharePoint state machine Workflow
From the above we can find that the state machine application of SharePoint has the following two problems:
1. The process in eventdrivenactivity is redundant. It is difficult to maintain the process when the process is complex and there are many approvers.
2. The number of approvers must be determined during the design period and cannot be changed.

In the previous article, we mentioned that Sharepoint is a workflow platform that encapsulates event-driven interfaces on top of the WF workflow engine. SharePoint expands many activities on WF, among them, there are three common activities closely related to WF: onworkflowactivated, createtask, and ontaskchanged.

A simple SharePoint Sequential stream.

 

Onworkflowactivated: responds to the Event initiated by the process.
Createtask: generate a Sharepoint task.
Ontaskchanged: the event in which the task is changed.

There can be only one onworkflowactivated in a process; there can be any number of createtask and ontaskchanged, but they must be paired;

Many SharePoint workflow solutions make createtask and ontaskchanged a custom activity in sequential flow mode, and then use the automatic copy function of replicatoractivity to allow multiple users to simultaneously approve the event. This method is simple, but the Sequential stream does not support rollback. When a rollback is required, it can only be simulated by whileactivity, and the process becomes complicated.

A simple SharePoint state machine

The process includes three statuses: Start, approve, and finish. You can roll back between statuses by adding other statuses.

Onworkflowactivated and setstateactivity are included in the response to the startup event.
Createtask is included in "add approver"
Ontaskchanged and setstateactivity are included in the "response approval event ".

Each stateactivity of WF can only contain one stateinitializationactivity, which is used to add approvers and implement initialized business logic. Multiple eventdrivenactivities can be contained to respond to multiple approval events at the same time and implement the business logic after approval. The first control of eventdrivenactivity must be handleexternaleventactivity (the base class of ontaskchanged ).

We can see that in the state machine, createtask and ontaskchanged must still be paired, but their locations are separated. createtask is in stateinitalizationactivity, and ontaskchanged is in eventdrivenactivity.

SharePoint state machine that can be simultaneously approved by multiple people

If multiple users need to approve the request at the same time, add multiple createtask in stateinitializationactivity, and add multiple eventdriven in stateactivity.

"Add approver" includes createtask of A and createtask of B.
The ontaskchanged of A is included in the "response to a's approval event.
The "response to B's approval event" contains B's ontaskchanged.

To add more approvers, and so on.

Problems with SharePoint state machine Workflow
From the above we can find that the state machine application of SharePoint has the following two problems:
1. The process in eventdrivenactivity is redundant. It is difficult to maintain the process when the process is complex and there are many approvers.
2. The number of approvers must be determined during the design period and cannot be changed.