1 什么是流程引擎

流程引擎是一個底層支撐平臺，是為提供流程處理而開發(fā)設(shè)計的。流程引擎和流程應(yīng)用，以及應(yīng)用程序的關(guān)系如下圖所示。

常見的支撐場景有：Workflow、BPM、流程編排等。本次分享，主要從 BPM 流程引擎切入，介紹流程引擎的架構(gòu)設(shè)計方法。

1.1 什么是流程

簡單來說，流程就是一系列活動的組合。比如，用于企業(yè)辦公的 OA 系統(tǒng)中，就存在大量的申請審批類的流程。在生產(chǎn)制造業(yè)，有大量的從銷售端的訂單，到生產(chǎn)制造，再到簽收回款的生產(chǎn)銷售流程。在機器學(xué)習領(lǐng)域，有亞馬遜 AWS Sagemaker 的大數(shù)據(jù)處理、機器學(xué)習的應(yīng)用。綜上，流程是一個概念，在和具體實現(xiàn)結(jié)合時，就產(chǎn)生了不同的流程產(chǎn)品，如 DevOps、Spring Data Stream 等。

在流程實現(xiàn)方面，主要可以分為 2 種實現(xiàn)方式，一種是用代碼實現(xiàn)，比如：用代碼實現(xiàn)一個加班申請，那么就要自己對接 SSO 進行單點登錄，通過接口拿到發(fā)起人和審批人的信息，同時保存表單數(shù)據(jù)。另一種方式是使用流程引擎來實現(xiàn)，流程引擎對接應(yīng)用場景所需數(shù)據(jù)，如加班申請，流程引擎對接 SSO、OU、審批人配置、權(quán)限等，實現(xiàn)這樣一個流程，只需要關(guān)心流程配置、流程節(jié)點和流程表單即可，流程流轉(zhuǎn)以及流程的數(shù)據(jù)處理，都通過流程引擎來完成。
流程引擎可以快速落地流程實現(xiàn)，這也是流程引擎存在的價值。

1.2 什么是引擎

一般而言，引擎是一個程序或一套系統(tǒng)的支持部分。常見的程序引擎有游戲引擎、搜索引擎、殺毒引擎等。引擎是脫離具體業(yè)務(wù)場景的某一類業(yè)務(wù)場景的高度抽象和封裝。

比如，某 OA 公司，封裝了一套審批用的 workflow，實施人員只需要配置流程和表單即可交付項目。再比如，美國某公司做了一個 AI 引擎做 NBA（Next Best Action）推薦，封裝了推薦領(lǐng)域的常用算法，在不同的場景自動選擇和組合多種算法，進行智能推薦。

1.3 流程設(shè)計器

流程設(shè)計器是流程和引擎的連接方，用戶通過流程設(shè)計器，將某種 layout 和 rule 固化成某種流程，然后通過數(shù)據(jù)和數(shù)據(jù)上下文，使用流程引擎自動按照某種固化的流程進行執(zhí)行。

我將目前見到的流程設(shè)計器的理論基礎(chǔ)，分為以下三類：1，自定義系；2，UML 中的活動圖系；3，BPMN 系。

1.3.1 自定義系

用于 Sagemaker 等場景的 AWS Step Function（自定義流程節(jié)點）

1.3.2 UML Activity Diagram

Flowportal BPM 的流程設(shè)計器

1.3.3 BPMN 系

activiti 的流程設(shè)計器

炎黃盈動的流程設(shè)計器

題外話：炎黃盈動的流程設(shè)計器，和 processon 中的流程設(shè)計器界面幾乎一樣，因為本質(zhì)上是一家的。

2 流程引擎的應(yīng)用

2.1 Workflow

工作流管理聯(lián)盟 (Workflow Management Coalition，WfMC) 作為工作流管理的標準化組織而成立。

WfMC 對工作流給出定義為：工作流是指一類能夠完全自動執(zhí)行的經(jīng)營過程，根據(jù)一系列過程規(guī)則，將文檔、信息或任務(wù)在不同的執(zhí)行者之間進行傳遞與執(zhí)行。

在 workflow 中，流程引擎主要用于支撐流程審批和數(shù)據(jù)流轉(zhuǎn)，應(yīng)用場景非常廣泛。

國外產(chǎn)品（開源或商用）通常需求和操作比較簡單，不會有國內(nèi)的需求那么復(fù)雜。國內(nèi)的產(chǎn)品，經(jīng)歷了眾多客戶的錘煉，功能目前都比較強大。

一般而言，workflow 使用場景最多的是 OA 產(chǎn)品。在 OA 辦公中，包含了企業(yè)辦公中的大量元素，這些元素足夠形成特定的產(chǎn)品，比如門戶系統(tǒng)、移動辦公。在 OA 的項目落地過程中，結(jié)合行業(yè)、業(yè)務(wù)側(cè)重點又可以形成行業(yè)解決方案和專題方案。

以下是某 OA 公司產(chǎn)品和解決方案。

2.2 BPM（Business Process Management）

Workflow 主要是解決審批和數(shù)據(jù)流轉(zhuǎn)，而 BPM 主要是解決端到端、信息孤島等問題而存在的。大多數(shù)用 BPM 產(chǎn)品的客戶，都是在 BPM 基礎(chǔ)上進行系統(tǒng)搭建，比如在 BPM 上面搭建 OA、CRM、HR 等系統(tǒng)。

BPM 的使用場景，比 Workflow 更廣泛，BPM 產(chǎn)品中包含大量的和第三方系統(tǒng)交互的組件和自定義 SQL、代碼組件。比如，BPM 系統(tǒng)中的文件觸發(fā)器，可以在海關(guān)等交互場景下，通過監(jiān)控 FTP 服務(wù)器中的文件，自動觸發(fā)流程實例；可以通過定時器 Timer，自動每日執(zhí)行數(shù)據(jù)同步，并通過 Mail 節(jié)點將同步結(jié)果通知到相關(guān)運營成員等。

BPM 的應(yīng)用，可以按照執(zhí)行前、執(zhí)行中和執(zhí)行后來劃分。

2.3 流程編排

流程編排是脫離流程業(yè)務(wù)領(lǐng)域的更高一層抽象，使用方可以通過流程編排系統(tǒng)，結(jié)合自己的業(yè)務(wù)場景進行業(yè)務(wù)定制。比如，可以將相關(guān)業(yè)務(wù)代碼，封裝成 function，然后通過云廠商平臺的 FAAS 平臺，將不同業(yè)務(wù)的 function 進行關(guān)聯(lián)和調(diào)度，從而完成某項任務(wù)。

3 流程引擎的架構(gòu)設(shè)計

鑒于一些朋友可能沒有使用和接觸過流程引擎，先介紹流程引擎的組成單元，再介紹基于某個 BPM 產(chǎn)品的項目是如何進行開發(fā)的。我們通過 BPM 項目開發(fā)，對流程引擎的作用有個初步的認識。

3.1 BPM 流程引擎的組成單元

組織、角色、用戶、成員的組織架構(gòu)托管；

流程資源文件的配置、校驗、存儲和執(zhí)行，對不同的流程節(jié)點，流程引擎自動結(jié)合配置、數(shù)據(jù)處理其對應(yīng)的業(yè)務(wù)邏輯，流程數(shù)據(jù)自動處理；

表單配置、數(shù)據(jù)綁定，表單數(shù)據(jù)的根據(jù)流程配置自動處理；

通用的數(shù)據(jù)接口；

3.1.1 組織架構(gòu)的設(shè)計

3.1.2 流程設(shè)計器

流程設(shè)計器包含左側(cè)的分組節(jié)點列表，和右側(cè)的畫布。左側(cè)的節(jié)點可以如下進行設(shè)計。

問題：對于一個 XML 或 JSON 格式的流程圖，如何進行解析？

不同的節(jié)點，按照不同的業(yè)務(wù)場景，配置不同的配置項。比如，對于 Human Node 需要配置審批人，配置審批環(huán)節(jié)的展示表單，審批環(huán)節(jié)能夠修改哪些字段，哪些字段的修改要進行留痕等。

3.1.3 表單設(shè)計器

這種是按照表單相關(guān)數(shù)據(jù)表，生成出一個表單，然后對表單字段進行配置和數(shù)據(jù)綁定。

這種是 Drag&Drop 控件，然后配置控件的屬性，如綁定字段等。

這種是 Drag&Drop 控件，無需關(guān)聯(lián)數(shù)據(jù)庫表字段的表單

數(shù)據(jù)表生成表單的概要流程如下圖所示。

拖拽控件綁定數(shù)據(jù)表字段的概要流程如下。

拖拽控件無需綁定數(shù)據(jù)表字段的概要流程。使用 NoSQL 的 Document 記錄或使用 RDS 提供的 JSON 類型進行保存會比較方便。

3.1.4 接口設(shè)計

結(jié)合 Activity 的接口設(shè)計，如下圖所示

一些系統(tǒng)在創(chuàng)建一個流程任務(wù)的時候，要先按照流程模板先創(chuàng)建一個應(yīng)用示例，再關(guān)聯(lián)發(fā)起人和備注，調(diào)用 RuntimeService，執(zhí)行到 StartNode，這類設(shè)計因人而異，這么做略顯繁瑣。

3.2 基于流程引擎的項目開發(fā)實踐

3.2.1 流程項目實踐流程

確定組織架構(gòu)

確定流程，包括流程布局、審批人設(shè)置、權(quán)限

確定表單信息（字段、類型、數(shù)據(jù)源、校驗規(guī)則）和表單樣式

確定頁面布局、樣式、數(shù)據(jù)字段、搜索、導(dǎo)入、導(dǎo)出

報表

3.2.2 組織架構(gòu)

組織架構(gòu)實現(xiàn)，有兩種方法，一種是按照維度進行數(shù)據(jù)管理，另一種是在同一棵組織架構(gòu)樹下進行管理。

按照集團、公司、部門、用戶等不同維度，進行數(shù)據(jù)管理，比較常見，這里不做討論。下圖為按維度維護數(shù)據(jù)的示例。

按照同一棵組織架構(gòu)樹進行數(shù)據(jù)維護，界面一般顯示為左樹右表。大多數(shù)商業(yè)化產(chǎn)品，都會將此組織架構(gòu)樹進行內(nèi)存緩存，以方便審批人查找、開窗選擇 OrgUnit、Role、User、Member 等場景。Member 的引入是為了解決一人多職等場景。一般發(fā)起流程的時候，需要帶出發(fā)起人擁有的 Member 列表，從而后續(xù)節(jié)點取合適的審批人。

對于組織架構(gòu)而言，需要考慮，系統(tǒng)本身要具備 OU 存儲的能力，對于沒有組織架構(gòu)的用戶，可以直接在系統(tǒng)的組織架構(gòu)中新建組織架構(gòu)。同時，對于已有系統(tǒng)的客戶，可以通過組織架構(gòu)數(shù)據(jù)同步來進行數(shù)據(jù)自動維護。對于用 AD 域內(nèi)部管控的客戶來說，需要具備 AD 域身份認證的能力。對于復(fù)雜場景，比如用戶是 SaaS 化等復(fù)雜場景，組織架構(gòu)也需要在系統(tǒng)內(nèi)部，支持使用 API 的方式來獲取組織信息。

所以在組織架構(gòu)設(shè)計的時候，要使用插件的方式來做，具體使用哪種插件，可以在配置文件中進行配置。以下為一個商業(yè)產(chǎn)品的組織架構(gòu)操作界面示例。

常見的組織架構(gòu)操作還有組織架構(gòu)同步，比如流程系統(tǒng)同步微信企業(yè)號、釘釘?shù)龋@里不再展開。

3.2.3 流程設(shè)計

我們想象的流程，可能是向下面的這種簡單流程。

而實際項目，碰到的流程，一般是如下圖所示的情景。

初步看幾個流程的模型文件是什么樣的，先有個印象。

${employeeName} would like to take ${numberOfDays} day(s) of vacation (Motivation: ${vacationMotivation}).










management






${vacationApproved == 'true'}





${vacationApproved == 'false'}



Your manager has disapproved your vacation request for ${numberOfDays} days.
Reason: ${managerMotivation}












${employeeName}






${resendRequest == 'true'}


${resendRequest == 'false'}

一個屏幕截圖都截不完的流程，如果用代碼去實現(xiàn)整個流程，其工作量和效率，可想而知。而實際做項目，使用基于流程引擎的產(chǎn)品來做項目的時候，只需要確定節(jié)點、節(jié)點配置、數(shù)據(jù)配置和權(quán)限即可。

問題：一般流程，都帶有郵件通知的節(jié)點，如何實現(xiàn)郵件通知節(jié)點？請考慮以下情景。

流程流轉(zhuǎn)和執(zhí)行的時候，會遇到各種情況的錯誤，比如找不到審批人等，此時流程引擎要對數(shù)據(jù)做 rollback，而郵件通知節(jié)點的業(yè)務(wù)邏輯已經(jīng)執(zhí)行過了。

權(quán)限方面，對于流程資源，哪些部門可以申請，哪些角色不可申請，都應(yīng)該做流程控制。而在流程執(zhí)行過程中，流程數(shù)據(jù)、不是路程的相關(guān)人也都不應(yīng)該看到流程，處理過流程的審批人，不可以再對流程進行處理等，都是權(quán)限方面要考慮的問題。

3.2.4 表單設(shè)計

如下圖所示的表單，可以分析以下，一個流程表單有多個主表信息和多個子表信息。一般而言，如果是通過流程引擎做非流程的數(shù)據(jù)處理，子表通過主表 ID 來做關(guān)聯(lián)，如果通過流程引擎做流程的數(shù)據(jù)處理，子表和主表通過 TaskId 來做關(guān)聯(lián)。以下為示例。

流程系統(tǒng)需要表單設(shè)計器，一個流程的不同節(jié)點可以掛接不同的表單，以方便不同角色的人關(guān)注不同維度的流程信息

3.2.5 頁面設(shè)計

一般而言，對于流程的發(fā)起、審批、歷史記錄等，都是通用的系統(tǒng)界面。而一些業(yè)務(wù)場景，需要單獨做列表界面，以方便使用。對于已有門戶系統(tǒng)的客戶，需要融合其界面樣式。以下為曾經(jīng)做過的項目示例。

3.2.6 報表

由于不是所有客戶都有報表系統(tǒng)，所以流程系統(tǒng)需要具備一個基本的報表功能。下圖為示例。

有報表系統(tǒng)的客戶，可以使用其商業(yè)版報表系統(tǒng)，獲取（直接取、數(shù)倉）數(shù)據(jù)進行展示。常見的報表系統(tǒng)有 FineReport、Tableau、PowerBI 等。

3.3 BPM 流程引擎架構(gòu)設(shè)計

3.3.1 流程引擎的架構(gòu)設(shè)計

3.3.2 發(fā)起流程

流程引擎處理過程

執(zhí)行節(jié)點處理過程

問題：在流程引擎處理過程中，如果一個節(jié)點有多條連線，如何尋找 FromNodeId 是某個 Node 的連線？

人工處理時，指定連線 text

3.4 流程引擎架構(gòu)設(shè)計

3.4.1 業(yè)務(wù)識別

識別業(yè)務(wù)場景中的配置項，使用集合或分組的方式，讓業(yè)務(wù)可配置

支撐業(yè)務(wù)流程過程的可配置化

支撐業(yè)務(wù)場景中的數(shù)據(jù)，自動處理

3.4.2 流程引擎的實現(xiàn)

資源相關(guān)服務(wù)，資源加載，資源保存，資源加密等

配置項相關(guān)服務(wù)

PVM 虛擬機的實現(xiàn)，即通過某個節(jié)點（發(fā)起時為開始節(jié)點）作為初始節(jié)點，按照某個連線的 action 進行節(jié)點的自動執(zhí)行的虛擬機

數(shù)據(jù)配置、數(shù)據(jù)權(quán)限

流程數(shù)據(jù)和業(yè)務(wù)數(shù)據(jù)的自動處理

4 商業(yè)機會

Business Process Analysis (BPA) 流程分析，幫助企業(yè)進行流程調(diào)整和優(yōu)化

Process Assets Library（PAL）流程資產(chǎn)庫，對企業(yè)流程進行知識化沉淀，將制度和流程落地做綁定，讓審批人知曉流程中對應(yīng)的職責

Process Simulate 流程模擬，自動化測試

Process Forecast 流程預(yù)測

低代碼平臺

更廣泛的機會，在于業(yè)務(wù)領(lǐng)域 + 流程引擎，比如：DevOps、RPA、應(yīng)用與服務(wù)編排、數(shù)據(jù)編排、FaaS 編排等。

審核編輯：劉清