IBM Tivoli Directory Integrator 5.2: スタートアップ …publib.boulder.ibm.com/tividd/td/IBMDI/SC32-1382-00/ja...まえがき本書では、IBM ®Tivoli Directory Integrator

IBM Tivoli Directory Integrator 5.2:スタートアップ・ガイド

SC88-9900-00

(英文原典：SC32-1382-00)

��

IBM Tivoli Directory Integrator 5.2:スタートアップ・ガイド

SC88-9900-00

(英文原典：SC32-1382-00)

��

お願い本書および本書で紹介する製品をご使用になる前に、 79ページの『付録 B. 特記事項』に記載されている情報をお読みください。

本書は、IBM Tivoli Directory Integrator バージョン 5 リリース 2、および新しい版で明記されていない限り、以降のすべてのリリースおよびモディフィケーションに適用されます。

本マニュアルに関するご意見やご感想は、次の URL からお送りください。今後の参考にさせていただきます。

http://www.ibm.com/jp/manuals/main/mail.html

なお、日本 IBM 発行のマニュアルはインターネット経由でもご購入いただけます。詳しくは

http://www.ibm.com/jp/manuals/ の「ご注文について」をご覧ください。

(URL は、変更になる場合があります)

お客様の環境によっては、資料中の円記号がバックスラッシュと表示されたり、バックスラッシュが円記号と表示されたりする場合があります。

　原　典： SC32–1382–00

IBM Tivoli Directory Integrator 5.2:

Getting Started Guide

　発　行：日本アイ・ビー・エム株式会社

　担　当：ナショナル・ランゲージ・サポート

第1刷 2004.2

この文書では、平成明朝体™W3、平成明朝体™W9、平成角ゴシック体™W3、平成角ゴシック体™W5、および平成角ゴシック体™W7を使用しています。この(書体*)は、（財）日本規格協会と使用契約を締結し使用しているものです。フォントとして無断複製することは禁止されています。

　　注* 平成明朝体™W3、平成明朝体™W9、平成角ゴシック体™W3、平成角ゴシック体™W5、平成角ゴシック体™W7

© Copyright International Business Machines Corporation 2002, 2003. All rights reserved.

© Copyright IBM Japan 2004

まえがき

本書では、IBM® Tivoli® Directory Integrator の管理に必要な情報について説明します。

本書の対象読者本書は、IBM Tivoli Directory Integrator の知識を身に付けたいシステム管理者、ユーザーおよびその他の方を対象としています。

資料IBM Tivoli Directory Integrator のライブラリーの説明を参照して、必要な資料を見つけてください。

IBM Tivoli Directory Integrator のライブラリーIBM Tivoli Directory Integrator のライブラリーには、以下の資料があります。

IBM Tivoli Directory Integrator 5.2: Readme

IBM Tivoli Directory Integrator 5.2 の最新情報を説明しています。

IBM Tivoli Directory Integrator 5.2: スタートアップ・ガイドIBM Tivoli Directory Integrator 5.2 の解説および概要です。

IBM Tivoli Directory Integrator 5.2: 管理者ガイドIBM Tivoli Directory Integrator のインストールに関するすべての情報について説明しています。IBM Tivoli Directory Integrator の旧バージョンからのマイグレーションに関する情報を説明しています。IBM Tivoli Directory

Integrator のロギング機能の構成に関する情報を説明しています。

IBM Tivoli Directory Integrator 5.2: ユーザーズ・ガイドIBM Tivoli Directory Integrator 5.2 ツールの使用に関する情報を説明しています。IBM Tivoli Directory Integrator ツール (ibmditk) を使用したソリューションの設計や、コマンド行 (ibmdisrv) からの既製ソリューションの実行について説明しています。また、インターフェース、概念、およびAssemblyLine/EventHandler の作成と管理の情報についても説明しています。対話の作成の例と IBM Tivoli Directory Integrator 5.2 のハンズオン学習を含んでいます。

IBM Tivoli Directory Integrator 5.2: リファレンス・ガイドIBM Tivoli Directory Integrator 5.2 AssemblyLine (コネクター、EventHandler、パーサー、プラグインなど) の個別コンポーネントに関する詳細情報を説明しています。

関連資料IBM Tivoli Directory Integrator に関連する情報は、以下の資料から入手できます。

v IBM Tivoli Directory Integrator 5.2 では、Sun Microsystems の JNDI クライアントを使用しています。JNDI クライアントに関する情報は、

© Copyright IBM Corp. 2002, 2003 iii

http://java.sun.com/products/jndi/1.2/javadoc/index.html の Sun Microsystems Web サイトにある Java™ Naming and Directory Interface™ 1.2.1 Specification を参照してください。

v Tivoli Software Library では、ホワイト・ペーパー、データ・シート、デモンストレーション、レッドブック、および発表レターなど、Tivoli 関連のさまざまな資料を提供しています。Tivoli Software Libraryには、http://www.ibm.com/software/tivoli/library/ からアクセスできます。

v Tivoli Software Glossary では、Tivoli ソフトウェアに関連する技術用語の定義を説明しています。Tivoli Software Glossary (英語版のみ) は、Tivoli Software

Library Web ページ http://www.ibm.com/software/tivoli/library/ の左側にある「Glossary」リンクからアクセスできます。

アクセシビリティーアクセシビリティー機能は、運動障害または視覚障害など身体に障害を持つユーザーがソフトウェア・プロダクトを快適に使用できるようにサポートします。本製品では、補助テクノロジーを使用して、インターフェースを音によってナビゲートできます。インストール後は、マウスではなくキーボードを使用して、グラフィカル・ユーザー・インターフェースの全機能を操作できます。

ソフトウェア・サポートとの連絡資料およびカスタマー・サポートについては、営業担当員にお問い合わせください。

iv IBM Tivoli Directory Integrator 5.2: スタートアップ・ガイド

http://java.sun.com/products/jndi/1.2/javadoc/index.html

http://www.ibm.com/software/tivoli/library/

http://www.ibm.com/software/tivoli/library/

目次まえがき . . . . . . . . . . . . . . iii本書の対象読者 . . . . . . . . . . . . . iii資料 . . . . . . . . . . . . . . . . . iii

IBM Tivoli Directory Integrator のライブラリー . iii関連資料 . . . . . . . . . . . . . . iii

アクセシビリティー . . . . . . . . . . . . ivソフトウェア・サポートとの連絡 . . . . . . . iv

第 1 章概要 . . . . . . . . . . . . . 1本書について . . . . . . . . . . . . . . 1スクリプト言語 . . . . . . . . . . . . . 2IBM Tivoli Directory Integrator のインストール . . . 2チュートリアル・ファイルのインストール . . . . 2

第 2 章単純化して解決 . . . . . . . . 3象を食べるには、どうやって食べればいいでしょう ? 3統合は通信 . . . . . . . . . . . . . . . 3アーキテクチャー . . . . . . . . . . . . . 6AssemblyLine . . . . . . . . . . . . . . 7コネクター . . . . . . . . . . . . . . . 8パーサー . . . . . . . . . . . . . . . . 9EventHandlers . . . . . . . . . . . . . . 9

第 3 章 IBM Tivoli Directory Integratorの紹介 . . . . . . . . . . . . . . . 11

迅速な統合開発 . . . . . . . . . . . . . 11新規構成の作成 . . . . . . . . . . . . . 12AssemblyLine の作成 . . . . . . . . . . . 14入力コネクターの追加 . . . . . . . . . . . 18AssemblyLine への属性のマッピング . . . . . . 25出力コネクターの追加 . . . . . . . . . . . 33AssemblyLine の実行 . . . . . . . . . . . 38フックの操作 . . . . . . . . . . . . . . 41スキーマの変換 . . . . . . . . . . . . . 45結合コネクターの追加 . . . . . . . . . . . 47リンク基準のセットアップ . . . . . . . . . 51EventHandlers . . . . . . . . . . . . . . 60まとめ . . . . . . . . . . . . . . . . 76

付録 A. index.html およびOtherPage.html . . . . . . . . . . . 77index.html . . . . . . . . . . . . . . . 77OtherPage.html . . . . . . . . . . . . . 77

付録 B. 特記事項 . . . . . . . . . . 79第三者コンポーネントについて . . . . . . . . 81

Apache について. . . . . . . . . . . . 81Rhino について . . . . . . . . . . . . 82

商標 . . . . . . . . . . . . . . . . . 82

© Copyright IBM Corp. 2002, 2003 v

vi IBM Tivoli Directory Integrator 5.2: スタートアップ・ガイド

第 1 章概要

本書について本書は、単純なシステムについて簡単に紹介したものです。間違えないでいただきたいのですが、ここで言う単純という表現は、最も肯定的でパワフルな意味合いで使っています。なぜなら、複雑な問題に対処し解決するための最善の策は単純化することだからです。問題をより単純で扱いやすい個々の部分に細分化し、それらの構成部分を 1 つ 1 つ攻略します。Divide-and-Conquer 手法、分断攻略手法などと言います。これは、日常的な問題を解決するために無意識に使用している技法であり、オフィス全体、企業全体、あるいは地球全体にわたる技術情報の交換にかかわる問題についても、同じことが言えます。

IBM Tivoli Directory Integrator は、統合の問題を次の 3 つの基本コンポーネントに分断できるという前提に基づいて設計され、構築されています。

v 通信に関係するシステム

v それらのシステム間のデータ・フロー

v データ・フローを起動するイベント

IBM Tivoli Directory Integrator を使用すると、統合の問題についてのこの基本的な前提からソリューションを直接的に導き出すことができます。ソリューションは、一度に 1 フローずつ、フィードバックと検証を繰り返しながら漸進的に構築できます。

つまりは、統合プロジェクトの見積もりや計画がさらに容易になります。場合によっては、インプリメントする個々のデータ・フローのコストを計算して決定するだけで済むこともあります。フロー単位で視覚的、対話式にソリューションを開発できるので、プロジェクト・チームと企業の経営陣の両方に対して、いつでも進捗を報告し、デモを見せることができます。

IBM Tivoli Directory Integrator は、お客様が統合したいと望むさまざまなデータ・ソースに接続し対話するための専門的な問題を、API、トランスポート、プロトコル、フォーマットなどの詳細事項を取り払った形で管理します。IBM Tivoli

Directory Integrator は、データにフォーカスを当てるのではなく、お客様の目線を情報レベルまで引き上げ、個々の交換機能を実行するために必要な変換、フィルター、およびその他のビジネス・ロジックに集中できるようにします。

IBM Tivoli Directory Integrator では、コンポーネントおよびビジネス・ロジックのライブラリーをビルドし、それらを保守、拡張、再利用して新しい課題に対処することができます。企業内で分散されたすべての開発プロジェクトで、IBM Tivoli

Directory Integrator の資産を共用できるため、整然と統合されたインフラストラクチャーに即時に適合し、しかも個々に独立したプロジェクト (さらにポイント・ソリューションさえも) が生まれます。

このアプローチは、プロジェクトの開始時点にライブラリーをセットアップするときにデータ・ソースやテクノロジーのエキスパートを投入するので、リソースをよ

© Copyright IBM Corp. 2002, 2003 1

り合理的に、予測可能な方式で使用できるようになります。これらの統合資産は、ネットワークを介して使用でき、新しいソリューションの作成や既存のソリューションの強化のために利用することができます。

本書は、このアプローチを紹介すると共に、IBM Tivoli Directory Integrator の先進的で洗練された単純性を活用するための方法を説明します。

スクリプト言語IBM Tivoli Directory Integrator は、統合ソリューションのフレームワークをすばやく構築できるよう、的確で直観的で自動的に焦点を定めることができる環境を提供します。しかし、より高度なデータ操作や変換ロジック、およびデータのフィルター操作やデータ・フローの振る舞いの制御のためのビジネス・ルールを追加する必要が後から生じてくる場合もあるでしょう。これらはすべて、各ソリューションでスクリプトを記述することによって実行できます。

IBM Tivoli Directory Integrator は Beans Scripting Framework を使用するので、JavaScript™、VBScript、および PerlScript を含め、広範囲にわたるスクリプト言語から選択できます。

スクリプト言語についての詳細は、「IBM Tivoli Directory Integrator 5.2 リファレンス・ガイド」を参照してください。

IBM Tivoli Directory Integrator のインストールIBM Tivoli Directory Integrator は、軽量ですばやく配置できる統合ミドルウェアです。従来のミドルウェアと異なり、IBM Tivoli Directory Integrator は数分間でインストールされるので、ソリューションの構築、テスト、配置を即座に開始できます。システムは、Windows® やいくつかのバージョンの UNIX® および Linux など、広範なプラットフォームで動作します。

IBM Tivoli Directory Integrator のインストールの詳細については、「IBM Tivoli

Directory Integrator 5.2: 管理者ガイド」の『IBM Tivoli Directory Integrator のインストール手順』を参照してください。

チュートリアル・ファイルのインストール本書の例を使用するには、チュートリアル・データ・ファイルが必要です (ただし、ファイルは本書のテキストから複製できます)。

これらのサンプル・ファイルにアクセスするには、インストール・ディレクトリーの中の root_directory/examples ディレクトリーに移動してください。

root_directory は、IBM Tivoli Directory Integrator がインストールされているディレクトリーです。

2 IBM Tivoli Directory Integrator 5.2: スタートアップ・ガイド

第 2 章単純化して解決

象を食べるには、どうやって食べればいいでしょう ?答えは簡単、一度に一口ずつです。これは、巨大な統合とシステム展開のプロジェクトを消化するための最善の方法でもあります。

成功への鍵は、問題をより小さくて扱いやすい小片に分割して、複雑さを減らすことです。これは、ソリューション全体の一部分から着手する、できれば 1 から 2

週間で完了できる部分から始めるということです。これは、独立して稼動できる部分であることが理想的です。そうすれば、ソリューションの残りの部分と格闘している間に、その部分はすでに投資への見返りを生み出してくれるからです。

処理しようとしている部分を他と分離したら、通信の基本単位 (データ・フローそのもの) に焦点を当てて、その部分をさらに単純化します。これで、インプリメントを開始する準備が整います。

統合開発は、IBM Tivoli Directory Integrator を使用し、「試行/テスト/改良」という一連のサイクルを通じて行われるため、プロセスは反復的で探究型のものになります。これは、お客様自身のインストール・システムに関してさらに多くのことを発見するのに役立つだけでなく、問題とその問題がインフラストラクチャーに与える影響に対する理解を深めるにつれて、統合ソリューションを発展させることができます。

当面の問題の概念図を心に描くための効果的な方法は、それを実際に紙に描いてみることです。紙と鉛筆を使用して、ソリューションの大体の流れを示すフロー・チャートを大まかに描いてみましょう。こうしてできあがったスケッチは、タスクの範囲を視覚化するために役立つだけでなく、IBM Tivoli Directory Integrator でそのタスクをインプリメントするための青写真の役割を果たします。

統合は通信統合の問題は、すべて通信にかかわるものであり、典型的には 3 つの基本部分に分割できます。

v 通信するシステムおよびデバイス

v それらのシステム間のデータ・フロー

v データ・フローを起動するイベント

通信シナリオを構成するこれらのエレメントは、次のようなものになります。

データ・ソースこれに該当するのは、互いに通信する、データ・リポジトリー、システム、およびデバイスです。たとえば、以下のような操作ができます。

v インプリメントまたは保守している Enterprise Directory

v ご使用の CRM アプリケーション

v オフィスの電話システム


v 会社の機器および各機器の発行先のリストを含む Access データベースなどもこれに含まれることがあります。

データ・ソースは、幅広い多様なシステムおよびリポジトリーを表します。これには、たとえば、データベース (DB2®、Oracle、SQL Server など)、ディレクトリー (iPlanet、IBM Directory Server、Domino™、eDirectory およびActive Directoryなど)、ディレクトリー・サービス (Exchange など)、ファイル (XML、LDIF、または SOAP 文書など)、特殊フォーマットの E メールのほか、社内のシステムや外部のビジネス・パートナーがお客様の情報資産およびサービスと通信するために使用する、いくつかのインターフェース・メカニズムなどがあります。

データ・フロー

データ・フローは、通信とその内容から成るスレッドで、通常はデータの移動方向を示す矢印で描かれます。

各データ・フローは、2 つ以上のシステム間の通信を表します。

ただし、会話をすべての参加者にとって意味のあるものにするには、何を通信しているのかを個々の参加者が理解している必要があります。おそらく、データの内容をさまざまに異なる方法で表現している複数のデータ・ソースを使用しています。あるシステムでは、電話番号は、番号を読みやすくするためのダッシュや括弧を含むテキスト情報で表されているかもしれません。別のシステムでは、電話番号が数値データとして格納されていることもあります。

このような 2 つのシステムがこの電話番号データに関して通信する場合、会話中に情報を変換することが必要になります。さらに、ソース内の情報がそれだけでは不完全な場合、他のデータ・ソースから取り出した属性で補完しなければなりません。また、フロー内のデータの一部のみが受信システムに関係しているという場合もあります。

したがって、データ・フローには、マッピング、フィルター操作、情報の変換、入力ソースから宛先システムへのコンテキストのシフトも組み込む必要があります。

イベント

イベントは、1 セットのデータ・ソースが別の 1 セットのデータ・ソースと通信することが必要になる状況であるということができます。たとえば、従業員の追加、更新、または削除が HR システムで必要になるたびに、イベントが発生します。制限されたエリアで使用中のキー・カードをアクセス制御システムが検出した場合にも、イベントが発生します。イベントは、カレンダーまたはクロック・ベースのタイマーに基づいて発生することもあります。例えば、10 分おき、または日曜日の深夜 12 時に通信を開始することができます。また、ディレクトリーへのデータの取り込みやシステム内のデータの洗浄など、1 回限りのイベントを手動で開始できます。

イベントは、通常、データ・ソースに結び付いていて、指定された状況が発生したときに起動されるデータ・フローに関連付けられています。


これらの各エレメントは、IBM Tivoli Directory Integrator によって、コネクター、パーサー、および EventHandler の 3 種類のコンポーネントを使用して処理されます。

v コネクターは、データ・ソース内のデータに接続およびアクセスするコンポーネントです。例えば、JDBC コネクターを使用すると SQL データベースで読み取りと書き込みを実行でき、LDAP コネクターを使用するとディレクトリーにアクセスできます。データ・ソースのタイプによっては、データを構造化オブジェクト (レコードやエントリーなど) として保管できません。その場合は、代わりにバイト・ストリームが使用されます。この例として、IP 上のデータとフラット・ファイルの 2 つがあります。ここで、パーサーが必要になります。パーサーは、バイト・ストリームと構造化された情報の間で変換を行います。

v データ・フローは、1 つ以上のコネクターを接続することによってインプリメントされます (必要に応じてコネクターとパーサーを関連付けます)。

v 最後に、接続されたシステム (ディレクトリーや POP3/IMAP メールボックスなど) 内の変更通知を取得してそれらのイベントを指定された AssemblyLine へディスパッチするように、EventHandler を構成できます。

これらのコンポーネントの機能の詳細を検討する前に、インプリメントするデータ・フローの概要を明らかにする必要があります。そのためには、前述のように、フロー・チャートを作成するのが良い方法です。

選択に使用できる各種のダイアグラミング規則やスタイルがありますが、ユーザーが問題を理解することに比べれば、シンボルの実際の形状やタイプはさほど重要なことではありません。ボックスでも円形でもしゃぼん玉でも、好きな形を使ってかまいません。ただし、必ず一貫性のある使い方をし、すべてに明確で読みやすいラベルを付けてください。そうしておけば、数か月後に自分が作成したダイアグラムを見たとき、あるいはだれか他の人がそれを見たときにも、本来の意味を正しく読み取ることができます。出力データ・ソース (DS3) は最初のデータ・ソース(DS1) からデータを取得します。途中で、2 番目のデータ・ソース (DS2) から取り出した情報もデータ・フローに加わります。IBM Tivoli Directory Integrator では、このようなデータ・フローを AssemblyLine と呼びます。

個々の AssemblyLine はそれぞれ 1 つの単一方向データ・フローをインプリメントするということを理解しておくことが重要です。2 つ以上のデータ・ソース間での双方向同期をするには、別個の AssemblyLine を使用して、それぞれの方向のフローを処理することが必要です。なぜなら、データの形式と内容、およびデータに対して実行される操作が、それぞれの方向で異なる場合が多いからです。

注: IBM Tivoli Directory Integrator は、Web Services などの要求応答型情報ソリューションを作成するために必要なものをすべて提供します。

1 つの AssemblyLine に含めることができるコネクター数には制限はありませんが、AssemblyLine に含めるコネクターはできるだけ少なくする必要があります (たとえば、フローに参入する 1 データ・ソースにつき 1 つというように)。それと同時に、AssemblyLine をできる限り自律型にするために十分なコンポーネントおよびスクリプト・ロジックを含めることも必要です。その理由は、AssemblyLine を分かりやすく保守しやすいものにするためです。これは、より単純で高速でスケーラブルなソリューションを生み出す結果にもつながります。

第 2 章単純化して解決 5

IBM Tivoli Directory Integrator の方法論は、フローを一度に 1 つずつ処理し、問題を単純化することなので、まず DS1 から DS3 へのフローから見てみましょう。

データの編成方法は、システムによって大きく異なる可能性があります。

v データベースは通常、固定された数のフィールドを持つレコードに情報を保管します。

v 一方、ディレクトリーは、項目という可変オブジェクトを処理します。

v その他のシステムは、メッセージまたはキー値のペアを使用できます。

IBM Tivoli Directory Integrator は、項目と呼ばれる強力で柔軟なデータ・コンテナーにあらゆる種類の情報を収集および保管することによって、この問題を単純化します。一方、データ値自体は項目が保持および管理する属性というオブジェクト内に保持されます。

もう 1 つの問題として、これらのソースが、保管された値を表すために別のタイプを使用することが考えられます。IBM Tivoli Directory Integrator は、この点にも対処します。データ・フローに取り込まれたデータはすべて、事前定義された規則に整合する形式に変換されます (Java オブジェクト)。したがって、ビジネス・ルールと変換ロジックは、タイプの競合を処理する必要がありません。データを出力する準備ができると、IBM Tivoli Directory Integrator はそれを変換して、関連するデータ・ソース固有のタイプに戻します。

データ・フローの視覚化を完成させるため、入力データ・ソースの属性をどのように宛先システムの属性にマップ (および場合によっては変更) するかを記録してください。例えば、DS3 は次のようになります。

First =DS1.FirstLast =DS1.LastFullName =DS1.First+" "+DS1.LastTitle =DS1.TitleMail =<compute_from_name>

例を単純にするために、コンマで区切った値のファイルを DS1 として使用します。DS1 には、First、Last、および Title というフィールドが含まれています。出力データ・ソース (DS3) は XML 文書です。

これでソリューションのイメージが十分にできあがったので、次は IBM Tivoli

Directory Integrator がデータ・フローをどのように取り扱うかを見てみましょう。

アーキテクチャーIBM Tivoli Directory Integrator のアーキテクチャーは、次の 2 つに分割されます。

v システムの機能のほとんどを提供するコア・システム。IBM Tivoli Directory

Integrator のコア・システムは、ログ・ファイル、エラーの検出とディスパッチング、データ・フロー実行パラメーターを処理します。また、カスタマイズした構成とビジネス・ロジックを保守します。

v 処理する必要のあるデータ・システムとフォーマットの技術的な詳細を一般化するためのコンポーネント。IBM Tivoli Directory Integrator には、次の 3 種類のコンポーネントが用意されています。

– コネクター

– パーサー


– EventHandler

各コンポーネントは、統合フロー制御やカスタマイズなどを処理するコア機能に包含されているので、コンポーネント自体は小規模で軽量です。例えば、独自のパーサーをインプリメントする場合は、受信バイト・ストリームの構造の解釈用と発信バイト・ストリームへの構造の追加用に 1 つずつ、計 2 つの機能を用意するだけで済みます。IBM Tivoli Directory Integrator の jars サブディレクトリーを参照すると、標準コンポーネントがどれほど軽く、作成と拡張が容易かを確認できます。

このコアとコンポーネントの設計により、IBM Tivoli Directory Integrator は容易に拡張できます。また、関連するコンポーネントを選択し、それらをクリックして適所に配置することによって、ソリューションのフレームワークをすばやく構築できます。コンポーネントは交換可能であり、データ・フローのカスタマイズ済みロジックや構成済みの振る舞いに影響を与えることなくスワップアウトできます。したがって、迅速に増大および拡張できる一方で、基礎となるインフラストラクチャーでは変更されにくい統合ソリューションを構築できます。

AssemblyLineダイアグラム内のデータ・フローの矢印は、IBM Tivoli Directory Integrator でAssemblyLine に変換されます。AssemblyLine は、実世界の工場の組み立てラインと似たような働きをします。

実世界の組み立てラインは、多数の専用機械で構成されています。これらの機械は、機能も構造もそれぞれに異なりますが、1 つだけ、重要な共通の属性を持っています。つまり、すべてが連携され、入力ソースから出力までの一貫したパスを形成するということです。

組み立てラインには、一般に、生産に必要な原材料 (たとえば、魚の切り身、コーラ・シロップ、自動車部品など) を受け入れるように設計された 1 つ以上の入力装置があります。これらの原材料は、加工され、一緒に組み合わされます。時には、行程途中のアセンブリー・ラインから、副産物が取り出されます。生産ラインの終点では、待ちかまえている出力装置に最終商品が送り出されます。

生産チームは、何か別のものを生産するよう指示を受けると、新しい指示に関係のある機械のみを残して、ラインを分解します。そして、新しい装置を適切な場所に接続し、ラインを調整して、生産を再開します。IBM Tivoli Directory Integrator のAssemblyLine も、これとほぼ似たような方法で働きます。

IBM Tivoli Directory Integrator の AssemblyLine は、各種の入力装置から情報を受け取り、この入力に対する操作を実行して、最終的にできあがったものを出力装置を介して伝送します。IBM Tivoli Directory Integrator の AssemblyLine は、一度に1 項目ずつ (たとえば、1 つのデータ・レコード、ディレクトリー項目、レジストリー・キーなどを) 処理します。接続された入力ソースからのデータ属性は、Java

バケット (work オブジェクトと呼ばれます) に集められます。この情報を処理するスクリプトが追加され、データの内容の検証、新しい属性と値の計算、既存の属性と値の変更が行われて、最終的に、ラインから 1 つ以上の出力ソースに向けてデータを配布する準備が整います。


IBM Tivoli Directory Integrator AssemblyLine の入力装置と出力装置は、コネクターと呼ばれます。各コネクターはデータ・ソースにリンクされています。コネクターは、データ・フローを外部の世界に結び付けるもので、データの形式変更と集約が行われる場所でもあります。コネクターは、ビジネス管理、セキュリティー管理、および ID 管理のロジックの層を設定できる場所でもあります。

コネクターコネクターは、ジグソー・パズルのピースに似ていて、ぴたりとはめ込まれて相互に連結され、同時に、特定のデータ・ソースにリンクされています。

このパズル・ピースの 1 つを選択して AssemblyLine に追加するたびに、次のことを行う必要があります。

1. コネクターのタイプを選択する。

2. コネクターに、データ・フロー内での役割を割り当てる。これは、コネクター・モードと呼ばれ、IBM Tivoli Directory Integrator に、コネクターを次のどの方法で使用するかを通知します。

v ソース内の情報を繰り返すか、またはルックアップする入力コネクターとして使用する。

v 接続先のシステムまたはデバイスにデータを挿入したり、それらのデータを更新または削除する出力コネクターとして使用する。

注: データは、入力ソースからプルし、出力先にプッシュする必要があります。コネクターが担当するのがこの作業です。

コネクターのタイプとモードはどちらも、インフラストラクチャーやソリューションのゴールの変更に応じていつでも変更できます。そのような事態に備えて計画しておけば、データ形式変更やフィルター操作も含め、AssemblyLine の残りの部分は影響を受けません。個々のコネクターを、データを配布して混合体にするためか、または混合体から一部を抽出してデータ・ソースに送信するためか、どちらか一方の処理をするブラック・ボックスとして取り扱うことが重要な理由は、ここにあります。各コネクターの独立性が高くなればなるほど、ソリューションの強化と保守が容易になります。

コネクターをできるだけ自律型にすることで、コネクター・ライブラリーに簡単に転送できるようになるため、それらのコネクターを再使用して新規ソリューションを短期間に作成すること、および他の人々とコネクターを共用することも可能になります。IBM Tivoli Directory Integrator のライブラリー機能を使用すると、コネクターの保守および拡張が容易になります。なぜなら、ライブラリー内のコネクター・テンプレートを更新しさえすれば、そのテンプレートから派生したすべてのAssemblyLine がこれらの拡張機能を継承するからです。ソリューションを重要な作業に適用する準備ができたら、ライブラリー内のコネクターを再構成し、テスト環境内のデータ・ソースでなく実動データ・ソースに接続して、ソリューションを瞬時にラボから実際の配置に移すことができます。

新規データをフローに組み込む必要がある場合は、関連するコネクターをAssemblyLine に追加するだけで済みます。


IBM Tivoli Directory Integrator には、 LDAP、 JDBC、 Microsoft® NT4 Domain、Lotus® Notes® および POP3/IMAP などが選択可能なコネクター・ライブラリーがあります。探しているコネクターが見つからない場合は、JavaScript、VBScript、PerlScript を始めとする主要スクリプト言語のいずれかを使用して関数の一部またはすべてを指定変更することにより、既存のコネクターを拡張することができます。スクリプト・コネクター・ラッパー内のスクリプト言語を使用するか、あるいは、Java または C/C++ を使用して、最初からユーザー独自のコネクターを作成することもできます。

さらに、IBM Tivoli Directory Integrator は、TCP/IP、FTP、HTTP、JMS (MQ) などほとんどのトランスポート・プロトコルを、情報のフローを保護する SSL やその他の暗号化メカニズムの有無に関わらずサポートしています。

スクリプト言語の詳細や独自のスクリプト言語の作成方法については、「IBM Tivoli

Directory Integrator 5.2: リファレンス・ガイド」を参照してください。

パーサーIP ポート経由で届くテキスト・ファイルやバイト・ストリームなどのような、構造化されていないデータでも、IBM Tivoli Directory Integrator を使用すると、1 つ以上のパーサーを介してバイト・ストリームを受け渡しすることによって、すばやく簡単に処理できます。パーサーは、IBM Tivoli Directory Integrator のコンポーネントの 1 つです。システムには出荷時に、LDIF、DSML、XML、CSV、および固定長フィールドを含む、さまざまのパーサーが付属しています。コネクターの場合と同様に、これらのパーサーも拡張や変更ができ、ユーザー独自のパーサーを作成することもできます。

次のステップは、6 ページの例からの続きで、データ・ソースを識別するためのステップです。入力データ・ソースはコンマで区切られた値の形式のテキスト・ファイルなので、ファイル・システム・コネクターを CSV パーサーと組み合わせて使用します。出力にも同様にファイル・システム・コネクターを使用しますが、出力側では、ファイルを XML 文書としてフォーマットするために XML パーサーを選択します。

注: 本書で使用する例は UNIX プラットフォームで作成されているので、UNIX のパス名規則を使用しています。ソリューションをプラットフォームから独立したものにするには、パス名の中で、バックスラッシュまたは円記号 (¥) の代わりに通常のスラッシュ (/) を使用してください。たとえば、以下のようになります。examples/Tutorial/Tutorial1.cfg これは、Windows プラットフォームとUNIX/Linux プラットフォームの両方で機能します。

EventHandlersEventHandler は、IBM Tivoli Directory Integrator の 3 番目のコンポーネントであり、リアルタイム統合ソリューションを構築するための機能を提供します。

EventHandler には、コネクターと同様に、データ・ソース情報があり、これによってシステムやサービスに接続し、イベント通知を待つことができます。例えば、POP3 または IMAP メールボックスに新規メッセージが到着したときにそれを検出する Mailbox EventHandler や、ディレクトリーに加えられた変更を検出する LDAP


EventHandler があります。イベントが発生すると、EventHandler はイベントの特性を保管し、ロジックを実行して、セットアップされた条件とアクションの規則に従って AssemblyLine を開始します。

場合によっては、JMS コネクターや LDAP Changelog コネクターなどのコネクターを使用してイベントを取り込むことができます。どちらのコネクターも、新規データが現れるのを待ってからそれを取り込むように構成できます。ただし、EventHandler は独自のスレッド内で動作するので、それらを使用すると、複数のAssemblyLine にイベントをディスパッチできます。これは、同一のソース (例えば、SOAP 呼び出しや Web Services 呼び出しなど) から複数のタイプのイベントをフィルターに掛けて処理するための、よりクリーンで強力な方法を提供します。EventHandler を Auto Start に対して構成することもできます。その場合、構成でサーバーを始動すると、それらの EventHandler がただちに活動化されます。これにより、コマンド行パラメーターで実行する AssemblyLine をサーバーに対して特に指定する必要がなくなります。

IBM Tivoli Directory Integrator で使用するコンポーネントの概要については以上で終わりです。これで、AssemblyLine を構築する準備が整いました。しかし、先に進む前に、入力ファイルが必要です。この種のファイルの例は、IBM Tivoli Directory

Integrator がインストールされているディレクトリーの examples/Tutorial サブディレクトリーにもありますし、テキスト・エディターで独自に作成してもかまいません。含まれているサンプル・データは、次のようなものになります。

First;Last;TitleBill;Sanderman;Chief ScientistMick;Kamerun;CEOJill;Vox;CTORogerGregory;Highpeak;VP Product DevelopmentErnie;Hazzle;Chief EvangelistPeter;Belamy;Business Support Manager

このファイルは People.csv と呼ばれ、IBM Tivoli Directory Integrator がインストールされているディレクトリーの examples/Tutorial フォルダーに格納されています。ファイルを配置したら、IBM Tivoli Directory Integrator を使用してソリューションをビルドする準備が整います。


第 3 章 IBM Tivoli Directory Integrator の紹介

迅速な統合開発IBM Tivoli Directory Integrator は実際には 2 つのプログラムで構成されています。

Toolkit IDE

このプログラムは、統合ソリューションを作成、テスト、デバッグするためのグラフィカル・インターフェースを提供します。Toolkit Integrated

Development Environment は、ランタイム・エンジンによって開始される構成ファイル (Config ファイルと呼ばれます) を作成するために使用します。Toolkit IDE 実行可能ファイルの名前は、ibmditk です。

ランタイム・サーバー

ランタイム・サーバーは、Toolkit IDE で作成された構成 (高度に構造化された XML 文書として格納されています) を使用して、統合ソリューションを強化します。このプログラム・ファイルの名前は ibmdisrv です。ソリューションを展開するときには、使用するサーバー・インスタンスの数を必要に応じて自由に増減することができます。IBM Tivoli Directory Integrator テクノロジーによって課される制限はありません。

Toolkit IDE を開始します。しばらくすると、メインスクリーンが表示されます。この画面から新規の構成を作成したり、それを再表示することができます。

注: 本書で示す画面ショットが実際の画面と異なる場合は、ご使用のシステムの表示設定が異なっている可能性があります。表示設定を変更するには、次のようにします。

1. 「ファイル」->「設定の編集」をクリックします。

2. 「外観」タブをクリックします。

3. 「ルック・アンド・フィール」タブをクリックします。

IBM Tivoli Directory Integrator のウィンドウはサイズ変更が可能です。したがって、本書に示す画面ショットが実際の画面と異なる場合は、ウィンドウ・サイズの変更も試してみてください。「ファイル」->「設定の編集」を選択するとオープンするダイアログで、その他の多数のユーザー・インターフェース・パラメーターを設定できます。メイン・ボタン・ツールバーを表示するか非表示にするか、IBM Tivoli Directory Integrator でウィンドウ下部のステータス・バーを使用するかどうかなども、ここで設定できます。

画面の上部には、メインメニューとボタン・ツールバーがあります。


メイン・ツールバーには、新規構成の作成、既存の構成のオープン、および現在の作業の保管のためのコマンドを実行するボタンのほか、いくつかのナビゲーション・ボタンもあります。ボタンで実行するものと同じコマンドが、「ファイル」メニューおよび「ウィンドウ」メニューからも使用できます。これらのメニューからは、ご使用の構成に新しいファイル名を付けて保管するための「別名保管」も選択できます。

新規構成の作成IBM Tivoli Directory Integrator の構成は、XML 文書として保管されます。これらは Toolkit IDE で作成および管理され、サーバーで配置されます。各構成には、サーバーが実行する AssemblyLine が含まれているほか、それらの AssemblyLine を形成している IBM Tivoli Directory Integrator コンポーネントも含まれています。構成には、カラーや GUI インターフェース・スタイルなどのユーザー設定も含まれています。


注: 構成は、複数のファイルに分割して保管したり、別々の場所に格納することもできます。IBM Tivoli Directory Integrator は、ユーザーが指定した組み込みURL およびファイル・パスを使用して、始動時に構成を動的にアセンブルします。これは、企業で使用する設定およびコンポーネントを、多数のサーバー構成で共用できる形で作成し保守できることを意味します。一度に複数の構成を開き、構成間でコンポーネントをドラッグ・アンド・ドロップして作業することができます。

システムを最初に始動したときは、前ページの図のような何もない画面が表示されます。新規構成を作成しようとすると、IBM Tivoli Directory Integrator は、rs.xml

という名前のデフォルトの構成ファイルを作成するかどうかを尋ねます。デフォルトの構成名を使用する代わりに、ファイルに別の名前を付けることもできます。「新規構成ルートを作成します」ボタンをクリックするか、または「ファイル」->「新規」のメニュー選択を使用して、Tutorial1 という名前の構成を作成します (拡張子 .xml が自動的に追加されます)。このファイルは、examples/Tutorial ディレクトリーの中に保管する必要があります。

注: パス名は、IBM Tivoli Directory Integrator をインストールするときに指定したディレクトリーを基準とした相対パス名で書くことができます。

画面の左側のツリー・ビューは「構成」ブラウザーと呼ばれ、ソリューションのさまざまな局面が組み込まれたフォルダーを表示します。

AssemblyLine というラベルの付いた一番上のフォルダーには、作成したAssemblyLine が格納されます。そのすぐ下には、コンポーネント・ライブラリーを保管するフォルダーが 3 つあります (各コンポーネントごとに 1 つのフォルダー)。これにより、構成パラメーターと動作パラメーター、データ形式変更、およびその他のビジネス・ルールで標準コネクター (例えば、LDAP、JDBC、Notes など)

をセットアップし、それらを使用および再使用して新規ソリューションを作成することができます。

ここでは、Toolkit IDE インターフェースの詳細には触れず、構成画面の一般的なレイアウトについて説明します。

v ツールバーの下の残りの画面は、複数のペインに編成されています。「構成」ブラウザーは左側に表示されますが、このペインは、メイン・ツールバーの「構成ツリー・ビューを切り替えます」ボタンを使用するか、「構成」ブラウザーの横の仕切りバーの一番上にある矢印をクリックして、表示または非表示にすることができます。このペインの右側には、「構成」ブラウザーで選択した項目の詳細の表示を変更する詳細領域があります。

v 「詳細 (Details)」ペインには、「構成」ブラウザーで別の項目を選択するたびに新規ビューが開かれるので、複数の詳細ビューが表示されます。これらのペインにアクセスするには、「ウィンドウ」メニューを使用するか、各ビューの一番上にあるタブを使用します (システムの表示の設定方法によって異なります)。

第 3 章 IBM Tivoli Directory Integrator の紹介 13

v 項目のリストが表示される「詳細 (Details)」ペインもあります。「詳細(Details)」ペインで各項目をクリックすると、その詳細も表示されます。

v リスト内の列幅を変更するには、列と列の境界線上にマウス・カーソルを置きます (境界線上にくると、カーソルの形状が変わって変更操作が可能なことを示します)。そして、クリック・アンド・ドラッグによって、境界を新しい位置まで移動します。

v 各エレメント・リストの上部には、そのタイプのオブジェクトに使用できる一連の操作のボタンが並んでいます (データ・フロー・ペインの場合は、コネクター・リストの下にボタン・バーがあります)。使用可能な操作のリストはペインによって異なりますが、リストから項目を選択し、ボタンをクリックするという、一般動作は同じです (ただし、「追加」ボタンのみは例外です。このボタンの場合、先に何も選択する必要はありません)。

v 複数のエレメントを一度に選択するには、Shift キーまたは Ctrl キーを押しながら、リスト内の項目を強調表示させます。

v 「構成」ブラウザーから AssemblyLine へ、あるいは開かれている構成間で、項目をドラッグすることができます。

AssemblyLine の作成最初にしなければならないことは、新規 AssemblyLine の作成です。「AssemblyLine」フォルダーを右マウス・ボタンでクリックします。コンテキストに応じて表示されるポップアップ・メニューから、「新規 AssemblyLine」を選択します。この AssemblyLine に、CSVtoXML という名前を付けます。

AssemblyLine の名前は自由に決めることができます。ただし、ソリューションの文書化に役立つような命名規則を用いることが重要です。

注: AssemblyLine または IBM Tivoli Directory Integrator のコンポーネント (コネクターや EventHandler など) に名前を付けるときに、特殊文字およびスペースを使用することはお勧めできません。後になってソリューションを実行するときに、IBM Tivoli Directory Integrator Server をコマンド・プロンプトから始動しようとした場合に、問題が起こることがあります。AssemblyLine ではソリューション内のコンポーネントとその他の構成項目をスクリプト・オブジェクトとして使用できるので、パラメーターと実行時の振る舞いを変更できます。つまり、スクリプトでこれらのオブジェクトを参照できるような名前を使用する必要があります。


これで、IBM Tivoli Directory Integrator の AssemblyLine 画面が表示されます。以前は何も表示されていなかった構成ペインが、この新しい画面では埋まっていることに注意してください。

コネクターを追加する前に、AssemblyLine 画面のレイアウトをざっと見ておきましょう。

「詳細 (Detail)」の上部にはタブが並んでおり、各タブは「構成」ブラウザーから開かれた項目と関連付けられています (ここでは新規 AssemblyLine 詳細画面)。各タブのタイトルには、この詳細画面を閉じる「クローズ」などのボタンが並んでいます。

注: 構成ツールのボタンにカーソルを合わせると、ツールの説明が現れます。


ボタンの並びには、「クローズ」ボタンのほかに次の 2 つのボタンがあります。

実行現在の AssemblyLine を実行します。

デバッグの実行IBM Tivoli Directory Integrator には、データ・フロー・デバッガーが組み込まれています。これにより、コネクター間で制御が渡される際にAssemblyLine 内部でトランスポートおよび変換処理されるデータを監視して、AssemblyLine をステップスルー・デバッグすることができます。

「AssemblyLine 詳細 (AssemblyLine Details)」画面の左の白いボックスはコネクター・リストであり、新規コネクターをフローに追加すると、このリストに表示されます。コネクター・リストの下には、「作業項目」表示があります。これにより、接続されたシステムから読み取られるデータ属性が常に表示される、データ・フローを参照できます。これらのリストの右側には、現在選択されているコネクターの詳細が表示されます。

詳細領域の上部に、AssemblyLine タブがあります。これらのタブを使用して、このデータ・フローのさまざまな局面にアクセスできます。

これらのタブには以下のものがあります。

フック AssemblyLine の「フック」タブでは、次の場合に評価または実行するスクリプトをセットアップできます。

v コネクターが初期化される前 (接続を開始する前にコネクターを再構成できます)

v コネクターを初期化してから最初のコネクターに制御を渡すまでの間

v 最後のコネクターが完了した後

v なんらかの外部イベントにより AssemblyLine の終了が要求された時

データ・フローここでは、コネクターの作成と保守ができます。

構成... この AssemblyLine 用の多数の構成パラメーターが示されています。

呼び出し/戻り外部プロセス (EventHandler など) からの呼び出しを容易にするため、このAssemblyLine の入力パラメーターと出力パラメーターを指定できます。

「構成...」タブをクリックすると、たとえば、この AssemblyLine に使用するスクリプト言語や、繰り返し回数の制限などのパラメーターの設定ができることが分かります (繰り返し回数の制限は、大きいデータ・セットを対象とする AssemblyLine を開発およびテストする場合に便利です)。

注: AssemblyLine で使用するためにどのスクリプト言語を選択するかには関係なく、IBM Tivoli Directory Integrator では、他の言語を使用してスクリプトが作成されているコンポーネントを使用できます。AssemblyLine ロジックを


JavaScriptで記述した場合でも、選択するスクリプト言語が IBM Tivoli Directory

Integrator を実行しているプラットフォームでサポートされていれば、VBScript

で作成したコネクターも PerlScript ベースのパーサーも使用できます。

「コネクター」ボックスのすぐ下には、コネクター・リスト・ボタン・バーがあり、コネクターを処理するためのさまざまな操作ができるようになっています。

これらのボタンでは、次のアクションを実行します。

コネクターの追加新規コネクターを AssemblyLine に追加します。これは、コネクター・リスト内の「構成」ブラウザーから、事前に構成されたコネクターをドラッグすることによっても実行できます。

スクリプト・コンポーネントの追加新規コネクターを AssemblyLine に追加します。スクリプト・コンポーネントは、AssemblyLine 内に置くことができるスクリプトのブロックです。

削除現在選択されているコネクターまたはスクリプト・コンポーネントをAssemblyLine から除去します。

名前変更現在選択されている項目の名前を変更できるようにします。

上へ選択したコネクターまたはスクリプト・コンポーネントを、AssemblyLine

の先頭方向に 1 スポット移動します。AssemblyLine はこれらの項目を上から下への順序で実行するので、この位置は重要です。

下へ選択した項目をリストの終わりに移動します。

ライブラリーにコピー選択したコネクターをコピーし、それをコネクター・ライブラリーにドロップします (「構成」ブラウザーの「コネクター」フォルダーの下)。


入力コネクターの追加最初のコネクターを作成するには、「追加」をクリックします。

このコネクター InputPeople を呼び出し、「コネクター」というラベルの付いたドロップダウン・リストをクリックします。リストから「ファイル・システム」テンプレートを選択します。このテンプレートに、システムで提供されるコネクターと、ユーザーのコネクター・ライブラリー (コネクター・フォルダー内) に登録されているコネクターが表示されます。ライブラリー・コンポーネントは、これらの選択ドロップダウン・リストの一番上に表示されます。

ここで設定する最後のパラメーターは、コネクター・モードです。これは、AssemblyLine にこのコネクターの役割を示します。IBM Tivoli Directory Integrator

には、次の 6 つのコネクター・モードがあります。

AddOnlyこのモードは、新規情報をデータ・ソースに追加するだけのコネクターに対して指定します。たとえば、ファイルに書き込む場合や、データベースまたはディレクトリーを初めて移植する場合などに使用します。

削除削除モードを指定すると、コネクターは、特定の項目またはレコードを検索し、削除します。検索に使用するキーの仕様は、リンク基準と呼ばれます。リンク基準は、ルックアップと更新を実行するコネクターに対しても指定する必要があります。これらのモードでも、コネクターが、接続されたシステム内で一致するデータを検索する必要があるためです。

イテレーターイテレーター・モードのコネクターは、データ・ソース全体 (または、データベースの特定ビューやディレクトリー検索の結果セットなど、データ・ソースの一部) を通じて実行され、AssemblyLine で処理するために項目を一度に 1 つずつ戻します。イテレーター・モードのコネクターをイテレーターと呼びます。1 つの AssemblyLine に複数のイテレーターを含めることができます。これらのイテレーターは順に始動され、最初のイテレーターがデータ・セットの終わりに達したときに、2 番目のイテレーターが始動されます。


ルックアップこのモードでは、コネクターは、指定された検索基準を満たす項目を検出して戻します。これは、情報を収集してデータ・フローに入れるために使用するモードです。

更新更新モードでは、コネクターは指定された項目またはレコードを検索しようとします。コネクターが検索に成功した場合は、コネクターに渡された情報によって既存の項目が変更されます。ルックアップに失敗した場合は、コネクターは、変更する代わりに情報を追加します。

呼び出し/戻りこれは、非常に特殊なモードであり、まず呼び出しパッケージ (SOAP メッセージや JMS 項目など) を出力してから応答を待ちます。Web Service

Connector を使用する場合は、呼び出し/戻りモードに設定する必要があります。

注: すべてのコネクターですべてのモードを使用できるわけではありません。例えば、フラット・ファイル対象の操作では、ルックアップ、削除、更新、および呼び出し/戻りはサポートされていません (ユーザー独自のコネクターを作成した場合、または既存のコネクターを拡張した場合は別です)。

1 つの AssemblyLine が保持できるコネクター数に制限はありません。また、同じタイプのコネクターを必要な数だけ指定でき、同一データ・ソースに接続することもできます。これが必要な場合もあります。例えば、データ・ソース内のレコードをすべて削除するために AssemblyLine を作成する必要があるとします。まずイテレーター (イテレーター・モードのコネクターなど) をセットアップして、削除するオブジェクトを戻します。次に、同じシステムを処理するように構成された 2 番目のコネクターを追加しますが、このときは削除モードに設定します。その結果、AssemblyLine は入力ソースをループして 2 番目のコネクターに項目を渡し、2 番目のコネクターはそれを削除します。

また、場合によっては、同一データ・ソースに複数の同時接続があるのは望ましくないこともあります。リソースのロックまたはソフトウェア・ライセンスによる制限などのため、同時接続が不可能な場合もあります。このような場合は、新規コネクターを追加する際に、IBM Tivoli Directory Integrator に既存の接続の再使用を指示することができます。そのためには、「コネクター・タイプ」ドロップダウン・リストの一番下にスクロールします。リストの一番下には、AssemblyLine 内のその他のコネクターの名前が表示され、名前の前にアットマーク ( @ ) が付いています。


作成したコネクターに名前を付け、タイプおよびモードを定義したら ( 18ページの『入力コネクターの追加』を参照)、「OK」をクリックして選択を確認してください。この新しいコネクターが、構成ペインの左側の AssemblyLine コネクター・リストに表示されます。現在選択されているコネクターの特性が、リストの右の詳細表示領域に表示されます。


コネクターのタイプを後で変更する場合は、詳細ペインの上部にある「継承元:」リンク (「状態」ドロップダウンの隣) をクリックして別のタイプを選択するだけで済みます。

追加したコネクターについて最初にしなければならないことは、そのコネクターを構成することです。コネクター詳細画面 (上記を参照) で「構成」タブが選択されていることを確認します。このタブは、接続先のデータ・ソースに密接に関連付けられていて、個々のコネクター・タイプに応じて異なります。

ファイル・システム・コネクターを追加したら、記述先のファイルのパスを入力する必要があります。「ファイル・パス」フィールド (画面解像度によっては、ペインを横にスクロールして表示させます) の横にある「選択 ...」ボタンを使用して、examples/Tutorial サブディレクトリーで People.csv ファイルを選択します。


ここでは、構造化されていないデータの読み取りと書き込みを行うコネクター・タイプを使用するので、パス名のほかにパーサーも構成する必要があります。まず「パーサー」タブ (コネクター詳細ペインの「接続」の横) を選択し、タブの下部にある「継承元:」ボックスで「[親] ([parent])」リンクをクリックします。


パーサー用にコネクターの継承およびその他の特性を設定するもう 1 つの方法は、「継承 (Inheritance)」ダイアログを使用することです。これは、コネクター詳細ペインの上部にある「継承 (Inheritance)」ボタンから使用できます。

注: 事前構成されたパーサーがライブラリーにある場合は、「構成」ブラウザーからパーサーをドラッグして、「継承元:」ボックスの [親] ([parent])リンクにドロップします。その他の「コネクター」タブを確認すると、コネクターのさまざまな性質がすべて継承されていることが分かります。

「継承 (Inheritance)」ダイアログを開いたら、「CSV パーサー」を選択します。


パーサーを選択したら、「スキーマ」タブを選択します。データ・ソースへ実際に接続できます。「データ・ソースに接続」ボタンをクリックします。

このタブの上部にある「接続」ボタンをクリックして、コネクターがデータ・ソースに到達するかどうかを確認します。成功すると、「接続が確立されました」というメッセージが表示されます。次に、「次へ」ボタンをクリックします。「次へ」ボタンをクリックするたびに、データ・ソース内の次の項目を読み取り、スキーマを分析し、ソース固有のデータ・タイプをそれに対応する Java オブジェクト (ストリング、日付 / 時刻、整数など) に変換するように、システムに指示していることになります。


ソースから検索されたデータは、表形式で表示され、属性名、Java オブジェクト・タイプ (IBM Tivoli Directory Integrator での変換後に得られるタイプ)、およびデータ・ソース内で検出された実際の値が示されます。これは、宛先のシステムまたはファイルとの接続が存続していることを確認するのに役立つだけでなく、読み取り中のデータを目で見ながら制御することもできます。IBM Tivoli Directory Integrator

が基礎になっているデータ・タイプを希望のタイプに変換していなかったとしても、慌てることはありません。この動作は、これらの属性をデータ・フローにマップするときに、いつでも指定変更することができます。

AssemblyLine への属性のマッピング属性マッピングは、データ・ソースとデータ・フローとの間で情報を移動する操作です。前のステップでは、どのようにして IBM Tivoli Directory Integrator がユーザーに代わってスキーマを発見するかだけでなく、データを自動的に Java オブジェクトに変換するかを見てきました。それでは、なぜ属性マッピングが必要なのでしょうか。

IBM Tivoli Directory Integrator はユーザーがデータを使用できるようにはしましたが、システムには、ユーザーがそのデータをどのように使用したいのかを予想することはできません。したがって、少なくとも、使用したい属性をユーザーが選択する必要があります。

一部の属性は、計算、結合、作成、または変換が行われ、IBM Tivoli Directory

Integrator が選択したものとは異なるフォーマットまたはタイプにすることが必要な場合があります。通常、この処理は属性マップ内のスクリプト記述で取り扱います。

IBM Tivoli Directory Integrator でこの作業がどのように機能するかを理解するには、まずコネクター (実際にはすべてのコンポーネント) が次の 2 つの部分から構成されていることを認識する必要があります。

v ロー・コネクター。これは、特定のデータ・ソースとどのように通信するか、およびそこからの応答をどのように解釈するかを認識しています。


v 汎用 AssemblyLine コネクター・ラッパー。これは、コネクターが IBM Tivoli

Directory Integrator の AssemblyLine フレームワークにプラグインしてそこで作動できるようにします。

データ・ソースとの間で受け渡しされる情報は、ロー・コネクター内部の一時ローカル・ストレージ・オブジェクトに保持されます。ここから、属性を AssemblyLine

にマップしたり、出力コネクターの場合はデータ出力ソースにマップしたりします。

work というストレージ・オブジェクト (項目オブジェクト) が 1 つあります。これは、データ値 (属性) をトランスポートするために AssemblyLine 全体で使用されます。さらに、各コネクターには、conn というローカル項目オブジェクトがあります。これは、データ・アクセス操作に使用されます。属性をデータ・フローの内外へ移動することを、マッピングといいます。これを実行するには、AssemblyLine

の work オブジェクトとコネクターの conn オブジェクトの間でデータ値を移動する必要があります。

前述のように、コネクターのデータ・ソース固有の部分は、「継承 (Inheritance)」ボタンを使用するか、コネクター詳細ペインの上部にある「継承元:」リンクをクリックしてタイプを変更するだけで、いつでも変更できます (22 ページを参照してください)。ただし、これを実行する場合は、ビジネス規則 (スクリプト) やAssemblyLine 内のその他のコネクターが必要な属性にアクセスできるように、属性マップも変更する必要があります。

ご使用の入力モードのコネクターは、ロー・コネクター (スクリプトでは conn と呼ばれる) 内のローカル・ストレージから、AssemblyLine 内のデータを格納しトランスポートするために使用されるオブジェクト (work オブジェクト) へと属性をマップするので、コネクターのモードを変更すると、属性マップにも影響が出ることがあります。出力コネクターは、反対方向に、つまり work から conn へと属性をマップします。

この例では、InputPeople コネクターが入力モードなので、入力マップを設定する必要があります。


「作業属性」というボックスの上に、属性マップ・ツールバーがあります。これを使用すると、マップ内の属性を処理できます。マップの右側の領域には、コネクターによって発見された属性のリストが表示されます。ここで、1 つ以上の属性を選択し、それらを属性マップにドラッグすることができます。複数のエレメントを一度に選択するには、Shift キーまたは Ctrl キーを押しながら、リスト内の項目を強調表示させます。

注: この操作をしようとしたときに、ユーザーのプラットフォームの Java 用 GUI

インターフェース・ライブラリーの現行バージョンで、問題が起こる場合があります。その場合は、「作業属性」というボックス・ヘッダーの上に属性をドラッグ¥アンド¥ドロップしてみてください。

入力マップに属性を追加すると、それらは AssemblyLine コネクター・リストのすぐ下にある「作業属性」リストと AssemblyLine の「作業項目」ボックスの両方に表示されます。

「作業項目」表示は、データ・フローへの窓口のようなものであり、接続されたシステムからどの属性がマップされているか (または作成されているか) や、それらを処理するコネクターの名前が表示されます。


最初のコネクターの属性マッピングが完了した後の画面は、次のようなものになります。

ここでセットアップしているのは、コネクターから Assembly Line への、単純な 1

対 1 のマッピングです。もう少し複雑なマッピングが必要な場合は、前に述べた「作業属性」ボックスの上にあるボタンの出番です。たとえば、以下のような操作ができます。

新規このボタンを使用すると、入力システムからは使用できない属性や既存の属性から計算する必要のある属性を手動で追加することができます。

削除 1 つ以上の属性をマップから除去します。

切り替え...使用可能なコネクター属性を表示するペインと、マップ内の各属性がどのように処理されているかの詳細を表示するペインとを切り替えます。

名前変更... (Rename...)属性の名前を変更できます。

上矢印と下矢印これらのボタンを使用すると、コネクターを実行する順序を変更できます。AssemblyLine は処理をリストの上から下へ順番に実行します。


ライブラリーにコピーコネクターが希望通りに構成されている場合は、このボタンを押して、コネクター・ライブラリーにコピーできます。

「入力マップ」で属性を選択すると、その属性の詳細のマッピングが表示されます。詳細ペインの上部に、「拡張」というチェック・ボックスがあります。チェック・マークが付いていない場合は、これから使用しようとしているのが属性の単純マッピングであることを意味します。例えば、IBM Tivoli Directory Integrator は、接続されたシステムから読み取られている対応する属性から値を引き上げます。

しかし、着信データを変換したい場合、またはその他の方法で値を操作したい場合は、拡張モードでその操作をスクリプト化することができます。拡張モードを選択すると、スクリプト・エディター・ウィンドウが表示されます。ここで、独自のロジックを追加できます。IBM Tivoli Directory Integrator がすでに単純モードで実行していることをエミュレートするだけの場合は、ボックスに次のような JavaScript

コードの断片が表示される場合があります。

ret.value = conn.getAttribute("First");

注: IBM Tivoli Directory Integrator は、単純マッピングを実行する際、前述のように属性をコピーしますが、この処理は、ユーザーが拡張マッピングを選択すると同時に起動されるスクリプト・エンジンではなく、ネイティブ Java で行われ


ます。単純マッピングで十分な場合は、拡張マッピングを選択しないでください。単純マッピングの方が、IBM Tivoli Directory Integrator が関連データの移動を処理する際に、はるかに効率がよくなります。

このスクリプト行は、ロー・コネクター内のローカル・ストレージから First と名付けられた属性 (conn オブジェクト) を戻します。

少し時間を割いて、IBM Tivoli Directory Integrator のスクリプト・エディター・ウィンドウを見てみましょう。このウィンドウは、スクリプトを書くことが必要な場合に必ず表示されます。このウィンドウ内では、さまざまな標準的なエディター機能を使用できます (一部は、エディター・ウィンドウの上に一列のボタンとして表示されています)。

矢印キーエディター・ウィンドウ内でカーソルを移動します。このとき同時に Shiftキーも押すと、テキストを選択できます。Ctrl キーを押しながら、左矢印キーまたは右矢印キーを押すと、カーソルが一度に 1 ワードずつ移動します。スクリプトをワード単位または行単位で選択するには、Shift キーとCtrl キーの両方を押します。

切り取り選択したテキスト範囲を切り取ります。この機能は、エディター・ウィンドウの上のボタン行の左端のボタンを押しても、キーボード上で Ctrl+X のショートカット・キーを押しても、どちらの方法でも使用できます。


コピー現在選択されているテキストをコピーします。コピーを実行するには、ボタン行の左から 2 番目のボタンをクリックするか、または Ctrl+C を押します。

貼り付けテキストを、スクリプト内のカーソルの現在位置に貼り付けます。左から 3

番目のボタンをクリックするか、または Ctrl+V を押します。

元に戻す前回の編集操作をロールバックします。これは、左から 4 番目のボタンです。

再実行元に戻したばかりの変更を再適用します。再実行ボタンは、ボタン列の中では「元に戻す」ボタンの右側にあります。

検索スクリプト内でのテキストの検索ができます。左から 6 番目のボタンを押すか、または Ctrl+F を押します。

再び検索前回の検索を繰り返します。検索ボタンのすぐ右にあるボタンをクリックします。または Ctrl+G を押します。

行折り返しの切り替えエディター・ウィンドウで行折り返しをオン/オフにします。

外部エディターを使用してバッファーを編集します「エディター設定」タブの下の「ファイル」->「設定」で外部エディターを宣言してある場合は、このボタンを押すとそれが起動します。スクリプト編集バッファーの内容が外部エディターに転送され、作業が完了すると、その結果が IBM Tivoli Directory Integrator に戻されます。

入力ソースから読み取られた他の属性の値を元に計算できる FullName という名前の属性を追加して、スクリプトを作成してみましょう。入力マップの上部にある「新規」ボタンをクリックします。

表示されるダイアログ・ボックスで、FullName という名前を入力し、「OK」をクリックします。

IBM Tivoli Directory Integrator は、自動的に単純マッピングを使用して FullNameという名前のデータ・ソース属性から値を検索しようとします。これは成功しません。なぜなら、入力ファイルの中にこの情報がないからです。ユーザーが属性マッ


プ・リストの中でこの新規項目を選択し、「拡張マッピング」チェック・ボックスを選択する必要があります。スクリプト・エディター・ウィンドウにアクセスします。

この属性の値を作成するために使用するスクリプトは、次に示すとおりです。

gn = conn.getString("First");sn = conn.getString("Last");

この最初の 2 行で、First 属性および Last 属性の値がストリングとして検索され、それぞれ gn および sn と呼ばれる 2 つの新規変数に格納されます。

ret.value = gn + " " + sn;

この最後のステートメントで、上記の 2 つのローカル変数の値が、間に 1 個のスペースを入れて連結された形式で戻されます。

注: この属性は出力コネクターの中でも作成できます。しかし、後で AssemblyLine

内でこの属性が必要になるので、入力コネクターに入れてください。

データ・フローへの入力データの送り込みは、これで終わりました。入力ソースに接続し、CSV パーサーを介してバイト・ストリームを一度に 1 行ずつ渡し、これらのフィールドを Java オブジェクトに変換し、変換後のデータを AssemblyLine に移すところまできました。ここで、出力コネクターを追加する必要があります。


出力コネクターの追加コネクター・リストの下部にあるボタン・ツールバーで「追加」ボタンをクリックします。コネクターに、XMLOutput という名前を付けます。ファイル・システム・タイプを再び選択し、コネクター・モードを AddOnly (ファイル・システム・コネクターによってサポートされる唯一の出力モード) に設定します。

コネクター・リストでこのコネクターを選択した状態で、出力ファイルにOutput.xml という名前を付け、入力ファイルが入っているのと同じディレクトリーに書き込むことによって、接続パラメーターを構成します。


次に、「パーサー」タブをクリックして「XML パーサー」を選択します。


最後に、どの属性を XML 文書に書き込むかを XMLOutput コネクターに指示します。「コネクター属性」ボックス (これは空であるはずです) の上にある「出力マップ」タブをクリックし、Assembly Line (例えば作業項目) からコネクター (例えばconn 項目) に属性をマップして、コネクターがこれらの値を出力できるようにします。このコネクターは出力モード (AddOnly) に設定されているので、「入力マップ」タブは無効になっています。

マッピング用に選択可能な属性は、コネクター詳細ペインの左にある「作業項目」というリストに表示されているので便利です。


入力マッピングの場合と同じように、「作業項目」リストから「コネクター属性」というリストへ項目をドラッグします (前述のように、場合によってはタイトル・バーへドロップする必要があります)。


次に、6 ページで指定した mail 属性を追加する必要があります。この属性は入力ソース内には存在しないので、値を計算する必要があります。「作業項目」リストから、(First および Last を使用して計算した) FullName という属性があることを確認します。この値を使用して、処理する各項目の E メール・アドレスを作成します。ユーザーが複数の E メール・アドレスを持つのは珍しいことではないので、mail を多値の属性にして、2 つ作成することができます。

そのためには、コネクター属性リストの左上にある「新規属性を属性マップに追加」ボタンをクリックします。これで、新規属性の名前を指定するためのダイアログがオープンします。属性名を Mail にして、「OK」をクリックします。

リストで新規コネクターを選択します。「拡張マッピング」チェック・ボックスにチェックマークを付けて、次のスクリプトを入力します。

gn = work.getString("First");cn = work.getString("FullName");


この最初の 2 行では、First 属性および FullName 属性の値をローカル変数に格納します。work オブジェクトをどのように使用して AssemblyLine 内部のデータにアクセスするかを見てください。

var att = system.newAttribute("Mail");

次の行では、システム・コールを使用して新規属性を作成します。一時的な名前を付けます。ただし、できるだけマップ先の属性にちなんだ名前を付けてください。

att.addValue(gn + "@company.com");att.addValue(cn.replace(" ",".") + "@company.com");

この 2 行では、2 つの値を計算してこの属性に追加します。これで、この属性は複数値属性になります。.GetString() の戻り値は Java String オブジェクトなので、2

番目の行では Java String .replace() 関数を使用しています。この呼び出しは、名前のスペースをドットに置換するために使用されるので、「Peter Belamy」などの値は「Peter.Belamy」になります。

ret.value = att;

最後に、新しく作成された属性が戻され、IBM Tivoli Directory Integrator により、複雑なオブジェクトが出力ソースのフォーマットに変換されています。

最初のデータ・フロー・インプリメンテーションは、テストできる状態です。

AssemblyLine の実行AssemblyLine はもう完成し、いつでもテストできる状態です。AssemblyLine 詳細ウィンドウの上部にあるボタン・ツールバーの「実行」ボタンをクリックしてください。

IBM Tivoli Directory Integrator に AssemblyLine の実行を指示すると、システムは、サーバーのインスタンスを開始して、現行構成をそのインスタンスに示します。

注: サーバーを Toolkit IDE の外部から始動して、特定の構成を使用するように指示することもできます。

IBM Tivoli Directory Integrator は、ここで、ExecuteTask-AL という名前の新規ペインを作成し、そこに新規作成された AssemblyLine の開始のログを表示します。


指定の AssemblyLine の開始後にサーバーが停止したことを示しているだけの、最下部の Process exit code という行を除いて、このウィンドウの出力は、3 つの主要部分に分かれます。

v 実行中のサーバーのバージョンに関する情報

v IBM Tivoli Directory Integrator が実行されている環境の記述。これには、使用するように構成されている VM や、作業ディレクトリーも含まれています。

v 次のものを含む、ソリューションの開始方法に関する情報。

– サーバーを始動するために使用されたパラメーター

– 使用される構成 (この場合は、<stdin> として示されます。これは、IDE からランタイム・サーバーへ渡されたことを意味します)。

– AssemblyLine とそのコネクターの実行中に生成されたメッセージ

また、task.logmsg(″your _message_goes_here″) 機能など、スクリプトの記述時に使用できる特殊な IBM Tivoli Directory Integrator オブジェクトと機能を使用して、自分でログへメッセージを送信することもできます。

この最後のセクションの下部にあるのは、AssemblyLine (CSVtoXML) がエラーなく実行されたことを示すメッセージです。これは、前に指定した出力ファイルをオー


プンできることを意味します ( 33ページの『出力コネクターの追加』を参照)。このファイルを (たとえばブラウザーで) オープンすると、AssemblyLine が CSV 入力データを XML 文書に実際に変換したことを確認できます。

Mail 属性や FullName 属性もスクリプトの断片で計算され、表示されます。


ただし、項目の 1 つ (前の画面ショットに表示されている Roger) は未完成です。この項目には、Last および Title 属性が両方とも欠落しています。入力データ・ファイル (10 ページを参照) をチェックすると、これらの属性フィールドが入力 CSV

ファイルから実際に抜けていることが分かります。

最も簡単な解決策は、CSV ファイルを編集して、欠落しているフィールドを追加するという方法です。しかし、この方法で制御できるデータ・ソースは、ほとんどありません。したがって、この方法を取る代わりに、フックをスクリプトで指定して、入力をフィルターに掛けます。

注: AssemblyLine を変更する前に、以下のいずれかの方法で、まず作業を保管してください。

v メイン・ツールバーの「保管」ボタンをクリックする。

v メインメニューから「ファイル」->「保管」を選択する。

v Ctrl+S を押す。

フックの操作フックは、AssemblyLine とそのコネクターの実行時の中間地点であり、ここで独自のロジックを追加できます。ほとんどのフックはコネクターに関連するものですが、「AssemblyLine フック」タブに表示されるフックもいくつかあります。これらは、データ・フローのライフ・サイクルの開始時と終了時に始動されます。

1. プロローグが開始されます。

a. ライブラリー・スクリプトが AssemblyLine のグローバル・プロローグとして構成されている場合は、実行されます。

b. AssemblyLine プロローグ・フックは 2 つあります。1 つはコネクターがデータ・ソースへの接続を初期化する前に始動され、もう 1 つは初期化した後に始動されます。AssemblyLine とそのコネクターはスクリプトから制御できるので、コンポーネントの再構成やフロー自体の変更もできます。

c. これで、コネクターが初期化されます。

d. 初期化後、「プロローグ」というフックが使用可能になり、始動されます。

2. これで、データ・フローが開始され、制御が最初のコネクターに渡されます。処理が完了すると、ライン内の次のコネクターへ処理が渡され、最後のコネクターが処理を完了するまでそれが繰り返されます。AssemblyLine 内にイテレーター(イテレーター・モードのコネクターなど) がある場合、制御は先頭に戻り、AssemblyLine は次の項目に対して処理を繰り返します。コネクター・モードにはそれぞれ独自のフローが組み込まれていますが、これらには一貫性があり、関連するフックを共有します。例えば、ルックアップ・モード、更新モード、削除モードは、検索を処理するためすべて同じように結びつけられています (「フック」タブを表示させてモードを切り替えようとすると、それが分かります)。これらのフローの図形は、コネクター・モード・フロー・チャートの形式で参照できます。これらは、「IBM Tivoli Directory Integrator リファレンス・ガイド」で個別のクイック・リファレンス・ガイドとして記載されています。

3. すべての反復が完了すると (例えば、最後のイテレーターがデータの終わりに達すると)、AssemblyLine エピローグが実行されます。

4. 最後に、コネクターは接続を閉じます。


例に戻って、CSV 入力ファイルで欠落データを確認します。このデータ・ソースはInputPeople というコネクターによって処理されるので、このコネクターをコネクター・リストで選択し、次に、「フック」タブ (属性マップの隣) を選択します。ここで、フィルター操作ロジックを追加します。

各コネクターには 3 セットのフックがあり、フック・ツリー・リストにフォルダーとして表示されます。

プロローグ内このフォルダーには少なくとも 2 つのフックがあります。

v 1 つは、AssemblyLine プロローグ (初期化前) の後に実行されます。

v もう 1 つは、AssemblyLine プロローグ (初期化後) の直前に実行されます。

イテレーター・モードでは、コネクターが反復を開始するデータのビューを取得したときに、選択操作の前後に使用する追加フックも取得されます。

データ・フローAssemblyLine の繰り返しのたびに、つまりコネクターが実行されるたびに始動されるフックです。実行前やデフォルト・エラーなどのフックは、すべてのコネクター・モードに共通しています。その他のフックのほとんどは


モードに固有です。InputPeople コネクターはイテレーター・モードになっているので、GetNext 操作を何度も実行して入力データを検索することになります。イテレーター・モードでは、この読み取り操作をユーザー独自のロジックに組み込むことができるように、「GetNext 前」や「GetNext後」などのフックがあります。

エピローグ後これらのフックは、AssemblyLine のライフ・サイクルの最後、つまりAssemblyLine のエピローグの直後に 1 回開始されます。各コネクターは、AssemblyLine に表示されるのと同じ順序で、エピローグのサイクル (クローズ前、接続のクローズ、クローズ後) を通過します (フックを書くときには、その点に依存しないようにしてください)。

InputPeople コネクターを選択した状態で、リストの「After GetNext」フックをクリックします。フック・リストの右にある編集ウィンドウで、以下のスクリプトを入力してください。


注: ペインが小さすぎる場合 (スクリプト・エディターなど) は、セパレーター・バーをクリックしてドラッグし、サイズ変更してください。

sn = conn.getString("Last");title = conn.getString("Title");

最初の 2 行では、ロー・コネクター内で使用可能な 2 つの属性の値を取り出します。属性マッピングのところ (25 ページ) で説明したように、各コネクターは、データ操作のためにローカル・ストレージ・オブジェクトを使用します。このオブジェクトは、スクリプト変数 conn を介して参照されます。前の例では、「GetNext成功」フックまたは「デフォルト成功」フックを使用してフィルター操作を実行できます。これらのフックは入力属性マップの後に出現するので、これらの属性は作業項目にマップされます。スクリプトは work 変数を使用して記述できます。

if (sn == null || title == null){


Last または Title 属性の値として戻された値が NULL (入力データ・ソース内に存在していないことを示す) かどうかを確認します。NULL の場合は、その次の 3 行が開始されます。

注: 実動バージョンのこの AssemblyLine では、もっと多数のフィールドについて、存在の有無をテストすることができます。

task.logmsg("--> Record skipped (missing data)");

このタスク・オブジェクトにより、AssemblyLine 関数 (たとえば、AssemblyLine のログ・ファイルへの書き込みを実行する logmsg() など) にアクセスすることができます。

task.dumpEntry(conn);

今度は、AssemblyLine の (タスク) dumpEntry() 関数を使用して、ロー・コネクターのローカル・ストレージ・オブジェクト (conn) の内容をログ・ファイルに書き込みます。

注: Conn と work は同じタイプのオブジェクトなので、dumpEntry() などの関数はどちらでも同じように機能します。

system.skipEntry();}

最後にシステム・オブジェクトの skipEntry() 関数を使用して、IBM Tivoli Directory

Integrator に対し、この入力項目をスキップして AssemblyLine ループの先頭に戻って処理を再開し、次の入力項目を読み取るように指示します。

この行を再びテストする前に、出力属性マップを少し変更します。

スキーマの変換この例 (6 ページを参照) では、出力属性は入力ソース内の属性と同じ名前です。しかし、ここで少し寄り道をして、出力属性を FirstName および LastName という名前にするように指定した場合を考えてみましょう。

FirstName =DS1.FirstLastName =DS1.LastFullName =DS1.First+" "+DS1.LastTitle =DS1.TitleMail =<compute_from_name>

IBM Tivoli Directory Integrator では、スキーマ間の属性名のマッピングが容易です。ユーザーがしなければならないのは、出力コネクターの属性マップの中で、該当の属性の名前を直接更新することだけです。

XMLOutput コネクターを選択し、属性マップ内で変更する属性をクリックして、入力を開始します。


これが AssemblyLine のスクリプトに影響すると心配する必要はありません。これらの名前は、出力コネクターの属性マッピング・フェーズ用にローカルに変更されるだけです。First および Last 属性は、これまでと同様正しく読み取られ、AssemblyLine 内部で使用可能です。

注: IBM Tivoli Directory Integrator は、ユーザーが別のコネクターまたはAssemblyLine に切り替えた場合でも、ユーザーが現在入力操作をしているフィールドにフォーカスを置いているので、属性名の編集モードが継続されます。編集モードを終了するには、同じマップ内の別の属性をクリックするか、Enterキーを押して、作業を完了したことを IBM Tivoli Directory Integrator に知らせます。

これらの変更を (オリジナルの指定の一部ではなくても) 加えたままにして、AssemblyLine を再び実行してください。IBM Tivoli Directory Integrator が終了したら、出力ブラウザー・ウィンドウに戻って、「最新表示」ボタンをクリックします。このウィンドウをクローズしてしまっていた場合は、最初の実行の後で出力フ


ァイルをオープンするために使用したステップと同じステップを繰り返す必要があります ( 38ページの『AssemblyLine の実行』を参照)。

出力ファイルが再び表示されたら、Roger がもう表示されていないことを確認してください (Jill と Gregory の間にありました)。また、2 つの属性名が変更されていることにも注意してください。

構成を再び保管して (Ctrl+S を使用)、次のステップである、第 3 のデータ・ソースからのデータの収集に進みます。

結合コネクターの追加チュートリアル・ファイルには、お金を借りている人々の簡単なデータベースが含まれています。このソースを使用して、債務者に関する情報を出力 XML 文書に出してみましょう。

最初のステップは、AssemblyLine ツールバーで「追加」をクリックして、3 番目のコネクターを追加することです。このコネクターに Debtors という名前を付け、BTree Object DB コネクターを選択します。AssemblyLine 内部のデータと一致するレコードを探そうとしているので、このコネクターはルックアップにする必要があります。

リストに新規コネクターを追加すると、IBM Tivoli Directory Integrator は新規コネクターを AssemblyLine の最後にドロップします。しかし、これは成功しません。入力後 (反復)、出力コネクターの前に収集を実行する必要があるからです。

これを解決するには、Debtors コネクターを選択し、AssemblyLine データ・フロー・ツールバーの「上へ」ボタンをクリックします。


これにより、コネクターが 1 スロット分上に移動し、したがって InputPeople の後で XMLOutput の前に開始されます。ここで、このコネクターをセットアップするために「構成...」タブを選択します。


データ・ファイルのパス名を入力してください。これは、IBM Tivoli Directory

Integrator をどこにインストールしたかによって異なるので、上の図に示すパス名とは異なる場合もあります (データベース・ファイル自体の名前は、Debtors.dat であることに注意してください)。「キー属性名」フィールドに、これらのレコードを固有に識別する属性の名前を指定する必要があります。チュートリアル・データベースでは、これは FullName 属性です (入力コネクター内に類似した名前の属性を作成した理由のヒントがここにあります)。

このコネクターをテストする場合は、「スキーマ」タブを使用して、InputPeopleの場合と同じように「接続」ボタンと「次へ」ボタンをクリックします。または、


直接「入力マップ」タブへ進んで、便利な「高速ディスカバリー」ボタンを使用することもできます。

これにより、コネクターはソースに接続し、データ・セット上で単一の GetNext を実行して、戻された項目を調べます。ここで検出された属性は、「使用可能コネクター属性」ウィンドウに表示されるので、マッピングに使用できます。データ・ソースのスキーマで定義されたすべての属性が検出されるわけではありませんが (そのためには、「スキーマ」タブで「スキーマの発見 (Discover Schema)」ボタンを使用する必要があります)、ここでの作業を続行するのにはこれで十分です。


これで、属性マップをセットアップして、関連情報が AssemblyLine で使用可能にすることができます。「スキーマ」タブの隣のタブをクリックして「入力マップ」ペインに進み、「使用可能コネクター属性」のリストから、Amount およびDateOfLoan を「作業属性」ボックスにドラッグします。

注: 次のセクションで説明するように、このデータ・ソースの FullName フィールドを使用して、ルックアップの検索基準をセットアップします。ただし、検索に使用するための条件として、属性を属性マップに組み込まなければならないわけではありません。これは、データ・ソースで使用する必要があるだけです。

リンク基準のセットアップ新規に作成した Debtors コネクターは、ルックアップ・モードになっているので、データ・ソース内の特定の項目を検索し、すでに AssemblyLine 内部にある項目と一致するものを見つけようとします。この突き合わせをするための厳密な方法は、コネクターのリンク基準と呼ばれるものによってユーザーが指定します。

もうお気付きでしょうが、Debtors コネクターを追加したときに (そのモードがルックアップであることにも注意してください)、「出力マップ」という名前のタブの隣に、「リンク基準」という新しいタブが使用可能になっています。


このタブを選択すると、リンク基準画面が表示されます。この画面で、このコネクターがどのようにルックアップを実行するかを指定することができます。

IBM Tivoli Directory Integrator に、属性マップを直接スクリプト記述できる機能があることを思い出してください。ここでも、同じ原理が適用されます。「カスタム・スクリプトで基準を作成」チェック・ボックス (リンク基準ツールバーの横) にチェックマークを付けると、エディター・ウィンドウが表示され、データ・ソース固有のルックアップ呼び出しを書くことができます。ここで、JDBC コネクターの場合は SQL SELECT ステートメントを使用でき、ディレクトリーに接続されている場合は LDAP 検索呼び出しを使用できます。


しかし、属性マッピングの場合と同様に、IBM Tivoli Directory Integrator では、基礎となるデータ・ソース用の関連 API コマンドを作成できるので、テクノロジーからのソリューションの独立性を高めることができます。

「構成...」タブの下にある、リンク基準ツールバーの「新規リンク基準を追加します」ボタンをクリックしてください。

「リンク基準」ダイアログ・ボックスが表示されたら、IBM Tivoli Directory

Integrator がデータ・ソース内で発見したスキーマから、属性を選択します。次に、比較演算 (例えば equals または contains) を選択します。最後のフィールドには、比較すべき AssemblyLine 内部の属性を指定します。

完了したら、「OK」をクリックします。


注: AssemblyLine の FullName 属性の前にあるドル記号 ($) は、IBM Tivoli

Directory Integrator でこの属性の最初の値を検索して、リンク基準の作成に使用することを示します (属性は複数個の値を持っている場合もあります)。複数値属性の値のいずれかと一致するものを検索したい場合は、ドル記号の代わりにアットマーク (@) を使用します。

ダイアログがクローズされ、AssemblyLine 画面に戻ったら、XMLOutput コネクターを選択し、その属性マップを更新して、収集中の新規データをラインに組み込みます。「作業項目」ボックスから、新しい Amount 属性および DateOfLoan 属性を「コネクター属性」ボックスにドラッグします。


作業を保管し、AssemblyLine を再び実行します。どうなりましたか。

AssemblyLine がクラッシュしたはずです。これは、Debtor ルックアップ・コネクターがデータベース内で FullName 属性をキーとして項目を検索し、失敗したときの


状況を考慮に入れていなかったからです。幸いなことに、IBM Tivoli Directory

Integrator には、この状況を取り扱うための方法がいくつかあります。この例の場合は、フックをプログラミングしてこの問題に対処できます。

何をするかについては、ユーザーが決定する必要があります。

v Debtors.dat データベース内に該当項目がない場合もあるという事実を無視するという選択ができます。この場合は、無視するようにプログラムに指示すれば、出力にはすべての項目が含まれ、一部の項目には債務に関する情報があり、一部の項目にはその情報がないことになります。

v 債務のある人だけを検索することもできます。この場合は、表内に項目のない人(たとえば債務記録のない人) をスキップするように、システムに指示します。

どちらの場合も、「On No Match」と呼ばれるフックが Debtors コネクター内で使用可能にされます。

1. このコネクターの画面に進み、「フック」タブをクリックします。

2. ここに表示されるツリー・ビューで、「一致なしの場合」フックをクリックします。「スクリプト・エディター」ウィンドウが表示されます。

3. 「使用可能」チェック・ボックスにチェックマークを付け、作業を保管して、AssemblyLine を再び実行します。


フックを使用可能にするだけで、IBM Tivoli Directory Integrator に対し、一致するデータがルックアップ中に見付からない場合は何も実行しないように指示できます。

AssemblyLine を再実行すると、今度はクラッシュせず、ログ出力は次のようになります。


ここで、(InputPeople の「GetNext 後」フックで) フィルター操作スクリプトにコード化したメッセージと項目ダンプ、および今回はエラーが検出されなかったメッセージが表示されます。

注: 各項目の属性が表示される順序は無意味で、ユーザーのシステムに示される順序は、この文書の画面ショットに示されている順序とは異なる場合もあります。

XML 出力ファイルには、重要な変更もいくつか示されます。

v 組み込まれた 2 つの新規 Debtors フィールドが、出力に示されています。

v AssemblyLine はどの XML 項目にも債務の情報を検出しなかったので、XML 項目当たりの属性数が可変になっています。

データベース内で一致情報が検出されなかった場合、ルックアップ・コネクター(債務者) は、デフォルトで AssemblyLine エラー・ハンドラーを呼び出します。エラー・ハンドラーは、(処理を指定した特別のコードがないため) ただ単にフックから戻ります。ただし、エラー条件はハンドラーによりクリアされるので、一部の属


性が欠落しても処理は続けられます。これは、後で問題の原因になる場合もありますが、この状況では問題は起きていません。

債務がある人のみに関心がある場合はどうすればいいでしょう。その場合は、「債務者」コネクターの「一致なしの場合」フックにこのスクリプトの断片を追加する必要があります。

system.skipEntry();

初期入力の処理中に Roger がどのようにフィルタリングされたかを思い出してください。入力時にフィルタリングされた人に実際には債務があったという状況もありえますが、AssemblyLine は、これらのレコードについてそこまでは関知しません。


この方法の代わりに、最初のコネクター内に欠落属性用のデフォルト値を作成しておくことができます。IBM Tivoli Directory Integrator には、欠落値を取り扱うためのさまざまな方法が用意されています。

ここまでは、統合ソリューションを構成するシステムとデータ・フローの作成方法を見てきました。次に、IBM Tivoli Directory Integrator を使用してインフラストラクチャー内で変更イベントを検出およびディスパッチする方法について説明します。

EventHandlersIBM Tivoli Directory Integrator のコンポーネントの 3 番目 (最後) のタイプとして、EventHandler があります。名前が示しているように、このコンポーネントでは、リアルタイムのイベント・ドリブン統合ソリューションを作成できます。EventHandler を使用すると、システムやサービスにプラグインし、何らかのイベント通知を待つことができます。例には、POP3/IMAP メールボックスに到着するメール、FTP URL に表示されるファイル、ディレクトリーで作成された変更が含まれています。

EventHandler は、インターセプトしたイベントのタイプに基づいて任意の数のアクションを実行するように構成することができます。

v 1 つ以上のパーサーを介しての受信データの引き渡し

v AssemblyLine が動作するために必要なイベント・パラメーターでの AssemblyLine

の開始

v 外部プログラムまたはライブラリーの起動

つまり、イベントを解釈およびディスパッチするために実行させる必要のあるあらゆるアクションです。

その他のコンポーネントと同様に、ほとんどの EventHandler は同じように機能します。ただし、完全にスクリプトでインプリメントされたもの (汎用スレッドEventHandler など) や、構成のために特殊なインターフェースを必要とするもの(Web サービス EventHandler など) もあります。単純化するため、例では標準タイプの EventHandler を示します。

EventHandler は、イベントを取得すると、イベント・パラメーターを Java オブジェクトに変換し、それらをローカル・ストレージ・オブジェクトに保管します。このストレージ・オブジェクトは、前のセクションで使用した work オブジェクトやconn オブジェクトに似ています。EventHandler の場合、この Java バケットはイベントと呼ばれます。

これらのイベント・パラメーターに加えて、イベントから属性を受け取る場合もあります。例えば、LDAP ディレクトリーからの変更イベントの場合などです。データ内容とパラメーターが混合しないようにするため、これらのストレージ・オブジェクトはすべて (work や conn も含め)、データ値を属性に保持し、パラメーターをプロパティーに保持します。プロパティーは属性と同じようにデータ値を運びますが、常に一価であり、通常はストリングである点が異なります。項目オブジェクトをログにダンプすると (例えば、task.dumpEntry() 関数を使用して)、ログ出力に属性とプロパティーを表示するための個別のセクションが示されます。


さまざまなイベントに EventHandler がどう反応するかを定義するには、接続されたシステムから受信したプロパティーと属性の値に基づいて、条件とアクションの規則を作成します。通常、EventHandler は、イベントを伝送する 1 つ以上のAssemblyLine に制御をディスパッチするために使用されます。ただし、EventHandler ではスクリプトを使用でき、機能も数多く組み込まれているので、独自に多くの作業を実行することもできます。

最初に使いやすい EventHandler の 1 つとして、HTTP EventHandler があります。このコンポーネントを使用して簡単な Web サーバーを作成してみましょう。

examples/Tutorial ディレクトリーで、index.html と OtherPage.html の 2 つの新規ファイルを作成する必要があります。これらのファイルの内容については 77ページの『付録 A. index.html および OtherPage.html』を参照してください。

ブラウザーで index.html を開きます。


これはメイン Web ページであり、いくつかのリンクが組み込まれています。上部のリンクは 2 番目の Web ページ (OtherPage.html) を参照し、下部のリンクはStartAL を参照します。この最後のリンクは、構築した AssemblyLine を起動します。

最初の手順は、HTTP EventHandler を作成し、それを Web サーバーとして動作するように構成することです。ここで、「オブジェクト」->「新規 EventHandler」メニュー選択を使用するか、「構成」ブラウザーで「EventHandler」フォルダーを右マウス・ボタンでクリックしてコンテキスト・メニューから「新規EventHandler...」を選択することにより、新規 EventHandler を構成に追加します。この新規 EventHandler を WebServer と呼びます。

IBM Tivoli Directory Integrator によって、EventHandler 詳細画面が表示されます。


AssemblyLine 詳細ペインと同じように、EventHandler にも一連のタブがあります。

フック EventHandler には、AssemblyLine の場合と同じようなフックがあります。

v プロローグ

v エピローグ

v シャットダウン要求

EventHandler の「プロローグ」フックと「エピローグ」フックは、イベントが検出されるたびに開始されます。

アクション・マップアクション・マップでは、条件とアクションの規則を定義します。

構成システムまたはデバイスからのイベント通知には多数の EventHandler がサブスクライブしているので、接続パラメーターを構成する必要があります。

「構成」タブを選択し、HTTP EventHandler をセットアップすることによって開始します。


このタブでは、EventHandler タイプの変更、使用するスクリプト言語の選択、各種接続パラメーターの設定を実行できます。「HTTP ポート」パラメーターにこのポート番号を入力して、マシン上のポート 88 を listen するように EventHandler を構成します。「プロパティーとしてのヘッダー」チェック・ボックスを選択した場合、EventHandler はすべての TCP および HTTP ヘッダー値をプロパティーとしてイベント・オブジェクトに保管します。

次に、「アクション・マップ」タブについて説明します。


この画面は、「アクション・マップ」、「条件」、および「アクション項目」の 3

つのペインに分かれています。各ペインには、関連するリスト内で項目の順序を作成、削除、変更するためのボタンの行があります。

EventHandler は、イベントが発生するたびに次の手順を実行します。

1. 「プロローグ」フックが実行されます。

2. 最初の使用可能なアクション・マップ項目に制御が渡され、その条件が評価されます。

3. 条件が True に評価された場合 (またはこのアクション・マップ項目に対して条件が定義されていない場合) は、「条件が True の場合」タブのアクションが開始されます。False に評価された場合は、「条件が False の場合」のアクションが実行されます。エラーは、「エラー時」タブで処理します。

4. アクションが完了すると、制御は次のアクション・マップ項目に移動し、その項目に対してステップ 3 が繰り返されます。ただし、そのアクション・マップ項目に対して「残りをスキップ」チェック・ボックスが選択されている場合やアクションが 1 つでも実行された場合、このイベントの処理は停止され、制御は次のステップ (「エピローグ」) に渡されます。

5. 「エピローグ」フックが開始されます。


6. EventHandler は次のイベントを待ちます。

「新規アクション・マップ項目を追加します」ボタンを押し、この新規項目DumpEventToLog を呼び出すことによって、新規アクション・マップ項目を作成します。

このアクション・マップ項目に対しては条件を作成しません。したがって、EventHandler は常に、「条件が True の場合」タブで定義されたアクションを開始します。新規アクション・マップ項目を選択し、「条件が True の場合」タブを選択して新規アクションを追加します。


この画面ショットのアクション選択ダイアログ・ボックスに示されているように、いくつかの標準のアクションから選択することができます。

v 1 つ以上のパーサーの起動

v カスタム・スクリプトの書き込み

v イベントのプロパティーと属性の追加と除去

v AssemblyLine の実行

v EventHandler の停止

「イベント・オブジェクトのダンプ」アクションを選択して、「OK」を押します。これで、「実行」ボタンをクリックすると EventHandler をテストできます。

EventHandler がポート 88 で開始されたら、ブラウザー・ウィンドウを開いて次のURL をアドレス・フィールドに入力します。

http://localhost:88

ブラウザーには何も表示されませんが、IBM Tivoli Directory Integrator を再び始動すると、IBM Tivoli Directory Integrator に指示したとおりに、EventHandler によっ


てイベントが取得され、各種イベント・パラメーターがログへダンプされていることを確認できます。

イベント・オブジェクトの内容をダンプすると、イベントで戻されるパラメーターをすばやく視覚的に識別できます。これは、条件の定義で使用できます。これには、前の画面ショットで強調表示されている http.base プロパティーを使用します。EventHandler へ加えようとしている変更を有効にするには、赤い「停止」ボタンをクリックするか、「実行」ペインを閉じることによって、現在実行中のインスタンスを停止する必要があります。


EventHandler に戻り、新規アクション・マップを作成して、それに StartAL という名前を付けます。この新規アクション・マップ項目を選択し、「新規条件を追加します」ボタンをクリックします。

IBM Tivoli Directory Integrator を使用すると、カスタム・スクリプトで複雑な状態を処理することもできます。ここでは、その柔軟性は必要ないので、「単純条件」を選択します。次に、システムによって「条件」ダイアログが表示されます。


「属性/プロパティー名」フィールドに http.base と入力し、ドロップダウン・リストから contains 演算子を選択します。「値」フィールドに、引用符付きのテキスト ″StartAL″ を入力します。これは、EventHandler に対し、http.base プロパティーを調べてテキスト ″StartAL″ が含まれているかどうかを確認するよう指示します。「大文字小文字を区別」チェック・ボックスは選択していないので、この条件の結果には、大文字小文字は影響しません。

あとは、条件が一致したときに何を実行するかを EventHandler に指示するだけです。StartAL アクション・マップ項目がまだ選択されている状態で、「条件が Trueの場合」フォルダー・タブに新規アクションを追加し、「AssemblyLine の実行」アクションを選択します。


任意のアクションをダブルクリックすると、アクション詳細ダイアログが表示されます。


ドロップダウン・リストを使用して CSVtoXML AssemblyLine を選択し、「完了を待機」というチェック・ボックスをクリックします。このオプションを選択すると、EventHandler は AssemblyLine が完了するまで一時停止するので、うっかり並行して複数回 AssemblyLine を始動することがなくなります。このアクションの詳細を入力したら、「クローズ」ペイン・ボタンを使用してダイアログをクローズします (前の画面ショットの概略を参照してください)。

EventHandler を再始動します。始動するのを待ってから、ブラウザー・ウィンドウを開きます。同じマシンとポート番号 (http://localhost:88) にアクセスしますが、今回は URL の終わりに条件テキスト (startAL) を付加します。

http://localhost:88/startAL

ブラウザーが戻るために時間がかかるように感じられるかもしれません。これは、EventHandler が AssemblyLine を始動してから、それが完了するのを待つためです。IBM Tivoli Directory Integrator に戻ると、EventHandler がイベント・オブジェクトをダンプした後で AssemblyLine を実行したというログ出力が表示されます。


ここまで問題はありませんが、EventHandler はまだ Web サーバーのようには機能していません。この機能を追加するには、StartAL アクション・マップ項目の「条件が False の場合」タブにコードを追加する必要があります。その項目を選択した状態で、「カスタム・スクリプト」アクションを「条件が False の場合」タブに追加します (新規アクションをダブルクリックして詳細画面を開きます)。条件とアクションの間の仕切りバーを上へドラッグして、スクリプトを記述するスペースを作ることもできます。


このアクションのため、「スクリプト・エディター」ウィンドウに次のスクリプトを入力します。

// First we get the http.base property (returned as a Java String object).// The second line below defines a new variable with the full path to// where the Tutorial HTML files are located on your machine.//base = event.getProperty("http.base");path = "C:/Program Files/IBM/IBMDirectoryIntegrator/examples/Tutorial/";

// We can use the Java String endsWith() function to check the extension// of the file being requested by the browser. We then set the properties// for the HTTP message that the EventHandler will pass back to the browser.if ( base.endsWith(".gif") )event.setProperty ("http.content-type", "image/gif")elseif ( base.endsWith(".jpg") || base.endsWith(".jpeg") )

event.setProperty ("http.content-type", "image/jpeg")elseevent.setProperty ("http.content-type", "text/html");

// If this is a root or null request, add the name of our main Web// page ("index.html").if ( base == "/" )

base = "/" + "index.html";


// Now we create a new Java file object with the name of file// that was requested, and prepended with the path variable that// we created above.var file = new java.io.File(path + base);

// Here we write the name of the file to the log.task.logmsg ("File request: " + file );

// Finally, we can use the exists() function to see if the file was found.// If so, we pass it back in the http.body property. If not, we set the// status so that the browser will display the standard 404 error.if ( file.exists() )

event.setProperty ("http.body", file);else

event.setProperty ("http.status", "NOT FOUND");

これは、これまでで最も長い断片です。それでも、Web サーバーを構築したことを考えれば、それほどたいへんなコードではありません。EventHandler を再始動し、ブラウザーに http://localhost:88 と入力します。前に見た Web ページが表示されます。

実際には、EventHandler は 2 つのイベントを処理する必要があります。最初のイベントでは index.html ページを戻し、次のイベントでは、ブラウザーが HTML のレンダリングを開始したときに GIF イメージを検出してこれをサーバーから要求しています。ログ出力を調べると、この追加イベントを確認できます。

別のページをクリックしてから戻ってみてください。単純な Web サーバーでは、使用可能なすべてのページにサービスを提供します。存在しないファイルの URL

(例えば、http://localhost:88/BadPage.html) を入力すると、EventHandler はブラウザーに「ファイルが見つかりません」というエラーを戻します。


メインページの下部に、前に見た 2 番目のリンクがあります。その上にマウスを合わせると、それが URL http://localhost:/StartAL を参照していることが分かります。このリンクをクリックすると、前に定義した条件が一致し、AssemblyLine が始動します。

お疲れ様でした。以上で IBM Tivoli Directory Integrator の基本的なトレーニングは終わりです。これで、独自のソリューションの構築を検討し始めることができます。もちろん、ここまでに学んだこと以外にも、豊富な機能を探求していくことができます。すべての開発ツールに言えることですが、専門技術は経験によって培われるものですから、さっそく取り掛かってください。

まとめIBM Tivoli Directory Integrator を使用するとデータ・フローを迅速に簡単にビルドできますが、結果のソリューションの品質は、ユーザーの指定がどれだけ優れているかにかかっています。IBM Tivoli Directory Integrator は、実際には、ユーザーのビジョンを遮りイマジネーションを制限するプラットフォームやベンダー・テクノロジーによる目隠しを取り去ることによって、手助けをするのです。

統合の問題にデータ・フロー・レベルでアプローチすることで、複雑さを軽減できます。この結果、開発速度、ソリューションの正確性、堅固さ、保守容易性、その他多くの、全体にわたる利点が得られます。事実、単純化して解決をモットーにしてその観点から物事を考え始めると、ご使用のシステムとその統合の可能性がまったく新しい視点から見えてくるでしょう。

IBM Tivoli Directory Integrator は、ユーザー作成のソリューションが完成し配置された後も、長期にわたって効果をもたらし続けます。ビジネスおよび技術上の要件が変わるにつれて、IBM Tivoli Directory Integrator では、それらの新しい課題に合わせてソリューションを強化し拡張することができます。これこそ、IBM Tivoli

Directory Integrator の利点であるインクリメンタル・インプリメンテーションです。統合ソリューション (およびインフラストラクチャー) を、ニーズに合わせると同時に、それを配置する環境にも合わせながら、拡大することができます。

認識したものが現実です。そして、あなたの認識は、使用するツールセットによって形成 (および限定) されます。選択肢は単純です。このままずっと認識したままの現実を受け入れ、現在ご使用のツールに合わせるために統合インフラストラクチャーについて描いていたビジョンを徐々に削ってゆくか、あるいは、ツールを切り替えるかです。


付録 A. index.html および OtherPage.html

本書の例を完了するには、index.html と OtherPage.html の 2 つの新規ファイルを作成する必要があります。

これらのファイルは、examples/Tutorial ディレクトリーで作成する必要があります。

index.html次に、index.html ファイルの内容を示します。

このコードを、例えばノートパッドなどの平面エディターにコピーして貼り付け、そのファイルを index.html として保管してください。

<html><head><title>IBM Tivoli Directory Integrator</title></head><body><h1>This sample website is powered by<br>IBM Tivoli Directory Integrator</h1><br><br><br><br>Click <a href="OtherPage.html">here</a>to go to the other page.<br><br><br><br>Click <a href="StartAL">here</a> to runour <i>Tutorial1</i> AssemblyLine. </body> </html>

OtherPage.html次に、OtherPage.html ファイルの内容を示します。

このコードを、例えばノートパッドなどの平面エディターにコピーして貼り付け、そのファイルを OtherPage.html として保管してください。

<html><head><title>IBM Tivoli Directory Integrator - Page 2</title></head><body><h1>...and this is the other page.</h1></div> <br><br><br><br><br><br>Click <a href="index.html">here</a>to go to back to the main page.</body></html>



付録 B. 特記事項

本書は米国 IBM が提供する製品およびサービスについて作成したものであり、米国以外の国においては本書で述べる製品、サービス、またはプログラムを提供しない場合があります。日本で利用可能な製品、サービス、および機能については、日本 IBM の営業担当員にお尋ねください。本書で IBM 製品、プログラム、またはサービスに言及していても、その IBM 製品、プログラム、またはサービスのみが使用可能であることを意味するものではありません。これらに代えて、IBM の知的所有権を侵害することのない、機能的に同等の製品、プログラム、またはサービスを使用することができます。ただし、IBM 以外の製品とプログラムの操作またはサービスの評価および検証は、お客様の責任で行っていただきます。

IBM は、本書に記載されている内容に関して特許権（特許出願中のものを含む）を保有している場合があります。本書の提供は、お客様にこれらの特許権について実施権を許諾することを意味するものではありません。実施権についてのお問い合わせは、書面にて下記宛先にお送りください。

〒106-0032

東京都港区六本木 3-2-31

IBM World Trade Asia Corporation

Licensing

以下の保証は、国または地域の法律に沿わない場合は、適用されません。IBM およびその直接または間接の子会社は、本書を特定物として現存するままの状態で提供し、商品性の保証、特定目的適合性の保証および法律上の瑕疵担保責任を含むすべての明示もしくは黙示の保証責任を負わないものとします。国または地域によっては、法律の強行規定により、保証責任の制限が禁じられる場合、強行規定の制限を受けるものとします。

この情報には、技術的に不適切な記述や誤植を含む場合があります。本書は定期的に見直され、必要な変更は本書の次版に組み込まれます。IBM は予告なしに、随時、この文書に記載されている製品またはプログラムに対して、改良または変更を行うことがあります。

本書において IBM 以外の Web サイトに言及している場合がありますが、便宜のため記載しただけであり、決してそれらの Web サイトを推奨するものではありません。それらの Web サイトにある資料は、この IBM 製品の資料の一部ではありません。それらの Web サイトは、お客様の責任でご使用ください。

IBM は、お客様が提供するいかなる情報も、お客様に対してなんら義務も負うことのない、自ら適切と信ずる方法で、使用もしくは配布することができるものとします。

本プログラムのライセンス保持者で、(i) 独自に作成したプログラムとその他のプログラム（本プログラムを含む）との間での情報交換、および (ii) 交換された情報の相互利用を可能にすることを目的として、本プログラムに関する情報を必要とする方は、下記に連絡してください。


IBM CorporationDepartment MU5A4611301 Burnet RoadAustin, TX 78758U.S.A.

本プログラムに関する上記の情報は、適切な使用条件の下で使用することができますが、有償の場合もあります。

本書で説明されているライセンス・プログラムまたはその他のライセンス資料は、IBM 所定のプログラム契約の契約条項、IBM プログラムのご使用条件、またはそれと同等の条項に基づいて、IBM より提供されます。

この文書に含まれるいかなるパフォーマンス・データも、管理環境下で決定されたものです。そのため、他の操作環境で得られた結果は、異なる可能性があります。一部の測定が、開発レベルのシステムで行われた可能性がありますが、その測定値が、一般に利用可能なシステムのものと同じである保証はありません。さらに、一部の測定値が、推定値である可能性があります。実際の結果は、異なる可能性があります。お客様は、お客様の特定の環境に適したデータを確かめる必要があります。

IBM 以外の製品に関する情報は、その製品の供給者、出版物、もしくはその他の公に利用可能なソースから入手したものです。IBM は、それらの製品のテストは行っておりません。したがって、他社製品に関する実行性、互換性、またはその他の要求については確証できません。IBM 以外の製品の性能に関する質問は、それらの製品の供給者にお願いします。

本書には、日常の業務処理で用いられるデータや報告書の例が含まれています。より具体性を与えるために、それらの例には、個人、企業、ブランド、あるいは製品などの名前が含まれている場合があります。これらの名称はすべて架空のものであり、名称や住所が類似する企業が実在しているとしても、それは偶然にすぎません。

著作権使用許諾:

本書には、様々なオペレーティング・プラットフォームでのプログラミング手法を例示するサンプル・アプリケーション・プログラムがソース言語で掲載されています。お客様は、サンプル・プログラムが書かれているオペレーティング・プラットフォームのアプリケーション・プログラミング・インターフェースに準拠したアプリケーション・プログラムの開発、使用、販売、配布を目的として、いかなる形式においても、IBM に対価を支払うことなくこれを複製し、改変し、配布することができます。このサンプル・プログラムは、あらゆる条件下における完全なテストを経ていません。従って IBM は、これらのサンプル・プログラムについて信頼性、利便性もしくは機能性があることをほのめかしたり、保証することはできません。お客様は、IBM のアプリケーション・プログラミング・インターフェースに準拠したアプリケーション・プログラムの開発、使用、販売、配布を目的として、いかなる形式においても、IBM に対価を支払うことなくこれを複製し、改変し、配布することができます。

それぞれの複製物、サンプル・プログラムのいかなる部分、またはすべての派生的創作物にも、次のように、著作権表示を入れていただく必要があります。


© (お客様の会社名) (西暦年). このコードの一部は、IBM Corp. のサンプル・プログラムから取られています。© Copyright IBM Corp. _年を入れる_. All rights

reserved.

この情報をソフトコピーでご覧になっている場合は、写真やカラーの図表は表示されない場合があります。

第三者コンポーネントについて

Apache についてこの製品には、Apache Software Foundation (http://www.apache.org/) により開発されたソフトウェアが含まれています。Apache のコンポーネントには、Xerces、Xalan、XML4J、および Log4J ライブラリーがあり、すべてオブジェクト・コード形式で提供されています。このオブジェクト・コードは、Apache Web サイトから取得されたもので、変更されていません。

Apache licenseApache Software License, Version 1.1

Copyright (c) 1999-2002 The Apache Software Foundation. All rights reserved.

ソースおよびバイナリー形式での再配布および使用は、変更の有無に拘らず、次の条件を満たす場合に許可されます。

1. ソース・コードを再配布する場合には、上記の著作権表示、この使用条件および以下の免責表示を含める必要があります。

2. バイナリー形式で再配布する場合には、上記の著作権表示、以下の使用条件および免責表示を、配布に際して提供する関連文書および資料に記載する必要があります。

3. The end-user documentation included with the redistribution, if any, must include

the following acknowledgment: ″This product includes software developed by the

Apache Software Foundation (http://www.apache.org/).″ Alternately, this

acknowledgment may appear in the software itself, if and wherever such third-party

acknowledgments normally appear.

4. The names ″Xerces″, ″Xalan″, ″log4j″, ″mx4j″ and ″Apache Software Foundation″must not be used to endorse or promote products derived from this software

without prior written permission. For written permission, please contact

[email protected].

5. Products derived from this software may not be called ″Apache″, nor may

″Apache″ appear in their name, without prior written permission of the Apache

Software Foundation.

THIS SOFTWARE IS PROVIDED ″AS IS″ AND ANY EXPRESSED OR IMPLIED

WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED

WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR

PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE APACHE SOFTWARE

FOUNDATION OR ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT,

INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL

付録 B. 特記事項 81

DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF

SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR

BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF

LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT

(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF

THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF

SUCH DAMAGE.

This software consists of voluntary contributions made by many individuals on behalf

of the Apache Software Foundation. For more information on the Apache Software

Foundation, please see http://www.apache.org

Rhino についてIBM Tivoli Directory Integrator では、Rhino (JavaScript for Java) オブジェクト・コードを使用しています。Rhino のソース・コードは、http://www.mozilla.org/rhino/download.html にあり、Netscape Public License 1.1

(http://www.mozilla.org/MPL/NPL-1.1.html) の許諾条件に基づき使用を許可されています。IBM Tivoli Directory Integrator で使用するオブジェクト・コードの生成時に、mozilla Web サイトにある Rhino ソース・コードは変更されてはいません。

商標以下は、IBM Corporation の商標です。

IBM DB2 Notes Lotus Domino Tivoli

Java およびすべての Java 関連の商標およびロゴは、Sun Microsystems, Inc. の米国およびその他の国における商標または登録商標です。

Microsoft および Windows は、Microsoft Corporation の米国およびその他の国における商標です。

UNIX は、The Open Group の米国およびその他の国における登録商標です。

他の会社名、製品名およびサービス名等はそれぞれ各社の商標です。


��

Printed in Japan

SC88-9900-00

Documents

IBM Tivoli Directory Integrator 5.2: スタートアップ …publib.boulder.ibm.com/tividd/td/IBMDI/SC32-1382-00/ja...まえがき 本書では、IBM ®Tivoli Directory Integrator

IBM Tivoli Directory Integrator 5.2: スタートアップ …publib.boulder.ibm.com/tividd/td/IBMDI/SC32-1382-00/ja...まえがき本書では、IBM ®Tivoli Directory Integrator