在前文中我们提到 SharePoint 是在 WF 工作流引擎之上，封装了事件驱动接口的一个工作流平台； SharePoint 在 WF 上扩充了很多 Activity，其中和 WF 密切相关的有三个常用 Activity是： OnWorkflowActivated，CreateTask，OnTaskChanged，
SharePoint状态机工作流解决方案（二）：SharePoint中的WF状态机
。一个简单的 SharePoint 顺序流。
OnWorkflowActivated：响应流程启动的事件。
CreateTask：生成 SharePoint 的任务。
OnTaskChanged：响应任务被改变的事件。
在一个流程中只能有一个 OnWorkflowActivated ；可以有任意数量的 CreateTask 和 OnTaskChanged ，但必须成对；
很多 SharePoint 工作流解决方案，在顺序流模式下，将 CreateTask 和 OnTaskChanged 组成一个自 定义的Activity，然后利用 ReplicatorActivity 的自动复制功能，使之支持多人同时审批。这种方式流 程很简洁，但顺序流不支持回退，遇到需要回退的情况，只能通过 WhileActivity 模拟，流程又会变得 很复杂。
一个简单的 SharePoint 状态机
流程包含了三个状态启动、审批和完成；再添加其他状态就可以实现状态之间的回退。
“响应启动事件”中包括了 OnWorkflowActivated 和 SetStateActivity
“添加审批人”中包括了 CreateTask
“响应审批事件”中包括了 OnTaskChanged 和 SetStateActivity
WF 的每个 StateActivity 只能包含一个 StateInitializationActivity，用于添加审批人和实现初 始化的业务逻辑，
电脑资料
《SharePoint状态机工作流解决方案（二）：SharePoint中的WF状态机》(https://www.unjs.com)。可以包含多个 EventDrivenActivity，用于同时响应多个审批事件，和实现审批后的业 务逻辑；EventDrivenActivity 的第一个控件必须是 HandleExternalEventActivity (OnTaskChanged的 基类）。从上图中我们看到，在状态机下 CreateTask 和 OnTaskChanged 仍然是必须成对的，但他们的位置分 开了，CreateTask 处于 StateInitalizationActivity 中，OnTaskChanged 处于 EventDrivenActivity 中。
可以多人同时审批的 SharePoint 状态机
如果要多人同时审批，需要在 StateInitializationActivity 中添加多个 CreateTask，和在 StateActivity 中添加多个 EventDriven。
“添加审批人”中包括了 A 的 CreateTask 和 B 的 CreateTask。
“响应A的审批事件”中包含了 A 的 OnTaskChanged。
“响应B的审批事件”中包含了 B 的 OnTaskChanged。
如果需要添加更多的审批人，以此类推。
SharePoint 状态机工作流存在的问题
从上面我们可以发现，SharePoint 的状态机应用存在下面两个问题：
1、EventDrivenActivity 中的流程存在冗余，当流程复杂，审批人多的时候，很难维护。
2、审批人数在设计期就必须确定，不能改变。
在下一篇《SharePoint 状态机工作流解决方案（三）；内置缺省流程逻辑的 SharePoint 状态机》中 ，我们会介绍对这两个问题的解决方案。