購読者チャネルと発行者チャネルの両方で定義できるポリシーにはさまざまなタイプがあります。各ポリシーは、データ変換のさまざまな段階で適用されます。また、一部のポリシーは特定のアクションが発生した場合にのみ適用されます。たとえば、作成ポリシーは新しいオブジェクトが作成される場合にのみ適用されます。
さまざまなポリシータイプとチャネル上でのそれらの実行順序は次のとおりです。
図 3-2 ポリシーの実行順序
イベント変換ポリシーは、識別ボールトまたは接続アプリケーションで発生したイベントをメタディレクトリエンジンに表示する方法を変更します。イベント変換ポリシーで実行される最も一般的なタスクは、スコープフィルタリングやイベントタイプフィルタリングなどのカスタムフィルタリングです。
スコープフィルタリングは、イベントの位置または属性値に基づいて、不要なイベントを削除します。たとえば、部署属性が特定の値と一致しないか、特定のグループのメンバではない場合に、イベントを削除します。
イベントタイプフィルタリングは、イベントタイプに基づいて、不要なイベントを削除します。たとえば、すべての削除イベントを削除します。
例:
次のDirXMLスクリプトポリシーの例では、Usersサブツリー内に含まれ、無効になっておらず、役職属性に「Consultant」または「Manager」という語が含まれていないユーザに対するイベントだけを許可します。操作がブロックされていることを示すステータスドキュメントも生成します。このポリシーをXMLで表示するには、Event_Transformation_Scope1.xmlを参照してください。
<policy> <rule> <description>Scope Filtering</description> <conditions> <or> <if-class-name op="equal">User</if-class-name> </or> <or> <if-src-dn op="not-in-subtree">Users</if-src-dn> <if-attr name="Login Disabled" op="equal">True</if-attr> <if-attr mode="regex" name="Title" op="equal">.*Consultant.*</if-attr> <if-attr mode="regex" name="Title" op="equal">.*Manager.*</if-attr> </or> </conditions> <actions> <do-status level="error"> <arg-string> <token-text>User doesn’t meet required conditions</token-text> </arg-string> </do-status> <do-veto/> </actions> </rule> </policy>
次のDirXMLスクリプトポリシーは、ユーザオブジェクトに対する変更操作を拒否します。ただし、すでに関連付けられているオブジェクトの変更を除きます。このポリシーをXMLで表示するには、Event_Transformation_Scope2.xmlを参照してください。
<policy> <rule> <description>Veto all operation on User except modifies of already associated objects</description> <conditions> <or> <if-class-name op="equal">User</if-class-name> </or> <or> <if-operation op="not-equal">modify</if-operation> <if-association op="not-associated"/> </or> </conditions> <actions> <do-veto/> </actions> </rule> </policy>
次のDirXMLスクリプトポリシーの例では、最初のルールで、EmployeeおよびContractorコンテナ内のオブジェクトの同期だけを許可します。2つ目のルールでは、すべての名前変更操作および移動操作をブロックします。このポリシーをXMLで表示するには、Event_Transformation_Type1.xmlを参照してください。
<policy> <rule> <description>Only synchronize the Employee and Contractor subtrees</description> <conditions> <and> <if-src-dn op="not-in-container">Employees</if-src-dn> <if-src-dn op="not-in-container">Contractors</if-src-dn> </and> </conditions> <actions> <do-status level="warning"> <arg-string> <token-text>Change ignored: Out of scope.</token-text> </arg-string> </do-status> <do-veto/> </actions> </rule> <rule> <description>Don’t synchronize moves or renames</description> <conditions> <or> <if-operation op="equal">move</if-operation> <if-operation op="equal">rename</if-operation> </or> </conditions> <actions> <do-status level="warning"> <arg-string> <token-text>Change ignored: We don’t like you to do that.</token-text> </arg-string> </do-status> <do-veto/> </actions> </rule> </policy>
次のDirXMLスクリプトポリシーは、すべての追加イベントをブロックします。このポリシーをXMLで表示するには、Event_Transformation_Type2.xmlを参照してください。
<policy> <rule> <description>Type Filtering</description> <conditions> <and> <if-operation op="equal">add</if-operation> </and> </conditions> <actions> <do-status level="warning"> <arg-string> <token-text>Change ignored: Adds are not allowed.</token-text> </arg-string> </do-status> <do-veto/> </actions> </rule> </policy>
購読者一致および発行者一致などの一致ポリシーは、ソースデータストア内の関連付けられていないオブジェクトに対応するオブジェクトをターゲットデータストアで検索します。重要な点は、一致ポリシーが常に必要または望ましいとは限らないということです。
たとえば、既存のオブジェクトや対応するオブジェクトが存在する場合に初めて移行を実行するときは、一致ポリシーは望ましくない可能性があります。
一致ポリシーは、誤った一致が検出されないように十分に注意して作成する必要があります。
次のDirXMLスクリプトポリシーの例は、インターネット電子メールアドレスに基づいてユーザを照合します。このポリシーをXMLで表示するには、Matching1.xmlを参照してください。
<policy> <rule> <description>Match Users based on email address</description> <conditions> <and> <if-class-name op="equal">User</if-class-name> </and> </conditions> <actions> <do-find-matching-object> <arg-dn> <token-text>ou=people,o=novell</token-text> </arg-dn> <arg-match-attr name="Internet EMail Address"/> </do-find-matching-object> </actions> </rule> </policy>
次のDirXMLスクリプトポリシーの例では、その共通名属性に基づいて、グループオブジェクトを照合します。このポリシーをXMLで表示するには、Matching2.xmlを参照してください。
<?xml version="1.0" encoding="UTF-8"?> <policy> <rule> <description>Match Group by Common Name</description> <conditions> <or> <if-class-name op="equal">Group</if-class-name> </or> </conditions> <actions> <do-find-matching-object scope="subtree"> <arg-match-attr name="CN"/> </do-find-matching-object> </actions> </rule> </policy>
購読者作成ポリシーおよび発行者作成ポリシーなどの作成ポリシーは、新しいオブジェクトを作成するときに満たす必要がある条件を定義します。作成ポリシーがないことは、オブジェクトを作成できることを意味します。
たとえば、識別ボールトに新しいユーザを作成する一方で、新しいユーザオブジェクトには名前とIDだけを指定するとします。この作成はeDirectoryツリーでミラーリングされますが、追加は識別ボールトに接続されているアプリケーションでは直ちに反映されません。これは、より完全な定義が指定されたユーザオブジェクトだけを許可するように、作成ポリシーで指定されているためです。
作成ポリシーは、発行者と購読者の両方で同じにすることも別にすることもできます。
テンプレートオブジェクトを指定して、オブジェクトがeDirectoryで作成される場合に作成プロセスで使用することができます。
作成ポリシーは、通常、次の目的で使用されます。
属性がないなどの理由で条件を満たさないオブジェクトの作成を拒否する。
デフォルト属性値を設定する。
デフォルトパスワードを設定する。
例:
次に示すDirXMLスクリプトポリシー例の最初のルールでは、ユーザを作成するにはユーザオブジェクトにCN、名前、名字、インターネット電子メールアドレスの各属性があらかじめ含まれている必要があります。2つ目のルールでは、すべての部門オブジェクトでOU属性が必要になります。最後のルールでは、名前が「Fred」であるすべてのユーザオブジェクトが拒否されます。このポリシーをXMLで表示するには、Create1.xmlを参照してください。
<policy> <rule> <description>Veto if required attributes CN, Given Name, Surname and Internet EMail Address not available</description> <conditions> <or> <if-class-name op="equal">User</if-class-name> </or> </conditions> <actions> <do-veto-if-op-attr-not-available name="CN"/> <do-veto-if-op-attr-not-available name="Given Name"/> <do-veto-if-op-attr-not-available name="Surname"/> <do-veto-if-op-attr-not-available name="Internet EMail Address"/> </actions> </rule> <rule> <description>Organizational Unit Required Attributes</description> <conditions> <or> <if-class-name op="equal">Organizational Unit</if-class-name> </or> </conditions> <actions> <do-veto-if-op-attr-not-available name="OU"/> </actions> </rule> <rule> <description>Conditionally veto guys named "Fred"</description> <conditions> <and> <if-global-variable name="no-fred" op="equal">true</if-global-variable> <if-op-attr name="Given Name" op="equal">Fred</if-op-attr> </and> </conditions> <actions> <do-status level="warning"> <arg-string> <token-text xml:space="preserve" xmlns:xml="http://www.w3.org/XML/1998/namespace">Vetoed "Fred"</token-text> </arg-string> </do-status> <do-veto/> </actions> </rule> </policy>
次のDirXMLスクリプトポリシーの例では、ユーザの説明属性のデフォルト値を追加します。このポリシーをXMLで表示するには、Create2.xmlを参照してください。
<policy> <rule> <description>Default Description of New Employee</description> <conditions> <or> <if-class-name op="equal">User</if-class-name> </or> </conditions> <actions> <do-set-default-attr-value name="Description"> <arg-value type="string"> <token-text>New Employee</token-text> </arg-value> </do-set-default-attr-value> </actions> </rule> </policy>
次のDirXMLスクリプトポリシーの例では、名前の最初の2文字と名字の最初の6文字(すべて小文字)で構成したパスワード値を作成します。このポリシーをXMLで表示するには、Create3.xmlを参照してください。
<policy> <rule> <description>Default Password of [2]FN+[6]LN</description> <conditions> <and> <if-class-name op="equal">User</if-class-name> <if-password op="not-available"/> </and> </conditions> <actions> <do-set-dest-password> <arg-string> <token-lower-case> <token-substring length="2"> <token-op-attr name="Given Name"/> </token-substring> <token-substring length="6"> <token-op-attr name="Surname"/> </token-substring> </token-lower-case> </arg-string> </do-set-dest-password> </actions> </rule> </policy>
次のDirXMLスクリプトポリシーの例では、ユーザの役職属性で、そのユーザがマネージャであることが示されている(「Manager」を含んでいる)場合のテンプレートオブジェクトを指定します。このポリシーをXMLで表示するには、Create4.xmlを参照してください。
<policy> <rule> <description>Assign Manager Template if Title contains Manager</description> <conditions> <and> <if-class-name op="equal">User</if-class-name> <if-op-attr name="Title" op="available"/> <if-op-attr mode="regex" name="Title" op="equal">.*Manager.*</if-op-attr> </and> </conditions> <actions> <do-set-op-template-dn> <arg-dn> <token-text>Users\Manager Template</token-text> </arg-dn> </do-set-op-template-dn> </actions> </rule> </policy>
配置ポリシーは、新しいオブジェクトを配置する場所と、識別ボールトおよび接続されたアプリケーションでのオブジェクトの名前を決定します。
配置ポリシーは識別ボールトでオブジェクト作成を行う場合に、発行者チャネルにおいて必要です。配置ポリシーは、購読者チャネルでは必須でない場合もあります。これはターゲットデータストアの特性に応じて、接続されたアプリケーションでオブジェクトの作成を行う場合も同じですたとえば、リレーショナルデータベースへの同期では、リレーショナルデータベースの行には位置も名前もないので配置ポリシーは不要です。
次のDirXMLスクリプトポリシーの例では、部署属性の値に基づいて、特定のコンテナにユーザを作成します。このポリシーをXMLで表示するには、Placement1.xmlを参照してください。
<policy> <rule> <description>Department Engineering</description> <conditions> <and> <if-class-name op="equal">User</if-class-name> <if-op-attr mode="regex" name="Department" op="equal">.*Engineering.*</if-op-attr> </and> </conditions> <actions> <do-set-op-dest-dn> <arg-dn> <token-text>Eng</token-text> <token-text>\</token-text> <token-op-attr name="CN"/> </arg-dn> </do-set-op-dest-dn> </actions> </rule> <rule> <description>Department HR</description> <conditions> <and> <if-class-name op="equal">User</if-class-name> <if-op-attr mode="regex" name="Department" op="equal">.*HR.*</if-op-attr> </and> </conditions> <actions> <do-set-op-dest-dn> <arg-dn> <token-text>HR</token-text> <token-text>\</token-text> <token-op-attr name="CN"/> </arg-dn> </do-set-op-dest-dn> </actions> </rule> </policy>
次のDirXMLスクリプトポリシーでは、入力ドキュメントのsrc-dnによって、ユーザまたは部門の配置を決定します。このポリシーをXMLで表示するには、Placement2.xmlを参照してください。
<policy> <rule> <description>PublisherPlacementRule</description> <conditions> <or> <if-class-name op="equal">User</if-class-name> <if-class-name op="equal">Organizational Unit</if-class-name> </or> <or> <if-src-dn op="in-subtree">o=people, o=novell</if-src-dn> </or> </conditions> <actions> <do-set-op-dest-dn> <arg-dn> <token-text>People</token-text> <token-text>\</token-text> <token-unmatched-src-dn convert="true"/> </arg-dn> </do-set-op-dest-dn> </actions> </rule> </policy>
次のDirXMLスクリプトポリシーの例では、ユーザの名字の最初の文字に基づいて、特定のコンテナにユーザを配置します。名字がA~Iで始まるユーザはUsers1コンテナ、J~RのユーザはUsers2コンテナ、S~ZはUsers3コンテナに配置されます。このポリシーをXMLで表示するには、Placement3.xmlを参照してください。
<policy> <rule> <description>Surname - A to I in Users1</description> <conditions> <and> <if-class-name op="equal">User</if-class-name> <if-op-attr mode="regex" name="Surname" op="equal">[A-I].*</if-op-attr> </and> </conditions> <actions> <do-set-op-dest-dn> <arg-dn> <token-text>Users1</token-text> <token-text>\</token-text> <token-op-attr name="CN"/> </arg-dn> </do-set-op-dest-dn> </actions> </rule> <rule> <description>Surname - J to R in Users2</description> <conditions> <and> <if-class-name op="equal">User</if-class-name> <if-op-attr mode="regex" name="Surname" op="equal">[J-R].*</if-op-attr> </and> </conditions> <actions> <do-set-op-dest-dn> <arg-dn> <token-text>Users2</token-text> <token-text>\</token-text> <token-op-attr name="CN"/> </arg-dn> </do-set-op-dest-dn> </actions> </rule> <rule> <description>Surname - S to Z in Users3</description> <conditions> <and> <if-class-name op="equal">User</if-class-name> <if-op-attr mode="regex" name="Surname" op="equal">[S-Z].*</if-op-attr> </and> </conditions> <actions> <do-set-op-dest-dn> <arg-dn> <token-text>Users3</token-text> <token-text>\</token-text> <token-op-attr name="CN"/> </arg-dn> </do-set-op-dest-dn> </actions> </rule> </policy>
コマンド変換ポリシーは、コマンドを置き換えるか追加することによって、Identity Managerがターゲットデータストアに送信するコマンドを変更します。削除コマンドを行わずに、それを変更、移動、または無効化コマンドに置き換えるのは、コマンド変換ポリシーのコマンド置き換えの例です。コマンド変換ポリシーでのコマンドの追加の一般的な例として、追加コマンドの属性値に基づいた変更コマンドの作成があります。
基本的には、コマンド変換ポリシーは、メタディレクトリエンジンに送信されたイベントのデフォルト処理の結果としてIdentity Managerが実行するコマンドを変更するために使用されます。
また、他のポリシーの説明に合致しないポリシーをここで含めるのも一般的な使用法です。
次のDirXMLスクリプトポリシーでは、「ログインの無効化」属性の削除操作を変更操作に変換します。このポリシーをXMLで表示するには、Comannd1.xmlを参照してください。
<policy> <rule> <description>Convert User Delete to Modify</description> <conditions> <and> <if-operation op="equal">delete</if-operation> <if-class-name op="equal">User</if-class-name> </and> </conditions> <actions> <do-set-dest-attr-value name="Login Disabled"> <arg-value type="state"> <token-text>true</token-text> </arg-value> </do-set-dest-attr-value> <do-veto/> </actions> </rule> </policy>
次のDirXMLスクリプトポリシーでは、ユーザのターゲットコンテナがすでに存在するかどうかを判断します。コンテナがない場合、このポリシーは、コンテナオブジェクトを作成する追加操作を作成します。このポリシーをXMLで表示するには、Command2.xmlを参照してください。
<policy> <rule> <description>Check if destination container already exists</description> <conditions> <and> <if-operation op="equal">add</if-operation> </and> </conditions> <actions> <do-set-local-variable name="target-container"> <arg-string> <token-dest-dn length="-2"/> </arg-string> </do-set-local-variable> <do-set-local-variable name="does-target-exist"> <arg-string> <token-dest-attr class-name="OrganizationalUnit" name="objectclass"> <arg-dn> <token-local-variable name="target-container"/> </arg-dn> </token-dest-attr> </arg-string> </do-set-local-variable> </actions> </rule> <rule> <description>Create the target container if necessary</description> <conditions> <and> <if-local-variable name="does-target-exist" op="available"/> <if-local-variable name="does-target-exist" op="equal"/> </and> </conditions> <actions> <do-add-dest-object class-name="organizationalUnit" direct="true"> <arg-dn> <token-local-variable name="target-container"/> </arg-dn> </do-add-dest-object> <do-add-dest-attr-value direct="true" name="ou"> <arg-dn> <token-local-variable name="target-container"/> </arg-dn> <arg-value type="string"> <token-parse-dn dest-dn-format="dot" length="1" src-dn-format="dest-dn" start="-1"> <token-local-variable name="target-container"/> </token-parse-dn> </arg-value> </do-add-dest-attr-value> </actions> </rule> </policy>
次のDirXMLスクリプトポリシーでは、eDirectoryユーザの「パスワード期限の時刻」属性を変更します。このポリシーをXMLで表示するには、Command3.xmlを参照してください。
<?xml version="1.0" encoding="UTF-8"?> <policy xmlns:jsystem="http://www.novell.com/nxsl/java/java.lang.System"> <rule> <description>Set password expiration time for a given interval from current day</description> <conditions> <and> <if-operation op="equal">modify-password</if-operation> </and> </conditions> <actions> <do-set-local-variable name="interval"> <arg-string> <token-text>30</token-text> </arg-string> </do-set-local-variable> <do-set-dest-attr-value class-name="User" name="Password Expiration Time" when="after"> <arg-association> <token-association/> </arg-association> <arg-value type="string"> <token-xpath expression="round(jsystem:currentTimeMillis() div 1000 + (86400*$interval))"/> </arg-value> </do-set-dest-attr-value> </actions> </rule> </policy>
スキーママッピングポリシーは、識別ボールトと接続システム間のスキーママッピングの定義を保持します。
識別ボールトスキーマは、eDirectoryから読み込まれます。接続されているアプリケーションのスキーマは、接続システムのIdentity Managerドライバから提供されます。2つのスキーマが特定された後、識別ボールトとターゲットアプリケーション間で単純なマッピングが作成されます。
スキーママッピングポリシーをIdentity Managerドライバ環境設定に定義した後は、対応するデータをマップできます。
次の点に十分注意してください。
同じポリシーが両方向で適用されます。
メタディレクトリエンジンとアプリケーションシム間で渡されるドキュメントは、いずれのチャネルでも、またいずれの方向でも、すべてのドキュメントがスキーママッピングポリシーを通過します。
管理の詳細については、『Designer 2.1のポリシー』の「スキーママッピングポリシーの定義
」、または『iManager for Identity Manager 3.5.1のポリシー』の「スキーママッピングポリシーの定義
」を参照してください。
次のDirXMLスクリプトポリシーの例では、基本的なスキーママッピングポリシーのXMLソースをそのまま表示しています。ただし、Identity ManagerのDesignerを使用してポリシーを編集する場合、デフォルトのスキーママッピングエディタで、ポリシーをグラフィカルに表示および編集できます。このポリシーをXMLで表示するには、SchemaMap1.xmlを参照してください。
<?xml version="1.0" encoding="UTF-8"?><attr-name-map> <class-name> <app-name>WorkOrder</app-name> <nds-name>DirXML-nwoWorkOrder</nds-name> </class-name> <class-name> <app-name>PbxSite</app-name> <nds-name>DirXML-pbxSite</nds-name> </class-name> <attr-name class-name="DirXML-pbxSite"> <app-name>PBXName</app-name> <nds-name>DirXML-pbxName</nds-name> </attr-name> <attr-name class-name="DirXML-pbxSite"> <app-name>TelephoneNumber</app-name> <nds-name>Telephone Number</nds-name> </attr-name> <attr-name class-name="DirXML-pbxSite"> <app-name>LoginName</app-name> <nds-name>DirXML-pbxLoginName</nds-name> </attr-name> <attr-name class-name="DirXML-pbxSite"> <app-name>Password</app-name> <nds-name>DirXML-pbxPassword</nds-name> </attr-name> <attr-name class-name="DirXML-pbxSite"> <app-name>Nodes</app-name> <nds-name>DirXML-pbxNodesNew</nds-name> </attr-name> </attr-name-map>
次のDirXMLスクリプトポリシーの例は、DirXMLスクリプトを使用してカスタムスキーママッピングを実行します。このポリシーをXMLで表示するには、SchemaMap2.xmlを参照してください。
<?xml version="1.0" encoding="UTF-8"?><policy> <rule> <!-- The Schema Mapping Policy can only handle one-to-one mappings. That Mapping Policy maps StudentPersonal addresses. This rule maps StaffPersonal addresses. --> <description>Publisher Staff Address Mappings</description> <conditions> <and> <if-local-variable name="fromNds" op="equal">false</if-local-variable> <if-xpath op="true">@original-class-name = ’StaffPersonal’</if-xpath> </and> </conditions> <actions> <do-rename-op-attr dest-name="SA" src-name="Address/Street/Line1"/> <do-rename-op-attr dest-name="Postal Office Box" src-name="Address/Street/Line2"/> <do-rename-op-attr dest-name="Physical Delivery Office Name" src-name="Address/City"/> <do-rename-op-attr dest-name="S" src-name="Address/StatePr"/> <do-rename-op-attr dest-name="Postal Code" src-name="Address/PostalCode"/> </actions> </rule> <rule> <description>Subscriber Staff Address Mappings</description> <!-- The Schema Mapping Policy has already mapped addresses to StudentPersonal. This rule maps StudentPersonal to StaffPersonal. --> <conditions> <and> <if-local-variable name="fromNds" op="equal">true</if-local-variable> <if-op-attr name="DirXML-sifIsStaff" op="equal">true</if-op-attr> </and> </conditions> <actions> <do-rename-op-attr dest-name="Address/Street/Line1" src-name="StudentAddress/Address/Street/Line1"/> <do-rename-op-attr dest-name="Address/Street/Line2" src-name="StudentAddress/Address/Street/Line2"/> <do-rename-op-attr dest-name="Address/City" src-name="StudentAddress/Address/City"/> <do-rename-op-attr dest-name="Address/StatePr" src-name="StudentAddress/Address/StatePr"/> <do-rename-op-attr dest-name="Address/PostalCode" src-name="StudentAddress/Address/PostalCode"/> </actions> </rule> </policy>
出力変換ポリシーは主に、メタディレクトリエンジンが提供するデータからアプリケーションシムで求められるデータへのデータ形式の変換を行います。次に変換の例を示します。
属性値の形式の変換
XMLボキャブラリの変換
メタディレクトリエンジンからアプリケーションシムに返されるステータスメッセージのカスタム処理
いずれかのチャネルでメタディレクトリエンジンがアプリケーションシムに提供するドキュメントはすべて出力変換ポリシーを通過します。出力変換はスキーママッピングの後に実行されるので、すべてのスキーマ名はアプリケーションネームスペース内にあります。
次のDirXMLスクリプトポリシーの例は、電話番号を「(nnn) nnn-nnnn」形式から「nnn.nnn.nnnn」形式に再フォーマットします。逆の変換については、入力変換ポリシーの例を参照してください。このポリシーをXMで表示するには、Output_Transformation1.xmlを参照してください。
<policy> <rule> <description>Reformat all telephone numbers from (nnn) nnn-nnnn to nnn.nnn.nnnn</description> <conditions/> <actions> <do-reformat-op-attr name="telephoneNumber"> <arg-value type="string"> <token-replace-first regex="^\((\d\d\d)\) *(\d\d\d)-(\d\d\d\d)$" replace-with="$1.$2.$3"> <token-local-variable name="current-value"/> </token-replace-first> </arg-value> </do-reformat-op-attr> </actions> </rule> </policy>
次のDirXMLスクリプトポリシーの例では、レベルが「success」と等しくなく、また操作データ内に子のpassword-publish-status要素を含むステータスドキュメントを検出し、DoSendEmailFromTemplate (テンプレートから電子メールを送信)アクションを使用して電子メールを生成します。このポリシーをXMLで表示するには、Output_Transformation2.xmlを参照してください。
<?xml version="1.0" encoding="UTF-8"?> <policy> <description>Email notifications for failed password publications</description> <rule> <description>Send e-mail for a failed publish password operation</description> <conditions> <and> <if-global-variable mode="nocase" name="notify-user-on-password-dist-failure" op="equal">true</if-global-variable> <if-operation op="equal">status</if-operation> <if-xpath op="true">self::status[@level != ’success’]/operation-data/password-publish-status</if-xpath> </and> </conditions> <actions> <!-- generate email notification --> <do-send-email-from-template notification-dn="\cn=security\cn=Default Notification Collection" template-dn="\cn=security\cn=Default Notification Collection\cn=Password Sync Fail"> <arg-string name="UserFullName"> <token-src-attr name="Full Name"> <arg-association> <token-xpath expression="self::status/operation-data/password-publish-status/association"/> </arg-association> </token-src-attr> </arg-string> <arg-string name="UserGivenName"> <token-src-attr name="Given Name"> <arg-association> <token-xpath expression="self::status/operation-data/password-publish-status/association"/> </arg-association> </token-src-attr> </arg-string> <arg-string name="UserLastName"> <token-src-attr name="Surname"> <arg-association> <token-xpath expression="self::status/operation-data/password-publish-status/association"/> </arg-association> </token-src-attr> </arg-string> <arg-string name="ConnectedSystemName"> <token-global-variable name="ConnectedSystemName"/> </arg-string> <arg-string name="to"> <token-src-attr name="Internet Email Address"> <arg-association> <token-xpath expression="self::status/operation-data/password-publish-status/association"/> </arg-association> </token-src-attr> </arg-string> <arg-string name="FailureReason"> <token-text/> <token-xpath expression="self::status/child::text()"/> </arg-string> </do-send-email-from-template> </actions> </rule> </policy>
入力変換ポリシーは主に、アプリケーションシムが提供するデータからメタディレクトリエンジンで求められるデータへのデータ形式の変換を行います。次に変換の例を示します。
属性値の形式の変換
XMLボキャブラリの変換
ドライバハートビート
アプリケーションシムからメタディレクトリエンジンに返されるステータスメッセージのカスタム処理
いずれかのチャネルでアプリケーションシムがメタディレクトリエンジンに提供するドキュメントはすべて入力変換ポリシーを通過します。
次のDirXMLスクリプトポリシーの例では、電話番号を「nnn.nnn.nnnn」形式から「(nnn) nnn-nnnn」形式に再フォーマットします。逆の変換については、セクション 3.4.7, 出力変換ポリシーの例を参照してください。このポリシーをXMLで表示するには、Input_Transformation1.xmlを参照してください。
<policy> <rule> <description>Reformat all telephone numbers from nnn.nnn.nnnn to (nnn) nnn-nnnn</description> <conditions/> <actions> <do-reformat-op-attr name="telephoneNumber"> <arg-value type="string"> <token-replace-first regex="^(\d\d\d)\.(\d\d\d)\.(\d\d\d\d)$" replace-with="($1) $2-$3"> <token-local-variable name="current-value"/> </token-replace-first> </arg-value> </do-reformat-op-attr> </actions> </rule> </policy>
次のDirXMLスクリプトポリシーでは、ステータスハートビートイベントを作成します。ドライバのハートビート機能は、各ハートビート間隔ごとに成功メッセージ(HEARTBEAT: $driver)を送信するために使用されます。メッセージは、Novell® Auditによって監視されます。Identity Managerドライバは、ハートビートをサポートしている必要があります。また、ハートビートがドライバ環境設定ページで有効になっている必要があります。このポリシーをXMLで表示するには、Input_Transformation2.xmlを参照してください。
<?xml version="1.0" encoding="UTF-8" ?> <policy> <rule> <description>Heartbeat Rule, v1.01, 040126, by Holger Dopp</description> <conditions> <and> <if-operation op="equal">status</if-operation> <if-xpath op="true">@type="heartbeat"</if-xpath> </and> </conditions> <actions> <do-set-xml-attr expression="." name="text1"> <arg-string> <token-global-variable name="dirxml.auto.driverdn" /> </arg-string> </do-set-xml-attr> <do-set-xml-attr expression="." name="text2"> <arg-string> <token-text>HEARTBEAT</token-text> </arg-string> </do-set-xml-attr> </actions> </rule> </policy>