# 流程设计器功能

# 简介

DragonFlow流程引擎是一款基于Web的流程建模工具，是Flowable BPM框架的一部分。它可以通过简单的拖拽和配置，快速创建和修改工作流程。本文将从环境安装、基础概念、流程设计、表单设计以及开发扩展等几个方面详细介绍DragonFlow流程引擎的使用方法

# 使用

在DragonFlow流程引擎中，创建流程定义非常简单。 首先，我们需要在左侧的组件栏中选择合适的流程元素，例如开始事件、用户任务、结束事件等，然后将其拖拽到画布中间的区域。

接下来，通过连线来定义流程的流转规则，网关线路需要在右侧属性面板中设置条件，以满足具体的业务需要。最后，再添加一些参数和表达式，用来设置流程中需要使用的变量及配置。

# 前言

在任何行业和企业中，一定存在着各式各样的流程，请假流程、报销流程、入职流程、离职流程、出差流程、合同审批流程、出入库流程等等…… 无论是管理者、技术人员还是业务人员，每天肯定也在使用各种流程，但我发现大家对流程的期待好像都不太一致。比如：

业务主管： 希望流程能够与不断变化的业务环境保持同步。

技术主管： 希望对变化的业务需求迅速做出响应，以较低的成本进行改变。

企业高管： 业务系统越来越多，也越来越复杂，完成业务需要人工访问多个系统。

出现这样的情况是由于很多企业流程用的还是比较初级的玩法：

在业务代码里面加入 Status(状态机) 字段维护流程状态，流程负责的审批人可能也是Hard Code(硬编码)，这种玩法实现流程初级会比较快。

但是也会导致其他的问题存在，比如：

1、流程健壮性差，但凡出现人员变动，或者组织结构调整，就需要修改代码，维护成本高；

2、流程无法复用，当组织出现新的工作流程，又要重新写一套代码，开发成本非常高；

3、流程和业务代码耦合，你中有我，我中有你(并不符合单一职责和解耦的设计原则)。

这是很多企业里，业务系统关于流程的使用方法。同时，这也是中国企业的数字化发展一直伴随着困惑的主要原因。

不论是ERP、CRM还是SCM，这些特定的软件只能解决特定层面的问题，虽然方便了具体的作业操作，提高了个人生产力，但传统企业存在的许多弊端还是不能解决，如协作流程混乱、部门间沟通不灵、分公司间活动脱节、机构臃肿、管理刻板、反应迟钝等。

同时很多企业的CIO也发现很多系统之间的业务数据根本无法整合，已有的资源无法利用，业务流程繁琐，致使错失良机。

这就是数字化赤裸裸的现实，散落在各个单独系统中的数据和流程只是企业数字化裸奔的遮羞布，一旦掀开就会露出不可见人的裸体。

正是因为这种情况，BPMN2.0才会成为我国企业数字化转型在流程方面的“救命稻草”。成为很多企业挑选系统开发平台时重要的考量标准之一。

那么BPMN2.0是如何解决流程和管理系统中的数字化难题的呢？下面我们一起详细了解下。

# 1、BPMN是什么？

BPMN是一个广泛接受与支持的，展现流程的注记方法。OMG BPMN标准. 首先BPMN规范是由标准组织BPMI发布的.BPMN 1.0规范发布于2004年5月。此规范展示了BPMI组织两年多的努力成果。BPMN的主要目标就是要提供被所有业务用户理解的一套标记语言，包括业务分析者、软件开发者以及业务管理者与监察者。BPMN还将支持生成可执行的BPEL4WS语言。所以，BPMN在业务流程设计与流程实现之间搭建了一条标准化的桥梁。 BPMN定义了业务流程图，其基于流程图技术，同时为创建业务流程操作的图形化模型进行了裁减。业务流程的模型就是图形化对象的网图，包括活动(也可以说工作)和定义操作顺序的流控制。

# 基本概念

我们生活中存在了大量的业务流程，大到结婚买房，小到请假买票。都需要按照规定的流程办事，如果流程比较简单我们可以通过画点草图来让大家理解。但当业务过于复杂的时候，如果没有一个业务流程图的规范，恐怕很难让人和机器看懂。为了让全球各种业务流程图能统一，就出现了BPMN（Business Process Model and Notation）标准，该标准已经成为了ISO标准之一 BPMN2.0主要规范了图形，像UML图一样，也就是我们看到图就明白这个业务流的逻辑。那实际系统如何去根据图形去实现控制运转，这是属于工作流引擎要做的事情，像工作流运行中的控制模式，就得参考Control-Flow Patterns。需要重点说明的是，现在知名工作流引擎：Activiti、Flowable、Camunda还有国内的炎黄盈动等，都是自称支持BPMN2.0规范。实际他们的运行逻辑、属性标识、存储结构都是大致相同，但略有区别，是不能跨流程引擎通用的。比如符合BPMN2.0规范的开始事件的XML格式一般叫<StartEvent>，但网关的引擎内部定义就不太一样了，有的工作流引擎甚至不会采用XML格式而是JSON格式存储。所以流程引擎所谓的支持BPMN2.0，只是功能及外观遵循了标准。实际软件层面的实现，是可以根据自身需求来的。对于第一次接触BPMN2.0规范的来说，区分这个概念至关重要。

# BPMN意义

使用图形规范的意义就是为了让所有能看懂，就和我们现实中的语言一样。除此之外，在这样一个信息化的时代，我们有太多软件业务去处理现实中复杂的流程了。比如OA办公系统、WMS仓库管理系统、TMS物流管理系统、OMS、SRM、CRM订单管理系统等等。这些业务流程通常非常复杂，如果不通过规范去约束，用我们自己的符号去绘制。恐怕很容易踩坑，并且也不容易形成业务层面的标准和经验积累。那通过BPMN2.0规范，我们可以极大程度的对流程图进行治理、风险把控与合规性检查。

# 2、BPMN基础

业务流程图由一系列的图形化元素组成。这些元素简化了模型的开发，且业务分析者看上去非常熟悉。这些元素每个都有各自的特性，且与大多数的建模器类似。比如，活动是矩形，条件是菱形。应该强调的是:开发BPMN的动力就是为了在创建业务流程模型时提供一个简单的机制，同时又能够处理来自业务流程的复杂性。要处理这两个矛盾的需求的方法就是将标记的图形化方面组织分类为特定的类别。这里提供标记类别中的一小部分，以便业务流程图的读者可以简单地识别出元素的基本类型从而理解图形。以下是四种基本的类型: 在BMPN2.0中，组件主要分为四类：活动、网关、事件、辅助。这里分享一个业务过程模型和符号规范总结图，便于你快速了解。

1)流对象(Flow)

2)连接对象(Connection)

3)泳道(Swimlane)

4)人工信息(Artifact)

下面一一解释

流对象:

一个业务流程图有三个流对象的核心元素。这三种流对象是

事件---一个事件用圆圈来描述，表示一个业务流程期间发生的东西。事件影响流程的流动，一般有一个原因(触发器)或一个影响(结果)。基于它们对流程的影响，有三种事件:开始，中间以及终止事件

活动---一个活动用圆角矩形表示，是要处理工作的一般术语。一个活动可以是原子性的也可以是非原子性的(可以是由多个活动组合而成的更大粒度的活动)。活动的类型包括:任务和子流程。子流程在图形的下方中间外加一个小加号(+)来区分。

条件---条件用熟悉的菱形表示，用于控制序列流的分支与合并。另外，它还可以作为传统的选择，还包括路径的分支与合并。其内部的标记会给出控制流的类型。

连接对象:

连接对象将流对象连接起来形成一个业务流程的基本结构。提供此功能的三个连接对象是:

顺序流---顺序流用一个带实心箭头的实心线表示，用于指定活动执行的顺序。注意"控制流"这个术语一般不用于BPMN

消息流---消息流用一条带有开箭头的虚线表示，用于描述两个独立的业务参与者(业务实体或业务角色)之间发送和接受的消息流动。在BPMN中，用两个独立的池代表两个参与者。

关联---用一根带有线箭头的点线表示关联，用于将相关的数据、文本和其他人工信息与流对象联系起来。关联用于展示活动的输入和输出。

泳道:

许多建模技术利用泳道这个概念将活动划分到不同的可视化类别中来描述由不同的参与者的责任与职责。BPMN支持2种主要的泳道构件。

池---池描述流程中的一个参与者。可以看做是将一系列活动区别于其他池的一个图形容器，一般用于B2B的上下文中。

道---道就是在池里面再细分，可以是垂直的也可以是水平的。道也是用于组织和分类活动。

人工信息:

人工信息添加到建模的业务流程上下文中作为信息备注，便于人员理解，当前BPMN规范的版本预定义了3种人工信息:

数据对象---数据对象是一个显示活动是如何需要或产生数据的。它们通过关联与活动连接起来。

组---组用一个虚线的圆角矩形表示，用于记录或分析的目的，但不影响顺序流。

注释---注释是建模者为BPMN图的读者提供附加文本信息的一个机制。

# BPMN文件结构说明

<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="http://www.omg.org/spec/BPMN/20100524/MODEL" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:flowable="http://flowable.org/bpmn" xmlns:bpmndi="http://www.omg.org/spec/BPMN/20100524/DI" xmlns:omgdc="http://www.omg.org/spec/DD/20100524/DC" xmlns:omgdi="http://www.omg.org/spec/DD/20100524/DI" xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://flowable.org/bpmn">
  <process id="xxx" name="xxxx" isExecutable="true">
    <startEvent id="aba1958401251475ca53b3f5d152fde3b" />
    <userTask id="ad4cb75f25df44780bcd2f831f7fe75b8" name="经理" flowable:skipExpression="">
      <extensionElements>
        <flowable:formData />
        <flowable:assigneeType>static</flowable:assigneeType>
      </extensionElements>
      <outgoing>Flow_1phon75</outgoing>
    </userTask>
    <sequenceFlow id="abe5b2b0a626845b688e0298d8c4635b3" sourceRef="aba1958401251475ca53b3f5d152fde3b" targetRef="ad4cb75f25df44780bcd2f831f7fe75b8" />
    <endEvent id="Event_19oxss3">
      <incoming>Flow_1phon75</incoming>
    </endEvent>
    <sequenceFlow id="Flow_1phon75" sourceRef="ad4cb75f25df44780bcd2f831f7fe75b8" targetRef="Event_19oxss3" />
  </process>
  <bpmndi:BPMNDiagram id="BPMNDiagram_xxx">
    <bpmndi:BPMNPlane id="BPMNPlane_xxx" bpmnElement="xxx">
      <bpmndi:BPMNEdge id="BPMNEdge_abe5b2b0a626845b688e0298d8c4635b3" bpmnElement="abe5b2b0a626845b688e0298d8c4635b3">
        <omgdi:waypoint x="5" y="40" />
        <omgdi:waypoint x="80" y="40" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNEdge id="Flow_1phon75_di" bpmnElement="Flow_1phon75">
        <omgdi:waypoint x="180" y="40" />
        <omgdi:waypoint x="242" y="40" />
      </bpmndi:BPMNEdge>
      <bpmndi:BPMNShape id="BPMNShape_ad4cb75f25df44780bcd2f831f7fe75b8" bpmnElement="ad4cb75f25df44780bcd2f831f7fe75b8">
        <omgdc:Bounds x="80" y="0" width="100" height="80" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="BPMNShape_aba1958401251475ca53b3f5d152fde3b" bpmnElement="aba1958401251475ca53b3f5d152fde3b">
        <omgdc:Bounds x="-25" y="25" width="30" height="30" />
      </bpmndi:BPMNShape>
      <bpmndi:BPMNShape id="Event_19oxss3_di" bpmnElement="Event_19oxss3">
        <omgdc:Bounds x="242" y="22" width="36" height="36" />
      </bpmndi:BPMNShape>
    </bpmndi:BPMNPlane>
  </bpmndi:BPMNDiagram>
</definitions>

# 3、BPMN建模的价值

BPMN的开发是减少众多已存在的业务建模工具和标记断层的重要的一步。BPMI标准化组织从许多存在的标记中展示出了专业和经验，且从这些不同的标记中找到了最好的理念形成一套标准的标记语言，众多的标记语言包括UML、Activity Diagram、UML EDOC Business Process、IDEF、ebXML BPSS、RosettaNet以及Event-Process Chains等等。一个好的标准建模标记将会减少业务与IT用户之间的混乱。

另一个驱使BPMN的开发原动力是，历史上由业务人员做出来的业务流程建模从需要系统设计与执行的流程描述中隔离出来，所以有必要将原有的业务流程模型转换为执行模型，而这个转换对于流程拥有者来说容易出错，且很艰难。

为了减少建模技术的断层，开发BPMN的重要目标就是要创建面向业务流程建模标记到面向IT执行语言的一座桥梁。以下是BPMN的图形化对象映射为BPMN v1.1的挂图。

# 4、结语

通过BPMN2.0规范的三要素：活动、网关、事件，我们可以做出一个完整闭环的流程，通过网关与事件的配置，几乎可以完成所有的业务需求，而且流程的各个环节与场景一目了然。

但是，它也有一个缺点，规范、元件太多，实际应用中需要很多的专业知识，除了需要了解业务场景之外，还需要根据各个业务场景解析各个环节所用到的元件。

而且BPMN2.0是外国的一套标准，站在国内使用者的角度去看，如果我们想用BPMN2.0标准做一套国内特色的工作流引擎的话，需要封装的内容较多，比如：各个参数的配置语法、格式，如何使用自然语言、如何扩展它的任务接收人、如何与表单挂接等等。

所以，如果企业的业务系统没有那么多工作流程，或者只有很简单的状态从A到B的转移，那么引入流程引擎显然是大马拉小车，费时费力不说，而且会造成简单的需求开发起来很麻烦，拉长开发周期时间。因此不推荐业务场景简单的小企业使用BPMN2.0。

但是如果您的企业业务场景比较复杂，那么BPMN2.0就是最好的选择。

本项目框架结合低代码和BPMN2.0，为数字化场景复杂的企业解决数字化难题。作为企业数字化转型首选方案，已累计为20多个行业，30000+企业用户提供低代码技术，支持在不同的行业，提出深度场景解决方案。