BPMN2基礎(chǔ)學(xué)習(xí)資料

1、“通過(guò)建模、自動(dòng)化、管理和BPM (Business Process Management) 優(yōu)化流程，打破跨部門(mén)跨系統(tǒng)業(yè)務(wù)過(guò)程依賴(lài)，提高業(yè)務(wù)效率和效果”。Workflow “全部或者部分由計(jì)算機(jī)支持或自動(dòng)處理的業(yè)務(wù)過(guò)程”（工作流管 理聯(lián)盟WfMC組織對(duì)工作流概念的經(jīng)典定義）BPM基本內(nèi)容是管理既定工作的流程，通過(guò)服務(wù)編排，統(tǒng)一調(diào)控各個(gè)業(yè)務(wù)流 程，以確保工作在正確的時(shí)間被正確的人執(zhí)行，達(dá)到優(yōu)化整體業(yè)務(wù)過(guò)程的目的。 BPM概念的貫徹執(zhí)行，需要有標(biāo)準(zhǔn)化的流程定義語(yǔ)言來(lái)支撐，使用統(tǒng)一的語(yǔ)言 遵循一致的標(biāo)準(zhǔn)描述具體業(yè)務(wù)過(guò)程，這些流程定義描述由專(zhuān)有引擎去驅(qū)動(dòng)執(zhí)行。 這個(gè)引擎就 是工作流引擎，它作為BPM

2、的核心發(fā)動(dòng)機(jī)，為各個(gè)業(yè)務(wù)流程定義提 供解釋、執(zhí)行和編排，驅(qū)動(dòng)流程“動(dòng)“起來(lái)，讓大家的工作“流”起來(lái)，為BPM 的應(yīng)用提供基本、核心的動(dòng)力來(lái)源?，F(xiàn)實(shí)工作中，不可避免的存在跨系統(tǒng)跨業(yè)務(wù)的情況，而大部分企業(yè)在信息化 建設(shè)過(guò)程中是分階段或分部門(mén)（子系統(tǒng)）按步實(shí)施的，后期實(shí)施的基礎(chǔ)可能是前 期實(shí)施成 果的輸出，在耦合業(yè)務(wù)實(shí)施階段，相同的業(yè)務(wù)過(guò)程可能會(huì)在不同的實(shí) 施階段重用，在進(jìn)行流程梳理過(guò)程中，不同的實(shí)施階段所使用的流程描述語(yǔ)言或 遵循的標(biāo)準(zhǔn)會(huì)有 所不同（服務(wù)廠商不同），有的使用WfMC的XPDL，還有些使 用BPML、BPEL、WSCI等，這就造成流程管理、業(yè)務(wù)集成上存在很大的一致性、 局限 性，提高

3、了企業(yè)應(yīng)用集成的成本。BPMN2.0規(guī)范的引入。遵循BPMN2.0新規(guī)范的工作流產(chǎn)品能很大程度上解決此類(lèi)問(wèn)題。BPMN2.0相 對(duì)于舊的1.0規(guī)范以及XPDL、BPML及BPEL等最大的區(qū)別是定 義了規(guī)范的執(zhí)行 語(yǔ)義和格式，利用標(biāo)準(zhǔn)的圖元去描述真實(shí)的業(yè)務(wù)發(fā)生過(guò)程，保證相同的流程在不 同的流程引擎得到的執(zhí)行結(jié)果一致。BPMN2.0對(duì)流程執(zhí)行語(yǔ)義 定義了三類(lèi)基本 要素，它們是日常業(yè)務(wù)流程的“三板斧”：Activities （活動(dòng)）一一在工作流 中所有具備生命周期狀態(tài)的都可以稱(chēng)之為“活動(dòng)”，如原子級(jí)的任務(wù)（Task）、 流向（Sequence Flow），以及子流程（Sub-Process）等Gat

4、eways （網(wǎng)關(guān)）一一顧名思義，所謂“網(wǎng)關(guān)”就是用來(lái)決定流程流轉(zhuǎn)指向 的，可能會(huì)被用作條件分支或聚合，也可以被用作并行執(zhí)行或基于事件的排它性 條件判斷Events （事件）一一在BPMN2.0執(zhí)行語(yǔ)義中也是一個(gè)非常重要的概念，像啟動(dòng)、結(jié)束、邊界條件以及每個(gè)活動(dòng)的創(chuàng)建、開(kāi)始、流轉(zhuǎn)等都是流程事件，利用事 件機(jī)制，可以通過(guò)事件控制器為系統(tǒng)增加輔助功能，如其它業(yè)務(wù)系統(tǒng)集成、活動(dòng) 預(yù)警等。這三類(lèi)執(zhí)行語(yǔ)義的定義涵蓋了業(yè)務(wù)流程常用的Sequence Flow （流程 轉(zhuǎn)向）、Task （任務(wù)）、Sub-Process （子流程）、Parallel Gateway （并行執(zhí) 行網(wǎng)關(guān)）、ExclusiveGa

5、teway （排它型網(wǎng)關(guān)）、InclusiveGateway （包容型網(wǎng)關(guān)） 等常用圖元，如圖圖1： BPMN2.0三類(lèi)基本執(zhí)行語(yǔ)義要素現(xiàn)實(shí)業(yè)務(wù)所有的業(yè)務(wù)環(huán)節(jié)都離不開(kāi)Activities、Gateways和Events，無(wú)論 是簡(jiǎn)單的條件審批還是復(fù)雜的父子流程循環(huán)處理，在一個(gè)流程定 義描述中，所 有的業(yè)務(wù)環(huán)節(jié)都離不開(kāi) Task、Sequence Flow、Exclusive Gateway、 Inclusive Gateway （如圖1中右側(cè)綠色標(biāo)記所示元素），其中Task是一個(gè)極 具威力的元素，它能描述業(yè)務(wù)過(guò)程中所有能發(fā)生工時(shí)的行為，它包括 User Task、Manual Task、Ser

6、vice Task、Script Task 等，可以被用來(lái)描 述人機(jī)交互任務(wù)、線(xiàn)下操作任務(wù)、服務(wù)調(diào)用、腳本計(jì)算任務(wù)等常規(guī)功能。User Task :生成人機(jī)交互任務(wù)，主要被用來(lái)描述需要人為在軟件系統(tǒng)中進(jìn) 行諸如任務(wù)明細(xì)查閱、填寫(xiě)審批意見(jiàn)等業(yè)務(wù)行為的操作，流程引擎流轉(zhuǎn)到此類(lèi)節(jié) 點(diǎn)時(shí)，系統(tǒng)會(huì)自動(dòng)生成被動(dòng)觸發(fā)任務(wù)，須人工響應(yīng)后才能繼續(xù)向下流轉(zhuǎn)。常用于 審批任務(wù)的定義。Manual Task :線(xiàn)下人為操作任務(wù)，常用于為了滿(mǎn)足流程圖對(duì)實(shí)際業(yè)務(wù)定義 的完整性而進(jìn)行的與流程驅(qū)動(dòng)無(wú)關(guān)的線(xiàn)下任務(wù)，即此類(lèi)任務(wù)不參與實(shí)際工作流流 轉(zhuǎn)。常用于諸如物流系統(tǒng)中的裝貨、運(yùn)輸?shù)热蝿?wù)的描述。Service Task:服務(wù)任務(wù)

7、，通常工作流流轉(zhuǎn)過(guò)程中會(huì)涉及到與自身系統(tǒng)服務(wù) API調(diào)用或與外部服務(wù)相互調(diào)用的情況，此類(lèi)任務(wù)往往由一個(gè)具有特定業(yè)務(wù)服務(wù) 功能的Java類(lèi)承擔(dān)，與User Task不同，流程引擎流經(jīng)此節(jié)點(diǎn)會(huì)自動(dòng)調(diào)用Java 類(lèi)中定義的方法，方法執(zhí)行完畢自動(dòng)向下一流程節(jié)點(diǎn)流轉(zhuǎn)。另外，此類(lèi)任務(wù)還可 充當(dāng)“條件路由”的功能對(duì) 流程流轉(zhuǎn)可選分支進(jìn)行自動(dòng)判斷。常用于業(yè)務(wù)邏輯 API的調(diào)用。Script Task:腳本任務(wù)，在流程流轉(zhuǎn)期間以“腳本”的聲明或語(yǔ)法參與流 程變量的計(jì)算，目前支持的腳本類(lèi)型有三種：juel（即JSP EL）、groovy和 javascript。在Activiti5.9中新增了 Shell Tas

8、k，可以處理系統(tǒng)外部定義的 Shell腳本文件，也與Script Task有類(lèi)似的功能。常用于流程變量的處理。Activiti5支持最新的BPMN2.0規(guī)范作為支持最新BPMN2.0規(guī)范的開(kāi)源工作流引擎Activit5,實(shí)現(xiàn)了對(duì)規(guī)范的絕 大多數(shù)圖元的定義，能夠滿(mǎn)足企業(yè)工作流的各種復(fù)雜應(yīng)用。它是一個(gè)無(wú)侵 入的、 支持嵌入式和獨(dú)立部署的開(kāi)源工作流引擎，是 Tom Bayen離開(kāi)jBoss加入 Alfresco公司后的另立山頭之作，共同開(kāi)發(fā)Activit5的除了 Alfresco外還有 SpringSource、 MuleSoft、Salves、FuseSource、Signavio 等公司。從 A

9、ctiviti5.0到當(dāng)前的5.9 （今年3月份發(fā)布），版本更新 迭代速度很快，新 版本功能穩(wěn)定，性能良好，為開(kāi)源社區(qū)提供了商業(yè)工作流之外非常具有競(jìng)爭(zhēng)力的 選擇。 Activiti5與jBPM5技術(shù)組成Activiti5使用Spring進(jìn)行引擎配置以及各個(gè)Bean的管理，綜合使用IoC 和AOP技術(shù)，使用CXF作為Web Services實(shí)現(xiàn)的基礎(chǔ)，使用MyBatis進(jìn)行底層 數(shù)據(jù)庫(kù)ORM的管理，預(yù)先提供Bundle化包能較容易的與OSGi進(jìn)行集成，通過(guò)與 Mule ESB的集成和對(duì)外部服務(wù)（Web Service、RESTful等）的接口可以構(gòu)建 全面的SOA應(yīng)用；jBPM5使用jBoss.

10、org社區(qū)的大多數(shù)組件，以Drools Flow 為核心組件作為流程引擎的核心構(gòu)成，以Hibernate作為數(shù)據(jù)持久化ORM實(shí)現(xiàn)，采用基于JPA/JTA的可插拔的持久化和事務(wù)控制規(guī)范，使 用Guvnor作為流程 管理倉(cāng)庫(kù)，能夠與Seam、Spring、OSGi等集成。需要指出的是Activiti5是在jBPM3、jBPM4的基礎(chǔ)上發(fā)展而來(lái)的，是原jBPM 的延續(xù)，而jBPM5則與之前的jBPM3、jBPM4沒(méi)有 太大關(guān)聯(lián)，且舍棄了備受推 崇的PVM （流程虛擬機(jī)）思想，轉(zhuǎn)而選擇jBoss自身產(chǎn)品Drools Flow作為流 程引擎的核心實(shí)現(xiàn)，工作流最為重要的“人機(jī)交互”任務(wù)（類(lèi)似于審批活動(dòng)）則

11、 由單獨(dú)的一塊“Human Task Service”附加到Drools Flow上實(shí)現(xiàn)，任務(wù)的 查詢(xún)、處理等行為通過(guò)Apache Mina異步通信機(jī)制完成。優(yōu)劣對(duì)比：從技術(shù)組成來(lái)看，Activiti最大的優(yōu)勢(shì)是采用了 PVM （流程虛擬機(jī)），支持 除了 BPMN2.0規(guī)范之外的流程格式，與外部服務(wù)有良好的集成能力，延續(xù)了 jBPM3、jBPM4良好的社區(qū)支持，服務(wù)接口清晰，鏈?zhǔn)紸PI更為優(yōu)雅；劣勢(shì)是持 久化層沒(méi)有遵循JPA規(guī)范。jBPM最大的優(yōu)勢(shì)是采用了 Apache Mina異步通信技術(shù)，采用JPA/JTA持久 化方面的標(biāo)準(zhǔn)，以功能齊全的Guvnor作為流程倉(cāng)庫(kù)，有RedHat（jBoss

12、.org被紅 帽收購(gòu)）的專(zhuān)業(yè)化支持；但其劣勢(shì)也很明顯，對(duì)自身技術(shù)依賴(lài)過(guò)緊且目前僅支持 BPMN2。 Activiti5 設(shè)計(jì)模式命令模式能將命令的發(fā)出與執(zhí)行分開(kāi)，委派給不同的對(duì)象，每一個(gè)命令都代 表一個(gè)指令，其最大的好處是提供了一個(gè)公共接口，使得用戶(hù)可以用同一種方式 調(diào)用所有的事務(wù)，同時(shí)也易于添加新事務(wù)以擴(kuò)展系統(tǒng)。Activiti5大量采用了命令模式，在流程運(yùn)行期間，所有的指令執(zhí)行（比如 流程部署、流程流轉(zhuǎn)、獲取任務(wù)等）都使用此模式實(shí)現(xiàn)，其中涉及到四個(gè)重要 的概念：Command:Activiti5的命令定義接口，僅有一個(gè)execute方法，所有運(yùn)行期 要執(zhí)行的指令都要實(shí)現(xiàn)該接口，定義要執(zhí)行的

13、具體行為。CommandContext:命令執(zhí)行的上下文環(huán)境，每個(gè)Command的執(zhí)行都依賴(lài)其上 下文環(huán)境，CommandContext創(chuàng)建了命令執(zhí)行期間的 引擎會(huì)話(huà)與數(shù)據(jù)庫(kù)會(huì)話(huà)， 每個(gè)CommandContext都是一個(gè)單獨(dú)的ThreadLocal，執(zhí)行期間不會(huì)受其它線(xiàn)程 干預(yù)，是線(xiàn)程安全的。CommandExecutor:命令執(zhí)行器，負(fù)責(zé)執(zhí)行所有的運(yùn)行時(shí)Command。引擎中各 項(xiàng)指令的執(zhí)行(即命令的產(chǎn)生者可能來(lái)源于多種對(duì)象)都托CommandExecutor 處理，僅有一個(gè)接口方法：execute(Command command) o ActivityBehavior: 活動(dòng)行為定義，用

14、于定義BPMN2.0執(zhí)行語(yǔ)義層的各圖元在流程引擎的行為，或稱(chēng) 之為所具備的圖元特征。與Command的概念類(lèi)似，僅僅描述“待執(zhí)行”的指令 是什么，會(huì)發(fā)生什么樣的行為，但真正要執(zhí)行時(shí)則由引擎負(fù)責(zé)驅(qū)動(dòng)。人機(jī)交互任務(wù)是業(yè)務(wù)流程應(yīng)用中最常用的業(yè)務(wù)類(lèi)型，以BPMN2.0中定義的 “Task”這個(gè)典型元素說(shuō)明一下命令模式在Activiti5中的應(yīng)用：Activiti5 針對(duì) BPMN2.0 的 Task Element 定義了 Task 接口，并依據(jù) Semantic.xsd執(zhí)行語(yǔ)義定義了相關(guān)任務(wù)元素所具有的行為特性，此行為特性通 過(guò) setActivityBehavior方法進(jìn)行行為與元素的綁定，這些B

15、ehavior在流程 引擎驅(qū)動(dòng)流轉(zhuǎn)到活動(dòng)節(jié)點(diǎn)時(shí)將被觸發(fā)，通 過(guò) execute(ActivityExecution execution)執(zhí)行 ActivityBehavior 中指定 的操作；每個(gè)活動(dòng)有若干 個(gè)Command與之對(duì)應(yīng)，比如ClaimTaskCmd、CompleteTaskCmd、 DelegateTaskCmd、 SaveTaskCmd、 DeleteTaskCmd 等，分 別表示任務(wù)的領(lǐng)取、完成、轉(zhuǎn)交、保存、刪除等，這些操作指令的執(zhí)行結(jié)果通過(guò) 命令執(zhí)行上下文 (CommandContext)得到DAO層的TaskManager將任務(wù)對(duì)象的 變更持久化到數(shù)據(jù)庫(kù)中；引擎不關(guān)心要執(zhí)

16、行什么，凡是實(shí)現(xiàn)了 Command接口的類(lèi)都可以通過(guò) CommandExecutor執(zhí)行，除了引擎提供的這些原生的任務(wù)指令外，如果業(yè)務(wù) 系 統(tǒng)有額外的特性化操作，也可以自定義一組Command，在Command.execute()中 自由調(diào)用外部服務(wù)、發(fā)送手機(jī)短信、附加任務(wù)屬性、調(diào)用DAO操作數(shù)據(jù)庫(kù)等， 封裝完畢后交由引擎去執(zhí)行，即可得到希望的結(jié)果。同樣，如果在業(yè)務(wù)系統(tǒng)中需 要自定義BPMN元素或?qū)傩?，僅需同步增加ActivityBehavior接口的實(shí)現(xiàn)，在 解析流程定義文件時(shí)將自定義的行為實(shí)現(xiàn)與元素(屬性)幫定，并緩存之，待引 擎驅(qū)動(dòng)到達(dá)節(jié)點(diǎn)時(shí)自動(dòng)執(zhí)行。在 ActivityBehavior

17、. execute()中依然可以調(diào) 用各種各樣的API已實(shí)現(xiàn)特定的業(yè)務(wù)目的。此處需要注意的是，Activiti5的CommandContext是包含事務(wù)處理的，在每 次關(guān)閉上下文環(huán)境時(shí)，會(huì)執(zhí)行事務(wù)的提交，但在實(shí)際業(yè)務(wù)系統(tǒng) 中，業(yè)務(wù)事務(wù)、 引擎事務(wù)以及數(shù)據(jù)庫(kù)事務(wù)應(yīng)該是被統(tǒng)一到一個(gè)事務(wù)中去管理，這就需要將 Activiti5的事務(wù)與業(yè)務(wù)系統(tǒng)的事務(wù)合并。Activiti5通 過(guò)Spring注入提供了 該方式的可行性，引擎內(nèi)部的事務(wù)控制可以委托給業(yè)務(wù)層去處理，在初始化引擎 配置時(shí)，將業(yè)務(wù)系統(tǒng)中定義的DataSource和 TransactionManager傳遞給流程 配置的 dataSource、t

18、ransactionManager 屬性后，Activiti5 內(nèi)部會(huì)使 用 Spring 提供的 TransactionAwareDataSourceProxy 來(lái)封裝傳進(jìn)來(lái)的 DataSource， 并利用外部的事務(wù)管理來(lái)接管Activiti5的事務(wù)控制，確保了從該DataSource 獲取的數(shù)據(jù)庫(kù)連接與Spring定義的事務(wù)能夠完美地結(jié)合，從而實(shí)現(xiàn)業(yè)務(wù)系統(tǒng) 與引擎系統(tǒng)事務(wù)的集成。Activiti5對(duì)BPMN2.0執(zhí)行語(yǔ)義的解析Activiti5通過(guò)BpmnParse使用SAX方式進(jìn)行BPMN2.0 XML流程定義文件的 解析，是解析的核心類(lèi)，從根節(jié)點(diǎn)開(kāi)始解析，依次對(duì)Definitions

19、Attributes、 Imports、 ItemDefinitions、Messages、Interfaces、和 Errors 以及 ProcessDefinitions各個(gè)元素進(jìn)行解析（以上均是標(biāo)準(zhǔn)的BPMN2.0元素），最后解析負(fù)責(zé)流程可視化定義的DiagramInterchangeElements元素。每解析一 個(gè)元素都會(huì)判 斷元素類(lèi)型，如果是“活動(dòng)“類(lèi)型（包括Task、Gateway等）， 則會(huì)為活動(dòng)設(shè)置相應(yīng)的ActivityBehavior，同時(shí)如果流程定義文件中定 義了 額外屬性，Activiti5會(huì)自行利用反射機(jī)制注入到ActivityBehavior。除了 Command和

20、ActivityBehavior外，Activiti5還大量引入了監(jiān)聽(tīng)機(jī)制（攔 截器的概念），目前引擎主要包含四類(lèi)監(jiān)聽(tīng)：BPMN解析監(jiān)聽(tīng)BpmnParseListener，負(fù)責(zé)對(duì)BPMN2.0規(guī)范的流程定義文 件進(jìn)行解析控制；任務(wù)監(jiān)聽(tīng)TaskListener，負(fù)責(zé)對(duì)各類(lèi)任務(wù)的狀態(tài)以及任務(wù)創(chuàng)建、指派責(zé)任人、完成任務(wù)三類(lèi)事件進(jìn)行響應(yīng)；執(zhí)行監(jiān)聽(tīng) ExecutionListener，對(duì)執(zhí)行過(guò)程添加輔助管控功能，對(duì)引擎 中發(fā)生的啟動(dòng)、流轉(zhuǎn)、結(jié)束事件進(jìn)行響應(yīng)；事務(wù)監(jiān)聽(tīng)TransactionListener，負(fù)責(zé)事務(wù)控制監(jiān)聽(tīng)。PVM流程虛擬機(jī)中包含三類(lèi)事件：Start、End、Take，分別表示流程的啟動(dòng)、

21、 流轉(zhuǎn)和結(jié)束，流程啟動(dòng)后，流引擎會(huì)從Start事件開(kāi)始執(zhí)行，通過(guò)Take事件， 驅(qū)動(dòng)流程流向下一個(gè)環(huán)節(jié)，該“流向”的動(dòng)作會(huì)被PVM運(yùn)行時(shí)的AtomicOperationTransitionNotifyListenerTake 監(jiān)聽(tīng)，該監(jiān)聽(tīng)會(huì)將附加到 該流向的所有執(zhí)行監(jiān)聽(tīng)依次執(zhí)行。任務(wù)有 也有三類(lèi)事件可以被監(jiān)聽(tīng)：Create、 Assignment、Complete,如果希望在任務(wù)被創(chuàng)建或指定了相關(guān)責(zé)任人或任務(wù)完成 后增加些額外的輔助功能，可以創(chuàng)建TaskListener接口的實(shí)現(xiàn)類(lèi)，并將其定 義到執(zhí)行定義元素中，Activiti5會(huì)處理這一切。這些監(jiān)聽(tīng)本質(zhì)上都算是活動(dòng)的 附加代理，在現(xiàn)有操作的

22、基礎(chǔ)上額外增加一個(gè)管理控制手段以達(dá)到特殊的目 的，ActivityBehavior從另一個(gè)角度來(lái)看也是一種代理，都是 由DelegateInvocation負(fù)責(zé)調(diào)用執(zhí)行，它主要用來(lái)提供用戶(hù)代碼調(diào)用的上下 文環(huán)境并負(fù)責(zé)控制實(shí)際調(diào)用，Activiti5為其提供了五個(gè)實(shí) 現(xiàn)： ActivityBehaviorInvocation、ExecutionListenerInvocation 、 ExpressionInvocation 、 JavaDelegateInvocation、 TaskListenerInvocation。Activiti5 提供的 Command、ActivityBehavio

23、r、Listener 等接口為引擎的 功能擴(kuò)展提供了方便，如果業(yè)務(wù)系統(tǒng)的功能不 能滿(mǎn)足時(shí)可以實(shí)現(xiàn)這些接口，以 無(wú)侵入的方式擴(kuò)展Activiti5，利用這些擴(kuò)展接口，可以在其執(zhí)行方法中完成很 多業(yè)務(wù)邏輯，如權(quán)限校驗(yàn)、與業(yè)務(wù)系統(tǒng)的交 互、與外部系統(tǒng)集成調(diào)用，甚至替 換原有功能偷梁換柱暗度陳倉(cāng)。Activiti5 API 應(yīng)用ProcessEngine是Activiti系統(tǒng)的核心接口，七類(lèi)基礎(chǔ)服務(wù)接口通過(guò) ProcessEngine獲取，均采用鏈?zhǔn)紸PI方式，直觀明了，易于使 用：RepositoryService：流程資源服務(wù)的接口，主要用于對(duì)流程定義的部署、查 詢(xún)和刪除操。新流程的部署使用createDeployment().addResourceXXX().deploy()方法；已部署流程的查詢(xún) 使用createDeploymentQuery()附加查詢(xún)條件的方式獲??；另外可以使用 deleteDeployment和 deleteDeploymentCascade方法進(jìn)行流程的刪除或級(jí)聯(lián) 刪除。TaskService:任務(wù)服務(wù)接口，該接口暴露了管理人機(jī)交互任務(wù)的操作，如 任務(wù)領(lǐng)取(claiming)、任務(wù)完成(completing)和任務(wù)指派(assigning)， 還包括對(duì)任務(wù)的創(chuàng)建