普元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，这个类包含了事

件的注册，事件的发布，事件的注册是一个静态代码块实现的。注册了上节描述的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下去了，好象很复杂。

1.2. 时限管理服务

1.2.1. 时限的分类

时限类型有两种：一种是一次触发完成时限，还有一种是循环触发（譬如隔多长时间进行一次提醒）并可设置触发的次数。

1.2.2. 时限计算器

在工作流引擎启动时就启动一个JVM唯一实例的时限计算器，该类可以使用引擎默认的。也可以自己去实现一个自定义的计算方法，在配置文件中注册要重写的类名即可。引擎的时限计算器只有两个方法，一个是计算结束时间，还有一个是计算提醒时间。其实是个静态类。

1.2.3. 时限服务的启动

在引擎中的时限服务有两个，一个是引擎启动的时候启动的时限服务，该服务初始化了时限对象列表；一个是在引擎启动后启动的服务，该服务是对列表中的时限对象进行轮询，触发超时的时限对象对应的触发事件，并移除该对象时限。时限的线程处理用了大量的过程化程序的结构，在这里还是比较绕人的。

1.2.4. 时限的注册和移除

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

在启动一个环节或启动一个流程时判断该活动或该流程的时限，如果该活动或该流程定义了时限则向时限服务注册该时限;在TimerManager类中的注册方法的实现是调用时限服务类的registeTimer方法，往时限对象列表（V ector）追加一条记录。

在结束活动事件时或结束流程时如果是超时的操作则时限对象列表中没有该活动的时限对象，因为该对象已被时限触发器触发并移除。如果没有超时则要把这个向量列表中的那条时限对象给去掉。在TimerManager类中的注册移除方法的实现是调用时限服务类的unregisteTimer方法，往时限对象列表（V ector）移除一条记录。

1.2.5. 时限事件的触发

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

对时限的处理是通过java.util.Timer这个类来实现的。是通过新建一个时限任务（MyTimerTask）让Timer来执行。并向该类传递一个OnceTimerHandler对象实例。该对象有个方法timerTrigged就是到了预定时限时触发的方法。该方法首先调用timerHandler类的handlerTimer方法，即如果有触发事件的话就调用上节讨论的事件代码以4开头的事件。然后修改时限类的当前状态为3，完成一次时限触发动作。

2. 流程同步服务

流程同步服务是引擎自定义的一个对流程实例和流程定义的锁的定义，譬如在做指定下一个环节的参与人（WFAppointParticipantManager中的appointNextActParticipant方法）时先把当前的流程实例给琐住（ServiceFactory.getLockService().lockProcInstance）。然后在方法结束后再把流程实例的锁给释放（ServiceFactory.getLockService().releaseProcInstance）。

在同步服务中定义了两种类型的锁，一种是流程定义锁，一种是流程实例琐（两个list），在加琐时检查改ID（流程实例ID或流程定义ID）是否已经在琐列表中，如果在则加琐。在加琐与解锁之间是通过一个线程来操作锁列表（waitingList）实现的。其实现方法大概是在加锁的时候向waitingList添加一个锁对象，然后把线程wait();在解锁的时候向waitingList减去一个锁对象，并把线程notify()。流程同步服务的实现方式还是比较复杂的。尽管只用了七八个类。

3. 组织机构管理

EOS提供了一套自己的组织机构模型，我们在安徽服务保障三期中引用了该模型。该组织机构模型的服务会话面的实现是在配置文件中配置的，然后引擎采用java的反射机制加载配置类（在引擎中有个叫做“服务定位器”来实现，该服务定位器和我们平时用的一样，只是它是从文件中读取服务定义，隐藏了具体寻址细节）。如果不用EOS提供的组织机构模型可以实现WFOMService接口，并实现里面的方法。估计EOS的原意是提供组织机构模型和引擎服务的松偶合，但在其引擎的实现上好象并没有做到。

OMServiceImpl类是引擎默认加载的组织机构模型会话面类。该类定义了人员，角色，机构等等，OMServiceImpl2类包含岗位的组织机构模型（目前的引擎的还不支持，没有搞清楚EOS没有把岗位纳入组织机构模型中），但EOS提供的开源的组织机构模型中并不支持。

4. 审计服务

该服务记载了所有流程模板的变更和对流程实例的操作历史。引擎共定义了39种审计类型，包括模板变更，启动流程，完成工作项等等。由于审计的类型代码和引擎的事件代码，所以引擎在中间做了一层映射，把事件代码和审计代码一一对应（审计代码多于事件代码）。在审计过程中其实是往审计表中加一条历史记录。

5. 日志服务

引擎的LOG服务很简单，和我们平时用的LOG差不多。在打日志的时候传入JVM唯一实例的日志上下文WFLogContext，在该类中定义了一条日志所需要的日志头，比如等级（@level），操作员（@operator），sql（@sql），时间戳（@timestamp）等等。然后在具体打某一条日志的时候把日志头和日志内容拼装起来形成一条日志。

引擎的日志实现了日志的读写，引用了log4j的RollingFileAppender和PatternLayout。并提供了类似AOP的方法前后拦截打日志的服务（不知道方法前后的拦截日志是在代码中人工加上的还是由AOP代理自动加载的，因为采用了AOP时在编译的时候就把代码插入到要拦截的切入点中去）。

6. 持久层服务

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

我理解的不对）。

7. 引擎的缓存

工作流引擎的缓存是通过一个HashMap来维护的。用有以下几类缓存：流程实例的缓存；活动实例的缓存；工作项的缓存；相关数据的缓存；相关数据Dom的缓存；流程属性数据的缓存，以上几类的实例缓存个数是通过在配置文件中配置的，还有一类流程模板的缓存是在引擎启动的时候就解析流程模板的XML文的定义（因为流程定义是通过XML文来存储在数据库中），解析成流程定义对象并加载到内存中。

7.1. 缓存的配置

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

1

2false

3

41000

5

65000

7

810000

910000

10

111000

12

131000

14

151000

7.2. 缓存的实现

在引擎启动的时候取得工作流配置信息，如果允许使用缓存则初始化上面所述的六类缓存。在初始化的时候引擎默认缓存的存活时间为0x1499700L。缓存的大小为配置文件所配。这样则生成在JVM里的六个Cache类的实例。每个Cache都有一个HashMap的属性，这里面存储了要缓存的对象。在CacheFactory类中又有一个HashMap对象属性，这个对象存储的是Cache对象的集合。就是上面所述的六个Cache类实例的集合。普元的开发人员把该对象起名为Caches。那么在取某个活动实例时就先中缓存中读取，如果找到则直接返回，如果没有则从数据库中加载。

引擎的缓存并不是直接把从数据库中取得的对象put到map中，而是做了一层优化，把从数据库中找到的对象封装成CacheObject对象，该对象有个链表（LinkedList）的属性对象。该对象有前驱和后继节点，其节点就是我们要put的对象。其具体的优化策略和大多数缓存一样，采用最近最多访问策略，共有两个列表维护，一个是最近访问对象位于首位，一个是最多访问对象位于首位。

8. EOS引擎的精彩之处

EOS引擎设计上最精彩的地方应该是基于多线程的事件调度机制，在事件处理是下层有个线程池处理事件，其中有个线程拿到了一个事件后就开始他的事件的发布和事件的迁移。（多线程协同工作的程序设计我觉得应该是程序设计中最复杂的地方，不但要屏弃所谓“万物皆是对象”的看法，可能还需要用到大量的goto语句来解决一个面向对象这种思想不好解决的问题，还有在JA V A中线程的调度可能还依赖于程序所跑的操作系统和硬件环境，有很多的不可预料性的存在。我怀疑这个线程池肯定有问题，或者单线程已经足够解决所有问题，不然EOS引擎为什么不把多线程处理事件作为默认的处理方式而是单线程作为默认的呢？）

多线程调度的初始化：引擎根据配置文件（wfconfig.xml）里的线程数（event_thread_num）新建了那么多数量的线程。并把这些线程放到已经定义好的线程组里。这些线程对象有个对象属性：EventList，这里装载的是该线程该处理的所有事件对象。然后把这些线程都start()；该线程轮询EventList里的事件对象列表，如果对象列表为空则把自己阻塞（wait()），如果有事件对象则取第一个事件然后发布该事件，对该事件的处理还是和单线程是一样的。

线程池对客户端动作的响应：客户要向引擎发布一个事件首先找到线程组的activeCount，然后根据取得的数量在新建这么多的线程然后enumerate（复制到线程组中）它们。引擎把这些线程对象转换成事件处理线程（EventThread），然后遍历这些线程，然后根据“找到这些线程对象中的EventList里的事件最少的一个线程“这种策略，把要发布的事件对象加到找到的这个线程对象的EventList里，同时唤醒这个线程，完成了一次事件的发布，完成了线程自己和自己的协同工作。

9. EOS引擎的不足

9.1. 组织机构模型

EOS提供的组织机构模型无法解决按岗位或按行政级别分派工作项。但这是很常见的一种情景（安徽二期的工作流平台好象实现了按行政级别来提交工作项）。网上有一种比较流行的组织机构的模型。

如果能把这种组织机构模型经演化应用到引擎中去可能会解决按岗位，按行政级别，按职务来设参与人的问题，甚至可以解决一个机构只有一个流程的问题而不是机构的下属机构拥有一套和其他下属机构一样的流程（只是参与人不同而已）。而我们的应用中只需要一套共性的流程和下属机构个性化流程的实施。由于客户在管理可能会有不足或把依靠系统来管理，而我们希望我们系统的不足能在管理上弥补，所以能在这中间达到一种平衡需要找到这中间的平衡点。

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

由于在引擎启动的时候引擎把流程定义XML文解析成流程定义对象，然后加载到内存中，而发布流程的动作只能来自一台集群节点，固无法把修改后的流程定义同步到其他的集群节点。现在的同步方法是发布流程的时候同时调用其他节点的一个远程方法来实现同步。虽然通过外挂式的解决方案解决了这个问题但没有从根本弥补引擎的缺陷。

EOS的业务字典的管理也是存在同样的缓存问题，在一个节点建了一个业务字典没办法同步到其他节点中去。

环节的时限也是用了缓存，一个环节的时限注册是在环节启动时如果定义了时限则向时限服务注册，并在内存中产生一个时限对象，有个后台线程在维护它，当环节结束时取消该环节的注册，移除该环节在内存中的时限对象并删除数据库中的时限表的那条数据。有一种极端的场景（不可能发生）：所有的用户在结束自己的环节后启动了下一个环节（假设

该环节的完成时限为一个月）。这个动作是在节点A进行的，则节点A的内存中有了所有下个环节的时限对象。节点A的后台线程在维护该对象，不停的判断是否超时。假设下个环节的所有用户在没有超时的情况下完成自己的工作项，并且操作的发生在节点B，用户操作自己的环节后结束环节并取消时限注册并删除时限表，但节点A的时限对象并没有移除。节点A的后台线程一直在维护着它直到它超时才从内存中删除，造成了内存里的垃圾数据．

我认为引擎层还是应该有一个类似缓存同步服务（可能我说的不对），譬如在流程未发布和发布成功的状态位的迁移过程中加一个待发布的状态，当发布流程的时候把该流程定义的发布状态定义为待发布，然后有两个线程协同工作，一个线程定时（譬如20S）来轮询待发布的流程定义并加载到一个待发布流程列表（该列表类似操作系统中的信号量）中，如果该列表非空则唤醒另一个流程发布线程，该线程sleep一定的时间（该时间要大于等于轮询的时间保证所有节点都已经把待发布的流程定义都加载到内存中）后发布该流程并把流程置为发布状态，然后将自己阻塞。

9.3. 子流程的设计

EOS的子流程是作为一个主流程的环节来实现的，我觉得不应该有子流程和父流程的概念，也不应该把一个流程作为一个环节来实现。流程与流程之间的通信可以已一定的接口定义和通信规则来实现，父子关系只是其中的一种（属于工作流协同工作的网状模型），还有链状模型，端到端的模型，并行同步模型。这样如果有了接口的标准既解决了父子关系的流程通信，同时也解决了EOS工作流不同实例的交叉操作，甚至解决了不同工作流产品之间的流程通信（只要遵循了接口定义标准，该接口为WFMC定义的接口4，该接口定义了一系列的互操作层次（好象是8个），但可能并不能满足像EOS的引擎具有中国特色（譬如自由流，抄送……）工作流需求）。

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

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)产生令牌。

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

工作流引擎讲解

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

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

工作流引擎技术白皮书

工作流引擎 产品功能介绍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)

基于工作流引擎的系统框架设计开发

基于工作流引擎的系统框架设计开发 ——工作流引擎子系统 摘要 工作流就是一系列相互衔接、自动进行的业务活动或任务。工作流引擎是工作流管理系统的核心，它的主要功能是通过计算机技术的支持去定义、执行和管理工作流，协调工作流执行过程中工作之间以及群体成员之间的信息交互。 论文主要讲述了工作流引擎的基本功能及设计方法，介绍工作流引擎的基本原理，具体分析了工作流引擎所包含的内容，详细介绍了相关的信息模型和控制模型。系统采用关系结构的理念来设计工作流引擎，给出了用Microsoft Visual Studio 2005和Microsoft SQL Server2000实现系统的方法。论文中利用本工作流引擎构建系统能适应大多数业务流程的扭转，大大缩短常见信息系统的项目开发周期，提高效率。 关键词：工作流引擎；关键业务；关系

The design of information system frame based on workflow engine ---- The subsystem of workflow engine Abstract Workflow is a series of interlocking, automatic business activities or tasks. Workflow engine is the work flow management system in the core, and its main function is to define, implement and manage work flow through the support of computer technology as well as co-ordinate work flow process of working implementation and groups of information between members of interaction. The thesis has mainly described basic functions and design of the workflow engine, introduced the basic theories, and specifically analyzed the content included in the work flow and the details of the relevant information model and control model. The idea of relation structure has been used to design this system and the method to achieve the system function with Microsoft Visual Studio 2005 and Microsoft SQL Server2000 has been given out. Constructing system with the workflow engine can adapt to the majority of the business process reversing that significantly reduce the development cycle of the common information system and improve efficiency. Key words：Workflow engine; Critical business; Relationship

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

2.10通信集中告警系统设计

目录

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

工作流技术方案

工作流技术方案

目录 1概述3 1.1工作流现状 (3) 1.2建设原则 (3) 1.3建设目标 (3) 1 (4) 2总体设计方案4 2 (4) 2.1业务架构设计 (4) 2.1.1业务功能设计 4 2.1.2业务模型设计 5 2.2总体架构设计 (6) 2.2.1工作流总体结构图 6 2.3技术架构设计 (7) 2.3.1展现层 7 2.3.2控制层 7 2.3.3业务逻辑层 7 2.3.4数据持久层 8 2.3.5缓存 8 3应用系统设计8 3 (8) 3.1流程定义 (8) 3.2流程管理和监控 (8) 3.3工作流引擎 (8) 3.4工作项列表 (9) 1 (9) 1.1 (9) 1.2 (9) 1.3 (9) 1 (9) 1.1 (9) 1.2 (9) 1.3 (9)

1概述 1.1工作流现状 工作流是实现企业业务过程建模、业务过程仿真、业务过程管理与集成，从而实现最终业务过程自动化化的核心技术。 传统的工作流管理系统缺乏柔性，不能及时响应变化和相互之间缺乏互操作的缺点不能满足这种复杂业务流程管理的需要。针对这种情况，提出工作流管理平台的实现方案，以便更好地对企业业务流程实行管理。 1.2建设原则 工作流管理平台的设计主要遵循实用性、稳定性、高效性、灵活性等原则： （1）稳定性原则：需要采用成熟的技术模型、稳定的软硬件产品、软件开发平台和工具。 （2）安全性原则：提供完整备份机制，提供安全的数据访问机制。 （3）友好性原则：考虑到平台将针对各个层面的用户群体，使用者的计算机水平参差不齐，所以需求平台提供的界面简便友好、操作方便。 （4）扩展性原则：系统设计应具有良好的可扩展性和升级能力，可以根据新的业务拓展，方便地追加新的模块，也可以根据运营的状况，自由地追加硬件，以实现对系统有效的负载均衡。 （5）快速开发原则：提供封装的开发构件，提供基本的系统管理模块，提供简洁的开发模板，能够满足各类业务需求的快速开发。 1.3建设目标 根据上述原则，工作流管理平台建设的主要建设目标为： （1）实现基于Jbpm的流程引擎的二次开发。 （2）实现图形化的流程定义工具和流程管理监控工具。 （3）实现工作项列表（包括待办事宜、已办事宜、历史事宜）的统一管理界面。 （4）实现在流程生命周期中应用系统对流程触发的动作的相关服务接口：工作流定义相关服务、工作流引擎相关服务、工作项列表相关服

工作流引擎技术白皮书

工作流引擎产品功能介绍

目录

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

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

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）构成：单据类型、流程、活动、函数、消息、通知和查找类型。单据类型是一种分类对象，其它的对象都属于一个单据类型。

OA流程引擎总体设计方案(含初步表说明)

AO流程引擎总体设计方案 一、名词。 流程表：每设置一个新的流程时，都会设置流程相关的字段信息。设置后生成一张流程表。每按此流程进行一个办事流程时即是此表的一条记录（实例）。 流转单：即处理流程中的各个环节，如科员填表申报环节、科长审批环节等。每个流转单所需要的字段是从流程表中选出的字段。每个流转单实例即是根据选择的字段从流程表的实例记录中进行显示或操作。 二、流程设置 2.1 流程表设置 在设置流程时，根据其下流转单的情况设置好所要的所有字段信息。设置好后生成一张数据库表。并把流程名称，流程表名等信息记录到一个流程记录表里（这张表只用来记录流程表及流程对应的流程表名）。默认存在的字段应该有：流程实例名（如：2011年3月消防器材发放管理工作），流程状态，父流程表名，父流程实例id,父流程关联流转单编号，开始时间，结束时间等。 2.2流转单设置。 2.2.1流转单基础信息设置。 设置流转单名称，即流程在此环节时的名称（如科长审批）； 设置流转单编号，编号应该是唯一性的； 设置流转单类型：一般流转单或子流程流转单或起始流转单； 2.2.2选择表单字段。 字段从流程表中字段进行选择。选择每个字段后， 要设置此字段的配置属性：是否只读、是否隐藏； 要设置此字段的验证属性：是否必填、验证方法（email验证、长度验证等）； 要设置此字段对应的控件：HTML控件：文本框、文本域、密码框、下拉框、多选框、单选框、上传框。及对应的默认数据和备选数据。动态控件：如部门下拉框等。及对应默认数据。 要设置此字段的控件样式：高宽等。 根据字段的名称流程表名等信息对此字段设置一个字符串标识。 在设置字段过程中如果觉得字段不够，应该有操作可以再添加流程表字段。 2.2.3设置流转单显示模板。

jbpm和shark工作流引擎对比

jbpm和shark工作流引擎对比 Xpdl：xml process definition language? Bpel:Business Process execution language? Jpdl：JBoss Jpbm Process definition language.

三亠 -出 1 (shark '^ B f Q M ) “tpcrfwwr 一 WfPmcrw 寥w ^C C E 王亍s- l t l l c -p =8 fe. n 2 Q ? su E wurhlt 1: 纟 - ory "&□.At vnsMk - uriflg jiubkd ehbunKk F t h 4- B c pruccan ^y t l i w &s.g n a l l l ) ^d 」2=-l ￡.x n ??=e *§9 mzr W n^ecIH ?- 一 dcunptF: nrinm 4 二-ring priority 二- 3g S u s - =Hat proc? uatm: FnxcfsFtl =J4lllh_og u cum- sutci) r M ^J C I F E J ,&d ?rcwinwO umin ?Ej ?r i - Mlm 一as- M K C d n i ) 亍 m E p whi fpenu =一一 —Jtiap :Tun??lu^::u~c 一 g JH*【 c.s-y 』。.:乂 ring bvi-yfuunc: ■王 ￡ l k .3 ?"『ring -2 l -x 2n : s z i n ? 2l -=^l -5-^ -]C 3.=V\3&dscBtAud r 卫 mmF. 二? H 4U ? ^u d l ,u n - ^urw sWtc : ?3a w daU “ NmeV flocs d H n : A . l _ ? I g 工 i ?亍1 ￡ ? ? 2 ??f& V j.i I s v v p g .gnugEvcfltAJidh ^evnerc-JJCy: ctring *l 3c c s l - 5 -il r g d remircc ndmc : K 3

普元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，这个类包含了事

工作流引擎平台解决方案

工作流引擎平台解决方案 工作流引擎平台在实际系统中的应用一般分为三个阶段，即模型建立阶段、模型实例化阶段和模型执行阶段。模型建立阶段利用工作流建模工具完成各种企业经营过程或者项目管理流程模型的建立，将企业的实际经营过程或项目管理流程转化为计算机可处理的工作流模型。模型的实例化阶段为每个过程设定运行所需的参数，并分配每个活动执行所需的资源（设备、人员等）。模型执行阶段完成经营过程的执行，在这个过程中重要的任务是完成人机交互和应用的执行，并对过程与活动的执行情况进行监控与跟踪 WorkFlow的设计理念是致力于企业的业务流程自动化解决方案，为企业的业务流程自动化以及企业流程再造提供坚实的基础平台，成为业界领先的企业业务流程自动化的基础平台产品以及企业流程再造的核心产品。有力的简化应用开发的步骤，降低应用开发的难度，提高应用开发的效率及灵活性，节约应用开发的成本，从而极大的提高应用开发的生产力。WorkFlow产品构成分为三块：模型定义工具、工作流引擎、客户端应用。模型定义工具提供图形化的过程定义工具，而工作流引擎则实现了工作流的后台驱动。后台工作流引擎以COM组件方式实现，为应用系统的集成提供了方便的编程接口。客户端应用是人机交互的界面、与业务系统的具体应用。 1.模型定义工具 Workflow建模工具以图形界面为建模人员提供了一个友好、方便的建模环境。一个工作流的定义包括模板和实例两个部分，模板用于描述工作流定义，用于工作流应用的设计阶段；实例是将模板定义用于特定工作流程时对模板的拷贝。这样做是为了在模板使用过程中对模板可随时进行修改而不影响已启动的流程。一个工作流程称为一个工作（Job），组成工作的每个执行单元称为活动（Activity），组成活动的更小单位称为任务（Task），活动的入口称为主表单（MasterForm）。每个工作都是由一系列具有逻辑关系的活动组成，这些逻辑关系构成活动的路由信息。因此，一个工作实际上可以看作是一系列具体工作和它们之间的逻辑关系构成的一个有机整体。每个工作都有一个创建者，他是启动此工作的人。每个工作可以有多个拥有者，拥有者具有撤销、挂起、强行终止工作的权力。每个活动都有一个拥有者，他是模板中定义的活动执行人，活动拥有者

(工作分析)国内外主流工作流引擎及规则引擎分析

国内外主流工作流引擎及规则引擎分析2013年2月创新研发部

目录 国内外主流工作流引擎及规则引擎分析 (1) 一.背景 (4) 二.原则 (4) 三.工作流功能分析点 (6) 4.1.标准类 (6) 3.1.1BPMN2.0标准支持 (6) 4.2.开发类 (7) 3.1.1业务模型建模工具 (7) 3.1.2工作流建模工具 (7) 3.1.3人工页面生成工具 (8) 3.1.4仿真工具 (9) 4.3.功能类 (9) 4.1.1流程引擎 (9) 4.1.2规则引擎 (10) 4.1.3组织模型与日期 (10) 4.1.4对外API的提供 (11) 4.1.5后端集成/SOA (11) 4.1.6监控功能 (12) 四.中心已有系统工作流功能点分析 (13) 4.1.备付金系统工作流分析 (13) 4.1.1联社备付金调出流程 (13)

4.1.2联社备付金调入流程 (16) 4.1.3资金划入孝感农信通备付金账户业务流程 (18) 4.1.4备付金运用账户开立流程 (20) 4.1.5备付金沉淀资金运用流程 (23) 4.1.6备付金沉淀资金支取流程 (26) 4.2.多介质项目工作流分析 (28) 4.1.1开卡审批流程 (28) 4.3.新一代农信银资金清算系统工作流分析 (29) 4.4.电子商票系统工作流分析 (29) 4.5.OA系统工作流分析 (32) 五.工作流产品分析 (32) 六.分析结论 (44) 4.4.对比 (44) 4.5.建议 (45)

一.背景 目前中心建成的“一大核心系统，七大共享平台”以及OA系统，对工作流应用程度高，但各系统实现工作流程管理没有建立在统一的工作流平台上，导致流程割裂、重复开发、不易于管理等问题。 备付金管控项目涉及多个岗位之间工作的审核步骤，同时还要与多个系统进行交互，因此，为了提高管理效率，降低业务流转时间，同时还要结合农信银中心的总体IT战略规划，备付金管控项目技术组决定选择一款先进的工作流引擎和一款规则引擎，作为备付金管控项目的核心技术架构。 二.原则 备付金管控项目组通过梳理各信息系统流程现状和未来需求，形成农信银中心工作流平台的发展规划，从而更全面的满足农信银各项关键业务、更好的支撑现有和未来的信息系统建设。项目组充分研究国内外领先的工作流产品和案例，同厂商交流。从用户界面生成、流程建模、流程引擎、规则引擎、组织模型、模拟仿真、后端集成/SOA、变更及版本管理、移动设备解决方案、监控分析能力等多方面考察工作流产品，进行工作流产品选型。 目前国内外的工作流引擎层出不穷，行业标准多种多样，通过对比不同工作流公司产品，本次工作流技术选型决定分析商业工作流引擎4款，开源工作流引擎2款。其中国际知名厂商的商业工作流引擎2款，本土厂商的商业工作流引擎2款。由于本次技术选型是以工作流引擎为主，选型工作将不再单独分析规则

工作流表单引擎系统

表单系统设计 一、目的 表单定义：表单是用来呈现与存储数据的图形化界面，数据展现、数据存储、用户交互的工具。我们用火车来比喻，数据就是货物、表单就是车厢、火车头就是工作流程引擎。 自定义表单设计器，采用数据库格式化存储表单模板。 二、实现原理 自定义表单功能概括起来如下 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、表单数据管理： 可根据字段配置信息显示表单的数据列表，并进行管理。

工作流图形设计器详细设计说明

工作流平台——工作流设计器 详细设计说明 1 引言 1.1 编写目的 为符合软件需求并对本软件系统各功能模块进行说明，以便编程人员进行程序的编制设计，同时贯彻需求报告中所确定的通用性、完整性、可靠性及可维护性原则，做到结构合理、方便、快捷、规范开发人员的工作，特编制本详细设计说明书。 适用对象： 软件开发者（Supplicrs），以便准确地理解客户需要什么样的产品和各功能模块的具体设计和编制。 1.2 背景 在企业日常经营管理活动中，为适应市场快速变化的需要，企业要经常调整自己的管理流程，这就是我们经常提到的流程重组。通常的流程重组只是将现有的业务处理次序进行改变或改变具体的执行角色或减少不必要的环节，因此，这就要求开发的计算机管理系统业务功能没有增加的情况下能根据需要随时调整处理流程。将工作流技术与业务系统结合可以很好的解决以上的问题，这也是工作流技术的应用越来越多的主要原因。 WfMC（工作流管理联盟）给出的工作流概念为：工作流是一类能够完全或者部分自动执行的经营过程，它根据一系列过程规则、文档、信息或任务能够在不同的执行者之间进行传递与执行。事实上，工作流技术就是业务流程的计算机化或自动化，它将过程逻辑从业务逻辑中分离出来，由工作流引擎专门完成对过程逻辑的计算，从而使开发人员将主要精力集中在业务逻辑的处理上。 工作流程设计器是工作流平台的一部分，它提供用户对自己的流程进行定义的功能。 系统名称：工作流程设计器（HTCS——WorkFlowDesigner）

1.3 参考资料 《workflow.mdl》作者： 《工作流管理联盟工作流标准》4Broad 译（V1.0） 2系统结构 2.1 功能概述 工作流程设计器是工作流平台中不可或缺的一部分。工作流程设计器以图形的方式为建模人员提供了一个方便的工作流程建模环境。 2.2 系统效果图 图2.0 系统效果图 2.3 系统结构图 详见workflow.mdl

基于OA系统的工作流引擎设计方案

基于OA系统的工作流引擎设计方案

1引言 1.1课题的背景与目标 工作流的概念起源于生产和办公自动化领域，是针对日常工作中具有固定流程的业务活动提出的一个概念。工作流管理联盟(WFMC)给出的工作流定义是：工作流是一类能够完全或者部分自动执行的经营过程，它根据一系列过程规则、文档、信息或任务能够在不同的执行者之间进行传递与执行。该技术的目的是通过将工作分解成定义良好的任务、角色，按照一定的规则和过程来执行这些任务并对它们进行监控，达到提高工作效率、降低生产成本、提高企业生产经营管理水平和企业竞争力的目标。 工作流管理系统的核心部分是工作流引擎，引擎是驱动流程流动的主要部件，它负责解释工作流流程定义，创建并初始化流程实例，控制流程流动的路径，记录流程运行状态，挂起或唤醒流程，终止正在运行的流程，与其他引擎之间通讯等等工作。 目前，工作流技术还处于发展曲线的初级阶段，然而，关于这方面的研究十分活跃，形成了许多规标准。例如主要的有：工作流管理联盟（Workflow Management Coalition ，WfMC）在体系结构[6]、工作流相关术语[7]及应用程序接口[8]、管理控制接口[9]、过程语言描述[10]等方面提出的一系列规。还有Microsoft, BEA, IBM, SAP等公司联合提交发布的BPEL规等等。 在实际应用中开源产品占据了重要的地位，如JBoss 项目中的jBPM、由OpenSymphony组织开发的OSWorkflow、Enhydra组织开发的Shark。在国，交通大学的基于Petri网点分布是工作流管理的研究，大学的基于工作流过程定义语言（WPDL）的工作流建模平台，都取得了良好的研究成果。 但是工作流管理技术很多方面还不成熟，在使用过程中往往会遇到的一个重要问题是系统过于庞大复杂：一些工作流软件产品，特别是国外成熟的产品，经过多年的发展，功能强大，配置和接口多样灵活。对于国大部分初次使用工作流技术的中小型项目来说，这些工作流软件的功能特性大大超过了需要，客户需要承受漫长的学习周期、复杂的安装配置等带来的风险。 鉴于上述的原因，本课题的目标在于提出一个配置简单、使用方便、功能实用的工作流引擎的设计方案，并完成编码。该工作流引擎——OAworkflow是借鉴了已有的工作流引擎，对某些复杂功能进行简化后，重新设计的。与传统工作流管理系统相比，本工作流管理系统具有以下优点： 1)支持灵活的流程定制 该系统能够针对办公自动化系统中的典型流程案例对流程进行灵活定制，支持的流程路由包括：顺序路由、汇聚路由和分支路由。用户可以根据

网络化设计与制造.

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 强调各企业间联系,业务范围包括贸易伙

net工作流引擎设计 三 WorkFlowEng

net工作流引擎设计三 WorkFlowEng .net工作流引擎设计(三)：WorkFlowEngine工作流引擎设计 a.工作流引擎只负责处理与流程运转相关事宜，处理过程的解释执行、流 转规则，控制任务管理器。架构在工作流引擎之上的web应用的具体业务处理 另外编写，以保持工作流引擎的独立性和简洁性。 b.通过此设计方案设计的工作流引擎，只负责业务系统流程的流转，业务 系统使用此工作流引擎需要根据业务系统的需要来评估使用性以及考虑业务逻 辑的具体实现，不能依靠工作流引擎来实现所有的业务功能。 c.此阶段在业务系统中需要控制表单控件的访问权限时需要业务系统结合 工作流来自行进行控制，在之后的工作流引擎功能扩展第二阶段可以设计通过 工作流引擎来控制表单中控件的访问权限。 d.此阶段流程定义采用程式来定义和维护，不使用图形化的建模工作。在 工作流平台的进一步深入开发的第三阶段再进行流程定义工具的开发。 .1工作流定义 根据WFMC的定义，工作流(Workflow)就是自动运作的业务流程部份或整体，表现为参与者对文件、信息或任务按照规程采取行动，并令其在参与者之间传递。简单的说，工作流就是一系列相互衔接、自动进行的业务活动或任务。如 果将整个业务流程看作是一条河，其中流过的就是工作流。使用工作流作为业 务流程的实现技术首先要求工作流系统能够反映业务流程的以下几个问题，即 业务流程是什么由哪些活动、任务组成，也就是结构上的定义、怎么做活动间 的执行条件、规则以及所交互的信息，也就是控制流与信息流的定义、由谁来 做人或计算机应用程序，也就是组织角色的定义、做的怎么样通过工作流管理 系统对执行流程进行监控。 工作流参考模型

工作流引擎技术

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