ポリシーとフィルターについて

ポリシーを使用すると、高いレベルで、DirXMLが更新を送受信する方法をカスタマイズできます。

ポリシーを理解するには、ドライバシムが何を実行するように作成されているかについてある程度詳しく知っておくと役に立ちます。

ドライバシムを作成する場合、ドライバを展開する企業で使用される可能性があるすべての情報を同期化する機能を含めようとします。開発者は、接続システム内での関連する変更をすべて検出して、この変更をNovell^(R) eDirectory^TMに渡すようにドライバシムを作成します。

この変更はXML文書に格納され、DirXMLの仕様に従ってフォーマットされます。次の抜粋には、これらのXML文書の1つが含まれています。

<nds dtdversion="2.0" ndsversion="8.7.3"> 
<source> 
   <product version="2.0">DirXML</product> 
   <contact>Novell, Inc.</contact> 
</source> 
 
<input> 
   <add class-name="User" event-id="0" src-dn="\ACME\Sales\Smith" 
   src-entry-id="33071"> 
      <add-attr attr-name="Surname"> 
         <value timestamp="1040071990#3" type="string">Smith</value> 
      </add-attr> 
      <add-attr attr-name="Telephone Number"> 
         <value timestamp="1040072034#1" type="teleNumber">111-1111</value> 
      </add-attr> 
   </add> 
</input> 
</nds>

目的によっては、Smithというユーザが電話番号111-1111と一緒にシステムに追加されても問題ないかもしれませんが、一部のユーザにとっては問題になる場合があります。

ここで重要なのは、ドライバは関連する変更をすべて報告し、ユーザが必要な変更かを判断してフィルタ処理または変更できるように設計されている点です。どの変更が重要かを判断し、これらの変更を処理する方法のロジックは、ドライバシムでなくエンジンで処理されます。

会社がユーザにそれほど関心がなければ、フィルタを実装して、eDirectoryまたは接続システムのユーザに関する操作をすべてブロックできます。ユーザが会社にとって重要であれば、フィルタを実装して逆の処理を実行できます。

ドライバをカスタマイズする際には、まず、重要でないオブジェクトを同期化しないようにフィルタを定義します。

次に、フィルタでブロックされなかったオブジェクトに対してDirXMLが行う処理を定義します。たとえば、前のXML文書にあったadd (追加)操作について考えてみましょう。Smithというユーザと電話番号111-1111が接続システムに追加されています。この操作をフィルタしない場合、DirXMLはこのユーザの処理を決定する必要があります。

この決定を行うために、DirXMLはポリシーセットを特定の順序で適用します(ここではTransformation Policy (変換ポリシー)については無視します。変換ポリシーは、フィルタが発行者チャネル上で適用される前に実行され、加入者チャネル上の最後のステップです)。

「このオブジェクトがすでにデータストアにあるか」という疑問を解消するのは、最初のポリシーであるMatching Policy (一致ポリシー)です。これに答えるには、オブジェクトに固有の特性を定義する必要があります。確認すべき一般的な属性は電子メールアドレスです。電子メールアドレスは通常個人特有のものであるからです。したがって、「2つのオブジェクトが同じ電子メールアドレスを持っていれば、それらは同一のオブジェクトである」という内容のポリシーを定義します。

一致するオブジェクトが見つかると、DirXMLはこのオブジェクトを関連付けと呼ばれる属性に記録します。関連付けとは、DirXMLがオブジェクトを接続システムに関連付けられる固有の値です。

一致するオブジェクトが見つからなかった場合、次のポリシーである作成が呼び出されます。Create Policy (作成ポリシー)は、どのような条件の場合にオブジェクトを作成するかをDirXMLに指示します。作成ルールでは、一部の属性を必須属性にできます。必須属性が存在しない場合、DirXMLは、必要な情報が提供されるまでオブジェクトの作成をブロックします。

オブジェクトが生成されると、3番目のルールである配置が、オブジェクトを配置する場所をDirXMLに指示します。オブジェクトを元のシステムと同一の階層構造に作成するか、それとも属性値に基づいてまったく別の場所に配置するかを指定できます。

ユーザをオブジェクトの場所属性に従って階層に配置し、フルネームに従って名前を付ける場合、Create Policy (作成ポリシー)でこれらの属性を必須にすることができます。このような方法により、この属性が存在することを確認して、配置計画を正しく機能させることができます。

ポリシーを使用すると、さまざまな処理が可能です。Policy Builderを使えば、固有の値の生成、属性の追加と削除、イベントの生成、電子メールの送信など、多くの操作を簡単に実行できます。XSLTを使用してXML文書を直接変換すると、さらに高度な変換が可能です(変更はeDirectoryとの間でXML文書で送受信されます)。

基本は、ポリシーによってDirXMLの更新処理を制御できるということです。

ポリシーの概要でポリシーのさまざまな種類について学んでから、Policy Builderを使用したポリシーの定義でPolicy Builderの具体的な操作を習得してください。

Transformation Policy (変換ポリシー)について

Transformation Policy (変換ポリシー)はDirXMLと接続システムの間の変換メカニズムとして機能します。システム間でスキーマを変換し、受信した操作には初期変更を、送信する操作には最終変更を加えます。

基本的には、Transformation Policy (変換ポリシー)は前に説明した他のルール(matching(一致)、create(作成)、placement(配置))を正しく機能させるために使用されます。各ドライバのデフォルト設定には必要なTransformation Policy (変換ポリシー)がすべて含まれているので、最初は変換ポリシーについて考える必要はありません(唯一の例外はSchema Mapping Policy (スキーママッピングポリシー)で、iManagerのGUIを使用して簡単に変更できます)。

ポリシーの基本的な種類がわかったら、Transformation Policy (変換ポリシー)を理解すると、基本ポリシーでは不可能なカスタマイズを行うことができます。