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 ，