我過去發布過一些有關遷移策略的文章，仔細研究了流程層，并提供了一些有關jBPM的最佳實踐 ，它們都涉及到BPM策略的非常具體的部分。 我想重新討論最佳實踐的主題，然后在智能集成企業級別上，我們討論使用JBoss BRMS對您的業務流程進行控制。

介紹

首先，我們需要仔細研究景觀，然后像洋蔥一樣剝開圖層，仔細研究如何提供可擴展的BPM項目。 圖1顯示了我們需要集中注意力的幾個組件層：

• 流程初始化層
• 流程實施層
• 流程資料庫
• 業務用戶和開發人員的工具
• 控制臺，報告和BAM儀表板
• 流程交互層

圖1：企業BPM格局。

本文將介紹流程初始化層，在此我將向您介紹一些最佳實踐，圍繞您，您的客戶以及如何啟動流程。

在流程存儲庫，工具，業務用戶和設計流程的開發人員的幫助下，流程實現層是維護流程的地方。 在這里，您還將找到各種實現細節，例如特定領域的擴展，以涵蓋我們項目中特定節點的類型。 稍后將介紹該層的最佳實踐。

控制臺，報告和BAM儀表板組件是項目中使用的擴展工具，用于提供可用于影響業務決策的業務價值或信息。 稍后將介紹該領域的最佳做法。

最后，在流程交互層中，您的流程將連接到各種形式的遺留系統，后臺系統，服務層，規則系統甚至第三方系統和服務。 該領域的最佳實踐將在以后的文章中介紹。

圖2：入門。

流程初始化層

看一下如何初始化流程，我想向您提供一些我多年來在大型企業中看到的最佳實踐。

似乎有一個主要主題是收集啟動流程所需的客戶，用戶或系統數據，然后通過startProcess調用將其注入。 可以通過BRMS jBPM API調用，使用RESTful服務或通過標準Java Web服務調用將其嵌入到您的應用程序中。 無論您如何收集數據以初始化流程實例，都可能要考慮從一開始就如何擴展初始化設置。 通常，最初的項目設置時對未來沒有太多考慮，因此某些問題沒有被考慮在內。

顧客

此處定義的客戶可以是提供初始過程啟動數據的人員，系統或某些用戶。 在圖2中，我們對客戶如何提供過程數據進行了高層次的研究，然后將這些過程數據打包成一個請求，以放入一個過程隊列中。 然后，我們可以從隊列中確定優先級，并讓不同的機制獲取這些流程請求，并使用提供的請求數據啟動流程實例。 我們在此處顯示了EJB，MDB和云，它們表示可以用來清空進程隊列的任何調度方式。

Queue列

這些隊列可以像數據庫表一樣簡單，也可以像消息隊列一樣完善。 可以按照項目需要的任何方式進行設置，例如后進先出（LIFO）或先進先出（FIFO）。 使用消息隊列的好處是，您可以通過輪詢機制確定它們的優先級。

此設置的原因有兩個。 首先，您通過不直接從客戶界面啟動流程實例來確保您保留了客戶請求。 它將永遠不會丟失到流程引擎。 其次，您可以對可能無法滿足項目要求的未來流程進行優先級排序，例如必須在客戶提交后10秒鐘內開始的新流程請求。 如果將其放在需要花費一個小時才能處理的隊列的底部，那么您就遇到了問題。 通過對隊列進行優先級排序，您可以調整輪詢機制以每次以正確的順序檢查適當的隊列。

Java /云

圖2中的Java圖標代表您可能想用來處理進程隊列的任何JEE機制。 它可以是EJB的，MDB的，您自己編寫的調度程序或您想拿出的任何程序來拾取流程請求。

云圖標旨在表示服務，您的軟件可以使用這些服務來實際調用最終的startProcess方法，以初始化所請求的流程實例并將其傳遞給初始數據。 將與jBPM API的交互集中到一個服務中很重要，這樣可以確保在API更改的情況下進行最少的工作，以便將來進行可能的版本遷移，并且如果您希望在將來的項目中進行擴展，以擴展與jBPM的服務交互。

結論

本文簡要介紹了高級BPM體系結構，并列出了交互的各個層次。 在較大的企業BPM體系結構中，交互的第一層是初始化層，以提供對該層內最佳實踐的一些見解。 討論不是試圖推動實現細節，而是退后一步，介紹在大型BPM體系結構中反復遇到的一些基本元素。 它涵蓋了客戶最初提交的處理請求，處理請求的排隊以及以一致且可擴展的方式處理這些隊列。 在以后的文章中，流程實現層，流程交互層，流程存儲庫，工具以及報告和BAM層中還有更多內容需要關注。

參考： JBoss BRMS最佳實踐–來自我們的JCG合作伙伴 Eric D. Schabell的BPM流程初始化層的提示， 有關中間件，Linux，軟件，騎行和其他新聞的思想…博客。