这是我们（东方易维）工作流产品设计过程中采取的设计：

一、流程实例的状态

   状态分为5种：实例化、执行中、挂起、手工结束、正常结束。

   状态的变迁如下图：

二、节点实例的状态

状态分为5种：实例化、执行中、挂起、手工结束、正常结束。

状态的变迁如下图：

三、具体节点的状态

   细分：

A、人工节点、等待节点

这两个节点被触发后存在一个执行等待的过程，所以可以被用户直接挂起和手工结束。人工节点的挂起意味着所有未完成工作项的挂起，同时相应时间服务的时间计算的挂起。手工结束会使流程跳过该节点（所有工作项手工结束），继续往后流转。

B、开始节点、结束节点、分支节点、自动节点

这些节点的特点在于被触发后立刻执行和流转，所以不会存在挂起和手工结束的状态。

C、并发节点、汇聚节点

并发节点和汇聚节点不存在挂起的状态，同时不能被用户直接手工结束，它们的状态受流程实例状态和相关节点实例状态的影响。

并发节点和汇聚节点的情况复杂一些，分模式讨论

图1

1、同步汇聚（图1）

根据情况触发节点0、节点1、节点2中的一个或多个，汇聚节点等待所有实际触发的节点完成后再执行流转。中间汇聚节点只会产生一个实例。

1.1、正常流转时的处理策略

当汇聚节点未被触发时（即节点0、节点1、节点2都未执行结束），并发节点处于执行状态，一旦汇聚节点被触发（即节点0、节点1、节点2有一个执行结束），并发节点正常结束并且汇聚节点处于执行状态，所有并发出的节点实例执行结束后，汇聚节点正常结束，流程继续流转。

1.2、用户挂起、手工结束相关节点的处理策略

1.2.1、汇聚节点未激活时

节点0、节点1、节点2的挂起和恢复执行不会影响并发节点的状态（依旧处于执行状态）；节点0、节点1、节点2的任一手工结束都会触发汇聚节点，使并发节点正常结束，如果所有并发的节点实例都结束（包括手工结束和正常结束），汇聚节点正常结束，触发流程流转。

1.2.2、汇聚节点已激活时

节点0、节点1、节点2的挂起和恢复执行不会影响汇聚节点的状态（依旧处于执行状态）；节点0、节点1、节点2的手工结束会影响汇聚节点的状态，每个节点实例的手工结束会引起汇聚节点的判断，如果所有并发的节点实例（包括正常结束和手工结束）都结束，汇聚节点正常结束，触发流程流转。

1.3、用户挂起、手工结束流程的处理策略

1.3.1、汇聚节点未激活时

流程的挂起和恢复执行不会影响并发节点的状态（依旧处于执行状态），节点0、节点1、节点2会被全部挂起或恢复；流程的手工结束会引起所有节点的手工结束。

1.3.2、汇聚节点已激活时

流程的挂起和恢复执行不会影响汇聚节点的状态（依旧处于执行状态），节点0、节点1、节点2未执行结束的实例会被全部挂起或恢复；流程的手工结束会引起所有节点的手工结束。

2、nOutOfM汇聚（图1）

根据情况触发节点0、节点1、节点2中的一个或多个，汇聚节点等待N个实际触发的节点完成后即执行流转（N>0且N<M，M为实际触发的节点个数），在N<=0和N>=M的情况下即为同步汇聚。中间汇聚节点只会产生一个实例。

2.1、正常流转时的处理策略

当汇聚节点未被触发时（即节点0、节点1、节点2都未执行结束），并发节点处于执行状态，一旦汇聚节点被触发（即节点0、节点1、节点2有一个执行结束），并发节点正常结束并且汇聚节点处于执行状态，N个并发出的节点实例执行结束后，汇聚节点正常结束，流程继续流转，M-N的节点实例被手工结束。

2.2、用户挂起、手工结束相关节点的处理策略

2.2.1、汇聚节点未激活时

节点0、节点1、节点2的挂起和恢复执行不会影响并发节点的状态（依旧处于执行状态）；节点0、节点1、节点2的任一手工结束都会触发汇聚节点，使并发节点正常结束，如果N个并发的节点实例都手工结束，并发节点正常结束，触发汇聚节点，汇聚节点正常结束，触发流程流转，M-N的节点实例被手工结束。

2.2.2、汇聚节点已激活时

节点0、节点1、节点2的挂起和恢复执行不会影响汇聚节点的状态（依旧处于执行状态）；节点0、节点1、节点2的手工结束会影响汇聚节点的状态，每个节点实例的手工结束会引起汇聚节点的判断，如果N个并发的节点实例（包括正常结束和手工结束）都结束，汇聚节点正常结束，触发流程流转，M-N的节点实例被手工结束。

2.3、用户挂起、手工结束流程的处理策略

2.3.1、汇聚节点未激活时

流程的挂起和恢复执行不会影响并发节点的状态（依旧处于执行状态），节点0、节点1、节点2会被全部挂起或恢复；流程的手工结束会引起所有节点的手工结束。

2.3.2、汇聚节点已激活时

流程的挂起和恢复执行不会影响汇聚节点的状态（依旧处于执行状态），节点0、节点1、节点2未执行结束的实例会被全部挂起或恢复；流程的手工结束会引起所有节点的手工结束。

3、辨别汇聚（图1）

是nOutOfM汇聚的特例，N=1

4、多实例汇聚（图2）

图2

根据情况触发节点0、节点1中的一个或多个，节点0和节点1任意一个执行结束后都会触发汇聚节点产生一个新的实例，汇聚节点实例紧接着触发节点2，节点2也会产生多个实例。

4.1、正常流转时的处理策略

当汇聚节点未被触发时（即节点0、节点1都未执行结束），并发节点处于执行状态，一旦汇聚节点被触发（即节点0、节点1有一个执行结束），汇聚节点会紧接着触发节点2，汇聚节点正常结束。所有并发出的节点实例执行结束后，并发节点正常结束。

4.2、用户挂起、手工结束相关节点的处理策略

节点0、节点1的挂起和恢复执行不会影响并发节点的状态（依旧处于执行状态）；节点0、节点1的手工结束会影响并发节点和汇聚节点的状态，每个节点实例的手工结束会引起汇聚节点产生新的实例并触发节点2，同时会引起并发节点的判断，如果所有并发的节点实例都手工结束，并发节点正常结束。

4.3、用户挂起、手工结束流程的处理策略

流程的挂起和恢复执行不会影响并发节点的状态（依旧处于执行状态），节点0、节点1、节点2会被全部挂起或恢复；流程的手工结束会引起所有未结束节点的手工结束。

5、隐式结束，没有汇聚节点与并发节点对应（图3）

图3

所有节点结束时（正常结束或手工结束），并发节点正常结束。流程的手工结束会引起所有未结束节点的手工结束。

四、流程实例状态变化对节点实例状态造成的影响

1、流程实例的挂起

   A类节点挂起，B、C类节点不受影响。同时在流程实例恢复执行之前，A类节点不允许用户直接恢复执行。

2、流程实例的手工结束

   所有节点全部手工结束。

五、节点实例状态变化对流程实例状态造成的影响

隐式结束的情况下，节点的手工结束或正常结束都会触发流程的判断，如果所有的节点都已结束则流程结束。

用户的需求大概分为两部分：一部分是整个项目完全基于工作流来搭建开发，这也是很多工作流厂商患有“平台压迫症”的原因；另一部分是将工作流作为业务组件加入已有的项目中，推动业务的“审批”流转。

前者的要求显然更高，但也意味着有更多的利润。其实这一部分的用户又可以进一步的细分：一是技术能力比较差的公司，他们通过层层外包接到项目，而又没有实力自己开发，于是想通过采购工作流加上几个刚入门的程序员来完成整个项目的开发（这类用户往往也是业务平台最大的客户群），他们想着是一整套的开发解决方案，甚至包括业务分析；二是对业务编程的需求，他们需要流程引擎能够侵入业务编程的内部，对业务的状态和生命周期进行灵活的管理，从而最大程度的简化开发或者说满足一些复杂业务编程的需要。

后者的需求则比较简单，多是某一行业的项目公司，突然碰到有审批的需求了，采用工作流多是满足人工“审批”的需要，以及部分的统计分析。

需要承认，工作流其实与最终用户还差得很远，也就是说在众多厂商的网页上，那副著名的业务流程生命周期其实是一句空话。一句话说，就是那个什么流程设计器是给程序员用的，至于用户，哪凉快哪去。也就是说现在的工作流还不能给最终用户提供价值。OK，既然工作流的价值是提供给集成商的，集成商就会考虑成本，于是工作流能否提供一个完整的开发解决方案就成了最重要的考量。

最后说说市场。工作流其实有着很大的市场，只不过这个市场被开源工作流和平台瓜分掉了。因为目前的工作流不能给最终用户提供价值，所以集成商在遇到审批的需求时，首先想到的会是开源的工作流引擎，从jbpm、osworkflow的流行也可以看出这一点，并且知识的积累确实比购买工作流来的划算，同时很多公司通过积累也会有自己的流程组件，这并没有太大的难度。难度留给技术能力一般的公司，他们首先想到的会是一整套解决方案而不仅仅止于流程服务，于是平台出现了，平台说：“灰壳显灵，银弹来了。”

关于平台，有一个很时髦的流行词汇，叫“业务应用基础平台”，稍候待续。 py工作流是国内比较好的工作流之一。大概看过它的一些文档，分析一下。
1、路由模型
 py支持的工作流模式其实并不多，只是支持1到7七种模式而已，其中比较重要的是模式6和模式7，即M选N分支和M选N聚合，看过它的实现，利用转移线条件来触发转移线，从而触发后续的节点。这样做比较简单，但是同时也存在很多问题，例如在路由非常复杂的情况下，例如多个分支节点的串联，以及并发路由存在多个节点时，这种做法实现起来就非常困难。另外，并发路由的工作流变量会存在相互冲突的情况，也包括业务数据的冲突。可以说py的路由模型还是很简单的，支持简单的业务可能没有问题，对于复杂的业务可能需要很多其他额外的办法。当然，很多国内的工作流甚至连模式6和模式7都支持不了，同时工作流的应用目前还具有很浓的“审批”的影子（貌似有人很讨厌审批这个说法），所以目前的路由模型应该满足需求了。
2、任意路由和回退
 没有看到任意路由和回退的复杂示例。关于任意路由，产品说明中说到可以在整个流程范围内任意自由路由，我觉得这个说法本来就是有问题的，并发路由的情况下，并发支线往主线上跳转，这种情况会有很多问题存在，其他并行的支线如何处理？或者说根本就没有考虑到这些复杂的情况？回退也是一样的道理，至于业务补偿的提出还是不错的，不过推给了用户自己设置回退动作。
3、关于WFMC和BPEL规范
 看看流程定义文件就知道了，它不支持任何规范。敢说国内工作流的流程定义就没有遵循规范的。
4、参与者的指定
 提供了组织机构、角色、个人这三种常见的参与者设置模式，还提供了流程启动者、活动执行者、从相关数据或从规则逻辑中获取参与者的模式。
5、工作的代理和代办
6、时间服务
 提供了四种时限。活动提醒、活动执行、流程提醒、流程执行。
7、业务开发
 感觉这是非常出彩的地方，在一个简单的示例中几乎不需要任何编码，比如一个简单的请假管理。看看它的流程定义文件，它几乎将整个业务表单都嵌入到流程定义里去了。这样做是否合适？我个人倾向于引擎与业务完全分开，通过反射或者某种映射将两者关联到一起。如果是用户自己开发已有的复杂业务，如何将工作流嵌入？至于studio也是非常出色的，具有开发调试的功能。调用接口非常的清晰。
总结一下：py工作流还是一个不错的工作流引擎，抛开它的宣传，感觉引擎的实现还是有些简单，或者说只是满足了目前的一些常见需求，至于所说的SOA和服务编排，我觉得目前还不现实。它的优势在于与其平台的完全融合，能够利用很多既有设施，可是这又何尝不是把双刃剑？另外，强大的市场宣传和良好的服务团队也是选择工作流时的重要考虑。 委办是什么？即分发给A的工作项可以委派给B代为进行处理。委办只针对个人。委派给组织或岗位似乎没有意义。
一、委办的分类
 1、用户单一工作项的委办以及收回委办
 2、用户所有工作项的委办，全权委办
 3、用户按流程划分工作项的委办，基于模板的全权委办，也可以理解为基于业务的委办
二、委办的触发与终止
 1、对于单一工作项的委办，在待签收和待办工作项列表需要出现委办的功能按钮，由用户选择其他用户代为办理。工作项委办后进入委办工作项列表，用户可以收回委办，同时用户和被委办人都可以对该工作项进行办理，用户自己处理则工作项自动被收回委办。
 2、对于全权委办以及基于模板的全权委办，需要委办申请单。用户通过填写委办申请单，将某段时期内工作项列表的处理工作委派给他人。消息通知：当用户将工作委派给指定的被委办人时，被委办人可以收到提醒消息。
 3、委办的自动终止以及手动结束：当委托的时间到期时，委办功能自动终止，委办申请记录将只读。用户也可以手动结束委托，逻辑删除或对委办申请记录进行修改。维护委办申请列表。
三、委办工作项列表
 1、用户可以在委办列表里对委办的工作项状态进行跟踪，对于还未被被委办人签收的工作项可以收回或直接办理
 2、被委办的工作项进入委办人的委办列表
 3、被委办的工作项按状态进入被委办人的待签、待办和办结列表，注明是被委办即可
 4、委办工作项的再委办，工作项增加委办的说明字段，委办工作项的依次状态影响
四、其他
 1、提交工作项页面，选择用户出现委办人时，名字红现，括弧注明其将被委办的被委办人
 2、提交工作项页面，选择部门或角色包含委办人时，不做处理。引擎生成工作项时做出处理，对工作项做出委托说明
 3、流程跟踪列表，增加委办说明字段 既然是与用户相关的权限，那么权限的表现则一定与UI紧密相连。工作流管理系统里，用户与工作流的交互界面有四种：
1、流程设计器
    流程设计器的功能比较单一：定义或更新流程定义。里面涉及到包、模板和版本的概念。资源即流程模板（例如发文模板、收文模板），权限可以细分为：维护、只读以及不可见。
2、流程管理控制台
  对流程实例（包括活动实例和工作项实例）进行管理。这里对资源的划分有两种方式：操作和数据。从操作来分比较琐碎，例如：流程实例的挂起、终止、恢复、跳转，活动实例的挂起、终止、恢复等等，当然可以做一种集合，例如：对流程实例的管理、对活动实例的管理、对工作项实例的管理、时间服务的管理等等。从数据划分则很好理解，例如：发文的流程实例、收文的活动实例等等。两种方式的组合构成最终的权限。
3、工作项列表
    这个似乎没什么好说的，工作项直接分配到用户、部门和岗位。
4、与流程相关的业务数据
    用户对业务自身的权限以及不同流程节点对业务的权限。看问题的两种方式。业务数据处于流程中时由流程决定权限，例如拟稿时可以操作哪些字段，审批时是否可以上传附件等等。流程结束后，业务数据归档，此时的权限由业务权限+流程权限组合。简单的一个例子：普通用户A可以在发文模块里看到自己参与过的所有发文文件，发文管理员B则可以看到发文模块里所有的发文文件。
    
结合具体的业务需求：
1、主控岗位的提出。例如发文管理，存在主控岗位，可以对所有的发文流程进行管理，催办、督办等等。
2、大集中模式下对数据的再划分。还是以发文管理为例，北京公司的发文管理员对北京的发文数据进行管理，上海公司的发文管理员则只能对上海的发文数据进行管理。

最终的权限分类：
1、流程设计器里流程模板的可见与不可见。可见即可维护。
2、流程管理按操作来分显得没有实际的意义，用户关注的是业务数据即操作的范围。流程实例（活动实例）的可见与不可见。可见即可操作。更进一步说，用户甚至根本都不会登录到流程管理控制台，他会倾向于在业务菜单里有自己相应的流程管理功能，例如在发文管理里增加发文催办、督办等等。
3、不用
4、往业务权限表里增加流程参与者的权限信息。

总结：总是感觉工作流管理部分的权限不是那么的必要，流程定义的复杂度让最终用户很难直接使用，流程实例的管理更多的是契合到业务中去，而这种契合表现则是流程数据按业务进行划分后的管理。