SharePoint state machines with built-in default process logic
As we mentioned in the previous article, SharePoint's task encapsulation mechanism determines that there are two problems with its state machine application, one is to add one eventdrivenactivity for each approver, and the other is that the approval number must be determined during the design period.
Is there any way to solve these two problems? Thanks to WF's ability to dynamically modify the process, we can inherit one of our state activities from stateactivity, and dynamically add CreateTask, EventDrivenActivity, and Ontask in the state, depending on the number of approvers before the status is executed. Changed activities.
The code logic that customizes the Execute method of the state activity.
Design period flow Chart of State machine workflow implemented by using custom states activity
Note Approval _initialization is added for the design period to show process logic, the runtime is deleted, and the approval _initialization for the runtime is regenerated.