bpmn和cmmn與dmn結合舉例
我們演示這三個標準的場景來自保險行業。它被簡化了，但它代表了我們反覆遇到的各種現實生活情況。注意，這裏使用的模型不僅僅是理論構造或文檔;它們可以通過引擎執行，其中之一就是我們自己的產品camunda bpm。camunda bpm允許您在所有三個標準中建模和執行模型:bpmn、cmmn和dmn。
如果您沒有使用bpmn、cmmn或dmn的經驗，下面的內容可能看起來像是您還不知道的符號語言的強制行軍。不過沒關係，有些元素不理解，我們將在以後的文章中會再次詳細講解，歡迎持續關注，技術支持盤古BPM
讓我們開始吧。
圖：camundanzia網站。
假設你想買汽車保險。現在，你的第一站是互聯網，在那裏你比較報價並決定供應商。您訪問您選擇的保險公司的網站——在這種情況下，是虛構的camundanzia保險公司。使用以下數據填寫申請表格(見上圖:）
-
你的出生日期是1980年1月1日。我們寫這篇文章的時候，你36歲。
-
你的汽車是寶馬公司生產的。車型爲x3。
您點擊提交表單，然後向後靠，急切地等待您的保險政策。
表單中的數據立即在camundanzia創建一個業務流程實例，該實例是在bpmn中建模的，在技術上是在camunda bpm中實現的(參見下圖)。我們可以從接收到的啓動事件應用程序看出這一點。上篇文章中首先提到的兼容bpmn的工作流引擎現在開始工作。
圖:bpmn中的請求處理。
該流程從確定風險業務規則任務開始。在模型端，該任務與決策引擎執行的dmn決策表風險評估(參見下圖)相關聯。決策引擎評估申請人年齡、汽車製造商和汽車模型的輸入值。當執行業務規則任務時，工作流模型將這些值轉移到決策引擎。
圖:dmn的風險評估。
因爲你說你開的是寶馬x3，所以第五條規則適用於任何年齡的人。這條規則規定，任何高價值車輛的駕駛員都將得到黃色風險評級。
決策引擎提供兩個輸出值——一個用於車輛，另一個用於車輛對於風險評級——回到工作流引擎，它繼續執行流程。在接下來的步驟中，我們將遇到一個異或網關，它將根據風險評估決定流程如何繼續。
如果沒有發現任何風險，網關就會選擇標籤爲none的路徑。這將導致問題策略服務任務。工作流引擎將通過接口調用camundanzia的後端系統，後端系統將生成一個文檔。反過來，文檔將被反饋給工作流引擎。下一步是send policy任務，它將文檔轉發給您。
然而，你的風險屬於黃色類別。異或網關激活應用程序檢查調用活動。這個調用活動在bpmn模型的屬性中鏈接到cmmn模型(參見下圖)，並且cmmn模型現在在case引擎中實例化。工作流引擎等待case引擎報告完成。工作流引擎是耐心的，但由於附加的時間事件，在等待兩天後，它將啓動升級。它將啓動一個名爲加速應用程序評估的用戶任務。例如，可以將用戶任務分配給負責應用程序評估的知識工作者的團隊領導。
圖:cmmn中的應用檢入。
讓我們假設知識工作者，即具有專家知識的辦公室職員，立即處理案例。他問自己:“儘管這輛車價值很高，這個申請人還應該投保嗎?”“除了必須處理的決定申請任務外，職員可選擇:
請求進一步的文檔:職員可以啓動請求文檔流程任務，該任務反過來被鏈接到一個單獨的bpmn流程模型。
詢問其他意見:職員可以啓動用戶任務評估應用程序，該應用程序將任務分配給他的團隊領導。
圖:決定應用程序時辦公室職員的任務表單。
上面的步驟可以以任何順序和多次執行，或者可以跳過這些步驟並立即決定應用程序。那是由辦公室職員決定的。在上圖中，我們看到了職員的任務表單。他可用的選項顯示在右邊。
如果職員接受了請求，則哨兵會用小鑽石表示，表示該決定必須由另一人授權。使授權成爲必要的環境可能已經作爲表達式存儲在哨兵中，或者它們可能已經定義在由哨兵引用的單獨dmn決策表中。在任何一種情況下，case引擎都會自動確定是否必須執行approve decision用戶任務。
如果最終結果是接受應用程序，cmmn案例將在該狀態中完成。現在，bpmn流程繼續進行，也就是說，工作流引擎到達xor網關決策並選擇應用程序接受的路徑。現在，上面描述的可能性變成了現實:服務任務從後端系統檢索保險策略，發送任務通過電子郵件將其發送給申請人。
也許從你遞交汽車保險申請書到現在才過了半個小時。你把時間都浪費在了打盹上，不是嗎?但是當你收到一封新郵件時，你的幻想就結束了。您激動的速度，Camundanzia 能夠發佈您的保險政策。
我們的示例到此結束。我們希望它能起到啓發作用。如果你願意，你可以在http://camunda.com/poster上看到這個例子的一張時髦的海報。我們很樂意免費寄給你。
如您所見，這三種bpm標準中的每一種都有各自的角色，但它們也有重疊之處。關於這個問題，我們經常會遇到兩個問題:
-
基於業務規則的決策可以通過網關在bpmn中表示，那麼我們爲什麼需要決策表呢?我們將在後面的文章中回答這個問題。
-
在bpmn中，存在特別的子進程。這不是專門爲cmmn現在要處理的用例開發的嗎?我們在後面的文章中討論這個問題。
還有另一個棘手的主題:在流程協調期間實現高度結構的困難。相關人員可能會得出結論，這個過程必須保持他們行動的靈活性。也許他們擔心bpmn會變得過於嚴格，所以他們很快就避開了cmmn作爲替代。他們希望保持靈活性，但仍然享受過程改進的所有好處。這是一個謬論!明確定義的過程結構和過程改進之間的聯繫是不容置疑的。依靠cmmn而不是bpmn是要冒放棄的風險:
-
透明度:cmmn圖較少地揭示了業務過程是如何被處理的，也就是說，在什麼情況下執行了哪些活動。畢竟，決策權是留給知識工作者的。因此，公司相對依賴於知識型員工。
-
效率:知識型員工具有長期積累的特殊知識和經驗。這意味着它們價格昂貴，而且很難被取代——或者隨着業務量的增加而複製。在這樣的條件下，你怎麼能設想整個過程的自動化呢?因此，業務模型的可伸縮性受到限制。
-
(結構)靈活性:如果過程需要修改，cmmn可以簡單地調整。然而，如果一個知識工作者被期望以不同於過去的方式工作，他或她將不得不被告知和說服。這樣做很麻煩，在某種意義上，也降低了結構的靈活性。是的，你可以爭辯說cmmn的重點是爲知識工作者提供很大的靈活性來進行自主決策，但是與使用bpmn相比，它需要更多的時間和精力來影響公司的決策行爲。如果市場狀況的變化比知識型員工改變習慣的能力或意願更快，就可能出現問題。
我們現在是在反對cmmn嗎?不。cmmn建立在合理的思考之上，如果使用得當，它是非常有價值的。我們努力要指出的一點是，當用BPMN開發一個清晰定義的過程結構似乎很難的時候，簡單地使用cmmn作爲最小阻力的路徑是錯誤的。我們不希望產生軟件開發中所謂的技術債務——這種債務在短期內使生活更容易，但在未來會產生更頑固、更昂貴的問題。
未來會出現更頑固、更昂貴的問題。
因此，我們的建議(基本上也是我們的經驗法則)是，首先認真嘗試在bpmn中定義所需的流程。對於那些不能獲得清晰的過程結構並且需要給知識工作者留有餘地的過程，考慮cmmn。
本文會持續更新，歡迎關注，技術支持：盤古BPM