在前文中我们提到 SharePoint 是在 WF 工作流引擎之上,封装了事件驱动接口的一个工作流平台;SharePoint 在 WF 上扩充了很多 Activity,其中和 WF 密切相关的有三个常用 Activity是: OnWorkflowActivated,CreateTask,OnTaskChanged。
一个简单的 SharePoint 顺序流。
OnWorkflowActivated:响应流程启动的事件。
CreateTask:生成 SharePoint 的任务。
OnTaskChanged:响应任务被改变的事件。
在一个流程中只能有一个 OnWorkflowActivated ;可以有任意数量的 CreateTask 和 OnTaskChanged ,但必须成对;
很多 SharePoint 工作流解决方案,在顺序流模式下,将 CreateTask 和 OnTaskChanged 组成一个自定义的Activity,然后利用 ReplicatorActivity 的自动复制功能,使之支持多人同时审批。这种方式流程很简洁,但顺序流不支持回退,遇到需要回退的情况,只能通过 WhileActivity 模拟,流程又会变得很复杂。
一个简单的 SharePoint 状态机
流程包含了三个状态启动、审批和完成;再添加其他状态就可以实现状态之间的回退。
“响应启动事件”中包括了 OnWorkflowActivated 和 SetStateActivity
“添加审批人”中包括了 CreateTask
“响应审批事件”中包括了 OnTaskChanged 和 SetStateActivity
WF 的每个 StateActivity 只能包含一个 StateInitializationActivity,用于添加审批人和实现初始化的业务逻辑。可以包含多个 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 状态机》中,我们会介绍对这两个问题的解决方案。