In the previous article we mentioned, SharePoint task encapsulation mechanism determines the two issues of its application state machine exists, is a multiplayer approval, it is required to add a EventDrivenActivity approval for every person; the other is the number of approvals in the design phase it must be determined.
These two issues have no way to solve it? Fortunately, WF provides a process to dynamically modify the function, we can inherit its own activities from the State StateActivity, depending on the number of approvers dynamically add CreateTask, EventDrivenActivity and OnTaskChanged activities in the state prior to execution state.
Execute method defined from the State of the activity code logic.
Design of self state machine workflow definition activities to achieve a flowchart State
Note approval _Initialization is to show the design of process logic increases, it will be deleted runs, regenerate approval _Initialization runtime.
In order to facilitate the development of business we added a lot of property in the custom State activities:
AssignedToType: Where did people get the approval, you can direct users, groups of users or SharePoint list field.
AssignedToValue: the approver AssignedToType value corresponding to a plurality of user names may be separated by semicolons, and may save the user a list of field names, may be SharePoint user group name.
ActionStates: allows the user to perform the operation, and the user to jump to the state of performing the operation; ActionState is a collection.
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