毫末工作流引擎方案

官网：https://haomo-tech.com

作者：毫末科技

邮箱：hxg@haomo-studio.com

1 引擎简介

毫末工作流引擎，基于Flowable，覆盖流程设计，建模，审批，跟踪，统计等多场景化流程管控，私有化部署。整合企业业务系统ERP/CRM及财务系统数据，实现跨系统的流程运转和业务协作。可用用在企业OA、CRM、ERP、政务信息化等相关行业领域，具备很好的扩展性和开放性。

工作流在企业管理系统中是高频使用的功能，一个最常见的例子是请假加班申请与审批的过程。事实上，工作流引擎能支持的业务场景远远不止单据审批，几乎所有涉及到业务流转、多人按流程完成工作的场景背后都可以通过工作流引擎作为支撑。基于工作流引擎，可以搭建客户关系管理系统（CRM）、运输管理系统（TMS）、仓储管理系统（WMS）、财务费用系统等多种复杂业务系统。对于达到一定规模的企业，良好的 BPM（业务流程管理，Business Process Management）体系可以支持创建公司内横跨不同部门的复杂业务流程，既提高工作效率、又可推动企业规范化发展。

2 界面预览

3 平台特点

基于 Flowable（Activiti）生来具有的稳定工作流引擎。
使用flowable官方流程设计器，功能强大，操作熟悉。
支持流程导入导出，符合BPMN规范，中国式工作流。
在线流程表单设计器，免去繁琐的表单开发步骤。
支持流程发起、任务办理、保存、指定、追踪、退回、跳转、委托、转办、终止、挂起、加签、减签等功能。
任务退回支持退回到任意历史节点，兼容并行网关、子流程等。
任务审批支持指定下一审批人、任务期限、优先级等。
任务跳转可自由跳转到指定节点，满足特事特办的需求。
任务加签、减签可动态为会签、或签任务临时增加、减少签核人员。
任务委托可将任务委托给他人，他人办理完成后再回到委托人。
支持流程跟踪图，流程状态展现，流转信息，任务历史，任务分配信息。
支持表单挂载，全局表单，节点表单。
支持流程事件脚本在线编写，包括：流程启动、完成、取消；任务分配、创建、结束等。
支持智能提交，相同处理人自动跳过，自动完成第一个任务。
版本化管理流程，新调整的流程业务不影响正在运行，未结束的流程继续流转。
流程在线监控，运行中、已结束的流程掌控在手，可将运行中流程挂起、终止。
完善的审批记录机制，每一步审批操作都进行详实的记录。
强大的建模器，支持自定义图标、图形化方式模型校验，看起来更加的清晰直观。
业务化的属性设置，因此在使用毫末工作流引擎的时候，无需过多的BPM专业知识，即可达到人人都可以设计成一个业务流程。
流程模拟器，业务建模师在建模完毕之后，无需部署、启动操作。只需要点击”模拟运行“按钮，即可快速了解流程的最终走向，这样可以将”死“或者”错误“流程绘制的概率降到最低。已于此功能，业务建模师使用毫末工作流引擎的时候，会感觉非常的流畅，不怕担心绘制错误，重复修改流程。
模型绘制日志记录，在建模的时候，引擎会记录每一个环节的耗时情况，工具面板的使用占比，这样既可以统计出不同业务系统对于BPM元素的使用情况，也可以记录业务建模的耗时情况，从而定制一套专门属于自己业务场景的建模器。建模优化建议：当业务建模师绘制完毕一个流程之后，可以点击校验按钮，毫末工作流引擎会罗列出一系列的验证信息和优化建议，这样尽可能的使模型在满足业务的同时，也最大程度的满足BPM2.0标准。
加签和会签可以再运行的时候动态进行操作。在中国式流程中，可能会在实例运转的过程中，动态的添加普通节点、传阅节点或者会签节点，为此毫末工作流引擎推出了一套完整的加签机制，以此支撑更复杂的业务场景。
任意跳转，毫末工作流引擎目前结合几大家国企、央企的需求，实现了完整的一套任意跳转节点机制，支持并行内的跳转，并行内外的跳转，子流程的内外跳转以及常规的跳转特性。
指哪到哪机制，在使用毫末工作流引擎的时候，可以再完成当前节点的同时，自由选择流程可以到达的下一个节点，从而满足各种业务场景。
动静集合机制，BPM2.0标准采用的是预先设计机制，因为在业务建模的时候需要考虑各种的场景进行建模，从而导致模型非常的臃肿和繁琐，为此毫末工作流引擎采用了动静结合机制，大部分固定的场景可以在模型中体现，少部分变化的地方采用在运行的时候进行设置。比如一个请假流程，根据请假人的岗位来决定到底是哪一级领导来审核，发起人节点和顶级领导节点为固定的，如果发起人是三级部门员工，则二级部门和一级部门都要审核，如果发起人是二级部门源，则只需要一级部门领导审核，三级部门领导无需参与审核。因此三级部门-一级部门内是不确定的，可以采用运行时计算方式完成该次建模。
表单建模器，传统的审批流，往往以表单的流动为视角进行流转，因此毫末工作流引擎使用了表单设计器，可以方便建模师快速设计出一套贴合业务的表单。
流程监控功能，模型监控、定义监控、实例监控、任务监控以及实例相关实体监控。
流程实例的迁移，用户可以在不同的实例之间进行数据的迁移，比如a流程运转了一段时间之后，添加了新的节点，旧的实例还没有完全结束，则可以让旧的实例迁移到最新版本的新节点，从而无缝升级。
动态化属性调整，可以在不升级流程版本的情况下，进行节点属性的调整，比如修改修改任务节点的处理人、名称之类的，没有升级模板的必要。
批处理，支持批量删除实例、批量完成任务。
支持跨数据库平台，开发者所需工作减少到最小，目前跨数据库支持mysql，postgres，oracle，sqlserver，h2，sqllite，DB2，也支持国产数据库达梦等。
高性能
支持DMN最新1.3标准。（包括决策表、drd，grd等）
支持CMMN最新的1.1标准。
支持引擎内核监控，包含引擎所执行的SQL/链路、内核CMD等。
支持自动化流程
支持任意添加节点
支持任意跳转
支持BPM全访问监控。
支持在途实例批量迁移到新版本。
支持批量完成任务。
支持国产化运行环境
支持任务池子，从繁琐的加签（节点）操作转换为自由任务。性能更好也更灵活。类似“一动一静”。模型不变，运行的时候每一个节点都可以转换为容器节点任意流程。
支持在线流程设计器，流程导入导出，符合 BPMN 规范，中国式工作流
支持流程办理、退回、自由流、会签、并行、串行、服务任务等
支持退回任务，退回到指定环节，退回到上一步，退回到发起人
支持转办任务，将任务交接给他人办理，办理完成后继续下一步骤
支持委托任务，将任务委托给他人，他人办理完成后再回到委托人
支持智能提交，相同处理人自动跳过，支持自由指定下一步处理人
支持作废流程，允许发起人快速终止流程，管理员维护终止流程
支持自由流程，根据环节选择，自由跳转到指定环节，特事特办
支持流程撤回，下一步未办理的任务，可进行取回撤销重做任务
支持流程跟踪图，流程状态展现，流转信息，任务历史，任务分配信息
支持一个流程模型挂接多个业务单据，如某公司8种费用审批流程，表单不一样，但流程相同
支持一个表单挂接多个流程环节，以表单角度去管理流程，方便业务理解
流程事件脚本在线编写，包括：流程启动、完成、取消；任务分配、创建、结束等
流程脚本管理（Groovy、Beetl），在线编辑、自动完成、脚本测试、多语言脚本模板维护
我的待办任务处理，我的已办任务、我创建的任务查询、流程跟踪、审批记录查询
流程管控，在无关联表单情况下流程调试，如流程发起、挂起；流程定义、实例、任务等查询；任务办理等
支持流程组件标签定义（流程按钮、意见审批、下一步流程信息等）快速与自定义的业务表单建立关系。
版本化管理流程，新调整的流程业务不影响正在运行，未结束的流程继续流转。
计划：任务加签、催办任务、传阅任务、流程委托设置、流水号管理、常用语管理

4 技术架构

毫末工作流引擎，后端采用SpringBoot + Flowable技术，前端采用Vue技术。

后端结合了Flowable、Redis、消息队列等多种主流技术框架，并提供了开放的API接口供低代码平台或三方平台调用；
前端采用主流的Vue技术，并结合AntV X6流程图绘制、表单构建等多种美观风格的界面元素，提供了人性化的交互界面；同时，所有的模块均采用组件化的方式开发，可以方便在低代码平台进行拖拽使用；

4.1 功能架构

工作流引擎，按照业务功能进行划分，可以划分成四大部分：流程模型管理、业务管理、任务管理和通知管理。下图为工作流按照业务功能进行的划分。

按照技术进行划分，可以划分为：流程引擎、CMMN案例模型引擎、DMN决策引擎、表单引擎、流程监控、通知引擎等模块。

4.2 解耦架构

为了实现工作流引擎模块间的解耦，实现引擎的高扩展性和高内聚性，将工作流管理模块和业务调度模块实现了分离，为将来支持更多流程相关的功能打下良好的基础。结构模块如下图所示。

4.3 其他架构图

模型架构

5 功能模块

5.1 流程设计器

业务流程引擎支持如下类型的流程元素：

事件：事件（event）通常用于为流程生命周期中发生的事情建模。在 BPMN 2.0中，有两种主要的事件分类：捕获（catching）与抛出（throwing）事件。捕获事件为当流程执行到达这个事件时，会等待直到触发器动作。抛出事件当流程执行到达这个事件时，会触发一个触发器。具体事件包括定时器事件、启动事件、结束事件、消息事件、信号事件、边界事件等丰富类型。
顺序流：顺序流（sequence flow）是流程中两个元素间的连接器。在流程执行过程中，一个元素被访问后，会沿着其所有出口顺序流继续执行。这意味着BPMN 2.0的默认是并行执行的：两个出口顺序流就会创建两个独立的、并行的执行路径。顺序流上定义条件（conditional sequence flow）时为条件顺序流。当离开 BPMN 2.0活动时，默认行为是计算其每个出口顺序流上的条件。当条件计算为true时，选择该出口顺序流。如果该方法选择了多条顺序流，则会生成多个执行，流程会以并行方式继续。但这种情况并不适用于网关（gateway），不同类型的网关，会用不同的方式处理带有条件的顺序流。所有的BPMN 2.0任务与网关都可以使用默认顺序流（default sequence flow）。只有当没有其他顺序流可以选择时，才会选择默认顺序流作为活动的出口顺序流。流程会忽略默认顺序流上的条件。
网关：网关（gateway）用于控制执行的流向，可类比路口的分叉来理解。如按BPMN 2.0 的用词也即是执行的「标志（token）」。网关可以消费（consuming）与生成（generating）标志。网关可细分为下列类型：
排他网关（exclusive gateway）：也叫异或网关（XOR gateway），或者基于数据的排他网关（exclusive data-based gateway），用于对流程中的决策建模。当执行到达这个网关时，会按照所有出口顺序流定义的顺序对它们进行计算。选择第一个条件计算为 true 的顺序流（当没有设置条件时，认为顺序流为true）继续流程。使用排他网关时，只会选择一条顺序流。当多条顺序流的条件都计算为true时，会且仅会选择在XML中最先定义的顺序流继续流程。
并行网关：并行网关不计算条件，如果连接到并行网关的顺序流上定义了条件，会直接忽略该条件。并行网关（parallel gateway）可以将执行分支（fork）为多条路径，也可以合并（join）多条入口路径的执行，并行网关的功能取决于其入口与出口顺序流。如果并行网关同时具有多条入口与出口顺序流，可以同时具有分支与合并的行为。在这种情况下，网关首先合并所有入口顺序流，然后分裂为多条并行执行路径。
包容网关：可看做排他网关与并行网关的组合。与排他网关一样，可以在包容网关的出口顺序流上定义条件，包容网关会计算条件。然而主要的区别是，包容网关与并行网关一样，可以同时选择多于一条出口顺序流。包容网关的汇聚行为比并行网关更复杂。
基于事件的网关：基于事件的网关（event-based gateway）提供了根据事件做选择的方式。网关的每一条出口顺序流都需要连接至一个捕获中间事件。一个基于事件的网关，必须有两条或更多的出口顺序流。
任务：Flowable 支持的任务类型超过十五种。
用户任务：用于对需要人工执行的任务进行建模。当流程执行到达用户任务时，会为指派至该任务的用户或组的任务列表创建一个新任务。用户任务允许标识到期日期以及直接指派给用户。
邮件任务：Flowable 引擎可以向一个或多个收信人发送邮件，支持 cc、bcc、HTML 文本等等，使用支持 SMTP 的外部邮件服务器发送邮件。
业务规则任务：业务规则任务（business rule task）用于同步地执行一条或多条规则。在 V6.3.0 到 V6.4.1 版本中，Flowable 使用名为 Drools Expert 的 Drools 规则引擎执行业务规则。截至 V6.4.1 版本，业务规则中包含的 .drl 文件，必须与定义了业务规则服务并执行规则的流程定义一起部署。这意味着流程中使用的所有 .drl 文件都需要打包在流程 BAR 文件中，与任务表单等类似。由于 Flowable 自己的规则引擎 DMN 功能逐渐完善，对业务规则任务的支持可能会在后续版本中变动，具体要看 Flowable 官方更新文档。
其他的任务类型还有脚本任务、Web 服务任务、Shell 任务、Java 服务任务、执行监听器、任务监听器等。子流程与调用活动：子流程（sub-process）是包含其他的活动、网关、事件等的活动。其本身构成一个流程，并作为更大流程的一部分。子流程完全在父流程中定义（所以也称作嵌入式子流程）。在复杂流程流转的场景下中子流程较为多见，使用这一特性可以比较灵活地维护包含子流程的审批路径。
调用活动（call activity）有别于一般的子流程，调用活动引用一个流程定义外部的流程，而子流程嵌入在原有流程定义内。调用活动的主要使用场景是，在多个不同流程定义中调用一个可复用的流程定义。

5.2 表单设计器

采用Flowable外部表单模式。表单设计器截图如下：

可视化表单拖拽
支持各种表单复杂布局方案
高性能，字段分布式渲染
支持多种UI组件框架，能设计出丰富、美观的表单界面

5.3 CMMN 案例模型引擎

CMMN 是 Case Management Model 的缩写，在 Flowable Modeler 应用中体现为「案例模型」菜单，使用时可以类似于流程引擎可视化配置流程，也可通过XML格式文件。CMMN（Case Management Model and Notation）行业标准 V1.1 版本于2016年发布，目前 Flowable 的 V6.4.1 已支持此标准。与 BPMN 引擎相比，CMMN 引擎适用于如下几种场景：

（1）重复与并行的工作分发。BPMN 引擎在处理顺序执行、职责分工明确的工作流程时有优势，但面对动态、自由、并行的情况时，BPMN 显得灵活性不足，此时CMMN 则更适合应对。
（2）处理带有生命周期特征的场景，如客户、产品、项目、雇员。以项目为例，项目的立项、中止、收尾、交付等阶段（phases），可以在 CMMN 中通过阶段（Stages）概念在更高层次进行描述。

CMMN 中一个案例模型呈现为一个公文夹的样式。每个案例模型都包含一个用于安置计划元素的「计划模型」，每个计划元素包含一个明确其类型和可能配置选项的计划元素定义，常见计划元素如用户任务（human task）、里程碑（milestone）、流程任务（process task）、案例任务（case task）和阶段（stage）。例如下图中的计划模型包含三个用户任务计划项和一个里程碑。

Flowable CMMN 引擎支持如下类型的案例元素：

阶段（Stage）：阶段用于把一组元素聚合在一起，可以有进入和退出的条件。阶段可以嵌套，一个阶段中的计划元素只有其父阶段激活时才生效。
任务（Task）：任务是发生于引擎外部的事件，包含名称、阻塞（决定任务是否阻塞的布尔值）、阻塞表达式（表达式的布尔值决定任务是否阻塞）等属性。
用户任务（Human task）：通常指需要用户通过表单执行的手动任务，包含一系列属性。
里程碑（Milestone）：里程碑标识某一具体案例到达特定点。
案例任务（Case task）：案例可以嵌套，案例中的子案例就是案例任务。
流程任务（Process task）：当流程任务阻塞时，实例化的计划要素会处于激活状态，直至流程任务完成。
条件（Criteria）：分为进入条件和退出条件。
决策任务（Decision task）：调用 DMN 引擎中的决策表。
HTTP任务、脚本任务、Java 服务任务、时间监听器等：与 BPMN 中的相应元素含义相近，不再赘述。

5.4 DMN 决策引擎

DMN 定义由决策(decision)和其他东西组成，决策由表达式描述。DMN 标准描述了几种表达式的类型，目前在 Flowable DMN 中仅支持决策表(decision table)类型的表达式。决策表分为输入表达式与输出表达式两个主要区域。在输入表达式中，可以定义变量，用于规则输入项(input entries)的表达式。可以通过选择Add Input(添加输入)，定义多个输入表达式。在输出表达式中，可以定义选择表执行结果要创建的变量（变量的值将用于输出项表达式，在下面解释）。可以通过选择Add Output(添加输出)，定义多个输出表达式。

在决策表编辑界面，可以选择命中策略，共有两大类（单命中、多命中）七种命中策略可选：

（1）单命中、第一命中（single hit & FIRST）：多个规则允许交叉，执行从上到下的第一条命中项。
（2）单命中、唯一命中（single hit & UNIQUE）：多个规则不允许交叉，执行从上到下的第一条唯一命中项。
（3）单命中、任一命中（single hit & ANY）：规则允许交叉，但是所有输出的优先级相同，随机执行一条命中项。
（4）单命中、优先级（single hit & PRIORITY）：多个命中规则的优先级不同，执行优先级最高的那条。
（5）多命中、输出优先级排序（multiple hit & OUTPUT ORDER）：按照输出优先级递减的顺序返回所有命中。
（6）多命中、规则顺序排序（multiple hit & RULE ORDER）：按照规则顺序返回所有命中。
（7）多命中、聚合（multiple hit & COLLECT）：按照随机顺序返回所有命中。 DMN 可以被 BPMN 定义的流程调用：在流程中引入一个决策任务(Decision task)，并选中引用决策表(Decision table reference)，来使用新创建的选择表

5.2.32.1.1 毫末工作流引擎方案