最近開(kāi)發(fā)的安全管理平臺(tái)新增了很多工單申請(qǐng)流程需求，比如加白申請(qǐng)，開(kāi)通申請(qǐng)等等。最開(kāi)始的兩個(gè)需求，為了方便，也沒(méi)多想，就直接開(kāi)發(fā)了對(duì)應(yīng)的業(yè)務(wù)代碼。

但隨著同類需求不斷增多，感覺(jué)再這樣寫(xiě)可要累死人，于是開(kāi)始了工作流引擎的開(kāi)發(fā)之路。查找了一些資料之后，開(kāi)發(fā)了現(xiàn)階段的工作流引擎，文章后面會(huì)有介紹。

雖然現(xiàn)在基本上能滿足日常的需求，但感覺(jué)還不夠智能，還有很多的優(yōu)化空間，所以正好借此機(jī)會(huì)，詳細(xì)了解了一些完善的工作流引擎框架，以及在架構(gòu)設(shè)計(jì)上需要注意的點(diǎn)，形成了這篇文章，分享給大家。

什么是工作流

先看一下維基百科對(duì)于工作流的定義：

工作流（Workflow），是對(duì)工作流程及其各操作步驟之間業(yè)務(wù)規(guī)則的抽象、概括描述。工作流建模，即將工作流程中的工作如何前后組織在一起的邏輯和規(guī)則，在計(jì)算機(jī)中以恰當(dāng)?shù)哪Ｐ捅磉_(dá)并對(duì)其實(shí)施計(jì)算。

工作流要解決的主要問(wèn)題是：為實(shí)現(xiàn)某個(gè)業(yè)務(wù)目標(biāo)，利用計(jì)算機(jī)在多個(gè)參與者之間按某種預(yù)定規(guī)則自動(dòng)傳遞文檔、信息或者任務(wù)。

簡(jiǎn)單來(lái)說(shuō)，工作流就是對(duì)業(yè)務(wù)的流程化抽象。WFMC（工作流程管理聯(lián)盟） 給出了工作流參考模型如下：

舉一個(gè)例子，比如公司辦公的 OA 系統(tǒng)，就存在大量的申請(qǐng)審批流程。而在處理這些流程時(shí)，如果每一個(gè)流程都對(duì)應(yīng)一套代碼，顯然是不現(xiàn)實(shí)的，這樣會(huì)造成很大程度上的代碼冗余，而且開(kāi)發(fā)工作量也會(huì)驟增。

這個(gè)時(shí)候就需要一個(gè)業(yè)務(wù)無(wú)關(guān)的，高度抽象和封裝的引擎來(lái)統(tǒng)一處理。通過(guò)這個(gè)引擎，可以靈活配置工作流程，并且可以自動(dòng)化的根據(jù)配置進(jìn)行狀態(tài)變更和流程流轉(zhuǎn)，這就是工作流引擎。

簡(jiǎn)單的工作流

那么，一個(gè)工作流引擎需要支持哪些功能呢？

這個(gè)問(wèn)題并沒(méi)有一個(gè)標(biāo)準(zhǔn)答案，需要根據(jù)實(shí)際的業(yè)務(wù)場(chǎng)景和需求來(lái)分析。在這里，我通過(guò)一個(gè)工單流程的演進(jìn)，從簡(jiǎn)單到復(fù)雜，循序漸進(jìn)地介紹一下都需要包含哪些基礎(chǔ)功能。

最簡(jiǎn)單流程

最簡(jiǎn)單的一個(gè)流程工單，申請(qǐng)人發(fā)起流程，每個(gè)節(jié)點(diǎn)審批人逐個(gè)審批，最終流程結(jié)束。

會(huì)簽

在這個(gè)過(guò)程中，節(jié)點(diǎn)分成了兩大類：簡(jiǎn)單節(jié)點(diǎn)和復(fù)雜節(jié)點(diǎn)。

簡(jiǎn)單節(jié)點(diǎn)處理邏輯不變，依然是處理完之后自動(dòng)到下一個(gè)節(jié)點(diǎn)。復(fù)雜節(jié)點(diǎn)比如說(shuō)會(huì)簽節(jié)點(diǎn)，則不同，需要其下的所有子節(jié)點(diǎn)都處理完成，才能到下一個(gè)節(jié)點(diǎn)。

并行

同樣屬于復(fù)雜節(jié)點(diǎn)，其任何一個(gè)子節(jié)點(diǎn)處理完成后，都可以進(jìn)入到下一個(gè)節(jié)點(diǎn)。

條件判斷

需要根據(jù)不同的表單內(nèi)容進(jìn)入不同的分支流程。

舉一個(gè)例子，比如在進(jìn)行休假申請(qǐng)時(shí)，請(qǐng)假一天需要直屬領(lǐng)導(dǎo)審批，如果大于三天則需要部門(mén)領(lǐng)導(dǎo)審批。

動(dòng)態(tài)審批人

審批節(jié)點(diǎn)的審批人需要?jiǎng)討B(tài)獲取，并且可配置。

審批人的獲取方式可以分以下幾種：

• 固定審批人
• 從申請(qǐng)表單中獲取
• 根據(jù)組織架構(gòu)，動(dòng)態(tài)獲取
• 從配置的角色組或者權(quán)限組中獲取

撤銷和駁回

節(jié)點(diǎn)狀態(tài)變更可以有申請(qǐng)人撤回，審批人同意，審批人駁回。那么在駁回時(shí)，可以直接駁回到開(kāi)始節(jié)點(diǎn)，流程結(jié)束，也可以到上一個(gè)節(jié)點(diǎn)。更復(fù)雜一些，甚至可以到前面流程的任意一個(gè)節(jié)點(diǎn)。

自動(dòng)化節(jié)點(diǎn)

有一些節(jié)點(diǎn)是不需要人工參與的，比如說(shuō)聯(lián)動(dòng)其他系統(tǒng)自動(dòng)處理，或者審批節(jié)點(diǎn)有時(shí)間限制，超時(shí)自動(dòng)失效。

個(gè)性化通知

節(jié)點(diǎn)審批之后，可以配置不同的通知方式來(lái)通知相關(guān)人。

以上是我列舉的一些比較常見(jiàn)的需求點(diǎn)，還有像加簽，代理，腳本執(zhí)行等功能，如果都實(shí)現(xiàn)的話，應(yīng)該會(huì)是一個(gè)龐大的工作量。當(dāng)然了，如果目標(biāo)是做一個(gè)商業(yè)化產(chǎn)品的話，功能還是需要更豐富一些的。

但把這些常見(jiàn)需求點(diǎn)都實(shí)現(xiàn)的話，應(yīng)該基本可以滿足大部分的需求了，至少對(duì)于我們系統(tǒng)的工單流程來(lái)說(shuō)，目前是可以滿足的。

工作流引擎對(duì)比

既然這是一個(gè)常見(jiàn)的需求，那么需要我們自己來(lái)開(kāi)發(fā)嗎？市面上有開(kāi)源項(xiàng)目可以使用嗎？

答案是肯定的，目前，市場(chǎng)上比較有名的開(kāi)源流程引擎有 Osworkflow、Jbpm、Activiti、Flowable、Camunda 等等。其中：Jbpm、Activiti、Flowable、Camunda 四個(gè)框架同宗同源，祖先都是 Jbpm4，開(kāi)發(fā)者只要用過(guò)其中一個(gè)框架，基本上就會(huì)用其它三個(gè)了。

Osworkflow

Osworkflow 是一個(gè)輕量化的流程引擎，基于狀態(tài)機(jī)機(jī)制，數(shù)據(jù)庫(kù)表很少。Osworkflow 提供的工作流構(gòu)成元素有：步驟（step）、條件（conditions）、循環(huán)（loops）、分支（spilts）、合并（joins）等，但不支持會(huì)簽、跳轉(zhuǎn)、退回、加簽等這些操作，需要自己擴(kuò)展開(kāi)發(fā)，有一定難度。

如果流程比較簡(jiǎn)單，Osworkflow 是一個(gè)很不錯(cuò)的選擇。

JBPM

JBPM 由 JBoss 公司開(kāi)發(fā)，目前最高版本是 JPBM7，不過(guò)從 JBPM5 開(kāi)始已經(jīng)跟之前不是同一個(gè)產(chǎn)品了，JBPM5 的代碼基礎(chǔ)不是 JBPM4，而是從 Drools Flow 重新開(kāi)始的?；?Drools Flow 技術(shù)在國(guó)內(nèi)市場(chǎng)上用的很少，所有不建議選擇 JBPM5 以后版本。

JBPM4 誕生的比較早，后來(lái) JBPM4 創(chuàng)建者 Tom Baeyens 離開(kāi) JBoss，加入 Alfresco 后很快推出了新的基于 JBPM4 的開(kāi)源工作流系統(tǒng) Activiti，另外 JBPM 以 hibernate 作為數(shù)據(jù)持久化 ORM 也已不是主流技術(shù)。

Activiti

Activiti 由 Alfresco 軟件開(kāi)發(fā)，目前最高版本 Activiti7。Activiti 的版本比較復(fù)雜，有 Activiti5、Activiti6、Activiti7 幾個(gè)主流版本，選型時(shí)讓人暈頭轉(zhuǎn)向，有必要先了解一下 Activiti 這幾個(gè)版本的發(fā)展歷史。

Activiti5 和 Activiti6 的核心 leader 是 Tijs Rademakers，由于團(tuán)隊(duì)內(nèi)部分歧，在 2017 年 Tijs Rademakers 離開(kāi)團(tuán)隊(duì)，創(chuàng)建了后來(lái)的 Flowable。Activiti6 以及 Activiti5 代碼已經(jīng)交接給了 Salaboy 團(tuán)隊(duì)，Activiti6 以及 Activiti5 的代碼官方已經(jīng)暫停維護(hù)了。

Salaboy 團(tuán)隊(duì)目前在開(kāi)發(fā) Activiti7 框架，Activiti7 內(nèi)核使用的還是 Activiti6，并沒(méi)有為引擎注入更多的新特性，只是在 Activiti 之外的上層封裝了一些應(yīng)用。

Flowable

Flowable 是一個(gè)使用 Java 編寫(xiě)的輕量級(jí)業(yè)務(wù)流程引擎，使用 Apache V2 license 協(xié)議開(kāi)源。2016 年 10 月，Activiti 工作流引擎的主要開(kāi)發(fā)者離開(kāi) Alfresco 公司并在 Activiti 分支基礎(chǔ)上開(kāi)啟了 Flowable 開(kāi)源項(xiàng)目?；?Activiti v6 beta4 發(fā)布的第一個(gè) Flowable release 版本為 6.0。

Flowable 項(xiàng)目中包括 BPMN（Business Process Model and Notation）引擎、CMMN（Case Management Model and Notation）引擎、DMN（Decision Model and Notation）引擎、表單引擎（Form Engine）等模塊。

相對(duì)開(kāi)源版，其商業(yè)版的功能會(huì)更強(qiáng)大。以 Flowable6.4.1 版本為分水嶺，大力發(fā)展其商業(yè)版產(chǎn)品，開(kāi)源版本維護(hù)不及時(shí)，部分功能已經(jīng)不再開(kāi)源版發(fā)布，比如表單生成器（表單引擎）、歷史數(shù)據(jù)同步至其他數(shù)據(jù)源、ES 等。

Camunda

Camunda 基于 Activiti5，所以其保留了 PVM，最新版本 Camunda7.15，保持每年發(fā)布兩個(gè)小版本的節(jié)奏，開(kāi)發(fā)團(tuán)隊(duì)也是從 Activiti 中分裂出來(lái)的，發(fā)展軌跡與 Flowable 相似，同時(shí)也提供了商業(yè)版，不過(guò)對(duì)于一般企業(yè)應(yīng)用，開(kāi)源版本也足夠了。

以上就是每個(gè)項(xiàng)目的一個(gè)大概介紹，接下來(lái)主要對(duì)比一下 Jbpm、Activiti、Flowable 和 Camunda。只看文字的話可能對(duì)它們之間的關(guān)系還不是很清楚，所以我畫(huà)了一張圖，可以更清晰地體現(xiàn)每個(gè)項(xiàng)目的發(fā)展軌跡。

那么，如果想要選擇其中一個(gè)項(xiàng)目來(lái)使用的話，應(yīng)該如何選擇呢？我羅列了幾項(xiàng)我比較關(guān)注的點(diǎn)，做了一張對(duì)比表格，如下：

Flowable 應(yīng)用舉例

如果選擇使用開(kāi)源項(xiàng)目來(lái)開(kāi)發(fā)自己的引擎，或者嵌入到現(xiàn)有的項(xiàng)目中，應(yīng)該如何使用呢？這里通過(guò) Flowable 來(lái)舉例說(shuō)明。

使用 Flowable 可以有兩種方式，分別是內(nèi)嵌和獨(dú)立部署方式，現(xiàn)在來(lái)分別說(shuō)明：

內(nèi)嵌模式

創(chuàng)建 maven 工程

先建一個(gè)普通的 maven 工程，加入 Flowable 引擎的依賴以及 h2 內(nèi)嵌數(shù)據(jù)庫(kù)的依賴，也可以使用 MySQL 數(shù)據(jù)庫(kù)來(lái)做持久化。

<!-- https://mvnrepository.com/artifact/org.flowable/flowable-engine -->
<dependency>
  <groupId>org.flowable</groupId>
  <artifactId>flowable-engine</artifactId>
  <version>6.7.2</version>
</dependency>
<dependency>
  <groupId>com.h2database</groupId>
  <artifactId>h2</artifactId>
  <version>1.4.192</version>
</dependency>

創(chuàng)建流程引擎實(shí)例

import org.flowable.engine.ProcessEngine;
import org.flowable.engine.ProcessEngineConfiguration;
import org.flowable.engine.impl.cfg.StandaloneProcessEngineConfiguration;

public class HolidayRequest {

  public static void main(String[] args){
    ProcessEngineConfiguration cfg = new StandaloneProcessEngineConfiguration()
      .setJdbcUrl("jdbc:h2:mem:flowable;DB_CLOSE_DELAY=-1")
      .setJdbcUsername("sa")
      .setJdbcPassword("")
      .setJdbcDriver("org.h2.Driver")
      .setDatabaseSchemaUpdate(ProcessEngineConfiguration.DB_SCHEMA_UPDATE_TRUE);

    ProcessEngine processEngine = cfg.buildProcessEngine();
  }

}

接下來(lái)，我們就可以往這個(gè)引擎實(shí)例上部署一個(gè)流程 xml。比如，我們想建立一個(gè)員工請(qǐng)假流程：

<?xml versinotallow="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:activiti="http://activiti.org/bpmn"
             typeLanguage="http://www.w3.org/2001/XMLSchema"
             expressinotallow="http://www.w3.org/1999/XPath"
             targetNamespace="http://www.flowable.org/processdef">

    <process id="holidayRequest" name="Holiday Request" isExecutable="true">

        <startEvent id="startEvent"/>
        <sequenceFlow sourceRef="startEvent" targetRef="approveTask"/>

<!--        <userTask id="approveTask" name="Approve or reject request"/>-->
        <userTask id="approveTask" name="Approve or reject request" activiti:candidateGroups="managers"/>

        <sequenceFlow sourceRef="approveTask" targetRef="decision"/>

        <exclusiveGateway id="decision"/>
        <sequenceFlow sourceRef="decision" targetRef="externalSystemCall">
            <conditionExpression xsi:type="tFormalExpression">
                <![CDATA[
          ${approved}
        ]]>
            </conditionExpression>
        </sequenceFlow>
        <sequenceFlow sourceRef="decision" targetRef="sendRejectionMail">
            <conditionExpression xsi:type="tFormalExpression">
                <![CDATA[
          ${!approved}
        ]]>
            </conditionExpression>
        </sequenceFlow>

        <serviceTask id="externalSystemCall" name="Enter holidays in external system"
                     activiti:class="org.example.CallExternalSystemDelegate"/>
        <sequenceFlow sourceRef="externalSystemCall" targetRef="holidayApprovedTask"/>

<!--        <userTask id="holidayApprovedTask" name="Holiday approved"/>-->
        <userTask id="holidayApprovedTask" name="Holiday approved" activiti:assignee="${employee}"/>

        <sequenceFlow sourceRef="holidayApprovedTask" targetRef="approveEnd"/>

        <serviceTask id="sendRejectionMail" name="Send out rejection email"
                     activiti:class="org.flowable.SendRejectionMail"/>
        <sequenceFlow sourceRef="sendRejectionMail" targetRef="rejectEnd"/>

        <endEvent id="approveEnd"/>

        <endEvent id="rejectEnd"/>

    </process>

</definitions>

此 xml 是符合 bpmn2.0 規(guī)范的一種標(biāo)準(zhǔn)格式，其對(duì)應(yīng)的流程圖如下：

接下來(lái)，我們就把這個(gè)文件傳給流程引擎，讓它基于該文件，創(chuàng)建一個(gè)工作流。

RepositoryService repositoryService = processEngine.getRepositoryService();
Deployment deployment = repositoryService.createDeployment()
  .addClasspathResource("holiday-request.bpmn20.xml")
  .deploy();

創(chuàng)建后，實(shí)際就寫(xiě)到內(nèi)存數(shù)據(jù)庫(kù) h2 了，我們還可以把它查出來(lái)：

ProcessDefinition processDefinition = repositoryService.createProcessDefinitionQuery()
  .deploymentId(deployment.getId())
  .singleResult();
System.out.println("Found process definition : " + processDefinition.getName());

創(chuàng)建工作流實(shí)例

創(chuàng)建工作流實(shí)例，需要提供一些輸入?yún)?shù)，比如我們創(chuàng)建的員工請(qǐng)假流程，參數(shù)就需要：?jiǎn)T工姓名、請(qǐng)假天數(shù)、事由等。

Scanner scanner= new Scanner(System.in);

System.out.println("Who are you?");
String employee = scanner.nextLine();

System.out.println("How many holidays do you want to request?");
Integer nrOfHolidays = Integer.valueOf(scanner.nextLine());

System.out.println("Why do you need them?");
String description = scanner.nextLine();


RuntimeService runtimeService = processEngine.getRuntimeService();

Map<String, Object> variables = new HashMap<String, Object>();
variables.put("employee", employee);
variables.put("nrOfHolidays", nrOfHolidays);
variables.put("description", description);

參數(shù)準(zhǔn)備好后，就可以傳給工作流了：

ProcessInstance processInstance =
    runtimeService.startProcessInstanceByKey("holidayRequest", variables);

此時(shí)，就會(huì)根據(jù)流程定義里的：

<userTask id="approveTask" name="Approve or reject request" activiti:candidateGroups="managers"/>

創(chuàng)建一個(gè)任務(wù)，任務(wù)有個(gè)標(biāo)簽，就是 candidateGroups，這里的 managers，可以猜得出，是給 managers 建了個(gè)審批任務(wù)。

查詢并審批任務(wù)

基于 manager 查詢?nèi)蝿?wù)：

TaskService taskService = processEngine.getTaskService();
List<Task> tasks = taskService.createTaskQuery().taskCandidateGroup("managers").list();
System.out.println("You have " + tasks.size() + " tasks:");
for (int i=0; i<tasks.size(); i++) {
  System.out.println((i+1) + ") " + tasks.get(i).getName());
}

審批任務(wù)：

boolean approved = scanner.nextLine().toLowerCase().equals("y");
variables = new HashMap<String, Object>();
variables.put("approved", approved);
taskService.complete(task.getId(), variables);

這里就是把全局變量 approved，設(shè)為了 true，然后提交給引擎。引擎就會(huì)根據(jù)這里的變量是 true 還是 false，選擇走不同分支。如下：

<sequenceFlow sourceRef="decision" targetRef="externalSystemCall">
    <conditionExpression xsi:type="tFormalExpression">
        <![CDATA[
  ${approved}
]]>
    </conditionExpression>
</sequenceFlow>
<sequenceFlow sourceRef="decision" targetRef="sendRejectionMail">
    <conditionExpression xsi:type="tFormalExpression">
        <![CDATA[
  ${!approved}
]]>
    </conditionExpression>
</sequenceFlow>

回調(diào)用戶代碼

審批后，就會(huì)進(jìn)入下一個(gè)節(jié)點(diǎn)：

<serviceTask id="externalSystemCall" name="Enter holidays in external system"
             activiti:class="org.example.CallExternalSystemDelegate"/>

這里有個(gè) class，就是需要我們自己實(shí)現(xiàn)的：

最后，流程就走完結(jié)束了。

REST API 模式

上面介紹的方式是其作為一個(gè) jar，內(nèi)嵌到我們的程序里。創(chuàng)建引擎實(shí)例后，由我們業(yè)務(wù)程序去驅(qū)動(dòng)引擎的運(yùn)行。引擎和業(yè)務(wù)代碼在同一個(gè)進(jìn)程里。

第二種方式，F(xiàn)lowable 也可以作為一個(gè)獨(dú)立服務(wù)運(yùn)行，提供 REST API 接口，這樣的話，非 Java 語(yǔ)言開(kāi)發(fā)的系統(tǒng)就也可以使用該引擎了。

這個(gè)只需要我們下載官方的 zip 包，里面有個(gè) rest 的 war 包，可以直接放到 tomcat 里運(yùn)行。

部署工作流

在這種方式下，如果要實(shí)現(xiàn)上面舉例的員工請(qǐng)假流程，可以通過(guò)調(diào)接口來(lái)實(shí)現(xiàn)：

啟動(dòng)工作流：

其他接口就不一一展示了，可以參考官方文檔。

通過(guò)頁(yè)面進(jìn)行流程建模

截止到目前，創(chuàng)建工作流程都是通過(guò)建立 xml 來(lái)實(shí)現(xiàn)的，這樣還是非常不方便的。因此，系統(tǒng)也提供了通過(guò)頁(yè)面可視化的方式來(lái)創(chuàng)建流程，使用鼠標(biāo)拖拽相應(yīng)組件即可完成。

但是體驗(yàn)下來(lái)還是比較辛苦的，功能很多，名詞更多，有很多都不知道是什么意思，只能不斷嘗試來(lái)理解。

開(kāi)源 VS 自研

既然已經(jīng)有成熟的開(kāi)源產(chǎn)品了，還需要自研嗎？這算是一個(gè)老生常談的問(wèn)題了。那到底應(yīng)該如何選擇呢？其實(shí)并不困難，歸根結(jié)底就是要符合自身的業(yè)務(wù)特點(diǎn)，以及實(shí)際的需求。

開(kāi)源優(yōu)勢(shì)：

入門(mén)門(mén)檻低，有很多可以復(fù)用的成果。通常而言，功能比較豐富，周邊生態(tài)也比較完善，投入產(chǎn)出比比較高。一句話總結(jié)，投入少，見(jiàn)效快。

開(kāi)源劣勢(shì)：

內(nèi)核不容易掌控，門(mén)檻較高，通常開(kāi)源的功能和實(shí)際業(yè)務(wù)并不會(huì)完全匹配，很多開(kāi)源產(chǎn)品開(kāi)箱即用做的不夠好，需要大量調(diào)優(yōu)。一句話總結(jié)，入門(mén)容易掌控難。

自研優(yōu)勢(shì)：

產(chǎn)品核心技術(shù)掌控程度高，可以更好的貼著業(yè)務(wù)需求做，可以定制的更好，基于上述兩點(diǎn)，通常更容易做到良好的性能表現(xiàn)。一句話總結(jié)，量身定制。

自研劣勢(shì)：

投入產(chǎn)出比略低，且對(duì)團(tuán)隊(duì)成員的能力曲線要求較高。此外封閉的生態(tài)會(huì)導(dǎo)致周邊支持缺乏，當(dāng)需要一些新需求時(shí)，往往都需要定制開(kāi)發(fā)。一句話總結(jié)，啥事都要靠自己。

基于以上的分析，再結(jié)合我們自身業(yè)務(wù)，我總結(jié)了以下幾點(diǎn)可供參考：

開(kāi)源項(xiàng)目均為 Java 技術(shù)棧，而我們使用 Python 和 Go 比較多，技術(shù)棧不匹配

開(kāi)源項(xiàng)目功能豐富，而我們業(yè)務(wù)相對(duì)簡(jiǎn)單，使用起來(lái)比較重

開(kāi)源項(xiàng)目并非開(kāi)箱即用，需要結(jié)合業(yè)務(wù)特點(diǎn)做定制開(kāi)發(fā)，學(xué)習(xí)成本和維護(hù)成本比較高

綜上所述，我覺(jué)得自研更適合我們現(xiàn)階段的產(chǎn)品特點(diǎn)。

工作流引擎架構(gòu)設(shè)計(jì)

如果選擇自研，架構(gòu)應(yīng)該如何設(shè)計(jì)呢？有哪些比較重要的模塊和需要注意的點(diǎn)呢？下面來(lái)詳細(xì)說(shuō)說(shuō)。

BPMN

BPMN 全稱是 Business Process Model And Notation，即業(yè)務(wù)流程模型和符號(hào)。

可以理解成一種規(guī)范，在這個(gè)規(guī)范里，哪些地方用空心圓，哪些地方用矩形，哪些地方用菱形，都是有明確定義的。

也就是說(shuō)，只要是基于這個(gè)規(guī)范開(kāi)發(fā)的系統(tǒng)，其所創(chuàng)建的流程就都是可以通用的。

其實(shí)，如果只是開(kāi)發(fā)一個(gè)內(nèi)部系統(tǒng)，不遵守這個(gè)規(guī)范也沒(méi)有問(wèn)題。但要是做一個(gè)產(chǎn)品的話，為了通用性更強(qiáng)，最好還是遵守這個(gè)規(guī)范。

流程設(shè)計(jì)器

對(duì)于工作流引擎來(lái)說(shuō)，流程設(shè)計(jì)器的選型至關(guān)重要，它提供了可視化的流程編排能力，決定了用戶體驗(yàn)的好壞。

目前主流的流程設(shè)計(jì)器有 Activiti-Modeler，mxGraph，bpmn-js 等，下面來(lái)做一個(gè)簡(jiǎn)單介紹。

Activiti 開(kāi)源版本中帶了 Web 版流程設(shè)計(jì)器，在 Activiti-explorer 項(xiàng)目中有 Activiti-Modeler，優(yōu)點(diǎn)是集成簡(jiǎn)單，開(kāi)發(fā)工作量小，缺點(diǎn)是界面不美觀，用戶體驗(yàn)差。

mxGraph

mxGraph 是一個(gè)強(qiáng)大的 JavaScript 流程圖前端庫(kù)，可以快速創(chuàng)建交互式圖表和圖表應(yīng)用程序，國(guó)內(nèi)外著名的 ProcessOne 和 draw.io 都是使用該庫(kù)創(chuàng)建的強(qiáng)大的在線流程圖繪制網(wǎng)站。

由于 mxGraph 是一個(gè)開(kāi)放的 js 繪圖開(kāi)發(fā)框架，我們可以開(kāi)發(fā)出很炫的樣式，或者完全按照項(xiàng)目需求定制。

官方網(wǎng)站：http://jgraph.github.io/mxgrap

bpmn-js

bpmn-js 是 BPMN2.0 渲染工具包和 Web 模型。bpmn-js 正在努力成為 Camunda BPM 的一部分。bpmn-js 使用 Web 建模工具可以很方便的構(gòu)建 BPMN 圖表，可以把 BPMN 圖表嵌入到你的項(xiàng)目中，容易擴(kuò)展。

bpmn-js 是基于原生 js 開(kāi)發(fā)，支持集成到 vue、react 等開(kāi)源框架中。

官方網(wǎng)站：https://bpmn.io/

以上介紹的都屬于是功能強(qiáng)大且完善的框架，除此之外，還有其他基于 Vue 或者 React 開(kāi)發(fā)的可視化編輯工具，大家也可以根據(jù)自己的實(shí)際需求進(jìn)行選擇。

流程引擎

最后來(lái)說(shuō)說(shuō)流程引擎，整個(gè)系統(tǒng)的核心。引擎設(shè)計(jì)的好壞決定了整個(gè)系統(tǒng)的穩(wěn)定性，可用性，擴(kuò)展性等等。

整體架構(gòu)如圖所示，主要包括一下幾個(gè)部分：

一、流程設(shè)計(jì)器主要通過(guò)一系列工具創(chuàng)建一個(gè)計(jì)算機(jī)可以處理的工作流程描述，流程建模通常由許多離散的節(jié)點(diǎn)步驟組成，需要包含所有關(guān)于流程的必要信息，這些信息包括流程的起始和結(jié)束條件，節(jié)點(diǎn)之間的流轉(zhuǎn)，要承擔(dān)的用戶任務(wù)，被調(diào)用的應(yīng)用程序等。

二、流程引擎主要負(fù)責(zé)流程實(shí)例化、流程控制、節(jié)點(diǎn)實(shí)例化、節(jié)點(diǎn)調(diào)度等。在執(zhí)行過(guò)程中，工作流引擎提供流程的相關(guān)信息，管理流程的運(yùn)行，監(jiān)控流程的運(yùn)行狀態(tài)，并記錄流程運(yùn)行的歷史數(shù)據(jù)。

三、存儲(chǔ)服務(wù)提供具體模型及流程流轉(zhuǎn)產(chǎn)生的信息的存儲(chǔ)空間，工作流系統(tǒng)通常需要支持各種常見(jiàn)的數(shù)據(jù)庫(kù)存儲(chǔ)。

四、組織模型不屬于工作流系統(tǒng)的建設(shè)范圍，但流程設(shè)計(jì)器在建模的過(guò)程中會(huì)引用組織模型，如定義任務(wù)節(jié)點(diǎn)的參與者。還有就是在流程流轉(zhuǎn)的過(guò)程中同樣也需要引用組織模型，如在進(jìn)行任務(wù)指派時(shí)，需要從組織模型中確定任務(wù)的執(zhí)行者。

工作流引擎內(nèi)部可以使用平臺(tái)自身的統(tǒng)一用戶組織架構(gòu)，也可以適配第三方提供的用戶組織架構(gòu)。

五、工作流引擎作為一項(xiàng)基礎(chǔ)支撐服務(wù)提供給各業(yè)務(wù)系統(tǒng)使用，對(duì)第三方系統(tǒng)開(kāi)放標(biāo)準(zhǔn)的 RESTful 服務(wù)。

后記

下面來(lái)說(shuō)說(shuō)我現(xiàn)在開(kāi)發(fā)的系統(tǒng)支持到了什么程度，以及未來(lái)可能的發(fā)展方向。由于畢竟不是一個(gè)專門(mén)的工單系統(tǒng)，工單申請(qǐng)也只是其中的一個(gè)模塊，所以在整體的功能上肯定和完整的工作流引擎有很大差距。

第一版

第一版并沒(méi)有流程引擎，開(kāi)發(fā)方式簡(jiǎn)單粗暴，每增加一個(gè)流程，就需要重新開(kāi)發(fā)對(duì)應(yīng)的表和業(yè)務(wù)代碼。

這樣做的缺點(diǎn)是非常明顯的：

每個(gè)流程需要單獨(dú)開(kāi)發(fā)，工作量大，開(kāi)發(fā)效率低

流程功能相近，代碼重復(fù)量大，冗余，不利于維護(hù)

定制化開(kāi)發(fā)，缺少擴(kuò)展性#

第二版

第二版，也就是目前的版本。

隨著工單流程逐漸增多，工作量逐漸增大，于是開(kāi)始對(duì)流程進(jìn)行優(yōu)化，開(kāi)發(fā)了現(xiàn)階段的工作流引擎。

在新增一個(gè)工單流程時(shí)，需要先進(jìn)行工作流配置，配置其基礎(chǔ)信息，自定義字段，狀態(tài)和流轉(zhuǎn)這些信息。還支持配置自動(dòng)化節(jié)點(diǎn)，可以根據(jù)條件由程序自動(dòng)完成相關(guān)操作并審批。

配置好之后，后端無(wú)需開(kāi)發(fā)，由統(tǒng)一的引擎代碼進(jìn)行處理，包括節(jié)點(diǎn)審批流轉(zhuǎn)，狀態(tài)變更等。只需要開(kāi)發(fā)前端的創(chuàng)建和查詢頁(yè)面即可，相比于第一版，已經(jīng)在很大程度上提高了開(kāi)發(fā)效率。

目前版本需要優(yōu)化的點(diǎn)：

缺少可視化流程設(shè)計(jì)器，無(wú)法做到拖拽式設(shè)計(jì)流程

節(jié)點(diǎn)之間狀態(tài)流轉(zhuǎn)不夠靈活

缺少分布式事物支持，以及異常處理機(jī)制

下一個(gè)版本

針對(duì)以上不足，下一個(gè)版本準(zhǔn)備主要優(yōu)化三點(diǎn)，如下：

需要支持可視化流程設(shè)計(jì)器，使流程設(shè)計(jì)更加簡(jiǎn)單，靈活

根據(jù)流程配置自動(dòng)生成前端頁(yè)面，做到新增一種類型的工單，無(wú)需開(kāi)發(fā)

增加節(jié)點(diǎn)自動(dòng)化能力，異常處理機(jī)制，提高系統(tǒng)的穩(wěn)定性

以上就是本文的全部?jī)?nèi)容，如果覺(jué)得還不錯(cuò)的話歡迎點(diǎn)贊，轉(zhuǎn)發(fā)和關(guān)注，感謝支持。

參考文章：

https://www.cnblogs.com/grey-wolf/p/15963839.html

https://www.cnblogs.com/duck-and-duck/p/14436373.html#!comments

https://zhuanlan.zhihu.com/p/369761832

https://zhuanlan.zhihu.com/p/143739835

https://bbs.qolome.com/?p=365

https://workflowengine.io/blog/java-workflow-engines-comparison/