开源工作流框架对比.
工作流开发框架
工作流开发框架（原创版）目录1.工作流开发框架概述2.工作流开发框架的优点3.工作流开发框架的缺点4.如何选择适合自己的工作流开发框架5.结论正文1.工作流开发框架概述工作流开发框架是一种用于实现工作流（即一系列任务有序执行的过程）的软件工具。
工作流开发框架可以帮助开发者快速构建工作流应用，简化工作流实施过程，降低开发和维护成本。
工作流开发框架通常具有很好的扩展性和可定制性，可以根据实际需求进行自定义。
2.工作流开发框架的优点（1）提高开发效率：工作流开发框架提供了丰富的组件和 API，可以快速搭建工作流应用，减少重复开发工作。
（2）易于维护：工作流开发框架具有清晰的模块划分和良好的代码结构，便于进行代码维护和升级。
（3）灵活性高：工作流开发框架通常支持多种工作流模型和引擎，可以根据实际需求进行选择和切换。
（4）可扩展性强：工作流开发框架具有良好的扩展性，可以根据项目需求进行插件和功能的扩展。
3.工作流开发框架的缺点（1）学习成本：虽然工作流开发框架可以提高开发效率，但是对于初学者来说，需要花费一定的时间学习和熟悉框架的使用。
（2）兼容性问题：工作流开发框架可能会涉及到多种系统和平台，可能存在兼容性问题，需要进行额外的测试和调整。
4.如何选择适合自己的工作流开发框架在选择工作流开发框架时，需要考虑以下几个方面：（1）项目需求：根据项目的具体需求，选择适合的工作流模型和引擎。
（2）技术栈：考虑团队的技术栈和开发经验，选择易于上手和工作流开发框架。
（3）社区支持：选择具有良好社区支持的工作流开发框架，便于解决在使用过程中遇到的问题。
（4）扩展性：考虑工作流开发框架的扩展性，以便于后期功能的扩展和升级。
5.结论总的来说，工作流开发框架是一种提高开发效率、降低开发成本的工具。
在选择工作流开发框架时，需要综合考虑项目需求、技术栈、社区支持和扩展性等因素，选择适合自己的框架。
Java开源工作流对比
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的详细配置以及安装和使用
⼯作流引擎详解！⼯作流开源框架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 页，共 2 页
功能
53349265.xls 项目 任务分配：分配 给用户和岗位； 分配算法 会审 动态协作、代理 撤销，退回 JBPM 支持对用户和岗位分配任务，用户只能 处理自己的任务，可以获取所属的岗位 的任务集合，并添加到自己的任务队列 中，如果需要退回给岗位中的其他人处 理，只需要把该任务的用户ID去掉。复 杂的分配算法需要自己实现。 可以在流程中配置，需要扩展实现 需要自己扩展实现 可以配置退回，撤销，复杂的需要扩展 实现 OsWorkflow Shark
53349265.xls 项目 服务商 标准 版本 开源 资源文档 学习成本 灵活性 扩展性 设计器 用户模型 后台服务 持久层
OpenWFE Shark Enhydra 1.完全基于WFMC和OMG规范的 基于有限状态机概念。 工作流 1.WFMC 状态转换通过Action 2.XPDL作为自己的过程定义语 2.流程文件为自定义 言 2.8.0 1.7.2与1.7.3per0 开源 2.0以后版本，部分组件不开 开源，BSD license 文档不是很详细，有较多网络资 相对较少 有使用文档,无源码API 有较多的配置，刚开始较难掌握 比较容易学习 学习成本高 shark1.0是一款纯粹的工作流 很灵活 很灵活 引擎，代码量较少，易于阅读 较灵活 、易于改写、易于维护。 扩展性好 扩展性好，但较为繁琐 模块间独立性很强，扩展性好 扩展性好 基于Eclipse的流程设计器 自带GUI设计器，Java编制 Jawe 基于Eclipse插件 自带简单的用户模型，可以扩展到自定 有自己的用户模型，可以扩展实 自己带用户模型 义的用户模型，用户变更需要处理在途 现 带后台管理服务，需要部署 带web后台处理工作列 支持内存、序列化、JDBC、EJB和 基于Hibernate的持久层，扩展自己的实 DODS作持久化存储工具,也许 Ofbiz存储，很容易扩展自己的实 JDBC xml存取 现比较复杂 在大量数据应用时会出现问题 现 JPDL/BPEL/PageFlow，流程定义清晰简 单，支持状态图、事件、任务、分配、 定义流程模型-定义流 通过配置XML文件来配置，也可以 客户自定义的java类作为流程 泳道、处理器、上下文环境变量、脚本 程参与者-定义存储区通过GUI设计器 变量来使用 、异步处理、日程管理配置、JCR文档管 定义流程-分配权限 理、异步同步消息、EMAIL 对外提供接口调用,支 调用接口简单 提供了很多方便的接口 持rmi 可以通过上下文环境和任务控制器，向 任务传递业务数据，系统自动保存流程 状态和上下文环境。如果业务信息量 大，可以只传递关键信息，通过这些信 息在从数据库中检索详细信息，展示给 需要修改代码，处理分页数据，复杂的 无 查询审批逻辑比较困难
工作流产品比较
对X5 Studio过分依赖，如果选择它的工作流，整个项目需要在其平台上开发。
用户自己的开发框架调用流程需要调用webService来实现，统计分析只支持系统里面创建的BO模型。
缺少流程效能分析，表单设计器不是很好用
报价单
链接地址
链接地址
链接地址
链接地址
详细了解
链接地址
中文
中文
国产化
是
是
是
是
数据库
oracle/db2/SQLServer/Sybase/Informix/Mysql
oracle/db2/SQLServer/Sybase/Informix/Mysql
oracle/db2/SQLServer/ /Mysql
Oracle/Mysql
工作流设计
器表现力
完全基于Flex/Flash的全图形化设计界面，易于理解，界面和操作非常简单，大部分业务逻辑的实现无需代码开发，eclipse中也可绘制流程。
X5提供自己的角色管理模块，也提供接口可自行扩展
有自己的角色管理模块，提供数据同步接口
必须使用提供的角色模块
优点
BPS与用户开发框架及集成开发环境可以高度融合，一方面以整合的开发环境开发，即保持了原来的开发模式与习惯，又能够方便的使用BPS的功能；另一方面，BPS提供标准的Java API，能够以多种协议与用户原有应用交互，更好的保护了原有资产，大大降低了应用开发和升级的成本。
X5平台提供了对数据的查询、统计、分析、挖掘的支持，能够完成多维、多项的数据统计分析，包括交叉表、统计表都实现
Aws提供数据库表对应表单，便于自己做统计分析。
Aws提供流程效能分析，还支持以多维度、多方案（BO统计图表、交叉表统计、SQL报表）表单数据统计分析。
开源工作流框架对比.
开源工作流框架对比工作流是基于业务流程的一种模型，它可以把业务流程组织成一个具有逻辑和规则的模型，从而指导业务工作的进行。
开源工作流把工作流进行了合理化、科学化的设计与组织，使其更能够满足现在的业务需求。
开源工作流可以帮助实现业务目标，通过计算机进行文档的传递，其使用非常广泛。
目前国内主要有几种开源工作流框架，下面我们简单地对比一下，帮助大家更深刻地了解开源工作流：1.JBPM：要想了解JBPM，首先要了解JBPM的简单定义，JBPM是指业务流程管理，它包含了整个业务流程管理过程中的工作流与服务协作，是一种灵活的、开源的管理模式。
JBPM可以把一些复杂的业务流畅简单化，让系统更加灵活运行，同时也很方便业务的跟踪、监控和管理，是一种很好的业务工作流框架模式。
2.OSWORKFLOW：这种框架是用java语言编写出来的，简单地说就是一种工作流引擎，其技术性非常强，它能满足用户多方面的需求。
用户可以根据自己的需要来设计一些简单或者是复杂的工作流，为企业业务流程管理服务。
这种工作流最大的优点是灵活简单，比较容易实现，能够满足当前市场对开源工作流的需求。
3.oa办公软件系统：这种工作流是符合相关标准的系统管理工作流软件，它也是由java编写出来的，其扩展性比较强，功能也多，还具有通用性的特点，可以用于完整的工作流管理系统中。
要说这种软件最大的特点，就是其功能模块比较多，比如说动态表单、可视化工作表、智能报表等等，不同的功能表可以帮助用户实现不同的功能，受到了用户的好评。
以上就是现在市场上比较常见的几种开源工作流管理模式，由此可见，不同的工作流模式其优势特点是不同的，不过这些工作流都能给企业业务流程管理起到一个很好的效果，受到了很多企业的欢迎。
在这几种工作流模式中，最值得一提的是JBPM，这种工作流是目前比较先进的，已经收到了很多企业的信赖。
开源automl框架效果评测与思考
开源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服务的缔造者，欧格工作流引擎能够简化和优化所有流程，并为流程提供统一的管理平台。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
开源工作流框架对比
工作流是基于业务流程的一种模型，它可以把业务流程组织成一个具有逻辑和规则的模型，从而指导业务工作的进行。
开源工作流把工作流进行了合理化、科学化的设计与组织，使其更能够满足现在的业务需求。
开源工作流可以帮助实现业务目标，通过计算机进行文档的传递，其使用非常广泛。
目前国内主要有几种开源工作流框架，下面我们简单地对比一下，帮助大家更深刻地了解开源工作流：
1.JBPM：要想了解JBPM，首先要了解JBPM的简单定义，JBPM是指业务流程管理，它包含了整个业务流程管理过程中的工作流与服务协作，是一种灵活的、开源的管理模式。
JBPM可以把一些复杂的业务流畅简单化，让系统更加灵活运行，同时也很方便业务的跟踪、监控和管理，是一种很好的业务工作流框架模式。
2.OSWORKFLOW：这种框架是用java语言编写出来的，简单地说就是一种工作流引擎，其技术性非常强，它能满足用户多方面的需求。
用户可以根据自己的需要来设计一些简单或者是复杂的工作流，为企业业务流程管理服务。
这种工作流最大的优点是灵活简单，比较容易实现，能够满足当前市场对开源工作流的需求。
3.oa办公软件系统：这种工作流是符合相关标准的系统管理工作流软件，它也是由java编写出来的，其扩展性比较强，功能也多，还具有通用性的特点，可以用于完整的工作流管理系统中。
要说这种软件最大的特点，就是其功能模块比较多，比如说动态表单、可视化工作表、智能报表等等，不同的功能表可以帮助用户实现不同的功能，受到了用户的好评。
以上就是现在市场上比较常见的几种开源工作流管理模式，由此可见，不同的工作流模式其优势特点是不同的，不过这些工作流都能给企业业务流程管理起到一个很好的效果，受到了很多企业的欢迎。
在这几种工作流模式中，最值得一提的是JBPM，这种工作流是目前比较先进的，已经收到了很多企业的信赖。