谈流程引擎

在分布式的架构中，流程引擎和权限引擎也不适合分离构建，两者之间的耦合度相当高，一个好的流程引擎首先要依赖于一个完善的权限模型和架构，其中包括了细粒度的数据权限控制等。

流程引擎中会产生动态权限控制，动态权限和静态权限的区别是静态权限是固定的，而动态权限是跟随流程节点的执行动态变化的，如当你处理到某个流程节点的时候，你对某个工单有查看权限，但是一旦审核或处理完成后，即权限自动回收。这是对静态权限的一个重要扩展。

流程引擎的活动节点需要参与人，参与人可以是具体的人，可以是岗位，可以是角色，也可以是直接上级的某个角色。参与人往往是一个抽象的概念，在最终流程执行的过程中会最终定位到一个或多个人。在处理静态功能和操作级权限的时候，往往定义到具体的角色和角色组就足够用了。但是在考虑和流程引擎结合的时候，需要进一步定义用户组。用户组是一个多维度累加后的一个概念，举个例子来说项目管理员是角色的概念，而某个组织某类产品的项目管理员即定位到具体的用户组，如市场部消费类产品项目管理员。

在流程执行过程中映射到具体的参与人一般有两种做法，在这里说明如下。一种是活动节点只配置到角色，即只配置到当前节点有项目管理员处理。在实际的工单中有具体的组织信息，有具体的产品线信息，因此根据映射可以明确的映射到某个工单是需要定位到哪个组织哪个产品的项目管理员，即用户组。在这个用户组里面往往可以定位到具体的一个人。如果还定位到多个人则可以处理为流程抢先处理机制。如果某个流程只涉及到根据组织进行划分，则有第二种不需要用户组的做法，即所有的人全部放到角色里面，流程在执行过程中首先映射出具体的人员，然后根据组织ID或上级组织ID对人员进一步进行筛选即可，这种方法的可行之处主要在于本身人员信息属性中就带有所属组织信息。

工单和流程模块是一种完全的松耦合关系，一个工单根据根据类型的不同挂多个不同的流程模版，而多个工单也可以同时挂接同一个流程模版。因此工单和流程模版之间需要有一种支撑这种松耦合的关系表。即实现工单和流程之间的一种映射。对于流程模型而言，关键的内容是流程模版，活动节点，连接弧和路由信息，活动节点对应的参与人信息，路由事件（前+后）相关信息等。这些信息在流程启动后又涉及到具体的实例信息，如流程实例信息，活动节点产生的任务实例信息等。

对于不属于一套完整的快速开发平台产品的流程引擎，最好的方式就是只管流程，而不管任何和表单相关的数据。包括在流程处理环节中可以涉及到的需要新补充填写的扩展字段等，这些内容最好的方式就是都放给应用侧来处理，流程引擎可以提供调用接口，但是不要去建模，存储和处理这些数据。

对于企业私有云PaaS平台中的流程引擎，实质是BPaaS的一部分内容，体现了流程即服务的思想，流程和应用完全松耦合开。在这里流程引擎必须要支撑内部的多租户，而租户就是外部的多个业务系统或应用模块。在多个业务系统之间需要考虑流程引擎本身的数据，权限等各方面内容的隔离性。

流程引擎需要有完善的条件节点和表达式节点的定义，在这里涉及到工单中的任何属性都可以作为表达式节点的计算条件参与到具体的计算和路由分支的选择。同时对于复杂的场景，在路由发生前和发生后还需要支持对外部服务接口的调用，外部接口服务是一个完整的业务逻辑触发，在这种情况下一个工作流引擎已经实现了部分BPM服务编排的内容。

再次强调下BPM是在工作流引擎之上，更加强调的是端到端流程整合，业务流处理和服务自动编排，对于顶层的BPM流程下钻后才是具体的审批流处理。

  青春就应该这样绽放   游戏测试：三国时期谁是你最好的兄弟！！   你不得不信的星座秘密