BPMN指南：使用標準流程符號記錄遺留系統互動

組織通常運行在複雜的應用生態系統中。有些是現代的雲原生平台，而其他則仍是基礎性的遺留系統。這些較舊的系統經常儲存無法輕易捨棄的關鍵業務資料與邏輯。挑戰在於，即使無法取得其內部原始碼或專有文件，仍需理解這些系統之間如何通訊。這正是標準流程符號變得至關重要的原因。

使用業務流程模型與符號（BPMN）來記錄遺留系統互動，可提供一種通用語言。它彌補了技術限制與業務需求之間的差距。本指南概述了映射這些互動的權威方法。其重點在於準確性、清晰度與可維護性，且不依賴特定供應商的工具。

🔍 標準符號的必要性

遺留系統通常如同「黑箱」。你清楚輸入與輸出，但內部處理邏輯卻不透明。依賴口耳相傳的知識或零散的文件會導致技術負債。當流程變更時，未記錄的依賴關係會導致失敗。標準符號透過建立視覺合約來解決此問題。

BPMN 在遺留環境中的主要優勢：

• 供應商獨立性： 該符號為 ISO 標準，不依賴於特定的實作工具。

• 清晰度： 視覺模型相比文字需求能有效減少歧義。

• 整合規劃： 它能突顯資料必須在系統間移動的位置，以及決策發生的位置。

• 缺口分析： 建模能揭示缺失的錯誤處理或資料驗證步驟。

透過採用標準，可確保即使底層技術架構變更，文件仍保持有效。重點始終放在業務邏輯上，而非程式碼。

📋 資料清單準備

在繪製任何形狀之前，必須先了解整體環境。遺留系統的互動通常涉及與現代 REST 或 SOAP API 不同的獨特通訊協定。詳細的資料清單可避免在建模階段出現錯誤。

必要清單項目：

• 系統介面： 識別所有進入點。是檔案傳遞？直接資料庫查詢？還是交易程式碼執行？

• 通訊協定： 確定傳輸機制。是 FTP、SFTP、EDI、JMS，還是直接資料庫呼叫？

• 資料格式： 遺留系統常使用固定寬度的檔案、COBOL 複本檔或 XML。請記錄其結構。

• 時間： 互動是即時、批次還是排程的？這決定了模型中使用的事件類型。

• 安全性： 驗證方式各異。是憑證、密碼，還是網路層級存取？

收集這些資料，可幫助你選擇正確的 BPMN 元素。例如，若使用錯誤的元素來表示檔案傳輸，可能會讓利害關係人對延遲與可靠性產生混淆。

🏗️ 遺留互動的核心建模元素

標準符號提供特定的形狀來代表不同類型的活動。在處理遺留系統時，元素選擇的精確性對於準確表示至關重要。

🏢 群組與泳道

群組代表不同的參與者。在遺留系統的背景下，每個主要系統都應擁有自己的群組。這可將一個系統的邊界與另一個系統分開。

• 外部系統群組： 代表遺留的主機系統或資料庫伺服器。

• 流程群組： 代表現代的編排層或應用程式。

• 泳道： 在流程群組內，使用泳道來標示不同的團隊或內部模組（例如：「前端」、「整合層」、「資料庫存取」）。

訊息流連接群組，序列流則停留在群組內部。混淆這兩者是一種常見錯誤。訊息流表示跨越邊界，這在遺留系統互動中非常典型。

🎯 事件

事件代表某件發生的事。在遺留系統整合中，事件的類型決定了系統的行為。

• 起始事件： 由外部檔案到達、手動請求或預設計時器觸發。

• 中間捕獲事件： 等待來自遺留系統的回應。使用訊息圖示表示通訊。

• 中間拋出事件： 向遺留系統發送請求或檔案。

• 結束事件： 成功完成或錯誤終止。

對於遺留系統的輪詢機制，請使用計時器中間事件。這明確記錄了系統會等待一段時間後才檢查資料，而非接收推送通知。

🔄 網關

網關用於管理控制流程。遺留系統通常具有嚴格的決策邏輯，必須在流程模型中予以反映。

• 互斥網關（XOR）： 用於簡單的二元決策（例如：「記錄找到」對「記錄未找到」）。

• 包含網關（OR）： 當多條路徑可同時進行時使用（例如：「更新帳本」與「發送通知」）。

• 複雜網關： 當邏輯過於複雜，無法用標準的 XOR/OR 表示時使用，通常需要程式碼執行邏輯。

在建模遺留系統錯誤處理時，通常會使用互斥網關，根據舊系統回傳的錯誤碼進行路由。

📡 處理非同步通訊

傳統系統很少與現代應用程式實時同步運作。它們通常依賴批次處理或輪詢。BPMN 透過特定的事件類型來處理此類情況。

輪詢模式：

如果傳統系統不支援推送通知，現代系統必須進行輪詢。這由計時器事件表示。

• 頻率： 在事件標籤中定義間隔（例如：「每 5 分鐘」）。

• 逾時： 使用邊界事件來處理傳統系統在預期時間內未回應的情況。

基於檔案的整合：

許多傳統系統的資料交換是透過檔案放置完成的。這需要使用檔案中間事件。

• 輸入： 該流程會等待特定檔名出現在目錄中。

• 輸出： 該流程會將檔案寫入指定的放置區域。

這些模式與 API 呼叫有顯著差異。準確記錄這些模式，可確保運營團隊清楚了解延遲預期。

💾 資料表示與轉換

傳統系統通常缺乏豐富的元資料。流程模型必須明確考慮資料轉換。這對於維持整合過程中的資料完整性至關重要。

資料物件：

使用資料物件來表示流程中流動的資訊。將這些物件附加到活動上，以顯示讀取或寫入的內容。

• 輸入資料： 顯示來源格式（例如：CSV、固定寬度）。

• 輸出資料： 顯示傳統系統所需的目標格式。

商業規則任務：

如果資料轉換涉及複雜邏輯（例如：根據傳統資料表計算利率），請使用商業規則任務。這可將流程邏輯與資料邏輯分離。

• 清晰性： 表示決策是根據外部資料規則做出的。

• 可追蹤性： 使開發人員能夠將特定邏輯與編排流程分離定位。

⚠️ 異常處理與補償

傳統系統並非總是可靠。它們可能會超時、拒絕資料，或傳回晦澀的錯誤代碼。強健的流程模型必須預見失敗。

邊界事件子流程：

將錯誤邊界事件附加到與傳統系統互動的活動上。這可捕獲失敗，而不會立即停止整個流程。

• 重試邏輯：建立一個子流程，以處理具有指數退避的重試。

• 死信佇列：將無法恢復的錯誤路由至特定佇列以進行手動審查。

補償：

某些傳統交易一旦提交便無法逆轉。若下游流程失敗，您可能需要撤銷傳統操作。請使用補償事件來定義「撤銷」邏輯。

• 觸發條件： 當主流程失敗時觸發此事件。

• 動作： 在傳統系統中執行反向交易。

這種細節層級在標準文件中經常缺失，但對生產穩定性至關重要。

📊 常見整合模式

理解常見模式有助於標準化文件。下表概述了典型的傳統互動及其對應的BPMN表示法。

模式	傳統環境	BPMN元素	關鍵考量
📂 檔案放置	傳統主機系統寫入SFTP	中間捕獲事件（檔案）	確保檔案鎖定機制已處理，以防止部分讀取。
🔁 輪詢	現代應用程式查詢主機資料庫	計時器中間事件	定義最大重試次數，以防止資料庫鎖定。
📬 訊息佇列	傳統系統推送至訊息佇列	中間捕獲事件（訊息）	如需確保，請確保訊息順序得以保留。
🔄 交易	更新舊系統記錄	交易（補償）	若步驟失敗，定義回滾程序。
⏳ 等待	等待手動批次執行	計時器中間事件	考慮營業時間與全天候處理之間的差異。

🛠️ 驗證與維護

模型建立後，必須進行驗證。無法執行或理解的圖表毫無用處。驗證包括將邏輯與實際系統行為進行比對。

驗證步驟：

• 走查：與舊系統團隊的專家一起走查圖表。

• 可追溯性：確保每個泳道和泳道都有明確的負責人。

• 完整性：檢查每個閘道是否都有出口路徑，且無死路。

• 效能：審查定時事件，確保其與實際系統效能指標一致。

維護策略：

舊系統即使演進緩慢，也仍會變化。文件必須與之同步演進。

• 版本控制：將流程圖表與程式碼一同儲存在版本控制系統中。

• 變更管理：只要介面合約變更，就更新模型。

• 訓練：利用模型訓練新開發人員了解舊系統的整合點。

🧩 記法中的技術細節

在將標準符號應用於舊系統時，存在一些特定的技術細節。理解這些細節可以防止誤解。

外部任務：

當某項任務需要外部邏輯，而該邏輯並非工作流引擎的一部分時，應使用外部任務。這在透過腳本或適配器調用舊系統時很常見。這表示工作流引擎將控制權交出並等待回調。

訊息關聯：

舊系統經常返回需要與原始請求匹配的回應。在BPMN模型中使用訊息關聯鍵。這確保當多個請求同時進行時，正確的回應會被路由到正確的流程實例。

交易邊界：

務必小心不要假設原子性。舊系統可能不支援分散式交易。記錄下資料一致性無法保證的邊界。使用錯誤事件明確處理這些不一致的情況。

📝 文件編寫最佳實務

為確保文件有效，應遵守嚴格的格式與內容標準。

• 一致性：在文件中始終使用相同的圖示集和顏色編碼。

• 註解：添加文字註解以解釋無法用圖形表示的複雜邏輯。

• 圖例：為所使用的任何自訂符號或特定協定圖示包含圖例。

• 元資料：在每張圖表上包含作者、日期和版本號。

清晰的文件可降低部署期間出錯的風險。同時，它也作為排查生產問題的參考。

🚀 展望未來

記錄舊系統的互動不僅僅是畫圖而已。這是要理解相關系統的限制與能力。透過使用標準流程符號，您將建立一個能經受技術變遷的持久資產。

專注於準確性而非美觀。確保每一條線都代表真實的互動。這種紀律為現代化工作奠定了基礎。當您最終取代舊系統時，流程模型依然有效，可引導新系統的實現。

採用此方法可確保您的整合架構具有透明度。讓利益相關者能夠看到資料流動與例外處理情況，而無需深入了解底層舊系統的技術細節。

首先清點您的介面。繪製關鍵路徑。定義錯誤情境。這種結構化方法可帶來穩定且可維護的整合模式。