Activiti 7 原始碼學習

1.  啟動分析

原始碼版本是 7.1.0.M6

首先從 ProcessEngineAutoConfiguration 開始

ProcessEngineAutoConfiguration 是activiti-spring-boot-starter 7.1.0.M6自動配置的入口類，在這里主要看 SpringProcessEngineConfiguration

主要是配置了自動部署

最最最重要的是 buildProcessEngine() 方法，將來根據配置構建 ProcessEngine 的時候它就派上用場了

ProcessEngine processEngine = ProcessEngineConfiguration.createProcessEngineConfigurationFromResourceDefault().buildProcessEngine();

下面重點看一下如何構建 ProcessEngine

在父類（ProcessEngineConfigurationImpl）的 buildProcessEngine() 里呼叫了一個非常重要的方法 init()

可以看到在init()方法里初始化了很多組件，接下來挑幾個來重點看一下

initAgendaFactory()

initCommandContextFactory()

new了一個CommandContextFactory，重要的是CommandContextFactory中持有當前processEngineConfiguration的參考

initCommandExecutors()

初始化攔截器interceptor要重點說下，這里構造了一個攔截器鏈，而且攔截器鏈的最后是CommandInvoker，并且將第一個攔截器放到CommandExecutor里面，姑且先記下，后面有用到

initServices()

initBehaviorFactory()

在初始化各個組件以后，new了一個ProcessEngineImpl，并將當前的配置 ProcessEngineConfigurationImpl 賦值給它

因此，這個代表流程引擎的ProcessEngine就變成了一個基礎的入口類，它提供了對作業流操作的所有服務的訪問，

2.  CommandContextInterceptor

在默認的攔截器中有一個 CommandContextInterceptor 特別重要

在其execute()方法中設定背景關系CommandContext

1. 查找堆疊頂部的元素，如果為空，則新new一個CommandContext，如果不為空，則將獲取到的CommandContext的熟悉reused設為true
2. 將剛才獲取到的CommandContext壓入堆疊中
3. 將當前processEngineConfiguration壓入另一個堆疊中
4. 呼叫下一個攔截器

也就是說，每個命令在經過CommandContextInterceptor后都有了自己的背景關系

那么，CommandContext中到底有什么呢？繼續看

CommandContext中有命令（Command）,還有agenda（ActivitiEngineAgenda）

3.  Command

Activiti這里采用命令模式，將操作以及與之相關的資訊都封裝成命令，

下面以完成任務為例來看一下命令是如何被完成的

前面初始化services的時候說過了，會將創建好的CommandExecutor設定到各個Service中，因此TaskService中commandExecutor的出現就不足為奇了

可以看到，完成任務的時候，直接new了一個CompleteTaskCmd，然后交由commandExecutor去執行

CompleteTaskCmd主要有兩個屬性：任務ID 和 流程變數

既然命令交給了CommandExecutor執行，那么接下來看下它是如何執行的，

在前面 initCommandExecutor() 的時候我們指定，它其實是 CommandExecutorImpl，并且我們還知道它持有默認的命令配置，以及攔截器鏈中的第一個攔截器

從代碼中可以看到 CommandExecutorImpl#execute() 直接從攔截器鏈中的第一個攔截器開始往后依次呼叫，可以預見到，它肯定會經過CommandContextInterceptor，于是在當前請求執行緒的區域變數中就會有一個堆疊（Stack），在堆疊的頂部放了一個CommandContext，在這個CommandContext中有待執行的Command，有processEngineConfiguration，還有agenda，

它這個CommandContext被設計成是每個執行緒私有的，就是每個執行緒都有自己的一個CommandContext

在執行緒區域變數中存放這堆疊，堆疊里面放著物件

攔截器鏈的最后一個攔截器是 CommandInvoker

4.  CommandInvoker

重頭戲來了，接下來 CommandInvoker 的每個方法都要仔細看了

可以看到，真正去執行命令是在CommandInvoker中觸發的

5.  Agenda

agenda （譯：議程，待議事項，議事日程）的意思是“議程”，“會議議程”，“待議事項”

可以把 agenda 想象成是一個會議，首先每個命令請求都有一個 CommandContext，CommandContext里面有Agenda

這樣的話，CommandContext 相當于會議室，Agenda 相當于這次會議的議程，就是這次會議要商議的事項有哪些，每個 Operation 相當于一個待議事項，在會議進行期間會不斷產生很多新的事項，然后一個一個事項的過，直到所有的事項都處理完了，

也可以把 agenda 想象成執行緒池，不斷有新的任務被丟進執行緒池，作業執行緒就不斷從作業佇列中取任務執行

還是 “會議室 --> 會議 --> 議程 --> 事項 --> 處理事項”更加形象生動

每個命令請求就相當于發起一次會議，會議的目的是處理這次的命令請求，為了開會討論解決問題，需要有個會議室，然后發起會議，會議上有很多要解決的問題，一個一個解決問題，直到所有問題都被解決，會議結束

每個待議事項都是一個 Runnable 型別的物件，注意別搞混了，Runnable 本身不是執行緒，我個人猜測，之所以設計成Runnable型別的主要是為了方便異步處理，我們可以配置Activiti的活動是同步還是異步執行，而直接呼叫Runnable的run()方法就是同步執行，把它放到執行緒池就是異步執行，業務處理的邏輯都在run()方法里，完全不用關心是同步還是異步執行，這種設計太絕了，妙啊，，，（PS：純屬個人猜測，沒有求證過，O(∩_∩)O哈哈~）

命令執行的結果放到會議室（CommandContext）

活動結束后，會呼叫planContinueProcessOperation()，流程繼續執行，進入下一個活動節點

6.  CompleteTaskCmd

回到最初的完成任務命令，我們指定任務執行呼叫的Runnable的run()方法，run()方法里面是呼叫命令的execute方法

所以，接下來看完成任務這個命令具體做了什么

7.  ActivityBehavior

要理解 Behavior 必須要和流程圖聯系起來，流程圖上的一些元素比如 網關、用戶任務、子流程、事件等等都有對應的行為，每種行為的處理方式都不同

ActivityBehavior 的實作類比較多，層級也比較深，不一一列舉，以其中一個為例看看就行了

繼續回到完成任務，剛才看到往agenda中放了一個 TriggerExecutionOperation，該操作觸發等待狀態并繼續該流程，并離開該活動，

8.  回顧

Command：命令

ActivitiEngineAgendaFactory：用于創建ActivitiEngineAgenda

ActivitiEngineAgenda：議程，待議事項，用于回圈執行Operation

AbstractOperation：事項/操作，它實作了Runnable介面

CommandContextFactory：用于創建CommandContext

CommandContext：每個命令執行執行緒都有自己的CommandContext，其內部有對Command和Agenda的參考

CommandExecutor：執行Command，從攔截器鏈的第一個攔截器開始執行

CommandInvoker：攔截器鏈上的最后一個攔截器，負責將命令封裝成Operation，在Agenda中執行Operation的時候就會呼叫具體命令的execute方法

ActivityBehavior：代表活動的行為，這是真正底層的驅動流程流轉的核心

標籤：其他

上一篇：Python：如何只用十幾行代碼寫一個程式？

下一篇：Django ORM 事務和查詢優化