在前文中我们提到，SharePoint 的任务封装机制决定了它的状态机应用存在两个问题，一个是多人审批时，需要为每个审批人都添加一个EventDrivenActivity；另一个是审批人数在设计期就必须确定。
这两个问题有没有办法解决呢？幸亏 WF 提供了流程动态修改的功能，我们可以从 StateActivity 继承一个自己的 State 活动，在状态执行前根据审批人的数量，在状态中动态添加 CreateTask、EventDrivenActivity 和 OnTaskChanged 活动。
自定义 State 活动的 Execute 方法的代码逻辑。
采用自定义 State 活动实现的状态机工作流的设计期流程图
注意 审批_Initialization 是为了设计期展现流程逻辑而增加的，运行时会被删除，重新生成运行时的 审批_Initialization。
为了方便业务的开发我们在自定义 State 活动中增加了很多属性：
AssignedToType：从哪获取审批人，可以是直接的用户，列表字段或 SharePoint 用户组。
AssignedToValue：与 AssignedToType 对应的审批人的值，可以是分号分隔的多个用户名，可以是保存用户的列表字段名，也可以是 SharePoint 用户组名。
ActionStates：允许用户执行的操作，和用户执行该操作时跳转到的状态；是一个 ActionState 的集合。
Action：用户的操作
RequireAll：需要所有的用户都执行此操作，用于会签。
TargetStateName：当用户执行此操作时，跳转到的状态。
ActionField：和任务进行交互的字段，生成任务时，将用户允许的操作传入到此字段；任务改变时，从此字段获取用户进行的操作。
SequenceApprove：顺序审批，当有多个审批人时，可以逐个进行审批。
自定义 State 活动运行时动态生成的状态机工作流
审批_Initialization 中的流程
审批_EventDriven_1 中的流程
解决方案的价值
这个解决方案，能够满足 SharePoint 工作流应用大部分的需求，因为它基本能够实现我们用 WF 实施过的近百个复杂的业务流程；现在也已经在一个项目中应用了近 10 个流程，较好地解决了用户复杂的业务需求；工作流的开发非常简单，只需要在 Visual Studio 中绘制流程图即可，客户的 IT 部人员经过我们培训后，就可以自行开发业务流程。
WF 提供了流程设计器的 Hosting 功能，我们在此基础上，开发过一个 WF 流程设计器，如果将其改进支持 SharePoint，那么流程设计就可以脱离 Visual Studio，从而实现一个相对独立的解决方案。
这个解决方案对任何一个实施商的价值都是有限的，每个实施商一年都只能做几个项目。
它对微软的价值最高，如果能够实现 SharePoint 工作流的完善的解决方案，将较大地推进 SharePoint 的应用。
WF 和 SharePoint 工作流的取舍
WF 是个工作流引擎，技术难度很高，直接应用在项目中是非常困难的；至少要先封装为一个工作流平台，虽然这个的难度更高，但在平台上的应用开发将会很简单。
很多人认为 WF 困难在状态机上，实际上 WF 的难点是在它的事件驱动机制，如果你能做一个事件驱动的顺序流，那么做一个事件驱动的状态机的难度是一样的。
SharePoint 的工作流封装了 WF 的事件驱动机制，在 SharePoint 工作流上进行开发，你只需要了解 WF 和 SharePoint 的 Activity 怎么用。
所以我们建议在 SharePoint 工作流上进行应用的开发。
在本文中我们给出了 内置缺省逻辑的 SharePoint 状态机解决方案，在这个方案中，流程逻辑可配置的，但不能自定义；可以有三个地方写业务逻辑，进入状态前、CreateTask 的 Methodnvoking 事件和 OnTaskChanged 的 Invoked 事件；在下一篇文章中，我们将提出 自定义业务逻辑的 SharePoint 状态机工作流解决方案，以满足更复杂的业务流程需求。
转载于:https://www.cnblogs.com/wfplatform/archive/2009/08/17/1547951.html