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

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

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

什么是工作流

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

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

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

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

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

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

簡單的工作流

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

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

最簡單流程

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

會簽

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

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

并行

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

條件判斷

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

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

動態(tài)審批人

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

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

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

撤銷和駁回

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

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

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

個性化通知

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

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

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

工作流引擎對比

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

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

Osworkflow

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

如果流程比較簡單，Osworkflow 是一個很不錯的選擇。

JBPM

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

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

Activiti

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

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

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

Flowable

Flowable 是一個使用 Java 編寫的輕量級業(yè)務(wù)流程引擎，使用 Apache V2 license 協(xié)議開源。2016 年 10 月，Activiti 工作流引擎的主要開發(fā)者離開 Alfresco 公司并在 Activiti 分支基礎(chǔ)上開啟了 Flowable 開源項(xiàng)目?；?Activiti v6 beta4 發(fā)布的第一個 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）等模塊。

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

Camunda

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

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

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

Flowable 應(yīng)用舉例

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

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

內(nèi)嵌模式

創(chuàng)建 maven 工程

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

<!-- 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();
  }

}

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

<?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)格式，其對應(yīng)的流程圖如下：

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

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

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

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)建的員工請假流程，參數(shù)就需要：員工姓名、請假天數(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);

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

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

創(chuàng)建一個任務(wù)，任務(wù)有個標(biāo)簽，就是 candidateGroups，這里的 managers，可以猜得出，是給 managers 建了個審批任務(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，然后提交給引擎。引擎就會根據(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)用戶代碼

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

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

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

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

REST API 模式

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

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

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

部署工作流

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

啟動工作流：

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

通過頁面進(jìn)行流程建模

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

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

開源 VS 自研

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

開源優(yōu)勢：

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

開源劣勢：

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

自研優(yōu)勢：

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

自研劣勢：

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

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

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

開源項(xiàng)目功能豐富，而我們業(yè)務(wù)相對簡單，使用起來比較重

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

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

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

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

BPMN

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

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

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

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

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

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

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

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

mxGraph

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

由于 mxGraph 是一個開放的 js 繪圖開發(fā)框架，我們可以開發(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 開發(fā)，支持集成到 vue、react 等開源框架中。

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

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

流程引擎

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

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

一、流程設(shè)計(jì)器主要通過一系列工具創(chuàng)建一個計(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ān)信息，管理流程的運(yùn)行，監(jiān)控流程的運(yùn)行狀態(tài)，并記錄流程運(yùn)行的歷史數(shù)據(jù)。

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

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

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

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

后記

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

第一版

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

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

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

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

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

第二版

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

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

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

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

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

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

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

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

下一個版本

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

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

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

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

以上就是本文的全部內(nèi)容，如果覺得還不錯的話歡迎點(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/