1 BPMN的歷史背景
BPMN(Business Process Model and Notation)，業務流程建模和標註。 Notation是BPMN的核心，即使用圖形來表達業務流程。另外，BPMN是由OMG組織維護的一個公開的標準，與任何特定商業組織或工具是沒有關係，無需爲此付費。BPMN和傳統的流程圖的區別如下：
- BPMN是一個正式的規範，各種圖標、元件是有準確的含義和使用規範
- BPMN可以描述基於事件觸發的行爲，比如響應超時、外部系統無法提供服務等
BPMN 標準發展版本歷史如下。BPMN2.0在1.x基礎上新增了元模型、存儲、交互、執行。
版本號 | 發佈時間 |
1.0 | 2007年3月 |
1.1 | 2008年1月 |
1.2 | 2009年1月 |
2.0 | 2011年1月 |
BPMN1.x被大多數的建模工具和BPMS廠商所支持。但是， BPMN1.x只是一些建模符號，不支持元模型，不支持存儲和交換，也不支持執行。那麼圍繞着BPMN1.x的存儲、交換和執行，必然會產生新的競爭，這次的主角換成了XPDL、BPEL和BPDM。
XPDL作爲WfMC(工作流管理聯盟)提出的流程定義語言規範，本身就是一個元模型，可以存儲，並且具備執行語義。如今有超過80個的不同公司的產品使用XPDL來交換流程定義，同時也有一些廠商在自己提供的BPMN工具中使用了XPDL作爲交換和存儲格式。
爲了抗衡XPDL，OASIS組織(包括幾個大的平臺公司，Microsoft、 BEA、 IBM、 SAP 、Sun、Oracle)開發了BPEL規範。但BPMN到BPEL的轉換存在着先天上的缺陷，原因是BPMN是基於圖的，而BPEL是基於塊的。這個缺陷導致有些BPMN建模的流程無法映射到BPEL，兩者的雙向工程更是存在問題。這個缺陷成爲人們反覆詬病的對象。許多支持BPEL的產品爲了解決這一問題，不得不在用戶建模時做出種種限制，讓用戶繪製不出無法轉換的模型。
而BPDM（業務流程定義元模型）則是OMG組織自己提出來解決BPMN存儲和交換問題的規範。於2007年7月形成初稿，2008年7月被OMG最終採用。BPDM是一個標準的概念定義，用來表達業務流程模型。元模型定義了用來交換的概念，關係和場景，可以使得不同的建模工具所建模出來的流程模型進行交換。BPDM超越了BPMN和BPEL所定義的業務流程建模的要素，它定義了編排和編制。
三者的競爭關係似乎還將繼續，但，BPMN2.0出現了。BPMN2.0相比BPMN1.x，最重要的變化在於其定義了流程的元模型和執行語義，即它自己解決了存儲、交換和執行的問題，BPMN由單純的業務建模重新迴歸了它的本源，即作爲一個對業務人員友好的標準流程執行語言的圖形化前端。BPMN2.0一出手，競爭就結束了，XPDL、BPEL和BPDM各自準備回家釣魚。看起來勝利者似乎是BPMN，但看看BPMN2.0的領導者，就會發現最後的勝利者還是IBM，Oracle和SAP這些大廠商們，他們提交的草案明確要賦予BPMN2.0以執行語義，這迫使BPDM團隊撤回了其提交，並將他們的提議與BPDM團隊想法合併，這就是BPMN2.0最後內容的由來。
BPMN官網：http://www.bpmn.org
2 BPMN的例子
本章使用一個簡單的訂單處理的業務流程爲例，簡要的說明BPMN的作用。
2.1 一個簡單的訂單流程
企業收到訂單後，檢查購買者的信用卡，執行訂單，提供發票。如下圖所示，圓形表示事件，第一個元件表示開始事件，最後一個元件表示結束事件，圓角矩形表示一個任務(task/activity)，帶箭頭的實現表示順序流(sequenceFlow)
2.2 異常和結束狀態
上圖只描述了正常的情況。信用卡過期，倉庫無庫存如何處理？所以業務流程圖中應該新增其它異常分支。在BPMN中，使用菱形表示網關(gateway)，用來控制流程中的流向。注意圖中包含了三個結束事件，每個結束事件表示不同的結束狀態。
2.3 泳道(swimlane)和執行者(performer)
泳道用來指明任務的執行者。如下圖所示，銷售人員接受訂單，倉庫執行執行訂單，財務處理髮票。注意不是所有的任務都會有執行者（更精確的說，只有user task纔有執行者）。
2.4 子流程
執行訂單是一個子流程，子流程必須有開始事件和結束事件，子流程內部的元件禁止和外部的元件直連，只能作爲一個整體與父流程的元件相連接。
3 BPMN2.0中的基礎元件
除了事件觸發的行爲，你幾乎可以使用的本章節的元件創建所有的業務流程。
3.1 Activity
一個activity表示一份待完成的任務或工作，用圓角矩形表示。分爲任務(task)和子流程(subprocess)。
3.1.1 任務
一個任務表示工作需要被外部實體完成，比如人工或自動服務。 任務的類型顯示在矩形的左上角，用小圖標區別。根據任務的類型，引擎會執行不同的功能。
人工任務(User Task)
人工任務表示需要人來執行的任務，有一個輸入和一個輸出。
相關的XML定義：
服務任務(Service Task)
Service Task是一個自動活動，它會調用一些服務， 比如web service，java service等等，必須有一個輸入和一個輸出。
相關的XML定義：
腳本任務(Script Task)
腳本任務時一個自動活動，當到達這個任務的時候流程引擎會執行一個腳本。必須有一個輸入和一個輸出。支持的腳本語言有Java，JavScript，XPath1.0，mvel。如下圖所示。
相關的XML定義：
腳本任務與服務任務的區別。服務任務一般用來處理和外部服務之間的交互。腳本任務只用來執行一些簡單的邏輯。
規則任務(Business Rule Task)
規則任務用來執行使用Drools定義的規則集，規則集通過ruleflow-group來識別。
Drools規則的定義
3.1.2 子流程(subprocess)
子流程表示多個activity的組合。子流程內部的元件禁止和外部的元件直連，只能作爲一個整體與父流程的元件相連接。如下圖所示。
jBPM中支持的子流程如下圖。
3.2 網關(gateway)
網關用來控制業務流程走向。分爲如下四個之類，每個類型網關都需要設置gateway direction屬性。下面的值可以使用：
converging：網關必須擁有多個進入順序流， 但是只能有一個外出順序流。
diverging：網關必須擁有一個進入順序流， 和多個外出順序流。
3.2.1 唯一網關(Exclusive Gateway)
用一個內部包含X的菱形表示。
diverging
表示只有一個外向順序流被執行。在執行時，必須確保至少一個外向順序流上面的條件爲true。
converging
每個入口順序流執行完成之後，都會觸發一次唯一網關後面的順序流。
3.2.2 並行網關(Parallel Gateway)
Diverging
表示多個外向順心流會同時執行。
Converging
等待所有的入口順序流完成之後，纔會觸發出口順序流。
3.2.3 包含網關(Inclusive Gateway)
Diverging
只要外向順心流上面的條件爲true，則都會被執行。
Converging
等待所有的active入口順序流完成之後，纔會觸發出口順序流。
3.3 開始事件
表示業務流程是如何開始的。用一個細線圓表示，園中的圖標表示觸發的方式。
空啓動事件: 表示沒有指明觸發者。子流程必須有一個空啓動事件。
消息啓動事件: 由外部消息來觸發流程的執行。
定時器啓動事件: 由時間來觸發流程的執行。
3.4 結束事件
使用粗線圓表示，意味着流程的一個順序流的結束。和啓動事件不一樣，在一個流程中出現多個結束事件是非常常見的。
空結束事件
表示流程中一個路徑的結束，不返回任何結果。
消息結束事件
表示流程中一個路徑的結束，併發送一個消息。
Terminate結束事件
結束整個流程的執行，即使有並行路徑在執行。
3.5 順序流(Sequence Flow)
表示順序執行的順序，用實線箭頭表達。
3.6 數據(Data Object)
Data Object可以理解爲流程實例的局部臨時變量，流程實例結束後Data Object也被釋放。
Notofication對應的workitemhandler源碼如下：
3.7 Artifact
artifact表示沒有執行語義，也就是說對流程的執行沒有任何影響。BPMN中有兩種artifact，註釋和分組。
3.8 註釋(Text Annotation)
用於對流程圖中的元件進行解釋說明。
3.9 分組(Group)
用帶虛線的矩形框表達，本質上沒有任何執行相關的含義。
4 參考
1 https://blog.csdn.net/ronghao100/article/details/6617257
2 BPMN Method and Type