开源工作流框架对比.

工作流开发框架（原创版）目录1.工作流开发框架概述2.工作流开发框架的优点3.工作流开发框架的缺点4.如何选择适合自己的工作流开发框架5.结论正文1.工作流开发框架概述工作流开发框架是一种用于实现工作流（即一系列任务有序执行的过程）的软件工具。

工作流开发框架可以帮助开发者快速构建工作流应用，简化工作流实施过程，降低开发和维护成本。

工作流开发框架通常具有很好的扩展性和可定制性，可以根据实际需求进行自定义。

2.工作流开发框架的优点（1）提高开发效率：工作流开发框架提供了丰富的组件和 API，可以快速搭建工作流应用，减少重复开发工作。

（2）易于维护：工作流开发框架具有清晰的模块划分和良好的代码结构，便于进行代码维护和升级。

（3）灵活性高：工作流开发框架通常支持多种工作流模型和引擎，可以根据实际需求进行选择和切换。

（4）可扩展性强：工作流开发框架具有良好的扩展性，可以根据项目需求进行插件和功能的扩展。

3.工作流开发框架的缺点（1）学习成本：虽然工作流开发框架可以提高开发效率，但是对于初学者来说，需要花费一定的时间学习和熟悉框架的使用。

（2）兼容性问题：工作流开发框架可能会涉及到多种系统和平台，可能存在兼容性问题，需要进行额外的测试和调整。

4.如何选择适合自己的工作流开发框架在选择工作流开发框架时，需要考虑以下几个方面：（1）项目需求：根据项目的具体需求，选择适合的工作流模型和引擎。

（2）技术栈：考虑团队的技术栈和开发经验，选择易于上手和工作流开发框架。

（3）社区支持：选择具有良好社区支持的工作流开发框架，便于解决在使用过程中遇到的问题。

（4）扩展性：考虑工作流开发框架的扩展性，以便于后期功能的扩展和升级。

5.结论总的来说，工作流开发框架是一种提高开发效率、降低开发成本的工具。

在选择工作流开发框架时，需要综合考虑项目需求、技术栈、社区支持和扩展性等因素，选择适合自己的框架。

Java开源工作流对比9、链接：从程序员的角度来看为什么我们需要工作流10、链接：工作流简介及其6种常用的工作流引擎J2EE常用工作流比较的概念是Process 和Activity。

XPDL 中的Activity是基于UML1.x中的活动图的概念。

活动图天生的适于工作流程建模，它相对于状态图的一个最大的优点是容易做并发线程的分叉控制，这些并发线程可以同时执行也可以顺序执行；它还有一个优点是有泳道的概念，可以控制工作流引擎中的任务的产生。

在所有开源工作流引擎中，Shark的体系最为完备和复杂。

其一直秉承着“模块化”的思想，所以比较容易扩展。

但是自从被Together公司收购后，Shark的商业化色彩已经越来越浓，改称为Together Workflo w Server，并仅以Community Editio n的形式提供了部分开源代码供参考。

和运转场景，而是提供一套可维护调度的机制，供开发人员自主扩展。

这个维护流程调度机制OSWorkflow选择的是基于行为（Action）的FSM理论，所以OSWorkflow更像是一个复杂而灵活的有限状态调度机。

Osworkflow有个重要概念是State，State是由step和status联合表达的，一个State就是一个step中的某个status；而state的转换由action来驱动，类似状态图中的event,因为一个event对应一个actionOSWorkflow在国内项目应用得较多，很多国内的简易审批流程项目都是基于其引擎二次开发而来。

这主要是由于OSWorkflow是基Jbpm把action也改名了，称为state。

Jbpm使用的状态图的概念有transition/event等。

Jbpm来内部实现中还采用了PetriNet的概念，如token,signal等，jBpm对Token的应用很有特色，巧妙地利用Parent-Child Token的机制处理分支、父子流程等复杂应用场景。

⼯作流引擎详解！⼯作流开源框架ACtiviti的详细配置以及安装和使⽤创建ProcessEngineActiviti流程引擎的配置⽂件是名为activiti.cfg.xml的XML⽂件.注意与使⽤Spring⽅式创建流程引擎是不⼀样的使⽤org.activiti.engine.ProcessEngines类,获得ProcessEngine:ProcessEngine processEngine = ProcessEngines.getDefaultProcessEngine()它会在classpath下搜索activiti.cfg.xml,并基于这个⽂件中的配置构建引擎<beans xmlns="/schema/beans"xmlns:xsi="/2001/XMLSchema-instance"xsi:schemaLocation="/schema/beans /schema/beans/spring-beans.xsd"><bean id="processEngineConfiguration" class="org.activiti.engine.impl.cfg.StandaloneProcessEngineConfiguration"><property name="jdbcUrl" value="jdbc:h2:mem:activiti;DB_CLOSE_DELAY=1000" /><property name="jdbcDriver" value="org.h2.Driver" /><property name="jdbcUsername" value="sa" /><property name="jdbcPassword" value="" /><property name="databaseSchemaUpdate" value="true" /><property name="jobExecutorActivate" value="false" /><property name="mailServerHost" value="" /><property name="mailServerPort" value="5025" /></bean></beans>配置⽂件中使⽤的ProcessEngineConfiguration可以通过编程⽅式创建,可以配置不同的bean idProcessEngineConfiguration.createProcessEngineConfigurationFromResourceDefault();ProcessEngineConfiguration.createProcessEngineConfigurationFromResource(String resource);ProcessEngineConfiguration.createProcessEngineConfigurationFromResource(String resource, String beanName); // 配置不同的bean id ProcessEngineConfiguration.createProcessEngineConfigurationFromInputStream(InputStream inputStream);ProcessEngineConfiguration.createProcessEngineConfigurationFromInputStream(InputStream inputStream, String beanName);如果不使⽤配置⽂件进⾏配置,就会基于默认创建配置ProcessEngineConfiguration.createXXX() ⽅法都会返回ProcessEngineConfiguration,后续可以调整成所需的对象. 在调⽤buildProcessEngine()后, 就会创建⼀个ProcessEngine:ProcessEngine processEngine = ProcessEngineConfiguration.createStandaloneInMemProcessEngineConfiguration().setDatabaseSchemaUpdate(ProcessEngineConfiguration.DB_SCHEMA_UPDATE_FALSE).setJdbcUrl("jdbc:h2:mem:my-own-db;DB_CLOSE_DELAY=1000").setJobExecutorActivate(true).buildProcessEngine();ProcessEngineConfiguration beanactiviti.cfg.xml必须包含⼀个id='processEngineConfiguration' 的bean<bean id="processEngineConfiguration" class="org.activiti.engine.impl.cfg.StandaloneProcessEngineConfiguration">这个bean会⽤来构建ProcessEngine. 有多个类可以⽤来定义processEngineConfiguration. 这些类对应不同的环境,并设置了对应的默认值:org.activiti.engine.impl.cfg.StandaloneProcessEngineConfiguration: 单独运⾏的流程引擎.Activiti会⾃⼰处理事务.默认数据库只在引擎启动时检测(如果没有Activiti的表或者表结构不正确就会抛出异常)org.activiti.engine.impl.cfg.StandaloneInMemProcessEngineConfiguration: 单元测试时的辅助类.Activiti会⾃⼰控制事务. 默认使⽤H2内存数据库,数据库表会在引擎启动时创建,关闭时删除.使⽤它时,不需要其他配置(除⾮使⽤job执⾏器或邮件功能)org.activiti.spring.SpringProcessEngineConfiguration: 在Spring环境下使⽤流程引擎org.activiti.engine.impl.cfg.JtaProcessEngineConfiguration: 单独运⾏流程引擎,并使⽤JTA事务数据库配置定义数据库配置参数基于数据库配置参数定义数据库连接配置jdbcUrl: 数据库的JDBC URLjdbcDriver: 对应不同数据库类型的驱动jdbcUsername: 连接数据库的⽤户名jdbcPassword: 连接数据库的密码基于JDBC参数配置的数据库连接会使⽤默认的MyBatis连接池,配置MyBatis连接池:jdbcMaxActiveConnections: 连接池中处于被使⽤状态的连接的最⼤值.默认为10jdbcMaxIdleConnections: 连接池中处于空闲状态的连接的最⼤值jdbcMaxCheckoutTime: 连接被取出使⽤的最长时间,超过时间会被强制回收. 默认为20000(20秒)jdbcMaxWaitTime: 这是⼀个底层配置,让连接池可以在长时间⽆法获得连接时, 打印⼀条⽇志,并重新尝试获取⼀个连接.(避免因为错误配置导致沉默的操作失败) 默认为20000(20秒)使⽤javax.sql.DataSource配置Activiti的发布包中没有这些类, 要把对应的类放到classpath下<bean id="dataSource" class="mons.dbcp.BasicDataSource" ><property name="driverClassName" value="com.mysql.jdbc.Driver" /><property name="url" value="jdbc:mysql://localhost:3306/activiti" /><property name="username" value="activiti" /><property name="password" value="activiti" /><property name="defaultAutoCommit" value="false" /></bean><bean id="processEngineConfiguration" class="org.activiti.engine.impl.cfg.StandaloneProcessEngineConfiguration"><property name="dataSource" ref="dataSource" />...</bean>⽆论使⽤JDBC还是DataSource,都可以设置下⾯的配置:databaseType:⼀般不⽤设置,因为可以⾃动通过数据库连接的元数据获取只有⾃动检测失败时才需要设置.可能的值有:{h2,mysql,oracle,postgres,mssql,db2}如果没使⽤默认的H2数据库就必须设置这项.这个配置会决定使⽤哪些创建/删除脚本和查询语句databaseSchemaUpdate: 设置流程引擎启动和关闭时如何处理数据库表false:默认, 检查数据库表的版本和依赖库的版本,如果版本不匹配就抛出异常true: 构建流程引擎时,执⾏检查,如果需要就执⾏更新. 如果表不存在,就创建create-drop: 构建流程引擎时创建数据库表,关闭流程引擎时删除这些表JNDI数据库配置在默认情况下,Activiti的数据库配置会放在web应⽤的WEB-INF/classes⽬录下的db.properties⽂件中. 这样做⽐较繁琐,因为要⽤户在每次发布时,都修改Activiti源码中的db.properties并重新编译war⽂件,或者解压缩war⽂件,修改其中的db.properties使⽤ JNDI(Java命名和⽬录接⼝) 来获取数据库连接,连接是由servlet容器管理的,可以在war部署外边管理配置. 与db.properties相⽐,它也允许对连接进⾏更多的配置JNDI的使⽤Activiti Explorer和Activiti Rest应⽤从db.properties转换为使⽤JNDI数据库配置:需要打开原始的Spring配置⽂件:activiti-webapp-explorer/src/main/webapp/WEB-INF/activiti-standalone-context.xmlactiviti-webapp-rest2/src/main/resources/activiti-context.xml删除dbProperties和dataSource两个bean,然后添加如下bean：<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean"><property name="jndiName" value="java:comp/env/jdbc/activitiDB"/></bean>我们需要添加包含了默认的H2配置的context.xml⽂件如果已经有了JNDI配置,会覆盖这些配置.对应的配置⽂件activiti-webapp-explorer2/src/main/webapp/META-INF/context.xml:<?xml version="1.0" encoding="UTF-8"?><Context antiJARLocking="true" path="/activiti-explorer2"><Resource auth="Container"name="jdbc/activitiDB"type="javax.sql.DataSource"scope="Shareable"description="JDBC DataSource"url="jdbc:h2:mem:activiti;DB_CLOSE_DELAY=1000"driverClassName="org.h2.Driver"username="sa"password=""defaultAutoCommit="false"initialSize="5"maxWait="5000"maxActive="120"maxIdle="5"/></Context>如果是Activiti REST应⽤,则添加activiti-webapp-rest2/src/main/webapp/META-INF/context.xml:<?xml version="1.0" encoding="UTF-8"?><Context antiJARLocking="true" path="/activiti-rest2"><Resource auth="Container"name="jdbc/activitiDB"type="javax.sql.DataSource"scope="Shareable"description="JDBC DataSource"url="jdbc:h2:mem:activiti;DB_CLOSE_DELAY=-1"driverClassName="org.h2.Driver"username="sa"password=""defaultAutoCommit="false"initialSize="5"maxWait="5000"maxActive="120"maxIdle="5"/></Context>最后删除Activiti Explorer和Activiti Rest两个应⽤中不再使⽤的db.properties⽂件JNDI的配置JNDI数据库配置会因为使⽤的Servlet container不同⽽不同Tomcat容器中的JNDI配置如下:JNDI资源配置在CATALINA_BASE/conf/[enginename]/[hostname]/[warname].xml(对于Activiti Explorer来说,通常是在CATALINA_BASE/conf/Catalina/localhost/activiti-explorer.war) 当应⽤第⼀次发布时,会把这个⽂件从war中复制出来.所以如果这个⽂件已经存在了,需要替换它.修改JNDI资源让应⽤连接mysql⽽不是H2:<?xml version="1.0" encoding="UTF-8"?><Context antiJARLocking="true" path="/activiti-explorer2"><Resource auth="Container"name="jdbc/activitiDB"type="javax.sql.DataSource"description="JDBC DataSource"url="jdbc:mysql://localhost:3306/activiti"driverClassName="com.mysql.jdbc.Driver"username="sa"password=""defaultAutoCommit="false"initialSize="5"maxWait="5000"maxActive="120"maxIdle="5"/></Context>Activiti⽀持的数据库h2: 默认配置的数据库mysqloraclepostgresdb2mssql创建数据库表创建数据库表的⽅法:activiti-engine的jar放到classpath下添加对应的数据库驱动把Activiti配置⽂件(activiti.cfg.xml)放到classpath下,指向你的数据库执⾏DbSchemaCreate类的main⽅法SQL DDL语句可以从Activiti下载页或Activiti发布⽬录⾥找到,在database⼦⽬录下.脚本也包含在引擎的jar中:activiti-engine-x.jar在org/activiti/db/create包下,drop⽬录⾥是删除语句- SQL⽂件的命名⽅式如下:[activiti.{db}.{create|drop}.{type}.sql]type 是:- engine:引擎执⾏的表,必须- identity:包含⽤户,群组,⽤户与组之间的关系的表.这些表是可选的,只有使⽤引擎⾃带的默认⾝份管理时才需要- history:包含历史和审计信息的表,可选的.历史级别设为none时不会使⽤. 注意这也会引⽤⼀些需要把数据保存到历史表中的功能数据库表名理解Activiti的表都以ACT_开头, 第⼆部分是表⽰表的⽤途的两个字母标识.⽤途和服务的API对应ACT_RE_*: RE表⽰repository. 这个前缀的表包含了流程定义和流程静态资源ACT_RU_*: RU表⽰runtime. 这些是运⾏时的表,包含流程实例,任务,变量,异步任务等运⾏中的数据. Activiti只在流程实例执⾏过程中保存这些数据，在流程结束时就会删除这些记录.这样运⾏时表可以⼀直很⼩速度很快ACT_ID_*: ID 表⽰identity. 这些表包含⾝份信息. ⽐如⽤户,组等等ACT_HI_*: HI 表⽰history. 这些表包含历史数据. ⽐如历史流程实例, 变量,任务等等ACT_GE_*: 通⽤数据. ⽤于不同场景下数据库升级在执⾏更新之前要先使⽤数据库的备份功能备份数据库默认情况下,每次构建流程引擎时都会进⾏版本检测.这⼀切都在应⽤启动或Activiti webapp启动时发⽣.如果Activiti发现数据库表的版本与依赖库的版本不同,就会抛出异常对activiti.cfg.xml配置⽂件进⾏配置来升级:<beans ... ><bean id="processEngineConfiguration" class="org.activiti.engine.impl.cfg.StandaloneProcessEngineConfiguration"><!-- ... --><property name="databaseSchemaUpdate" value="true" /><!-- ... --></bean></beans>然后,把对应的数据库驱动放到classpath⾥.升级应⽤的Activiti依赖,启动⼀个新版本的Activiti指向包含旧版本的数据库,将databaseSchemaUpdate设置为true,Activiti会⾃动将数据库表升级到新版本当发现依赖和数据库表版本不通过时,也可以执⾏更新升级DDL语句也可以执⾏数据库脚本,可以在Activiti下载页找到启⽤Job执⾏器JobExecutor是管理⼀系列线程的组件,可以触发定时器(包含后续的异步消息).在单元测试场景下,很难使⽤多线程.因此API允许查询Job(ManagementService.createJobQuery) 和执⾏Job(ManagementService.executeJob),因此Job可以在单元测试中控制, 要避免与job执⾏器冲突,可以关闭它默认,JobExecutor在流程引擎启动时就会激活. 如果不想在流程引擎启动后⾃动激活JobExecutor,可以设置<property name="jobExecutorActivate" value="false" />配置邮件服务器Activiti⽀持在业务流程中发送邮件,可以在配置中配置邮件服务器配置SMTP邮件服务器来发送邮件配置历史存储Activiti可以配置来定制历史存储信息<property name="history" value="audit" />表达式和脚本暴露配置默认情况下,activiti.cfg.xml和Spring配置⽂件中所有bean 都可以在表达式和脚本中使⽤如果要限制配置⽂件中的bean的可见性,可以通过配置流程引擎配置的beans来配置ProcessEngineConfiguration的beans是⼀个map.当指定了这个参数,只有包含这个map中的bean可以在表达式和脚本中使⽤.通过在map中指定的名称来决定暴露的bean配置部署缓存因为流程定义的数据是不会改变的,为了避免每次使⽤访问数据库,所有流程定义在解析之后都会被缓存默认情况下,不会限制这个缓存.如果想限制流程定义缓存,可以添加如下配置<property name="processDefinitionCacheLimit" value="10" />这个配置会把默认的HashMap缓存替换成LRU缓存来提供限制. 这个配置的最佳值跟流程定义的总数有关,实际使⽤中会具体使⽤多少流程定义也有关也可以注⼊⾃定义的缓存实现,这个bean必须实现org.activiti.engine.impl.persistence.deploy.DeploymentCache接⼝<property name="processDefinitionCache"><bean class="org.activiti.MyCache" /></property>类似的配置有knowledgeBaseCacheLimit和knowledgeBaseCache, 它们是配置规则缓存的.只有流程中使⽤规则任务时才⽤⽇志从Activiti 5.12开始,所有⽇志(activiti,spring,,mybatis等等)都转发给slf4j允许⾃定义⽇志实现引⼊Maven依赖log4j实现,需要添加版本<dependency><groupId>org.slf4j</groupId><artifactId>slf4j-log4j12</artifactId></dependency>使⽤Maven的实例,忽略版本<dependency><groupId>org.slf4j</groupId><artifactId>jcl-over-slf4j</artifactId></dependency>映射诊断上下⽂Activiti⽀持slf4j的MDC功能, 如下的基础信息会传递到⽇志中记录:流程定义ID: mdcProcessDefinitionID流程实例ID: mdcProcessInstanceID分⽀ID: mdcexecutionId默认不会记录这些信息,可以配置⽇志使⽤期望的格式来显⽰它们,扩展通常的⽇志信息. ⽐如,通过log4j配置定义会让⽇志显⽰上⾯的信息:yout.ConversionPattern =ProcessDefinitionId=%X{mdcProcessDefinitionID}executionId=%X{mdcExecutionId}mdcProcessInstanceID=%X{mdcProcessInstanceID} mdcBusinessKey=%X{mdcBusinessKey} %m%n"当系统进⾏⾼风险任务,⽇志必须严格检查时,这个功能就⾮常有⽤,要使⽤⽇志分析的情况事件处理Activiti中实现了⼀种事件机制,它允许在引擎触发事件时获得提醒为对应的事件类型注册监听器,在这个类型的任何时间触发时都会收到提醒:可以添加引擎范围的事件监听器,可以通过配置添加引擎范围的事件监听器在运⾏阶段使⽤API添加event-listener到特定流程定义的BPMN XML中所有分发的事件,都是org.activiti.engine.delegate.event.ActivitiEvent的⼦类.事件包含type,executionId,processInstanceId和processDefinitionId. 对应的事件会包含事件发⽣时对应上下⽂的额外信息事件监听器实现实现事件监听器要实现org.activiti.engine.delegate.event.ActivitiEventListener.下⾯监听器的实现会把所有监听到的事件打印到标准输出中,包括job执⾏的事件异常:public class MyEventListener implements ActivitiEventListener {@Overridepublic void onEvent(ActivitiEvent event) {switch (event.getType()) {case JOB_EXECUTION_SUCCESS:System.out.println("A job well done!");break;case JOB_EXECUTION_FAILURE:System.out.println("A job has failed...");break;default:System.out.println("Event received: " + event.getType());}}@Overridepublic boolean isFailOnException() {// The logic in the onEvent method of this listener is not critical, exceptions// can be ignored if logging fails...return false;}}isFailOnException(): 决定了当事件分发时onEvent(..) ⽅法抛出异常时的⾏为返回false,会忽略异常返回true,异常不会忽略,继续向上传播,迅速导致当前命令失败当事件是⼀个API调⽤的⼀部分时(或其他事务性操作,⽐如job执⾏), 事务就会回滚当事件监听器中的⾏为不是业务性时，建议返回falseactiviti提供了⼀些基础的实现,实现了事件监听器的常⽤场景可以⽤来作为基类或监听器实现的样例org.activiti.engine.delegate.event.BaseEntityEventListener:这个事件监听器的基类可以⽤来监听实体相关的事件,可以针对某⼀类型实体,也可以是全部实体隐藏了类型检测,并提供了三个需要重写的⽅法:onCreate(..)onUpdate(..)onDelete(..)当实体创建,更新,或删除时调⽤对于其他实体相关的事件,会调⽤onEntityEvent(..)事件监听器的配置安装把事件监听器配置到流程引擎配置中,会在流程引擎启动时激活,并在引擎启动过程中持续⼯作eventListeners属性需要org.activiti.engine.delegate.event.ActivitiEventListener的队列通常,我们可以声明⼀个内部的bean定义,或使⽤ref引⽤已定义的bean.下⾯的代码,向配置添加了⼀个事件监听器，任何事件触发时都会提醒它，⽆论事件是什么类型:<bean id="processEngineConfiguration" class="org.activiti.engine.impl.cfg.StandaloneProcessEngineConfiguration">...<property name="eventListeners"><list><bean class="org.activiti.engine.example.MyEventListener" /></list></property></bean>为了监听特定类型的事件可以使⽤typedEventListeners属性它需要⼀个map参数map的key是逗号分隔的事件名或单独的事件名map的value是org.activiti.engine.delegate.event.ActivitiEventListener队列下⾯的代码演⽰了向配置中添加⼀个事件监听器,可以监听job执⾏成功或失败:<bean id="processEngineConfiguration" class="org.activiti.engine.impl.cfg.StandaloneProcessEngineConfiguration">...<property name="typedEventListeners"><map><entry key="JOB_EXECUTION_SUCCESS,JOB_EXECUTION_FAILURE" ><list><bean class="org.activiti.engine.example.MyJobEventListener" /></list></entry></map></property></bean>分发事件的顺序是由监听器添加时的顺序决定的⾸先,会调⽤所有普通的事件监听器(eventListeners属性),按照它们在list中的次序然后,会调⽤所有对应类型的监听器(typedEventListeners属性),对应类型的事件被触发运⾏阶段添加监听器通过API:RuntimeService, 在运⾏阶段添加或删除额外的事件监听器:/*** Adds an event-listener which will be notified of ALL events by the dispatcher.* @param listenerToAdd the listener to add*/void addEventListener(ActivitiEventListener listenerToAdd);/*** Adds an event-listener which will only be notified when an event occurs, which type is in the given types.* @param listenerToAdd the listener to add* @param types types of events the listener should be notified for*/void addEventListener(ActivitiEventListener listenerToAdd, ActivitiEventType... types);/*** Removes the given listener from this dispatcher. The listener will no longer be notified,* regardless of the type(s) it was registered for in the first place.* @param listenerToRemove listener to remove*/void removeEventListener(ActivitiEventListener listenerToRemove);运⾏阶段添加的监听器引擎重启后就消失流程定义添加监听器特定流程定义添加监听器:监听器只会监听与这个流程定义相关的事件以及这个流程定义上发起的所有流程实例的事件监听器实现:可以使⽤全类名定义引⽤实现了监听器接⼝的表达式配置为抛出⼀个message,signal,error的BPMN事件监听器执⾏⾃定义逻辑下⾯代码为⼀个流程定义添加了两个监听器:第⼀个监听器会接收所有类型的事件,它是通过全类名定义的第⼆个监听器只接收作业成功或失败的事件,它使⽤了定义在流程引擎配置中的beans属性中的⼀个bean<process id="testEventListeners"><extensionElements><activiti:eventListener class="org.activiti.engine.test.MyEventListener" /><activiti:eventListener delegateExpression="${testEventListener}" events="JOB_EXECUTION_SUCCESS,JOB_EXECUTION_FAILURE" /></extensionElements>...</process>对于实体相关的事件,也可以设置为针对某个流程定义的监听器,实现只监听发⽣在某个流程定义上的某个类型实体事件.下⾯的代码演⽰了如何实现这种功能:第⼀个例⼦:⽤于监听所有实体事件第⼆个例⼦:⽤于监听特定类型的事件<process id="testEventListeners"><extensionElements><activiti:eventListener class="org.activiti.engine.test.MyEventListener" entityType="task" /><activiti:eventListener delegateExpression="${testEventListener}" events="ENTITY_CREATED" entityType="task" /></extensionElements>...</process>entityType⽀持的值有:attachmentcommentexecutionidentity-linkjobprocess-instanceprocess-definitiontask监听抛出BPMN事件另⼀种处理事件的⽅法是抛出⼀个BPMN事件:只针对与抛出⼀个activiti事件类型的BPMN事件, 抛出⼀个BPMN事件,在流程实例删除时,会导致⼀个错误下⾯的代码演⽰了如何在流程实例中抛出⼀个signal,把signal抛出到外部流程(全局),在流程实例中抛出⼀个消息事件,在流程实例中抛出⼀个错误事件.除了使⽤class或delegateExpression, 还使⽤了throwEvent属性,通过额外属性,指定了抛出事件的类型<process id="testEventListeners"><extensionElements><activiti:eventListener throwEvent="signal" signalName="My signal" events="TASK_ASSIGNED" /></extensionElements></process><process id="testEventListeners"><extensionElements><activiti:eventListener throwEvent="globalSignal" signalName="My signal" events="TASK_ASSIGNED" /></extensionElements></process><process id="testEventListeners"><extensionElements><activiti:eventListener throwEvent="message" messageName="My message" events="TASK_ASSIGNED" /></extensionElements></process><process id="testEventListeners"><extensionElements><activiti:eventListener throwEvent="error" errorCode="123" events="TASK_ASSIGNED" /></extensionElements></process>如果需要声明额外的逻辑,是否抛出BPMN事件,可以扩展activiti提供的监听器类:在⼦类中重写isValidEvent(ActivitiEvent event), 可以防⽌抛出BPMN事件.对应的类是:org.activiti.engine.impl.bpmn.helper.MessageThrowingEventListenerorg.activiti.engine.test.api.event.SignalThrowingEventListenerTestorg.activiti.engine.impl.bpmn.helper.ErrorThrowingEventListener流程定义监听器注意点事件监听器只能声明在process元素中,作为extensionElements的⼦元素.监听器不能定义在流程的单个activity下delegateExpression中的表达式⽆法访问execution上下⽂,这与其他表达式不同(⽐如gateway).它只能引⽤定义在流程引擎配置的beans属性中声明的bean, 或者使⽤spring(未使⽤beans属性)中所有实现了监听器接⼝的spring-bean使⽤监听器的class属性时,只会创建⼀个实例.监听器实现不会依赖成员变量,是多线程安全的当⼀个⾮法的事件类型⽤在events属性或throwEvent中时,流程定义发布时就会抛出异常(会导致部署失败)如果class或delegateExecution由问题:类不存在,不存在的bean引⽤,或代理类没有实现监听器接⼝在流程启动时抛出异常在第⼀个有效的流程定义事件被监听器接收时所以要保证引⽤的类正确的放在classpath下,表达式也要引⽤⼀个有效的实例通过API分发事件Activiti我们提供了通过API使⽤事件机制的⽅法,允许触发定义在引擎中的任何⾃定义事件建议只触发类型为CUSTOM的ActivitiEvents.可以通过RuntimeService触发事件:/*** Dispatches the given event to any listeners that are registered.* @param event event to dispatch.** @throws ActivitiException if an exception occurs when dispatching the event or when the {@link ActivitiEventDispatcher}* is disabled.* @throws ActivitiIllegalArgumentException when the given event is not suitable for dispatching.*/void dispatchEvent(ActivitiEvent event);⽀持的事件类型引擎中每个事件类型都对应org.activiti.engine.delegate.event.ActivitiEventType中的⼀个枚举值事件名称事件描述事件类型ENGINE_CREATED监听器监听的流程引擎已经创建,准备好接受API调⽤ActivitiEvent ENGINE_CLOSED监听器监听的流程引擎已经关闭,不再接受API调⽤ActivitiEvent ENTITY_CREATED创建了⼀个新实体,实体包含在事件中ActivitiEntityEventENTITY_INITIALIZED 创建了⼀个新实体,初始化也完成了.如果这个实体的创建会包含⼦实体的创建,这个事件会在⼦实体都创建/初始化完成后被触发,这是与ENTITY_CREATED的区别ActivitiEntityEventENTITY_UPDATED更新了已存在的实体,实体包含在事件中ActivitiEntityEvent ENTITY_DELETED删除了已存在的实体,实体包含在事件中ActivitiEntityEvent ENTITY_SUSPENDED暂停了已存在的实体,实体包含在事件中.会被ProcessDefinitions,ProcessInstances和Tasks抛出ActivitiEntityEventENTITY_ACTIVATED激活了已存在的实体,实体包含在事件中.会被ProcessDefinitions,ProcessInstances和Tasks抛出ActivitiEntityEvent JOB_EXECUTION_SUCCESS作业执⾏成功,job包含在事件中ActivitiEntityEventJOB_EXECUTION_FAILURE作业执⾏失败,作业和异常信息包含在事件中ActivitiEntityEvent ActivitiExceptionEventJOB_RETRIES_DECREMENTED因为作业执⾏失败,导致重试次数减少.作业包含在事件中ActivitiEntityEvent TIMER_FIRED触发了定时器,job包含在事件中ActivitiEntityEventJOB_CANCELED取消了⼀个作业.事件包含取消的作业.作业可以通过API调⽤取消,任务完成后对应的边界定时器也会取消,在新流程定义发布时也会取消ActivitiEntityEventACTIVITY_STARTED⼀个节点开始执⾏ActivitiActivityEvent ACTIVITY_COMPLETED⼀个节点成功结束ActivitiActivityEvent ACTIVITY_SIGNALED⼀个节点收到了⼀个信号ActivitiSignalEventACTIVITY_MESSAGE_RECEIVED ⼀个节点收到了⼀个消息.在节点收到消息之前触发,收到后,会触发ACTIVITY_SIGNAL或ACTIVITY_STARTED, 这会根据节点的类型:边界事件,事件⼦流程开始事件ActivitiMessageEventACTIVITY_ERROR_RECEIVED ⼀个节点收到了⼀个错误事件.在节点实际处理错误之前触发, 事件的activityId对应着处理错误的节点.这个事件后续会是ACTIVITY_SIGNALLED或ACTIVITY_COMPLETE, 如果错误发送成功的话ActivitiErrorEventUNCAUGHT_BPMN_ERROR抛出了未捕获的BPMN错误.流程没有提供针对这个错误的处理器.事件的activityId为空ActivitiErrorEventACTIVITY_COMPENSATE⼀个节点将要被补偿.事件包含了将要执⾏补偿的节点id ActivitiActivityEvent VARIABLE_CREATED创建了⼀个变量.事件包含变量名,变量值和对应的分⽀或任务(如果存在)ActivitiVariableEvent VARIABLE_UPDATED更新了⼀个变量.事件包含变量名,变量值和对应的分⽀或任务(如果存在)ActivitiVariableEvent VARIABLE_DELETED删除了⼀个变量.事件包含变量名,变量值和对应的分⽀或任务(如果存在)ActivitiVariableEvent TASK_ASSIGNED任务被分配给了⼀个⼈员.事件包含任务ActivitiEntityEventTASK_CREATED创建了新任务.它位于ENTITY_CREATE事件之后.当任务是由流程创建时,这个事件会在TaskListener执⾏之前被执⾏ActivitiEntityEventTASK_COMPLETED 任务完成.它会在ENTITY_DELETE事件之前触发.当任务是流程⼀部分时,事件会在流程继续运⾏之前, 后续事件将是ACTIVITY_COMPLETE,对应着完成任务的节点ActivitiEntityEventTASK_TIMEOUT任务已超时.在TIMER_FIRED事件之后,会触发⽤户任务的超时事件,当这个任务分配了⼀个定时器的时候ActivitiEntityEventPROCESS_COMPLETED流程已结束.在最后⼀个节点的ACTIVITY_COMPLETED事件之后触发.当流程到达的状态,没有任何后续连线时,流程就会结束ActivitiEntityEvent MEMBERSHIP_CREATED⽤户被添加到⼀个组⾥.事件包含了⽤户和组的id ActivitiMembershipEvent MEMBERSHIP_DELETED⽤户被从⼀个组中删除.事件包含了⽤户和组的id ActivitiMembershipEventMEMBERSHIPS_DELETED 所有成员被从⼀个组中删除.在成员删除之前触发这个事件,所以他们都是可以访问的.因为性能⽅⾯的考虑,不会为每个成员触发单独的MEMBERSHIP_DELETED事件ActivitiMembershipEvent引擎内部所有ENTITY_* 事件都是与实体相关的,实体事件与实体的对应关系:[ENTITY_CREATED],[ENTITY_INITIALIZED],[ENTITY_DELETED]:AttachmentCommentDeploymentExecutionGroupIdentityLinkJobModelProcessDefinitionProcessInstanceTaskUserENTITY_UPDATED:AttachmentDeploymentExecutionGroupIdentityLinkJobModelProcessDefinitionProcessInstanceTaskUserENTITY_SUSPENDED, ENTITY_ACTIVATED:ProcessDefinitionProcessInstanceExecutionTask注意只有同⼀个流程引擎中的事件会发送给对应的监听器如果有很多引擎在同⼀个数据库运⾏,事件只会发送给注册到对应引擎的监听器.其他引擎发⽣的事件不会发送给这个监听器,⽆论实际上它们运⾏在同⼀个或不同的JVM中对应的事件类型都包含对应的实体.根据类型或事件,这些实体不能再进⾏更新(⽐如,当实例以被删除).可能的话,使⽤事件提供的EngineServices来以安全的⽅式来操作引擎.即使如此,也要⼩⼼的对事件对应的实体进⾏更新,操作没有对应历史的实体事件，因为它们都有运⾏阶段的对应实体。

开源工作流框架对比工作流是基于业务流程的一种模型，它可以把业务流程组织成一个具有逻辑和规则的模型，从而指导业务工作的进行。

开源工作流把工作流进行了合理化、科学化的设计与组织，使其更能够满足现在的业务需求。

开源工作流可以帮助实现业务目标，通过计算机进行文档的传递，其使用非常广泛。

目前国内主要有几种开源工作流框架，下面我们简单地对比一下，帮助大家更深刻地了解开源工作流：1.JBPM：要想了解JBPM，首先要了解JBPM的简单定义，JBPM是指业务流程管理，它包含了整个业务流程管理过程中的工作流与服务协作，是一种灵活的、开源的管理模式。

JBPM可以把一些复杂的业务流畅简单化，让系统更加灵活运行，同时也很方便业务的跟踪、监控和管理，是一种很好的业务工作流框架模式。

2.OSWORKFLOW：这种框架是用java语言编写出来的，简单地说就是一种工作流引擎，其技术性非常强，它能满足用户多方面的需求。

用户可以根据自己的需要来设计一些简单或者是复杂的工作流，为企业业务流程管理服务。

这种工作流最大的优点是灵活简单，比较容易实现，能够满足当前市场对开源工作流的需求。

3.oa办公软件系统：这种工作流是符合相关标准的系统管理工作流软件，它也是由java编写出来的，其扩展性比较强，功能也多，还具有通用性的特点，可以用于完整的工作流管理系统中。

要说这种软件最大的特点，就是其功能模块比较多，比如说动态表单、可视化工作表、智能报表等等，不同的功能表可以帮助用户实现不同的功能，受到了用户的好评。

以上就是现在市场上比较常见的几种开源工作流管理模式，由此可见，不同的工作流模式其优势特点是不同的，不过这些工作流都能给企业业务流程管理起到一个很好的效果，受到了很多企业的欢迎。

在这几种工作流模式中，最值得一提的是JBPM，这种工作流是目前比较先进的，已经收到了很多企业的信赖。

开源automl框架效果评测与思考自动化机器学习(AutoML) 是一种快速生成高性能机器学习模型的方法，它能够自动执行数据预处理、特征选择、特征工程、超参数优化等一系列机器学习过程。

AutoML 框架可以解决许多ML 工程师面临的问题，例如减少繁琐工作、加速模型构建和优化、提高模型质量等。

目前已有许多开源的AutoML 框架可供选择。

但是，每个AutoML 框架都具有其优缺点，对于用户而言选择适合自己需求的AutoML 框架十分重要。

因此，对AutoML 框架的效果进行评测是十分必要的。

下面介绍几种常见的AutoML 框架及其效果评测。

1. TPOTTPOT (Tree-based Pipeline Optimization T ool) 是一款基于遗传算法和决策树的开源自动机器学习框架。

该框架允许用户定义评估标准和超参数搜索空间，以便为给定的数据集生成高质量模型。

TPOT 还提供了一些预处理和特征选择工具，以确保数据集的正确性。

在多个基准测试中，TPOT 用于生成分类和回归模型，其表现通常超过了手工编码模型。

2. Auto-sklearnAuto-sklearn 是一个基于Python 的AutoML 工具，它使用贝叶斯优化和元学习技术自动搜索最佳的机器学习模型和超参数。

该框架支持分类、回归、多标签分类和时间序列预测任务的解决，并具备超过15 个基于scikit-learn 的机器学习模型。

Auto-sklearn 与比较模型之间的比较表明，它在广泛的数据集上具有竞争力和高效性。

3. H2O.ai开源H2O.ai 是一个企业级AutoML 框架，提供了多种机器学习算法、超参数优化和特征选择等功能。

H2O.ai 可用于大规模数据集和分布式计算。

H2O.ai 提供了Python、R 和Java API，构建高性能机器学习工作流是非常便捷的。

H2O.ai 被广泛应用在许多领域，例如保险、医疗保健、零售和金融行业。

国内外主流工作流引擎及规则引擎分析近年来，随着信息技术的高速发展和应用需求的增加，工作流引擎和规则引擎已成为企业信息化建设的重要组成部分。

相比于传统的人工操作，工作流引擎可以通过自动化和流程化的方式提高企业的工作效率和质量，规则引擎则可通过规则的自动验证和执行帮助企业实现业务流程的自动化处理。

本文将着重对国内外主流的工作流引擎和规则引擎进行分析。

一、国际主流工作流引擎1.1 ActivitiActiviti 是一个开源工作流管理系统，最初由Alfresco 软件公司开发。

Activiti 使用Java语言编写，采用Spring和Hibernate框架，并且允许开发人员使用BPMN 2.0 规范来定义工作流程。

Activiti 支持分布式部署，具有良好的可扩展性和高度的灵活性。

1.2 jBPMjBPM 是一个基于开放标准的开源业务流程管理系统，也是一个部分Java Business 的资深技术。

jBPM 使用BPMN 2.0 规范的建模语言来设计和实现业务流程，并采用面向服务的架构，使其能够处理非常复杂的流程。

1.3 CamundaCamunda 是一个开源工作流引擎，可以轻松地实现工作流程的自动化。

Camunda 使用BPMN 2.0 规范和DMN 规范来定义工作流程和规则，其支持分布式环境下的各种操作。

二、国内主流工作流引擎2.1 艾森格艾森格是一家专业的工作流引擎厂商，艾森格的工作流引擎具有高效性、可靠性以及良好的易用性。

艾森格工作流引擎支持分布式环境，可应用于企业级内部流程处理。

2.2 WeBWorkFlowWeBWorkFlow是一家国内比较优秀的工作流引擎厂商，支持多种操作系统（Linux、Windows等），支持HTTP 与TCP 协议的交互，并具有非常好的任务调度、安全性等特性。

2.3 宁波欧格软件宁波欧格软件是一家专业从事OEM服务的缔造者，欧格工作流引擎能够简化和优化所有流程，并为流程提供统一的管理平台。

工作流开源框架JBPM：简介Java Business Process Management(业务流程管理)，覆盖了业务流程管理、工作流、服务协作等领域的一个开源的、灵活的。

Jbpm是公开开源代码项目，它使用要遵循Apache License.Jbpm在2004年10月18日，发布了2.0版本，并在同一天加入了Jboss，成为了Jboss企业中间件平台的一个组成部分，jbpm也进入了一个全新的发展时代。

优势将业务流程复杂的系统结构清晰化，提供系统运行的灵活性解耦系统业务流程（流程独立，可以使用工具定义和建模，利于跟踪、监控、管理、调度、优化和重整）提供系统的灵活性(系统流程定义生产环境的修改和调整，用户和外部工具交互，任务的动态分派)使用使用简单，易上手，源代码也易读，作嵌入式工作流是一个很好的选择OSWORKFLOW：简介完全用java语言编写的开放源代码的工作流引擎，具有显著的灵活性及完全面向有技术背景的用户的特点。

用户可以根据自身的需求利用这款开源软件设计简单或是复杂的工作流。

优势绝对的灵活性、较为简单的和灵活的实现方式不足非标准脚本语言，工作流引擎对于自动任务支持尚不完善OpenWFE：简介John Mettraux所领导的项目组开发的一套符合WFMC标准的工作流管理系统组件。

项目使用JAVA语言编写，具有功能完善、通用型好、扩展能力强等特点。

其除了能够为各种开发环境提供一个符合要求的工作流引擎之外，也能够直接作为一个完整有效的工作流管理系统进行使用。

其主要功能模块包括优势可视化工作流、动态表单、智能报表, 丰富的应用模板开源工作流产品占有率趋势2004年前，国内的工作流引擎使用率最高的是osworkflow到2004年底，Shark就占有了明显的优势地位，分析有如下原因：国内的企业都看中XPDL，因为这意味着在产品说明书中又可以吹牛说“我们遵循WFMC……”Shark的确是一套不错的工作流引擎，就算你只是想学习XPDL，你也可以从学习Shark开始jbpm3支持bpel4ws的核心部分。

三大工作流引擎对比1．从《功夫》说起时下的新新人类看到我，一定会认为在下是个十足的老古董，这不，《功夫》这样的片子我到今年2月底才看。

不过看过《功夫》，我想的一定比一般的人多：周星星浪迹江湖，和他胖子大哥出去敲竹杆时，为什么要他大哥胸前画两把斧头？找个假靠山呗！装是斧头帮的人才不会被人欺负啊。

这让我想到年前的一则新闻：jbpm joins jboss and becomes jb oss-jbpm。

也就是说了，jbpm找了个靠山jboss，以后不用自己在外流浪了。

好，我们转入正题，谈这里说的三大主流开源工作流引擎：Shark, osworkflow,jbpm。

Shark的靠山是Enhydra。

Enhydra做过什么呢？多了！从j2ee 应用服务器，到o/r mapping工具，到这个工作流引擎等等。

为什么Shark的持久层采用DODS来实现？就是因为他们是一家人。

Jbpm的靠山是jboss。

Jbpm3的持久层采用hibernate3来实现，也是因为这个原因吧。

Jbpm3的图形化流程定义已经决定嵌入到jbos s eclipse IDE中，大家看看jboss eclipse IDE preview 1.5版，我们已经可以用插件方式编辑一个jbpm3流程定义文件了。

Osworkflow的靠山是opensymphony。

我是非常喜欢这个组织的，它做出了很多的好东西。

在开发工作流管理系统时，我就推荐用它的另外一个东西：webwork2。

笔者主持的开源工作流引擎AgileFl ow就是基于ww2+spring+hibernate架构实现的。

完成本段时说句题外话：现在基本上所有的J2EE应用程序服务器都有自己的工作流引擎，如上面提到的Enhydra,jboss和没有提到的websphere和weblogic等，可见，学习工作流引擎技术的确是非常重要的。

2．如来神掌光有靠山是不行的，周星星加入了斧头帮还不是被邪神打扁了头？要救自己，还是要靠如来神掌。