1、基於數據的包容網關
想讓我們的過程更加靈活:當我們餓的時候，我們想要喫東西
- 只有一個沙拉,
- 沙拉和一些意大利麪或牛排，
- 或者只是意大利麪或牛排。
使用到目前爲止學到的符號，我們可以使用圖1.1所示的情況建模。
圖1.1:組合餐的各種選擇。
如果您想要更緊湊的表示，可以使用基於數據的包容性網關(或簡稱gateway)。(參見圖1.2)使用或網關來描述處理，可以沿着一個、多個或者所有傳出路徑的情況進行，或者網關可以防止圖變得過於複雜。
圖1.2：網關支持複雜路徑變量的緊湊表示
也可以組合路徑:取決於我們是隻喫沙拉還是喫一些牛排、意大利麪，或者是沙拉和牛排、意大利麪，我們必須等待一個令牌到達(合併)或兩個令牌(同步)，然後我們纔可以喫。但是，請注意它與圖1.1之間的區別。在沒有or gateway的版本中，我們本可以決定不準備任何東西(既不是沙拉也不是牛排和意大利麪)，但我們在做出這個決定後吃了東西。or gateway排除了這種荒謬。我們必須決定至少是沙拉或牛排和意大利麪，否則令牌會卡在入口。嚴格地說，bpmn規範確定在這種情況下會發生運行時錯誤，這對於技術流程實現很重要。
實際上，處理網關並不像這些示例所暗示的那樣簡單。很容易理解，進程依賴於等待另一個令牌到達or合併。對於跨越多個頁面的複雜圖表，跟蹤同步規則可能比較困難。僅僅記住“或者”拆分時的條件並不是一個解決方案。
圖1.3:第二個網關需要等待多長時間?
考慮圖1.3:or合併是否需要同步取決於or分割是否通過一個或多個路徑運行。場景:第一個令牌在30天后到達or合併。因爲答案2也應用於前一個或分割，另一個令牌正在進行中，它將在task 2中再停留15天。此任務完成後，xor分割時做出的決策可能會導致第二個令牌通過answer 1路徑路由，並被end事件使用。同步或合併時第一個令牌發生了什麼?or網關必須註冊第二個令牌已經消失，並且必須轉發第一個令牌。
這可能在三種情況下導致問題:
- 您在流程手冊的第10頁遇到了or merge，您必須翻看前面的9頁，以瞭解哪些條件需要哪些等待時間。
- 您在一個組織中實現這樣一個過程，該組織讓一個人負責任務3，但不允許這個人對過程進行控制。
- 工作流引擎運行流程並控制同步行爲。
實現這樣的檢查是昂貴的，而且肯定會失敗。在某些情況下，這是不可能的。
使用or網關有幾個原因——要小心。
問題:我們可以按照圖1.4所示的流程建模嗎?
圖1.4:非常緊湊的版本。
回答:當然，這使模型更緊湊，但它改變了意義。該過程模型產生以下結果:
- 我們只吃意大利麪。
- 我們只吃牛排。
- 我們只吃沙拉。
- 我們喫意大利麪和沙拉。
- 我們喫牛排和沙拉。
- 我們喫意大利麪和牛排。
- 我們喫意大利麪、牛排和沙拉。
最後兩種結果不是我們想要的!
本文會持續更新，歡迎關注，技術支持：盤古BPM