2019獨角獸企業重金招聘Python工程師標準>>>

##Query API簡介 Activiti的查詢API:
1）標準查詢 ：在以Java物件的方式通過建立一個指定型別的Query物件(實現Query介面)後用鏈式程式設計的方式設定查詢引數。弊端：不能支援複雜的查詢，比如多張表聯合查詢或者使用OR關係查詢；
2）Native查詢 ：允許採用標準SQL的方式查詢流程物件，不過Native查詢僅支援部分流程物件(查詢結果只能返回引擎的固定幾個物件，返回結果不能自定義)，並且查詢物件需要實現NativeQuery介面。sql(String sql)可以接受一個標準的SQL語句。其中表名可以通過ManagementService#getTaskName()

##管理員特性 流程狀態
假設這樣一個場景：一個正在執行的流程例項由於某些原因要暫停，從技術上來說就是"掛起"，當條件滿足之後再恢復狀態繼續執行該流程例項。

在Activiti中，這一過程有2個對應的操作：掛起(suspend)、啟用(active)。除了控制流程例項外還可以控制流程定義(ProcessDefinition)的狀態，並且可以選擇是否啟用與流程定義相關的流程例項，以及定是啟用或掛起。

流程定義許可權控制
從Activiti5.10版本開始引擎把使用者任務的候選配置移植到流程級別上，從而可以根據登入系統的使用者所擁有的角色決定是否有權查詢、啟動流程。

讀取引擎屬性
引擎提供了一個便捷的介面可以快速獲取引擎配置資訊：managementService.getProperties();

讀取引擎屬性
引擎提供了查詢引擎資料庫的介面，使用者獲取與引擎資料庫表的結構、記錄。此功能封裝在ManagementService介面中。TableMetaData,TablePage...

##統一身份管理
在一個完整的系統中，身份模組式必不可少的，用於管理系統的使用者、組織、角色或崗位。大多數系統都會有組織的管理，而在Activiti中並沒有組織的概念，也沒有角色的管理，取而代之的是組。

###引擎身份介面方式
####1. 通過引擎介面同步資料 通過引擎介面同步資料是一種“非侵入式”的同步方法，做法類似於引擎中的監聽，當現有身份模組的使用者資料變更時呼叫Activiti引擎的IdentityService介面的對應方法同步操作。當然在同步資料時要做好資料的校驗工作，例如在新增、修改使用者和組時要先檢查物件是否存在防止引擎介面丟擲異常。

這種同步身份資料方式的特點在於“不破壞”引擎表結構、面向介面程式設計。如果根據使用者ID查詢相關的候選任務，那麼SQL的過濾條件：在ACT_RU_IDENTITYLINK表中型別類candidate且USER_ID_欄位等於當前使用者ID，或任務有候選組且當前人與候選組有關聯關係(在ACT_ID_MEMBERSHIP表中維護)。

當我們操作業務系統的使用者、角色以及兩者關係時把這些更改都同步到引擎的表中，所以引擎內部的SQL關聯查詢可以正常工作。之所以在這裡強呼叫戶與組的關係是因為下面介紹的第2種方式就不能使用與ACT_ID_MEMBERSHIP表關聯查詢了，因為下面的方式會禁用引擎的身份模組表。

####2. 自定義Session工廠
Activiti的每一張表都有一個對應的實體管理器，在引擎初始化時會初始化所有表的實體管理類(提供CRUD等功能)，每一個實體類都有一個對應的實體管理類(XxxEntityManager)及 實體管理工廠類(XxxEntityManagerFactory)。實體管理工廠類實現SessionFactory介面。 (是個坑，可能自己沒有理解透，TaskService底層也有用到identity相關的表做關聯，單單隻改IdentityService用到的實體類管理工具不夠。後來就直接繼承ProcessEngineConfiguration相關實現類重寫getMyBatisXmlConfigurationSteam方法修改mybatis配置檔案裡的identity相關的mapping檔案)

####3. 用檢視代替物理表
在引擎中，和身份相關的表如下：
ACT_ID_USER: 使用者表；
ACT_ID_INFO：使用者資訊表；
ACT_ID_GROUP：組，也可以理解為角色；
ACT_ID_MEMBERSHIP：使用者與組的關係，這也是查詢任務候選人需要關聯的表。

相比前2種方式，使用檢視代理物理表顯得“輕量”一些，把引擎的物理表刪除，取而代之是與物理表同名的檢視，只要保證檢視的結構與原來物理表的表結構及欄位型別一致即可。

採用這種方式需要在配置引擎的時候把屬性dbIdentityUsed設定為false，即禁用身份模組的功能，實際上是在初始化引擎時不再檢查ACT_ID_*表是否存在。

##REST服務 釋出REST API
整合REST API
整合流程圖跟蹤元件Diagram Viewer
基於REST服務搭建流程中心：基礎架構，表單模型選型，統一的元件，事務管理
整合流程設計器Activiti Moderler

##入侵Activiti ###解析BPMN檔案 部署流程：

1. 引擎會解析XML格式的流程檔案提取流程定義(ProcessDefinition)物件，部署動作由BpmnDeployer類負責，下圖展示該類依賴的各種解析器、處理器的結構圖：
2. 把BpmnDeployer處理得到的流程物件，儲存到引擎資料庫並快取；
   3）同時也會儲存相關的資原始檔到資料庫。
   

###命令與攔截器
外觀模式(Facade)、命令模式(Command)、攔截器模式(Interceptor)是常見的設計模式，也是Activiti整體架構採用的三種主要設計模式，所有的API均以這三種模式為基礎實現。

“面向介面程式設計”是Activiti API設計的一大設計思想，對外公開的所有API均用抽象定義的方式，提供了7大模組的XxxService介面，這也是採用了外觀模式的表現；引擎的內部實現不對外公開，開發人員只要呼叫暴露的API程式設計介面實現相應的功能。基於抽象的介面還可以覆蓋引擎內部的實現，使用自定義的實現類替換(在引擎配置物件中可以配置)。

在Activiti中所有操作均對應一個命令介面(Command)實現類，這樣不同的功能分散到N個命令中，易於維護與擴充套件；當呼叫引擎XxxService介面時實際上是呼叫不同的Commande，但介面並不是直接呼叫命令，而是把命令交給CommandExecutor統一執行，因為通過它可以在命令執行中執行若干攔截器(類似JAVAEE中的Filter鏈)。

Activit中的攔截器可以為所有的Command命令準備好命令上下文(CommandContext)物件，以便在Command實現類中獲取到引擎配置物件(獲取引起配置屬性)、會話物件(Session)，以及其他擴充套件屬性等；還可以為Command提供食物管理器、樂觀鎖自動重試等功能。

###流程虛擬機器PVM
PVM(Process Virtual Machine)流程虛擬機器，是Activiti整個流程驅動(流程推進)機制的核心規範。

Activiti原始碼分析

轉載於:https://my.oschina.net/braveCS/blog/706682