6.13 規則 (Rule)、規則 (Policy) 與樣式表
Identity Manager 中的規則 (rule) 是指規則 (policy) 的集合。每個規則 (Rule) 都包含必須符合的條件，以及在條件符合時要執行動作。條件的文法應可供人認讀，而且一般要合理。例如，當目前文件中描述的物件為使用者物件時，「if object class equal user」條件會為 True，而當此物件為群組時，此條件會為 False。條件群組由條件組成。在條件群組中，所有條件可透過 And 與 Or 進行組合，僅當組合條件的結果為 True 時，條件群組才會評估為 True，否則，條件群組會評估為 False。多個條件群組也可以使用 And 與 Or 進行組合。一旦條件群組評估為 True，便會執行規則定義的動作。
圖 6-2 規則產生器條件
動作可能是針對目前文件的，而且在 大多數情況下，只需針對此文件進行操作。不過，動作也可以查詢來源或目的地以獲取其他資訊，該來源或目的可能是 Identity Vault，也可能是已連接系統，取決於您所在的通道。動作可以將目前文件變為其修改後的版本，也可以完全封鎖它。使用動作可以建立不同的文件。描述已連接系統中之刪除事件的文件可由條件 (if operation equal delete) 進行測試並由動作集予以執行，使其在 Identity Vault 中的關聯物件不會被刪除 (否決)，而是被修改 (即從中移除此應用程式的關聯值 (remove-association)) 並停用 (將目的地屬性值 Login Disabled 設定為 True)。
圖 6-3 規則產生器動作
規則定義要傳輸的資料以及在已連接系統與 Identity Vault 之間同步資料的方式。驅動程式組態中包含一組預設規則。其他規則可能是驅動程式的本地自定。您可以使用 DirXML 程序檔、XSLT 或 ECMA 程序檔來編寫規則。
規則的用途在於對輸入文件進行變更並產生輸出文件。大多數規則要麼是在訂閱者通道中，要麼是在發行者通道中進行評估。綱要對應規則、輸入轉換規則以及輸出轉換規則在這兩個通道中都會進行評估。例如，一個組織可能會使用 inetOrgPerson 做為主要使用者類別，而另一個組織可能會使用「使用者」。對於第一個組織，可以實作規則以向 inetOrgPerson 新增電話號碼變更；對於「使用者」類別，可以實作並套用另一個規則。規則會進行網要轉換，指定比對準則以確定已連接系統或 Identity Vault 中是否已存在某個物件，以及許多其他操作。因此，如果相符規則確定 Identity Vault 中已存在您新增的物件，則已連接系統報告的新增事件在 Identity Vault 中可能會以修改操作結束。
在訂閱通道中，如果 Identity Vault 中建立了一個新使用者，而您想將此使用者建立在已連接系統中，則在向驅動程式傳送此指令之前，Identity Manager 引擎會呼叫一系列規則。這些規則會定義物件的建立方法，確定已連接系統中是否已存在對應的使用者，做出有關佈置的決策，向未指定具體值的必要屬性提供預設值，以及執行其他操作。若已連接系統中存在該物件，此新增事件可能會轉換為修改事件。系統可能會新增原始事件中未包含的屬性，以與已連接系統的物件建立模型相符。
樣式表定義 XSLT 轉換規則。樣式表會將輸入或輸出指令轉換為其他指令，變更事件的類型，或執行其他任意 XML 轉換。如需詳細資訊，請參閱 Identity Manager 樣式表。
6.13.1 輸入轉換規則
輸入轉換規則既適用於訂閱者通道，也適用於發行者通道。輸入轉換規則用於對已連接系統送往以及傳回 Identity Manager 的所有 XML 文件執行初步轉換。已連接系統呼叫時，輸入轉換規則會套用於傳送至 XmlCommandProcessor.execute 與 XmlQueryProcessor.query 的 XML 文件；而 Identity Manager 引擎呼叫時，輸入轉換規則會套用於從 SubscriptionShim.execute 與 XmlQueryProcessor.query 傳回的 XML 文件。輸入轉換規則排在網要對應規則前面套用。
輸入轉換規則常用於將資料從應用程式格式轉換為 Identity Vault 格式。當使用輸入轉換來進行資料格式轉換時，輸出轉換規則通常會執行反向資料轉換，即將資料從 Identity Vault 格式轉換為應用程式格式。此規則在應用程式的名稱空間中進行操作。它可能會用來重新格式化資料，例如，將格式為 1(815)555-1212 的電話號碼格式化為 1-815-555-1212。此外，輸入轉換規則還可用於執行一些動作，以回應傳送至 Shim 之指令的結果。輸入轉換規則所處理的 XML 中，綱要名稱始終存放於應用程式名稱空間中。也可以使用輸入轉換規則將已連接應用程式的任意原始 XML 格式轉換為 Identity Manager 所希望的格式。此類轉換必須以 XSLT 編寫，因為 DirXML 程序檔只對 Identity Manager 專用的 XML 詞彙表有效。
6.13.2 輸出轉換規則
輸出轉換規則既適用於訂閱者通道，也適用於發行者通道。該規則用於對 Identity Manager 引擎送往以及傳回 Shim 的所有 XML 文件執行最終轉換。Identity Manager 引擎呼叫時，輸出轉換規則會套用於傳送至 SubscriptionShim.execute 與 XmlQueryProcessor.query 的 XML 文件；而 Shim 呼叫時，輸出轉換規則會套用於從 XmlCommandProcessor.execute 與 XmlQueryProcessor.query 傳回的 XML 文件。輸出轉換規則排在網要對應規則後面套用。
輸出轉換規則與輸入轉換規則相反。該規則會視需要對要提交至 Shim 的指令予以修改，通常就是復原輸入轉換規則所進行的操作。例如，如果輸入轉換規則將格式為 1(815)555-1212 的電話號碼格式化為 1-815-555-1212，您需要有一個輸出轉換規則以將 1-815-555-1212 轉換為 1(815)555-1212。
您也可以使用輸出轉換規則將 Identity Manager 使用的格式轉換為已連接應用程式的任意原始 XML 格式。這些轉換必須以 XSLT 編寫，因為 DirXML 程序檔只對 Identity Manager 專用的 XML 詞彙表有效。
6.13.3 關聯
關聯值是 Identity Manager 用於追蹤已連接系統中的哪些物件與 Identity Vault 中的物件相符的方法。基本上所有情況下物件都應當是一一對應的，以使 HR 系統中員工編號為 1234567 的「john doe」與 Identity Vault 中的使用者物件「jdoe13」、Active Directory 中的「doe john」，以及電子郵件系統中的「jdoe13@example.com」完全相符。大多數電腦系統都有其內部的唯一識別碼。eDirectory 與 Active Directory 有一個全域唯一識別碼或 GUID。許多 HR 系統都包含員工編號。在電子郵件系統中，通常每個人都有一個唯一的電子郵件地址值。Identity Manager 使用這些識別碼來建立其關聯。關聯儲存在 Identity Vault 中。在訂閱者通道中，Identity Manager 引擎可借助此值讓 Shim 能夠修改已連接系統中的正確物件。在發行者通道中，Shim 會提供該關聯值，讓 Identity Manager 引擎能夠在 Identity Vault 中輕鬆快速地找到正確物件。
6.13.4 綜合新增
當修改操作到達新增處理器時，如果該操作未包含可解析到實際物件的關聯，Identity Manager 引擎會將修改事件轉換為綜合新增程序。這就是綜合新增程序，無論是發行者通道還是訂閱者通道，都可能會發生。Identity Manager 引擎利用修改事件確定要處理的物件。然後使用過濾器進行反向查詢，以取得適用於該物件並且已在目前通道中設定為「同步化」或「通知」的所有屬性。之後，引擎會丟棄修改事件並建立新增事件以取代它。此新增事件會接著轉遞，依次通過相符、建立、佈置和指令轉換 (在訂閱者通道中，還需通過綱要對應和輸出轉換)。綜合新增操作不會觸發事件轉換規則。這是因為該規則排在新增處理器的前面。
圖 6-4 訂閱者通道關聯處理器
6.13.5 合併處理
當 Identity Manager 引擎將新增操作轉換為修改操作時，會執行合併操作。此操作通常發生在啟始移轉過程中，當移轉程序沿著通道傳送物件時，相符規則會找到一個可用於關聯要移轉之物件的物件。
執行合併操作的過程中會丟棄目前文件 (類似於綜合新增操作)，並會使用過濾器向已連接系統和 Identity Vault 查詢所有值。系統會使用過濾器中每個屬性的設定來決定要對資料執行的操作。選項包括以目的資訊覆寫來源資訊、以來源資訊覆寫目的資訊、結合兩項資訊並在兩邊更新結果，或者不做任何操作。下面的流程圖說明發行者合併處理器與訂閱者合併處理器
圖 6-5 發行者合併處理器
圖 6-6 訂閱者合併處理器
