BPMN2 與 Activiti5

什麼是BPMN、Workflow？

BPM（Business Process Management）——“通過建模、自動化、管理和優化流程，打破跨部門跨系統業務過程依賴，提高業務效率和效果”。
Workflow——“全部或者部分由計算機支持或自動處理的業務過程”（工作流管理聯盟WfMC組織對工作流概念的經典定義）

BPM基本內容是管理既定工作的流程，通過服務編排，統一調控各個業務流程，以確保工作在正確的時間被正確的人執行，達到優化整體業務過程的目的。BPM概念的貫徹執行，需要有標準化的流程定義語言來支撐，使用統一的語言遵循一致的標準描述具體業務過程，這些流程定義描述由專有引擎去驅動執行。這個引擎就是工作流引擎，它作爲BPM的核心發動機，爲各個業務流程定義提供解釋、執行和編排，驅動流程“動“起來，讓大家的工作“流”起來，爲BPM的應用提供基本、核心的動力來源。

現實工作中，不可避免的存在跨系統跨業務的情況，而大部分企業在信息化建設過程中是分階段或分部門（子系統）按步實施的，後期實施的基礎可能是前期實施成果的輸出，在耦合業務實施階段，相同的業務過程可能會在不同的實施階段重用，在進行流程梳理過程中，不同的實施階段所使用的流程描述語言或遵循的標準會有所不同（服務廠商不同），有的使用WfMC的XPDL，還有些使用BPML、BPEL、WSCI等，這就造成流程管理、業務集成上存在很大的一致性、侷限性，提高了企業應用集成的成本。

BPMN2.0規範的引入

遵循BPMN2.0新規範的工作流產品能很大程度上解決此類問題。BPMN2.0相對於舊的1.0規範以及XPDL、BPML及BPEL等最大的區別是定義了規範的執行語義和格式，利用標準的圖元去描述真實的業務發生過程，保證相同的流程在不同的流程引擎得到的執行結果一致。BPMN2.0對流程執行語義定義了三類基本要素，它們是日常業務流程的“三板斧”：

Activities（活動）——在工作流中所有具備生命週期狀態的都可以稱之爲“活動”，如原子級的任務（Task）、流向（Sequence Flow），以及子流程（Sub-Process）等
Gateways（網關）——顧名思義，所謂“網關”就是用來決定流程流轉指向的，可能會被用作條件分支或聚合，也可以被用作並行執行或基於事件的排它性條件判斷
Events（事件）——在BPMN2.0執行語義中也是一個非常重要的概念，像啓動、結束、邊界條件以及每個活動的創建、開始、流轉等都是流程事件，利用事件機制，可以通過事件控制器爲系統增加輔助功能，如其它業務系統集成、活動預警等

這三類執行語義的定義涵蓋了業務流程常用的Sequence Flow（流程轉向）、Task（任務）、Sub-Process（子流程）、Parallel Gateway（並行執行網關）、ExclusiveGateway（排它型網關）、InclusiveGateway（包容型網關）等常用圖元，如圖1：

圖1：BPMN2.0三類基本執行語義要素

現實業務所有的業務環節都離不開Activities、Gateways和Events，無論是簡單的條件審批還是複雜的父子流程循環處理，在一個流程定義描述中，所有的業務環節都離不開Task、Sequence Flow、Exclusive Gateway、Inclusive Gateway（如圖1中右側綠色標記所示元素），其中Task是一個極具威力的元素，它能描述業務過程中所有能發生工時的行爲，它包括User Task、Manual Task、Service Task、Script Task等，可以被用來描述人機交互任務、線下操作任務、服務調用、腳本計算任務等常規功能。

User Task:生成人機交互任務，主要被用來描述需要人爲在軟件系統中進行諸如任務明細查閱、填寫審批意見等業務行爲的操作，流程引擎流轉到此類節點時，系統會自動生成被動觸發任務，須人工響應後才能繼續向下流轉。常用於審批任務的定義。

Manual Task:線下人爲操作任務，常用於爲了滿足流程圖對實際業務定義的完整性而進行的與流程驅動無關的線下任務，即此類任務不參與實際工作流流轉。常用於諸如物流系統中的裝貨、運輸等任務的描述。

Service Task:服務任務，通常工作流流轉過程中會涉及到與自身系統服務API調用或與外部服務相互調用的情況，此類任務往往由一個具有特定業務服務功能的Java類承擔，與User Task不同，流程引擎流經此節點會自動調用Java類中定義的方法，方法執行完畢自動向下一流程節點流轉。另外，此類任務還可充當“條件路由”的功能對流程流轉可選分支進行自動判斷。常用於業務邏輯API的調用。

Script Task:腳本任務，在流程流轉期間以“腳本”的聲明或語法參與流程變量的計算，目前支持的腳本類型有三種：juel（即JSP EL）、groovy和javascript。在Activiti5.9中新增了Shell Task，可以處理系統外部定義的Shell腳本文件，也與Script Task有類似的功能。常用於流程變量的處理。

BPMN2.0流程示例

BPMN2.0爲所有業務元素定義了標準的符號，不同的符號代表不同的含義，以OA應用中請假流程爲例，使用標準的BPMN2.0圖元定義示意如圖2：

圖2：BPMN2.0請假流程定義

在上述的流程示意圖中，所涉及到的執行語義圖元主要有表1中的8類：

表1：請假流程所用圖元

除了上述Start Event、User Task、Exclusive Gateway、Parallel Gateway、Service Task、End Event標準的BPMN2.0圖元外，上述流程圖還使用了Lane Set（業務部門、人力資源部、考勤系統），分別表示流程活動所涉及到的部門或角色，Lane的概念和jBPM4中“泳道”的概念一樣，都用來表示同一類相似任務的歸屬者。

應用BPMN2.0標準的一個最顯著的特色是，不同階段的人員，無論是需求分析、概要設計、詳細設計或是具體的業務實現，都可在一個流程圖上開展工作，避免業務理解存在偏差。一個系統的實現，需求分析人員可以利用BPMN2.0標準圖元草繪一下蒐集到的需求；然後可以拿給設計人員，討論出具體的業務需求進行功能設計，由設計人員在草圖的基礎上逐步細化，並得到需求人員的認同；設計人員又將細化後的流程圖交給開發人員，羅列要實現的功能點，指出流程圖上各活動節點所具備的行爲，設計人員與開發人員依據此圖達成共識，進入具體的開發階段；如果後期請假流程發生更改，仍然是在現有流程圖上更改，隨着項目的推進，流程圖也在不斷的演進，但至始至終，項目受衆都使用同一個流程圖交流，保障需求理解的一致性，一定程度上推動了項目的敏捷性。

Activiti5支持最新的BPMN2.0規範

作爲支持最新BPMN2.0規範的開源工作流引擎Activit5，實現了對規範的絕大多數圖元的定義，能夠滿足企業工作流的各種複雜應用。它是一個無侵入的、支持嵌入式和獨立部署的開源工作流引擎，是Tom Bayen離開jBoss加入Alfresco公司後的另立山頭之作，共同開發Activit5的除了Alfresco外還有SpringSource、MuleSoft、Salves、FuseSource、Signavio等公司。從Activiti5.0到當前的5.9（今年3月份發佈），版本更新迭代速度很快，新版本功能穩定，性能良好，爲開源社區提供了商業工作流之外非常具有競爭力的選擇。

與jBPM5的差別

值得一提的是，Activiti5與jBPM5都屬於業界優秀的開源工作流引擎，都支持BPMN2.0最新規範，均基於Apache License，符合J2EE規範，提供工作流建模、執行以及對流程生命週期過程監控。但兩者設計理念和技術組成卻有很大不同，見下表2：

序號	技術組成	Activiti	jBPM
1	數據庫持久層ORM	MyBatis3	Hibernate3
2	持久化標準	無	JPA規範
3	事務管理	MyBatis機制/Spring事務控制	Bitronix，基於JTA事務管理
4	數據庫連接方式	Jdbc/DataSource	Jdbc/DataSource
5	支持數據庫	Oracle、SQL Server、MySQL等多數數據庫	Oracle、SQL Server、MySQL等多數數據庫
6	設計模式	Command模式、觀察者模式等
7	內部服務通訊	Service間通過API調用	基於Apache Mina異步通訊
8	集成接口	SOAP、Mule、RESTful	消息通訊
9	支持的流程格式	BPMN2、xPDL、jPDL等	目前僅只支持BPMN2 xml
10	引擎核心	PVM（流程虛擬機）	Drools
11	技術前身	jBPM3、jBPM4	Drools Flow
12	所屬公司	Alfresco	jBoss.org

表2：Activiti5與jBPM5技術組成

Activiti5使用Spring進行引擎配置以及各個Bean的管理，綜合使用IoC和AOP技術，使用CXF作爲Web Services實現的基礎，使用MyBatis進行底層數據庫ORM的管理，預先提供Bundle化包能較容易的與OSGi進行集成，通過與Mule ESB的集成和對外部服務（Web Service、RESTful等）的接口可以構建全面的SOA應用；jBPM5使用jBoss.org社區的大多數組件，以Drools Flow爲核心組件作爲流程引擎的核心構成，以Hibernate作爲數據持久化ORM實現，採用基於JPA/JTA的可插拔的持久化和事務控制規範，使用Guvnor作爲流程管理倉庫，能夠與Seam、Spring、OSGi等集成。

需要指出的是Activiti5是在jBPM3、jBPM4的基礎上發展而來的，是原jBPM的延續，而jBPM5則與之前的jBPM3、jBPM4沒有太大關聯，且捨棄了備受推崇的PVM（流程虛擬機）思想，轉而選擇jBoss自身產品Drools Flow作爲流程引擎的核心實現，工作流最爲重要的“人機交互”任務（類似於審批活動）則由單獨的一塊“Human Task Service”附加到Drools Flow上實現，任務的查詢、處理等行爲通過Apache Mina異步通信機制完成。

優劣對比：

從技術組成來看，Activiti最大的優勢是採用了PVM（流程虛擬機），支持除了BPMN2.0規範之外的流程格式，與外部服務有良好的集成能力，延續了jBPM3、jBPM4良好的社區支持，服務接口清晰，鏈式API更爲優雅；劣勢是持久化層沒有遵循JPA規範。

jBPM最大的優勢是採用了Apache Mina異步通信技術，採用JPA/JTA持久化方面的標準，以功能齊全的Guvnor作爲流程倉庫，有RedHat(jBoss.org被紅帽收購)的專業化支持；但其劣勢也很明顯，對自身技術依賴過緊且目前僅支持BPMN2。

Activiti5設計模式

命令模式能將命令的發出與執行分開，委派給不同的對象，每一個命令都代表一個指令，其最大的好處是提供了一個公共接口，使得用戶可以用同一種方式調用所有的事務，同時也易於添加新事務以擴展系統。

Activiti5大量採用了命令模式，在流程運行期間，所有的指令執行（比如流程部署、流程流轉、獲取任務等）都使用此模式實現，其中涉及到四個重要的概念：

Command:Activiti5的命令定義接口，僅有一個execute方法，所有運行期要執行的指令都要實現該接口，定義要執行的具體行爲。

CommandContext:命令執行的上下文環境，每個Command的執行都依賴其上下文環境，CommandContext創建了命令執行期間的引擎會話與數據庫會話，每個CommandContext都是一個單獨的ThreadLocal，執行期間不會受其它線程干預，是線程安全的。

CommandExecutor:命令執行器，負責執行所有的運行時Command。引擎中各項指令的執行（即命令的產生者可能來源於多種對象）都託CommandExecutor處理，僅有一個接口方法：execute(Command command)。 ActivityBehavior:活動行爲定義，用於定義BPMN2.0執行語義層的各圖元在流程引擎的行爲，或稱之爲所具備的圖元特徵。與Command的概念類似，僅僅描述“待執行”的指令是什麼，會發生什麼樣的行爲，但真正要執行時則由引擎負責驅動。

人機交互任務是業務流程應用中最常用的業務類型，以BPMN2.0中定義的“Task”這個典型元素說明一下命令模式在Activiti5中的應用：

Activiti5針對BPMN2.0的Task Element定義了Task接口，並依據Semantic.xsd執行語義定義了相關任務元素所具有的行爲特性，此行爲特性通過setActivityBehavior方法進行行爲與元素的綁定，這些Behavior在流程引擎驅動流轉到活動節點時將被觸發，通過execute(ActivityExecution execution)執行ActivityBehavior中指定的操作；

每個活動有若干個Command與之對應，比如ClaimTaskCmd、CompleteTaskCmd、DelegateTaskCmd、SaveTaskCmd、DeleteTaskCmd等，分別表示任務的領取、完成、轉交、保存、刪除等，這些操作指令的執行結果通過命令執行上下文（CommandContext）得到DAO層的TaskManager將任務對象的變更持久化到數據庫中；

引擎不關心要執行什麼，凡是實現了Command接口的類都可以通過CommandExecutor執行，除了引擎提供的這些原生的任務指令外，如果業務系統有額外的特性化操作，也可以自定義一組Command，在Command.execute()中自由調用外部服務、發送手機短信、附加任務屬性、調用DAO操作數據庫等，封裝完畢後交由引擎去執行，即可得到希望的結果。同樣，如果在業務系統中需要自定義BPMN元素或屬性，僅需同步增加ActivityBehavior接口的實現，在解析流程定義文件時將自定義的行爲實現與元素（屬性）幫定，並緩存之，待引擎驅動到達節點時自動執行。在ActivityBehavior. execute()中依然可以調用各種各樣的API已實現特定的業務目的。

此處需要注意的是，Activiti5的CommandContext是包含事務處理的，在每次關閉上下文環境時，會執行事務的提交，但在實際業務系統中，業務事務、引擎事務以及數據庫事務應該是被統一到一個事務中去管理，這就需要將Activiti5的事務與業務系統的事務合併。Activiti5通過Spring注入提供了該方式的可行性，引擎內部的事務控制可以委託給業務層去處理，在初始化引擎配置時，將業務系統中定義的DataSource和TransactionManager傳遞給流程配置的dataSource、transactionManager屬性後，Activiti5內部會使用Spring提供的TransactionAwareDataSourceProxy來封裝傳進來的DataSource，並利用外部的事務管理來接管Activiti5的事務控制，確保了從該DataSource獲取的數據庫連接與 Spring 定義的事務能夠完美地結合，從而實現業務系統與引擎系統事務的集成。

Activiti5對BPMN2.0執行語義的解析

Activiti5通過BpmnParse使用SAX方式進行BPMN2.0 XML流程定義文件的解析，是解析的核心類，從根節點開始解析，依次對DefinitionsAttributes、Imports、ItemDefinitions、Messages、Interfaces、和Errors以及ProcessDefinitions各個元素進行解析（以上均是標準的BPMN2.0元素），最後解析負責流程可視化定義的DiagramInterchangeElements元素。每解析一個元素都會判斷元素類型，如果是“活動“類型（包括Task、Gateway等），則會爲活動設置相應的ActivityBehavior，同時如果流程定義文件中定義了額外屬性，Activiti5會自行利用反射機制注入到ActivityBehavior。

除了Command和ActivityBehavior外，Activiti5還大量引入了監聽機制（攔截器的概念），目前引擎主要包含四類監聽：

BPMN解析監聽——BpmnParseListener，負責對BPMN2.0規範的流程定義文件進行解析控制；
任務監聽——TaskListener，負責對各類任務的狀態以及任務創建、指派責任人、完成任務三類事件進行響應；
執行監聽——ExecutionListener，對執行過程添加輔助管控功能，對引擎中發生的啓動、流轉、結束事件進行響應；
事務監聽——TransactionListener，負責事務控制監聽。

PVM流程虛擬機中包含三類事件：Start、End、Take，分別表示流程的啓動、流轉和結束，流程啓動後，流引擎會從Start事件開始執行，通過Take事件，驅動流程流向下一個環節，該“流向”的動作會被PVM運行時的AtomicOperationTransitionNotifyListenerTake監聽，該監聽會將附加到該流向的所有執行監聽依次執行。任務有也有三類事件可以被監聽：Create、Assignment、Complete，如果希望在任務被創建或指定了相關責任人或任務完成後增加些額外的輔助功能，可以創建TaskListener接口的實現類，並將其定義到執行定義元素中，Activiti5會處理這一切。這些監聽本質上都算是活動的附加代理，在現有操作的基礎上額外增加一個管理控制手段以達到特殊的目的，ActivityBehavior從另一個角度來看也是一種代理，都是由DelegateInvocation負責調用執行，它主要用來提供用戶代碼調用的上下文環境並負責控制實際調用，Activiti5爲其提供了五個實現：ActivityBehaviorInvocation、ExecutionListenerInvocation、ExpressionInvocation、JavaDelegateInvocation、TaskListenerInvocation。

Activiti5提供的Command、ActivityBehavior、Listener等接口爲引擎的功能擴展提供了方便，如果業務系統的功能不能滿足時可以實現這些接口，以無侵入的方式擴展Activiti5，利用這些擴展接口，可以在其執行方法中完成很多業務邏輯，如權限校驗、與業務系統的交互、與外部系統集成調用，甚至替換原有功能偷樑換柱暗度陳倉。

Activiti5 API應用

ProcessEngine是Activiti系統的核心接口，七類基礎服務接口通過ProcessEngine獲取，均採用鏈式API方式，直觀明瞭，易於使用:

RepositoryService：

流程資源服務的接口，主要用於對流程定義的部署、查詢和刪除操。新流程的部署使用createDeployment().addResourceXXX().deploy()方法；已部署流程的查詢使用createDeploymentQuery()附加查詢條件的方式獲取；另外可以使用deleteDeployment和deleteDeploymentCascade方法進行流程的刪除或級聯刪除。

TaskService：

任務服務接口，該接口暴露了管理人機交互任務的操作，如任務領取（claiming）、任務完成（completing）和任務指派（assigning），還包括對任務的創建、查詢、保存、刪除等。

RuntimeService：

運行時服務主要用於啓動或查詢流程實例，以及流程變量、當前激活狀態活動的查詢、流程實例的刪除等。流程在運行過程中所產生的東西都可以使用該接口進行相關處理。

HistoryService：

流程歷史的服務接口。提供對歷史流程實例、歷史任務的查詢和刪除操作，從提供的API來看，歷史流程的查詢其提供了finished和unfinished流程的查詢，即是說，HistoryService提供了對已完成和當前正在執行流程的活動/任務查詢，這一點似乎與runtimeService提供的查詢有些衝突，但其實是有差別的，運行時的信息僅包含任意時刻活動的實際運行狀態信息（是從流程運行執行性能上考慮的），而歷史信息是對已經固化的信息做簡單查詢而優化的，其所持有的對象是不同的。

IdentityService：

用戶、組管理服務接口，用於管理Group、User的增刪改查，並維護Membership，涉及到的API有newUser、newGroup、saveUser、saveGroup、createMembership以及相關的deleteXXX方法。

FormService：

表單服務用於訪問表單數據以及在啓動新的流程實例時或完成任務時所需的渲染後的表單，提供UI界面輔助用戶填寫相關值以保存至流程變量。該服務在實際業務應用中並不常用，屬於引擎的非核心服務。

ManagementService：

提供流程管理和控制操作的接口服務，和業務流程的運行沒有關聯關係，比如查詢數據庫本身的內容、Activiti的版本及序列生成ID規則等，屬於引擎的非核心服務。

Activiti5工作流引擎應用需要首先掌握的是配置及API基礎應用，下面以上述BPMN2.0請假流程爲例，簡述Activiti5在具體系統中的應用。

Step1：繪製請假流程圖

請假流程圖使用標準的BPMN2.0圖元進行流程定義，可以使用任何XML編制工具編寫（導入XSD可以爲編寫過程提供代碼提示），建議使用Joinwork Process Studio進行可視化編制，如圖3:

圖3：Step2配置Activiti5環境

流程引擎環境主要涉及到三個方面：數據源、事務管理以及流程引擎配置實例。通常流程引擎僅是業務系統的一個核心模塊，其數據源和事務都要委託給業務平臺，在流程引擎配置定義中，可以通過ref將業務系統的dataSource和transactionManager注入給Activiti5的引擎配置：

<beanid="processEngineConfiguration"class="org.activiti.spring.SpringProcessEngineConfiguration">
<propertyname="dataSource"ref="dataSource" />
<propertyname="transactionManager" ref="transactionManager"/>
<propertyname="databaseSchemaUpdate"value="true"/>
<propertyname="jobExecutorActivate"value="false"/>
</bean>

如果是在OSGi環境中應用Activiti5，還需要將業務環境中註冊的dataSource和transactionManager作爲OSGi Service引入到當前Bundle，然後再進行processEngineConfiguration的配置：

<osgi:referenceid="dataSource"interface="javax.sql.DataSource"/>
<osgi:referenceid="transactionManager"interface="org.springframework.transaction.PlatformTransactionManager"/>

Step3：部署請假流程定義文件到Activiti5環境

利用流程引擎提供的RepositoryService接口實現流程的部署：

//通過ProcessEngine獲取repositoryService
RepositoryServicerepositoryService = processEngine.getRepositoryService();
//使用repositoryService進行新流程部署
repositoryService.createDeployment()
.addClasspathResource("請假申請-條件分支與合併流程.bpmn20.xml")
.deploy();

Step4：創建請假單頁面輸入請假天數及原由，啓動流程

編寫html表單輸入界面，然後使用Ajax提交請求，由Servlet根據請求參數創建新流程實例，啓動流程後界面如圖4：

圖4：流程啓動後的界面

輸入請假天數及原因，如果天數大於等於3天，則走“部門經理審批路由“分支，利用jQuery綁定”提交“按鈕的操作：

$('#startProcess').click(function(){
            varurl = '/com.ygsoft.process.demo/ProcessEngineServlet?operate=start&'+$('#inputform').serialize();            
            //以UTF8方式提交：
            $.ajax({
                url:url,
                type:"POST",
                dataType:"json",
                contentType:"application/x-www-form-urlencoded;charset=utf-8",//此參數避免中文亂碼
                success:function(data){
                    if(data.success){
                        alert('您的單據已提交，流程ID：'+data.id);
                        $('#inputform').hide();
                        $('#viewTodo').show(2000);
                    }else{
                        alert('您的單據未提交成功');
                    }                   
                }
            });
        })

Backend端利用RuntimeService接口創建新的流程實例：

// 通過ProcessEngine獲取runtimeService
RuntimeServiceruntimeService = processEngine.getRuntimeService();
// 使從Request中獲取請求參數，用於構造流程啓動參數
Map<String, Object>params = newHashMap<String, Object>();
String processKey = request.getParameter("processKey");     
int day = Integer.parseInt(request.getParameter("day"));
String reason = request.getParameter("reason");
params.put("day", day);
params.put("user", user);
params.put("reason", reason);   
// 使用runtimeService啓動流程實例（將參數做爲流程變量處理）
ProcessInstanceprocessInstance = runtimeService.startProcessInstanceByKey(processKey,params) ;

Step5：獲取審批人待辦任務

利用TaskService接口可是實現指配給自己的以及候選任務：
// 通過ProcessEngine獲取taskService
TaskServicetaskService = processEngine.getTaskService();
// 使用taskService根據用戶ID獲取候選任務
List<Task> tasks = taskService.createTaskQuery()
.taskAssignee(user)
.orderByTaskCreateTime()
.desc()
.list();

將查詢到的List通過Gson轉換成json數組傳遞到前端，由jQuery解析並顯示到界面。

還有一種情況是查詢分配給某個組或某個人的候選任務：

List<Task> tasks = taskService.createTaskQuery()
.processInstanceId(processInstance.getId())
.taskCandidateGroup("xxxGrp")
.list();
// 或
List<Task> tasks = taskService.createTaskQuery()
.processInstanceId(processInstance.getId())
.taskCandidateUser("xxxUser")
.list();

Step6：審批人查看任務明細

任務明細除了包含Task本身的信息（如任務名稱、描述以及流程變量等）外，還要動態顯示當前激活任務的可視化流程圖。

Task信息可以從List中獲取，可視化流程圖可以利用以下方式輸出至前端：

// 根據當前Task獲取流程定義對象 ProcessDefinitionEntityprocessDefinition = (ProcessDefinitionEntity) ((RepositoryServiceImpl) repositoryService) .getDeployedProcessDefinition(task.getProcessDefinitionId()); // 利用ProcessDiagramGenerator生成當前激活任務的圖片流 InputStreamdefinitionImageStream = ProcessDiagramGenerator.generateDiagram(processDefinition, "png", runtimeService.getActiveActivityIds(task.getProcessInstanceId())); // 將圖片流生成byte[]數組 byte[] diagramBytes = IoUtil.readInputStream(definitionImageStream,null); response.setContentType("image/png");// 設置瀏覽器響應的ContentType ServletOutputStream out = response.getOutputStream(); out.write(diagramBytes);// 輸出至前端 out.close();

Step7：完成審批任務

審批人在查看請假申請單後，填寫審批意見後以Ajax方式提交“完成任務“請求；Servlet利用TaskService進行任務的提交：

//先完成當前任務： 
Map<String, Object>params = taskService.getVariables(taskId); 
String reviewMessage = request.getParameter(“msg”); 
String choice = request.getParameter(“choice”); 
params.put(“msg”, choice+“-”+user+“-”+reviewMessage); taskService.complete(taskId, params);

待第一個的審批工作完成後，流程引擎會產生Task事件，經由並行網關處理後，系統將生成“人力專員確認“的UserTask任務和”自動備案“的ServiceTask任務，其中ServiceTask任務將由系統自動執行，”人力專員確認“任務依然通過Step5、6、7完成，待這兩個任務都完成後，兩條路由分支由”合併“路由流轉到”結束“節點，至此，流程結束。

通過以上API的應用分析，Activiti5 API構成清晰，針對性更強，不同的功能由相應的服務接口完成，訪問接口更友好。

總結

BPMN2.0是一個工作流業界標準，規範了大型廠商和開源工作流產品的實現，Activiti5實現了該標準的大部分圖元定義和執行語義解釋，功能強大，Activiti5可以與IBM、Oracle等大型商用工作流產品流程引擎節點的核心功能媲美，並且爲了簡化應用、擴充原有功能，Activiti5又自定義了6個擴展元素和15個擴展屬性，這些元素和屬性能夠與BPMN規範相互組合可以實現更多、更實用的業務功能。

筆者通過技術組成、對BPMN規範的覆蓋率、API應用友好性、社區支持度、第三方組件依賴程度以及可擴展性六個方面進行分析和比對，Activiti5的綜合實力較強。對於如何選型符合BPMN標準的工作流產品，這是一個仁者見仁智者見智的問題，一方面依賴於各個公司對工作流技術方面的歷史積累，另一方面也要針對具體項目具體情況區別對待。但如果對於一個全新的項目或對jBPM3、4設計理念認同的公司，不妨考慮Activiti5。

BPMN2 與 Activiti5

什麼是BPMN、Workflow？

BPMN2.0規範的引入

BPMN2.0流程示例

Activiti5支持最新的BPMN2.0規範

與jBPM5的差別

Activiti5設計模式

Activiti5對BPMN2.0執行語義的解析

Activiti5 API應用

總結

連接池技術BoneCP

做一個道德完善的人

java測試URL是否連通的方法

單例模式實現延遲加載在多線程下的思考(雙檢鎖和內部類)

BPMN2 與 Activiti5

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結