日本综合一区二区|亚洲中文天堂综合|日韩欧美自拍一区|男女精品天堂一区|欧美自拍第6页亚洲成人精品一区|亚洲黄色天堂一区二区成人|超碰91偷拍第一页|日韩av夜夜嗨中文字幕|久久蜜综合视频官网|精美人妻一区二区三区

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

達(dá)日網(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、APP開發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)公司等網(wǎng)站項(xiàng)目制作，到程序開發(fā)，運(yùn)營維護(hù)。創(chuàng)新互聯(lián)2013年開創(chuàng)至今到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。

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

雖然現(xiàn)在基本上能滿足日常的需求，但感覺還不夠智能，還有很多的優(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ì)算。

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

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

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

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

簡單的工作流

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

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

最簡單流程

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

會(huì)簽

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

簡單節(jié)點(diǎn)處理邏輯不變，依然是處理完之后自動(dòng)到下一個(gè)節(jié)點(diǎn)。復(fù)雜節(jié)點(diǎn)比如說會(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)審批，如果大于三天則需要部門領(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í)，可以直接駁回到開始節(jié)點(diǎn)，流程結(jié)束，也可以到上一個(gè)節(jié)點(diǎn)。更復(fù)雜一些，甚至可以到前面流程的任意一個(gè)節(jié)點(diǎn)。

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

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

個(gè)性化通知

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

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

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

工作流引擎對(duì)比

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

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

Osworkflow

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

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

JBPM

JBPM 由 JBoss 公司開發(fā)，目前最高版本是 JPBM7，不過從 JBPM5 開始已經(jīng)跟之前不是同一個(gè)產(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 幾個(gè)主流版本，選型時(shí)讓人暈頭轉(zhuǎn)向，有必要先了解一下 Activiti 這幾個(gè)版本的發(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 是一個(gè)使用 Java 編寫的輕量級(jí)業(yè)務(wù)流程引擎，使用 Apache V2 license 協(xié)議開源。2016 年 10 月，Activiti 工作流引擎的主要開發(fā)者離開 Alfresco 公司并在 Activiti 分支基礎(chǔ)上開啟了 Flowable 開源項(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ì)開源版，其商業(yè)版的功能會(huì)更強(qiáng)大。以 Flowable6.4.1 版本為分水嶺，大力發(fā)展其商業(yè)版產(chǎn)品，開源版本維護(hù)不及時(shí)，部分功能已經(jīng)不再開源版發(fā)布，比如表單生成器（表單引擎）、歷史數(shù)據(jù)同步至其他數(shù)據(jù)源、ES 等。

Camunda

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

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

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

	Activiti 7	Flowable 6	Camunda	JBPM 7
流程協(xié)議	BPMN2.0、XPDL、PDL	BPMN2.0、XPDL、XPDL	BPMN2.0、XPDL、XPDL	BPMN2.0
開源情況	開源	商業(yè)和開源版	商業(yè)和開源版	開源
開發(fā)基礎(chǔ)	JBPM4	Activiti 5 & 6	Activiti 5	版本 5 之后 Drools Flow
數(shù)據(jù)庫	Oracle、SQL Server、MySQL	Oracle、SQL Server、MySQL、postgre	Oracle、SQL Server、MySQL、postgre	MySQL，postgre
架構(gòu)	spring boot 2	spring boot 1.5	spring boot 2	Kie
運(yùn)行模式	獨(dú)立運(yùn)行和內(nèi)嵌	獨(dú)立運(yùn)行和內(nèi)嵌	獨(dú)立運(yùn)行和內(nèi)嵌	-
流程設(shè)計(jì)器	AngularJS	AngularJS	bpmn.js	-
活躍度	活躍	相對(duì)活躍	相對(duì)活躍	-
表數(shù)量	引入 25 張表	引入 47 張表	引入 19 張表	-
jar 包數(shù)量	引入 10 個(gè) jar	引入 37 個(gè) jar	引入 15 個(gè) jar	-

Flowable 應(yīng)用舉例

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

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

內(nèi)嵌模式

創(chuàng)建 maven 工程

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

  org.flowable
  flowable-engine
  6.7.2


  com.h2database
  h2
  1.4.192

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

}

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

             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">

    

        
        


        

        

        
        
            
                          ${approved}
        ]]>
            
        
        
            
                          ${!approved}
        ]]>
            
        

                             activiti:class="org.example.CallExternalSystemDelegate"/>
        


        

        

                             activiti:class="org.flowable.SendRejectionMail"/>
        

        

        

    

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

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

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)建的員工請(qǐng)假流程，參數(shù)就需要：員工姓名、請(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 variables = new HashMap();
variables.put("employee", employee);
variables.put("nrOfHolidays", nrOfHolidays);
variables.put("description", description);

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

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

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

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

查詢并審批任務(wù)

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

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

審批任務(wù)：

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

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

    
          ${approved}
]]>
    


    
          ${!approved}
]]>
    

回調(diào)用戶代碼

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

             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 語言開發(fā)的系統(tǒng)就也可以使用該引擎了。

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

部署工作流

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

啟動(dòng)工作流：

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

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

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

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

開源 VS 自研

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

開源優(yōu)勢：

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

開源劣勢：

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

自研優(yōu)勢：

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

自研劣勢：

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

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

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

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

開源項(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ù)流程模型和符號(hào)。

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

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

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

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

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

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

Activiti-Modeler

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

mxGraph

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

由于 mxGraph 是一個(gè)開放的 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)行選擇。

流程引擎

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

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

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

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

四、組織模型不屬于工作流系統(tǒng)的建設(shè)范圍，但流程設(shè)計(jì)器在建模的過程中會(huì)引用組織模型，如定義任務(wù)節(jié)點(diǎn)的參與者。還有就是在流程流轉(zhuǎn)的過程中同樣也需要引用組織模型，如在進(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)開放標(biāo)準(zhǔn)的 RESTful 服務(wù)。

后記

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

第一版

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

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

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

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

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

第二版

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

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

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

下一個(gè)版本

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

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

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

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

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

網(wǎng)站名稱：工作流引擎架構(gòu)設(shè)計(jì)
當(dāng)前URL：http://www.dlmjj.cn/article/cdeheci.html