探索 BPMN—工作流技术的理论与实践|得物技术
一、前言
19 世纪 70 年代,流程管理思想萌芽阶段。
怎样提高工作效率?
泰勒:标准化个人操作流程
亨利·福特:规定标准时间定额
标准化、精简化、通用化、专业化。
20 世纪 70 年代,工作流技术起源于办公自动化领域的研究。由于当时计算机尚未普及,网络技术水平还很低以及理论基础匮乏,这项新技术并未取得成功,许多公司采用纸张表单,手工传递的方式,一级一级审批签字,工作效率非常低下。
20 世纪 90 年代,信息技术驱动流程自动化阶段。信息技术开始引入管理领域,对传统的业务进行自动化改造。
产品:Sabre 订票系统,MRP(物料需求计划),MIS(管理信息系统),CIMS(计算机集成制造系统)。
21 世纪初,BPM 管理与治理结合。
BPR/BPI:以信息技术为核心重新设计业务流程,失败率高达 50%-70%;
BPM:以业务流程为主导的管理思想;
BPM 治理思想:对 BPM 实施的成功率以及 ROI 的高要求,强调 BPM 与企业战略相结合。
二、BPMN 介绍
BPMN(Business Process Modeling Notation,业务流程建模符号)是一种用于描述业务流程的标准化建模语言。它通过图形符号及规则,帮助企业建模、分析和优化各种业务流程。BPMN 有两个主要版本:BPMN 1.0 和 BPMN 2.0。BPMN 1.0 规范由标准组织 BPMI(后并入到 OMG)于 2004 年 5 月发布;BPMN 2.0 标准由 OMG 于 2011 年推出。
2.0 相对于 1.0 规范了流程引擎的语义和格式,利用标准的图元描述真实的业务发生过程,保证相同的流程在不同的流程引擎中得到一致的执行结果。
BPMN 的理论基础
流程建模:BPMN 使用不同的图形符号来表示业务流程中的各项活动、任务、决策和事件等。这些符号包括任务、网关、事件等,每个符号都有特定的含义和用法。
流程分析:通过 BPMN 模型,企业可以分析业务流程的效率、资源利用率和风险等,以便进行优化和改进。
流程执行:BPMN 不仅是一种建模语言,还可以将建模的业务流程实际执行起来,并进行监控和控制。
BPMN 的优势
传统使用场景
采购流程:通过 BPMN 建模,企业可以规范采购流程,包括需求确认、供应商选择、合同签订、物品收货等环节,提高采购效率。
请假审批流程:BPMN 模型可以帮助企业规范请假审批流程,包括员工请假申请、直属主管审批、人力资源部门审批等环节,减少误差和纠纷。
客户投诉处理流程:利用 BPMN,企业可以清晰地展示客户投诉处理流程,包括客户投诉登记、处理人员分配、处理过程跟踪、客户反馈等环节,提高客户满意度。
三、实践举例:XX 平台 XXX 商家合规治理任务优化项目(非真实场景)
背景目标
商家合规治理手段的单一性和对线下人工的过度依赖方面需要优化,通过整合商家合规治理策略,并实现这些策略的可在线化配置。这一举措将打破传统的手工操作模式,允许业务方直接在系统中配置和更新治理策略,减少人工干预,提高治理效率。同时,在线化配置也便于策略的快速部署和灵活调整,以应对不同业务场景下的合规要求。
各商家的合规治理进度和状态的透明度方面需要优化,为改变这一现状,我们需要搭建一套高效的工作流引擎。该引擎将支持商家合规治理流程的编排和自动化流转,从任务触发到完成审核、记录反馈等各个环节都将实现自动化处理。同时,内置的进度跟踪机制将确保业务团队能够实时查看各商家的治理进度,及时发现问题并采取相应措施。这将大大提高治理的透明度和可控性。
评估治理成果和手段的有效性分析方面需要优化,将合规治理成果的数据可视化,通过强大的数据分析与可视化系统,我们将关键指标(如治理效率、违规率、改进情况等)以图表、报告等形式直观展现。同时,通过持续的数据分析与改进循环,我们将逐步优化治理策略和方式,最终形成商家合规治理的闭环机制。
方案
业务流程
治理流程 1
治理流程 2
系统架构图
流程编排
工作流技术选型
SmartEngine 详细介绍
E-R 图
代码实操
第一步,要选择正确的 SmartEngine 版本,将其添加到 pom 依赖中。
<dependency>
<groupld>com.alibaba.smart.framework</groupld>
<artifactld>smart-engine-extension-storage-custom</artifactld>
<version>3.0.0</version>
</dependency>
第二步,完成 SmartEngine 初始化。在初始化时,一般要加载流程定义到应用中。集群情况下,要注意流程定义的一致性(如果纯静态记载则无此类问题)。在初始化时,可以根据需要定义 Bean 的加载优先级。
BMPN2.0 xml 举例
附言:排他网关的条件表达式是跟着线条绑定的,要自己确保条件的是和否加在一起的总概率是 100%,如果不是 100%,小概率执行节点会卡在排他网关走不下去。例如:线条“否”的条件表达式为:条件 1 为假且条件 2 为假,线条“是”的条件表达式为条件 1 为真且条件 2 为真,则其他条件会卡死在排他网关流程走不下去。
test1.bpmn
process,表示一个流程。
id="exclusiveTest" version="1.0.0",分别表示流程定义的 id 和版本。这两个字段唯一区分一个流程定义。
startEvent,表示流程开始节点。只允许有一个开始节点。
endEvent,表示流程结束节点。可以有多个结束节点。
sequenceFlow,表示环节流转关系。sourceRef="theStart" targetRef="submitTask" 分别表示起始节点和目标节点。该节点有个子节点, approve == 'agree',这个片段很重要,用来描述流程流转的条件。approve == 'upgrade'使用的是 MVEL 表达式语法。另外,还值得注意的是,在驱动流程运转时,需要传入正确的参数。比如说,在后面介绍的 api 中,通常会需要在 Map 中传递业务请求参数。那么需要将 Map 中的 key 和 Mvel 的运算因子关联起来。以这个例子来说,request.put("approve", "agree");里面的 approve 和 approve == 'agree'命名要一致。
exclusiveGateway,表示互斥网关。该节点非常重要。用来区分流程节点的不同转向。互斥网关在引擎执行 conditionExpression 后,有且只能选择一条匹配的 sequenceFlow 继续执行。
serviceTask,服务任务,用来表示执行一个服务,所以他会有引擎默认的扩展:smart:class="com.alibaba.smart.framework.example.AuditProcessServiceTaskDelegation". Client Developer 使用时,需要自定义对应的业务实现类。在该节点执行时,它会自动执行服务调用,执行 smart:class 这个 delegation。该节点不暂停,会自动往下一个流转。
receiveTask,接收任务。在引擎遇到此类型的节点时,引擎执行会自动暂停,等待外部调用 signal 方法。当调用 signal 方法时,会驱动流程当前节点离开。在离开该节点时,引擎会自动执行 smart:class 这个 delegation。在一般业务场景中,我们通常使用 receiveTask 来表示等需要等待外部回调的节点。
userTask,表示用户任务节点,仅用于 DataBase 模式。该节点需要人工参与处理,并且通常需要在待办列表中展示。在 Custom 模式下,建议使用 receiveTask 来代替。
parallelGateway,这个节点并未在上述流程定义中体现,这里详细说一下。parallelGateway 首先必须成对出现,分别承担 fork 和 join 职责。其次,在 join 时需要实现分布式锁接口:LockStrategy。第三,fork 默认是顺序遍历多个 sequeceFlow,但是你如果需要使用并发 fork 功能的话,则需要实现该接口:ExecutorService。
重要领域对象
部署实例: DeploymentInstance,描述这个流程定义是谁发布的,当前处于什么状态。
流程定义: ProcessDefinition,描述一个流程有几个环节,之间的流转关系是什么样子的。
流程实例: ProcessInstance,可以简单理解为我们常见的一个工单。
活动实例: ActivityInstance,主要是描述流程实例(工单)的流转轨迹。
执行实例: ExecutionInstance,主要根据该实例的状态,来判断当前流程处在哪个节点上。
任务实例: TaskInstance,用来表示人工任务处理的,可以理解为一个需要人工参与处理的环节。
任务处理:TaskAssigneeInstance,用来表示当前任务共有几个处理者。通常在代办列表中用到此实体。
变量实例:VariableInstance,用来存储流程实例上下文。
SmartEngine 引擎源码地址:https://github.com/alibaba/SmartEngine/tree/masterSmartEngine UserGuide: https://github.com/alibaba/SmartEngine/wiki/SmartEngine-UserGuide--Chinese-Version-%28%E4%B8%AD%E6%96%87%E7%89%88%29Camunda 开源流程设计器(支持在线和本地 node.js 部署两种方式):https://camunda.com/download/modeler/Camunda 设计器学习文档:https://docs.camunda.io/docs/components/modeler/bpmn/bpmn-primer/
四、总结与建议
优点
业务流程可视化与实际系统流程可视化高度一致,所见即所得。
调整效率高(业务平均每个月会升级一次治理流程),如果业务流程 1.0 要升级到 1.1,只需要重新复制一份 bpmn.xml 流程模板重新编排为 1.1,并下发流程实例即可,不影响原有的流程模板和流程实例执行(调整效率由原来的一周缩短到 1 小时)。
流程实例和流程节点实例可视,方便监控各个节点的执行和数据报表的产出。
缺点
异常处理的支持度不够友好(SmartEngine 是异常丢弃),如果在某一个节点上执行失败(一般情况是业务接口执行失败导致),默认当前流程进度是卡在该节点的,需要设计张异常表,把当前流程实例,节点实例以及变量都保存下载,通过 job 重新拉起重试去驱动流程继续执行,并需要做好告警监控,以及任务实例和流程实例的核对。
高并发场景的支持度并不是太友好,要通过异步消息的方式来控制创建流程实例的速度,目前得到的创建流程实例的 TPS 是 100/s 单台,只是相对于 activiti 来说并发支持度要高,超过这个上限的场景建议谨慎使用。
可扩展性不足,例如:ProcessQueryService 只支持 findById,findList,count;ExecutionQueryService 只支持 findActiveExecutionList,findAll 这些基本查询 ,复杂查询需要新写 SmartEngine 核心包,升级 jar 包版本后才可使用。
无历史记录表,每隔一段时间要清理表中流程实例已经完结的相关数据,否则历史数据堆积影响查询效率。
建议
如果业务流程的复杂度一般,且经常会调整,并发量并不高的情况下,建议使用;如果业务复杂度过高,或并发量 TPS 超过单台 100/s,不建议使用。
*文 / 冬冬
本文属得物技术原创,更多精彩文章请看:得物技术
未经得物技术许可严禁转载,否则依法追究法律责任!
版权声明: 本文为 InfoQ 作者【得物技术】的原创文章。
原文链接:【http://xie.infoq.cn/article/b531bb10659ab54998fc72ae5】。文章转载请联系作者。
评论