通過 Flowable-UI 來體驗一把 Flowable 流程引擎

語言: CN / TW / HK

[TOC]

本文為稀土掘金技術社群首發簽約文章,14天內禁止轉載,14天后未獲授權禁止轉載,侵權必究!

本專欄第一篇已釋出,尚未看過的小夥伴請移步這裡:

  1. Flowable 開篇,流程引擎掃盲

在我們使用 Flowable 的過程中,最重要的流程繪製工具就是 Flowable-UI 了,雖然我們在上篇文章和大夥也介紹了不少流程繪製工具,但是個人感覺,還是 Flowable-UI 更好用一些。

今天我們就來聊聊 Flowable-UI 的一些玩法。

1. Flowable-UI

Flowable-UI 說白了就是一堆 Web 應用,它主要提供了四方面的功能:

  • Flowable IDM: 身份管理應用。為所有 Flowable UI 應用提供單點登入認證功能,並且為擁有 IDM 管理員許可權的使用者提供了管理使用者、組與許可權的功能。
  • Flowable Modeler: 讓具有建模許可權的使用者可以建立流程模型、表單、選擇表與應用定義。
  • Flowable Task: 執行時任務應用,這個提供了啟動流程例項、編輯任務表單、完成任務,以及查詢流程例項與任務的功能。
  • Flowable Admin: 管理應用。讓具有管理員許可權的使用者可以查詢 BPMN、DMN、Form 及 Content 引擎,並提供了許多選項用於修改流程例項、任務、作業等。管理應用通過 REST API 連線至引擎,並與 Flowable Task 應用及 Flowable REST 應用一同部署。

簡單來說:

  • 建立使用者、分配角色用 Flowable IDM。
  • 畫流程圖使用者 Flowable Modeler。
  • 測試、體驗流程用 Flowable Task。
  • 後臺管理相關的用 Flowable Admin。

2. 安裝方式

在之前的版本中,前面說的這幾個應用都是不同的 war 包,部署和訪問都非常麻煩,不過現在,官方將之前的 5 個 war 整合成一個了,所以現在訪問就非常容易了。

2.1 執行 war 包

由於這些應用是基於 Spring Boot2.0 開發的,因此也可以直接作為獨立應用來直接執行,通過執行 java -jar xxx.war 的方式來啟動這些應用。

這個需要大家首先去 GitHub 上下載最新的 Flowable:

下載成功之後解壓,裡邊有一個 wars 資料夾,該資料夾中就有我們需要的 war 包,如下:

然後進入到該目錄中,執行如下命令啟動該 war 檔案:

shell java -jar flowable-ui.war

從啟動到日誌中我們就可以看出來這是一個 Spring Boot:

既然是一個 Spring Boot,那麼如果又一些引數想改,就可以直接在啟動命令中修改,例如預設的埠號是 8080,現在想改為 8088,那麼就在啟動命令中新增引數 --server.port=8088 即可。

所以直接啟動這些應用並不是麻煩事,反而是比較簡單的。

需要說明的是,有的小夥伴在網上看到的教程裡邊可能提到了多個 war 包,這是因為 Flowable 的歷史問題,早期的 Flowable 上面我們說的四個功能都對應了不同的 war 包,要單獨部署,但是在新版中合成一個了,新版用起來相對更方便一些。

2.2 docker 安裝

我看了下他這個還支援 Docker 安裝,所以我還是用 Docker 吧,更省事,將來不想要了刪除也方便(對 Docker 不熟悉的小夥伴可以在微信公眾號後臺回覆 docker,有鬆哥寫的入門教程)。

docker 安裝的話,直接如下命令即可:

shell docker run -d --name flowableui -p 8086:8080 flowable/flowable-ui

沒什麼特別需要配置的地方,指定一下容器名字和埠對映即可。

2.3 訪問

無論是直接執行還是 Docker 執行,執行成功之後,瀏覽器輸入 http://localhost:埠/flowable-ui 進行訪問,此時會彈出來如下頁面:

預設情況下,登入的使用者名稱是 admin,密碼是 test,注意別把密碼寫錯了。

登入成功之後,如果看到如下頁面,就表示安裝成功了(一般來說應該不會有安裝問題):

裝好之後,接下來我們就來逐步體驗這裡的功能,因為之前和小夥伴們講過這裡的大部分功能了,所以今天我主要和大家講講這裡的身份管理和流程體驗功能(因為流程體驗中要用到身份管理)。

3. 身份管理(IDM)

身份管理就是使用者、使用者組的管理,我們點進到身份管理頁面之後,可以看到如下內容:

可以看到,預設只有一個 admin 使用者,也就是我們剛剛登入時候的使用者。

3.1 使用者管理

接下來點選左邊的建立使用者按鈕,我們可以建立新的使用者出來:

填入使用者的基本資訊和密碼即可。

我一共建立了四個使用者,最終結果如下:

3.2 組管理

接下來點選上面的,我們可以建立使用者組,這個使用者組相當於我們在 vhr 中所說的角色,給使用者分組,相當於給使用者分配一個角色。

預設情況下,沒有任何組,組是空的:

我們點選建立組按鈕,先來建立一個經理組:

組新增成功之後,點選新增使用者按鈕,為使用者組中新增使用者:

假設 zhangsan 是經理,最終新增結果如下:

利用相同的方式,我再建立一個主管的組,併為之新增兩個使用者 lisi 和 wangwu。

3.3 許可權控制

我們前面建立的使用者現在是沒有任何許可權的,例如現在如果使用 zhangsan/123 進行登入,登入成功後頁面是空的,沒有任何東西:

所以我們要為使用者新增相應的許可權。點選頂部的許可權控制一欄,如下:

我們可以為這五種訪問分別設定對應的使用者/使用者組:

  • 訪問 idm 應用:這個就是訪問身份管理應用,如果使用者沒有訪問這個的許可權,那麼使用者在登入成功的後的首頁上就看不到身份管理應用程式這個選單項。
  • 訪問 admin 應用:這個是訪問管理員應用程式,如果沒有沒有這個的訪問許可權,那麼使用者在登入成功之後的首頁上就看不到管理員應用程式這個選單項。
  • 訪問 modeler 應用:這個是訪問建模器應用程式,如果沒有沒有這個的訪問許可權,那麼使用者在登入成功之後的首頁上就看不到建模器應用程式這個選單項。
  • 訪問 workflow 應用:這個是訪問任務應用程式,如果沒有沒有這個的訪問許可權,那麼使用者在登入成功之後的首頁上就看不到任務應用程式這個選單項。
  • 訪問 REST API:這個是指使用者通過 REST API 訪問工作流的許可權。

以訪問 idm 應用為例,在設定的時候,我們可以直接設定使用者,也可以設定使用者組,設定使用者組的話,則這個組中的所有使用者都能訪問這個選單項。

我這裡設定的是經理和 javaboy 可以訪問所有應用,而主管只可以訪問 workflow 應用。

好啦,準備工作完成後,接下來我們就來繪製一個報銷的流程圖,這個流程圖稍微複雜一些,並且帶有表單,這是鬆哥之前從未寫過的內容。

4. 流程圖繪製

我先大致上用文字描述下我們的報銷流程:

  1. 啟動一個流程。
  2. 員工填寫報銷單,然後進行提交。
  3. 如果報銷金額小於等於 1000 元,則主管審批,主管審批通過後,流程結束;主管審批拒絕,則回到步驟 2 中員工重新填寫報銷單。
  4. 如果報銷金額大於 1000 元,則先由經理進行審批,經理審批通過後,再由 CEO 審批,兩者都審批通過,則流程結束;經理和 CEO 任意一個審批不通過,則流程重新回到步驟 2 中。

好啦,這就是我們一個大致的流程描述,接下來我們就在 Flowable-UI 中來繪製這樣一個流程圖我們來看下。

首先點選建模器應用程式,我們開始繪製:

點選右上角建立流程,建立一個流程:

然後就開始繪製。

首先第一步是使用者提交報銷材料,報銷材料需要填寫一個表單,所以我們在下面的屬性中,找到表單引用,為這個使用者任務設定一個外部表單:

如果有提前繪製好的表單,這裡就會顯示出來,那麼直接引用即可,如果沒有提前繪製好的表單,那麼大家看到的就如同上圖那樣。

現在我們點選新表單,建立一個新表單:

為新表單設定名稱、key 等內容:

建立成功之後,我們就可以看到表單設計頁面了:

左邊是表單元件區域,右邊是表單繪製區域。思考使用者需要提交哪些資訊來報銷,直接將相應的表單拖過來即可。

其實大家看最上面一欄的頂部選單,也自動切換到表單選單了,這也就意味著,當我們想要建立一個表單的時候,也可以不用從流程繪製那個入口進來,可以直接提前繪製好表單,然後在畫流程的時候直接引用即可。

例如我首先拖一個文字框過來,作為使用者名稱,然後點選右邊的編輯按鈕進行編輯,如下:

有如下屬性:

  • 標籤:這個文字框將來展示的資訊。
  • 覆蓋 id:勾上這個,就可以自定義 id 了,否則 id 和標籤是一樣的。
  • id:這個是這個元件的唯一名稱,將來在程式碼中,如果我們想要獲取這個表單的值,就需要通過這個 id 去訪問。
  • 設定表單是否只讀或者必填。
  • 預設值:這個相當於是這個表單的 placeholder。

好了,理解了這個,我們再來隨便加兩個元件,按照相同的思路進行配置:

報銷金額,這是一個小陣列件:

報銷用途是一個多行文字元件:

最終設計結果如下:

標籤後面有一個 * 表示這是一個必填項。

繪製完成後,點選左上角的儲存按鈕,儲存成功後,會自動回到流程繪製頁面。

接下來,我們還需要設定這個使用者任務由誰來處理,如下:

很明顯,這個流程是誰發起的,誰就來填寫這個表單,所以,配置如下:

好了,這個使用者任務就配置完成了,接下來要根據報銷金額進行劃分了,我一口氣畫完吧,再來和大家逐步分析:

先來看報銷金額小於等於 1000 的那條線。

首先,我們要為這條線設定條件,也就是流程從互斥閘道器中出來之後,什麼情況下會進入到主管審批這個節點中,選中這條出線,配置流條件,配置如下:

這裡的 money 就是我們剛剛在表單中填寫的 money,表單中各個欄位的值,都會被對映成為一個流程變數,我們可以直接訪問。

接下來配置主管審批,首先我們設定分配使用者,即由誰來執行這個使用者任務:

我們設定候選組為主管,也就是所有的主管都可以審批這個節點:

主管審批的時候,無非就是同意或者拒絕,通過表單我們可以定義出同意或者拒絕這兩個按鈕。配置方式如下,首先為主管審批設定表單引用:

給這個新建的表單取一個名字和 id,這個 id 大家要記牢了,將來我們會用到:

在表單設計的頁面,有一個結果選項卡,這個表示表單的輸出內容,這個結果選項卡決定了這個表單上的最終按鈕,預設情況下,只有一個完成按鈕,我們可以自定義配置:

我們為這個表單設定同意和拒絕兩個按鈕,方式如下:

這塊也有其他設定方式,我就先以這種方式來和大家演示,將來在視訊中再來和大家聊一聊其他方式。

表單配置完成後,儲存即可,儲存之後,就會回到流程繪製頁面。

接下來為同意這條出線設定條件:

大家注意這個表單的命名規則,是 form_表單名稱_outcome 這個就表示表單的輸出結果,也就是我們剛剛在表單中配置的結果選項卡中的內容:

配置完成後,相同的方式,將同意改為拒絕,再來配置一下拒絕那條線。

好啦,上面這條線配置好之後,接下來相同的方式配置下面大於 1000 的情況,其中經理這個使用者任務就由經理這個組來處理,CEO 審批這個使用者任務就由指定使用者 javaboy 來審批即可,具體細節我就不多說了,都跟上面一樣。

繪製完成後,記得點一下左上角的勾,看下流程有沒有漏洞,如下圖:

至此,我們的流程圖就畫好了。

一個流程圖只能有一個開始,但是可以有多個結束。

5. 建立應用

流程圖畫好之後,接下來我們可以下載這個流程圖對應的 XML 檔案,然後去開發自己的 Java 程式碼。但是,這不是我們本文的工作,本文的工作是直接在 Flowable-UI 這個工具中,建立一個應用,然後釋出這個流程。

點選上面的應用程式選單,然後點選右上角的建立應用程式按鈕,如下:

接下來可以為你的應用設定圖示、主題啥的:

然後點選編輯包含的模型按鈕,為這個應用選擇一個流程:

然後點選左上角的儲存按鈕,儲存併發布這個應用,如下:

釋出成功之後,回到首頁,就可以看到這個應用了,如下:

6. 體驗報賬

接下來我們就來體驗一把這個報賬流程,我們目前的身份是 admin,也就是說 admin 這個使用者現在要報賬了。

首先點選應用圖示,進入到應用中,任務是空的,也就是目前沒有 admin 需要審批的任務:

然後我們點選上方的流程選單,如下:

首先點選左邊的啟動流程,然後點選右邊的啟動流程,流程啟動之後,我們可以點選右上角的顯示圖按鈕,檢視流程目前走到哪一步了:

可以看到,流程目前走到使用者提交報銷材料這一步了:

使用者提交報銷材料這一步是由流程的發起人完成的,也就是 admin 自己完成,此時我們回到任務選單,就可以看到 admin 有需要完成的任務了:

填入報銷資料,然後點選完成按鈕。

接下來再點選流程選單,檢視流程圖,可以看到,此時進入到主管審批這一步了:

按照我們第 3 小節的配置,lisi 和 wangwu 是主管,所以,我們先登出登入,然後重新以 lisi 或者 wangwu 的身份登入,假設我這裡以 lisi 的身份登入,登入成功之後,進入到這個應用中,進來之後,首先將篩選規則改為我是其中一個候選人的任務:

然後在任務中就可以看到自己需要處理的任務了:

對於這種候選人或者候選組的任務,需要先點選右上角的認領,然後再處理(如果是直接分配給某一個使用者的,就不需要認領了,可以直接處理了),認領之後,就可以選擇同意或者拒絕了,如下圖:

假設我們點選拒絕按鈕,拒絕之後,我們點選流程選單,檢視流程圖,如下:

可以看到,流程在進入到主管審批這個節點之後,被拒絕了,然後回到了使用者提交報銷材料這個節點上,現在 admin 要重新登入,登入之後,在自己的任務中又可以看到提交報銷材料了,如下:

隨便改一下,然後繼續提交。

切換到 wangwu 登入,同意報銷,流程結束。

好啦,下面那條超過 1000 塊錢的線,小夥伴們可以自行測試,我就不演示啦~

7. 資料表分析

對於前面的案例,資料都存入到哪裡去了呢?我們也來分析下。

如果是 war 包直接啟動的話,它預設使用的是 H2 資料庫,資料存在了系統當前使用者目錄下的 h2 資料夾裡,我們通過 h2 資料庫的連線工具即可操作這個資料庫。IDEA 上自帶的資料庫連線工具就可以連線 H2 資料庫,這裡我就不演示具體連線方式了,我們來看下錶的查詢:

sql SELECT COUNT(*) TABLES, table_schema FROM information_schema.TABLES WHERE table_schema = 'flowable02' GROUP BY table_schema;

這裡顯示了 82 張表,是因為我自己手動建立了三個跟使用者相關的表,其他 79 張表都是 Flowable 自動建立的。

好了,接下來我們就對這 79 張表進行一個簡單的分類整理。

  1. ACT_APP_*(5)
  2. ACT_CMMN_*(12)
  3. ACT_CO_*(3)
  4. ACT_DMN_*(6)
  5. ACT_EVT_*(1)
  6. ACT_FO_*(6)
  7. ACT_GE_*(2)
  8. ACT_HI_*(10)
  9. ACT_ID_*(9)
  10. ACT_PROCDEF_*(1)
  11. ACT_RE_*(3)
  12. ACT_RU_*(13)
  13. FLW_CHANNEL_*(1)
  14. FLW_EV_*(2)
  15. FLW_EVENT_*(3)
  16. FLW_RU_*(2)

* 是萬用字元,後面的數字表示這種型別的表有多少個。

大致看一下,其實還是有很多規律的。

最明顯的規律就表名通過兩個 _ 隔開成了三部分,接下來我們就以此為線索,一部分一部分來講。

7.1 表名字首

首先搭建看這個表的字首,分了兩種:

  • ACT_
  • FLW_

鬆哥在之前的文章中已經和大家介紹過了,Flowable 是基於 Activiti 開發出來的流程引擎,所以我們在很多地方都還能看到 Activiti 的影子,這個表名中 ACT_ 就是 Activiti。

具體來說,與 Flowable 開原始碼庫相關的資料庫表名以 ACT_ 開頭。特定於 Flowable Work 或 Engage 的資料庫表以 FLW_ 字首開頭。

7.2 表名中間部分

緊跟著 ACT_ 或者 FLW_ 後面的內容,基本上也都是簡稱,例如:

  • APP 表示這都是跟應用程式相關的表。
  • CMMN 表示這都是跟 CMMN 協議相關的表。
  • CO(CONTENT)表示這都是跟內容引擎相關的表。
  • DMN 表示這都是跟 DMN 協議相關的表。
  • EVT(EVENT)表示這都是跟事件相關的表。
  • FO(FORM)表示這都是跟表單相關的表。
  • GE(GENERAL)表示這都是通用表,適用於各種用例的。
  • HI(HISTORY)這些是包含歷史資料的表。當從執行時表中刪除資料時,歷史表仍然包含這些已完成例項的所有資訊。
  • ID(IDENTITY)表示這都是跟使用者身份認證相關的表。
  • PROCDEF(PROCESSDEFINE) 表示這都是跟記錄流程定義相關的表。
  • RE(REPOSITORY)表示這都是跟流程的定義、流程的資源等等包含了靜態資訊相關的表。
  • RU(RUNTIME)代表執行時,這些是包含尚未完成的流程、案例等的執行時資料的執行時表。Flowable 僅在執行期間儲存執行時資料,並在例項結束後刪除記錄,這使執行時表保持小而快。
  • CHANNEL 表示這都是跟泳道相關的表。
  • EV 表示這個是跟 FLW_ 搭配的,在這裡似乎並沒有一個明確的含義,相關的表也都是跟 Liquibase 相關的表。
  • EVENT 表示這都是跟事件相關的表。

把這些簡稱的單詞搞明白了,接下來的就容易看懂每一個表的含義了。

表名是由三部分構成的,我們現在已經分析了前兩部分了,接下來我們來看第三部分。

7.3 表名字尾

表名的字尾,有一些是通用的字尾名詞,我們先來看下。

  • DATABASECHANGELOG:表名中包含這個單詞的,表示這個表是 Liquibase 執行的記錄,Liquibase 是一個數據庫指令碼管理的工具,有點像 flyway,鬆哥之前寫過 flyway 的文章,我這裡就不囉嗦了。包含 DATABASECHANGELOG 字尾的表一共是 6 張。
  • DATABASECHANGELOGLOCK:表名中包含這個單詞的,表示這個表記錄 Liquibase 執行鎖的,用以確保一次只執行一個 Liquibase 例項,包含 DATABASECHANGELOGLOCK 字尾的表也是 6 張。

這兩個加起來就 12 張表了,一共 79 張,現在還剩 67 張,我們來詳細看下。

在後面的介紹中,凡是涉及到 DATABASECHANGELOG 和 DATABASECHANGELOGLOCK 的表,我就直接省略了。

7.3.1 ACT_APP_*

ACT_APP_* 開頭的表負責應用引擎儲存和應用部署定義。相關的表一共是五張,如下:

ACT_APP_APPDEF

應用程式模型產生應用程式定義。此定義,如流程/案例/等。是成功部署到應用引擎的應用模型的表示。

ACT_APP_DEPLOYMENT

當通過應用引擎部署應用模型時,會儲存一條記錄以儲存此部署。部署的實際內容被儲存在 ACT_APP_DEPLOYMENT_RESOURCE 表中,並從該表中引用。

ACT_APP_DEPLOYMENT_RESOURCE

此表包含構成應用程式部署的實際資源(儲存為位元組)。當引擎需要實際模型時,將從該表中獲取資源。

7.3.2 ACT_CMMN_*

Flowable CMMN Engine 的資料庫名稱都以 ACT_CMMN_ 開頭。這裡涉及到一個東西就是 CMMN,CMMN 與 BPMN 協議一致,也是一種流程內容的規範,CMMN 這類表一般用於儲存處理 BPMN 所不能適用的業務場景資料,CMMN 通常與 BPMN 搭配使用,不過只有符合 CMMN 規範的模型資料才會使用這類表。

這裡涉及到的相關表一共是 12 張,如下:

  • ACT_CMMN_CASEDEF
  • ACT_CMMN_DEPLOYMENT
  • ACT_CMMN_DEPLOYMENT_RESOURCE

這三個都是沒有附加字首的表,主要定義了靜態資訊,例如 case 的定義和部署和以及相關的資源等。

接下來這些以 ACT_CMMN_HI_ 開頭的表代表歷史資料,例如過去的案例例項、計劃專案等。

ACT_CMMN_HI_CASE_INST

此表記錄由 CMMN 引擎啟動的每個案例例項的資料。

ACT_CMMN_HI_MIL_INST

此表記錄了在案例例項中達到的每個里程碑的資料。

ACT_CMMN_HI_PLAN_ITEM_INST

此表記錄了作為案例例項執行的一部分建立的每個計劃項例項的資料。

接下來以 ACT_CMMN_RU_ 開始的表代表執行時的資料,這些資料包含案例例項、計劃項等的執行時資料。Flowable 僅在案例例項執行期間儲存執行時資料,並在案例例項結束時刪除記錄,這使執行時表保持小且查詢速度快。

ACT_CMMN_RU_CASE_INST

此表包含每個已啟動但尚未完成的案例例項的條目。

ACT_CMMN_RU_MIL_INST

此表包含作為執行案例例項的一部分達到的每個里程碑的條目。

ACT_CMMN_RU_PLAN_ITEM_INST

案例例項執行由案例定義中定義的計劃項的多個例項組成,此表包含在案例例項執行期間建立的每個例項的條目。

ACT_CMMN_RU_SENTRY_PART_INST

計劃專案例項可以有守衛狀態轉換的哨兵,這樣的哨兵在狀態改變之前可以包含多個部分,這個表就是專門用來儲存這種哨兵。

7.3.3 ACT_DMN_*

Flowable DMN 的資料庫名稱都以 ACT_DMN_ 開頭,這裡涉及到的表一共是 6 張:

  • ACT_DMN_DEPLOYMENT
  • ACT_DMN_DEPLOYMENT_RESOURCE

這兩個是就不需要我多說了吧,跟前面的都一樣,只不過這裡部署的是 DMN。

ACT_DMN_DECISION

此表包含已部署決策表的元資料,並與來自其他引擎的定義相對應。

ACT_DMN_HI_DECISION_EXECUTION

此表包含有關 DMN 決策表執行的審計資訊。

7.3.4 ACT_RU_*

ACT_RU_ 開頭的表都是和流程引擎執行時資訊相關的一些表。涉及到的表一共有 13 張:

ACT_RU_ACTINST

流程例項中的每個活動在此表中都有一行來指示活動的當前狀態。

  • ACT_RU_JOB
  • ACT_RU_TIMER_JOB
  • ACT_RU_SUSPENDED_JOB
  • ACT_RU_EXTERNAL_JOB
  • ACT_RU_HISTORY_JOB
  • ACT_RU_DEADLETTER_JOB

Flowable 引擎使用作業表來實現非同步邏輯、計時器或歷史處理。這些表儲存每個作業所需的資料。

ACT_RU_ENTITYLINK

此表儲存有關例項的父子關係的資訊。例如,如果流程例項啟動子案例例項,則此關係儲存在此表中。這樣可以輕鬆查詢關係。

ACT_RU_EVENT_SUBSCR

當流程定義使用事件(訊號/訊息/等或啟動/中間/邊界)時,引擎將對該表的引用儲存在該表中。這簡化了查詢哪些例項正在等待某種型別的事件。

ACT_RU_EXECUTION

儲存流程例項和指向流程例項當前狀態的指標(稱為執行)。

ACT_RU_IDENTITYLINK

此表儲存有關使用者或組的資料及其與(流程/案例/等)例項相關的角色。該表也被其他需要身份連結的引擎使用。

ACT_RU_TASK

此表包含正在執行的例項的每個未完成使用者任務的條目。然後在查詢使用者的任務列表時使用此表。CMMN 引擎也使用此表。

ACT_RU_VARIABLE

此表儲存與例項相關的變數。 CMMN 引擎也使用此表。

7.3.5 ACT_HI_*

ACT_HI_* 開頭的表包含正在執行和已完成的例項的歷史資料,這些表的名稱遵循其執行時對應的名稱,這裡一共涉及到 10 張表:

ACT_HI_ACTINST

歷史活動資訊。這裡記錄流程流轉過的所有節點,與 ACT_HI_TASKINST 不同的是, ACT_HI_TASKINST 只記錄 Task 內容。

ACT_HI_ATTACHMENT

歷史附件表。

ACT_HI_COMMENT

流程的歷史評論表。

ACT_HI_DETAIL

歷史詳情表:流程中產生的變數詳細,包括控制流程流轉的變數,業務表單中填寫的流程需要用到的變數等。

ACT_HI_ENTITYLINK

歷史參與的人員表。

ACT_HI_IDENTITYLINK

任務參與者資料表,主要儲存歷史節點參與者的資訊,可能是 Group 也可能是 User。

ACT_HI_PROCINST

儲存每一個歷史流程,建立時就生成,一條流程例項對應一個記錄。

ACT_HI_TASKINST

記錄每一個歷史節點,一個 Task 對應一個記錄。

ACT_HI_TSK_LOG

每一次執行可能會帶上資料,存在這裡。

ACT_HI_VARINST

流程歷史變量表。

7.3.6 ACT_ID_*

ACT_ID_* 開頭的都是和使用者身份相關的表,一共是有 9 張表:

ACT_ID_BYTEARRAY

這是使用者組的部署內容。

ACT_ID_GROUP

這是使用者組的表。

ACT_ID_INFO

這是所有的使用者的資訊,賬號密碼。

ACT_ID_MEMBERSHIP

使用者和使用者組的關聯表。

ACT_ID_PRIV

許可權表。

ACT_ID_PRIV_MAPPING

使用者、使用者組以及許可權之間的關聯表。

ACT_ID_PROPERTY

使用者的變量表。

ACT_ID_TOKEN

使用者訪問記錄表。

ACT_ID_USER

使用者表。

7.3.7 ACT_FO_FORM_*

ACT_FO_FORM_ 開頭的表儲存表單引擎和圍繞表單模型和這些表單的例項資料。

ACT_FO_FORM_DEFINITION

表單定義表。

ACT_FO_FORM_DEPLOYMENT

表單部署表。

ACT_FO_FORM_INSTANCE

表單例項表。

ACT_FO_FORM_RESOURCE

表單源資料表。

7.3.8 ACT_GE_*

ACT_GE_ 開頭的表表示一些通用資訊表,涉及到的表一共是兩個。

ACT_GE_BYTEARRAY

儲存每個流程的部署記錄,bytes_ 欄位中儲存流程的具體內容。

ACT_GE_PROPERTY

儲存 Flowable 自身的一些變數,主要是版本號。

7.3.9 ACT_RE_*

ACT_RE_ 開頭的表表示這些表都是跟流程的定義、流程的資源等等包含了靜態資訊相關的表。

ACT_RE_DEPLOYMENT

流程部署記錄,每次服務重啟會部署一次,這裡會新增一條記錄。

ACT_RE_MODEL

建立模型時,額外定義的一些模型相關資訊,存在這張表,預設不儲存。

ACT_RE_PROCDEF

記錄流程的變更,流程每變更一次存一條記錄,version_ 欄位加 1。

7.3.10 FLW_EVENT_*

FLW_EVENT_DEFINITION

已部署事件定義的元資料。

FLW_EVENT_DEPLOYMENT

已部署事件部署元資料。

FLW_EVENT_RESOURCE

事件所需資源。

7.3.11 其他表

還剩一些規則不太明顯的表,如下:

FLW_RU_BATCH FLW_RU_BATCH_PART

這兩個是批量遷移流程時使用。

ACT_PROCDEF_INFO

流程定義資訊,對流程的說明。

ACT_CO_CONTENT_ITEM

每項內容在此表中都有個條目。

ACT_EVT_LOG

Flowable 引入了事件日誌機制,預設會在資料庫中建立 ACT_EVT_LOG 表儲存事件日誌,如果不使用事件日誌,則可以刪除這個表。

FLW_CHANNEL_DEFINITION

泳池管道定義表。

好啦,Flowable 中的表結構就和小夥伴們介紹完畢啦~大家可以收藏本文,在需要的時候作為一個參考~