我们生活中存在了大量的业务流程,大到结婚买房,小到请假买票。都需要按照规定的流程办事,如果流程比较简单我们可以通过画点草图来让大家理解。但当业务过于复杂的时候,如果没有一个业务流程图的规范,恐怕很难让人和机器看懂。为了让全球各种业务流程图能统一,就出现了BPMN(Business Process Model and Notation)标准,该标准已经成为了ISO标准之一(标准下载)。
BPMN2.0主要规范了图形,像UML图一样,也就是我们看到图就明白这个业务流的逻辑。那实际系统如何去根据图形去实现控制运转,这是属于工作流引擎要做的事情,像工作流运行中的控制模式,就得参考Control-Flow Patterns。需要重点说明的是,现在知名工作流引擎:Activiti、Flowable、Camunda还有国内的炎黄盈动等,都是自称支持BPMN2.0规范。实际他们的运行逻辑、属性标识、存储结构都是大致相同,但略有区别,是不能跨流程引擎通用的。比如符合BPMN2.0规范的开始事件的XML格式一般叫
,但网关的引擎内部定义就不太一样了,有的工作流引擎甚至不会采用XML格式而是JSON格式存储。所以流程引擎所谓的支持BPMN2.0,只是功能及外观遵循了标准。实际软件层面的实现,是可以根据自身需求来的。对于第一次接触BPMN2.0规范的来说,区分这个概念至关重要。
使用图形规范的意义就是为了让所有能看懂,就和我们现实中的语言一样。除此之外,在这样一个信息化的时代,我们有太多软件业务去处理现实中复杂的流程了。比如OA办公系统、WMS仓库管理系统、TMS物流管理系统、OMS、SRM、CRM订单管理系统等等。这些业务流程通常非常复杂,如果不通过规范去约束,用我们自己的符号去绘制。恐怕很容易踩坑,并且也不容易形成业务层面的标准和经验积累。那通过BPMN2.0规范,我们可以极大程度的对流程图进行治理、风险把控与合规性检查。
上图是一个简单的BPMN模型实例,该流程是一个招聘职位的模型。根据我们的观察不难理解其中含义,虽然你可能不知道这个图中每个模块的专业名词,但能看懂理解这个图的流程是什么。所以BPMN在可视化理解方面,还是做的挺不错的,也就是我所推崇的:最好的产品就是没有说明书的产品。
在BMPN2.0中,组件主要分为四类:活动、网关、事件、辅助。这里分享一个业务过程模型和符号规范总结图,便于你快速了解。
活动相当于实体,可以说流程图的实体模型定义主要就是由活动组成的。组件如下图所示:
最常用的活动就是任务了,。为了区分各种类型的任务,通常会在任务组件中,加入图标用以说明:
组件的颜色、样式及图标并没有统一的规范,在开发的时候可以根据系统的主色调进行适配。只要保持大致的形状即可。
但我们的流程过于复杂,就需要对流程图进行抽象。这样可以将细枝末节并相对独立的部分抽取到一个单独的流程里,在总体流程中再进行引入。
一般子流程和任务它们属于流程图的一部分,不能单独使用。然而在多数情况下,一个活动应该在多个流程图中都可以复用。BPMN为此提供了调用活动
的构造。当一个全局的活动或子流程被调用时候,用粗边框进行表示。
与普通流程不同,时间子流程不是序列流触发的。而是由程序执行期间,消息流所触发的事件而设计的流程。
和数据库里的事务概念一样,一项事务可以全部执行,也可以全部不执行。如果出现问题,则必须回滚事务。
网关相当于业务处理组件,活动(实体)只是来说明有什么,网关则可以通过与活动的连线来定义其规则。组件如下图所示:
上面三种网关是基于数据的独占 (XOR) 网关,但对于正在处理的数据走不同路径我们就需要事件网关。即基于事件的网关,该网关不基于数据进行路由,而是根据接下来发生的事件进行路由。请考虑这样一个业务流:我们订购比萨饼并等待它送达。我们只能在收到披萨后才能吃饭,但是如果 60 分钟后披萨还没有送来怎么办?我们会打一个焦虑的电话,就是这样!我们可以使用事件网关对此进行建模:
复杂网关(Complex Gateway):复杂网关允许根据特定业务场景的需要,自定义路径拆分和收回算法。
流程图只能用来描述静态的业务流程,但现实世界是由各种不确定性因素所所叠加的。当执行一个流程时,它将使用并创建数据、信息、文件、文档等。从一个活动到另一个活动的序列流通常伴随着数据传递。而数据的不同会造成不同的事件,我们要像编写程序一样,捕获各种各样的事件,这样才能保证系统的完整性和可靠性。
在绘图的时候,需要考虑两个方面:事件的原因(触发器),以及事件在流程图中的影响。
最常用的事件是以下三种,其中开始事件和结束事件最关键,也是每个流程图都需要具备的元素,中间事件根据所需添加。需要注意的是,三种事件图标中间会填充的不同符号,用来表达不同的意思。
事件的类型很多,所以这里用一个实际的例子来观察:
条件事件即条件为真的时候所触发的流程;信号事件指的是全局广播事件的监听;多重事件是指组合了多个事件,只要其中一个事件发生就会被启动;并行多重事件需要所有事件都必须发生才会启动。
默认结束事件就是一个加重的黑圈,里面是空白的;消息事件信封符号会被填充为黑色;终止结束事件则是纯黑色,该事件不仅删除了单个令牌,而是终止了整个流程。
中间事件可以发送和接收信号,通常在以下两种情况下使用中间事件:
BPMN2.0规范中,最常用的图形就是上述的活动、网关、事件。但为了让复杂的业务更加清晰的表达,BPMN也提出了一些辅助组件的使用。注意:这些辅助组件只是为了更好的表达业务模型,并不是必须的。
不同的组件可以用各种线条形状来关联,而不同的线条也有不同的含义,大致分为以下四种线条:
泳道图如下图所示,可以将不同的业务流拆分成不同的道。他们类似于将游泳池划分为不同得道,游泳比赛的每位参赛者只能在自己道里游泳。
注释主要是为了流程图做一些补充说明,我们可以按照自己喜欢的方式应用注释和组,甚至可以跨越池边界。注释和组不会影响执行语义,因此不要将它们与子流程等混淆。注:可用颜色区分。
流程图在运行时,如想突出其数据流的走向,可以通过数据对象和数据库来表达。
下图为数据流的例子:
本节主要介绍面对复杂场景的时候,如何构建清晰的流程模型。
当需要多个公司进行交互互作的时候,如多家公司以一种能够完全自动化下达和履行订单以及其他业务事务的方式连接其信息系统,每家公司需要对自己的流程负责。
上图为一个协作图,但没有办法表达更为详细的表达:消息流中的事件和逻辑顺序。编排图就是为了重点突出消息交换本身,如下图所示:
编排图分为了三栏,上下两栏分别表示了参与者。例图中:深色为接收方,白色为发起方。
会话图概述了某个区域的哪些参与者在哪些任务上进行合作。在下图中,可以看到三个会话。在处理广告订单时,一个客户与一个广告代理商和几个饭计师一起工作。另一方面,客户和广告代理商可以共同开展广告活动。为此,他们与几家媒介合作。设计师还可以是另一家公司的活动的一部分:与出版商一起,设计师处理插图的订单。
目前,BPMN2.0应用最广泛的地方就是流程引擎了。人们通过标准所规定的符号,画出全球公认的流程图。然后在自身系统中,进行运行实现复杂的业务逻辑的可视化。下面罗列出实现业务流程需要的前后端技术,可根据自身项目情况进行选型:
BPMN 2.0 渲染工具包和 web 建模器。它是用 JavaScript 编写的,将 BPMN 2.0 图表嵌入在浏览器中, 并独立于后端, 这也使得将其嵌入到任务 Web 应用程序中变得很容易: 可以独立使用也可以集成到你的应用中。
滴滴开源的,LogicFlow 是一款流程图编辑框架,提供了一系列流程图交互、编辑所必需的功能和简单灵活的节点自定义、插件等拓展机制,方便我们快速在业务系统内满足类流程图的需求。专注于业务自定义的流程图编辑框架,支持实现脑图、ER图、UML、工作流等各种图编辑场景。
阿里开源的,X6 是 AntV 旗下的图编辑引擎。提供简单易用的节点定制能力和开箱即用的交互组件,方便我们快速搭建流程图、DAG 图、ER 图等图应用。
针对商务人员、开发人员和系统管理员的轻量级工作流和业务流程管理 (BPM) 平台。它的核心是用于 Java 的超快速且坚如磐石的 BPMN 2 流程引擎。它是开源的,并在 Apache 许可下分发。 Activiti 可以在任何 Java 应用程序、服务器、集群中部署使用。
面向开发人员、系统管理员和业务用户的紧凑且高效的工作流和业务流程管理 (BPM) 平台。Flowable是用Java编写的开源工作流引擎,可以执行BPMN 2.0中描述的业务流程。它是Activiti的一个积极维护的分支。
compileflow是一个非常轻量、高性能、可集成、可扩展的流程引擎。该引擎是淘宝工作流TBBPM引擎之一,是专注于纯内存执行,无状态的流程引擎,通过将流程文件转换生成java代码编译执行,简洁高效。当前是阿里业务中台交易等多个核心系统的流程引擎。compileflow能让开发人员通过流程编辑器设计自己的业务流程,将复杂的业务逻辑可视化,为业务设计人员与开发工程师架起了一座桥梁。
最后说点我自己关于BPMN规范的想法:工具也好,规范也罢。都是为了满足我们实际所需的需求,在进行开发实现的时候,我们不要过于死板。要根据实际情况完善、优化和扩充。比如在BPMN规范中,是不允许多个数据流连到一个活动上(多脚针除外),中间需要有网关的角色。但实际开发过程中,发现网关太多以至于影响图形的可视化和可读性的时候,我们就可以通过技术性手段去简化优化相关规范。所以我不建议为了遵守规范而遵守规范,而要根据实际情况适当调整,方可开发出更有实际意义的产品。