SharePoint workflow solution (III): SharePoint state machine with built-in default process logic

As we mentioned earlier, the task encapsulation mechanism of SharePoint determines that there are two problems with its state machine application. One is that when multiple people approve the application, an eventdrivenactivity must be added to each approver; the other is that the number of approvers must be determined during the design period.

Are there any solutions to these two problems? Thanks to WF, the process can be dynamically modified. We can inherit a State activity from stateactivity, based on the number of approvers before the State is executed, dynamically add createtask, eventdrivenactivity, and ontaskchanged activities in the status.

Execute method of the custom state activityCodeLogic.

Design period flowchart of state machine workflow implemented by custom state activity

Note: Approval _ Initialization is added to display the process logic during the design period. It will be deleted during the runtime and the approval _ initialization during the runtime will be regenerated.

To facilitate business development, we have added many attributes in the Custom state activity:

Assignedtotype:Where to obtain the approver can be a direct user, list field or SharePoint user group.
Assignedtovalue:The value of the approver corresponding to assignedtotype can be multiple user names separated by semicolons, either the name of the List field that stores the user, or the name of the SharePoint user group.
Actionstates:The operations that can be performed by the user and the status that the user jumps to when performing this operation. It is a collection of actionstates.

Action:User operations
Requireall:All users must perform this operation for signing.
Targetstatename:The status that the user jumps to when performing this operation.

Actionfield:A field that interacts with a task. When a task is generated, operations permitted by the user are passed in to this field. When a task changes, operations performed by the user are obtained from this field.
Sequenceapprove:Sequential approval. When there are multiple approvers, they can be reviewed one by one.

Custom state activityState Machine workflow dynamically generated during runtime

Approval Process in Initialization

Approval Process in eventdriven_1

Benefits of solutions

This solution can meet most of the requirements of SharePoint workflow applications, because it can basically implement nearly complex business processes that we have implemented using WF; currently, nearly 10 processes have been applied in a project to better solve users' complicated business needs. workflow development is very simple, and you only need to draw a flowchart in Visual Studio, after training, the customer's IT department staff can develop their own business processes.

WF provides the hosting function of the Process designer. On this basis, we have developed a WF process designer. If it is improved to support Sharepoint, the process design can be separated from Visual Studio, to implement a relatively independent solution.

The value of this solution is limited for any implementer, and each implementer can do only a few projects a year.

It has the highest value for Microsoft. If it can implement a perfect solution for Sharepoint workflows, it will greatly promote SharePoint applications.

Workflow selection between WF and SharePoint

WF is a workflow engine with high technical difficulty and it is very difficult to directly apply it to projects. At least it must be encapsulated as a workflow platform, although this is more difficult, however, application development on the platform will be very simple.

Many people think that the difficulty of WF lies in the state machine. In fact, the difficulty of WF is in its event-driven mechanism. If you can make an event-driven Sequential stream, the difficulty of creating an event-driven state machine is the same.

SharePoint workflows encapsulate the WF event-driven mechanism for development on SharePoint workflows. You only need to know how to use WF and SharePoint activities.
Therefore, we recommend that you develop applications on SharePoint workflows.

In this article, we provide a Sharepoint state machine solution with built-in default logic. In this solution, the process logic can be configured but cannot be customized. You can write the business logic in three places, the methodnvoking event of createtask and the invoked event of ontaskchanged before entering the status; In the nextArticleWe will propose a Sharepoint state machine workflow solution for customizing business logic to meet more complex business process requirements.

As we mentioned earlier, the task encapsulation mechanism of SharePoint determines that there are two problems with its state machine application. One is that when multiple people approve the application, an eventdrivenactivity must be added to each approver; the other is that the number of approvers must be determined during the design period.

Are there any solutions to these two problems? Thanks to WF, the process can be dynamically modified. We can inherit a State activity from stateactivity, based on the number of approvers before the State is executed, dynamically add createtask, eventdrivenactivity, and ontaskchanged activities in the status.

The Code logic of the execute method of the custom state activity.

Design period flowchart of state machine workflow implemented by custom state activity

Note: Approval _ Initialization is added to display the process logic during the design period. It will be deleted during the runtime and the approval _ initialization during the runtime will be regenerated.

To facilitate business development, we have added many attributes in the Custom state activity:

Assignedtotype:Where to obtain the approver can be a direct user, list field or SharePoint user group.
Assignedtovalue:The value of the approver corresponding to assignedtotype can be multiple user names separated by semicolons, either the name of the List field that stores the user, or the name of the SharePoint user group.
Actionstates:The operations that can be performed by the user and the status that the user jumps to when performing this operation. It is a collection of actionstates.

Action:User operations
Requireall:All users must perform this operation for signing.
Targetstatename:The status that the user jumps to when performing this operation.

Actionfield:A field that interacts with a task. When a task is generated, operations permitted by the user are passed in to this field. When a task changes, operations performed by the user are obtained from this field.
Sequenceapprove:Sequential approval. When there are multiple approvers, they can be reviewed one by one.

Custom state activityState Machine workflow dynamically generated during runtime

Approval Process in Initialization

Approval Process in eventdriven_1

Benefits of solutions

This solution can meet most of the requirements of SharePoint workflow applications, because it can basically implement nearly complex business processes that we have implemented using WF; currently, nearly 10 processes have been applied in a project to better solve users' complicated business needs. workflow development is very simple, and you only need to draw a flowchart in Visual Studio, after training, the customer's IT department staff can develop their own business processes.

WF provides the hosting function of the Process designer. On this basis, we have developed a WF process designer. If it is improved to support Sharepoint, the process design can be separated from Visual Studio, to implement a relatively independent solution.

The value of this solution is limited for any implementer, and each implementer can do only a few projects a year.

It has the highest value for Microsoft. If it can implement a perfect solution for Sharepoint workflows, it will greatly promote SharePoint applications.

Workflow selection between WF and SharePoint

WF is a workflow engine with high technical difficulty and it is very difficult to directly apply it to projects. At least it must be encapsulated as a workflow platform, although this is more difficult, however, application development on the platform will be very simple.

Many people think that the difficulty of WF lies in the state machine. In fact, the difficulty of WF is in its event-driven mechanism. If you can make an event-driven Sequential stream, the difficulty of creating an event-driven state machine is the same.

SharePoint workflows encapsulate the WF event-driven mechanism for development on SharePoint workflows. You only need to know how to use WF and SharePoint activities.
Therefore, we recommend that you develop applications on SharePoint workflows.

In this article, we provide a Sharepoint state machine solution with built-in default logic. In this solution, the process logic can be configured but cannot be customized. You can write the business logic in three places, before entering the status, createtask's methodnvoking event and ontaskchanged invoked event; in the next article, we will propose a Sharepoint state machine workflow solution for customizing business logic, to meet more complex business process requirements.