EOS工作流引擎原理.doc

实用文案 EOS 工作流引擎工作原理 1. 工作流基础知识 2. EOS 工作流引擎工作原理 本文是我在工作之余写的一点我对 EOS 工作流的了解，我的理解不一定全是对的，可 能会与引擎的真正的面目有出入。所以只能提供给大家一点参考。 2.1. EOS 工作流引擎核心调度算法 EOS 工作流最重要的组成部分是它的核心调度算法，在我们没有深入研究它的工作原 理之前我们认为它的工作原理是在工作项， 活动和流程实例对象上加了一些标志位来驱动流 程的运转。 认为其引擎完全是个由数据库来驱动流程的引擎 （安徽二期的工作流平台好象就

是以库表来驱动流程的运转） ，其实它是由事件来驱动流程运转的引擎，数据库只是把引擎 运转前后的状态持久化。在我近来在工作之余对其引擎的工作原理进行跟踪才弄明白在 EOS 帮助文档上介绍的“事件驱动”的工作流引擎。 2.1.1. EOS 工作流引擎的事件类型 事件名称 事件代码 START_PROCESS：启动流程 1001

SCHEDULE_NEXT_ACTIVITY ：由线程来启动下个活动实例 1002

BACKWORD_ACTIVITY ：回退活动 1003

SUSPEND_PROCESS ：流程挂起 1004

RESUME_PROCESS ：启动挂起流程 1005

CHANGE_PROCESS_STATE ：改变流程状态 1006

TERMINATE_PROCESS ：终止流程 1007

ABORT_PROCESS ： 1008

标准 实用文案 FINISH_PROCESS ：结束流程 1009

PRESTART_ACTIVITY ：重起流程 2000

START_ACTIVITY ：启动活动实例 2001

RESTART_ACTIVITY ：重起活动实例 2002

CHANGE_ACTIVITY_STATE ：改变活动实例状态 2003

FINISH_ACTIVITY ：结束活动实例 2004

TERMINATE_ACTIVITY ：终止活动实例 2005 ABORT_ACTIVITY ： 2006

SUSPEND_ACTIVITY ：挂起活动实例 2007 RESUME_ACTIVITY ：启动挂起的活动实例 2008 SUSPEND_WORKITEM ：挂起工作项 3001 RESUME_WORKITEM ：启动挂起工作项 3002 CHANGE_WORKITEM_STATE ：改变工作项状态 3003

FINISH_WORKITEM ：结束工作项 3004 TERMINATE_WORKTIEM ：终止工作项 3005

ABORT_WORKTIEM ： 3006 EXCEPTION_PROC_TIMEOUT ：流程超时事件 4002

EXCEPTION_PROC_REMIND ：流程临近超时事件 4003

EXCEPTION_ACT_TIMEOUT ：活动超时事件 4004

EXCEPTION_ACT_REMIND ：活动临近超时事件 4005

APPLICATION_RETURN ： 5001

以上的每个事件都是原子的不可分割的。其中一系列事件的集合通过 EOS 引擎事件调 标准 实用文案 度机制实现我们平时在工作中经常遇到的如启动流程，结束工作项等等。 （在事件类型类中 EOS 定义了 29 种事件，但在事件工厂类中 EOS 定义了 26 种类型。） 2.1.2. EOS 工作流事件调度机制 EOS 事件的调度服务是在工作流引擎初始化时通过服务工厂类加载到内存中 （ServiceFactory.initEventService() ）。用户可以通过服务工厂类（ ServiceFactory ）取得

JVM 的唯一事件服务实例进行事务调度。 所有的事件程序入口都是事件类 （ EventService ），

这个类其实是个接口， 其有两个实现类， 一个是单线程的实现类 SingleThreadEventService （在实现代码中其实不是单线程，而是单例的对象），一个是多线程的实现类 MulThreadThreadSvc ，（其实现方式不在这里详细说明，多线程的类后面又跟了一大堆的 线程池实现代码） ，在事件服务类中有一个属性类是 WFEventDisposer ，这个类包含了事

件的注册，事件的发布，事件的注册是一个静态代码块实现的。注册了上节描述的 29 种事 件，其实就是把相应的事件代码注册到相应的处理类，事件处理类共用 5 个 （ ProcessScheduler ， ActivityExecuter ， ExceptionHandler ， WorkItemHandler ， ApplicationHandler ），对应事件代码的前 5 个数字；共有事件的发布有两种，一种是正常 发布，一种是无异常的发布（即在具体执行事件时关闭了异常处理） 。所谓的事件发布是给 事件服务类传递一个事件对象（ WFEvent 类），这个事件对象包含了事件类型，线程名，事

件 ID ，流程定义 ID ，活动定义 ID ，活动实例 ID ，和工作项 ID 等等。 以上简要的描述了事件模型， 下面来拿我们平时用的最多的一个构件： 结束工作项来详

细跟踪它的事件处理。 结束工作项可能是最具有代表性的一个流程动作， 因为在做这个时间

后遍历了整个流程实例的流程： 1， 用户通过引擎的 API 调用 WorkItemManager 类的 finishWorkItem 方法，该

方法通过服务工厂取得持久层的数据访问服务，并根据 workitemID 取得

标准 实用文案 WFWorkItem 对象。做相关的判断后通过事件工厂类的 createFinishWorkItemEvent 方法创建个事件代码为 3004 的事件对象 （ WFEvent ）。然后通过服务工厂类取得事件服务类把该事件对象发布给事件 处理服务。从此刻就开始了 EOS 事件调度服务的运转。 2， 事件服务类（拿单线程事件服务类做例子）拿到这个事件类后把该事件通过

WFEventDisposer 发布该事件。具体的发布过程很简单，即判断该事件类型 是否已注册，如果已经注册则取到改事件代码的注册类。该代码是 3004 ，则 应取 WorkItemHandler。然后调用 WorkItemHandler 的 invoke （）方法， 3， WorkItemHandler类 invoke （）中写到： if(event.getType() == 30004)

{finishWorkItem(event);} 则找到该方法， 该方法开始做了相关的判断后做相关 标志位的修改：置当前工作项的状态为 12 ，然后判断当前活动是否结束。 （大 概的算法是取得已经结束的工作项和该活动总的工作项，取得活动定义的多工 作项是否启动。如果是多工作项则判断完成个数策略：是按百分比还是按操作 员个数等等，做一系列的判断后得到应该结束的工作项，如果小于等于已经结 束的工作项则该活动结束， 没有启动多工作项则相应的处理要简单点） ，如果该 活动已完成，则调用事件服务的结束活动实例事件createFinishActivityEvent ；

如 果 没 有 结 束 则 判 断 工 作 项 启 动 的 策 略 是 “ at_the_same_time ” 还 是

“ one_by_one ”，如果是“ one_by_one ”则找本活动实例下的工作项状态为

1 的工作并启动它。 4， 结束活动实例是调用事件工厂的方法createFinishActivityEvent ，新建一个事

件代码为 2004 的事件。用 createFinishWorkItemEvent 的方法发布该事件。

到 ActivityExecuter 类中找到 finishActivity ，该方法修改活动实例状态为 7 ，

标准 实用文案 填写活动结束时间。如果该活动注册了时限则取消活动时限的注册。如果该活 动实例定义了结束活动的触发动作则触发该动作（通过 WFAppCaller 调用）。

最 后 由 事 件 工 厂 产 生 一 个 事 件 代 码 为 1002 的 createScheduleNextActivityEvent 事件。由事件服务发布事件。 5， 启动下个活动实例的事件动作是事件工厂调用 scheduleNextActivity 方法，该

方法通过流程定义找到下个环节的转移条件，并根据转移条件和分支模式（全 部分支： AND ；多路分支： XOR ；单一分支： OR ）生成一个环节定义列表。 引擎首先把未启动的活动实例和挂起的活动实例找到，如果没有则生成一个活 动实例。然后生成一个转移对象（WFTransition ），最后把待启动的活动实例

对象放到一个列表中。根据该列表中的活动定义的启动策略（直接启动，待激 活，由规则逻辑指定）来启动活动实例；如果是直接启动活动实例则由事件工 厂新建一个事件代码为 2001 的事件 startActivity ，如果待激活策略则由事件 工厂产生事件代码为 2000 的事件 preStartActivity 。同样如果在流程定义中定 义了创建活动实例触发的事件则触发该事件， scheduleNextActivity 方法做了 很多业务处理的事情，所以比较复杂。 6， 事件服务调用 startActivity 方法，修改当前活动状态位为 2，并向时限管理服 务注册时限，然后通过活动执行类的帮助类分派工作项，分派工作项的过程是 判断是否是多工作项，如果不是则按参与人员分派，如果是则判断多工作项的 启动策略，启动工作项业务处理比较复杂，并没有相应的事件代码对应，在这 里不详细介绍。 以上的六个步骤完成了我们平时最常用的完成工作项的方法。综上所述应该能够对 EOS 工作流的事件调度机制有个清楚的认识，比如结束工作项的事件调度有

标准