ということで私は内容を一切聞いていないので聴講された方がどのような理解をされたのかわかりませんが、個人的に初めてILM"2"に触られる方（特にMIIS/ILM2007経験者）が最も理解しにくい概念がMPR（Management Policy Rules）とOSR（Outbound Synchronization Rules）だと思います。
MIISやILM2007のように単純にMetaVerseにあるエントリをConnector Space上にプロビジョニングコードでストレートに吐き出してあげれば、後はExportすれば実際の同期対象システムにIDができるという考え方は、とてもわかりやすいのですが実際のユーザ環境ではそのまま使うには機能が足りません。（入力データの取り込みについてはとりあえず何でも取り込んでしまってもIdMの中の話なので、キー属性さえちゃんとしていればそれほど問題になりません）
ここで、同期対象のシステムへプロビジョニングを行う際に考えられる最低限の要件を考えてみると、
・誰（何）を
・どのような条件で
・どこに
・どのように
同期／プロビジョニングするのか？というのが最低限ルールとして定義されている必要があると言えると思います。
ILM"2"ではこの要件をある程度コーディングせずに実装するための仕組みとして、
・MPR（Management Policy Rules）
・SET
・WorkFlow
・OSR（Outbound Synchronization Rules）
という概念を実装してきました。
上記の、誰を、どのような条件で、どこに、どのようにという要件をこれらの概念に当てはめると、下の表と様になります。このセット自体のことをMPRと呼びます。
| 要件 | 関連する概念 | 解説 |
| 誰（何）を | SET | ILM"2"内で定義するオブジェクトのグループ（セット）。スタティックにメンバを決めることもできますし、オブジェクトの属性をベースに動的にメンバを決めることもできます。 例）EmployeeType属性がContractorのユーザオブジェクトのセット |
| どのような条件で＋どこに | WorkFlow | 承認が必要な場合などを含め条件をWorkFlowで定義します。 特にOSRと紐付をするタイプのWorkFlowをActionWorkFlow（AW）といいます。 承認後、結果によって振る舞いを変える場合はAuthorization WorkflowとActionWorkflowを組み合わせることにより実現します。 |
| どのように | OSR | ISRと同様にAttributeFlowなどを設定し属性のマッピング等を行います。 |
ILM"2"では、ILMSDB上のエントリに対してこのMPRを適用し、各オブジェクトに対して適用されるOSRが決定されます。（これが各オブジェクトのExpected Rules List（ERL）属性となります）
その後、ILMSDB MAのConnector Spaceへのimport/synchronizationを行うと属性に入っているERLを見て関連するOSRが実行され、実際のプロビジョニング／同期が実行されます。（ERLにはOSRオブジェクトへの参照が入ります）
最近の他社の製品には普通に実装されている機能なのですが、MIIS/ILM2007ユーザにはちょっとわかりにくいかと思うので、MIIS/ILM2007との機能対比を最後に書いておきます。
| 要件 | MIIS/ILM2007 | ILM"2" |
| だれを同期するか | MetaVerseのRules ExtensionのProvision関数内に条件分（IF、SWITCHなど）で実装 | SETを利用 |
| 同期条件は何か | WorkFlowを利用 | |
| どこに同期するか | Action WorkflowにOSRを設定 | |
| どのように同期するか | 同期対象MAの設定（Rules Extension含む） | OSRを利用 |
ちなみに、ILM"2"でもMAやMetaVerseのRules Extensionは従来通り利用可能なので、合わせて実装することも可能です。（切り分けが難しくなりそうなので、お勧めはしませんが）
投稿
0 件のコメント:
コメントを投稿