SharePoint 状态机工作流解决方案（一）：为什么要用状态机

升木

　　以前一直是作 Windows Workflow Foundation 的工作流平台，对 WF 比较熟悉，开发的工作流平台满足了公司实施的各种项目的工作流应用的需求。
　　最近作了一个 SharePoint 文档库项目，里面的审批流程，涉及到 SharePoint 工作流；一直都听说 SharePoint 下没有成熟的工作流解决方案，但接触了以后发现，SharePoint 是一个非常好的工作流平台；虽然在实际应用中还有一些设计和技术上的问题需要解决，可这些问题解决以后，SharePoint 工作流几乎能满足各种项目的需求。
　　SharePoint 的工作流是基于 Workflow Foundation 的，我们就先谈谈 WF，只有对 WF 有正确的认识，才能找到 SharePoint 工作流的解决方案。
　　Workflow Foundation 的 2 个最显著的特点
　　直接支持状态机模型
　　状态机是工作流的理论基础，但以前几乎没有工作流产品直接支持状态机，因为一般的工作流产品大都有直接的商业目的，目标就是应用，而状态机的技术难度较高，出于降低应用难度的原因，都会对状态机进行封装，使之可以在一个流程图中实现流程的跳转。通过牺牲功能，来换取易用性。
　　而 WF 的目标是一个基础的架构，所以可以直接支持状态机模型，虽然开发有较高的技术难度，却实现了完善的流程流转功能。而在 WF 之上，可以构建不同的平台，来满足不同应用的需要。
　　我们的工作流平台实施了近百个业务流程，都是采用状态机，没有一个能够通过顺序流来实现，所以状态机是 WF 应用的基础，只有通过状态机才能实现复杂的流程逻辑。有些人通过在顺序流中加入循环来实现流程的回退，这种发式大大的提高了流程的复杂度，并限制了流程的功能。
　　细粒度的Activity
　　WF 的基础构件是 Activity, Activity 的数量很多，功能很细；在编码中需要的所有流转相关的语句，几乎都有对应的 Activity；通过现有 Activity 的继承，可以方便的对功能进行扩充；通过 CodeActivity 可以方便的实现业务逻辑。
　　但有一些 WF 和 SharePoint 工作流解决方案却对 Activity 进行了封装，不再支持原生的 Activity, 对流程的开发可能有一些好处，但对业务逻辑的开发却带来了非常大的麻烦。
　　SharePoint 工作流和 WF 的关系
　　WF 是一个工作流引擎，实现了流程驱动的功能，对外部提供了流程驱动的接口，它既可以应用于人机交互的流程，也可以实现工业控制的流程。但是 WF 技术难度较高，代码复杂；在 WF 上开发一个最简单的人机交互流程，也需要了解其复杂的机制，实现流程驱动的接口，编写大量的代码。
　　SharePoint 是一个工作流平台，它应用于人机交互的流程，在 WF 流程驱动的接口上实现了角色或人员对流程驱动的功能。所以在 SharePoint 上，既不需要了解 WF 流程驱动接口的机制，也不需要编写代码，就可以实现一个简单的人机交互流程。
　　现有解决方案的问题
　　见过几个 SharePoint 的已完成和开发中的工作流产品和解决方案，但是都不支持状态机和原生的 Activity；不支持状态机，流程的回退和跳转功能的实现会很困难；不支持原生的 Activity，实现业务逻辑很麻烦。
　　WF 工作流的解决方案对经验有很高的要求，只有用过其它的工作流产品，对其不足有所了解，才能认识到 WF 的精妙；只有对 WF 有深入的了解，并进行过成功的应用，才能对 SharePoint 工作流有信心。虽然前面提到的那几个 SharePoint 工作流产品的设计和开发人员的技术水平还是比较高的，但经验上有所不足，连复杂的 WF 应用都没有成功实施过，如何设计开发 SharePoint 的工作流产品和解决方案。
　　成功的解决方案即能满足功能上的要求，同时它的应用也应该是一件简单的工作。
　　SharePoint 工作流解决方案的基础
　　综上所述要想成功应用 SharePoint 工作流，以下两点是基础：
1、采用 WF 的状态机模型
2、支持 WF 原生的 Activity
　　在下一篇《SharePoint 状态机工作流解决方案（二）；SharePoint 工作流中的 WF 状态机》中，我们会介绍 SharePoint 状态机应用会遇到的问题，再后面的文档中，会介绍我们的解决方案。