引言
本文將介紹高級治理解決方案的 IBM ODM 治理框架。本文基於可配置的 Java 業務邏輯（如 規則治理產品示例所示）提供了常用規則治理實現的一個靈活替代方案。我們將展示，使用規則（而不使用 Java）治理更改流程可在 ODM 中提高高級治理的能效和靈活性。
對於更改活動的治理，我們建議您查 看一下ODM V8.5 中新增的治理功能。
規則治理示例
產品示例中提供的治理擴展的架構如 圖 1 所示。本示例的核心是會話控制器，它根據狀態提供訪問權限。決策中心提供了一個自定義會話控制器，名為 WorkflowSessionController，它擴展了 IlrDefaultSessionController。WorkflowSessionController 替代 諸如 checkUpdate、checkCreate 和 checkDelete 之類的方法來執行治理操作。
該架構的限制如下：
狀態庫權限由嵌入到決策中心 EAR 中的文本配置文件控制。如果不重新部署 EAR，則無法應用配置更改。
采用 Java 實現自定義業務邏輯。由於實現和測試 Java 更改非常昂貴，因此可能需要與每個新版本的 ODM API 合並。此外，還需要針對節點的每個更改來重新部署決策中心 EAR。
項目訪問是通過組合兩個不同的角色概念來控制的：功能角色和項目角色。這可能會導致角色激增。有關 此內容的詳細信息，請參閱 分配角色 部分。
圖 1. 規則治理 ODM 產品示例的架構
基於規則的規則治理
考慮 以下場景：如果您將 EAR 文件中的治理邏輯委派給一個決策服務（如 圖 2 所示），會出現什麼情況。
圖 2. 規則治理決策服務
圖 2 中的架構假定決策中心與決策 服務器位於相同的應用程序服務器上，以便允許進行本地 POJO (Plain Old Java Object) 調用。另一個方法 是將 J2SE 規則引擎嵌入到決策中心 EAR 中。如果決策中心沒有訪問決策服務器的權限，則會使用該方法。
治理決策服務和治理會話控制器之間的參數接口是通過常規的規則集簽名模式來實現的。該模式能夠 更改規則模型 (.brmx)，無需重新部署決策中心 EAR。使用映射到規則模型的 Excel 動態域來構建對象模型 。
治理規則流
治理決策服務中的規則流如 圖 3 所示。它分為六個子流，這些子流很大程度上 與會話控制器方法是相對應的。
圖 3. 治理規則流
六個子流的用途如下所示：
Roles：返回功能角色
Status：返回提供產品當前狀態的狀態轉換
Permissions：確定角色產品的創建/更新/刪除權限
Committed：發生提供提交前和提交後狀態的通知消息
Validation：驗證規則和規則元數據並返回錯誤。
StyleCheck：對規則進行樣式檢查並返回警告。
在以下小節中，我們將查看這些操作。
角色
決策中心中的角色權限適用於所有項目。定義 項目訪問權限的方法是為每個項目和功能創建組合角色。例如，對於 Tester 的功能，項目 LoanValidation 將生成 TesterLoanValidation 角色。兩個名為 LoanValidation 和 Annuity 的項目和兩個名為 Tester 和 Author 的功能將生成以下組合角色：
AuthorLoanValidation
TesterLoanValidation
AuthorAnnuity
TesterAnnuity
我們將為 TesterLoanValidation 角色分配一個訪問 LoanValidation 項目的 tester。此外，還將為 TesterAnnuity 角色分配一個訪問 Annuity 項目的 tester。並為 TesterLoanValidation 和 TesterAnnuity 角色分配允許訪問這兩個項目的一個 tester。
對許多項目采用該方法可能會導致角色激增。例如，6 個功能角色和 10 個項目將需要 60 個角色。
一個簡單的方法是拆分項目角色和功能角色，然後限制 決策中心安全模型只對項目角色進行操作，並且限制治理決策服務只能對功能角色進行操作。圖 4 演示了功 能角色和項目角色的分離。
圖 4. 角色的分離
項目角色和功能角色的實現非常簡 單。只需在決策中心中分配項目角色即可，如 圖 5 和 圖 6 所示。
圖 5. 為 LoanValidation 項目 分配項目角色
圖 6. 為 Annuity 項目分配項目角 色
在規則治理中分配功能角色，如 圖 7 所示。現在，項目訪問由決策中心確定，功能訪問由下一部分所 述的規則治理權限規則確定。
圖 7. 在規則治理中分配功能角色
權限
如上一小節所述，我們 使用決策中心安全模型來確定項目訪問並委派對規則治理的細粒度訪問權限。這樣做不僅允許我們將功能角色 與項目角色分離，還允許我們分配細粒度訪問權限。例如，您可以根據規則狀態、文件夾、規則名稱和過期日 期來限制訪問。
在 圖 8 中，允許作者在 new、defined 和 cancelled 狀態中更改決策表屬性，但只 能在 new 狀態中更改規則主體 (definition)。
圖 8. 權限決策表
狀態
圖 9 中 的圖顯示了規則作者的狀態轉換。在 圖 10 所示的決策表中實現轉換。
圖 9. 狀態轉換圖
圖 10. 決策表中定義的狀態轉換
您可以看出，在圖 10 的第一行中 ，新創建的規則被設置為 new 狀態。在第二行中，作者被限制為從 new 轉到 defined 或 cancelled 狀態。
驗證規則
治理驗證規則制定了誰可以做什麼，並阻止在發生錯誤時提交規則。圖 11 顯示了一 個治理驗證規則，該規則阻止作者測試他自己的規則。當某個用戶同時被分配了 Tester 和 Author 角 色時，可能會出現這種情況。作者測試他或她自己的規則是不可取的行為，因為這違背了 “四眼 (four eyes)” 原則。
圖 11. 阻止作者測試他或她自己的規則的規則
圖 12 中的治理驗證規則阻止用戶在不使用文檔的情況下提交規則。
圖 12. 阻止作者不使用文 檔進行保存的規則
樣式檢查規則
樣式檢查規 則將會檢查可能存在的問題而不是錯誤。和驗證規則不同，樣式規則並不阻止用戶保存規則，而只是創建一個 警告消息。由作者以及最終的審稿人來決定是否應該采納警告建議。圖 13 顯示了實施命名標准的一個樣式規 則。該標准要求規則名稱以大寫字符開頭，後跟一個或多個小寫字符或數字。
圖 13. 實施命名標准的 樣式規則
如果某個名稱違反了這個慣例，則 會在 Warnings 屬性字段中顯示一條警告消息。在 圖 14 中，用戶輸入了一個包含美元符號的無效規則名稱 。這由 圖 13 中的名稱驗證規則進行檢測，並將結果寫入 Warnings 屬性字段。
圖 14. 警告消息
為了進一步突出顯示此問題，Rule Explorer 視圖中會顯示一個警告符號，而且警告消息將會位於工具 提示中，如 圖 15 所示。
圖 15. Rule Explorer 中的警告標志
樣式規則的其他示例如下：
列名稱的命名標准
決策表最大行數限制
決策表單元值最大長度限制
決策表中數值的阈值
圖 16、圖 17、圖 18 和圖 19 中分別顯示了這些規則的示例。
圖 16. 檢查決策表是否包含無效 列名的樣式規則
圖 17. 檢查決策表是否包含太多行 的樣式規則
圖 18. 檢查決策表單元值是否超過 16 個字符的樣式規則
圖 19. 檢查更改是否在阈值限制之 外的樣式規則
提交的規則
提交的規則在 onCommit 事件上調用，用於確定是否應該設置通知。通知可以是電子郵件、SMS 或對數據庫進行的寫入操作 。圖 20 顯示了一個從 New 到 Defined 的狀態轉換，用於觸發一封電子郵件。觸發規則如圖 21 所示。
圖 20. 電子郵件通知
圖 21. 電子郵件通知規則
IBM ODM 規則治理資產
本文中所述的所有功能以及更多功能都是在 IBM 規則治理資產中實現的。 該資產為高級治理實現提供了一個可自定義的治理解決方案。有關詳細信息以及如何獲得該資產，請與作者聯 系。
結束語
本文介紹了一個基於規則的規則治理設計模式，該模式使用業務規則（而不是 Java）來提高決策服務器治理實現的靈活性和能效。
