Activiti 7 源碼學習_ZenDei技術網路在線

1. 啟動分析源碼版本是 7.1.0.M6 首先從 ProcessEngineAutoConfiguration 開始 ProcessEngineAutoConfiguration 是activiti-spring-boot-starter 7.1.0.M6自動配置的入口類，在這裡主要看 Spri ...

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

查找棧頂部的元素，如果為空，則新new一個CommandContext，如果不為空，則將獲取到的CommandContext的熟悉reused設為true
將剛纔獲取到的CommandContext壓入棧中
將當前processEngineConfiguration壓入另一個棧中
調用下一個攔截器

也就是說，每個命令在經過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方法