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工作流的事件调度机制有个清楚的认识，比如结束工作项的事件调度有

3004->2004->1002->2001这几种事件的触发。同样还有我们平时比较常用的启动流程

实例方法首先是创建一个流程实例，然后开始事件调度：10001->10002->2001,最后是分派工作项。

OSWorkflow里也有自己的调度机制，但在业务上要比EOS简单的多，准确的讲OSWorkflow 只有两个概念：steps（步骤）和actions（动作）。一个简单的调度过程

它可能从一个步骤流转到另外一个步骤（或者有时候还是停留在一样的步骤）。它的调度其

实就是一个类：AbstractWorkflow，这个类里面有两个方法：doAction和transitionWorkflow基本实现了所有的调度（其实也不能算是调度，只能算是状态的迁移）。OSWorkflow 最大的优点是在执行调度过程中执行的一系列的Function（在SOA里叫服务

模型，在 EOS里叫展现逻辑），它在执行客户端的服务时的机制时还是比较复杂的，如果感

兴趣在工作之余可以看一下。

还有个最近比较流行的开源的引擎，JBpm ，我没看过这个，好象现在又整合到JBOSS 下去了，好象很复杂。

2.2. 时限管理服务

2.2.1. 时限的分类

时限名称时限代码

活动提醒时限ACT_PRE_REMIND

活动执行时限ACT_OVERTIME_REMIND

流程提醒时限PROCESS_PRE_REMIND

流程执行时限PROC_OVERTIME_REMIND 时限类型有两种：一种是一次触发完成时限，还有一种是循环触发（譬如隔多长时间进

行一次提醒）并可设置触发的次数。

2.2.2.时限计算器

在工作流引擎启动时就启动一个JVM 唯一实例的时限计算器，该类可以使用引擎默认

的。也可以自己去实现一个自定义的计算方法，在配置文件中注册要重写的类名即可。引擎的时限计算器只有两个方法，一个是计算结束时间，还有一个是计算提醒时间。其实是个静态类。

2.2.

3.时限服务的启动

在引擎中的时限服务有两个，一个是引擎启动的时候启动的时限服务，该服务初始化了时限对象列表；一个是在引擎启动后启动的服务，该服务是对列表中的时限对象进行轮询，

触发超时的时限对象对应的触发事件，并移除该对象时限。时限的线程处理用了大量的过程

化程序的结构，在这里还是比较绕人的。

2.2.4.时限的注册和移除

在流程引擎中的时限服务其实就是在维护一个时限对象的列表，该列表记载了处于运行状态的活动的时限对象。

在启动一个环节或启动一个流程时判断该活动或该流程的时限，如果该活动或该流程定义了时限则向时限服务注册该时限;在 TimerManager类中的注册方法的实现是调用时限服

务类的 registeTimer方法，往时限对象列表（Vector ）追加一条记录。

在结束活动事件时或结束流程时如果是超时的操作则时限对象列表中没有该活动的时

限对象，因为该对象已被时限触发器触发并移除。如果没有超时则要把这个向量列表中的那

条时限对象给去掉。在TimerManager类中的注册移除方法的实现是调用时限服务类的unregisteTimer方法，往时限对象列表（Vector ）移除一条记录。

2.2.5.时限事件的触发

时限的触发完全是后台的线程做的事情。该线程对时限服务所维护的时限对象列表进行轮询，如果发现有超时的对象则触发已定义好的动作，该动作就是我们平时在studio中设

的如果超时则干什么事的触发动作。

对时限的处理是通过java.util.Timer这个类来实现的。是通过新建一个时限任务（MyTimerT ask ）让 Timer来执行。并向该类传递一个OnceTimerHandler对象实例。该

对象有个方法timerTrigged就是到了预定时限时触发的方法。该方法首先调用

timerHandler类的 handlerTimer方法，即如果有触发事件的话就调用上节讨论的事件代

码以 4 开头的事件。然后修改时限类的当前状态为 3 ，完成一次时限触发动作。

3.流程同步服务

流程同步服务是引擎自定义的一个对流程实例和流程定义的锁的定义，譬如在做指定下一个环节的参与人（WFAppointParticipantManager中的appointNextActParticipant

方法）时先把当前的流程实例给琐住

（ServiceFactory.getLockService().lockProcInstance）。然后在方法结束后再把流程实例

的锁给释放（ServiceFactory.getLockService().releaseProcInstance）。在同步服务中定

义了两种类型的锁，一种是流程定义锁，一种是流程实例琐（两个list ），在加琐时检查改

ID（流程实例ID 或流程定义ID ）是否已经在琐列表中，如果在则加琐。在加琐与解锁之间

是通过一个线程来操作锁列表（waitingList）实现的。其实现方法大概是在加锁的时候向

waitingList添加一个锁对象，然后把线程wait(); 在解锁的时候向waitingList减去一个锁

对象，并把线程notify()。流程同步服务的实现方式还是比较复杂的。尽管只用了七八个类。

4.组织机构管理

EOS 提供了一套自己的组织机构模型，我们在安徽服务保障三期中引用了该模型。该

组织机构模型的服务会话面的实现是在配置文件中配置的，然后引擎采用java 的反射机制

加载配置类（在引擎中有个叫做“服务定位器” 来实现，该服务定位器和我们平时用的一样，

只是它是从文件中读取服务定义，隐藏了具体寻址细节）。如果不用EOS 提供的组织机构模

型可以实现WFOMService接口，并实现里面的方法。估计EOS 的原意是提供组织机构模

型和引擎服务的松偶合，但在其引擎的实现上好象并没有做到。

OMServiceImpl类是引擎默认加载的组织机构模型会话面类。该类定义了人员，角色，机构等等， OMServiceImpl2类包含岗位的组织机构模型（目前的引擎的还不支持，没有

搞清楚 EOS 没有把岗位纳入组织机构模型中），但EOS提供的开源的组织机构模型中并不

支持。

5.审计服务

该服务记载了所有流程模板的变更和对流程实例的操作历史。引擎共定义了39 种审计类型，包括模板变更，启动流程，完成工作项等等。由于审计的类型代码和引擎的事件代码，

所以引擎在中间做了一层映射，把事件代码和审计代码一一对应（审计代码多于事件代码）。

在审计过程中其实是往审计表中加一条历史记录。

6.日志服务

引擎的 LOG 服务很简单，和我们平时用的LOG 差不多。在打日志的时候传入JVM 唯一实例的日志上下文WFLogContext，在该类中定义了一条日志所需要的日志头，比如等

级（ @level ），操作员（ @operator），sql（@sql），时间戳（@timestamp）等等。然后

在具体打某一条日志的时候把日志头和日志内容拼装起来形成一条日志。

引擎的日志实现了日志的读写，引用了log4j的

RollingFileAppender和PatternLayout 。并提供了类似AOP 的方法前后拦截打日志的服务（不知道方法前后的拦

截日志是在代码中人工加上的还是由AOP 代理自动加载的，因为采用了AOP 时在编译的

时候就把代码插入到要拦截的切入点中去）。

7.持久层服务

引擎的持久层和studio里的持久层是采用一样的设计。大概是把数据库的字段和持久

层的 XML 定义一一对应，没有采用像hibernate或者EJB的CMP或者BMP那样很复杂的 OR_mapping。由JDBC驱动持久层在系统中显的很高效，但采用数据库和持久层的XML 描述文件一一对应所以没有把关系数据的对象化做的很别致。（没有深入的看过代码，可能

我理解的不对）。

8.引擎的缓存

工作流引擎的缓存是通过一个HashMap 来维护的。用有以下几类缓存：流程实例的

缓存；活动实例的缓存；工作项的缓存；相关数据的缓存；相关数据Dom 的缓存；流程属性数据的缓存，以上几类的实例缓存个数是通过在配置文件中配置的，还有一类流程模板的

缓存是在引擎启动的时候就解析流程模板的XML 文的定义（因为流程定义是通过XML 文来存储在数据库中），解析成流程定义对象并加载到内存中。

8.1.缓存的配置

工作流缓存的配置是在wfconfig.xml文件中配置的。共有以下几种配置：

false

1000

5000

10000

key="workItemViewCacheCount">10000

1000

1000

key="procInstAttrDomCacheCount">1000

8.2.缓存的实现

在引擎启动的时候取得工作流配置信息，如果允许使用缓存则初始化上面所述的六类缓存。在初始化的时候引擎默认缓存的存活时间为0x1499700L。缓存的大小为配置文件所配。这样则生成在JVM 里的六个Cache 类的实例。每个Cache 都有一个 HashMap的属性，

这里面存储了要缓存的对象。在 CacheFactory类中又有一个HashMap对象属性，这个对象存储的是Cache 对象的集合。就是上面所述的六个Cache 类实例的集合。普元的开发人

员把该对象起名为Caches 。那么在取某个活动实例时就先中缓存中读取，如果找到则直接

返回，如果没有则从数据库中加载。

引擎的缓存并不是直接把从数据库中取得的对象put 到 map 中，而是做了一层优化，把从数据库中找到的对象封装成CacheObject对象，该对象有个链表（LinkedList）的属性对象。该对象有前驱和后继节点，其节点就是我们要put的对象。其具体的优化策略和

大多数缓存一样，采用最近最多访问策略，共有两个列表维护，一个是最近访问对象位于首

位，一个是最多访问对象位于首位。

9.EOS 引擎的精彩之处

EOS 引擎设计上最精彩的地方应该是基于多线程的事件调度机制，在事件处理是下层

有个线程池处理事件，其中有个线程拿到了一个事件后就开始他的事件的发布和事件的迁

移。（多线程协同工作的程序设计我觉得应该是程序设计中最复杂的地方，不但要屏弃所谓

“万物皆是对象”的看法，可能还需要用到大量的goto 语句来解决一个面向对象这种思想

不好解决的问题，还有在JAVA 中线程的调度可能还依赖于程序所跑的操作系统和硬件环

境，有很多的不可预料性的存在。我怀疑这个线程池肯定有问题，或者单线程已经足够解决所有问题，不然 EOS 引擎为什么不把多线程处理事件作为默认的处理方式而是单线程作为

默认的呢？）

多线程调度的初始化：引擎根据配置文件（ wfconfig.xml ）里的线程数

（event_thread_num ）新建了那么多数量的线程。并把这些线程放到已经定义好

的线程组里。这些线程对象有个对象属性：EventList ，这里装载的是该线程该处

理的所有事件对象。然后把这些线程都start() ；该线程轮询 EventList 里的事件对

象列表，如果对象列表为空则把自己阻塞（wait() ），如果有事件对象则取第一个

事件然后发布该事件，对该事件的处理还是和单线程是一样的。

线程池对客户端动作的响应：客户要向引擎发布一个事件首先找到线程组的

activeCount ，然后根据取得的数量在新建这么多的线程然后enumerate （复制

到线程组中）它们。引擎把这些线程对象转换成事件处理线程（EventThread ），

然后遍历这些线程，然后根据“找到这些线程对象中的EventList 里的事件最少的

一个线程“这种策略，把要发布的事件对象加到找到的这个线程对象的EventList

里，同时唤醒这个线程，完成了一次事件的发布，完成了线程自己和自己的协同工

作。

10.EOS 引擎的不足

10.1.组织机构模型

EOS 提供的组织机构模型无法解决按岗位或按行政级别分派工作项。但这是很常见的

一种情景（安徽二期的工作流平台好象实现了按行政级别来提交工作项）。网上有一种比较流行的组织机构的模型。

如果能把这种组织机构模型经演化应用到引擎中去可能会解决按岗位，按行政级别，按职务来设参与人的问题，甚至可以解决一个机构只有一个流程的问题而不是机构的下属机构

拥有一套和其他下属机构一样的流程（只是参与人不同而已）。而我们的应用中只需要一套

共性的流程和下属机构个性化流程的实施。由于客户在管理可能会有不足或把依靠系统来管

中间的平衡点。

10.2.不能应用在分布式系统中

由于在引擎启动的时候引擎把流程定义XML 文解析成流程定义对象，然后加载到内存中，而发布流程的动作只能来自一台集群节点，固无法把修改后的流程定义同步到其他的集

群节点。现在的同步方法是发布流程的时候同时调用其他节点的一个远程方法来实现同步。

虽然通过外挂式的解决方案解决了这个问题但没有从根本弥补引擎的缺陷。

EOS 的业务字典的管理也是存在同样的缓存问题，在一个节点建了一个业务字典没办

法同步到其他节点中去。

环节的时限也是用了缓存，一个环节的时限注册是在环节启动时如果定义了时限则向时

限服务注册，并在内存中产生一个时限对象，有个后台线程在维护它，当环节结束时取消该

环节的注册，移除该环节在内存中的时限对象并删除数据库中的时限表的那条数据。有一种极端的场景（不可能发生）：所有的用户在结束自己的环节后启动了下一个环节（假设该

环节的完成时限为一个月）。这个动作是在节点 A 进行的，则节点 A 的内存中有了所有下个环节的时限对象。节点 A 的后台线程在维护该对象，不停的判断是否超时。假设下个环节

的所有用户在没有超时的情况下完成自己的工作项，并且操作的发生在节点B，用户操作自己的环节后结束环节并取消时限注册并删除时限表，但节点 A 的时限对象并没有移除。节

点 A 的后台线程一直在维护着它直到它超时才从内存中删除，造成了内存里的垃圾数据。

我认为引擎层还是应该有一个类似缓存同步服务（可能我说的不对），譬如在流程未发布和发布成功的状态位的迁移过程中加一个待发布的状态，当发布流程的时候把该流程定义

的发布状态定义为待发布，然后有两个线程协同工作，一个线程定时（譬如20S ）来轮询待发布的流程定义并加载到一个待发布流程列表（该列表类似操作系统中的信号量）中，如果

该列表非空则唤醒另一个流程发布线程，该线程 sleep 一定的时间（该时间要大于等于轮询

的时间保证所有节点都已经把待发布的流程定义都加载到内存中）后发布该流程并把流程置

为发布状态，然后将自己阻塞。

10.3.子流程的设计

EOS 的子流程是作为一个主流程的环节来实现的，我觉得不应该有子流程和父流程的概念，也不应该把一个流程作为一个环节来实现。流程与流程之间的通信可以已一定的接口

定义和通信规则来实现，父子关系只是其中的一种（属于工作流协同工作的网状模型），还有链状模型，端到端的模型，并行同步模型。这样如果有了接口的标准既解决了父子关系的

流程通信，同时也解决了EOS 工作流不同实例的交叉操作，甚至解决了不同工作流产品之

间的流程通信（只要遵循了接口定义标准，该接口为WFMC定义的接口 4 ，该接口定义了一系列的互操作层次（好象是8 个），但可能并不能满足像EOS 的引擎具有中国特色（譬如自由流，抄送）工作流需求）。

11.一种理论上的引擎原理

Petri Net是离散并行系统的数学表示，它的数学表述我搞不明白，只能明白他的表面上的一些东西。它不是为工作流而产生的，但如果能把Petri Net和XPDL结合起来去构造

一个引擎不一定是符合实际需求的，但我相信它一定是很有前景的。也是很具有竞争力的。

在 Petri Net中主要有四个元素：

1.Place ：

Place 是一种状态，譬如马路上的红绿灯，他的Place 可以是红灯，绿灯。

2.Transition

Transition是从一个状态转变到另一个状态的过程。

3.Arc

Arc 是连接 Place 和 Transition的一个有向弧，可以从Transition指向Place，也可以从 Place 指向 Transition ，但不能从 Place 指向 Place 或从 Transition 指向 Transition ，

中间一定要有个状态变迁的过程。

4.Token

Token 是一个物件，他可以代表任何东西，当Place 或 Transition拥有足够的Token 时才可以从一种状态边成另一中状态。

Petri Net的运作方式

图元定义：

上图的 enter经过fire会变成下面的状态：

使 enter 可以 fire 必须消耗 free 和 wait 的各一个 token ， enter 就可以个 before 和occupied 各一个 token 。依次类推的方式推动流程的运转。

至此我们可以给PN 网这样的过程调度算法这样的定义：如果一个变迁的每个输入

库所（ input place ）都拥有令牌，该变迁即为被允许(enable) 。一个变迁被允许时，变迁将发生(fire) ，输入库所(input place) 的令牌被消耗，同时为输出库所(output place) 产生令牌。

使用这种算法的工作流引擎有开源的YAWL ，还有 BOSSA ，大家在茶余饭后可以研究一下。

Activiti工作流入门详解完整教学教程

Activiti入门教程详解完整教程 1.A ctiviti介绍 Activiti是由Alfresco软件在2010年5月17日发布的业务流程管理(BPM)框架,它是覆盖了业务流程管理，工作流，服务协作等领域的一个开源，灵活的，易扩展的可执行流程语言框架。 Activiti基于Apache许可的开源BPM平台，创始人Tom Baeyens是JBoss JBPM的项目架构师，它的特色是提供了eclipse插件，开发人员可以通过插件直接绘画出业务流程图。 1.1工作流引擎 ProcessEngine对象，这是Activiti工作的核心。负责生成流程运行时的各种实例及数据，监控和管理流程的运行。 1.2BPMN 业务流程建模与标注（Business Process Model and Notation,BPMN），描述流程的基本符号，包括这些图元如何组合成一个业务流程图(Business Process Diagram)

2.准备环境 2.1Activiti软件环境 1)JDK1.6或者更高版本 2)支持的数据库有:h2,mysql,oracle,mysql,db2等 3)支持Activiti运行的jar包，可以通过maven依赖引入 4)开发环境为Eclipse3.7或者以上版本，myeclipse为8.6版本2.2安装流程设计器(eclipse插件) 1）打开Help →Install New Software →Add 输入Name: Activiti Designer Location: https://www.sodocs.net/doc/b03801715.html,/designer/update/ 输入完成后，单击OK按钮等待下载完成后安装。 安装完成后在菜单选项中会出现Activiti的目录选项

工作流引擎技术白皮书

工作流引擎 产品功能介绍V0.07

目录 1.1工作流引擎简介 (4) 1.1.1产生背景 (4) 1.1.2发展阶段 (5) 1.1.2.1EDF(电子数据流)阶段 (5) 1.1.2.2TPF(事务处理流)阶段 (5) 1.1.2.3IMF(整体集成管理流)阶段 (5) 1.1.2.4CPF(知识共享和持续改进)阶段 (6) 1.1.3主要特点 (6) 1.1.4流程定义和运行 (7) 1.1.5流程运转模式 (7) 1.1.6工作流引擎不等于OA系统 (9) 1.2XX工作流引擎 (10) 1.2.1XX工作流引擎简介 (10) 1.2.2产品设计 (11) 1.2.2.1工作流是XX电子政务平台的组件之一 (11) 1.2.2.2工作流引擎设计思想 (12) 1.2.2.3工作流引擎产品架构 (14) 1.2.3产品功能 (15) 1.2.3.1支持流程运转模式 (15) 1.2.3.2设计工具 (19) 1.2.3.3控制平台 (21) 1.2.3.4任务列表 (22) 1.2.3.5流程与用户 (24) 1.2.3.6工作流数据 (25) 1.2.3.7事务处理 (26) 1.2.3.8异常处理 (26) 1.2.4产品安全能力 (26) 1.2.5产品集成扩展 (26)

1.2.6运行环境 (27) 1.3XX工作流引擎适应复杂应用的要求 (27) 1.3.1多机构联合作业 (28) 1.3.2流程的定义集中管理 (29) 1.3.3嵌套子流程和和引用子流程 (29) 1.4XX工作流应用实施方法 (29) 1.4.1点面结合，全面推进 (29) 1.4.2分步实施，适当激励 (30) 1.4.3持续改进，形成文化 (30) 1.5XX工作流引擎成功案例 (30) 1.5.1广州移动广州公务机管理系统 (31) 1.5.1.1实现功能 (31) 1.5.1.2实施效果 (32) 1.5.2广州外经贸网上政务-发文管理 (33) 1.5.2.1实现功能 (33) 1.5.2.2实施效果 (35)

Activiti6.0工作流使用说明文档V1.0

Activiti工作流使用说明文档 V1.0 2019年8月9日

目录 一、模型设计器 (4) 1.1任务 (5) 1.1.1 用户任务 (5) 1.1.2 服务任务 (5) 1.1.3 脚本任务 (6) 1.1.4 业务规则任务 (7) 1.1.5 接收任务 (7) 1.1.6 手动任务 (7) 1.1.7 邮件任务 (8) 1.1.8 Camel任务 (8) 1.1.9 Mule任务 (8) 1.1.10 决策任务 (9) 1.2构造 (10) 1.2.1 子流程 (10) 1.2.2 事件子流程 (11) 1.3泳道列表 (11) 1.4分支 (12) 1.4.1 排他分支 (12) 1.4.2 并行分支 (12) 1.4.3 包容分支 (13) 1.4.4 事件分支 (13) 1.5事件 (14) 1.5.1 定时器事件 (14) 1.5.2 信号事件 (14) 1.5.3 消息事件 (16) 1.5.4 错误事件 (16) 1.5.5 边界事件 (17) 1.5.6 中间事件 (18)

1.5.7 开始事件 (18) 1.5.8 结束事件 (18) 1.6属性元素 (18) 1.6.1 异步 (18) 1.6.2 排他 (19) 1.6.3 补偿 (19) 1.6.4 中断任务 (20) 1.6.5 分配 (21) 1.6.6 到期时间 (22) 1.6.7 表单 (22) 1.6.8 表达式 (24) 1.6.9 多实例 (25) 1.7监听器配置 (28) 1.7.1 执行监听器 (29) 1.7.2 任务监听器 (30) 1.7.3 事件监听器 (32) 1.7.4 全局事件监听器 (33) 二、workflow-service (34) 2.1数据更新逻辑 (34) 2.2方法表达式配置 (35) 2.3自定义外置表单 (36) 2.4事件监听器配置 (37) 2.5方法调用说明 (37) 三、常见问题 (37)

集中告警系统设计方案..

2.10通信集中告警系统设计

目录

2.7.1.概述 集中告警系统就是利用计算机数据处理和计算机网络传输技术，对西安地铁一号线各通信子系统设备信息进行采集并集中反映到告警终端，使通信维护人员能及时、准确了解整个通信系统设备的故障信息以便于处理。系统能够对通信各专业系统的告警进行汇总、显示、确认及报告，能进行故障定位，使维护管理人员能够准确、迅速地获得设备的运行状态信息，及时进行维护。 集中告警系统监测的各通信专业系统包括传输系统、无线通信系统、公务电话系统、专用电话系统、视频监视系统、有线广播系统、时钟分配系统、通信电源设备、乘客信息系统等。 2.7.2.系统功能及原理说明 通信集中告警系统主要实现了对通信各系统设备告警的集中监管，为维护人员提供方便、快捷的集中监控管理平台。主要包括故障管理、报表管理、拓扑管理、资源管理、自身监控、工单管理、流程管理、系统管理、参数管理和外部接口等模块。 2.7.2.1.故障管理 集中告警系统通过数据采集模块从各通信系统中采集各种设备告警、性能越限告警和网络告警等信息，通过各种分析处理后，以合适的方式呈现给运维人员，实现对各通信系统告警信息的管理。主要包括告警采集、告警处理、告警呈现、告警操作和查询四大功能，通过故障管理功能，通信系统运维人员可以速度知道各系统故障发生的位置、可能原因等信息。 2.7.2.1.1.告警采集 告警采集主要是指集中告警系统从各通信系统网管中采集告警和告警恢复数据的功能。集中告警系统是通过以太网从各通信系统的网管接口自动采集各网元的设备告警、性能越限告警和网络告警和各种告警恢复等信息后，把原始告警/告警恢复存储到数据库中，并通过过虑和转换，统一成集中告警系统的告警格式，及时通知应用服务层进行告警的分析和处理。 告警采集方式根据厂家网管接口可以分为两种： (1)主动上报：各专业系统网管主动向集中告警系统上报各种告警信息。 (2)被动采集：集中告警系统主动从各厂家网管中获得告警信息。

Activiti工作流数据库表结构

Activiti数据表结构 目录 1ACTIVITI数据库表结构 ----------------------------------------------------------------------------------------------- 2 1.1数据库表名说明 ------------------------------------------------------------------------------------------------ 2 1.2数据库表结构---------------------------------------------------------------------------------------------------- 3 1.2.1Activiti数据表清单: ---------------------------------------------------------------------------------------- 3 1.2.2表名:ACT_GE_BYTEARRAY （通用的流程定义和流程资源）-------------------------------- 3 1.2.3表名:ACT_GE_PROPERTY （系统相关属性） ----------------------------------------------------- 4 1.2.4表名:ACT_HI_ACTINST （历史节点表） ------------------------------------------------------------ 5 1.2.5表名:ACT_HI_ATTACHMENT （附件信息）-------------------------------------------------------- 6 1.2.6表名:ACT_HI_COMMENT （历史审批意见表）-------------------------------------------------- 6 1.2.7表名:ACT_HI_DETAIL （历史详细信息）----------------------------------------------------------- 7 1.2.8表名:ACT_HI_IDENTITYLINK （历史流程人员表） ---------------------------------------------- 8 1.2.9表名:ACT_HI_PROCINST（历史流程实例信息）核心表---------------------------------------- 8 1.2.10表名:ACT_HI_TASKINST（历史任务流程实例信息）核心表------------------------------ 9 1.2.11表名:ACT_HI_VARINST（历史变量信息） ------------------------------------------------------ 9 1.2.12表名:ACT_ID_GROUP（用户组表） ------------------------------------------------------------ 10 1.2.13表名:ACT_ID_INFO （用户扩展信息表） ---------------------------------------------------- 10 1.2.14表名:ACT_ID_MEMBERSHIP（用户用户组关联表） -------------------------------------- 11 1.2.15表名:ACT_ID_USER（用户信息表） ------------------------------------------------------------ 11 1.2.16表名:ACT_RE_DEPLOYMENT（部署信息表）------------------------------------------------ 12 1.2.17表名:ACT_RE_MODEL (流程设计模型部署表) ----------------------------------------------- 12 1.2.18表名:ACT_RE_PROCDEF （流程定义表） ---------------------------------------------------- 13 1.2.19表名:ACT_RU_EVENT_SUBSCR (运行时事件) ------------------------------------------------- 14 1.2.20表名:ACT_RU_EXECUTION （运行时流程执行实例） ----------------------------------- 15 1.2.21表名:ACT_RU_IDENTITYLINK（身份联系） --------------------------------------------------- 15 1.2.22表名:ACT_RU_JOB（运行中的任务）---------------------------------------------------------- 16 1.2.23表名:ACT_RU_TASK(运行时任务数据表) ------------------------------------------------------ 16 1.2.24表名:ACT_RU_VARIABLE(运行时流程变量数据表) ----------------------------------------- 17 2ACTIVITI中主要对象的关系 -------------------------------------------------------------------------------------- 18

工作流引擎讲解

什么是工作流引擎，工作流引擎有什么作用，为什么需要工作流管理系统，在这里我们主要研究它的好处，你想要理解它的好处，就得知道不使用它会带来什么样的坏处。 现在我们来讲工作流，什么是工作流？所谓的工作流就是通常所说的业务流程，那么所谓的业务流程换句话来讲就是多个人在一起去完成一件事情。这就可以称之为工作流。流程的本质就是一个参与者参与到一个过程里面来 那么现在我们就想为什么需要工作流管理系统，工作流管理系统能给我们带来什么好处。我们就从这个角度出发来了解JBPM 工作流引擎 下面我们就来看关于为什么需要工作流管理系统，以及它给我们带来的好处。 实际上它带来的好处就是使某些容易变化的东西抽象出去，我们能够通过某种方式改变它，然后你就可以对你的某些核心部分不需要做什么变动 现在就通过一个小例子来讲这个工作流引擎到底是一个什么东西 举个请假流程的例子 一个请假的过程 重点讲解UML 里面的内容，确定UML 里面流程图的讲解顺序 请假流程 现在只看左边的内容，右边的后面再讲，我是方便讲解就将这点东西放到这个空白的地方 一个简单的流程图Main 模拟出请假的过程

对提交请假单进行分析 用一个用户来表示普通用户和审批者，只不过他们的权限不同，他们都能够登录到这个系统 现在我们来看用户和请假单，分析他们之间的关系，用户和请假单之间的联系有请假，用户填了一个请假单就创建了一个请假单对象，他们之该是一对多的关系。因为某一个用户可以请多次假 对吧（其实一般是一个请假单对应一个请假者，这个需求就应该得到客户的确定，客户说了算）那么用户和这个请假单之间还有没有其他联系？ 接下来是提交请假单。我首先将请假单提交给张三，那么张三就能够看到这个请假单，如果用户将请假单提交给张三，那么就可以在张三和请假单之间建立一个待审关系 他们之间的关系也是一对多的关系，因为张三可以同时审核几个请假单，就是这意思，一个请假单等待的用户是一个，从现在的需求来看。那么两者之间还有另外一个联系那就是已审，一个用户可以审批过多个请假单，请假单也可以被多个用户审批 比如张三审批以后交给李四审批，李四审批以后交给王五审批，其实这个已审就是记录审批信息的，比如审批时间，审批意见，把它放在审批关联里边 这个就是一个基本的概念，了解这个概念之后我们就考虑它的设计，JBPM 实际上就是协助我们把这个请假单从一个用户手上转递到另一个用户手上。当把这个模型分析清楚了我们就要去实现它。 这里重点分析提交，怎样去提交，在SSH 架构体下，提交请假单这个业务逻辑，你可能就需要这样一个业务逻辑类，里边可能有这么一个方法专门来进行提交操作的，那么这个方法怎样设计，以及这个方法怎样去实现。了解这点你就可以了解JBPM 干什么的，能给我们带来什么好处 (用自己的话说明一下提交请假单的过程 <读一下那段伪代码>) 在这个过程里边写这些代码是比较麻烦的，现在还只是一个固定的流程，假设我现在在这里边变化一下 那么整个方案都要变动。 我现在希望有一个会签的功能 比如我现在要将这个这样的功能，把这个请假单同时提交给多个审批者审批。 那这个时候你就不能够在请假单中间增加一个外键， 把它整成审批者什么的，

OracleERP开发计划流程简介

大唐兴竹软件公司

工作流使用讲明

修改纪录 签名 职务姓名签字日期

内容索引 1简介 (1) 1.1 目的 (1) 1.2 范围 (1) 1.3 如何得到这篇文档 (1) 2工作流实现机制 (1) 2.1 工作流的组成部分 (1) 2.1.1单据类型（Item Type） (2) 2.1.2活动（Activity） (2) 2.1.3流程（Process） (3) 2.1.4消息（Message） (4) 2.1.5函数（Function） (5) 2.1.6通知（Notification） (5) 2.1.7查找类型（Lookup Type） (6) 3工作流的定义 (6)

3.1 创建流程定义 (7) 3.1.1从下往上定义 (7) 3.1.2从上往下定义 (9) 3.1.3打开保存单据类型 (9) 3.2 定义工作流组件 (12) 3.2.1单据类型（Item Type） (12) 3.2.2查找类型（Lookup Type） (23) 3.2.3消息（Message） (26) 3.2.4活动（Activities） (34) 3.3 定义一个流程图 (43) 3.3.1增加一个节点 (44) 3.3.2定义一个节点 (45) 3.3.3定义活动属性值 (47) 4在应用中调用工作流 (48)

1简介 1.1目的 ?讲明Oracle ERP里工作流的原理 ?在Oracle ERP里定义并定制工作流 1.2范围 Oracle ERP里工作流引擎的实现原理以及如何利用Workflow Builder定义一个流程，以及在程序里调用差不多定义好的流程保证业务依照流转规则流转。 1.3如何得到这篇文档 该文档要紧供兴竹公司开发部内部交流使用。 2工作流实现机制 2.1工作流的组成部分 工作流的流程要紧由以下组件（Component）构成：单据类型、流程、活动、函数、消息、通知和查找类型。单据类型是一种分类对象，其它的对象都属于一个单据类型。

工作流Activiti的学习总结(十二) activiti官方十分钟快速学习

根据activiti官方提供的编写 1.财务部门填写月财务报告 2.股东审核月财务审计报告 流程图： 流程配置： <;?xml version=";1.0"; encoding=";UTF-8";?>; <;definitions xmlns=";https://www.sodocs.net/doc/b03801715.html,/spec/BPMN/20100524/MODEL"; xmlns:xsi=";https://www.sodocs.net/doc/b03801715.html,/2001/XMLSchema-instance"; xmlns:activiti=";https://www.sodocs.net/doc/b03801715.html,/bpmn"; xmlns:bpmndi=";https://www.sodocs.net/doc/b03801715.html,/spec/BPMN/20100524/DI"; xmlns:omgdc=";https://www.sodocs.net/doc/b03801715.html,/spec/DD/20100524/DC"; xmlns:omgdi=";https://www.sodocs.net/doc/b03801715.html,/spec/DD/20100524/DI"; typeLanguage=";https://www.sodocs.net/doc/b03801715.html,/2001/XMLSchema"; expressionLanguage=";https://www.sodocs.net/doc/b03801715.html,/1999/XPath"; targetNamespace=";https://www.sodocs.net/doc/b03801715.html,/bpmn20";>; <;process id=";financialReport"; name=";Monthly financial report reminder process";>; <;startEvent id=";startevent1"; name=";月财务报告审核开始";>;<;/startEvent>; <;!-- 采用用户组为accountancy编写财务报告 -->; <;userTask id=";usertask1"; name=";财务编写月财务报告"; activiti:candidateGroups=";accountancy";>;<;/userTask>; <;userTask id=";usertask2"; name=";股东审核月财务审计报告"; activiti:candidateGroups=";management";>;<;/userTask>; <;endEvent id=";endevent1"; name=";月财务报告审核结束";>;<;/endEvent>; <;sequenceFlow id=";flow1"; name=";"; sourceRef=";startevent1"; targetRef=";usertask1";>;<;/sequenceFlow>; <;sequenceFlow id=";flow2"; name=";"; sourceRef=";usertask1"; targetRef=";usertask2";>;<;/sequenceFlow>; <;sequenceFlow id=";flow3"; name=";"; sourceRef=";usertask2"; targetRef=";endevent1";>;<;/sequenceFlow>; <;/process>; <;bpmndi:BPMNDiagram id=";BPMNDiagram_financialReport";>; <;bpmndi:BPMNPlane bpmnElement=";financialReport"; id=";BPMNPlane_financialReport";>; <;bpmndi:BPMNShape bpmnElement=";startevent1"; id=";BPMNShape_startevent1";>; <;omgdc:Bounds height=";35"; width=";35"; x=";30"; y=";200";>;<;/omgdc:Bounds>; <;/bpmndi:BPMNShape>; <;bpmndi:BPMNShape bpmnElement=";usertask1"; id=";BPMNShape_usertask1";>;

工作流引擎技术白皮书

工作流引擎产品功能介绍

目录

1.1工作流引擎简介 1.1.1产生背景 随着我国信息化建设的不断深入，越来越多的政府部门和企事业单位都清醒地认识到信息化对于自身的生存与发展的重要性，以IT 系统建设为基础提高工作效率，增强竞争能力，已经成为共识。 在过去的若干年中，许多企业以当时的IT 发展水平为基础，针对不同的业务需求搭建了种类繁多的应用系统。回顾这一阶段，我们可以发现长期以来IT 系统的建设一直跟随着技术的革新和业务需求的增长而被动地发展着。不论技术手段如何变化，企业仍旧习惯于沿着功能分析的思路为特定的需求开发专有应用。随着时间的推移，企业内部逐渐积累了许多相互孤立的筒仓式应用系统。不可否认，正是这些应用系统共同构成了当今企业的主要IT 运行环境并有效地支撑了企业早期的业务发展，但是我们也必须清醒地认识到，在这些缺乏前期规划、互连性极差的应用系统之间信息不能被有效地共享且难于保持一致，业务过程也无法顺畅地流转，它们是造成“信息孤岛”现象的根源。一些企业也曾经尝试采用整理、合并各种需求、统一数据接口、规范业务过程等方式来降低集成的复杂度，但是在经过一番实践后，人们又发现仅仅依靠规范静态信息的交换格式，集合局部的需求等方法并不足以支持更大范围内的应用整合。因此当前的企业迫切需要一个能够支持在不同的应用系统之间完成协作任务的具有前瞻性的应用集成框架。 当前，企业面对的是一个多变且难以预测的市场，要在这样的环境中生存和

发展，就必需具备对外部变化做出迅速响应的能力。同样，政府部门也面临着转变工作职能，适应市场经济发展要求的压力，需要不断地为大众提供各种高效的公共服务。各项独立调查表明: 对业务系统和IT 基础设施进行快速调整和扩展一直是政府部门和企事业单位应对外部环境变化的重要手段。然而在早期的IT 系统设计过程中，人们往往更加关注于系统的稳定性而不是迅速应对变化的能力，原先那种僵硬的基于硬编码实现的系统功能扩展和集成方式已远远不能满足要求。“采用什么样的技术来搭建能够实现跨部门、跨企业、跨地理范围的支持流程协作和流程自动化的IT 基础设施”，“如何能够从被动地应对变化到预见变化进而实现前瞻性地主动变化”…这些都是当前每一个政府部门和企事业单位必须面对的挑战。 通过工作流系统把各业务部门的孤立应用系统整合起来是IT技术发展的必然趋势，而我国从上实际八十年代大量建设基础信息系统至今，工作流技术的发展可以分成以下几个阶段。 1.1.2发展阶段 1.1. 2.1EDF(电子数据流)阶段 此阶段的工作流在信息技术中的应用,仅着眼于利用信息技术减轻人们在流程中的计算强度最主要的特点是仅对企业单项业务进行处理,基本不涉及管理的内容。国内最早成功的产品是财务管理产品，为了配合产生正确的数据，可能要设计一个流程用来协调多个会计统计帐目。 此阶段仅仅停留在诸如文档处理、公文流转以及信息发布等这些简单的业务

普元EOS工作流引擎设计原理

EOS工作流引擎工作原理 作者：Gocom注册用户dogreet（李国生） 1. 工作流基础知识 ……略 2. EOS工作流引擎工作原理 本文是我在工作之余写的一点我对EOS工作流的了解，我的理解不一定全是对的，可能会与引擎的真正的面目有出入。所以只能提供给大家一点参考。 2.1. EOS工作流引擎核心调度算法 EOS工作流最重要的组成部分是它的核心调度算法，在我们没有深入研究它的工作原理之前我们认为它的工作原理是在工作项，活动和流程实例对象上加了一些标志位来驱动流程的运转。认为其引擎完全是个由数据库来驱动流程的引擎（安徽二期的工作流平台好象就是以库表来驱动流程的运转），其实它是由事件来驱动流程运转的引擎，数据库只是把引擎运转前后的状态持久化。在我近来在工作之余对其引擎的工作原理进行跟踪才弄明白在EOS帮助文档上介绍的“事件驱动”的工作流引擎。 2.1.1. EOS工作流引擎的事件类型

以上的每个事件都是原子的不可分割的。其中一系列事件的集合通过EOS引擎事件调度机制实现我们平时在工作中经常遇到的如启动流程，结束工作项等等。（在事件类型类中EOS定义了29种事件，但在事件工厂类中EOS定义了26种类型。） 1.1.1. EOS工作流事件调度机制 EOS事件的调度服务是在工作流引擎初始化时通过服务工厂类加载到内存中（ServiceFactory.initEventService()）。用户可以通过服务工厂类（ServiceFactory）取得JVM的唯一事件服务实例进行事务调度。所有的事件程序入口都是事件类（EventService），这个类其实是个接口，其有两个实现类，一个是单线程的实现类SingleThreadEventService （在实现代码中其实不是单线程，而是单例的对象），一个是多线程的实现类MulThreadThreadSvc，（其实现方式不在这里详细说明，多线程的类后面又跟了一大堆的线程池实现代码），在事件服务类中有一个属性类是WFEventDisposer，这个类包含了事

工作流表单引擎系统

表单系统设计 一、目的 表单定义：表单是用来呈现与存储数据的图形化界面，数据展现、数据存储、用户交互的工具。我们用火车来比喻，数据就是货物、表单就是车厢、火车头就是工作流程引擎。 自定义表单设计器，采用数据库格式化存储表单模板。 二、实现原理 自定义表单功能概括起来如下 1、表单预览,动态报表展示(列表数据展示) 2、表单数据填报, 3、支持多数据表同时填报,一对多数据表填报,单表多条数据批量填报等 4、自定义表单支持用户自定义模板 5、大量丰富的标准表单控件 三、目标 1、新建表单(需要关联流程id，表单关联实例，历史版本)。 2、表单预览。

3、主表单和子表单相关属性管理。 4、表单字段关联表单控件。 5、实现表单模型自动布局。 6、实现表单模板与数据结合渲染控制。 7、通过表单的定义自动创建/修改自定义数据表。 四、功能实现 4.1、表单定义管理 表单基本信息管理（表单名称、描述）、表单存储表字段管理、表单布局设计、表单数据验证定义、表单字段关联/子表单管理、表单字段编辑框行为管理，表单基本信息定义。 4.2、表单存储表字段定义 定义表单中用到的数据项，包括字段名、字段类型、长度、默认值、编辑框类型、是否允许为空、是否自增长字段、分组名称、是否在列表中显示等信息。编辑框类型一般有：文本框、文本域、复选框、单选框、列表框、时间日期选择、文件上传框等；这里定义的是表单主表字段，注意每张表单仅针对一张表，否则操作多张表的SQL不容易处理，涉及到主从表的情况可用子表单来处理。 4.3、表单布局设计 能够提供一个表单设计器。 自定义表单，有可视化表单设计界面，直接采用拖、拉、点、拽的方式来设计表单。 常见的数据获取保存等等，直接用页面构件，不需要用户写代码就能完成（有时候简单的sql语句还是需要写）。 4.4、表单数据验证定义 定义需要验证字段的规则，验证规则，可用正则表达式的方式来定义，系统内部可自带一些常用的验证规则，复杂的情况可能会出现各字段之间的值进行比较的情况。 比如判断空，是否数字，取值范围判断，是否日期，是否电话号码，省份证验证，汉字验证，等等多样的验证。 1、条件校验， 2、基础类型校验 3、逻辑表达式校验 4.5、表单字段关联/子表单管理 定义表/表单之间的关联信息，即主键外键信息。 4.6、表单字段编辑框行为定义 主要负责处理字段值发生变化时引发的其他编辑框事件，比如连动下拉框、从选择值中返回值并赋予其他字段编辑框、其他编辑框的隐藏等。 4.7、表单数据管理： 可根据字段配置信息显示表单的数据列表，并进行管理。

Activiti工作流对象关系及表结构

Activiti数据表结构和核心对象关系 西安创富电子科技有限公司 二〇一三年九月

版本历史

目录 1ACTIVITI数据库表结构--------------------------------------------------------------------------------------- 4 1.1 数据库表名说明 ---------------------------------------------------------------------------------------- 4 1.2 数据库表结构 ------------------------------------------------------------------------------------------- 4 2ACTIVITI中主要对象的关系 -------------------------------------------------------------------------------- 5

1Activiti数据库表结构 1.1数据库表名说明 Activiti工作流总共包含23张数据表，所有的表名默认以“ACT_”开头。并且表名的第二部分用两个字母表明表的用例，而这个用例也基本上跟Service API匹配。 ◆ACT_GE_* : “GE”代表“General”（通用），用在各种情况下； ◆ACT_HI_*: “HI”代表“History”（历史），这些表中保存的都是历史数 据，比如执行过的流程实例、变量、任务，等等。当系统中配置history的信息记录级别为“none”时，这一类表也可以不用； ◆ACT_ID_* : “ID”代表“Identity”（身份），这些表中保存的都身份信 息，如用户和组以及两者之间的关系。如果Activiti被集成在某一系统当中的话，这些表可以不用，可以直接使用现有系统中的用户或组信息； ◆ACT_RE_* : “RE”代表“Repository”（仓库），这些表中保存一些‘静 态’信息，如流程定义和流程资源（如图片、规则等）； ◆ACT_RU_*: “RU”代表“Runtime”（运行时），这些表中保存一些流程实 例、用户任务、变量等的运行时数据。Activiti只保存流程实例在执行过程中的运行时数据，并且当流程结束后会立即移除这些数据，这是为了保证运行时表尽量的小并运行的足够快； 1.2数据库表结构 Activiti数据表清单:

网络化设计与制造.

2 网络化设计与制造 2 . 1 Internet 的魅力及企业Intranet / Extranet Internet 是在计算机网络的基础上建立起来的,它采用TCP / IP 协议作为共同的通信协议,将世界范围内许许多多计算机网络联结在一起,成为当今最大的和最流行的国际性网络,也被人们称为全球信息资源网。I 以ernet 的主要功用有网络通信、计算机系统远程登录、文件传输、网络信息服务等。 网络的出现,改变了计算机的工作方式,而Internet 的出现,又改变了网络的工作方式。对用户来说,Internet 不仅使他们不再被局限于分散的计算机上,同时也使他们脱离特定网络的约束。任何人只要进人Internet ,他就可以利用其中各个网络和各种计算机上难以数计的资源,同世界各地的人们自由通信和交换信息,以及去做通过计算机能做的无论什么事情。Internet 一经出现,在短短几年时间里,就遍及美国大陆,并伸延到世界各个角落。 利用Internet 技术,可以构建不同的应用。对于Internet 在企业中的应用,可以按照对内和对外分成Intranet 和Extranet 。 Intranet 是一个在企业内用Internet 的开放标准建立起来的网络结构,整个结构都会在TCP / IP 上执行。整个企业网络采用HTTP 、FTP 、NNTP 、SMTP 这样一些hiternet 标准的优点首先是跨平台的应用,无论你用PC 、MAC 或UNIX 也好,所有的工作或工具都是基于Web 的,易学易用;而因为所有的工具及应用程序也是用一个Web 浏览器作为工作界面,使用者不用花时间去学或适应各种工具,像无纸办公的梦想也可能因为Intranet 的出现而成真。Extranet 其实是将企业Intranet 接上供应商、服务商的网络,成为一个大Intranet ,即称为Extranet 。 Internet 、Intranet 和Ext 了anet 三者的区别和联系在于:Internet 是基础,是网络基础和包括Intranet 和Extranet 在内的各种应用的集合;Intranet 强调企业内部各部门的联系,业务范围仅限于企业内;Extranet 强调各企业间联系,业务范围包括贸易伙

工作流引擎技术

1.1工作流引擎技术 工作流概念的提出是人们注意到了隐藏在业务处理的过程控制的共性，并从业务处理操作中分离出过程逻辑单独加以研究，从而可以实现过程优化配置和重组。但是，多年来，不同的研究者和产品供应商从不同的角度给出了工作流的定义。下面分别从工作流定义及工作流相关术语进行解释，并分析工作流应用中所遇到的多种模式，提出了工作流参考引擎、处理模型、体系结构等。 1.1.1工作流定义 WfMC给出的工作流的定义[21]：工作流（Workflow）是一类能够完全或者部分自动执行的经营过程，根据一系列过程规则，文档、信息或任务能够在不同的执行者之间传递、执行。 工作流是指业务领域的流程，它描述了业务过程中的各个要素以及要素之间的关系。 业务过程则是对工作流的抽象，通过对业务过程中各要素的描述形成过程定义。过程定义是过程自动化的基础数据，它通过工作流引擎进行管理。 下面将对工作流引擎技术中涉及到的一些基本概念给出其定义。这些概念包括：工作流引擎、业务过程、过程定义、活动、自动活动、人工活动、实例、过程实例、活动实例、工作流参与者、工作项、工作项列表等。 1.工作流引擎 工作流引擎是一个软件系统，它定义、创建和管理工作流的执行，并且运行在一个或多个工作流引擎之上。工作流引擎能够解释过程定义、实现与工作流参与者的交互并且调用各种外部IT工具和应用。 2.业务过程 一个包含一个或多个相关程序或活动的集合，这些程序或活动共同实现一个业务或决策目标。通常地，业务过程存在于一个定义了职能角色和业务关系的组织结构中。 3.过程定义 过程定义是对业务过程的描述，这种描述形式支持诸如建模、通过工作六管理系统执行等操作的自动化处理。过程定义有活动和它们之间的关系组成，这些活动和关系形成了一个网状结构，并且还包含过程开始和结束条件和各活动的详细信息，如活动参与者、相关应用和数据等。 4.活动 活动是对一份工作的描述，它是过程中的一个逻辑步聚。一个活动可以是

致远OA系统设计原理与安全性介绍

系统设计原理与安全性介绍： 1.1. 系统设计原则 1.1.1.先进性 ★采用纯B/S结构技术的系统实现 基于纯WEB方式的客户端实现，整个系统全部功能，包括系统管理员功能和全部应用功能，均为纯B/S实现，有效地降低了系统的整体实施和维护成本，也使单位培训成本大为降低。 ★基于J2EE的技术架构 基于跨平台的J2EE架构，实现各种操作系统整合应用。 ★采用先进的服务器应用软件设计及N层体系结构进行开发 采用先进的N层体系结构设计应用软件，采用分部式系统，降低系统对支持工作单一服务器的要求。 ★ XML应用 协同工作流引擎、资源信息共享平台、数据交换平台的所有数据交互，都是以XML格式来进行定义。 ★数据连接池 与单一连接不同，数据连接池会大大提高系统的运行效率。 ★数据缓存 为了进一步提高系统的运行效率，系统采用对象数据缓存技术，以内存换效率。大幅度的降低数据库的访问频度，大大提高了效率。 1.1. 2.适用性 ★使用方便，交互性强 系统的操作和管理都采用浏览器界面进行，方便操作人员使用。充分利用图形技术，展现操作流程和结构，确保系统的易用性。 系统采用一键式安装方式，仅需半小时即可完成系统的安装，降低了系统的实施成本。

★系统维护方便 纯B/S结构的系统，系统管理员只需维护系统服务器。不必再一一去处理每台机器，大大降低了使用和维护成本。 系统支持自动数据备份和恢复，减低系统管理员人为备份数据的工作量和由此带来的数据安全隐患。 1.1.3.可靠性 ★操作系统的稳定性 操作系统采用Windows 2003，具有很高的可靠性，易维护、易扩充。系统满足C2级安全性要求。 ★数据连接的稳定性 系统通过JNDI和JDBC服务连接数据库，并使用连接池提高系统性能，对每个连接的申请和归还跟踪监视，严格保持连接数量在系统性能的允许范围之中★系统安全 充分利用操作系统和java提供的安全机制(口令验证、存取控制、电子签名、加密)，实现服务器、数据库、视图、表单、操作、域和代理等多层安全控制。对敏感数据的存储进行128位的数据加密。从而保证了系统在用户认证、数据传输和数据储存等多方面的安全要求。 ★数据库安全 用户访问必须提供正确的用户名和密码，不能以匿名方式登录访问。 1.1.4.集成性 ★跨平台支持 系统基于http协议和B / S 结构设计，稳定运行于JA V A平台，服务器支持WINDOW系列、LINUX、UNIX各种操作系统。 ★功能模块化体系结构 用友致远协同工作系统采用模块化体系架构开发，各模块间彼此有接口又相互独立，各个功能模块可拆分、可选、可定制，支持将来各模块功能的单独扩展和定制。 ★DHTML实现的图形化流程定制工具

Activiti工作流入门详解完整教程

A c t i v i t i工作流入门详 解完整教程 Prepared on 24 November 2020

Activiti入门教程详解完整教程 1.Activiti介绍 Activiti是由Alfresco软件在2010年5月17日发布的业务流程管理(BPM)框架,它是覆盖了业务流程管理，工作流，服务协作等领域的一个开源，灵活的，易扩展的可执行流程语言框架。 Activiti基于Apache许可的开源BPM平台，创始人TomBaeyens是JBossJBPM 的项目架构师，它的特色是提供了eclipse插件，开发人员可以通过插件直接绘画出业务流程图。 1.1工作流引擎 ProcessEngine对象，这是Activiti工作的核心。负责生成流程运行时的各种实例及数据，监控和管理流程的运行。 1.2BPMN 业务流程建模与标注（BusinessProcessModelandNotation,BPMN），描述流程的基本符号，包括这些图元如何组合成一个业务流程图(BusinessProcessDiagram) 2.准备环境 2.1Activiti软件环境 1)或者更高版本 2)支持的数据库有:h2,mysql,oracle,mysql,db2等 3)支持Activiti运行的jar包，可以通过maven依赖引入 4)开发环境为或者以上版本，myeclipse为版本 安装流程设计器(eclipse插件) 1）打开HelpInstallNewSoftwareAdd

输入Name:ActivitiDesigner designer/update/ 输入完成后，单击OK按钮等待下载完成后安装。 安装完成后在菜单选项中会出现Activiti的目录选项 设置eclipseactivit插件的画流程图选项 打开菜单Windows-->Preferences-->Activiti-->Save下流程图片的生成方式 勾选上Createprocessdefinitionimagewhensavingthediagram操作，勾选上这个操作后在画流程图后保存eclipse会自动生成对应的流程图片。 准备开发环境 Activiti依赖 在eclipse左边工作栏右键New选择创建MavenProject项目，创建一个名为ActivitiTest的项目 点击Finish完成。 右键项目选择Properties，选择ProjectFacets勾选上图中的选项，点击Apply，再点击OK 然后将项目转换成web项目,右键项目选择Properties,在ProjectFacets中做如下勾选,然后点击Appy应用和OK确定 然后右键项目Properties，选择DeploymentAssembly,将test相关目录Remove掉之保留main下面需要发布的内容，如下图 然后点击Appply和OK 然后在文件中添加以下依赖