IBM Tivoli Directory Integrator 5.2...

IBM Tivoli Directory Integrator 5.2リファレンス・ガイド

SC88-9897-00

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

��

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

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

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

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

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

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

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

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

　原　典： SC32–1377–00

IBM Tivoli Directory Integrator 5.2:

Reference 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 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

第 2 章コネクター . . . . . . . . . . 3コネクターの可用性およびリファレンス . . . . . 3ロー・コネクター . . . . . . . . . . . . 3スクリプト・ベースのコネクター . . . . . . 5構成 . . . . . . . . . . . . . . . . 5

BTree オブジェクト DB コネクター . . . . . . 5構成 . . . . . . . . . . . . . . . . 6BTree オブジェクト . . . . . . . . . . . 6

コマンド行コネクター . . . . . . . . . . . 7構成 . . . . . . . . . . . . . . . . 7例 . . . . . . . . . . . . . . . . . 7

直接 TCP/URL スクリプト . . . . . . . . . 7TCP . . . . . . . . . . . . . . . . 7URL . . . . . . . . . . . . . . . . 8

Domino ユーザー・コネクター . . . . . . . . 8Domino Server の展開と接続 . . . . . . . . 9構成 . . . . . . . . . . . . . . . . 10セキュリティー . . . . . . . . . . . . 11Domino コネクターの使用 . . . . . . . . 11Domino ユーザー属性 (ユーザー文書項目) のリスト . . . . . . . . . . . . . . . . 20Domino Server 6.0 for AIX/Linux/Solaris . . . . 22例 . . . . . . . . . . . . . . . . 23関連情報 . . . . . . . . . . . . . . 23

ファイル・システム・コネクター . . . . . . . 23構成 . . . . . . . . . . . . . . . . 23関連情報 . . . . . . . . . . . . . . 23

FTP クライアント・コネクター. . . . . . . . 24構成 . . . . . . . . . . . . . . . . 24関連情報 . . . . . . . . . . . . . . 24

旧 HTTP クライアント・コネクター . . . . . . 25モード . . . . . . . . . . . . . . . 25特殊属性 . . . . . . . . . . . . . . 26構成 . . . . . . . . . . . . . . . . 27例 . . . . . . . . . . . . . . . . 27関連情報 . . . . . . . . . . . . . . 27

HTTP クライアント・コネクター . . . . . . . 28モード . . . . . . . . . . . . . . . 28特殊属性 . . . . . . . . . . . . . . 29構成 . . . . . . . . . . . . . . . . 30例 . . . . . . . . . . . . . . . . 31

関連情報 . . . . . . . . . . . . . . 31旧 HTTP サーバー・コネクター . . . . . . . 31構成 . . . . . . . . . . . . . . . . 32関連情報 . . . . . . . . . . . . . . 32

HTTP サーバー・コネクター . . . . . . . . 32構成 . . . . . . . . . . . . . . . . 33関連情報 . . . . . . . . . . . . . . 33

JDBC コネクター . . . . . . . . . . . . 33構成 . . . . . . . . . . . . . . . . 34リンク基準 . . . . . . . . . . . . . 35その他 . . . . . . . . . . . . . . . 35タイム・スタンプ . . . . . . . . . . . 35SQL データベース: 特殊文字を含む列名 . . . . 36準備済みステートメントの使用 . . . . . . . 36複数項目時 . . . . . . . . . . . . . 36ODBC: データベース・パスの直接指定 . . . . 36

JMS コネクター . . . . . . . . . . . . . 37JMS メッセージ・フロー . . . . . . . . . 37JMS メッセージのタイプ . . . . . . . . . 38イテレーター・モード . . . . . . . . . . 40CallReply モード. . . . . . . . . . . . 40ルックアップ・モード . . . . . . . . . . 40JMS のヘッダーとプロパティー . . . . . . 41構成 . . . . . . . . . . . . . . . . 43例 . . . . . . . . . . . . . . . . 45特定トピック . . . . . . . . . . . . . 45SSL の使用可能化 . . . . . . . . . . . 46

JNDI コネクター . . . . . . . . . . . . 46構成 . . . . . . . . . . . . . . . . 46変更操作の設定 . . . . . . . . . . . . 48関連情報 . . . . . . . . . . . . . . 50

LDAP コネクター . . . . . . . . . . . . 50構成 . . . . . . . . . . . . . . . . 51LDAP コネクターでのメモリーの問題の取り扱い 54LDAP コネクターの更新情報 . . . . . . . 55アクティブな非 LDAP ポートへの接続時の問題 57関連情報 . . . . . . . . . . . . . . 58IBM ディレクトリー変更ログ・コネクター . . . 58Netscape/iPlanet 変更ログ・コネクター . . . . 59Active Directory 変更ログ・コネクター . . . . 60Exchange 変更ログ・コネクター . . . . . . 66

Lotus Notes コネクター . . . . . . . . . . 73既知の制限事項 . . . . . . . . . . . . 73セッション・タイプ . . . . . . . . . . 74接続 . . . . . . . . . . . . . . . . 75構成 . . . . . . . . . . . . . . . . 75セキュリティー . . . . . . . . . . . . 76

メールボックス・コネクター . . . . . . . . 77構成 . . . . . . . . . . . . . . . . 78事前定義済みのプロパティーおよび属性 . . . . 78関連情報 . . . . . . . . . . . . . . 79

© Copyright IBM Corp. 2002, 2003 v

メモリー・ストリーム・コネクター . . . . . . 79構成 . . . . . . . . . . . . . . . . 80

MQe パスワード・ストア・コネクター . . . . . 80MQe パスワード・ストア・コネクター項目の構造 . . . . . . . . . . . . . . . . 81構成 . . . . . . . . . . . . . . . . 81

NT4 コネクター . . . . . . . . . . . . . 82前提条件 . . . . . . . . . . . . . . 82文字セット . . . . . . . . . . . . . 86例 . . . . . . . . . . . . . . . . 86NT4 コネクターの機能仕様とソフトウェア要件 86

RDBMS 変更ログ・コネクター . . . . . . . . 88構成 . . . . . . . . . . . . . . . . 88変更表の形式 . . . . . . . . . . . . . 89DB2 での変更表の作成 . . . . . . . . . 90Oracle での変更表の作成 . . . . . . . . . 90

ランタイム提供コネクター . . . . . . . . . 91構成 . . . . . . . . . . . . . . . . 92関連情報 . . . . . . . . . . . . . . 92

スクリプト・コネクター . . . . . . . . . . 92定義済みスクリプト・オブジェクト . . . . . 93関数 . . . . . . . . . . . . . . . . 93構成 . . . . . . . . . . . . . . . . 94例 . . . . . . . . . . . . . . . . 94関連情報 . . . . . . . . . . . . . . 94

SNMP コネクター . . . . . . . . . . . . 94構成 . . . . . . . . . . . . . . . . 95例 . . . . . . . . . . . . . . . . 95

TCP コネクター . . . . . . . . . . . . . 96イテレーター・モード . . . . . . . . . . 96AddOnly モード . . . . . . . . . . . . 96構成 . . . . . . . . . . . . . . . . 97関連情報 . . . . . . . . . . . . . . 97

URL コネクター . . . . . . . . . . . . . 97構成 . . . . . . . . . . . . . . . . 97サポートされる URL プロトコル . . . . . . 97関連情報 . . . . . . . . . . . . . . 98

Web サービス・コネクター . . . . . . . . . 98Web サービス・コネクターの使用 . . . . . . 98構成 . . . . . . . . . . . . . . . 100エラー時フック . . . . . . . . . . . . 100サポートされるスキーマ/ネーム・スペースのタイプ . . . . . . . . . . . . . . . 100

第 3 章 EventHandler. . . . . . . . 101EventHandler のタイプ . . . . . . . . . . 101どのようなときに始動されるか . . . . . . . 101EventHandler の働き . . . . . . . . . . . 102データ・フロー . . . . . . . . . . . . . 102AssemblyLine への入出力ファイル名の引き渡し . . 102EventHandler の可用性 . . . . . . . . . . 103Active Directory 変更ログ EventHandler . . . . . 103動作 . . . . . . . . . . . . . . . 104ユーザー・プロパティー・ストア内の USN 同期値へのアクセス . . . . . . . . . . . . 104

ランタイム EventHandler の USN 同期値へのアクセス . . . . . . . . . . . . . . . 105構成 . . . . . . . . . . . . . . . 105

コネクター EventHandler. . . . . . . . . . 107構成 . . . . . . . . . . . . . . . 107オブジェクト/プロパティー/属性 . . . . . . 107関連情報 . . . . . . . . . . . . . . 107

DSMLv2 EventHandler . . . . . . . . . . 108移送 (バインディング) . . . . . . . . . 108操作 . . . . . . . . . . . . . . . 108構成 . . . . . . . . . . . . . . . 111

Exchange 変更ログ EventHandler . . . . . . . 114動作 . . . . . . . . . . . . . . . 114ユーザー・プロパティー・ストア内の USN 同期値へのアクセス . . . . . . . . . . . . 114ランタイム EventHandler の USN 同期値へのアクセス . . . . . . . . . . . . . . . 115構成 . . . . . . . . . . . . . . . 116

HTTP EventHandler . . . . . . . . . . . 117例 . . . . . . . . . . . . . . . . 118構成 . . . . . . . . . . . . . . . 118関連情報 . . . . . . . . . . . . . . 119

IBM Directory Server EventHandler . . . . . . 119構成 . . . . . . . . . . . . . . . 120関連情報 . . . . . . . . . . . . . . 122

JMX EventHandler . . . . . . . . . . . . 122動作の説明 . . . . . . . . . . . . . 122EventHandler の使用 . . . . . . . . . . 122IBM Tivoli Directory Integrator の通知タイプ 123JMX システムの通知タイプ . . . . . . . 124構成 . . . . . . . . . . . . . . . 124通知タイプの動的追加/除去 . . . . . . . . 125

LDAP EventHandler . . . . . . . . . . . 126オブジェクト追加 (_objAdded) . . . . . . . 127オブジェクト名前変更 (_objRenamed) . . . . 127オブジェクト変更 (_objModified) . . . . . . 127オブジェクト除去 (_objRemoved) . . . . . . 128エラー検出 (_handleError) . . . . . . . . 128構成 . . . . . . . . . . . . . . . 128関連情報 . . . . . . . . . . . . . . 130

LDAP サーバー EventHandler . . . . . . . . 130スクリプト . . . . . . . . . . . . . 130LDAP メッセージ戻り値のリターン . . . . . 130エラー処理 . . . . . . . . . . . . . 131構成 . . . . . . . . . . . . . . . 131

メールボックス EventHandler . . . . . . . . 131構成 . . . . . . . . . . . . . . . 132オブジェクト/プロパティー/属性 . . . . . . 132例 . . . . . . . . . . . . . . . . 133関連情報 . . . . . . . . . . . . . . 133

SNMP EventHandler . . . . . . . . . . . 133希望するアクションのスクリプト記述 . . . . 134エラー処理 . . . . . . . . . . . . . 134SNMP パケット戻り値のリターン . . . . . 134構成 . . . . . . . . . . . . . . . 135

TCP ポート EventHandler . . . . . . . . . 135

vi IBM Tivoli Directory Integrator 5.2 リファレンス・ガイド

構成 . . . . . . . . . . . . . . . 135オブジェクト/プロパティー/属性 . . . . . . 136例 . . . . . . . . . . . . . . . . 136関連情報 . . . . . . . . . . . . . . 136

汎用スレッド (プリミティブ EventHandler) . . . 136構成 . . . . . . . . . . . . . . . 136関連情報 . . . . . . . . . . . . . . 137

タイマー EventHandler (プリミティブ EventHandler) 137構成 . . . . . . . . . . . . . . . 137例 . . . . . . . . . . . . . . . . 138

Web サービス EventHandler . . . . . . . . 138AssemblyLine と WSDL のマッピング . . . . 138EventHandler の使用 . . . . . . . . . . 141Web サービス EventHandler の処理シーケンス 141構成 . . . . . . . . . . . . . . . 143WSDL のホスティング . . . . . . . . . 144WSDL の自動生成 . . . . . . . . . . . 144

zOS LDAP 変更ログ EventHandler . . . . . . 145構成 . . . . . . . . . . . . . . . 146ポーリング・ロジック . . . . . . . . . 147

第 4 章パーサー . . . . . . . . . . 149基本パーサー . . . . . . . . . . . . . 149文字エンコード変換 . . . . . . . . . . . 149可用性 . . . . . . . . . . . . . . . 150

CSV パーサー . . . . . . . . . . . . . 150構成 . . . . . . . . . . . . . . . 150

DSML パーサー . . . . . . . . . . . . 151構成 . . . . . . . . . . . . . . . 151例 . . . . . . . . . . . . . . . . 151関連情報 . . . . . . . . . . . . . . 152

固定パーサー . . . . . . . . . . . . . 152構成 . . . . . . . . . . . . . . . 152

HTTP パーサー . . . . . . . . . . . . . 153構成 . . . . . . . . . . . . . . . 153属性またはプロパティー . . . . . . . . . 153関連情報 . . . . . . . . . . . . . . 155

LDIF パーサー . . . . . . . . . . . . . 155構成 . . . . . . . . . . . . . . . 155関連情報 . . . . . . . . . . . . . . 156

行リーダー・パーサー . . . . . . . . . . 156構成 . . . . . . . . . . . . . . . 157

スクリプト・パーサー . . . . . . . . . . 157オブジェクト . . . . . . . . . . . . 157関数 . . . . . . . . . . . . . . . 158構成 . . . . . . . . . . . . . . . 159例 . . . . . . . . . . . . . . . . 159関連情報 . . . . . . . . . . . . . . 159

単純パーサー . . . . . . . . . . . . . 159構成 . . . . . . . . . . . . . . . 159

SOAP パーサー. . . . . . . . . . . . . 160項目の例 . . . . . . . . . . . . . . 160SOAP 文書の例. . . . . . . . . . . . 160構成 . . . . . . . . . . . . . . . 160パーサー固有の呼び出し . . . . . . . . . 161例 . . . . . . . . . . . . . . . . 161

XML パーサー . . . . . . . . . . . . . 162構成 . . . . . . . . . . . . . . . 163例 . . . . . . . . . . . . . . . . 163例 . . . . . . . . . . . . . . . . 165関連情報 . . . . . . . . . . . . . . 165

ユーザー定義パーサー . . . . . . . . . . 165

第 5 章スクリプト言語 . . . . . . . 167BSF ベースのスクリプト言語 . . . . . . . . 167WSH ベースのスクリプト言語. . . . . . . . 167BeanShell . . . . . . . . . . . . . . . 167PerlScript . . . . . . . . . . . . . . . 168

PerlScript の例 . . . . . . . . . . . . 169VBScript . . . . . . . . . . . . . . . 169JavaScript . . . . . . . . . . . . . . . 169Java および JavaScript . . . . . . . . . . 170

第 6 章オブジェクト . . . . . . . . 171AssemblyLine コネクター・オブジェクト . . . . 171属性オブジェクト . . . . . . . . . . . . 171例 . . . . . . . . . . . . . . . . 171関連情報 . . . . . . . . . . . . . . 172

ロー・コネクター・オブジェクト . . . . . . . 172メソッド . . . . . . . . . . . . . . 172

項目オブジェクト . . . . . . . . . . . . 173スクリプトの中で使用できるグローバル項目インスタンス . . . . . . . . . . . . . . 173関連情報 . . . . . . . . . . . . . . 174

FTP オブジェクト . . . . . . . . . . . . 174例 . . . . . . . . . . . . . . . . 174

メイン・オブジェクト . . . . . . . . . . 175検索 (基準) オブジェクト . . . . . . . . . 175オペランド . . . . . . . . . . . . . 175例 . . . . . . . . . . . . . . . . 175

shellCommand オブジェクト . . . . . . . . 176状況オブジェクト . . . . . . . . . . . . 176システム・オブジェクト . . . . . . . . . . 176タスク・オブジェクト . . . . . . . . . . 176

付録 A. パスワード同期プラグイン. . . 177

付録 B. AssemblyLine およびコネクター・モードのフローチャート . . . . . 181AssemblyLine フロー . . . . . . . . . . . 182コネクターの初期化 . . . . . . . . . . 185クローズ・フロー . . . . . . . . . . . 186

AddOnly モード . . . . . . . . . . . . 186Call/Reply モード . . . . . . . . . . . . 188削除モード . . . . . . . . . . . . . . 190複数項目時 . . . . . . . . . . . . . 191

イテレーター・モード . . . . . . . . . . 195ルックアップ・モード . . . . . . . . . . 197複数項目時 . . . . . . . . . . . . . 198

更新モード . . . . . . . . . . . . . . 201複数項目時 . . . . . . . . . . . . . 201

すべてのモードの場合のフローの終わり . . . . 208

目次 vii

フロー終わり . . . . . . . . . . . . 209エラー処理 . . . . . . . . . . . . . 209

付録 C. MOBJ 管理エンジン . . . . . 213JMX MBean Server オブジェクト. . . . . . . 213MOBJ オブジェクト . . . . . . . . . . . 213

付録 D. 特記事項 . . . . . . . . . . 215第三者コンポーネントについて . . . . . . . 217

Apache について . . . . . . . . . . . 217Rhino について . . . . . . . . . . . . 218

商標 . . . . . . . . . . . . . . . . 218

viii IBM Tivoli Directory Integrator 5.2 リファレンス・ガイド

第 1 章概要

本書の内容を補足する各種の例を利用するには、インストール・パッケージを参照して必要なファイルをダウンロードする必要があります。

これらの実例ファイルは、インストール・ディレクトリー内のroot_directory/examples ディレクトリーにあります。

© Copyright IBM Corp. 2002, 2003 1

2 IBM Tivoli Directory Integrator 5.2 リファレンス・ガイド

第 2 章コネクター

コネクターの可用性およびリファレンス以下に、IBM Tivoli Directory Integrator に組み込まれているすべてのロー・コネクター (および AssemblyLine コネクター) をリストします。

必要があれば、ユーザー独自のロー・コネクターも作成できます (AssemblyLine はこれらのコネクターをラップして、AssemblyLine コネクターとして使用できるようにします)。

以下に示すすべての AssemblyLine コネクターは、ロー・コネクターのメソッドおよびプロパティーに加えて、com.ibm.di.server.AssemblyLineComponent で記述されているメソッドにアクセスできます。

ロー・コネクターサポートされるモードのリストについては、 5ページの『サポートされるモードの欄の凡例』を参照してください。

以下に示す各ロー・コネクターについては、この章に示す概要説明を参照してください。

5ページの『BTree オブジェクト DB コネクター』A D I L U

7ページの『コマンド行コネクター』A I

7ページの『直接 TCP/URL スクリプト』?????

8ページの『Domino ユーザー・コネクター』A D I L U

23ページの『ファイル・システム・コネクター』A I

24ページの『FTP クライアント・コネクター』A I

25ページの『旧 HTTP クライアント・コネクター』A D I L U C

28ページの『HTTP クライアント・コネクター』A I L C

31ページの『旧 HTTP サーバー・コネクター』A D I L U C

32ページの『HTTP サーバー・コネクター』A I


33ページの『JDBC コネクター』A D I L U

37ページの『JMS コネクター』A I L C

46ページの『JNDI コネクター』A D I L U

50ページの『LDAP コネクター』A D I L U

58ページの『IBM ディレクトリー変更ログ・コネクター』I

59ページの『Netscape/iPlanet 変更ログ・コネクター』I

60ページの『Active Directory 変更ログ・コネクター』I

66ページの『Exchange 変更ログ・コネクター』I

73ページの『Lotus Notes コネクター』A D I L U

77ページの『メールボックス・コネクター』I L D

79ページの『メモリー・ストリーム・コネクター』A I

80ページの『MQe パスワード・ストア・コネクター』I

82ページの『NT4 コネクター』A D I L U

88ページの『RDBMS 変更ログ・コネクター』I

91ページの『ランタイム提供コネクター』? ? ? ? ?

ランタイム提供コネクターは、AssemblyLine の始動時にパラメーターとして AssemblyLine に送られるコネクターです。このコネクターがどのモードをサポートするかは確定できません。 91ページの『ランタイム提供コネクター』を参照してください。

92ページの『スクリプト・コネクター』A D I L U C

スクリプト・コネクターはユーザー自身が作成するものであり、ユーザーがスクリプトに書き込んだモードを提供します。

94ページの『SNMP コネクター』I A L


96ページの『TCP コネクター』I A

97ページの『URL コネクター』I A

98ページの『Web サービス・コネクター』C

サポートされるモードの欄の凡例v A: AddOnly

v D: 削除

v I: イテレーター

v L: ルックアップ

v U: 更新

v C: Call/Reply

v ?: 条件付きでサポートされます (資料を参照)。

v +: 新しいバージョンのサポートが存在します。

スクリプト・ベースのコネクターIBM Tivoli Directory Integrator と同じライブラリーを使用する場合は、別の問題が生じることがあります。コネクターを最後にコンパイルした後で、新バージョンのIBM Tivoli Directory Integrator でライブラリーが更新されたり、ユーザーがライブラリーをアップグレードした可能性があります。

サポートされるモードのリストについては、『サポートされるモードの欄の凡例』を参照してください。

汎用コネクター? ? ? ? ?

スクリプト・コネクターはユーザー自身が作成するものであり、ユーザーがスクリプトに書き込んだモードを提供します。「IBM Tivoli Directory

Integrator 5.2 ユーザーズ・ガイド」の『JavaScript™ Connector』を参照してください。

構成サポートされるモードのリストについては、『サポートされるモードの欄の凡例』を参照してください。

BTree オブジェクト DB コネクターBTree コネクターは、Java オブジェクトを格納できる単純なデータベースです。各オブジェクトは、キーと呼ばれる値により一意的に識別されます。このコネクターは、基礎となっている BTree インプリメンテーションを使用して、AssemblyLine

の項目オブジェクトを格納します。これにより、ユーザーは、固有キーを使用してconn 項目および作業項目を格納することができます。製品のバージョン 5.2 以降では、AssemblyLine のデルタ機能にはシステム・ストアの使用が推奨されていますが、このコネクターはデルタ機能でも使用されます。

第 2 章コネクター 5

BTree インプリメンテーションを直接使用して、AssemblyLine 項目以外の Java オブジェクトを格納したい場合は、まず BTree オブジェクトを取得し、そのオブジェクトのメソッドを直接使用する必要があります。

注:

1. BTree データベースが存在しない場合は、BTree コネクターは新規のデータベースを作成します。ただし、存在しないデータベース上で繰り返しを実行すると、そのデータベースは作成されますが、イテレーターは値を戻しません。

2. Btree コネクターは小規模の高速なジョブでは優れていますが、BTree コネクターはデータ構造のバランスを自動的に取らないので、何千もの項目を含むソート済みリストが入力されるとダウンします。ランダムな順序のデータ・セットの場合、限界はいくらか高くなります。大規模なデータ・セットの場合は、CloudScape™ データベースを検討してください (「IBM Tivoli Directory

Integrator 5.2 ユーザーズ・ガイド」の『Using CloudScape database』を参照してください)。

構成このコネクターは、以下のパラメーターを必要とします。

DB ファイル名BTree データを格納するファイル・パス。

キー属性名項目の固有値を提供する属性名。

選択モードAll、Existing、または Deleted を指定します。Existing キーワードおよびDeleted キーワードを使用するには、デルタが使用可能にされているAssemblyLine でコネクター (データベース) が使用されていることが必要です。イテレーターでデルタが使用可能にされている場合は、AssemblyLine

はデータベースにシーケンス・プロパティーを格納すると共に、ソースから読み取った各項目にシーケンス番号を追加します。

詳細ログこのフィールドにチェックマークを付けると、追加のログ・メッセージが生成されます。

BTree オブジェクトgetDatabase() メソッドは、基礎となっている BTree オブジェクトを戻します。このオブジェクトを使用して、AssemblyLine 項目以外の Java オブジェクトを格納することができます。以下の部分コードは、データベース内のオブジェクトをどのように挿入、検索、および置換できるかを示します。

var bt = system.getConnector("btreedb");bt.initialze (null);

var db = bt.getDatabase();db.insert ("my key", new java.lang.String("my value"));var value = db.search ("my key");value = value + " - modified";db.replace ("my key", value);


注: BTree コネクターを使用すると、keyAttribute のみで検索または更新できます。また、BTree コネクターは拡張リンク基準をサポートしません (「IBM Tivoli

Directory Integrator 5.2 ユーザーズ・ガイド」の『Advanced link criteria』を参照してください)。

コマンド行コネクターコマンド行コネクターを使用すると、コマンド行から出力を読み取ること、またはコマンド行の標準入力にデータをパイピングすることができます。コマンド引き数はそれぞれスペース文字で区切られ、引用符は無視されます。

注: 独立したシェルが取得されるのではないので、リダイレクト文字 (| > など) は無効です。リダイレクトを使用するには、適切なパラメーター・セットを指定したシェル・スクリプト (UNIX®) またはバッチ・コマンド (DOS) を作成してください。例えば、Windows® システムでは次のように入力します。

cmd /c dir

ディレクトリーの内容がリストされます。


コマンド行実行するコマンド行。


パーサー項目の解釈または生成を行うパーサー。

例ご使用の IBM Tivoli Directory Integrator システムのroot_directory/examples/commandLine_connector ディレクトリーにあります。

直接 TCP/URL スクリプトコネクターを使用せずに、URL オブジェクトまたは TCP ポートに直接アクセスすることもできます。プロローグに入力できるサンプル・コードを以下に示します。

TCP// This example creates a TCP connection to www.example_page_only.com

and asks for a bad page

var tcp = new java.net.Socket ( "www.example_page_only.com", 80 );var inp = new java.io.BufferedReader ( new java.io.InputStreamReader

( tcp.getInputStream() ) );var out = new java.io.BufferedWriter ( new java.io.OutputStreamWriter

( tcp.getOutputStream() ) );

task.logmsg ("Connected to server");


// Ask for a bad pageout.write ("GET /smucky¥r¥n");out.write ("¥r¥n");

// When using buffered writers always call flush to make sure datais sent on connection

out.flush ();

task.logmsg ("Wait for response");var response = inp.readLine ();

task.logmsg ( "Server said: " + response );

URL// This example uses the java.net.URL object instead of the raw

TCP socket object

var url = new java.net.URL("http://www.example_page_only.com");var obj = url.getContent();

var inp = new java.io.BufferedReader ( new java.io.InputStreamReader( obj ) );

while ( ( str = inp.readLine() ) != null ) {task.logmsg ( str );}

Domino ユーザー・コネクターDomino™ ユーザー・コネクターを使用すると、Lotus® Domino ユーザー・アカウントにアクセスし、それらのユーザー・アカウントを管理することができます。このコネクターは、イテレーター、ルックアップ、AddOnly、更新、および削除の各モードで働き、それぞれ以下の操作を行うことができます。

イテレーター (Iterator)アドレス帳から取り出したすべてのユーザー文書 (またはフィルターにより選別したサブセット) に対して、繰り返しを行います。

ルックアップ (Lookup)一定の基準を満たすユーザー文書を探して検索します。

AddOnlyDomino Server に新規ユーザーを登録し、それらのユーザーのユーザー文書を作成します。

更新 (Update)ユーザーのユーザー文書の変更、ユーザーの使用可/使用不可、および既存(インターネット) ユーザーの登録を行います。

削除 (Delete)ユーザー削除の要求を Domino Server 管理要求データベースにポストします。

注: Domino ユーザー・コネクターを使用するには、Lotus Notes® はリリース 5.0.8

以降でなければなりません。


Domino Server の展開と接続Domino ユーザー・コネクターは、Lotus Domino Server バージョン 5.0.8 以降で使用する必要があります。

Domino ユーザー・コネクターを使用するには、IBM Tivoli Directory Integrator

を、Domino Server がインストールされているマシンにインストールし、そこから実行する必要があります。ibmdisrv.bat および ibmditk.bat の両方のファイル内のmyclasspath 変数 (または、Windows プラットフォーム以外の場合は ibmdisrv および ibmditk の両方のファイル内の MYCLASSPATH 変数) に、Notes.jar のパス名を追加してください。これにより、Domino Server にアクセスするネイティブ呼び出しへのインターフェースが提供されます。このライブラリーは Lotus により提供されるもので、Domino Server がインストールされているフォルダー (例えば、C:¥Lotus¥Domino) に入っています。

root_directory/jars フォルダーから、ncso.jar ファイルを削除する必要があります。また、ibmdisrv.bat および ibmditk.bat の両方のファイル内の myclasspath 変数 (または、Windows プラットフォーム以外の場合は ibmdisrv および ibmditk の両方のファイル内の MYCLASSPATH 変数) から、jars/ncso.jar; というストリングも削除してください。

最後に、ibmditk および ibmdisrv の中の PATH 環境変数に、ローカル Domino バイナリーへのパス (例えば、C:¥Lotus¥Domino) を追加します。

Solaris 固有の設定ibmditk および ibmdisrv ファイル内で、Java コマンド行に以下の行を追加します。

-Djava.library.path=$PATH

これにより、JVM は (したがって Domino ユーザー・コネクターも)、必要なDomino ライブラリーを見つけることができるようになります。次に示すのは Java

コマンド行の例です。

/opt/IBM/IBMDirectoryIntegrator/_jvm/bin/java \-cp $MYCLASSPATH -Djava.library.path=$PATH \-Dcom.ibm.di.installdir=/opt/IBM/IBMDirectoryIntegrator \com.ibm.di.loader.IDILoader com.ibm.di.admin.miadmin "$@"

Domino のいくつかのバージョン (少なくとも 5.0.8) では、Java コマンド行にさらに追加の変更を加える必要があります。Java 1.3.1 が実際には値として SunOS を戻すときに、Domino ライブラリーは、Java プロパティー os.name が SOLARISであることを予期しています。この状況を修正するには、ibmditk および ibmdisrv

内の Java コマンド行に以下の行を追加します。

-Dos.name=SOLARIS

以下に示すのは、上記の情報をすべて組み込んだ行の例です。

/opt/IBM/IBMDirectoryIntegrator/_jvm/bin/java \-cp $MYCLASSPATH -Djava.library.path=$PATH \-Dos.name=SOLARIS -Dcom.ibm.di.installdir=/opt/IBM/IBMDirectoryIntegrator \com.ibm.di.loader.IDILoader com.ibm.di.admin.miadmin "$@"

Linux 固有の設定Linux で実行するときは、前に述べた変更を java.library.path に対して行う必要があります。次に示すのは Linux 始動スクリプトの例です。


/opt/IBM/IBMDirectoryIntegrator/_jvm/bin/java \-Xquickstart -Xms16m -cp $MYCLASSPATH -Djava.library.path=$PATH \-Dcom.ibm.di.installdir=/opt/IBM/IBMDirectoryIntegrator \com.ibm.di.loader.IDILoader com.ibm.di.admin.miadmin "$@"

ローカル・サーバー接続を認証するには、Domino では、ユーザーのショート・ネームおよびインターネット・パスワードが必要です (これらはコネクターのパラメーターです)。


ユーザー名Domino Server へのログインまたは認証に使用するユーザー名。

パスワードユーザー名のパスワード。

アドレス帳データベース使用するアドレス帳データベースの名前。デフォルト値は names.nsf です。

フルテキスト検索チェックマークを付けると、コネクターはユーザー・ビューとフルテキスト検索を使用してユーザー文書にアクセスします。チェックマークを付けないと、コネクターは通常のデータベース検索を使用します。この場合、コネクターはフォーム項目の値が Person である文書のみにアクセスすることにより、自動的にデータベース検索をユーザー文書のみに絞ります。このパラメーターの影響を受けるのは、イテレーター・モードとルックアップ・モードのみです。

フルテキスト・フィルターこの値が考慮されるのは、フルテキスト検索が使用可能である場合のみです。このパラメーターには、イテレーター・モードのコネクターが戻すユーザー文書をフィルターに掛ける、フルテキスト照会が含まれます。Null または空のストリングの場合は、フィルター操作は行われません。デフォルト値は ″″ です。

公式フィルターこの値が考慮されるのは、フルテキスト検索が使用不可である場合のみです。このパラメーターには、イテレーター・モードのコネクターが戻すユーザーをフィルターに掛ける公式が含まれます。コネクターは、この公式に自動的に以下を追加します。

"& Form = "Person""

これにより、検索がユーザー文書のみに制限されます。デフォルト値は ″″です。



セキュリティーIBM Tivoli Directory Integrator が Domino Server にアクセスできるようにするには、「Domino Administrator」 -> 「設定」 -> 「現在のサーバー文書」 -> 「セキュリティ」 -> 「Java/COM Restrictions」で IBM Tivoli Directory Integrator を有効にする必要があります。IBM Tivoli Directory Integrator が使用するものとして構成したユーザー・アカウントは、「制限付き Java/Javascript/COM の実行」および「制限なし Java/Javascript/COM の実行」の下にリストされているグループのいずれかに属していなければなりません。

Domino コネクターの使用

イテレーター・モードこのコネクターは、アドレス帳データベースのユーザー文書を対象として繰り返しを行います。すべてのユーザー文書 (フィルターが設定されている場合はフィルター基準を満たすもの) が項目オブジェクトとして引き渡され、すべての文書項目 (添付文書を除く) が項目属性に変換されます。

コネクターが戻す項目には、ユーザー文書項目に対応する属性のほかに、コネクターが計算した値を持つ追加 (派生) 属性が含まれています。以下に、このような派生属性のリストを示します。

DER_IsEnabled(ブール) ユーザーが使用可能にされているか使用不可にされているかを指定します。

v true: ユーザーが Deny List only グループに属していない場合。

v false: ユーザーが少なくとも 1 つの Deny List only グループに属している場合。

ルックアップ・モードルックアップ・モードでは、コネクターはユーザー文書の検索を行い、検索のタイプはフルテキスト検索パラメーターの値によって決まります。

v フルテキスト検索 = true: コネクターはユーザー・ビュー内でフルテキスト検索を実行します。フルテキスト検索は、フルテキスト索引付きデータベースとフルテキスト索引なしデータベースのどちらにも有効です。ただし、フルテキスト索引なしのデータベースの場合は、検索効率は低下します。また、データベースのフルテキスト索引が更新されないことがあり、その場合は、検索結果は実際のデータベースの内容と一致しません。

v フルテキスト検索 = false: コネクターは Lotus 公式を使用して、通常のデータベース検索を実行します。コネクターは、この公式にエレメント (Form =

″Person″) を自動的に追加するので、検索対象はユーザー文書のみに限定されます。

単純リンク基準を使用する場合は、正規名 (CN=UserName/O=Org) および短縮名(UserName/Org) の両方の値を使用して、ユーザーの FullName を指定することができます。コネクターは、指定された値を自動的に処理し、必要があれば変換します。


拡張リンク基準を使用する場合は、十分に注意して、次に示す正しい形式でユーザーの FullName を指定する必要があります。

v フルテキスト検索の場合: 短縮名 (UserName/Org) を使用します。

v 通常データベース検索の場合: 正規名 (CN=UserName/O=Org) を使用します。

AddOnly モードAddOnly モードでは、常に新しいユーザー文書がアドレス帳データベースに追加されます。追加プロセスでは、属性マッピングにより提供されるどのような属性でも受け入れられますが、Domino が正しいユーザー処理を行うためには、属性名は、Domino が処理する項目名と一致している必要があります。このコネクターはユーザーのみを対象として操作を行うので、常に属性の Type および Form の値をPerson に設定します。したがって、属性マッピング・プロセスでこれらの属性に設定されている値はすべて指定変更されます。ユーザー文書を正しく作成するためには、Domino ユーザー属性 LastName が必要です。既存の値がコネクターによって自動的にハッシュされるのでなければ、HTTPPassword 属性は必須ではありません。

属性の固定スキーマに応じて、コネクターは新規ユーザーを登録できます。以下の表は、これらの属性、conn 項目内の各属性の有無に応じたコネクターの動作、および各属性の値を示しています。

属性名タイプ登録のために必要か? 値

REG_Perform ブールはい true に設定すると、コネクターはユーザー登録を行います。この属性が存在しないか、値が false である場合は、他のREG_ 属性の存在の有無やその値にかかわらず、コネクターはユーザー登録を行いません。

REG_IdFile ストリングはい登録する ID ファイルの絶対パスが含まれています。たとえば、

c:¥¥newuserdata¥¥newuser.id

REG_UserPw ストリングはいユーザーのパスワード。

REG_CertifierIDFile ストリングはい認証者 ID ファイルへの絶対ファイル・パス。


REG_CertPassword ストリングはい認証者 ID ファイルのパスワード。注: ユーザーを登録しているときに認証者パスワードに誤りがあると、ポップアップ・ウィンドウが表示されます。認証者パスワードは必ず正しく指定してください。

REG_Server ストリングいいえユーザーのメール・ファイルを含むサーバーの名前。この属性が存在しない場合は、コネクターのDominoSession オブジェクトから値が取得されます。

REG_CreateMailDb ブール/ストリングいいえ true: メール・データベースを作成します。false :メール・データベースを作成しません (セットアップ時に作成されます)。この属性が存在しない場合は、デフォルト値として false が使用されます。この属性が true の場合は、MailFile 属性を有効なパスにマップする必要があります。

REG_Expiration 日付いいえ ID ファイルを作成するときに使用する有効期限の日付。この属性が存在しないか、値が Null である場合は、デフォルト値として「現在日 +

2 年」が使用されます。


REG_IDType 整数/ストリングいいえ作成する ID ファイルのタイプ。0: フラット ID を作成。1:

階層 ID を作成。2:

認証者 ID がフラットか階層かに合わせて ID を作成。この属性が存在しない場合は、デフォルト値として 2 が使用されます。

REG_Is

NorthAmerican

ブール/ストリングいいえ true: ID ファイルはNorth American です。false: ID ファイルは North American

ではありません。この属性が存在しない場合は、デフォルト値として true が使用されます。

REG_OrgUnit ストリングいいえ ID ファイルを作成するときに使用する組織単位。この属性が存在しない場合は、デフォルト値として″ ″ が使用されます。

REG_RegistrationLog ストリングいいえ ID ファイルを作成するときに使用するログ・ファイル。この属性が存在しない場合は、デフォルト値として ″ ″ が使用されます。

REG_StoreID

InAddressBook

ブール/ストリングいいえ true: ID ファイルをサーバーの Domino

Directory に保管します。false: ID ファイルをサーバーのDomino Directory に保管しません。この属性が存在しない場合は、デフォルト値として false が使用されます。


REG_Registration

Server

ストリングいいえ ID ファイルを作成するときに使用するサーバー。この属性が使用されるのは、作成された ID がサーバーの Domino

Directory に保管される場合か、新規ユーザー用のメール・データベースが作成される場合のみです。

REG_MinPassword

Length

整数/ストリングいいえ REG_MinPassword

Length 値は、ユーザーが以後パスワードを変更する際に必要とされる最小パスワード長を定義します。ユーザーを登録するときに使用するパスワードは、REG_MinPassword の制約を受けません。

Length 値。この属性が存在しない場合は、デフォルト値として 0 が使用されます。

REG_Forward ストリングいいえユーザーのメール・ファイル用の転送ドメイン。

REG_AltOrgUnit <ストリング> のベクトル

いいえ ID ファイルを作成するときに使用する組織単位の代替名。

REG_AltOrgUnit

Lang

<ストリング> のベクトル

いいえ ID ファイルを作成するときに使用する組織単位の代替言語名。

ユーザー登録が成功するためには、「登録のために必要」フィールドが「はい」に設定されている属性が必要です。ユーザー登録には、これらの REG_ 属性の他に、LastName Domino ユーザー属性も必要です。

REG_Perform が true に設定されているときに、登録に必要な他の属性のいずれかが欠落している場合は、コネクターは例外をスローし、問題を説明するメッセージを出します。


更新モード更新モードでは、以下のことが行われます。

1. Domino で、更新する項目が検索されます。

2. 該当項目が見つからない場合は、『AddOnly モード』の項で説明した AddOnly

操作が実行されます (必要な REG_ 属性が指定されている場合は、ユーザー登録も行われます)。

3. 該当項目が見つかった場合は、変更操作が行われます。

ユーザーを変更するときは、Domino ユーザー・コネクターは、アドレス帳データベース内のユーザー文書を、指定された属性で変更します。変更プロセスでは、属性マッピングにより提供されるどのような属性でも受け入れられますが、Domino が正しいユーザー処理を行うためには、属性名は、Domino が処理する項目名と一致している必要があります。

このコネクターはユーザーのみを対象として操作を行うので、属性マッピング・プロセスで何が行われるかに関係なく、属性の Type および Form は変更しません(これらの値はいずれも Person です)。HTTPPassword 属性が指定されている場合は、既存の値がコネクターによって自動的にハッシュされます。

ユーザーを変更するプロセスでは、Domino ユーザー・コネクターは、ユーザーを使用不可および使用可能にするオプションを提供します。ユーザーを使用不可にするには、Deny List only グループにそのユーザーを追加します (Deny List only グループについては、Domino の資料を参照してください。http://www.lotus.com/products/domdoc.nsf にアクセスして、Lotus DominoDocument Manager 3.5 リンクをクリックしてください)。ユーザーを使用可能にするには、すべての Deny List only グループからそのユーザーの名前を削除します。

コネクターは、conn 項目の有無、および以下の項目属性の値に応じて、ユーザーを使用不可または使用可能にします。

ACC_SetType(整数/ストリング) この属性が存在しない場合は、アクションは何も行われず、ユーザーは現在の使用不可/使用可能の状況を維持します。この属性が指定されている場合は、その値が検査されます。

v 0: コネクターはユーザーを使用不可にする操作を行います(ACC_DenyGroupName 属性に指定されているグループにそのユーザーの名前が追加されます)。

v 1: コネクターはユーザーを使用可能にする操作を行います (その他の値の場合、例外が出されます)。

ACC_DenyGroupName(ストリング) ユーザーを使用不可にするときに、そのユーザーの名前を追加する Deny List only グループの名前。ACC_SetType の値が 0 の場合は、ACC_DenyGroupName 属性が必須になります。この属性が欠落しているか、存在しない Deny List only グループを値に指定する場合、例外がスローされます。ACC_SetType 属性が欠落しているか、その値が 1 である場合は、ACC_DenyGroupName 属性は不要であり、その値は無視されます。


このコネクターは、変更時にユーザー登録も行うことができます。登録を行うかどうかの決定には、AddOnly モードの場合と同じ規則が適用されます。同じ属性スキーマが使用され、すべての REG_ 属性が同じ意味を持ちます。

REG_ 属性に基づき登録を行うことが決定された場合に、以下のような状況が生じることがあります。

v ユーザーはまだ登録されていない (例えば、インターネットまたは Web ユーザーを登録し、そのユーザーが Notes Client を使用してログオンおよび作業ができるようにしようとしている場合)。ユーザーは登録され、新規 ID ファイルの作成などが行われます。

v ユーザーは既に登録されている。この場合、ユーザーは再登録されます。例えば、Domino 登録値が新規に指定された値でリセットされます。新規 ID ファイルも作成されます。

注:

1. 変更時にユーザー登録を行う場合は、コネクターの変更の計算オプションをオフにします。オンにされていると、変更の計算機能によって、ある種のユーザー登録に必要な属性がクリアされ、登録が失敗する場合があります。

2. 変更時にユーザー登録を行う場合は、登録後のユーザーの FullName を事前に確認することが必要です。そして、conn 項目内の FullName 属性にその値を指定する必要があります (これは、多くの場合スクリプトにより構成します)。これは、Domino の登録プロセスに関する詳細な知識が必要になるため、あまり便利とはいえません。ただし、ユーザーの正しい FullName を事前に設定しておかないと、既存ユーザーではなく新規ユーザーが登録されてしまう恐れがあります。

削除モードこのコネクターは、Domino 管理プロセスを使用してユーザーを削除します。

コネクターは、システム管理要求データベースにアドレス帳内削除要求をポストします。アドレス帳内削除のタイプの要求が Domino 管理プロセスで処理されるたびに、管理要求のポストと処理、および管理プロセスがユーザーを削除するために実行するアクションが起動されます。アドレス帳内削除管理要求をポストすると、Domino Administrator を使用して手動でユーザーを削除するのと同じ結果になります。特に、次のことがあげられます。

v 管理要求の処理時間は、Domino Server 構成によって異なります。

v 要求された削除のタイプによっては、一連の管理要求に、管理者の承認が必要な要求が含まれることがあります (例えば、ユーザーのメール・ファイルを削除するためのファイル削除承認要求)。

このコネクターでは、開始するユーザー削除ごとに調整を行うことができます。構成可能なパラメーターは、以下のとおりです。

メール・ファイルの削除次のいずれかのオプションを指定できます。

v メール・ファイルを削除しない。

v 個人文書内で指定されているメール・ファイルのみを削除する。

v 個人文書およびすべてのレプリカの中で指定されているメール・ファイルを削除する。


グループへの追加ユーザーを削除するときに、いずれかのグループにそのユーザーの名前を追加するかどうかを指定します。はいの場合は、そのグループの名前も指定します。このオプションは、通常、削除するユーザーを Deny List only グループに追加して、そのユーザーがサーバーにアクセスすることを拒否するために使用します。

上記の削除パラメーターには、それぞれデフォルト値がありますが、これらはDomino ユーザー・コネクターが提供する API を使用して変更することもできます。Domino ユーザー・コネクターのインスタンスが作成されるときに (特に各AssemblyLine の開始時)、パラメーターは以下のデフォルト値に設定されます。

メール・ファイルの削除メール・ファイルを削除しない。

グループへの追加削除時にユーザーの名前をどのグループにも追加しない。

これらのデフォルト値が、使用する削除のタイプに適合している場合は、削除についての特別な構成は必要ありません。必要なのは、削除コネクターで正しいリンク基準を指定することです。

ただし、Domino ユーザー・コネクターが提供する API を使用して、実行時にデフォルト値を変更することもできます (スクリプトを使用)。

int getDeleteMailFile()「メール・ファイルの削除」パラメーターのデフォルト値のコードを戻します。

v 0: メール・ファイルを削除しない。

v 1: ユーザー文書内で指定されているメール・ファイルのみを削除する。

v 2: ユーザー文書およびすべてのレプリカの中で指定されているメール・ファイルを削除する。

void setDeleteMailFile (int deleteType)「メール・ファイルの削除」パラメーターのデフォルト値を設定します。deleteType メソッドのパラメーターには、希望する値のコードを含める必要があります (コードは getDeleteMailFile() に示したとおりです)。

String getDeleteGroupName ()「グループへの追加」パラメーターのデフォルト値を戻します。

v NULL: ユーザーの名前をどのグループにも追加しないことを意味します。

v NULL 以外の値: ユーザーの名前を追加するグループの名前。

void setDeleteGroupName (String groupName)「グループへの追加」パラメーターのデフォルト値を設定します。

v NULL: 削除時にユーザーの名前をどのグループにも追加しないことを指定します。

v NULL 以外のストリング値: 削除時にユーザーの名前を追加するグループの名前を指定します。


削除パラメーターのデフォルト値は、別の値に変更されるかまたはコネクター・インスタンス (オブジェクト) が破棄されるまでは、このコネクターが行うすべての削除操作に適用されます。

以下に、上記のメソッドを使用したシナリオを示します。

v Before Delete フック内のスクリプト・コードで、作業オブジェクトおよびconn オブジェクト (および検査を要するその他のすべてのもの) を検査し、特定の決定ロジックに従い、setDeleteMailFile および setDeleteGroupName を使用して個々のユーザー削除を調整する。

v 削除対象のすべてのユーザーを 1 つのパターンに従って削除する必要がある (そして個々のユーザー削除について調整を行う必要はない) 場合、AssemblyLine プロローグ内のスクリプト・コードで、setDeleteMailFile およびsetDeleteGroupName メソッドを使用し、プロセス全体についての値を設定できる。

さらに、conn 項目内で以下の属性を設定することによって、削除パラメーターを操作することもできます。

DEL_DeleteMailFile(整数/ストリング)

conn 項目内にこの属性がない場合は、メール・ファイルの削除のデフォルト値が使用されます。

conn 項目内にこの属性が存在する場合は、その値によって、現行の削除のみについてのメール・ファイルの削除パラメーターの値が決まります。

v 0: メール・ファイルを削除しない。

v 1: ユーザー文書内で指定されているメール・ファイルのみを削除する。

v 2: ユーザー文書およびすべてのレプリカの中で指定されているメール・ファイルを削除する。

DEL_DeleteGroupName(ストリング)

conn 項目内にこの属性がない場合は、グループへの追加のデフォルト値が使用されます。

conn 項目内にこの属性が存在する場合は、その値によって、現行の削除のみについてのグループへの追加パラメーターの値が決まります。

v NULL: ユーザーの名前をどのグループにも追加しないことを指定します。

v NULL 以外のストリング値: ユーザーの名前を追加するグループの名前を指定します。

conn 項目内で DEL_DeleteMailFile 属性および DEL_DeleteGroupName 属性を使用すると、現行の削除についてのみ、それぞれに対応する削除パラメーターのデフォルト値が指定変更されます。

conn 項目内で DEL_DeleteMailFile 属性および DEL_DeleteGroupName 属性を設定するには、Before Delete フック内でスクリプトを使用します。しかし、スク


リプトを使用して属性を追加するのは必ずしも便利な方法ではないので、多くの場合、デフォルトの削除パラメーターを使用し、API を使用してそれを変更する方が簡単です。

Domino ユーザー属性 (ユーザー文書項目) のリスト以下に示すのは、サーバーがユーザーを操作するときに、Domino が認識して処理する Domino ユーザー文書項目のリストです (すべてを網羅しているわけではありません)。これらの項目について詳しくは、Lotus Domino の資料を参照してください。http://www.lotus.com/products/domdoc.nsf にアクセスして、Lotus DominoDocument Manager 3.5 リンクをクリックしてください。

コネクターで追加、変更、削除、またはルックアップ操作を行うときは、項目属性名に下記のリストに示されているものと同じ名前を使用してください。

v AltFullName

v AltFullNameLanguage

v AltFullNameSort

v Assistant

v AvailableForDirSync

v CalendarDomain

v CellPhoneNumber

v CcMailUserName

v Certificate

v CheckPassword

v Children

v City

v ClientType

v Comment

v CompanyName

v country

v Department

v DocumentAccess

v EmployeeID

v EncryptIncomingMail

v FirstName

v Form

v FullName

v HomeFAXPhoneNumber

v HTTPPassword

v InternetAddress

v JobTitle

v LastName

v Level0


v Level0_1

v Level0_2

v Level0_3

v Level1

v Level1_1

v Level1_2

v Level1_3

v Level2

v Level2_1

v Level2_2

v Level2_3

v Level3

v Level3_1

v Level3_2

v Level3_3

v Level4

v Level4_1

v Level4_2

v Level4_3

v Level5

v Level5_1

v Level5_2

v Level5_3

v Level6

v Level6_1

v Level6_2

v Level6_3

v LocalAdmin

v Location

v MailAddress

v MailDomain

v MailFile

v MailServer

v MailSystem

v Manager

v MessageStorage

v MiddleInitial

v NetUserName

v NoteID

v OfficeCity


v OfficeCountry

v OfficeFAXPhoneNumber

v OfficeNumber

v OfficePhoneNumber

v OfficeState

v OfficeStreetAddress

v OfficeZIP

v Owner

v PasswordChangeDate

v PasswordChangeInterval

v PasswordGracePeriod

v PersonalID

v PhoneNumber

v PhoneNumber_6

v SametimeServer

v ShortName

v Spouse

v State

v StreetAddress

v Suffix

v Title

v Type

v WebSite

v x400Address

v Zip

Domino Server 6.0 for AIX/Linux/SolarisDomino ユーザー・コネクターを Domino Server 6.0 for AIX/Linux/Solaris で使用する場合は、ibmditk スクリプトと ibmdisrv スクリプトを更新する必要があります。スクリプトの PATH 定義と開始行の間に、次の 2 行を追加します。

LD_LIBRARY_PATH=Domino_binary_folderexport LD_LIBRARY_PATH

ここで、Domino_binary_folder は Domino ネイティブ・ライブラリーを含むフォルダーです (例えば、Solaris の場合は /opt/lotus/notes/latest/sunspa、Linux の場合は/opt/lotus/notes/latest/linux)。

Domino ユーザーで IBM Tivoli Directory Integrator を始動します (root を使用しないでください)。Domino Server のインストール時に変更しない限り、Domino ユーザーは notes と呼ばれます。


例ご使用の IBM Tivoli Directory Integrator システムのroot_directory/examples/dominoUsersConnector ディレクトリーにあります。

関連情報73ページの『Lotus Notes コネクター』

ファイル・システム・コネクターファイル・システム・コネクターはトランスポート・コネクターの 1 つであり、このコネクターが正しく機能するにはパーサーが必要です。ファイル・システム・コネクターは、それを実行しているシステムで使用可能なファイルの読み取りと書き込みを行います。

注: このコネクターは、イテレーター・モードまたは AddOnly モードでのみ使用できます。または、受動状態でこれらのモードに対応する操作を行うためにのみ使用できます。


ファイル・パス読み取りまたは書き込みを行うファイルの名前。

読み取りタイムアウト (秒単位)このパラメーターを正数で指定すると、コネクターはファイルからの読み取りの際に使用可能なデータを待ちます。0 (ゼロ) は待機時間が無制限であることを指定し、その他の数値はファイル終わりを通知するまでに待つ時間(秒数) を指定します。このパラメーターを 0 (ゼロ) に設定すると、コネクターは、UNIX スタイルの tail -f コマンドをシミュレートします。

出力時に付加このパラメーターを設定した場合、書き込みのためにファイルをオープンするときに、上書きではなく追加が行われます。


パーサーファイルの内容にアクセスするパーサーの名前。

関連情報97ページの『URL コネクター』


FTP クライアント・コネクターFTP クライアント・コネクターはトランスポート・コネクターの 1 つであり、このコネクターが正しく機能するにはパーサーが必要です。このコネクターは、データ・ストリーム (ファイルまたはディレクトリー・リスト) の読み取りまたは書き込みを行います。 FTP クライアント・コネクターは、ファイルの転送に使用する手段というより、リモート読み取り/書き込み機能と考える方が妥当です。

注:

1. イテレーター・モードでは、get および list 操作がサポートされます。AddOnly

モードでは、put 操作がサポートされます。

2. このコネクターは、バイナリー・ファイルを転送するためのものではありません。


FTP ホスト名FTP ホスト名。

FTP ポートFTP TCP ポート (デフォルトは 21)。

ログイン・ユーザーログイン・ユーザー名。

ログイン・パスワードログイン・パスワード。

操作意図された操作。ファイルの読み取り (イテレーター) の場合は get、ファイルの書き込み (AddOnly) の場合は put、ディレクトリーのリスト作成(イテレーター) の場合は list を指定します。

リモート・パスアクセスする初期リモート・ディレクトリー (list の場合) または初期リモート・ファイル (get/put の場合)。

転送モードASCII またはバイナリー。サポートされているモードは ASCII のみです。


パーサー必須パーサー。例えば、リストを作成する場合や 1 つのファイルのみをコピーしたい場合は、Line Reader パーサーが便利です。

関連情報174ページの『FTP オブジェクト』, 97ページの『URL コネクター』, 25ページの『旧 HTTP クライアント・コネクター』, 31ページの『旧 HTTP サーバー・コネクター』


旧 HTTP クライアント・コネクター

注: このコネクターは、レガシー目的のためにのみ保持されています。新規のコネクターを作成する場合は、代わりに HTTP クライアント・コネクターを使用してください。

旧 HTTP クライアント・コネクターは、URL コネクターより、HTTP セッションに対する高い制御能力を提供します。この HTTP コネクターを使用すると、事前定義済みの属性を使用して HTTP ヘッダーと本文を設定できます。また、ユーザーは、データを戻すサーバーへのどのような要求でも、属性として使用できます。

注: 旧 HTTP クライアント・コネクターは、拡張リンク基準をサポートしません(「IBM Tivoli Directory Integrator 5.2 ユーザーズ・ガイド」の『Advanced link

criteria』を参照してください)。

モード旧 HTTP クライアント・コネクターは、3 つの AssemblyLine モードで使用できます。下記を参照してください。

イテレーター (Iterator)このコネクターを呼び出すたびに、このコネクター用に構成されている同じURL が要求されます。したがって、コネクターの構成にパーサーを組み込んでいない限り、コネクターは永続的に同じページを要求して実行を続けます。パーサーを組み込んである場合は、パーサーは接続から最後の項目が読み取られた時点で通知を送り、コネクターは最終的に AssemblyLine を終了させます。

ルックアップ (Lookup)このモードでは、コネクターは、ルックアップ関数が呼び出されるたびに 1

つのページを要求します。検索基準には、要求するページまたは URL を指定するか、任意の数のパラメーターを組み込むことができます。これらのパラメーターは、すべて要求パラメーターとして基本 URL に追加されます。

AddOnlyこのモードでは、コネクター要求はイテレーター・モードとほとんど同じように実行されます。

ルックアップ・モードルックアップ・モードでは、次のように、検索基準を設定することにより動的に要求 URL を変更することができます。

v 基準が 1 つしかなく、属性の名前が url である場合は、その基準の中で指定した値が要求 URL として使用されます。

url equals $url

v 複数の基準があるか、または唯一の基準が url 以外のものである場合は、コネクター構成で要求 URL として指定されている URL に、すべての属性名と値が付加されます。

基本 URL: http://www.example_name.com/lookup.cgi

検索基準:


name equals johnmail equals doe.com

結果の URL: http://www.example_name.com/lookup.cgi?name=john&mail=doe.com ルックアップ関数はオペランドを無視します。したがって、equals ではなくcontains を指定したとしても、コネクターは equals を使用したときと同じようにURL を作成します。

特殊属性このコネクターをイテレーター・モードまたはルックアップ・モードで使用するときは、以下に示す属性またはプロパティーのセットがコネクター項目に戻されます。

http.responseCode整数オブジェクトとしての HTTP 応答コード。

200 OK —-> 200

http.responseMsgストリング・オブジェクトとしての HTTP 応答メッセージ。

200 OK —-> OK

http.content-type戻される http.body のコンテンツ・タイプ (存在する場合)。

http.content-encoding戻される http.body のエンコード (存在する場合)。

http.content-lengthhttp.body のバイト数。

http.bodyこのオブジェクトは、戻された本文のバイトを読み取るために使用できる、java.io.InputStream クラスのインスタンス/サブクラスです。

var body = conn.getObject ("http.body");var ch;

while ( (ch = body.read()) != -1 ) {task.logmsg ("Next character: " + ch);

}

InputStream クラスおよびおよびそれぞれのメソッドについては、JavaDocs

を参照してください。

http.text-bodyhttp.content-type が text/ というシーケンスで始まっている場合は、コネクターは本文がテキスト・データであると判断し、http.body ストリーム・オブジェクトをこの属性に読み込みます。

このコネクターを AddOnly モードで使用しているときは、コネクターはヘッダー名に http. が付いている属性をすべて送信します。したがって、要求のコンテンツ・タイプを設定するには、属性に http.content-type という名前を付け、通常どおりに値を指定します。特殊な属性の 1 つに http.body があり、これには、ストリングまたは任意の java.io.InputStream または java.io.Reader サブクラスを含めることができます。


どのモードの場合も、コネクターは必ず http.responseCode 属性およびhttp.responseMsg 属性を設定します。AddOnly モードでは、コネクターに渡される conn オブジェクトはこれらの属性の取り込み先オブジェクトなので、やや特別です。これらの属性にアクセスするには、コネクターの After Add フック内の値を取得する必要があります。


HTTP URL要求する HTTP ページ。

要求メソッドページを要求するときに使用する HTTP メソッド。詳細については、http://www.w3.org/Protocols/HTTP/Methods.html を参照してください。

ユーザー名このパラメーターが設定されている場合は、HTTP 許可ヘッダーは、このパラメーターとパスワード・パラメーターを使用して設定されます。

パスワードユーザー名を指定した場合に使用されます。


パーサーパーサーを指定した場合は、追加操作の対象として送られたデータを生成するためにそのパーサーが使用されます。

例属性マップの中で以下の割り当てを使用して、ファイルのコンテンツを HTTP サーバーに通知することができます。

// Attribute assignment for "http.body"ret.value = new java.io.FileInputStream ("myfile.txt");

// Attribute assignment for "http.content-type"ret.value = "text/plain";

コネクターによって、http.content-length 属性が計算されます。したがって、この属性を指定する必要はありません。

関連情報97ページの『URL コネクター』, 31ページの『旧 HTTP サーバー・コネクター』, 28ページの『HTTP クライアント・コネクター』


HTTP クライアント・コネクターHTTP クライアント・コネクターは、URL コネクターより、HTTP セッションに対する高い制御能力を提供します。この HTTP コネクターを使用すると、事前定義済みの属性を使用して HTTP ヘッダーと本文を設定できます。また、ユーザーは、データを戻すサーバーへのどのような要求でも、属性として使用できます。

注: HTTP クライアント・コネクターは、拡張リンク基準をサポートしません(「IBM Tivoli Directory Integrator 5.2 ユーザーズ・ガイド」の『Advanced link

criteria』を参照してください)。

モードHTTP クライアント・コネクターは、3 つの AssemblyLine モードで使用できます。下記を参照してください。

イテレーター (Iterator)このコネクターを呼び出すたびに、このコネクター用に構成されている同じURL が要求されます。したがって、コネクターの構成にパーサーを組み込んでいない限り、コネクターは永続的に同じページを要求して実行を続けます。パーサーを組み込んである場合は、パーサーは接続から最後の項目が読み取られた時点で通知を送り、コネクターは最終的に AssemblyLine を終了させます。

ルックアップ (Lookup)このモードでは、コネクターは、ルックアップ関数が呼び出されるたびに 1

つのページを要求します。検索基準には、要求するページまたは URL を指定したり、任意の数のパラメーターを組み込むことができます。これらのパラメーターは、すべて要求パラメーターとして基本 URL に追加されます。

AddOnlyこのモードでは、コネクター要求はイテレーター・モードとほとんど同じように実行されます。

Call/Replyこのモードでは、コネクターには入力属性マップと出力属性マップの 2 つの属性マップがあります。AssemblyLine がコネクターを呼び出すと、出力マップ操作が行われ、続いて入力マップ操作が行われます。

ルックアップ・モードルックアップ・モードでは、次のように、検索基準を設定することにより動的に要求 URL を変更することができます。

v 基準が 1 つしかなく、属性の名前が url である場合は、その基準の中で指定した値が要求 URL として使用されます。

url equals $url

v 複数の基準があるか、または唯一の基準が url 以外のものである場合は、コネクター構成で要求 URL として指定されている URL に、すべての属性名と値が付加されます。

基本 URL: http://www.example_page_only.com/lookup.cgi

検索基準:


name equals johnmail equals doe.com

結果の URL:

http://www.example_page_only.com/lookup.cgi?name=john&mail=doe.com

v ルックアップ関数はオペランドを無視します。したがって、equals ではなくcontains を指定したとしても、コネクターは equals を使用したときと同じように URL を作成します。

特殊属性このコネクターをイテレーター・モードまたはルックアップ・モードで使用するときは、以下に示す属性またはプロパティーのセットがコネクター項目に戻されます。

http.responseCode整数オブジェクトとしての HTTP 応答コード。

200 OK —-> 200

http.responseMsgストリング・オブジェクトとしての HTTP 応答メッセージ。

200 OK —-> OK

http.content-type戻される http.body のコンテンツ・タイプ (存在する場合)。


http.content-lengthhttp.body のバイト数。

http.bodyこのオブジェクトは、戻された本文のバイトを読み取るために使用できる、java.io.InputStream クラスのインスタンス/サブクラスです。

var body = conn.getObject ("http.body");var ch;

while ( (ch = body.read()) != -1 ) {task.logmsg ("Next character: " + ch);

}

InputStream クラスおよびおよびそれぞれのメソッドについては、JavaDocs

を参照してください。

http.text-bodyhttp.content-type が text/ というシーケンスで始まっている場合は、コネクターは本文がテキスト・データであると判断し、http.body ストリーム・オブジェクトをこの属性に読み込みます。

このコネクターを AddOnly モードで使用しているときは、コネクターはヘッダー名に http. が付いている属性をすべて送信します。したがって、要求のコンテンツ・タイプを設定するには、属性に http.content-type という名前を付け、通常どおり


に値を指定します。特殊な属性の 1 つに http.body があり、これには、ストリングまたは任意の java.io.InputStream または java.io.Reader サブクラスを含めることができます。

どのモードの場合も、コネクターは必ず http.responseCode 属性およびhttp.responseMsg 属性を設定します。AddOnly モードでは、コネクターに渡される conn オブジェクトはこれらの属性の取り込み先オブジェクトなので特別です。これらの属性にアクセスするには、コネクターの After Add フック内の値を取得する必要があります。


HTTP URL要求する HTTP ページ。

注: https:// アドレスを使用する場合は、証明書のインポートも必要になることがあります。

要求メソッドページを要求するときに使用する HTTP メソッド。詳細については、http://www.w3.org/Protocols/HTTP/Methods.html を参照してください。

ユーザー名このパラメーターが設定されている場合は、HTTP 許可ヘッダーは、このパラメーターとパスワード・パラメーターを使用して設定されます。

パスワードユーザー名を指定した場合に使用されます。

プロキシーこれを指定した場合は、URL の中で指定されているホストに直接接続する代わりに、プロキシー・サーバーに接続します。形式は proxyhost:port です(例えば、proxy:8080)。ここで、proxy は proxyhost の名前で、8080 は使用するport 番号です。

HTTP 本文のファイルファイルの絶対パス。ファイル内容は、HTTP 本文として HTTP メッセージにコピーされます。

応答 HTTP 本文のファイルファイルの絶対パス。応答 HTTP メッセージの本文は、ファイルにコピーされます。


パーサーパーサーを指定した場合は、データを送信するときに、http.body のコンテンツを生成するためにそのパーサーが使用されます。パーサーは、名前がhttp. で始まっていない属性を持つ項目を取得します。さらに、このパーサー (指定されている場合) は、データの受信時に、追加の解析を行うために


http.body を取得します。ただし、メッセージ本文には別のメッセージは含まれないので、system:/Parsers/ibmdi.HTTP は指定しないでください。

例属性マップの中で以下の割り当てを使用して、ファイルのコンテンツを HTTP サーバーに通知することができます。

// Attribute assignment for "http.body"ret.value = new java.io.FileInputStream ("myfile.txt");

// Attribute assignment for "http.content-type"ret.value = "text/plain";

コネクターによって、http.content-length 属性が計算されます。したがって、この属性を指定する必要はありません。

関連情報97ページの『URL コネクター』, 32ページの『HTTP サーバー・コネクター』,

153ページの『HTTP パーサー』

旧 HTTP サーバー・コネクター

注: このコネクターは、レガシー目的のためにのみ保持されています。新規のコネクターを作成する場合は、代わりに HTTP サーバー・コネクターを使用してください。

旧 HTTP サーバー・コネクターは、着信 HTTP 接続を listen し、get パラメーターを項目として戻します。パーサーが指定されている場合は、コネクターは post要求を処理し、指定されたパーサーを使用してコンテンツを解析します。get 要求では、パーサーは使用されません。パーサーが指定されていないときに post 要求が受信された場合は、post データのコンテンツは属性 (postdata) として戻り項目に戻されます。

コネクターは、次のようにして、URL 要求を解析し、項目を取り込みます。

http://host/path?p1=v1&p2=v2

entry.path = "/path"entry.p1="v1"entry.p2="v2"

http://host?p1=v1&p2=v2

entry.path="/"entry.p1="v1"entry.p2="v2"

POST 要求が使用される場合は、リクエスターはこの接続を介してデータも送信しているものと見なされます。コネクターは、パーサー・パラメーターの値に応じて次のことを行います。

Parser presentHTTP 入力ストリームを使用して、パーサーをインスタンス化します。コネクターは getNext をパーサーの getEntry に委任し、パーサーが戻すものをそのまま戻します。


Parser not presentポスト・データのコンテンツを postdata という属性に入れます。

entry.postdata = "postdata"

コネクターが AssemblyLine から getNext 要求を受信したときに、取り出すデータが何も残っていなければ、HTTP クライアントとのセッションはクローズされます。例えば、パーサーが NULL 値を戻した場合や、パーサーが存在しない場合は、getNext が 2 回目に呼び出されるときです。また、コネクターから NULL 値を受信した後で、getNext を呼び出す (例えば、繰り返す) 場合です。


TCP ポートlisten する TCP ポート (デフォルト・ポートは 80)。


パーサーPOST 要求のコンテンツを取り扱うパーサーの名前。

関連情報97ページの『URL コネクター』, 『HTTP サーバー・コネクター』

HTTP サーバー・コネクターHTTP サーバー・コネクターは、着信 HTTP 接続を listen し、get パラメーターを項目として戻します。パーサーが指定されている場合は、コネクターは post 要求を処理し、指定されたパーサーを使用してコンテンツを解析します。get 要求では、パーサーは使用されません。パーサーが指定されていないときに post 要求が受信された場合は、post データのコンテンツは属性 (postdata) として戻り項目に戻されます。

HTTP サーバー・コネクターは、パーサーが指定されていない場合は、ibmdi.HTTP

を内部パーサーとして使用します。

コネクターは、次のようにして、URL 要求を解析し、項目を取り込みます。

http://host/path?p1=v1&p2=v2

entry.path = "/path"entry.p1="v1"entry.p2="v2"

http://host?p1=v1&p2=v2

entry.path="/"entry.p1="v1"entry.p2="v2"


POST 要求が使用される場合は、リクエスターはこの接続を介してデータも送信しているものと見なされます。コネクターは、パーサー・パラメーターの値に応じて次のことを行います。

Parser presentHTTP 入力ストリームを使用して、パーサーをインスタンス化します。コネクターは getNext をパーサーの getEntry に委任し、パーサーが戻すものをそのまま戻します。

Parser not presentポスト・データのコンテンツを postdata という属性に入れます。

entry.postdata = "postdata"

コネクターが AssemblyLine から getNext 要求を受信したときに、取り出すデータが何も残っていなければ、HTTP クライアントとのセッションはクローズされます。例えば、パーサーが NULL 値を戻した場合や、パーサーが存在しない場合は、getNext が 2 回目に呼び出されるときです。


TCP ポートlisten する TCP ポート (デフォルト・ポートは 80)。


パーサーPOST 要求のコンテンツを取り扱うパーサーの名前。

関連情報97ページの『URL コネクター』, 28ページの『HTTP クライアント・コネクター』, 153ページの『HTTP パーサー』

JDBC コネクターJDBC コネクターは、さまざまのシステムへのアクセスを提供します。 JDBC を使用していずれかのシステムに到達するには、システム・プロバイダーからの JDBC

ドライバーが必要です。このプロバイダーは、jar または zip ファイルの形式で製品と共に提供されます。これらのファイルはユーザーのクラスパス内に入れるか、または拡張ディレクトリーにコピーする必要があります。

注: JDBC コネクターは、Microsoft® Access 2000 およびそれ以降のバージョンでサポートされています。これは、Access 用の特定 JDBC コネクターであり、ODBC ブリッジを使用しません。ただし、どちらのアプローチも使用できます。旧バージョンの Access にアクセスするには ODBC ブリッジを使用してください。これは、ブリッジを使用して、Excel またはその他の ODBC として公開されたソースにアクセスするときと同じです。


標準 Java2 JDBC-ODBC ブリッジを使用する ODBC は、Windows システムでのみサポートされます。

市販の ODBC/JDBC ブリッジを使用できます。ODBC/JDBC ブリッジが必要な場合は、市販のブリッジの購入を検討してください。


JDBC URLJDBC プロバイダーの資料を参照してください。これは、IBM Directory

Integrator Config Editor では JDBC URL と呼ばれます。

ユーザー名このユーザーが使用できる表のみが提示されます。

パスワードユーザーのパスワード。

スキーマ使用するデータベースの表内のスキーマ。これをブランクのままにした場合は、jdbcLogin の値が使用されます。

JDBC ドライバーJDBC ドライバーのクラス名。

NULL 値を戻すこのパラメーターが true に設定されている場合は、空の属性 (空値のセット) として NULL 値が戻されます。false に設定されている場合は、属性は戻される項目に含まれません。

SQL SELECT繰り返しの対象の項目を選択するときに実行する SELECT ステートメント。このパラメーターをブランクのままにした場合は、デフォルトの構成(SELECT * FROMTABLE) が使用されます。

表名操作する表またはビュー。このパラメーターは、コネクターがルックアップ・モードまたは更新モードで稼働している場合のみ使用されます。SQLSelect パラメーターが指定されていない場合は、イテレーター・モードのコネクターも、このパラメーターを使用してデフォルトの SELECT ステートメントを構成します。

セッション・ステートメントの変更このパラメーターは、ALTER SESSION コマンドを指定するための複数行フィールドです。次に示すのは ALTER SESSION コマンドの例です。

"SET NLS_FORMAT ’YYYY-MM-DD’"

日付形式ストリングとして供給された日付を解析するために使用する書式制御ストリング。

コネクター・フラグ特定の動作を使用可能にするフラグのリスト。

{ignoreFieldErrors}


このフラグは、フィールドの値の取得結果がエラーになる場合に、例外をスローする (コネクターの *Fail EventHandler を呼び出す) 代わりに Java 例外オブジェクトを値として戻すように、コネクターに指示します。

コミットいつデータベース・トランザクションをコミットするかを制御します。オプションは、次のとおりです。

v 各データベース操作後

v コネクターのクローズ時

v 手動

手動とは、ユーザーが JDBC コネクターの commit() メソッドを呼び出す必要があることを意味します。


リンク基準Equal オペランドは等号 (=) に変換され、Contains、Start With、および EndWith 演算子は類似の演算子にマップされます。

その他このコネクターは、すべてのコネクターが公開する標準関数に加えて、ユーザーがスクリプト内で使用できる他のいくつかの関数も公開します。

execSQL (string)任意の SQL コマンドを開始します。失敗した場合はエラー・ストリングを戻します。

execSQLSelect (string)SQL SELECT コマンドを開始します。失敗した場合はエラー・ストリングを戻します。

getNextSQLSelectEntry ()execSQLSelect を開始した後で、このメソッドを使用して、結果セットから次の項目を取得することができます。

この関数が正しく機能するためには、コネクターの Table Name パラメーターが空であることが必要です。

上記の関数は、このコネクター用の通常の項目フローおよび属性マッピングを妨げることはありません。

metamerge.MySQL: これは JDBC コネクターのバリエーションの 1 つです。機能はJDBC コネクターと同じです。

タイム・スタンプ日付と時刻の両方を含むタイム・スタンプ値を保管するときは、次のような属性マッピングを使用できるように、必ず java.sql.Timestamp タイプのオブジェクトを指定するようにしてください。


a = java.util.Date();ret.value = new java.sql.Timestamp (a.getTime());

SQL データベース: 特殊文字を含む列名特殊文字を含む名前を持つ列があるときに、AddOnly モードまたは更新モードを使用する場合は、次のようにしてください。

1. 更新コネクターまたは AddOnly コネクターの属性マップに進みます。

2. コネクター属性の名前 (work 属性ではありません) を、name-with-dash から″name-with-dash″ に変更します (引用符を追加)。

この機能を使用する必要があるかどうかは、使用している JDBC ドライバーによっても異なりますが、標準の MS Access 2000 ではこの問題が生じます。

準備済みステートメントの使用このセクションでは、コネクターがどのように SQL 照会を作成するかについて説明します。このような内部の働きについて興味がない場合は、このセクションは飛ばしてもかまいません。

データベースに対して、コネクターは、状況に応じて準備済みステートメントまたは動的照会を使用します。

v データベースからスキーマ定義を取得する場合は、コネクターは準備済みステートメントを使用します。

v その他の場合は、コネクターは動的 SQL 照会を作成します。

複数項目時コネクターで複数項目を戻すリンク基準が設定されている場合に何が起きるかについて詳しくは、 181ページの『付録 B. AssemblyLine およびコネクター・モードのフローチャート』を参照してください。

削除モードまたは更新モードの JDBC コネクターについて setCurrent() メソッドを使用し、特に他のロジックを追加しなかった場合は、リンク基準を満たすすべての項目が削除または更新されます。

ODBC: データベース・パスの直接指定JDBC-ODBC ブリッジ (Windows システムのみでサポートされます) を使用するODBC 接続を使用する場合は、ODBC ドライバーで使用する必要があるデータベースまたはファイル・パスを指定できます (ODBC ドライバーで許可される場合)。このタイプの構成を使用すれば、コネクターが使用する各データベースまたはファイル・パスのデータ・ソース名を定義する必要がなくなります。

jdbcDriversun.jdbc.odbc.JdbcOdbcDriver

jdbcSourcejdbc:odbc:driver name;DBQ=path

MS Access がインストールされている場合ODBC データ・ソース制御パネルを開き、「ユーザー DSN」タブを選択します。このテーブルには、JDBC ソース・パラメーターで使用できるドライ


バー名が表示されます。例えば、MS Access データベース (c:¥my

documents¥mydb.mdb) にアクセスする場合は、JDBC ソースとして以下の値を指定します。

jdbc:odbc:MS Access Database;dbq=c:¥my documents¥mydb.mdb

MS Access がインストールされていない場合MS Access がインストールされておらず、Windows システムを使用している場合は、以下の値を使用します。

jdbc:odbc:Driver={MS Access Driver(*.mdb)};dbq=c:¥my documents¥mydb.mdb

JMS コネクターJMS コネクターは、IBMMQ Server などの JMS ベースのシステムへのアクセスを提供します。

JMS コネクターを稼働させるために、ご使用の IBM Tivoli Directory Integrator システムに対して何を行う必要があるかについては、『特定トピック』の項を参照してください。

このコネクターは、Java Message Server 製品を使用してネイティブ項目オブジェクトおよび XML テキストの両方を受け渡しできる通信を可能にします。

JMS コネクターは、JMS メッセージ・プロパティーをサポートしています。 JMS

コネクターがメッセージを受け取ると、その JMS メッセージからのプロパティーが conn オブジェクトに取り込まれます (これらのプロパティーにアクセスするには、項目クラスの getProperty() メソッドおよび setProperty() メソッドを参照してください)。conn オブジェクトのプロパティーは、jms. の接頭部で始まり、その後にJMS メッセージ・プロパティー名が続きます。プロパティーは、JMS メッセージからの値を保持します。ユーザーは、メッセージを送信するときにプロパティーを設定でき、これらのプロパティーは送信する JMS メッセージに渡されます。 JMS コネクターは、conn オブジェクトをスキャンして jms. で始まるプロパティーを見つけ、conn プロパティーからそれに対応する JMS メッセージ・プロパティーを設定します。

v JMS: correlationID=12 ——> conn jms.correlationID=12

v conn:jms.inReplyTo=12 ——> JMS:inReplyTo=12

conn オブジェクトを使用できるフックは限られています。「IBM Tivoli Directory

Integrator 5.2 ユーザーズ・ガイド」の『Conn object』を参照してください。

現在サポートされているのは、IBM MQ Series サーバーだけです。

JMS メッセージ・フローJMS コネクターが送信および受信するものは、すべて JMS メッセージです。JMS

コネクターは、IBM Tivoli Directory Integrator の項目オブジェクトを JMS メッセージに (またはその逆に) 変換します。各 JMS メッセージには、事前定義済みのJMS ヘッダー、ユーザー定義のプロパティー、そして、何らかの本文 (テキスト、バイト配列、または直列化 Java オブジェクト) が含まれています。


JMS バスとの通信を大幅に容易にする JMS コネクターの一部としてのメソッドに、acknowledge() があります。メソッド acknowledge() は、自動確認にチェックマークが付いていないときに、JMS セッションの消費済みメッセージをすべて明示的に確認するために使用します。コネクターの acknowledge() を呼び出すことにより、コネクターは、メッセージの配達先セッションで消費されたすべてのメッセージを確認します。自動確認にチェックマークが付いている場合は、acknowledge() の呼び出しは無視されます。

JMS コネクターを、IBM Tivoli Directory Integrator で使用可能なチェックポイント/

リスタート機能とともに配置するときには、受信メッセージの確認を慎重に考慮する必要があります (「IBM Tivoli Directory Integrator 5.2 ユーザーズ・ガイド」の『Checkpoint/Restart — Saving and storing AssemblyLine state information』を参照してください)。前述したように、JMS コネクターでは自動確認を使用せずに、AssemblyLine の JMS コネクターの直後にスクリプト・コネクターを挿入して、JMS コネクターの acknowledge() メソッドを呼び出すのが最良の方法です。こうすると、保管されるチェックポイント/リスタート・ストア内の関連メッセージ情報とJMS キュー通知との間のウィンドウが最小になります。このウィンドウで障害が発生した場合には、メッセージは再度受信されます。

逆に、自動確認に依存すると、キューのメッセージを検索 (および確認) した時点から、項目にマップされたメッセージの内容がチェックポイント/リスタート・ストアに保管されるまで存続するウィンドウが作成されます。このウィンドウで障害が発生した場合には、メッセージは失われるため、大きな問題となることがあります。

注: 自動確認がオンになっている場合に Config Editor で JMS コネクターを構成すると、問題が発生することがあります。これは、このような状況である限り、「スキーマ」 -> 「接続」 -> 「GetNext」、または入力マップから高速ディスカバーを実行してスキーマ・ディスカバリーのプロセスを行うと、メッセージが受信および消費される (つまり、入力キューからなくなる) ことが原因です。これによって、意図しない副次作用が起こる場合があります。このような状況を回避するには、スキーマ検出の前に自動確認をオフにします。ただし、こうした動作を望む場合には、オンに戻すことを忘れないでください。

JMS メッセージのタイプJMS 環境では、JMS バス上で異なるタイプのデータを送信できます。このコネクターは、3 つのデータ・タイプを認識します。この 3 つのタイプとは、テキスト・メッセージ、バイト・メッセージ、およびオブジェクト・メッセージと呼ばれるものです。最も制約の少ないストラテジーはテキスト・メッセージを使用するもので(例えば、jms.usetextmessages=true)、この場合は、IBM Tivoli Directory Integrator

以外のアプリケーションで、JMS コネクターが生成するメッセージを読み取ることができます。

JMS バスを介して他の IBM Tivoli Directory Integrator サーバーと通信する場合、バイト・メッセージを使用すると、非常に単純に項目オブジェクト全体を宛先に送信できます。これは、特に、テキストでは簡単に表せない特殊な Java オブジェクトが項目オブジェクトに含まれている場合にも便利です。ほとんどの Java オブジェクトは、ストリング表現を戻す toString() メソッドを提供しますが、その逆が可能なことはきわめてまれです。さらに、toString() メソッドは必ずしも有用な情報を戻すとは限りません。例えば、バイト配列のストリング表現は、次のようになります。


"[B@<memory-address>"

テキスト・メッセージテキスト・メッセージはテキストの本文を伝達します。テキスト自体の形式は定義されていないので、事実上何でもかまいません。このタイプのメッセージを送受信するとき、コネクターは、ユーザーがパーサーを指定しているかどうかに応じて、次の 2 つのいずれかを行います。

v パーサーを指定してある場合は、コネクターはそのパーサーを呼び出してテキスト・メッセージを解釈し、属性、ヘッダー、およびプロパティーを戻します。メッセージを送信するときは、指定した conn オブジェクトがパーサーに渡されて、テキスト本文部分が生成されます。したがって、さまざまな形式のデータをJMS バスに乗せて簡単に送信できます (例えば、LDIF パーサー、XML パーサーなどを使用)。また、Simple Object Access Protocol (SOAP) パーサーを使用して、JMS バスを介して SOAP 要求を送信することもできます。

v パーサーを定義していない場合は、テキスト本文はメッセージと呼ばれる属性に入れて戻されます。メッセージを送信するときは、コネクターは、指定されたメッセージ属性を使用して JMS テキスト本文部分を設定します。

var str = work.getString ("message");task.logmsg ("Received the following text: " + str );

多様な形式のテキスト・メッセージ (XML、LDIF、CSV など) を受信することが予測される場合は、パーサー・パラメーターをブランクのままにしておき、テキスト・メッセージがどのような形式かを自分で判断する必要があります。形式が分かれば、次のように system.parseObject(parserName, data) 構文を使用して解析することができます。

var str = work.getString ("message");// code to determine formatif ( isLDIF )

e = system.parseObject( "ibmdi.LDIF", str );else if ( isCSV )

e = system.parseObject ( "ibmdi.CSV", str );else

e = system.parseObject ( "ibmdi.XML", str );}// Dump parsed entry to logfiletask.dumpEntry ( e );

Textmessage の使用フラグは、メッセージを送信するときにこのメソッドを使用するかどうかを、コネクターに指示します。

オブジェクト・メッセージオブジェクト・メッセージは、直列化 Java オブジェクトを含むメッセージです。直列化 Java オブジェクトは、特定の形式のバイト・ストリームに変換された Java オブジェクトで、これを使用することにより、受信側でのオブジェクトの復活が可能になります。テストの結果では、送信側と受信側の両方で JMS サーバーが Java クラス・ライブラリーを利用できる状態にあれば、この機能が正しく働くことが分かっています。一般に、java.lang.String オブジェクトは問題を起こすことはありませんが、他の Java オブジェクトについては問題が起きる可能性があります。このため、JMS コネクターでは、オブジェクト・メッセージの生成はしませんが、この種のメッセージを受信することはできます。オブジェクト・メッセージを受信すると、コネクターは次の 2 つの属性を戻します。


java.objectこの属性は Java オブジェクトを保持するもので、このオブジェクトにアクセスするには、work または conn 項目内で getObject メソッドを使用します。

java.objectClassこの属性は、Java オブジェクトのクラス名 (ストリング) を保持する簡易属性です。

var obj = work.getObject ("java.object");obj.anyMethodDefinedForTheObject ();

受信されるのはこれらのメッセージだけです。

バイト・メッセージバイト・メッセージは、任意のバイト配列を伝達するメッセージです。 JMS コネクターは、Textmessage の使用フラグが false の場合にこのタイプのメッセージを生成します。このコネクターは、指定された項目を直列化してバイト配列にし、バイト・メッセージとしてメッセージを送信します。バイト・メッセージを受信すると、このコネクターは、まずバイト配列を非直列化して項目オブジェクトにしようとします。これが失敗した場合は、そのバイト配列がメッセージ属性に入れて戻されます。このオブジェクトにアクセスするには、作業項目または conn 項目内でgetObject メソッドを使用する必要があります。

var ba = work.getObject ("message");for ( i = 0; i < ba.length; i++)

task.logmsg ( "Next byte: " + ba [ i ] );

このタイプのメッセージが生成されるのは、Textmessage の使用が false である(チェックされていない) 場合だけです。

イテレーター・モードメッセージ・キューの内容全体に対する繰り返しのほかに、構成で使用可能なパラメーターでは、キューまたはトピックに戻す特定のメッセージを選別するためのメッセージ・フィルターを指定できます (トピックは Pub/Sub とも呼ばれます)。メッセージ・フィルター仕様は、SQL92 のサブセットです。

CallReply モードこのモードでは、コネクターは、入力属性マップと出力属性マップの両方があります。

ルックアップ・モードこのコネクターは、ルックアップ・モード (例えば、findEntry) をサポートします。このモードでは、JMS キュー内で一致するメッセージを検索することができます (ルックアップ・モードではトピック (Pub/Sub) はサポートされていません)。

リンク基準は、キュー上の一致するメッセージを選択するための JMS ヘッダーおよびプロパティーを指定します。

拡張リンク基準の場合は、JMS 仕様 (http://java.sun.com/products/jms) で記述されているメッセージ選択仕様に従う必要があります。 JMS コネクターは SQL フィルタ


ー仕様を再使用して (JMS メッセージ選択は SQL92 のサブセットです)、メッセージ選択ストリングを作成します。生成されたメッセージ・フィルター・ストリングを見るには、デバッグ・モードをオンにしてください。

ルックアップを行うには、基本的に 2 つの方法があります。

v キュー内で非破壊検索を行う (QueueBrowser を使用)。JMS キューからメッセージを削除せずに、一致するメッセージが戻されます。

v 一致するすべての項目を JMS キューから削除する。

どちらを使用するかを設定するには、コネクター構成内でルックアップの除去フラグを設定します。トピック接続の場合は、トピック上のメッセージはサブスクライバーがそれを受信した時点で常に削除されるので、ルックアップの除去フラグは適用されません。ただし、ルックアップ・モードでは永続サブスクライバー・フラグに留意します。このフラグが設定されている場合は、JMS サーバーは、ユーザーが切断された後もトピックで送信されたメッセージをすべて保持します。

JMS コネクターでも、他のコネクターの場合と同様に、AssemblyLine 設定の中で、戻される項目の最大数を指定することができます。ルックアップで単一のメッセージのみが検索されるようにするには、AssemblyLine 設定の中で、戻される重複項目の最大数 = 1 を指定します。戻される重複項目の最大数を 1 に設定すると、JMS

キュー内に一致するメッセージがいくつあっても、一致する項目を一度に 1 つずつ検索することができます。

JMS バスは非同期なので、JMS コネクターでは、ルックアップ機能がどの時点でメッセージ検索を停止するかを指示するためのパラメーターを使用できます。この種のパラメーターは 2 つあります。1 つは JMS キューを何回照会するかをコネクターに指示し、もう 1 つは、照会中に新しいメッセージを待つ時間を指示します。再試行回数に 10、タイムアウトに 1000 を指定したとすれば、コネクターは JMS キューを 10 回照会し、1 回ごとに 1 秒ずつ新規メッセージを待ちます。この時間内にメッセージが受信されない場合は、コネクターは戻ります。照会中にメッセージを受信した場合は、コネクターはさらに追加のメッセージの有無をチェックします(これにはタイムアウトはありません)。これは、キューからメッセージが戻されなくなるか、または、受信したメッセージの数が AssemblyLine で定義されている戻される重複項目の最大数の限界に達するまで続けられます。この方法には、ルックアップ操作により、その時点で使用可能なメッセージのみが検索されるという利点があります。

JMS のヘッダーとプロパティーJMS メッセージは、ヘッダー、プロパティー、および本文から構成されます。ヘッダーはプロパティーとは異なる方法でアクセスされ、旧バージョンではこれは使用できませんでした。現バージョンでは、ヘッダーとプロパティーをどのように扱うかを指定することができます。

JMS ヘッダーJMS ヘッダーは、すべてのメッセージ内に存在する事前定義された名前付きの値です (値は NULL の場合もあります)。このコネクターは、以下に挙げる JMS ヘッダー名をサポートしています。


JMSCorrelationID(ストリング) アプリケーションは、他のアプリケーションで使用するためにこのヘッダーを設定します。

JMSDeliveryMode(整数) このヘッダーは JMS プロバイダーが設定するもので、配送モードを示します。

JMSExpires(long 型) 値が 0 の場合は、メッセージの有効期限がないことを意味します。その他の値は、メッセージがキューから削除されるまでの有効期限を示します。

JMSMessageID

(ストリング) 固有のメッセージ ID。これは必須フィールドではなく、値はNULL でも構いません。

JMS プロバイダーはユーザー指定のメッセージ ID を使用しないことがあるので、コネクターは、メッセージを送信した後で $jms.messageid という特殊プロパティーを設定します。これは、ユーザーが常にそのメッセージID を使用できるようにするためです。この値を検索するには、After Addフックの中で conn.getProperty("$jms.messageid") を使用します。

JMSPriority(整数) メッセージの優先順位。

JMSTimestamp(long 型) メッセージが送信された時刻。

JMSType(ストリング) メッセージのタイプ。

JMSReplyTo

(宛先) 送信側が応答の宛先として予期しているキュー/トピック。メッセージを受信するときは、この値はプロバイダー固有の宛先インターフェース・オブジェクトであり、通常これは内部のキュー・オブジェクトまたはトピック・オブジェクトです。メッセージを送信するときは、着信宛先オブジェクトを再使用するか、この値を有効なトピック/キュー名に設定する必要があります。この値が NULL (例えば、値のない属性) か、ストリング"%this%" である場合は、コネクターは独自のキュー/トピックを値として使用します。この方式と、キュー/トピックを明示的に設定する方式との違いは、ユーザーがコネクター構成のキュー/トピック名を変更した場合に、属性割り当てを更新する必要がないという点です。

現行バージョンには、制約事項が 1 つあります。それは、ユーザーが現在接続しているものと同じタイプの接続に対する応答しか要求できないという点です。つまり、トピックに関するメッセージを発行してキューへの応答を要求すること、またはその逆を行うことはできないということです。

このヘッダーに応答することは必須条件ではないので、メッセージの受信側がこのフィールドを完全に無視したとしても何の弊害も生じません。

上記のヘッダーはすべてプロバイダーが設定するもので、JMS ドライバーによって出力メッセージ用に処理される場合があります。構成画面では、すべてのヘッダー


を属性として戻すことを指定することも、関心のあるヘッダーのリストを指定することもできます。すべてのヘッダーには、jms. という接頭部付きの名前が付けられます。また、JMS ヘッダー名は必ず JMS というストリングで始まるという点にも注意してください。したがって、jms.JMS で始まるプロパティー名は決して使用しないでください。このような名前は、ヘッダーとして解釈されてしまいます。

JMS プロパティーこのコネクターの旧バージョンでは、項目オブジェクトと JMS メッセージの間ですべての JMS プロパティーがコピーされていました。現行リリースでは、ユーザー定義のすべてのプロパティーを属性として戻すことをコネクターに指示することも、関心のあるプロパティーのリストを指定することもできるので、この動作を細かく設定できるようになりました。すべてのプロパティーには、他の属性と区別するために、jms. という接頭部が付けられます。プロパティーのリストをブランクのままにし、属性としての JMS プロパティー・フラグにチェックマークを付けていない場合の動作は、旧バージョンの場合と同じになります。JMS ヘッダーと異なり、JMS プロパティーがユーザーが設定できます。後方互換モードを使用する場合は、次の例のように、Before Add フックの中で項目プロパティーを設定する必要があります。

conn.setProperty ( "jms.MyProperty", "Some Value" );

属性としての JMS プロパティー・フラグにチェックマークを付けるか、プロパティーのリストを指定した場合は、JMS プロパティーを属性として指定する必要があります。そのための方法の 1 つは、jms. 接頭部を使用して属性を属性マップに追加することです。例えば、jms.MyProperty を属性マップに追加すると、MyProperty という名前の JMS プロパティーができることになります。


ブローカーJMS サーバーの URL。

サーバー・チャネルMQ サーバー用に構成されたチャネルの名前。

SSL 接続を使用SSL 接続に必要なパラメーターおよび構成設定を使用可能にします。

SSL サーバー・チャネルSSL を使用して MQ サーバーにアクセスするために構成されたチャネルの名前。

キュー・マネージャーMQ サーバー用に定義されたキュー・マネージャーの名前。

SSL CipherSuiteMQ サーバー・チャネルの構成時に選択された暗号に対応する CipherSuite

名。

ユーザー名JMS へのアクセス認証用のユーザー名。


パスワードJMS へのアクセスを認証するためのパスワード。

接続タイプキューまたはトピック (トピックは Pub/Sub と呼ばれることもあります)

のどちらに接続するかを指定します。

トピック/キューメッセージを交換する相手のトピック。

耐久トピック・サブスクライバートピック (Pub/Sub) 接続タイプのみに関連。true の場合、コネクターは永続サブスクライバーを作成します。これは、コネクターがオフラインのときも、サーバーがトピックに関するメッセージを後で検索できるように保管しておくことを意味します。

クライアント IDトピック接続に使用するクライアント ID (耐久の場合は必須)。

メッセージ選択フィルタートピック/キューからメッセージを選択するためのメッセージ・フィルターを指定します。これはイテレーター・モードでのみ使用されます。

GetNext タイムアウトイテレーター・モードにおいて、新規項目を待つ時間 (ミリ秒単位)。-1 は永久を示します。

JMS サーバー・タイプJMS サーバー・タイプを選択します。

自動確認true の場合は、このコネクターは自動的に各メッセージの受信通知を送ります。false の場合は、ユーザーが手動で JMS メッセージの受信を通知する必要があります (コネクターの acknowledge() メソッドを使用)。このパラメーターがオフの場合は、JMS CLIENT_ACKNOWLEDGE モードが使用されます。

Textmessage の使用true の場合、コネクターは、指定されたパーサーを使用してテキスト本文を生成するか、事前定義済みのメッセージ属性をテキスト本文として使用して、Textmessage を作成し、項目オブジェクトを送信します。

属性としての JMS ヘッダーtrue の場合、イテレーター・モードおよびルックアップ・モードでは、すべての JMS ヘッダーが属性として戻されます (jms. の接頭部が付けられます)。AddOnly モードでは、jms.JMS で始まる属性はすべて JMS ヘッダーと見なされます。その結果、これらの属性は JMS ヘッダーとして設定され、メッセージの送信前に項目オブジェクトから削除されます。

注: 設定できるヘッダーはわずかであり、設定したとしても JMS プロバイダーが必ずそのヘッダーを使用するとは限りません。


特定 JMS ヘッダー属性としての JMS ヘッダーと同様ですが、リストされる JMS ヘッダーがヘッダーとして扱われる点が異なります。ヘッダーは 1 行に 1 つずつ指定してください。

属性としての JMS プロパティーtrue の場合、イテレーター・モードおよびルックアップ・モードでは、すべての JMS プロパティーが属性として戻されます (jms. の接頭部が付けられます)。AddOnly モードでは、jms. で始まる属性はすべて JMS プロパティーと見なされます。その結果、これらの属性は JMS プロパティーとして設定されます。

特定 JMS プロパティー属性としての JMS プロパティーと同様ですが、リストされる JMS プロパティーがプロパティーとして扱われる点が異なります。プロパティーは 1

行に 1 つずつ指定してください。

ルックアップの除去true の場合は、ルックアップで検出された各メッセージはキューから削除されます。

注: AssemblyLine 設定の中で戻される重複項目の最大数パラメーターを使用して、ルックアップで項目が 1 つしか戻されないようにできます。

false の場合は、メッセージは通常どおりに戻されますが、キューから削除はされません。

ルックアップ再試行回数ルックアップ機能が、一致するメッセージを見つけるためにキューを検索する回数。

ルックアップ・タイムアウトコネクターが、1 回のルックアップ照会で新しいメッセージを待つ時間 (ミリ秒)。このパラメーターを使用するのは、ルックアップの除去が true に設定されている場合のみです。


パーサーパーサーを指定すると、JMS テキスト・メッセージはこのパーサーを使用して解析されます。このパーサーは、JMS コネクターが受信したメッセージを処理し、また、JMS コネクターがメッセージを送信するときにテキスト・メッセージを生成するために使用されます。

例ご使用の IBM Tivoli Directory Integrator システムの root_directory/examples/jms ディレクトリーにあります。

特定トピック以下に示すのは、IBM Tivoli Directory Integrator の jars ディレクトリーまたはクラスパスに追加する必要があるいくつかのファイルです。


IBM MQ Series

WebSphere® MQ 5.3:

v com.ibm.mqjms.jar

v com.ibm.mq.jar

v jms.jar

v connector.jar

他のバージョンの MQ では、異なる .jar ファイルが必要な場合があります(すべて MQ をインストールしたシステムの java/lib ディレクトリーに入っています)。

SSL の使用可能化Secure Socket Layer (SSL) セッションを使用可能にするには、まず MQ サーバーでチャネルを構成する必要があります。この作業を実行する方法の詳細は、http://www7b.software.ibm.com/wsdd/techjournal/0211_yusuf/yusuf.html (Dr Kareem

Yusef、2002 年 11 月) の Technical Journal Article「Configuring SSL Connections

between JMS Clients and the WebSphere MQ JMS Provider」に記載されています。この記事には、SSL テストの実行に必要な証明書の取得および管理についての説明も記載されています。

SSL 構成を使用するには、事前に IBM MQ バージョン v5.3、Service Level 5.3.0.4

(フィックスパック CSD04) をインストールする必要があります。IBM Tivoli

Directory Integrator を始動する前に、root_directory\global.properties ファイルにtrustStore および keyStore 設定を指定します。例 :

javax.net.ssl.trustStore=d:\\jdk141\\jre\\lib\\security\\cacertsjavax.net.ssl.trustStorePassword=javax.net.ssl.trustStoreType=

javax.net.ssl.keyStore=C:\\Program Files\\IBM\\WebSphere MQ\\Java\\bin\\jmskeystorejavax.net.ssl.keyStorePassword=changeitjavax.net.ssl.keyStoreType=jks

JNDI コネクターJNDI コネクターは、さまざまの JNDI サービスへのアクセスを提供します。特定のシステムに到達するためには、そのシステム用の JNDI ドライバーをインストールする必要があります。ドライバーは、通常、1 つ以上の jar または zip ファイルとして配布されます。これらのファイルは、Java ランタイムから到達できるような場所に入れておいてください (例えば、lib/ext ディレクトリー)。


JNDI ドライバーJNDI ドライバーのクラス名。

プロバイダー URL接続の URL。


参照 LDAP サーバーが見つけた参照をどのように処理するかを指定します。指定できる値は、以下のとおりです。

v follow: 自動的に参照に従います。

v ignore: 参照を無視します。

v throw: 参照が見つかった時点で ReferralException をスローします。これはエラー・フックの中で処理する必要があります。

認証メソッド認証メソッド。

ログイン・ユーザー名プリンシパル名 (例えば、username)。

ログイン・パスワード信任状 (例えば、password)。

名前パラメーターAssemblyLine 項目内のどのパラメーターを項目の名前に使用するかを指定します。これは、追加、変更、および削除操作で使用され、読み取りまたは検索操作時に戻されます。このパラメーターを指定しない場合は、$DN が使用されます。

プロバイダー・パラメータープロバイダーに受け渡す追加のプロバイダー・パラメーターのリスト。行ごとにパラメーター :値を指定します。

検索ベースディレクトリーの繰り返しの際に使用する検索ベース。識別名を指定します。ディレクトリーによっては、ブランク・ストリングを指定することができます。その場合は、デフォルトにより、サーバーについて設定されている処置がとられます。ディレクトリー・サービスによっては、そのディレクトリー内の有効な識別名を指定しなければならないこともあります。

検索フィルターディレクトリーの繰り返しの際に使用する検索フィルター。

検索範囲データ・ソースの繰り返しの際に使用する検索範囲。指定できる値は、次のいずれかです。

subtree検索ベースおよびその下位にあるすべてのレベルの項目を戻します。

onelevel検索ベースの直下にある項目のみを戻します。



変更操作の設定JNDI コネクターでは、コネクターが変更モードのときに変更操作を設定できます。また、変更操作を設定する代わりに、単純なコネクター・インターフェースを使用して、属性値や属性を直接追加、除去、または置換することもできます。

変更操作を設定するための Config Editor は提供されていません。変更モードで次のインターフェースを使用して、JNDI コネクターの作業項目の各属性に操作値を手動で追加する必要があります。

di.com.ibm.di.entry.Attribute.setOper(char operation) 操作

di.com.ibm.di.entry.Attribute.ATTRIBUTE_DELETEこの定数は、指定された属性値を属性から削除します。

その結果、属性には元の値セットから指定された値セットを除いた値セットが含まれます。値が指定されない場合は、属性全体を削除します。属性が存在しないか、指定された値セットの一部またはすべてのメンバーが存在しない場合は、そのことが無視されて操作が成功するか、存在しないことを示す例外がスローされます。属性に少なくとも 1 つの値が必要な場合は、最後の値を除去すると、属性も除去されます。

di.com.ibm.di.entry.Attribute. ATTRIBUTE_REPLACEこの定数は、属性を指定された値に置換します。

属性が既に存在する場合は、この定数はすべての既存の値を新たに指定された値に置換します。属性が存在しない場合は、この定数は属性を作成します。値が指定されない場合は、この定数は属性のすべての値を削除します。属性に少なくとも 1 つの値が必要な場合は、最後の値を除去すると、属性も除去されます。これはデフォルトの変更操作です。

di.com.ibm.di.entry.Attribute. ATTRIBUTE_ADDこの定数は、属性を指定された値に追加します。

属性が存在しない場合は、この定数は属性を作成します。その結果、属性には指定された値セットと元の値セットの結合が含まれます。

変更インターフェースの呼び出し

属性への値の追加:

public void addAttributeValue(String moddn, String modattr, String modval)

例外をスローします。ここで、

v moddn: 属性値を追加する DN

v modattr: 値を追加する属性の名前

v modval: modattr に追加する値

例えば、"cn=bob" を "cn=mygroup" の members 属性に追加する場合は、次のメソッドを使用します。

addAttribute("cn=mygroup","members","cn=bob");


基礎的な変更操作が失敗すると、例外がスローされます。

属性値の置換:

public void replaceAttributeValue(String moddn, String modattr, String modval)


v moddn: 属性値を置換する DN

v modattr: 値を置換する属性の名前

v modval: modattr を置換する値

例えば、″cn=mygroup″ の members 属性を ″cn=bob″ のみに置換する場合は、次のメソッドを使用します。

replaceAttribute("cn=mygroup","members","cn=bob");


属性の除去:

public void removeAttribute(String moddn, String modattr)


v moddn: すべての属性値を除去する DN

v modattr: すべての値を除去する属性名

例えば、″cn=mygroup″ の members 属性を除去する場合は、次のメソッドを使用します。

removeAttribute("cn=mygroup","members");


属性からの特定の属性値の除去:

public void removeAttributeValue(String moddn, String modattr, String modval)


v moddn: 属性値を除去する DN

v modattr: 変更する属性名

v modval: 指定した属性から除去する値


変更操作変更操作は、変更要求ごとに設定できます。これにより、変更要求項目内のすべての属性に対する変更操作が適切な変更操作値に設定されます。プロパティー値とマッチングする変更操作値は、次のとおりです。

プロパティー値(ストリング)

変更操作値

delete di.com.ibm.di.entry.Attribute.

ATTRIBUTE_DELETE


add di.com.ibm.di.entry.Attribute.

ATTRIBUTE_ADD

replace di.com.ibm.di.entry.Attribute.

ATTRIBUTE_REPLACE

このプロパティーは、次のスクリプトから modOperation プロパティーを設定することにより、コネクターの実行時にいつでも設定できます。

setProperty("modOperation","delete");

注: このプロパティーは、上記で定義されたインターフェースの動作には影響しません。ただし、di.com.ibm.di.entry.Attribute.setOper(char operation) を使用すると、既存の変更操作設定が上書きされます。

関連情報『LDAP コネクター』

LDAP コネクターLDAP コネクターは、さまざまな LDAP ベースのシステムへのアクセスを提供します。このコネクターは、LDAP バージョン 2 および 3 の両方をサポートしています。

他のほとんどのコネクターと異なり、LDAP ディレクトリーにオブジェクトを挿入するときは、他のコネクターで指定する属性に加えて、オブジェクト・クラス属性と $dn 属性も指定する必要があるという点に注意してください。次に示すコードをプロローグに挿入すると、後で使用できる objectClass 属性が定義されます。

// This variable used to set the object class attributevar objectClass = system.newAttribute ("objectclass");objectClass.addValue ("top");objectClass.addValue ("person");objectClass.addValue ("inetorgperson");objectClass.addValue ("organizationalPerson");

これで、

ret.value = objectClass

の割り当てを使用することにより、LDAP コネクターは objectclass という属性を持つことができます。

person クラスがどのような属性を持つかを確認するには、http://ldap.akbkhome.com/objectclass/person.html を参照してください。

これを見ると、更新または追加コネクター内で sn および cn 属性を指定する必要があることが分かります。

さらに、LDAP コネクターでは、識別名に対応する $dn 属性も必要です。属性マップ内に、iuid という名前の作業オブジェクト内の属性の 1 つとして $dn を作成するには、次のようなコードを使用します。

var tuid = work.getString("iuid");ret.value = "uid= " + tuid + ",ou=people,o=example_name.com";


注:

1. 項目の更新に加えて移動も行いたい場合以外は、更新モードでの変更には、$dnおよび objectclass の 2 つの特殊属性は含めないでください。

2. ディレクトリーに接続できない場合は、構成の「SSL の使用」フラグが、ディレクトリーが要求している状態に合わせて設定されていることを確認してください。

3. ルックアップを行うときは、コネクター属性として $dn を使用し、識別名を使用してルックアップを行ってください。$dn と他の属性の両方を使用する単純リンク基準は指定しないでください。

4. ある種のサーバーには、すべてのデータの選択ができないようにするサイズ制限パラメーターがあります。これが使用されている場合、イテレーターは最初の n

個の項目しか戻さないため、不便な場合があります。一部のサーバー (例えば、Netscape/iPlanet) では、ユーザーがマネージャーとして認証されていれば、このサイズ制限を超過することができます。

5. 1 回の実行でディレクトリー全体を戻すサーバー (例えば非ページ検索) の場合は、クライアント・サイドでメモリーの問題を引き起こすことがよくあります。54ページの『LDAP コネクターでのメモリーの問題の取り扱い』を参照してください。

6. コネクター・フラグに deleteEmptyStrings の値が含まれている場合は、LDAP

コネクターは、各属性について空のストリング値を除去します。これにより、属性に値がまったく含まれなくなることがあります (例えば、空の値セット)。属性に空の値セットがある場合は、変更操作により、その属性はディレクトリー内の項目から削除されます。空の属性は許可されないため、追加操作では組み込まれません。空でない場合、項目変更では属性値は置換されます。

7. コネクター・フラグに deleteEmptyStrings が含まれていない場合は、空ストリングは有効な値としてディレクトリー・サーバーに渡されます。ほとんどのサーバーは、空ストリングで置換する要求を、属性そのものを削除する要求と解釈します。この動作を制御する場合は、次の例のように、Before Update フックの中で項目を変更する関数を呼び出すことができます。

removeBlanks (work);

function removeBlanks (entry) {var list = entry.getAttributeNames();for (i = 0; i < list.length; i++) {if (entry.getString(list[i]) == "") {entry.removeAttribute (list[i]);}}}


LDAP URL接続の LDAP URL (ldap://host:port)。

ログイン・ユーザー名サーバーへの認証に使用する識別名。

ログイン・パスワード信任状 (パスワード)。




検索範囲このパラメーターは、コネクターがイテレーター・モードの場合のみ使用されます。指定できる値は、以下のとおりです。



時間制限項目の検索を行う最大時間 (秒)。0 = 無制限。

サイズ制限検索または繰り返しの結果として戻す最大項目数。0 = 無制限。

ページ・サイズこれを指定した場合は、LDAP コネクターはページ・モードの検索を試行します。ページ・モードでは、ディレクトリー・サーバーは、1 つのチャンク内のすべての項目を戻すのではなく、特定数の項目 (ページと呼ばれる) を戻します。このオプションをサポートしていないディレクトリー・サーバーもあります。

コメントユーザーのコメントを入力します。

認証メソッドLDAP 認証のタイプ。これは、次のいずれかです。

v 単純 (ログイン・ユーザー名とログイン・パスワードを使用。ログイン・ユーザー名とログイン・パスワードを指定しない場合は、無名と見なされます)。

v MD5-CRAM。

v SASL。

v 無名 (ログイン・ユーザー名とログイン・パスワードが指定されている場合は、単純と見なされます)。

SSL の使用これにチェックマークを付けると、LDAP サーバーとの通信に Secure

Sockets Layer が使用されます。

参照 LDAP サーバーが見つけた参照をどのように処理するかを指定します。指定できる値は、以下のとおりです。

v follow: 自動的に参照に従います。


v ignore: 参照を無視します。

v throw: 参照が見つかった時点で ReferralException をスローします。これはエラー・フックの中で処理する必要があります。

コネクター・フラグ特定の動作を使用可能にするフラグ。

deleteEmptyStringsこのフラグを使用すると、コネクターは、ディレクトリーを更新する前に、値として空ストリングのみを含んでいる属性を削除します。LDAP バージョン 3 サーバーを使用している場合は、属性の値を空ストリングにすることはできないので、必ずこのフラグを使用してください。

追加のプロバイダー・パラメーター追加の JNDI プロバイダー・パラメーター。行ごとにコロンで区切ったname:value のペアを 1 つずつ入れた形式を使用してください。

戻り属性戻す属性のリスト (1 行に付き 1 属性)。このパラメーターを空のままにした場合は、すべての属性が戻されます。

バイナリー属性バイナリーとして扱われる属性のリスト。 1 行に 1 つずつ属性を入力してください。このパラメーターを指定しなかった場合は、デフォルトの属性リストが使用されます。デフォルトのリストは以下のとおりです。

v photo

v personalSignature

v audio

v jpegPhoto

v javaSerializedData

v thumbnailPhoto

v thumbnailLogo

v userPassword

v userCertificate

v authorityRevocationList

v certificateRevocationList

v crossCertificatePair

v x500UniqueIdentifier

v objectGUID

v objectSid

注: 1 つの AssemblyLine が持つことのできるバイナリー属性のリストは 1

つだけです。1 つの AssemblyLine 内に複数の LDAP コネクターがあるときに、デフォルトのリストを変更する必要がある場合は、最後のコネクターで、その AssemblyLine 内のすべての LDAP コネクター用のバイナリー属性のリストを定義してください。

AD パスワードの自動マップ


LDAP を使用して、Active Directory におけるユーザーのパスワードを追加または更新するために使用します。これにチェックマークを付けた場合は、LDAP パスワード (userPassword と呼ばれる conn 属性) が別の名前(unicodePwd) にマップされます。unicodePwd には、コネクターが変換を行う特殊な形式があります。

LDAP トレース・ファイルLDAP BER パケットをファイルにトレースします。

属性のソートサーバー・サイドのソートを指定する新しいパラメーター。Netscape/iPlanet 4.2 では使用できません。

注: サーバー上のひずみが増加します。

仮想リスト・ビュー・ページ・サイズ繰り返しのための仮想リスト・ビューを使用します。これは一部のサーバーには効果がある可能性がありますが、テストの結果、その他のサーバー (例えば、Netscape/iPlanet 4.2) の速度が極度に低下することが示されています。ただし、メモリー不足が生じた場合の次善策としては利用できます。

名前変更のシミュレートサーバーで名前変更がサポートされていない場合に、削除または追加操作でシミュレートします。

属性の追加 (置換しない)このオプションは、項目の変更時に LDAP コネクターのデフォルトの動作を変更します。

このチェック・ボックスにチェックマークを付けると、LDAP コネクターはDirContext.ADD_ATTRIBUTE の制約を設定します。このチェック・ボックスにチェックマークを付けない場合、LDAP コネクターはDirContext.REPLACE_ATTRIBUTE の制約を設定します。

LDAP 接続に DirContext.ADD_ATTRIBUTE 制約を設定すると、AssemblyLine で処理される任意の属性に新しい値が追加されます。したがって、この制約を慎重に使用しないと、項目に同じ値が繰り返し追加されてしまいます。また、対象の属性が一価である場合に、例外が発生することがあります。DirContext.REPLACE_ATTRIBUTE を設定すると、動作は旧LDAP コネクターと同じになります (デフォルト動作)。つまり、属性のすべての値が作業項目の内容で置換されます。


LDAP コネクターでのメモリーの問題の取り扱いサーバーには、検索結果の全体を一度に戻すものがあり (例えば非ページ検索)、その場合はしばしばメモリーの問題が発生します。この状況は、ユーザーには IBM

Tivoli Directory Integrator でメモリー・リークが起きているように見えることがありますが、これは、サーバーが次から次へと送り込んでくる項目を Directory Integrator

が次々に処理しているために、そう見えるだけです。


Active Directory などの LDAP サーバーは、ページ検索拡張機能をサポートしており、ページ (一度に戻すオブジェクト数) を検索できます。これは、大規模な戻りセットを取り扱うための望ましい方法です (詳細については、ページ・サイズ・パラメーターを参照してください)。サーバーがページ検索をサポートしているかどうかは、LDAP コネクターの「構成」タブで、ページ・サイズ・パラメーターの右側にあるボタンをクリックすることにより、いつでも確認できます。

ページ・サイズ・パラメーターがサポートされていない場合は、クライアントはサーバーから送られてくる大量のデータに対してほとんど成すすべがなく、問題が起きる可能性があります。以下、この問題への対応策を 2 つ紹介します。

v 仮想リスト・ビューを行うための仮想リスト・ビュー・ページ・サイズ・パラメーター (54 ページ) を参照してください。この方法は、使用している LDAP サーバーによっては、効果がある場合とない場合があります。

v ディレクトリーがメモリーに収まるサイズのものであることが分かっている場合は、JavaVM に使用できるメモリーの量を増やすことができます。「IBM Tivoli

Directory Integrator 5.2 ユーザーズ・ガイド」の『Increasing the memory available

to the Virtual Machine』を参照してください。この問題に対する一般的な解決策は、サーバー固有のユーティリティーを使用して、LDAP データベースを LDIF

ファイルまたは他の形式のファイルにダンプし、ファイルまたは URL コネクターを使用してそのファイルの読み取りまたは繰り返しを行うことです。プロローグの中で (system.shellCommand によりコネクターが活動化される前に) コマンド行を開始して、LDIF エクスポートを生成し、AssemblyLine がそのファイルを読み取れるようにできます。この方法は、実施が可能であれば効果的な解決策となります。大きいディレクトリー全体を繰り返すモードを使用している場合は、バッチとして処理できるという点を忘れないでください。

v 場合によっては、IBM Tivoli Directory Integrator を使用して、ディレクトリー検索をファイルにダンプすることもできます。これは、ファイルへの高速書き込みにより、IBM Tivoli Directory Integrator が入力側の供給量に対応するのに十分な量のデータにアクセスできるためです (データの量と供給速度に応じて異なります)。AssemblyLine が 1 項目を処理するのに長時間を要する場合 (例えば、他のディレクトリーを更新している場合) は、早期に項目のあふれが生じることになります。しかし、このソリューションは時間への依存度が大きいので、他にもっと効果的な方法がある場合は使用しないようにしてください。

LDAP コネクターの更新情報このセクションでは、既存の LDAP コネクターへの機能強化について説明します。

以下に、この LDAP コネクターの更新における新機能を示します。

LDAP の比較public boolean compare(String compdn, String attname, String attvalue)

throws Exception

ここで、

v compdn: 属性を比較する DN。

v attname: 比較する属性の名前。

v attvalue: 比較の元となる attvalue の値。


値が等しい場合は、true が戻されます。値が等しくない場合は、false が戻されます。例えば、cn=joe,o=ibm の userpassword 属性が secret と等しいかどうか判別する場合は、メソッド compare("cn=joe,o=ibm", "userpassword", "secret") を使用します。

属性への値の追加このメソッドは、指定された値を属性に追加します。

public void addAttributeValue(String moddn, String modattr, String modval)throws Exception

ここで、

v moddn: 属性値を追加する DN。

v modattr: 値を追加する属性の名前。

v modval: modattr に追加する値。

例えば、cn=mygroup の members 属性に cn=bob を追加する場合は、メソッドaddAttributeValue("cn=mygroup", "members", "cn=bob") を使用します。

基礎的な変更操作が失敗すると、java.langException がスローされます。

属性値の置換このメソッドは、属性に対して指定された値を置換します。

public void replaceAttributeValue(String moddn, String modattr, String modval)throws Exception

ここで、

v moddn: 属性値を置換する DN。

v modattr: 値を置換する属性の名前。

v modval: modattr において置換する値。

例えば、cn=mygroup の members 属性を cn=bob のみに置換する場合は、メソッド replaceAttributeValue("cn=mygroup", "members", "cn=bob") を使用します。


属性値の除去このメソッドは、指定された値を属性から除去します。

public void removeAttributeValue(String moddn, String modattr, String modval)throws Exception

ここで、

v moddn: 属性値を除去する DN。

v modattr: 値を除去する属性の名前。

v modval: modattr から除去する値。

例えば、DN cn=mygroup の members 属性から値 cn=bob を除去する場合は、メソッド removeAttributeValue("cn=mygroup", "members", "cn=bob") を使用します。



すべての属性値の除去このメソッドは、指定された属性からすべての値を除去します。

public void removeAllAttributeValues(String moddn, String modattr)throws Exception

ここで、

v moddn: 属性値を除去する DN。

v modattr: すべての値を除去する属性の名前。

例えば、cn=mygroup の members 属性からすべての値を除去する場合は、メソッド removeAllAttributeValues("cn=mygroup", "members") を使用します。


属性の追加または置換のデフォルト・アクション用の Config Editorの新規フラグLDAP コネクターの Config Editor には、属性の追加 (置換しない)という新しいチェック・ボックスがあります。このオプションは、項目の変更時に LDAP コネクターのデフォルトの動作を変更します。

このチェック・ボックスにチェックマークを付けると、LDAP コネクターはDirContext.ADD_ATTRIBUTE の制約を設定します。このチェック・ボックスにチェックマークを付けない場合、LDAP コネクターは DirContext.REPLACE_ATTRIBUTE の制約を設定します。

LDAP 接続に DirContext.ADD_ATTRIBUTE 制約を設定すると、AssemblyLine で処理される任意の属性に新しい値が追加されます。したがって、この制約を慎重に使用しないと、項目に同じ値が繰り返し追加されてしまいます。また、対象の属性が一価である場合に、例外が発生することがあります。DirContext.REPLACE_ATTRIBUTE

を設定すると、動作は旧 LDAP コネクターと同じになります (デフォルト動作)。つまり、属性のすべての値が作業項目の内容で置換されます。

このフラグを設定するのは、通常、グループを処理している場合です。グループ(属性) にメンバー (値) を追加する場合は、他のすべての値は削除しないはずです。

以前の動作では、属性が新規の値に置換されていました。この動作は、デフォルトとして残っています。

注: このプロパティーは、スクリプトから addAttribute プロパティーを設定することにより、コネクターの実行時にいつでも設定できます。次のようなコマンドを使用します。

setProperty(addAttribute, true)

注: このプロパティーは、上記で定義された addAttributeValue およびreplaceAttributeValue メソッドの動作には影響しません。

アクティブな非 LDAP ポートへの接続時の問題アクティブな非 LDAP ポートに接続すると、アプリケーションは TCP タイムアウトが発生するのを待つのでフリーズします (この時間フレームは、オペレーティン


グ・システムによって異なります)。この問題は、JVM 1.3.1 では見られません。その代わり、MalformedURL 例外がスローされます。この問題の原因は、JVM 1.3.1

の JNDI プロバイダーが LDAP URL を検査して、ユーザーが既知の非 LDAP ポート (Notes ポートや ftp ポートなど) に接続しないようにすることにあります。JVM 1.4.1 では、この検査は行われません。これは、任意のポート番号で稼動するLDAP サーバーを持つことが可能であり、有効であるためです。

関連情報46ページの『JNDI コネクター』

IBM ディレクトリー変更ログ・コネクターIBM ディレクトリー変更ログ・コネクターは、LDAP コネクターの特殊インスタンスです。 IBM ディレクトリー変更ログ・コネクターには、変更ログを繰り返すためのロジックが含まれています。戻されるさまざまな属性には、変更属性が含まれます。このコネクターは、変更を標準属性のように見える形式で戻しますが、これは実際には項目クラスの属性です。

このコネクターはバッチ型実行で使用できます。その場合は、特定の変更番号で開始され、最後の変更ログ項目の後で終了します。また、定期的に次の変更ログ項目をチェックするためのタイマー値を指定して、連続モードで実行することもできます。

このコネクターは変更ログ項目を読み取り、1 回の繰り返しのたびに変更ログ・カウンターを自動的に 1 ずつ増加させます。存在しない変更ログ項目を読み取ろうとした場合は、このコネクターは一定期間 (スリープ間隔) スリープ状態に入ります。新規項目を待っている時間の合計がタイムアウト値を超過すると、コネクターは、呼び出し元に Null 値 (繰り返しの終了) を戻します。





変更ログ・ベース変更ログが保持される検索ベース。標準 DN は cn=changelog です。

認証メソッド認証メソッド。指定できる値は、次のいずれかです。

v CRAM-MD5 (CRAM-MD5 (RFC-2195) SASL メカニズムを使用)

v なし (認証を使用しない (無名))

v 単純 (弱い認証 (平文パスワード) を使用)


v このパラメーターを指定しない場合は、デフォルト (単純) が使用されます。ログイン・ユーザー名とログイン・パスワードを指定しない場合は、無名が使用されます。

SSL の使用「SSL の使用」が true である場合は、コネクターは SSL を使用してLDAP サーバーに接続します。これに従ってポート番号の変更が必要になることがあります。

イテレーター状態ストアIBM Tivoli Directory Integrator のユーザー・プロパティー・ストアに現在の同期状態を保管するパラメーターの名前を指定します。この名前は、IBM

Tivoli Directory Integrator のユーザー・プロパティー・ストアの 1 つのインスタンス内に保管されるすべてのパラメーターに対して固有である必要があります。

変更番号で開始開始変更番号を指定します。各変更ログ項目には changenumber=intvalueという名前が付けられ、コネクターはこのパラメーターに指定した番号から開始され、自動的に 1 つずつ番号が増加します。

タイムアウトコネクターが次の変更ログ項目を待つ秒数を指定します。

スリープ間隔コネクターが各ポーリング間でスリープする秒数を指定します。



関連情報46ページの『JNDI コネクター』

Netscape/iPlanet 変更ログ・コネクターiPlanet 変更ログ・コネクターは、LDAP コネクターの特殊インスタンスです。

iPlanet Directory Server 5.0 では、変更ログの形式が専有の形式に変更されました。旧バージョンの iPlanet Directory Server では、LDAP を使用して変更ログにアクセスできました。現在は、変更ログはサーバーによる内部使用専用になっています。変更ログを読み取る必要があるアプリケーションがある場合は、後方互換性を維持するために iPlanet Retro Change Log Plug-in を使用する必要があります。






変更ログ・ベース変更ログが保持される検索ベース。標準 DN は cn=changelog です。


v CRAM-MD5 (CRAM-MD5 (RFC-2195) SASL メカニズムを使用)

v なし (認証を使用しない (無名))


v このパラメーターを指定しない場合は、デフォルト (単純) が使用されます。ログイン・ユーザー名とログイン・パスワードを指定しない場合は、無名が使用されます。

SSL の使用true である場合は、コネクターは SSL を使用して LDAP サーバーに接続します。

注: これに従ってポート番号の変更が必要になることがあります。

変更番号で開始開始変更番号を指定します。各変更ログ項目には changenumber=intvalueという名前が付けられ、コネクターはこのパラメーターに指定した番号から開始され、自動的に 1 つずつ番号が増加します。

タイムアウトコネクターが次の変更ログ項目を待つ秒数を指定します。

スリープ間隔コネクターが各ポーリング間でスリープする秒数を指定します。



Active Directory 変更ログ・コネクターActive Directory 変更ログ・コネクターは、LDAP コネクターの特殊インスタンスです。このコネクターには、uSNChanged メカニズムを使用して Active Directory の変更済みオブジェクトをポーリングするためのロジックが含まれています。

Active Directory 変更ログ・コネクターは、イテレーター・モードで稼働します。

動作Active Directory 変更ログ・コネクターは、始動後に、最新の Active Directory 変更ログ・コネクター・セッションから保管されている汎用シーケンス番号 (USN) 値を、IBM Tivoli Directory Integrator のユーザー・プロパティー・ストアから読み取ります。


Active Directory 変更ログ・コネクターは、まず新規に追加された Active Directory

オブジェクトを検索し、次に変更または削除された Active Directory オブジェクトを検索します。 Active Directory オブジェクトが 1 つ検索されると、そのオブジェクトは解析され、属性および属性値が新しい項目オブジェクトにコピーされます。そして、Active Directory コネクターはこの項目オブジェクトを戻します。

検索する変更済みオブジェクトがなくなると、Active Directory コネクターは Active

Directory での新たなオブジェクト変更を待ちながら循環します。スリープ間隔パラメーターは、コネクターが新たな変更を待つときの 2 つの連続したポーリング間の秒数を指定します。コネクターは、新しい Active Directory オブジェクトが検索されるか、タイムアウト時間 (タイムアウト・パラメーターにより指定) が満了するまで、ループします。タイムアウト時間が満了した場合は、Active Directory コネクターは、戻す項目が残っていないことを示す NULL 項目を戻します。新しい Active

Directory オブジェクトが検索されると、そのオブジェクトは前に述べたように処理され、Active Directory コネクターは新しい項目を戻します。

Active Directory 変更ログ・コネクターは、Active Directory オブジェクトをすべての現行属性とともにそのまま引き渡します。どのオブジェクト属性が変更されたか、およびオブジェクトが何回変更されたかは判別されません。オブジェクトに対するすべての中間の変更内容は完全に失われます。Active Directory は変更ログを持たず、オブジェクトが変更されたときに判別のみを行います。 Active Directory コネクターが報告する各オブジェクトは、そのオブジェクトに対して実行されたすべての変更の累積効果を表します。ただし、Active Directory コネクターは、複製データ・ソース上で実行する必要のあるオブジェクト変更タイプを認識し、複製データ・ソースにおいてそのオブジェクトの追加、変更、または削除を行う必要があるかどうかを報告します。

注: 検索できるのは、ユーザーが読み取り許可を持っているオブジェクトと属性だけです。Active Directory コネクターは、ユーザーが読み取り許可を持っていないオブジェクトまたは属性については、Active Directory 内に存在していても検索しません。この場合、Active Directory コネクターは、そのオブジェクトまたは属性が Active Directory 内に存在しない場合と同じ動作をします。

Active Directory 変更ログ・コネクターの使用Active Directory 変更ログ・コネクターは、戻されるすべての項目に changeType属性を追加します。changeType 属性に指定できる値は、add、modify、およびdelete です。これらの値は、それぞれ、新規オブジェクト、変更済みオブジェクト、削除済みオブジェクトを表します。 Active Directory 変更ログ・コネクターが引き渡す各項目は、objectGUID 属性を持っています。 objectGUID 属性の値は16 バイトのバイト配列で、対応する Active Directory オブジェクトの 128 ビットobjectGUID を表します。便宜上、Active Directory コネクターは、引き渡す各項目に余分な属性を追加します (objectGUIDStr)。objectGUIDStr の値は、128 ビットobjectGUID の 16 進数値を表すストリングです。この値は、{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} の形式で引き渡されます。x はそれぞれ1 つの 16 進数字を表します。

移動または削除されたオブジェクトを検出して処理する必要がある場合は、オブジェクト ID として、LDAP 識別名ではなく objectGUID 値を使用する必要があります。LDAP 識別名はオブジェクトが移動または削除されると変わりますが、


objectGUID 属性は常に変わりません。オブジェクトの objectGUID 属性を複製データ・ソースに保管し、この属性を使用してオブジェクトを検索してください。

注: Active Directory 内の削除されたオブジェクトは、指定した期間 (デフォルトは60 日) が経過するまで存続し、その後で完全に除去されます。削除済みオブジェクトを完全に失ってしまうのを防ぐには、より頻繁に増分同期を行うようにしてください。

オブジェクトが削除されると、以下のことが行われます。

v オブジェクトの isDeleted 属性が TRUE に設定されます。isDeleted==TRUEであるオブジェクトは、トゥームストーン (墓石) と呼ばれます。

v オブジェクトの属性値は除去されます。ただし、RDN、objectGUID、およびobjectSID (セキュリティー原則) は常に保持されます。

v オブジェクトは命名コンテキスト用の削除済みオブジェクト・コンテナーに移され、削除済みオブジェクト・コンテナー内での固有性を確保するために RDN が変更されます。

オブジェクトが新規オブジェクトとして報告された後でその内容が変更されていなくても、そのオブジェクトが変更済みとして報告されることがあります。この状況が生じるのは、現行の Active Directory コネクター・セッションが開始される前にオブジェクトが作成され、現行の Active Directory コネクター・セッションの開始後、そのオブジェクトが変更され、その後で Active Directory コネクターが実際にそのオブジェクトを検索した場合です。この場合は、Active Directory コネクターはオブジェクトの変更済みの内容を検索し、それを新規オブジェクトとして報告します。その少し後で (同じセッション中に)、Active Directory コネクターは同じオブジェクトを変更済みとして報告し、変更されて既に報告済みのその同じオブジェクトの内容を検索します。この動作は、同期プロセスに弊害をもたらすこともなく、重大なパフォーマンス上のオーバーヘッドを生じる原因にもならないので、特に注意を払う必要はありません。

また、すでに削除済みのオブジェクトが新規オブジェクトとして報告され、その後、同じコネクター・セッション中に削除済みオブジェクトとして報告される場合もあります。この状況が生じるのは、現行の Active Directory コネクター・セッションが開始される前にオブジェクトが作成され、現行の Active Directory コネクター・セッションの開始後、そのオブジェクトが削除され、その後で Active Directory

コネクターが実際にそのオブジェクトを検索した場合です。この場合は、コネクターはオブジェクトの削除済み状態を検索し、それを新規オブジェクトとして報告します。その少し後で (同じセッション中に)、コネクターは同じオブジェクトを削除済みとして報告します。既に削除されたオブジェクトの追加は、isDeleted 属性を確認することにより認識できます。この属性が存在し、値が true である場合は、オブジェクトは既に削除されています。

注: 削除された Active Directory オブジェクトについては、ほとんどすべての属性が除去されます。

削除されたオブジェクトを保管および追跡するために、属性 $dn およびdistinguishedName を使用してはなりません。削除されたオブジェクトを追跡するには、前に説明した objectGUID 属性を使用する必要があります。


Active Directory 変更ログ・コネクターには、同期プロセス中のどの時点でも割り込むことができます。このコネクターは同期プロセスの状態を IBM Tivoli Directory

Integrator のユーザー・プロパティー・ストアに保管するので (各項目の検索後)、次回に Active Directory コネクターを開始したときには、割り込まれた位置から正しく同期が続行されます。

Active Directory 変更ログ・コネクターでは、IBM Tivoli Directory Integrator 5.2 チェックポイント/リスタート機能がサポートされます。

ユーザー・プロパティー・ストア内の USN 同期値へのアクセス任意の時間の同期状態は、4 つの更新シーケンス番号 (USN) で表されます。

v START_USN

v END_USN

v CURRENT_USN_CREATED

v CURRENT_USN_CHANGED

これらの値は、ユーザー・プロパティー・ストアにパックおよび保管されています。これらの値を手動で変更しないでください。同期の特定の段階に対応する番号を保存し、後でそれらの番号を使用して、その段階から同期をやり直すことができます。

以下のスクリプト・コードを IBM Tivoli Directory Integrator で使用すると、ユーザー・プロパティー・ストアに保管されている USN 値を取得できます。

// Retrieve USN values from User Property Storevar usn = system.getPersistentObject("ad_sync");var startUsn = usn.getString("START_USN");var endUsn = usn.getString("END_USN");var currentUsnCreated = usn.getString("CURRENT_USN_CREATED");var currentUsnChanged = usn.getString("CURRENT_USN_CHANGED");

main.logmsg("START_USN: " + startUsn);main.logmsg("END_USN: " + endUsn);main.logmsg("CURRENT_USN_CREATED: " + currentUsnCreated);main.logmsg("CURRENT_USN_CHANGED: " + currentUsnChanged);

"ad_sync" は、ユーザー・プロパティー・ストアに既に保管されているパラメーターの名前です。この値は、イテレーター状態ストア・パラメーターで指定します。上記の例では値を画面にダンプしていますが、他に希望する方法で処理できます。例えば、ファイルに保管して、このファイルをバックアップすることもできます。

以下のスクリプト・コード例は、USN 値をユーザー・プロパティー・ストアにどのように保管するかを示しています。

// Store USN values in the User Property Storevar usn = system.newEntry();usn.setAttribute("START_USN", startUsn);usn.setAttribute("END_USN", endUsn);usn.setAttribute("CURRENT_USN_CREATED", currentUsnCreated);usn.setAttribute("CURRENT_USN_CHANGED", currentUsnChanged);system.setPersistentObject("ad_sync", usn);

このコード例では、変数 startUsn、endUsn、currentUsnCreated、およびcurrentUsnChanged にストリングとして USN 番号が含まれると想定されています。


この例では、"ad_sync" パラメーターに USN 値が保管されるので、希望する時点から同期を続行するためには、イテレーター状態ストア・パラメーターに"ad_sync" を指定する必要があります。

ランタイム・コネクターの USN 同期値へのアクセスActive Directory 変更ログ・コネクターには、現在の USN 値にアクセスするために以下の共通メソッドがあります。

public Entry getUsnValues ();以下の属性を持つ項目オブジェクトを戻します。

v START_USN

v END_USN



各属性の値のタイプは java.lang.Integer であり、対応する Active

Directory コネクター USN 値を表します。

public void setUsnValues (Entry usnEntry);Active Directory コネクターの現在の USN 同期値を、usnEntry パラメーターに指定された値に設定します。usnEntry パラメーターの構造は、getUsnValues() により戻された項目の構造と同じにする必要があります。usnEntry 属性の値は、java.lang.Integer か、対応する数のストリング表現にする必要があります。

注: 実行時に USN 値を変更する際には慎重に行ってください。矛盾する値を指定すると、不適切な同期が行われる場合があります。


LDAP URLアクセスする Active Directory サービスの LDAP URL。LDAP URL の形式は、ldap://hostname:port または ldap://server_IP_address:port です。例えば、ldap://localhost:389。

注: デフォルトの LDAP ポート番号は 389 です。 SSL を使用しているときは、デフォルトの LDAP ポート番号は 636 です。

ログイン・ユーザー名サービスへの認証に使用する識別名。例えば、cn=administrator,cn=users,dc=your_domain,dc=com。

注: 無名認証を使用する場合は、このパラメーターをブランクのままにしておく必要があります。




認証メソッド使用する認証メソッド。指定できる値は、次のいずれかです。

v 無名 (認証を使用しない)


SSL の使用Active Directory との LDAP 通信に Secure Sockets Layer を使用するかどうかを指定します。

LDAP 検索ベース変更の有無を調べるためにポーリングされる Active Directory サブツリー。例えば、dc=your_domain,dc=com。

USN ファイル名USN の値が保管され、そこから読み取られるテキスト・ファイルの名前を指定します。



開始位置同期を開始する開始 USN 番号を指定します。EOD は、コネクターの開始後に行われた変更のみを報告することを意味します。

タイムアウトコネクターが次の変更済み Active Directory オブジェクトを待つ最大秒数を指定します。このパラメーターが 0 の場合は、コネクターは無期限に待機します。タイムアウト秒数内に次の変更済み Active Directory オブジェクトを検索しなかった場合は、コネクターは、戻す項目が残っていないことを示す空 (NULL) 項目を戻します。

スリープ間隔コネクターが連続したポーリング間でスリープする秒数を指定します。



マイグレーションIBM Tivoli Directory Integrator 5.2 の場合、Active Directory 変更ログ・コネクターは USN 同期値を IBM Tivoli Directory Integrator のユーザー・プロパティー・ストアに保管します。旧バージョンの Active Directory 変更ログ・コネクターは、テキスト・ファイルを使用して USN 値を保管します。

バージョン 5.2 より前の IBM Tivoli Directory Integrator 構成をマイグレーションするには、次の手順を実行します。


1. IBM Tivoli Directory Integrator の 5.2 より前の構成を開き、イテレーター状態ストア・パラメーターの値を設定します。

2. AssemblyLine を実行します。コネクターはテキスト・ファイルから開始 USN

値を読み取りますが、更新された USN 値はテキスト・ファイルとユーザー・プロパティー・ストアの両方に保管します。

3. AssemblyLine を停止します。

4. USN ファイル名パラメーターの値をクリアし、構成を保管します。コネクターはユーザー・プロパティー・ストア内の USN 同期値を読み取り、更新されたUSN 値をユーザー・プロパティー・ストアに保管します。テキスト・ファイルは使用しません。

関連情報58ページの『IBM ディレクトリー変更ログ・コネクター』, 50ページの『LDAP

コネクター』

Exchange 変更ログ・コネクターExchange 変更ログ・コネクターは、LDAP コネクターの特殊インスタンスです。Exchange コネクターには、uSNChanged メカニズムを使用して Exchange の変更済みオブジェクトをポーリングするためのロジックが含まれています。

Exchange 変更ログ・コネクターは、イテレーター・モードで稼働します。

注:

1. Exchange 変更ログ・コネクターは Exchange 5.5 の場合のみ使用できます。Exchange 2000 に接続しようとしている場合は、代わりに Active Directory 変更ログを使用してください。

2. Exchange Server に Exchange 5.5 Service Pack 4 をインストールしてあることが必要です。

動作Exchange 変更ログ・コネクターは、始動後に、最新の Exchange コネクター・セッションから保管されている USN 値を、IBM Tivoli Directory Integrator のユーザー・プロパティー・ストアから読み取ります。Exchange コネクターは、まず新規に追加された Exchange オブジェクトを検索し、次に変更または削除された Exchange

オブジェクトを検索します。Exchange オブジェクトが 1 つ検索されると、そのオブジェクトは解析され、属性および属性値が新しい項目オブジェクトにコピーされます。そして、Exchange コネクターはこの項目オブジェクトを戻します。検索する変更済みオブジェクトがなくなると、Exchange コネクターは新たな変更が発生するのを待ちながら循環します。スリープ間隔パラメーターは、Exchange コネクターが新たな変更を待つときに連続したポーリング間にスリープする秒数を指定します。Exchange コネクターは、新しい変更が検索されるか、タイムアウト時間が満了するまでループします。タイムアウト時間が満了した場合は、Exchange コネクターは、戻す項目が残っていないことを示す NULL 項目を戻します。変更済みオブジェクトが検索されると、そのオブジェクトは処理され、Exchange コネクターは新しい項目を戻します。

Exchange 変更ログ・コネクターは、Exchange オブジェクトをすべての現行属性とともにそのまま引き渡します。どのオブジェクト属性が変更されたか、およびオブ


ジェクトが何回変更されたかは判別されません。オブジェクトに対するすべての中間の変更内容は完全に失われます。Exchange は変更ログを持たず、オブジェクトが変更されたときに判別のみを行います。Exchange コネクターが報告する各オブジェクトは、そのオブジェクトに対して実行されたすべての変更の累積効果を表します。ただし、Exchange コネクターは、複製データ・ソース上で実行する必要のあるオブジェクト変更タイプを認識し、複製データ・ソースにおいてそのオブジェクトの追加、変更、または削除を行う必要があるかどうかを報告します。

注: 検索できるのは、ユーザーが読み取り許可を持っているオブジェクトと属性だけです。Exchange コネクターは、ユーザーが読み取り許可を持っていないオブジェクトまたは属性については、Exchange 内に存在していても検索しません。この場合、Exchange コネクターは、そのオブジェクトまたは属性が Exchange

内に存在しない場合と同じ動作をします。

Exchange 変更ログ・コネクターの使用Exchange 変更ログ・コネクターは、戻されるすべての項目に changeType 属性を追加します。changeType 属性に指定できる値は、add、modify、および deleteです。これらの値は、それぞれ、新規オブジェクト、変更済みオブジェクト、削除済みオブジェクトを表します。

Exchange Server でオブジェクトが削除される場合、そのオブジェクトはトゥームストーン (墓石) としてマークされ、オブジェクトの Is-Deleted 属性が true に設定されます。ただし、オブジェクトは他のコンテナー (Active Directory コネクター内のコンテナーなど) に移動されず、distinguishedName 属性は保持されます。Exchange オブジェクトは移動できません。したがって、Exchange ではdistinguishedName 属性が変更されることはなく、同期時にオブジェクト ID に対して安全に使用することができます。

注: Exchange 内の削除されたオブジェクトは、指定した期間 (デフォルトは 30 日)

が経過するまで存続し、その後で完全に除去されます。削除済みオブジェクトを完全に失ってしまうのを防ぐには、より頻繁に増分同期を行うようにしてください。

オブジェクトが新規オブジェクトとして報告された後でその内容が変更されていなくても、そのオブジェクトが変更済みとして報告されることがあります。この状況が生じるのは、現行の Exchange コネクター・セッションが開始される前にオブジェクトが作成され、現行の Exchange コネクター・セッションの開始後、そのオブジェクトが変更され、その後で Exchange コネクターが実際にそのオブジェクトを検索した場合です。この場合は、Exchange コネクターはオブジェクトの変更済みの内容を検索し、それを新規オブジェクトとして報告します。その少し後で (同じセッション中に)、Exchange コネクターは同じオブジェクトを変更済みとして報告し、変更されて既に報告済みのその同じオブジェクトの内容を検索します。この動作は、同期プロセスに弊害をもたらすこともなく、重大なパフォーマンス上のオーバーヘッドを生じる原因にもならないので、特に注意を払う必要はありません。

また、すでに削除済みのオブジェクトが新規オブジェクトとして報告され、その後、同じ Exchange コネクター・セッション中に削除済みオブジェクトとして報告される場合もあります。この状況が生じるのは、現行の Exchange コネクター・セッションが開始される前にオブジェクトが作成され、現行の Exchange コネクター・セッションの開始後、そのオブジェクトが削除され、その後で Exchange コネ


クターが実際にそのオブジェクトを検索した場合です。この場合は、Exchange コネクターはオブジェクトの削除済み状態を検索し、それを新規オブジェクトとして報告します。その少し後で (同じセッション中に)、コネクターは同じオブジェクトを削除済みとして報告します。既に削除されたオブジェクトの追加は、Is-Delete 属性を確認することにより認識できます。このオブジェクトが存在し、値が true である場合は、オブジェクトは既に削除されています。

Exchange 変更ログ・コネクターには、同期プロセス中のどの時点でも割り込むことができます。このコネクターは同期プロセスの状態を IBM Tivoli Directory

Integrator のユーザー・プロパティー・ストアに保管するので (各項目の検索後)、次回に Exchange 変更ログ・コネクターを開始したときには、割り込まれた位置から正しく同期が続行されます。

Exchange 変更ログ・コネクターでは、IBM Tivoli Directory Integrator 5.2 チェックポイント/リスタート機能がサポートされます。

Exchange の Is-Deleted 属性デフォルトでは、Exchange は、LDAP を介して Is-Deleted オブジェクト属性を公開しません。ただし、戻される Exchange オブジェクトの一部として Is-Deleted 属性が戻されない場合は、LDAP 検索照会の中で Is-Deleted 属性を使用できます。したがって、LDAP を介して Is-Deleted 属性が認識されなくても、Exchange コネクターは変更のタイプを正しく検出することができます。Is-Deleted 属性が LDAP

を介して認識される場合は、″Is-Deleted″ 属性を可視パラメーターを TRUE に設定してあれば、Exchange コネクターは迅速に変更を検索できます。コネクターは戻された Is-Deleted 属性を使用して、より速く処理を完了します。

注: サーバーが Is-Deleted 属性を公開する場合は、″Is-Deleted″ 属性を可視がfalse に設定されていてもコネクターは正しく機能しますが、″Is-Deleted″ 属性を可視を true に設定することにより、Exchange コネクターの処理速度を速めることができます。サーバーが Is-Deleted 属性を公開せず、″Is-Deleted″ 属性を可視が true に設定されている場合は、コネクターは変更と削除を識別できないため、変更操作と削除操作のどちらに対しても変更を報告してしまいます。

Is-Deleted 属性が公開されるようにするには、Exchange Server の管理者特権を取得し、次の手順を実行します。

1. Exchange 管理プログラム admin.exe を Raw モード (admin /r) で始動します。

2. メニューから「表示」 -> 「Raw Directory」を選択します。

3. 左側のウィンドウから「スキーマ」を選択します。

4. 右側のウィンドウで「Is-Deleted」をダブルクリックします。

5. ロー・プロパティーのみが表示されることを知らせるメッセージ・ボックスが現れます。このメッセージ・ボックスから、それらのロー・プロパティーを表示するかどうかを尋ねられます。「はい」をクリックしてください。

6. 「ヒューリスティック (Heuristics)」プロパティーを選択します。右側に現行のプロパティー値が表示されます。このプロパティー値は編集することもできます。


7. 「Heuristics」プロパティーをどのような値に設定するかを決定するには、以下を参照してください。このプロパティーはビット・マスクで、次のように解釈されます。

ビット 0

v 0: サイト間で複製する。

v 1: サイト間で複製しない。

ビット 1

v 0: 属性は LDAP を介して見ることができない。

v 1: 属性は、無名クライアントおよび認証済み LDAP クライアントで見ることができる。

ビット 2

v 0: 属性は認証クライアントからはアクセスできない。

v 1: 属性は認証クライアントからはアクセスできるが、無名クライアントからはアクセスできない。

ビット 3

v 0: 属性は操作可能な属性ではない。

v 1: 属性は操作可能な属性である。

ビット 4

v 0: 属性は、Config Editor (DS サイト構成オブジェクトの属性ページ) で見ることはできない。

v 1: 属性は、Config Editor (DS サイト構成オブジェクトの属性ページ) で見ることができる。

ヒューリスティックを調べることにより、特定の属性の可視性を判断することができます。例えば、ヒューリスティック値 3 は、属性がサイト間で複製されず、無名LDAP クライアントが見ることができることを示します。ヒューリスティック値 11は、属性が操作可能属性であり、認証済み LDAP クライアントが見ることができることを意味します。

上記の表から分かるように、ヒューリスティック値のビット 1 は、LDAP を介してオブジェクトを見ることができるかどうかを決定します。したがって、LDAP を介して属性を見ることができるようにするには、ビット 1 を設定する必要があります。

Exchange オブジェクトまたは Exchange オブジェクト属性のもう 1 つの重要なプロパティーに、「説明」プロパティーがあります。このプロパティーは、属性またはオブジェクトの LDAP 名を決定します。

注: LDAP 名を変更すると、インターオペラビリティーの問題が起きることがあります。

ユーザー・プロパティー・ストア内の USN 同期値へのアクセス任意の時間の同期状態は、4 つの USN 番号で表されます。

v START_USN

v END_USN






// Retrieve USN values from User Property Storevar usn = system.getPersistentObject("exchange_sync");var startUsn = usn.getString("START_USN");var endUsn = usn.getString("END_USN");var currentUsnCreated = usn.getString("CURRENT_USN_CREATED");var currentUsnChanged = usn.getString("CURRENT_USN_CHANGED");


"exchange_sync" は、ユーザー・プロパティー・ストアに既に保管されているパラメーターの名前です。この値は、イテレーター状態ストア・パラメーターで指定します。上記の例では値を画面にダンプしていますが、他に希望する方法で処理できます。例えば、ファイルに保管して、このファイルをバックアップすることもできます。


// Store USN values in the User Property Storevar usn = system.newEntry();usn.setAttribute("START_USN", startUsn);usn.setAttribute("END_USN", endUsn);usn.setAttribute("CURRENT_USN_CREATED", currentUsnCreated);usn.setAttribute("CURRENT_USN_CHANGED", currentUsnChanged);system.setPersistentObject("exchange_sync", usn);

このコードでは、変数 startUsn、endUsn、currentUsnCreated、およびcurrentUsnChanged にストリングとして USN 番号が含まれると想定されています。この例では、"exchange_sync" パラメーターに USN 値が保管されるので、希望する時点から同期を続行するためには、イテレーター状態ストア・パラメーターにexchange_sync を指定する必要があります。

ランタイム・コネクターの USN 同期値へのアクセスExchange 変更ログ・コネクターには、現在の USN 値にアクセスするために以下の共通メソッドがあります。


v START_USN

v END_USN




各属性の値のタイプは java.lang.Integer であり、対応するコネクター USN

値を表します。

public void setUsnValues (Entry usnEntry);Exchange コネクターの現在の USN 同期値を、usnEntry パラメーターに指定された値に設定します。usnEntry パラメーターの構造は、getUsnValues() により戻された項目の構造と同じにする必要があります。usnEntry 属性の値は、java.lang.Integer か、対応する数のストリング表現にする必要があります。



LDAP URLアクセスしたい Exchange サーバーの LDAP URL。 LDAP URL の形式は、ldap://hostname:port または ldap://server_IP_address:port です。例えば、ldap://localhost:389。


ログイン・ユーザー名サービスへの認証に使用する識別名。例えば、cn=administrator,ou=domain_name,o=organization_name。







SSL の使用Exchange Server との LDAP 通信に Secure Sockets Layer を使用するかどうかを指定します。

LDAP 検索ベース変更の有無を調べるためにポーリングされる指定された Exchange サブツリー。例えば、cn=recipients,ou=domain_name,o=organization_name。

USN ファイル名最新のコネクター・セッション USN の値が保管されるテキスト・ファイルの名前を指定します。このファイルが存在しないか、形式が正しくない場合は、コネクターは Exchange との完全同期を行います。コネクターは、項目


を 1 つ検索するたびに更新済みの USN 値を書き込むので、このファイルは読み取り専用であってはなりません。

注: 検索ベースまたはサーバー (あるいはその両方) を変更した場合は、USN ファイルも変更または編集した方がよい場合があります。これは、保管されている USN 値が、新しい検索ベースまたはサーバーから見て無効な場合があるからです。



開始位置同期を開始する開始 USN 番号を指定します。EOD は、コネクターの開始後に行われた変更のみを報告することを意味します。

″Is-Deleted″ 属性を可視Exchange Server が LDAP を介して Is-Deleted オブジェクト属性を公開するかどうかを指定します。

注: サーバーが Is-Deleted 属性を公開しているが、″Is-Deleted″ 属性を可視が false に設定されている場合は、コネクターは正しく機能します。″Is-Deleted″ 属性を可視を true に設定すると、コネクターの処理速度を速めることができます。サーバーが Is-Deleted 属性を公開しない場合に、″Is-Deleted″ 属性を可視が true に設定されているときは、コネクターは変更済みオブジェクトと削除済みオブジェクトの違いを判別できないため、削除をすべて変更操作として報告します。

タイムアウト

コネクターが新規変更の検索を行う秒数を指定します。このパラメーターの値に関係なく、コネクターは、現行のコネクター・セッションの開始前に発生したすべての変更をスキャンするまではタイムアウトになりません。

このパラメーターが 0 の場合は、コネクターは無期限に次の変更を待ちます。

タイムアウト時間が満了した場合は、コネクターは、戻す項目が残っていないことを示す空 (NULL) 項目を戻します。

スリープ間隔変更のための連続したポーリング間で、コネクターがスリープする秒数を指定します。




マイグレーションIBM Tivoli Directory Integrator 5.2 の場合、Exchange 変更ログ・コネクターは USN

同期値を IBM Tivoli Directory Integrator のユーザー・プロパティー・ストアに保管します。旧バージョンの Exchange 変更ログ・コネクターは、USN 値をテキスト・ファイルに保管します。

バージョン 5.2 より前の Tivoli Directory Integrator 構成をマイグレーションするには、次の手順を実行します。

1. 5.2 より前の構成を開き、イテレーター状態ストア・パラメーターの値を設定します。

2. AssemblyLine を実行します。Exchange コネクターはテキスト・ファイルから開始 USN 値を読み取りますが、更新された USN 値はテキスト・ファイルとユーザー・プロパティー・ストアの両方に保管します。


4. USN ファイル名パラメーターの値をクリアし、構成を保管します。コネクターはユーザー・プロパティー・ストア内の USN 同期値を読み取り、更新されたUSN 値をユーザー・プロパティー・ストアに保管します。テキスト・ファイルは使用しません。

関連情報60ページの『Active Directory 変更ログ・コネクター』, 58ページの『IBM ディレクトリー変更ログ・コネクター』, 50ページの『LDAP コネクター』

Lotus Notes コネクターLotus Notes コネクターは、Lotus Domino データベースへのアクセスを提供します。

Lotus Notes コネクターは、任意の Notes データベース内のレコードの読み取り、書き込み、および削除を行うので、Domino ディレクトリーのみに限定されません。Lotus Notes のユーザー管理では、証明書、ACL、およびメールボックスを変更する必要があります。これは、手動で行うか、または Config Editor 使用する必要があります。ステージング・データベースを適用し、Notes スクリプトを使用して Config

Editor と統合することにより、ユーザーを Notes に組み込んだり除外したりすることができます。

注: Lotus Notes コネクターを使用するには、Lotus Notes はリリース 5.0.8 以降であることが必要です。

既知の制限事項ローカル・クライアント・モードまたはローカル・サーバー・モードのみを使用する Notes コネクターの場合: IBM Tivoli Directory Integrator Config Editor を使用して Notes データベースに接続できないことがあります。Notes コネクターが Notes

API に対してパスワードを提供する場合であっても、Notes コネクターがユーザーにパスワードを求めるプロンプトを出すことがあります。このプロンプトは標準出力に書き込まれ、ユーザーからの入力は標準入力から読み取られます。このプロンプト表示は Notes API により行われるもので、IBM Tivoli Directory Integrator の制御の範囲外です。


IBM Tivoli Directory Integrator Server を実行すると、標準入力と標準出力の両方がコンソールに接続されるので、ユーザーはプロンプトを見てパスワードを入力することができます。Notes コネクターは制御を再獲得し、実行を続けます。これは、このコネクターが予期したとおりに働いているということです。

IBM Tivoli Directory Integrator Config Editor を実行すると、標準入力および標準出力はコンソールから切断されるので、ユーザーに対して何も表示されず、応答も入力できません。接続操作は、無期限にユーザー入力を待ってハングすることがあります。

セッション・タイプが LocalClient である場合は、Notes または Designer クライアントを始動し、「ファイル」 -> 「ツール」 -> 「ユーザー ID」パネルでフラグを設定することにより、他のアプリケーションがその接続を使用できるようにすることができます。使用するチェック・ボックスは、「Don’t prompt for apassword from other Notes-based programs. (Share this user ID passwordwith these Notes add-ins)」です。この場合、Notes コネクター (つまり Notes

API) は、指定されたパスワードを無視し、Notes または Designer クライアントが確立した現行セッションを再使用します。IBM Tivoli Directory Integrator がこのセッションを再使用するには、Notes または Designer クライアントが実行されていることが必要です。

注: 一度 DIIOP モードに切り替えて AssemblyLine を構成してから、再びローカル・クライアント・モードまたはローカル・サーバー・モードに戻し、IBM

Tivoli Directory Integrator Server を使用して AssemblyLine を実行することができます。

セッション・タイプ以下のセッション・タイプがサポートされています。

IIOP このセッション・タイプでは、Domino Server への TCP 接続が使用されます。Lotus Notes コネクターは、HTTP および IIOP を使用して Domino

Server にアクセスするので、これらのサービスが開始されていて、Lotus

Notes コネクターを実行しているホストからアクセスできることを確認してください。

LocalClientこのセッション・タイプは、Lotus Notes または Designer のローカル・インストールを使用します。 Lotus Notes コネクターは、ローカル・クライアントが使用している ID ファイルを使用します。必須条件は、Lotus 提供のNotes.jar ファイルが Java CLASSPATH 内にあることと、ローカル・クライアント・バイナリーが PATH 内にあることです。Notes.jar ファイルは、ネイティブ呼び出し (例えばローカル・クライアント・ライブラリー) を使用してデータベースにアクセスします。また、root_directory/jars の中のncso.jar ファイルを削除することも必要です。このセッション・タイプでは、ユーザー名パラメーター (dominoLogin) は無視されます。パスワード(dominoPassword) は、使用されている ID ファイル内のパスワードと一致していなければなりません。一致しない場合は、ローカル Notes クライアントはパスワードを求めるプロンプトを出します。


注: この操作は困難な場合があります。例えば、コンソールから離れて標準入力または標準出力を使用して AssemblyLine を実行する場合です。AssemblyLine は常にコマンド行ウィンドウで実行して、ローカル・クライアントがパスワードを求めるかどうかを確認するようにしてください。テストの結果によれば、ローカル・クライアントは正しいパスワード・パラメーターを無視して、常にパスワードを求めるプロンプトを出します。プロンプトが出されないようにするには、次の手順を実行します。

1. Notes または Designer クライアントを始動します。

2. 「ファイル」 -> 「ツール」 -> 「ユーザー ID」メニューを選択します。

3. 「Don’t prompt for a password for other Notes programs」にチェックマークを付けます。

LocalServerこれは LocalClient と同じですが、ローカル Domino Server インストールを使用します。違っているのは、有効なユーザー名および一致するパスワードを指定できるという点です。

接続このコネクターは、IIOP を使用して Domino Server と通信します。Domino Server

との IIOP セッションを確立するには、コネクターは、サーバー上で IIOP プロセスを検出するための IOR ストリングを必要とします。

Notes コネクターを構成するときに、ホスト名の他に、オプションとして、サーバーが置かれているポート番号を指定します。この hostname:port ストリングは、実際には、コネクターが IOR ストリングを検索する Domino Server の http サービスのアドレスです。そして、この IOR ストリングを使用して、サーバーの IIOP サービス (diiop) との IIOP セッションが作成されます。この http サービスが必要なのは、IOR ストリングを検出するためだけです。この操作は非常に単純です。コネクターは、IOR ストリングが含まれているものと予期される /diiop_ior.txt という名前の文書を、Domino http サーバーに要求します。 hostname:port の指定をこのストリングで置き換えれば、最初のステップを省略し、http サーバーへの依存を回避することができます。通常、diio_ior.txt ファイルは、Domino Server インストール・ディレクトリー内の data/domino/html ディレクトリーに入っています。正確な場所については、Lotus Administrator の中の Web 構成を調べてください。

最初のステップを確認するには、http://hostname:port/dioop_ior.txt を参照してください。ここで、hostname はホスト名、port は Domino Server のポート番号です。ユーザーは、IOR: numbers という文書を受け取ります。このような応答を受け取った場合は、最初のステップは確認されたことになります。この操作が失敗した場合は、サーバー上の HTTP 構成を調べて、無名アクセスを許可するように設定されていることと、プロセスが実行されていることを確認してください。


ホスト名Domino Server への IP ホスト名またはアドレス。


ユーザー名サーバーに対する入力に使用するユーザー名。セッション・タイプがLocalClient である場合は、これは無視されます。

パスワード使用するパスワード。

セッション・タイプIIOP、LocalClient、または LocalServer のいずれかを指定できます。 74

ページの『セッション・タイプ』を参照してください。

SSL の使用このフラグにチェックマークを付けると、コネクターは暗号化された IIOP

接続を要求します。このフラグが意味を持つのは、セッション・タイプがIIOP の場合だけです。 SSL を使用するための要件の 1 つに、DIIOP プロセスが開始されるたびに生成される TrustedCerts.class ファイルが、クラスパス内に含まれていなければならないという条件があります。CLASSPATH に含まれるローカル・パスに TrustedCerts.class をコピーするか、またはクラスパス内に Domino をインストールしたシステムの¥Lotus¥Domino¥Data¥Domino¥Java を含める必要があります。

サーバーデータベースが置かれているサーバーの名前。現在接続しているサーバー(dominoHost) を使用する場合は、ブランクのままにしておきます。

データベース使用するデータベースの名前。

文書選択データ・ソースを繰り返すときに使用する選択肢。有効な Lotus Notes 選択ステートメントを使用する必要があります。アドレス帳から項目を選択するには、次の選択ステートメントを使用します。

Select Form="Person"

常に公式検索を使用このフラグが意味を持つのは、ビューを使用していず、アクセスしているデータベースがフルテキスト索引付きである場合です。このフラグにチェックマークを付けると、コネクターは、データベースが索引付きかどうかに関係なく、公式ステートメントを使用します。ビューは公式検索ステートメントをサポートしていないので、ビューを指定した場合は、常にフルテキスト検索が使用されます。

データベース・ビュー使用するデータベース・ビュー。


セキュリティーIBM Tivoli Directory Integrator が Domino Server にアクセスできるようにするには、「Domino Administrator」 -> 「セキュリティー」 -> 「IIOP restriction」を使用する必要があります。 IBM Tivoli Directory Integrator が使用するものとして


構成したユーザー・アカウントは、「制限付き Java/Javascript の実行」および「制限なし Java/Javascript の実行」の下にリストされているグループのいずれかに属していなければなりません。

Domino Web サーバーは、無名アクセスを許可するように構成する必要があります。このように構成しておかないと、現行バージョンの Notes コネクターはDomino IIOP サーバーに接続できません。

注: Notes アドレス帳の HTTPPassword フィールドを暗号化したい場合は、次のスクリプトを AssemblyLine に追加します。

var pwd = "Mypassword";var v = dom.connector.getDominoSession().evaluate("@Password(\"" + pwd + "\")" ) ;ret.value = v.elementAt(0);

このコードは、Domino のパスワード暗号化ルーチンを使用して、変数 pwd を暗号化します。このコードは、Domino が提供する @Password 関数を使用してストリングを暗号化したい任意の場所で使用できます。このコードを使用する最も適切な場所の 1 つは、HTTPPassword 属性の出力マップです。

メールボックス・コネクターメールボックス・コネクターは、インターネット・メール・ボックス (pop またはimap) へのアクセスを提供します。メールボックス・コネクターは、イテレーター・モード、ルックアップ・モード、および削除モードで使用できます。メールボックス・コネクターは、使用頻度の高いヘッダーには事前定義済みの属性名を使用します。別の名前を使用する必要がある場合は、mail.message プロパティーを使用してネイティブ・メッセージ・オブジェクトを検索してください。

メールボックス・コネクターをルックアップ・モードまたは削除モードで使用している場合は、検索可能なヘッダーは以下のとおりです。

v mail.from

v mail.to

v mail.cc

v mail.subject

v mail.messageid

v mail.messagenumber

注:

1. 1 ユーザー ID に付き 1 接続のみサポートされます。ユーザーが、スキーマ・タブを使用しているときに切断するのを忘れ、その後で AssemblyLine を実行すると、接続拒否エラーが生じることになります。

2. メールボックス・コネクターは、拡張リンク基準をサポートしません (「IBM

Tivoli Directory Integrator 5.2 ユーザーズ・ガイド」の『Advanced link criteria』を参照してください)。


構成メール・サーバー

メール・ボックスのホストとして稼働するメール・サーバー。これには、次の例のように、スペースで区切ってポート番号を含めることができます (url

port)。例 :

domino.raleigh.ibm.com 110

アクセス・プロトコルpop3 または imap を指定します。

ユーザー名ユーザー名。

パスワードユーザー名のパスワード。

メール・フォルダーモニターするメール・フォルダー。 POP3 の場合は、指定できるのはINBOX のみです。 IMAP4 サーバーの場合は、これはサーバーで使用できるどのフォルダーでもかまいません。


事前定義済みのプロパティーおよび属性メールボックス・コネクターは、以下に示す事前定義済みの属性およびプロパティーを使用します。

mail.from送信者ヘッダー

mail.to宛先 (受信者) ヘッダー

mail.ccCC 宛先ヘッダー

mail.subjectサブジェクト・ヘッダー

mail.messageidメッセージ ID ヘッダー

mail.messagenumberメッセージの内部番号

mail.sentメッセージが送信された日付

mail.receivedメッセージが受信された日付

mail.body1 パーツ・メッセージの場合、この属性にはメッセージ本文が含まれます。


mail.bodyparts複数パーツ・メッセージの場合、この属性には javax.mail.Part オブジェクトが含まれます。

mail.messageこれは、項目に戻されるメッセージを表す javax.mail.Message です。

関連情報131ページの『メールボックス EventHandler』

メモリー・ストリーム・コネクターメモリー・ストリーム・コネクターは、どのような Java ストリームとの間での読み書きでもできますが、ほとんどの場合はメモリーへの書き込みのために使用されます。そして、後でメモリーからフォーマット済みデータを検索することができます。バッファーは必要に応じて割り振られます。

このコネクターは、イテレーター・モード、AddOnly モード、または受動状態でのみ使用できます。このコネクターの動作は、どのように初期化されているかによって決まります。

initialize(null)これはデフォルトの動作です。コネクターはメモリーに書き込み、getDataBuffer() メソッドを使用してフォーマット済みデータを検索できます。このメソッドはメモリー・ストリーム・コネクターの中でのみ使用できます。コネクター名が MM である場合、次に示すコードはどこででも使用できます (例えば、プロローグ、エピローグ、すべてのフック、スクリプト・コンポーネントのほか、属性マッピングの中でも使用できます)。

var str = MM.connector.getDataBuffer();// use str for something.// To clear the data buffer and ready the Connector

for more output, re-initializeMM.connector.initialize(null);

initialize(Reader r)コネクターは r から読み取ります。これは、ストリームからの読み取りを行いたい場合に使用できます。

initialize(Writer w)コネクターは w に書き込みます。

initialize(Socket s)コネクターは、ソケット s からの読み取りおよび書き込みの両方を行うことができます。

注: 他のデータ・ストリームからの読み取りまたはそこへの書き込みを行いたい場合以外は、再初期化はしないでください。ロー・コネクター・オブジェクトを使用したい場合は、 172ページの『ロー・コネクター・オブジェクト』を参照してください。このコネクターには、getDataBuffer() という追加メソッドがあります。


構成詳細ログ

このフィールドにチェックマークを付けると、追加のログ・メッセージが生成されます。

パーサー出力をフォーマットする、または入力を解析するパーサーの名前。

MQe パスワード・ストア・コネクター

注: 詳細については、「MQ Everyplace Password Store Installation and Setup」(pwsync_install_directory¥IDS¥readme_mqepwstore_ismp.htm) を参照してください。

MQe パスワード・ストア・コネクターは、MQe QueueManager からパスワード更新メッセージを受け取ります。MQe パスワード・ストア・コネクターには、MQe

QueueManager が組み込まれています。 MQe QueueManager はコネクターの初期化時に始動し、コネクターの終了時に終了します。

MQe パスワード・ストア・コネクターでは、イテレーター・モードのみがサポートされます。

MQe パスワード・ストア・コネクターのワークフローは、次のとおりです。

1. MQe パスワード・ストア・コネクターは、JMS インターフェースを使用して、ローカル MQe QueueManager 上の事前定義済みキューからメッセージを要求します。

2. 検索されたメッセージが暗号化解除されます (このステップはオプションです)。

3. メッセージが解析され、項目オブジェクトが作成されます。この項目オブジェクトの属性は、ユーザー ID、パスワード値、およびパスワード更新のタイプを表します。

4. この新規に作成された項目オブジェクトが IBM Directory Integrator

AssemblyLine に受け渡されます。

MQe パスワード・ストア・コネクターは、初期化時に次のことを実行します。

v MQe QueueManager を始動します。

v ストレージ・コンポーネントへの接続を開始し、MQe パスワード・ストア・コネクターの QueueManager が稼動していることをストレージ・コンポーネントに通知します。

MQe パスワード・ストア・コネクターは、終了時に MQe QueueManage を停止します。

コネクターは、パスワード更新メッセージの取得時に、次の 3 つのモードのいずれかで作動できます。

待機なしQueueManager キュー内でパスワード更新メッセージを取得できるかどうか


を検査します。はいの場合は、このモードはメッセージを検索して解析します。いいえの場合は、モードは NULL を戻し、イテレーターの終了を示します。

待機するミリ秒数指定したミリ秒の間、パスワード更新メッセージが QueueManager キューに表示されるのを待機します。パスワード更新メッセージが表示されると、このモードはメッセージを検索して解析します。パスワード更新メッセージが表示されない場合は、このモードは NULL を戻し、イテレーターの終了を示します。

永久に待機コネクターは、QueueManager キューにパスワード更新メッセージが表示されるまで待機します。NULL が戻されることはありません。このモードで作動する場合は、コネクターを外部から停止する必要があります。

MQe パスワード・ストア・コネクター項目の構造MQe パスワード・ストア・コネクターは、次の固定属性構造の IBM Directory

Integrator 項目オブジェクトを構成します。

UserID単一のストリング値が含まれます。

OperationType次のストリング値のいずれかが含まれます。

v replace (パスワード値の置換操作)

v add (パスワード値の追加操作)

v delete (パスワード値の削除操作)

Passwords多値属性。各値は、パスワード値を表すストリングです。

構成QueueManager ini ファイル

生成される MQe QueueManager の ini ファイルへのパス。通常は、root_directory¥MQePWStore¥pwstore_server.ini です。

GetNext タイムアウトパスワード更新メッセージが QueueManager キューに表示されるのを、コネクターが待機するミリ秒を指定します。-1 は永久に待機することを指定し、0 はメッセージが取得できない場合に即時に戻ることを指定します。

ストレージ通知サーバーMQe コネクターからの通知を listen するストレージ・コンポーネント・サーバーを、host:port の形式で指定します。ポートのデフォルト値は 41002です。ホストは、パスワード・シンクロナイザーおよびストレージ・コンポーネントを配置するマシンの IP アドレスでなければなりません。

メッセージの暗号化解除ストレージ・コンポーネントがパスワード更新メッセージを暗号化し、そのメッセージを MQe コネクターが暗号化解除する必要がある場合には、このフィールドにチェックマークを付けます。


鍵ストア・ファイルパスワード・データの暗号化解除に使用する JKS ファイルのパス (「メッセージの暗号化解除」フィールドが選択されている場合にのみ考慮されます)。

鍵ストア・ファイルのパスワードJKS ファイルのパスワード (「メッセージの暗号化解除」フィールドが選択されている場合にのみ考慮されます)。

鍵ストア証明書の別名JKS ファイルからの鍵の別名 (「メッセージの暗号化解除」フィールドが選択されている場合にのみ考慮されます)。

鍵ストア証明書のパスワード秘密鍵の取得に使用するパスワード。これを指定しない場合は、秘密鍵の取得に「鍵ストア・ファイルのパスワード」が使用されます (「メッセージの暗号化解除」フィールドが選択されている場合にのみ考慮されます)。

詳細ログ詳細なログ・メッセージが必要な場合は、このフィールドにチェックマークを付けます。

NT4 コネクターNT4 コネクターは、Windows NT® セキュリティー・データベースを操作します。このコネクターは、Windows NT セキュリティー・データベースの 2 つの基本エンティティー、つまり Windows NT のユーザーとグループを取り扱います。NT4 コネクターは、ローカル Windows NT マシン、1 次ドメイン・コントローラー・マシン、および他のドメインの 1 次ドメイン・コントローラー・マシン上にあるWindows NT セキュリティー・データベースの読み取りおよび変更の両方を行うことができます。

注: この NT4 コネクターは Windows NT API に依存し、Windows プラットフォームでのみ稼働します。

NT4 コネクターは、Win32 API for Windows NT および Windows 2000 のユーザーおよびグループ・アカウントを使用して、Windows NT4 および Windows 2000

SAM データベースに接続するように設計されています。ユーザーは Windows 2000

の SAM データベースに接続できますが、NT4 コネクターは、NT4 との後方互換性を持つ属性のみを読み書きします (つまり、NT4 コネクターは、NT4 属性から成る定義済みの静的属性マップ・テーブルを持っています)。したがって、NT4 コネクターでは、Windows 2000 のネイティブ属性またはユーザー定義の属性はサポートされません。

NT4 コネクターの詳細な機能仕様、アーキテクチャーの説明、およびハードウェアとソフトウェアの要件については、 86ページの『NT4 コネクターの機能仕様とソフトウェア要件』を参照してください。

前提条件NT4 コネクターを正しく実行し、そのすべての機能を利用するには、NT4 コネクターは、ユーザー (ローカル管理者グループのメンバー) が所有するプロセス内で実行


され、ドメイン・コントローラーおよび他のドメイン (アクセスする場合) へのログイン特権を持っていることが必要です。NT4 コネクターのユーザー名およびパスワード・パラメーターを、上記の要件を満たすアカウントを指定するように設定してある場合は、この前提条件を省略できます。

NT4 コネクターは、次のモードで稼働するように設計されインプリメントされています。

v イテレーター

v ルックアップ

v AddOnly

v 削除

v 更新

注: NT4 コネクターは、拡張リンク基準をサポートしません (「IBM Tivoli



コンピューター名このコネクターを実行するマシンの名前 (例えば ntserver01) またはそのマシンの IP アドレス (例えば 212.52.2.218)。IBM Tivoli Directory

Integrator を実行しているマシンは、ターゲット・システムと同じドメインまたはワークグループの中になければなりません。

ユーザー名これをブランクのままにした場合は、指定したマシンでのログオンは行われず、NT4 コネクターは、IBM Tivoli Directory Integrator が実行されているプロセスの特権を持ちます。このパラメーターに何らかの値を指定した場合は、NT4 コネクターは、そのユーザー名とパスワード・パラメーターに指定されているパスワードを使用して、ComputerName マシンにログオンしようとします。

パスワードこのパラメーターの値が意味を持つのは、ユーザー名パラメーターをブランク以外の値に設定した場合だけです。その場合にログオン操作に使用するパスワードを指定します。

項目タイプ設定できる値は、User (NT4 コネクターがユーザーにより構造化されたデータを操作することを指定)、または Group (NT4 コネクターがグループにより構造化されたデータを操作することを指定) のいずれかです。

ページ・サイズNT4 コネクターがユーザーおよびグローバル・グループを検索するときに、Windows NT または Active Directory が 1 つのチャンクとして戻す項目 (ユーザーおよびグローバル・グループ) の数を指定します。指定できる値の範囲は 1 から 100 です。



リンク基準の構成NT4 コネクターをルックアップ・モード、更新モード、および削除モードで使用するときは、リンク基準を構成します。NT4 コネクターがサポートしているのは、1

つの項目を一意的に識別するリンク基準のみです。形式は厳密であり、この形式と一致しないリンク基準を渡すと、

「Unsupported Link Criteria structure」

という例外が発生します。

必要なリンク基準構造は、以下のとおりです。

User NT4 コネクターの項目タイプパラメーターが User に設定されていること。このパラメーターは、以下のような 1 つの行から成ります。

v NT4 コネクター属性は UserName に設定します。

v オペランドは equals に設定します。

v 値は、ユーザー・アカウントの名前 (例えばユーザー名) に設定するか、ユーザー・アカウントを受け取るテンプレートにより構成します。

Group NT4 コネクターの項目タイプパラメーターが Group に設定されていること。このパラメーターは、以下に示す 2 行から成ります。

1. 1 行目

v NT4 コネクター属性は GroupName に設定します。


v 値は、グループ・アカウントの名前 (例えばグループ名) に設定するか、グループ・アカウントを受け取るテンプレートにより構成します。

2. 2 行目

v NT4 コネクター属性は IsGlobal に設定します。


v 値は、True (1 行目に指定したグループ・アカウントがグローバルであることを示す)、または False (グループ・アカウントがローカルであることを示す) に設定します。グローバル・グループ・アカウントかローカル・グループ・アカウントかを示す True または False の値を受け取るテンプレートにより構成することもできます。

その他

ユーザー/グループ・アカウント名:

ドメイン・コントローラー・マシン上ユーザーおよびグループが検索され、次の形式でアクセスされます。

USER_NAME , GROUP_NAME


非ドメイン・コントローラー・マシン上ローカル・ユーザーおよびグループが検索され、次の形式でアクセスされます。

USER_NAME , GROUP_NAME

グローバル・グループおよびドメイン・ユーザー (非ドメイン・コントローラー・マシン上のローカル・グループのメンバーでもよい) が検索され、次の形式でアクセスされます。

DOMAIN_NAME\GLOBAL_GROUP_NAME , DOMAIN_NAME\USER_NAME

新規ユーザーの作成: NT4 コネクターで新規ユーザーを作成するときに、以下の属性のいずれかが省略されているか、または NULL 値が割り当てられている場合は、次のように自動的にデフォルト値が割り当てられます。

Flags アカウントは、通常アカウントおよびユーザー・パスワードは有効期限なしとしてマークされます。

AccountExpDateアカウントの有効期限なしを示す値が設定されます。

LogonHours時間制限なし (例えば、ユーザーは常にログオンできる) を示す値が設定されます。

ユーザー・パスワードの設定ユーザー・パスワードの値は検索できないということを忘れないでください。Windows NT は、パスワード値を読み取り不能の形で保管します。AssemblyLine

が、ある Windows NT マシンから別のマシンにユーザーをコピーする場合は、ユーザーは Password 属性値を手動で設定する必要があります。

値のない Password 属性を渡してユーザーを追加すると、空のパスワードを持つユーザーが作成されることになります。

値のない Password 属性を渡してユーザーを変更した場合は、旧パスワードがそのまま使用されます。

ユーザー 1 次グループ/グローバル・グループのメンバーシップの設定これは、ドメイン・ユーザー (1 次ドメイン・コントローラー・マシン上のユーザー) のみに適用されます。各ユーザーは、常に各自の 1 次グループのメンバーになります。これは、PrimaryGroup 属性に設定する値が GlobalGroups 属性内になければならないことを意味します。ただし、ユーザーを追加するときに、値のないPrimaryGroup 属性を設定することができます。この場合、デフォルトの 1 次グループは、そのユーザー (ドメイン・ユーザー) に設定されます。

グループの操作WindowsNT 固有の定義済みグループがいくつかあります。この種のグループに対しては実行できない操作があります。この操作とは、グループの一部の属性の削除、名前変更、および変更です。これらの定義済みグループに対して無効な操作を試行すると、例外が発生します。


以下に示すのは、Windows NT インストールに従って編成されたこれらのグループのリストです。

ドメイン・コントローラー:

v グローバル・グループ

– ドメイン管理者

– ドメイン・ユーザー

v ローカル・グループ

– 管理者

– ユーザー

– ゲスト

– バックアップ・オペレーター

– レプリケーター

– アカウント・オペレーター

– 印刷オペレーター

– サーバー・オペレーター

非ドメイン・コントローラー:

v ローカル・グループ

– 管理者

– ユーザー

– ゲスト

– バックアップ・オペレーター

– レプリケーター

– パワー・ユーザー

文字セットUnicode がサポートされています。

例ご使用の IBM Tivoli Directory Integrator システムの root_directory/examples/NT4 ディレクトリーにあります。

NT4 コネクターの機能仕様とソフトウェア要件NT4 コネクターは、以下に示すように、Windows NT の定義および制約条件に従って、Windows NT システムのユーザー管理とグループ管理の両方に NT4 コネクターの機能をインプリメントします。

機能

ユーザー/グループ・データの抽出: NT4 コネクターは、NT4 リポジトリーからユーザー情報とグループ情報の両方を読み取ります。これには、グループおよびユーザーのメタデータ、および関係情報 (例えば、users グループおよび groups グループのメンバーシップ) が含まれます。NT4 コネクターは、ローカルおよびドメイ


ンのユーザー・データまたはグループ・データを読み取ります。データは Windows

NT から読み取られ、編成されて、IBM Tivoli Directory Integrator エンジンが予期しているコンテナーに入れて供給されます。

ユーザー/グループ・データの追加: NT4 コネクターは、ローカル・マシンとドメイン・コントローラーの両方にユーザー情報を追加します。

NT4 コネクターは、ローカル・マシンとドメイン・コントローラーの両方にグループ情報を追加します。ドメイン・コントローラーを操作するときには、NT4 コネクターはローカル・グループとグローバル・グループの両方を作成できます。ドメイン・コントローラー以外のマシンを操作するときには、NT4 コネクターは、Windows NT が設定するセキュリティー上の制約条件に従い、ローカル・グループのみを作成することができます。

グループ・メンバーシップの変更: NT4 コネクターは、ローカル・グループおよびグローバル・グループの両方についてグループ・メンバーシップを変更します。グループへのメンバーの追加は、Windows NT のセキュリティー制限に従って、次のように行うことができます。

v グローバル・グループには、そのグループのドメイン内のユーザーのみをメンバーとして含めることができます。

v ローカル・グループには、そのドメインまたは他の任意のトラステッド・ドメイン内のグローバル・グループおよびユーザーを、メンバーとして含めることができます。ただし、ローカル・グループに他のローカル・グループを含めることはできません。

v ローカル・マシンには、特定グループのメンバーとなっていないユーザーが存在することができます。

v ドメイン・コントローラー上の各ユーザーは、同じ 1 次グループに属していなければなりません。ユーザーの 1 次グループは、ドメイン内のどのグローバル・グループでもかまいません。ユーザーの 1 次グループは変更できますが、ユーザーは常に自分の 1 次グループのメンバーです。

ユーザー/グループ・データの変更: NT4 コネクターは、ローカル・マシンおよびドメイン・コントローラーの両方の外部プロパティーおよびグループ・プロパティーを変更します。ドメイン・コントローラーに接続されているときは、NT4 コネクターは、ローカル・グループとグローバル・グループの両方のプロパティーを変更することができます。

ユーザー/グループ・データの削除: NT4 コネクターは、ローカル・マシンおよびドメイン・コントローラーの両方からユーザーを削除することができます。

NT4 は、ローカル・マシンおよびドメイン・コントローラーの両方からグループを削除することができます。ドメイン・コントローラーを操作しているときは、コネクターはローカル・グループとグローバル・グループの両方を削除することができます。


RDBMS 変更ログ・コネクターRDBMS 変更ログ・コネクターは、IBM Tivoli Directory Integrator が特定のRDBMS 表内の変更を検出できるようにします。現在、セットアップ・シナリオは、Oracle データベースと DB2® データベースの表に対して提供されています。

RDBMS には、選択済みデータベース表上で行われた変更を外部に通知するための共通のメカニズムはありません。このことに対処するため、IBM Tivoli Directory

Integrator では、一部の RDBMS メカニズム (トリガーやストアード・プロシージャーなど) が、ターゲット表内の変更されたレコードごとに 1 つのレコードを持つ個別の変更表を保持できます。シーケンス番号も、同じメカニズムによって保持されます。

LDAP 変更ログ・コネクターと同様に、RDBMS 変更ログ・コネクターは特定の形式で構成された変更表と通信するので、変更を他のシステムに伝達できます。形式は IBM DB2 Information Integrator (バージョン 8) で使用するものと同じであり、IBM Tivoli Directory Integrator ユーザーは、DB2II を使用してそのような表を作成したり、別の方法で表を作成するオプションを選択できます。RDBMS 変更ログ・コネクターはシーケンス番号のトラックを保持するので、変更表を使用して最後の繰り返し以降の変更のみを報告します。

RDBMS 変更ログ・コネクターは、JDBC を使用して特定の RDBMS テーブルに接続します。

RDBMS 変更ログ・コネクターは、イテレーター・モードでのみ稼働します。

RDBMS 変更ログ・コネクターは、特定のフィールドを読み取って、変更表内の新規の変更を判別します ( 89ページの『変更表の形式』を参照してください)。RDBMS 変更ログ・コネクターは、次の変更表レコードを読み取るか、最初の変更表レコードを検索します。変更表内にデータが見つからない場合は、RDBMS 変更ログ・コネクターは最大待ち時間を超えたかどうか確認します。最大待ち時間を超えた場合は、RDBMS 変更ログ・コネクターは反復の終了を示す NULL を戻します。変更表内にデータが見つからず、最大待ち時間を超えていない場合は、RDBMS

変更ログ・コネクターは特定の秒数 (ポーリング間隔) だけ待ってから、次の変更表レコードを読み取ります。

RDBMS 変更ログ・コネクターは変更表にデータを戻し、ユーザー・プロパティー・ストア (このタイプの永続的情報を調整するためのシステム・ストア内の領域)

の nextchangelog 番号を増分して更新します。

項目が戻されるたびに、制御情報 (カウンター、操作、時刻/日付) が項目プロパティーに移動します。変更表内の制御情報以外のすべてのフィールドは、そのまま属性として項目にコピーされます。項目オブジェクト操作 (getOperation により戻される) は、対応する変更ログ操作 (追加、削除、または変更) に設定されます。

イテレーター・モードでの RDBMS 変更ログ・コネクターのチェックポイント時に、変更番号はコネクター再始動情報として保管されます。



JDBC URLJDBC プロバイダーの資料を参照してください。これは、IBM Tivoli

Directory Integrator Config Editor では JDBC URL と呼ばれます。

ユーザー名コネクターが RDBMS にサインオンするときのユーザー ID。このユーザーが使用できる表のみが提示されます。

パスワードユーザーのパスワード。

スキーマ使用するデータベースの表内のスキーマ。これをブランクのままにした場合は、ユーザー名パラメーターの値が使用されます。

JDBC ドライバーJDBC ドライバーのクラス名。

表名操作する表またはビュー。

処理済みの行を除去次のポーリング試行の前に処理済みの表行をすべて除去する場合に選択します。

イテレーター状態鍵ユーザー・プロパティー・ストアへのアクセスに使用する鍵。

値を設定すると、IBM Tivoli Directory Integrator はユーザー・プロパティー・ストアから開始変更番号を検索します。

ポーリング間隔IBM Tivoli Directory Integrator が変更表をポーリングする時間 (秒単位) を指定します。

タイムアウト新規の変更を待つ時間 (秒単位) を指定します。値 0 (ゼロ) を設定すると、コネクターは無期限にループします。

コミットいつデータベース・トランザクションをコミットするかを制御します。オプションは、次のとおりです。

v 各データベース操作後

v コネクターのクローズ時

v 手動

手動とは、ユーザーが commit() を呼び出す必要があることを意味します。


変更表の形式以下の変更表の例では、NAME および EMAIL フィールドが含まれる表から変更を収集します。太字のエレメントは、すべての変更ログ表に共通です。この例の構文は、Oracle 用のものです。


IBMSNAP_COMMITSEQ is used as our changelog-nr.IBMSNAP_OPERATION takes on of the values I (Insert), U (Updated) or D (Deleted).CREATE TABLE "SYSTEM"."CCDCHANGELOG"(IBMSNAP_COMMITSEQ RAW(10) NOT NULL,IBMSNAP_INTENTSEQ RAW(10) NOT NULL,IBMSNAP_OPERATION CHAR(1) NOT NULL,IBMSNAP_LOGMARKER DATE NOT NULL,NAME VARCHAR2 ( 80 ) NOT NULL,EMAIL VARCHAR2 ( 80 ))#

DB2 での変更表の作成以下の例では、前述したように DB2 データベース内にトリガーを作成して、変更表を保持します。

connect to your_username

drop table emaildrop table ccdemail

create table email ( \name varchar(80), \email varchar(80) \)

create table ccdemail ( \ibmsnap_commitseq integer, \ibmsnap_intentseq integer, \ibmsnap_logmarker date, \ibmsnap_operation char, \name varchar(80), \email varchar(80) \)

drop sequence ccdemail_seqcreate sequence ccdemail_seq

create trigger t_email_ins after insert on email referencing new as n \for each row mode db2sql \

INSERT INTO your_username.ccdemail VALUES (nextval for ccdemail_seq, 0,CURRENT_DATE, ’I’, n.name, n.email )

create trigger t_email_del after delete on email referencing old as n \for each row mode db2sql \

INSERT INTO your_username.ccdemail VALUES (nextval for ccdemail_seq, 0,CURRENT_DATE, ’D’, n.name, n.email )

create trigger t_email_upd after update on email referencing new as n \for each row mode db2sql \

INSERT INTO your_username.ccdemail VALUES (nextval for ccdemail_seq, 0,CURRENT_DATE, ’U’, n.name, n.email )

Oracle での変更表の作成以下の例では、前述したように Oracle データベース内にトリガーを作成して、変更表を保持します。

CREATE SEQUENCE YOUR_USERNAME.SGENERATOR001 ORDER;

CREATE TRIGGER "YOUR_USERNAME"."ICCDCHANGELOG"AFTER INSERT ON "YOUR_USERNAME"."CHANGELOG"FOR EACH ROW BEGIN INSERT INTO "YOUR_USERNAME"."CCDCHANGELOG"(NAME,


EMAIL,IBMSNAP_COMMITSEQ,IBMSNAP_INTENTSEQ,IBMSNAP_OPERATION,IBMSNAP_LOGMARKER )VALUES (:NEW.NAME,:NEW.EMAIL,LPAD(TO_CHAR("YOUR_USERNAME"."SGENERATOR001".NEXTVAL),20,’0’),LPAD(TO_CHAR("YOUR_USERNAME"."SGENERATOR001".NEXTVAL),20,’0’),’I’,SYSDATE);END;

CREATE TRIGGER "YOUR_USERNAME"."UCCDCHANGELOG"AFTER UPDATE ON "YOUR_USERNAME"."CHANGELOG"FOR EACH ROW BEGIN INSERT INTO "YOUR_USERNAME"."CCDCHANGELOG"(NAME,EMAIL,IBMSNAP_COMMITSEQ,IBMSNAP_INTENTSEQ,IBMSNAP_OPERATION,IBMSNAP_LOGMARKER)VALUES(:NEW.NAME,:NEW.EMAIL,LPAD(TO_CHAR("YOUR_USERNAME"."SGENERATOR001".NEXTVAL),20,’0’),LPAD(TO_CHAR("YOUR_USERNAME"."SGENERATOR001".NEXTVAL),20,’0’),’U’,SYSDATE);END;

CREATE TRIGGER "YOUR_USERNAME"."DCCDCHANGELOG"AFTER DELETE ON "YOUR_USERNAME"."CHANGELOG"FOR EACH ROW BEGIN INSERT INTO "YOUR_USERNAME"."CCDCHANGELOG"(NAME,EMAIL,IBMSNAP_COMMITSEQ,IBMSNAP_INTENTSEQ,IBMSNAP_OPERATION,IBMSNAP_LOGMARKER)VALUES(:OLD.NAME,:OLD.EMAIL,LPAD(TO_CHAR("YOUR_USERNAME"."SGENERATOR001".NEXTVAL),20,’0’),LPAD(TO_CHAR("YOUR_USERNAME"."SGENERATOR001".NEXTVAL),20,’0’),’D’,SYSDATE);END;

COMMIT

ランタイム提供コネクターランタイム提供コネクターは、ランタイムに提供されるロー・コネクターです。EventHandler またはスクリプトにより AssemblyLine が開始されるときに、ユーザーは、AssemblyLine へのパラメーターとしてコネクターを 1 つだけ指定できます。このコネクターは、ランタイム提供タイプとして構成されている AssemblyLine

コネクター用に使用されます。このコネクターは、AssemblyLine 内で数回使用できます。

EventHandler からランタイム提供コネクターを使用する方法の例:

var myConnector = system.getConnector ("ibmdi.FileSystem");myConnector.setParam ("filePath", "mypath.txt");myConnector.initialize ( null );


// Start the AssemblyLinevar al = main.startAL ( "AssemblyLine1", myConnector );

初期作業項目が含まれる例:

var myConnector = system.getConnector ("ibmdi.FileSystem");myConnector.setParam ("filePath", "mypath.txt");myConnector.initialize ( null );

var entry = system.newEntry();entry.setAttribute ("cn", "My Name");entry.setAttribute ("mail", "([email protected])");

var al = main.startAL ( "AssemblyLine2", myConnector, entry );

構成このコネクターはパラメーターを必要とする場合がありますが、パラメーターの名前と値は実際のコネクターに応じて異なります。

関連情報「IBM Tivoli Directory Integrator 5.2 ユーザーズ・ガイド」の『IBM Tivoli

Directory Integrator concepts - The AssemblyLine』を参照してください。

スクリプト・コネクタースクリプト・コネクターを使用すると、使い慣れているスクリプトを使用して独自のコネクターを書くことができます。

スクリプト・コネクターが機能するためには、いくつかの関数をインプリメントする必要があります。このコネクターを繰り返しのためにのみ使用する (例えば、検索や更新ではなく読み取りを行う) ことを予定している場合は、2 つの関数のみで目的を果たすことができます。このコネクターを完全な機能を備えたコネクターとして使用することを予定している場合は、すべての関数をインプリメントする必要があります。これらの関数は、パラメーターを使用しません。これは、一部のスクリプト言語では必ずしもパラメーターの使用をサポートしていないためです。ホストとして稼働するコネクターとスクリプトの間のデータの受け渡しには、事前定義済みのオブジェクトが使用されます。これらの定義済みオブジェクトの 1 つに結果オブジェクトがあり、これは状況情報を伝達するために使用されます。いずれかの関数に入る時点では、状況フィールドは通常に設定されており、その場合ホスト・コネクターは呼び出しを続行します。入力終了またはエラーを通知するには、このオブジェクト内の状況フィールドおよびメッセージ・フィールドを設定します。他の 2 つのスクリプト・オブジェクト、項目オブジェクトと検索オブジェクトは、関数に入るときに定義されます。

注: スクリプト・コネクターまたはパーサーを変更すると、スクリプトは、それが入っているライブラリーから構成ファイルにコピーされます。これには、スクリプトをカスタマイズできるという利点がありますが、AssemblyLine が新規バージョンを認識しないという欠点もあります。

一つの次善策としては、AssemblyLine から旧スクリプト・コネクターを除去してから再導入する方法があります。その際、フックからコードをコピーするようにしてください。


定義済みスクリプト・オブジェクト

結果オブジェクト

setStatus (コード)

v 0: 入力終了

v 1: 状況 OK

v 2: エラー

setMessage (テキスト)エラー・メッセージ。

項目オブジェクト項目オブジェクトの説明については、 173ページの『項目オブジェクト』を参照してください。

検索オブジェクト検索オブジェクトの説明については、 175ページの『検索 (基準) オブジェクト』を参照してください。

関数スクリプト・コネクターは、以下の関数をインプリメントする必要があります。関数にはまったく呼び出される可能性のないものもいくつかありますが、このような関数は、呼び出し元にその関数がサポートされていないことを知らせるエラー通知コードと共に挿入しておくことをお勧めします。

selectEntriesこの関数は、順次読み取り用としてコネクターを準備するために呼び出されます。このコネクターが呼び出されるのは、通常、コネクターがAssemblyLine 内でイテレーターとして使用される場合です。

getNextEntryこの関数は、入力セット内の次のエントリーから属性と値を項目オブジェクトに取り込みます。戻す項目がなくなると、コネクターは結果オブジェクトを使用して、呼び出し元に入力終了を知らせます。

findEntryfindEntry 関数は、接続されているシステム内で、検索オブジェクトに指定されている基準と一致する項目を検索するために呼び出されます。コネクターが一致項目を 1 つだけ検出した場合は、コネクターはその項目オブジェクトを取り込みます。該当項目が 1 つも見つからない場合は、コネクターは、結果オブジェクトの中に、項目を検出できなかったことを知らせるエラー・コードを設定します。一致する項目が複数検出された場合は、コネクターは重複項目の配列を取り込むことができます。それ以外の場合は、該当項目が見つからない場合と同じプロシージャーが行われます。

modEntryこの関数は、接続されているシステム内の既存項目を変更するために呼び出されます。新しい項目データは項目オブジェクトから提供され、どの項目を変更するかは検索オブジェクトで指定されます。一部のコネクターは、通知


なしで検索オブジェクトを無視し、項目オブジェクトを使用してどの項目を変更するかを決定することがあります。

putEntryこの関数は、接続されているシステムに項目オブジェクトを追加します。

deleteEntryこの関数は、接続されているシステム内の既存項目を削除するために呼び出されます。削除する項目は検索オブジェクトに指定します。一部のコネクターは、通知なしで検索オブジェクトを無視し、項目オブジェクトを使用してどの項目を削除するかを決定することがあります。


スクリプト言語リストからスクリプト言語を選択します。

外部ファイル実行時に外部スクリプト・ファイルを組み込む場合は、それらのファイルを指定します。ファイルは 1 行に 1 つずつ指定してください。これらのファイルは、スクリプトの前に開始されます。

グローバル・スクリプトの組み込みスクリプト・ライブラリーからグローバル・スクリプトを組み込みます。


スクリプト独自のスクリプト・コードを作成できます。

例ご使用の IBM Tivoli Directory Integrator システムのroot_directory/examples/script_connector ディレクトリーにあります。

関連情報157ページの『スクリプト・パーサー』、および「IBM Tivoli Directory Integrator

5.2 ユーザーズ・ガイド」の『JavaScript Connector』を参照してください。

SNMP コネクターこのコネクターは、ネットワーク上で送信される SNMP トラップを listen し、SNMP PDU 内のすべてのエレメントの名前と値を示す項目を戻します。

注:

1. クライアント・モードでは、要求は、1 回ごとに間隔を長くしながら、13 秒間にわたり 5 回再試行されます。その間に応答が受信されないと、タイムアウトが生じます。

2. SNMP トラップを送信することが目的である場合は、system.snmpTrap() メソッドを使用できます。


3. SNMP コネクターは、拡張リンク基準をサポートしません (「IBM Tivoli



コミュニティー・ストリングpublic を使用してコネクターをテストします。

モードトラップ・リスナーまたはクライアント。クライアント・モードの場合は、このコネクターを、AddOnly モード (SNMP Set)、ルックアップ・モード(SNMP Get)、またはイテレーター・モード (Walk) で使用できます。

トラップ・リスナーの場合は繰り返しのみが可能で、ローカル・ホスト上でトラップが listen されます。

SNMP トラップ・ポートトラップ・モードのポート。クライアント・モードでは使用されません。

トラップ待機タイムアウトトラップ・モードでのタイムアウト。次のプロトコル・データ単位 (PDU)

を待つミリ秒数。この値が 0 以下の場合は、コネクターは無期限に待機します。

SNMP ホスト (get 用)クライアント・モードでの Get の場合のみ使用されます。トラップ・モードでは使用されません。

SNMP ポートクライアント・ポート (クライアント・モードの場合)。トラップ・モードでは使用されません。

SNMP Walk OID (繰り返し)クライアント・モードのイテレーター・コネクターでのみ使用されます。ウォークする OID ツリーを指定します。

SNMP バージョンクライアント・モードでの get/walk 用のデフォルト・バージョン。トラップ・モードでは使用されません。


注: このコネクターではリンク基準の取り扱いが他と異なります。ルックアップ・モードでは、このコネクターは get 要求を実行し、要求された oid についてoid/値を戻します。リンク基準は、oid、サーバー、ポート、およびバージョンを指定します。例えば、リンク基準は、″oid″ = ″1.1.1.1.1.1.1″ のようになります。

例ご使用の IBM Tivoli Directory Integrator システムのroot_directory/examples/snmpTrap ディレクトリーにあります。


TCP コネクターTCP コネクターは、トランスポート用に TCP ソケットを使用するトランスポート・コネクターです。 TCP コネクターは、イテレーター・モードおよび AddOnly

モードでのみ使用できます。

イテレーター・モードイテレーター・モードで使用する場合、TCP コネクターは、特定のポート上で着信TCP 呼び出しを待ちます。接続が確立されると、getnext メソッドが以下のプロパティーを持つ項目を戻します。

socketTCP ソケット・オブジェクト (例えば、TCP 入力および出力ストリーム)

in ソケットの入力ストリームを使用する BufferedReader のインスタンス

out ソケットの出力ストリームを使用する BufferedWriter のインスタンス

in および out オブジェクトは、TCP 接続からのデータの読み取り、または TCP

接続へのデータの書き込みのために使用されます。例えば、次のようにして、単純なエコー・サーバーをインプリメントすることができます (コードを GetNext 後フックに書き込みます)。

var ins =conn.getProperty("inp");var outs =conn.getProperty("out");var str =ins.readLine();outs.write("You said==>"+str+"<==");outs.flush();

BufferedWriter を使用しているので、データが実際にこの接続で発信されるようにするために、out.flush() メソッドを呼び出すことが重要です。

パーサーを指定した場合は、BufferedReader はそのパーサーに渡され、パーサーがストリーム上で送信されるデータを読み取って解釈します。その結果、戻される項目には、上記にリストしたプロパティー (socket、in、および out) のほかに、パーサーが割り当てる属性が組み込まれます。

TCP コネクターが serverMode=true として構成されている場合は、getnext メソッドに対する各呼び出し間で接続がクローズされます。serverMode=false の場合は、リモート・ホストへの接続は、TCP コネクターがアクティブの間は (例えば、AssemblyLine が終了するまで) オープンのままになっています。

AddOnly モードTCP コネクターがこのモードになっているときは、デフォルトのインプリメンテーションでは、項目は、有用とは言えないストリング形式で書き込まれます。通常は、特定出力を行うには、パーサーを指定するか、追加の指定変更フックを使用します。追加の指定変更フックでは、次のように、ロー・コネクターの getReader() および getWriter() メソッドを呼び出して、in または out オブジェクトにアクセスします。

var in = mytcpconnector.connector.getReader();var out = mytcpconnector.connector.getWriter();


また、追加前フックおよび追加後フックを使用して、パーサーからの出力の前後にヘッダーまたはフッターを挿入することもできます。

構成TCP ポート

servermodeの値に応じて、接続または listen する TCP ポート番号。

TCP ホスト接続するリモート・ホスト (servermode = false の場合)。

サーバー・モードtrue の場合は、繰り返し操作では着信要求が listen されます。 false の場合は、繰り返し操作ではリモート・サーバーに接続されます。


パーサー項目の読み取りまたは書き込みに使用するパーサー。

関連情報23ページの『ファイル・システム・コネクター』, 7ページの『直接 TCP/URL スクリプト』, 『URL コネクター』

URL コネクターURL コネクターはトランスポート・コネクターの 1 つであり、このコネクターが正しく機能するにはパーサーが必要です。このコネクターは、URL で指定されているストリームをオープンします。

注: プロキシー・サーバーを強制適用するファイアウォールを通して実行された場合は、URL コネクターは機能しません。 URL コネクターは、正しいプロキシー・サーバー・セットを持っている必要があります。


URL 公開する URL (例えば、http://host/file.csv)。


パーサーファイルの内容を取り扱うパーサーの名前。

サポートされる URL プロトコルサポートされる URL プロトコルは、以下のとおりです。

v HTTP


関連情報23ページの『ファイル・システム・コネクター』, 96ページの『TCP コネクター』, 7ページの『直接 TCP/URL スクリプト』

Web サービス・コネクターWeb サービス・コネクターは、Web サービス・プロバイダーに接続し、特定のWeb サービス操作を呼び出します。

Web サービス・コネクターは、アクセスする Web サービスの定義を Web サービス記述言語 (WSDL) 文書から読み取ります。

サポートされているオブジェクトおよびトランスポート・プロトコルは、SOAP および HTTP です。

Web サービス・コネクターは、Call/Reply モードで稼働します。

注: この Web サービス・コネクターを使用するには、直接インターネット接続が利用できることが必要です。たとえば、使用しているインターネット接続にHTTP プロキシー・サーバーが含まれており、ブラウザーがそのプロキシーを使用するように設定されている場合は、ブラウザーで wsdl ファイルを表示することはできますが、Web サービス・コネクターでそのファイルを検索することはできません。

Web サービス・コネクターでは、要求/応答タイプの操作のみがサポートされます。

Web サービス・コネクターの使用Web サービス・コネクターは Call/Reply モードで稼働するものであり、これはAssemblyLine における中間コネクターのような役割を果たすことを意味します。このコネクターは、以下のことを行います。

1. Web サービス・コネクターの出力マップ内の属性を、指定された WSDL 定義に照らして検証します。

2. WSDL 定義に従って必要な SOAP 要求を作成します。

3. この要求を Web サービス・プロバイダーに送信します。

4. Web サービス・プロバイダーの SOAP 応答を受信します。

5. SOAP 応答を解析し、conn 項目オブジェクトを作成します。

6. conn 項目の属性を WSDL 定義に照らして検証します。

この単純なシナリオに従って AssemblyLine を拡張し、ワークフロー内の各種のステージでさまざまな Web サービスにアクセスできるようにすることができます。

稼動中の Web サービス EventHandler を、Web サービス・コネクターの Web サービス・プロバイダーにすることができますが、その場合、非 IBM Tivoli Directory

Integrator Web サービスも使用されます。

RPC スタイルの SOAP 操作Web サービス・コネクターでは、リモート・プロシージャー・コール (RPC) スタイルの SOAP 操作のみがサポートされます。文書スタイルの SOAP 操作はサポー


トされません。WSDL 文書を指定した場合、Web サービス・コネクターは文書スタイルの SOAP 操作をすべてスキップします。Web サービス・コネクターは、初期化の時点で、WSDL の解析の際にスキップされたすべての文書スタイルの SOAP

操作名をログにダンプします。

属性マッピングと検証WSDL メッセージは、Web サービス操作の入力属性および出力属性の名前とタイプを定義します。Web サービス・コネクターは、WSDL メッセージで定義されている入力属性を、Web サービス・コネクターの出力マップから検索します。この出力マップは、作業項目内の属性を Web サービス・コネクターにマップします。

注: Web サービス・コネクターは、出力マップの中で、WSDL 文書内で定義されている名前とタイプに一致する属性を検索します。出力マップ内に余分な属性があっても、問題はありません。ただし、WSDL 入力属性の中に出力マップ内に見つからない属性がある場合は、Web サービス・コネクターは例外をスローします。

Web サービス・コネクターは、Web サービスから戻ると、Web サービスから戻されたデータを conn 項目に保管します。次に、Web サービス・コネクターの入力マップにより、conn 項目の属性が AssemblyLine の作業項目にマップされます。Web サービス・コネクターは、conn 項目内の名前、タイプ、および合計属性数(例えば Web サービスから戻されたデータ) が、WSDL 出力属性と一致するかどうかを確認します。そして、一致しない場合は例外がスローされます。したがって、Web サービスが WSDL 文書と一致するデータを戻さない場合は、Web サービス・コネクターは失敗することになります。

Web サービス操作の入力パラメーターに必要なデータ・タイプの設定Web サービス・コネクターは、Web サービス操作用の入力パラメーターを出力マップから取得します。Web サービス・コネクターが正しく機能するには、出力マップ内の属性のタイプ (これは Web サービス操作への入力パラメーターとして使用される) が、Web サービス操作で予期されているタイプと一致していることが必要です。Web サービス操作で入力パラメーターとして予期されているデータ・タイプを判別するには、後述のセクションの説明のとおりにスキーマ照会を使用します。以下を実行して、属性のデータ・タイプを Web サービス操作に必要なタイプに設定してください。

1. Web サービス・コネクターの出力マップを表示します。

2. データ・タイプを設定する属性を選択します。

3. 「属性マップ設定」セクションの「拡張マッピング」チェック・ボックスにチェックマークを付けます。

4. ここでは、age という属性があり、この属性の値タイプを java.lang.Integer に設定するとします (スキーマ照会では、Web サービス操作を行うためには age入力パラメーターが java.lang.Integer であることが必要なため)。スクリプト編集ボックスに次のように入力します。

ret.value = new java.lang.Integer(integer_as_string);


ここで、integer_as_string は age 属性値のストリング表現です。したがって、age 属性にデフォルトの属性マッピング・モードを使用した場合は、次のように入力すればよいことになります。

ret.value = new java.lang.Integer(conn.getString("age"));

これで、age 属性は java.lang.Integer として Web サービス・コネクターに受け渡されます。

構成WSDL URL

Web サービス定義を含む WSDL 文書の URL。

Web サービス操作呼び出す Web サービス操作の名前。Web サービス・コネクターの Config

Editor 上の「操作...」ボタンを使用すると、RPC スタイルの操作のみが表示されます。ユーザーは、Web サービス・コネクターによって呼び出す操作を選択する必要があります。



パーサーパーサーを指定した場合は、追加操作の対象として送られたデータを生成するためにそのパーサーが使用されます。

エラー時フックWeb サービス・コネクターがサーバーから SOAP 障害を受け取ったときに、Web

サービス・コネクターのエラー時フックが有効になっていると、エラー時フックが起動されます。エラー・オブジェクト (エラー時フック内で使用可能) のメッセージ属性には、SOAP 障害に含めて送られたエラー情報が含まれています。

サポートされるスキーマ/ネーム・スペースのタイプWeb サービス・コネクターは、http://www.w3.org/2001/XMLSchema (またはhttp://www.w3.org/1999/XMLSchema) で定義されているタイプのサブセットをサポートしています。 Web サービス・コネクターは、その他のスキーマはサポートしていません。

注: Web サービス EventHandler および Web サービス・コネクターを操作するときに、属性名の最初の 1 文字には、特殊文字 ([0 から 9] [ - ’ ( ) + , . / = ? ;! * # @ $ %] など) を使用することはできません。また、特殊文字 ([ ’ ( ) +, / = ?; ! * # @ $ % ] など) を属性名の中で使用することもできません。これは、Web サービスは SOAP (つまり XML) を基礎として作成されており、XML はタグ内の文字として $ を受け入れないためです。


第 3 章 EventHandler

EventHandler は、AssemblyLine およびコネクターの実行を制御するフレームワークを用意して、機能を拡張するために使用されます。このフレームワークは、着信イベント (例えば、着信 http、LDAP 変更トリガー、JMS メッセージ) が、着信データの内容に応じていくつかの異なる AssemblyLine を起動する場合に、特に便利です。操作を簡素化するために、プログラム済みの EventHandler がいくつか用意されています。

注: EventHandler の動作は、ユーザー独自のスクリプトによりいつでも指定変更できます。

EventHandler のタイプIBM Tivoli Directory Integrator に組み込まれている EventHandler には、以下のものがあります。

標準 EventHandler標準 EventHandler は、最も使用される EventHandler です。ユーザーは、多数の事前定義済みの条件およびアクションを使用して、条件とアクションを指定します。また、フル制御のためのスクリプト・コードを開始できるフックも提供します。詳細については、 122ページの『JMX EventHandler』および 126ページの『LDAP EventHandler』を参照してください。

プリミティブ EventHandler (単純 EventHandler、トリガー、またはポート・リスナー) プリミティブ EventHandler では、あらゆるもののスクリプトを作成できま

す。この EventHandler を使用すると EventHandler のアクションのフル制御が可能になりますが、ユーザーは EventHandler を手動でコーディングする必要があります。詳細については、 136ページの『汎用スレッド (プリミティブ EventHandler)』および 137ページの『タイマー EventHandler (プリミティブ EventHandler)』を参照してください。

拡張 EventHandler拡張 EventHandler は、標準 EventHandler を上回る機能を Config Editor に包含します。 138ページの『Web サービス EventHandler』を参照してください。

どのようなときに始動されるかIBM Tivoli Directory Integrator サーバーは、始動後、EventHandler のテーブルをスキャンし、各 EventHandler について自動始動フラグの有無をチェックします。自動始動フラグが設定されている EventHandler は、IBM Tivoli Directory Integrator サーバー・プロセスの内部のスレッドとして spawn されます。EventHandler スレッドが停止しても、IBM Tivoli Directory Integrator サーバーは EventHandler を再始動しません。

注: コマンド行オプションを使用すれば、自動始動フラグの設定に関係なく、強制的に EventHandler を始動することができます。


Config Editor から EventHandler を始動する方法の詳細については、「IBM Tivoli

Directory Integrator 5.2 ユーザーズ・ガイド」の『Starting the EventHandler』を参照してください。

EventHandler の働きEventHandler はさまざまの機能を実行しますが、代表的な働きは、外部イベントによって IBM Tivoli Directory Integrator サーバー内部でアクションが起動されるようにすることです。これらのアクションは、各サイトおよび各個人にとってはそれぞれ異っていても、AssemblyLine にとっては 1 つの共通アクションとなることもあります。例えば、タイマーは、クロックが特定の時点に到達したという外部イベントにより起動されるアクションです。その他のイベントは、TCP ポートEventHandler が着信 TCP 接続を待っている場合のように非同期であったり、メールボックス・コネクター EventHandler のように接続やイベントへのポーリングを開始する場合があります。詳細については、EventHandler の構成を参照してください。

データ・フローEventHandler には、AssemblyLine のようにプロローグとエピローグが存在します。プロローグは、各イベントのアクション・フローの前に開始されます。

AssemblyLine への入出力ファイル名の引き渡しEventHandler から AssemblyLine にファイル名を受け渡すには、項目オブジェクトを使用します。次の例では、ファイル名は myFileName で、属性の代わりにプロパティーを使用しています。

var entry = system.newEntry();entry.setProperty("inputFileName","myFileName");// start AssemblyLinevar al = main.startAL ("myAssemblyLine", entry);al.join (); // wait for al to finish

AssemblyLine サイドでは、コネクター初期化前フックの中でプロローグをコーディングします (コネクターが初期化されるときに指定のパラメーターが使用されるようにするため)。

workEntry = task.getWork(); // gets the initial entryvar FileName = workEntry.getProperty("inputFileName");// Set the relevant parameter of the (Connector)myFileConnector.connector.setParam("filePath",FileName);// If you don’t want the AssemblyLine to run with the intitial entry, clear ittask.setWork(null);

これについては、細かい注意点が 2 つあります。

1. 作業項目を消去すると、制御が最初のイテレーターに受け渡されることになります。処理が必要な項目は消去しないでください。AssemblyLine の初期化時に有効な作業項目が存在する場合は、AssemblyLine 内のすべてのイテレーターがその作業サイクルのためにバイパスされ、最初の非イテレーターで処理が開始されます。詳細については、「IBM Tivoli Directory Integrator 5.2 ユーザーズ・ガイド」の『Connector Modes』を参照してください。


2. 属性の代わりにプロパティーを使用することにより、AssemblyLine が後で属性をマップしないようにすることができます (すべての属性を自動的にマッピングします)。

EventHandler の可用性IBM Tivoli Directory Integrator に組み込まれている EventHandler には、以下のものがあります。

v 『Active Directory 変更ログ EventHandler』

v 107ページの『コネクター EventHandler』

v 108ページの『DSMLv2 EventHandler』

v 114ページの『Exchange 変更ログ EventHandler』

v 117ページの『HTTP EventHandler』

v 119ページの『IBM Directory Server EventHandler』

v 122ページの『JMX EventHandler』

v 126ページの『LDAP EventHandler』

v 130ページの『LDAP サーバー EventHandler』

v 131ページの『メールボックス EventHandler』

v 133ページの『SNMP EventHandler』

v 135ページの『TCP ポート EventHandler』

v 136ページの『汎用スレッド (プリミティブ EventHandler)』

v 137ページの『タイマー EventHandler (プリミティブ EventHandler)』

v 138ページの『Web サービス EventHandler』

v 145ページの『zOS LDAP 変更ログ EventHandler』

Active Directory 変更ログ EventHandlerActive Directory 変更ログ EventHandler は、Active Directory 内の変更を検出し、通知を送信します。この EventHandler は変更された Active Directory オブジェクトを報告するので、他のデータ・ソースは Active Directory と同期することができます。変更通知の登録および変更済みオブジェクトの検索のどちらにも、LDAP プロトコルが使用されます。

この EventHandler は、Active Directory 変更ログ・コネクターを内部で使用して、Active Directory から変更済みオブジェクトを取得します。変更済みオブジェクト検索は、「uSNChanged」メカニズムに基づいて行われます。

変更の検索順序、送達済み項目の構造、および削除済みオブジェクトと移動済みオブジェクトの処理の詳細については、 60ページの『Active Directory 変更ログ・コネクター』を参照してください。

この EventHandler は、LDAPv3 サーバー通知要求制御を使用して、Active Directory

内で新たに変更が発生するまでブロックします。

第 3 章 EventHandler 103

動作この EventHandler は、始動後、Active Directory に接続し、すべての新しいディレクトリー変更 (この EventHandler がオフライン中に発生したもの) を検索します。次にブロックし、Active Directory 内の新たな変更を待ちます。新たな変更が見つかると、EventHandler はすべての新しい変更を検索し、新たな変更を待機しながら再びブロックします。この EventHandler が実行されていない間の通知を失うことはありません。これは、この EventHandler が始動されるたびに、オフライン中に行われた変更が検索されるからです。

Active Directory 変更ログ EventHandler には、同期プロセス中のどの時点でも割り込むことができます。この EventHandler は同期プロセスの状態を IBM Tivoli

Directory Integrator のユーザー・プロパティー・ストアに保管するので (各項目の検索後)、次回に EventHandler を開始したときには、割り込まれた位置から正しく同期が続行されます。

Active Directory がオフライン状態になると、EventHandler は停止せずに、成功または停止が要求されるまで再接続を試行します。

ユーザー・プロパティー・ストア内の USN 同期値へのアクセス任意の時間の同期状態は、4 つの更新シーケンス番号 (USN) で表されます。

v START_USN

v END_USN





// Retrieve USN values from User Property Storevar usn = system.getPersistentObject("ad_sync");var startUsn = usn.getString("START_USN");var endUsn = usn.getString("END_USN");var currentUsnCreated = usn.getString("CURRENT_USN_CREATED");var currentUsnChanged = usn.getString("CURRENT_USN_CHANGED");


"ad_sync" は、ユーザー・プロパティー・ストアに既に保管されているパラメーターの名前です。この値は、永続パラメーター名パラメーターで指定します。上記の例では値を画面にダンプしていますが、他に希望するアクションを実行できます。例えば、値をファイルに保管して、このファイルをバックアップすることもできます。



// Store USN values in the User Property Storevar usn = system.newEntry();usn.setAttribute("START_USN", startUsn);usn.setAttribute("END_USN", endUsn);usn.setAttribute("CURRENT_USN_CREATED", currentUsnCreated);usn.setAttribute("CURRENT_USN_CHANGED", currentUsnChanged);system.setPersistentObject("ad_sync", usn);

このコードでは、変数 startUsn、endUsn、currentUsnCreated、およびcurrentUsnChanged にストリングとして USN 番号が含まれると想定されています。この例では、"ad_sync" パラメーターに USN 値が保管されるので、希望する時点から同期を続行するためには、EventHandler の永続パラメーター名パラメーターに"ad_sync" を指定する必要があります。

ランタイム EventHandler の USN 同期値へのアクセスActive Directory 変更ログ EventHandler には、現在の USN 値にアクセスするために以下の共通メソッドがあります。


v START_USN

v END_USN



各属性の値のタイプは java.lang.Integer であり、対応する EventHandler

の USN 値を表します。

public void setUsnValues (Entry usnEntry);EventHandler の現在の USN 同期値を、usnEntry パラメーターに指定された値に設定します。usnEntry パラメーターの構造は、getUsnValues() により戻された項目の構造と同じにする必要があります。usnEntry 属性の値は、java.lang.Integer か、対応する数のストリング表現にする必要があります。


構成この EventHandler は、以下のパラメーターを必要とします。




ログイン・ユーザー名サービスへの認証に使用する識別名。例えば、cn=administrator,cn=users,dc=your_domain,dc=com。







SSL の使用Active Directory との LDAP 通信に Secure Sockets Layer を使用するかどうかを指定します。

LDAP 検索ベース変更の有無を調べるためにポーリングされる Active Directory サブツリー。例えば、dc=your_domain,dc=com。

注: これはディレクトリーのネーミング・コンテキストでなければなりません。

永続パラメーター名IBM Tivoli Directory Integrator のユーザー・プロパティー・ストアに現在の同期状態を保管するパラメーターの名前を指定します。この名前は、IBM


開始位置EOD または 0 を指定します。EOD は、EventHandler の開始後に発生した変更のみを報告することを意味します。0 は、完全同期の実行を意味します。つまり、Active Directory サービス内の使用可能なすべてのオブジェクトを報告します。このパラメーターを考慮するのは、永続パラメーター名パラメーターに指定されたパラメーターがユーザー・プロパティー・ストアに見つからない場合のみです。

詳細ログ詳細なデバッグ情報をログ・ファイルに書き込むかどうかを指定します。

自動始動サービスこのフィールドにチェックマークを付けると、IBM Tivoli Directory

Integrator の始動時にこの EventHandler が始動します。


コネクター EventHandlerこの EventHandler は、任意のコネクターを入力イベント・ジェネレーターとして使用します。この EventHandler は、コネクターの getNext メソッドを呼び出して、コネクターから次の項目を取得します。コネクターは、入力の終わりに達するとNULL を戻します。EventHandler は、コネクターが NULL を戻した後も、コネクターの入力メソッドを呼び出し続けます。この動作は、コネクターによって、意義がある場合も無意味な場合もあります。

例えば、ファイル・システム・コネクターを使用している場合は、コネクターが読み取ったファイルにいつでもデータを付加できるため、この動作には意義があります。有限の項目セットを選択するコネクターの場合は、最後には処理する項目がなくなってしまうので、EventHandler は無限に新規データを待ち続けることになります。


グローバル・コネクター入力に使用するコネクター。

ポーリング間隔コネクターから NULL 項目が受信された後の、コネクターに対する各呼び出し間の秒数。



詳細ログ詳細なログ情報をログ・ファイルに書き込むかどうかを指定します。

オブジェクト/プロパティー/属性EventHandler は、以下のイベント・プロパティーを設定します。

event.originatorEventHandler オブジェクト。

event.connectorこの EventHandler が使用するコネクター・オブジェクト。

イベント・オブジェクトには、コネクターから戻された属性も含まれます。

関連情報「IBM Tivoli Directory Integrator 5.2 管理者ガイド」の『Starting the EventHandler』を参照してください。


DSMLv2 EventHandlerDirectory Services Markup Language v1.0 (DSMLv1) を使用すると、ディレクトリー構造情報を XML 文書として表現できます。DSMLv2 はさらに進歩し、ディレクトリーの照会や更新 (ひいてはこれらの操作) を XML 文書として表現するメソッドを提供します。DSMLv2 文書は、さまざまな方法で使用できます。IBM Tivoli

Directory Integrator には、DSML サーバーとして機能し、HTTP を介して DSMLv2

要求を listen する EventHandler が用意されています。要求を受け取ると、EventHandler はその要求を解析し、処理のために AssemblyLine に送信します。結果は HTTP を介してクライアントに送り返されます。

DSMLv2 EventHandler は単純な Web サーバーであり、HTTP 要求メッセージ内のHTTP 本文として転送される DSMLv 要求の処理方法を提供します。 DSMLv2

EventHandler は、クライアント要求をイベント・オブジェクトに自動的に解析し、要求の操作用に構成されたユーザー定義の AssemblyLine を呼び出します。このAssemblyLine は、通常、適切なモードの単一コネクターから構成されます。 111ページの『構成』を参照してください。また、認証コネクターを指定した場合は、この EventHandler は HTTP 基本認証をインプリメントします。

このリリースでは、DSML インプリメンテーションは DSMLv2 仕様に完全には準拠しません。サポートされるバインディングおよび操作は限定されます。

DSMLv2 EventHandler の例は、examples ディレクトリー(examples¥event_handler_dsmlv2_http¥DSML_EH_Test.xml) にあります。

移送 (バインディング)DSMLv2 の要求および応答は、HTTP を介して HTTP 本文として DSML クライアントと DSMLv2 EventHandler 間で移送されます。IBM Tivoli Directory Integrator

では、要求ごとに 1 つの操作のみがサポートされます。SOAP およびファイル・バインディングは、この EventHandler には組み込まれていません。

操作IBM Tivoli Directory Integrator では、変更、追加、削除、検索、ModifyDN、および比較操作がサポートされます。

変更DSMLv2 は、操作属性を attr エレメントに付加することによって各属性の変更を指定します。LDAP の場合と同様に、操作は追加、削除、または置換です。

AssemblyLine に受け渡される初期作業項目には、以下のプロパティーがあります。

dsml.operationmodifyRequest

dsml.baseDN 値 (例えば ″CN=Bob Rush,OU=Dev,DC=Example,DC=COM″)

この操作には、DSMLv2 要求内のすべての属性のほか、次の属性も含まれます。

$dn DN 値 (例えば ″CN=Bob Rush,OU=Dev,DC=Example,DC=COM″)


追加DSMLv2 addRequest は、searchResultEntry と同様のエンコード・スタイルを使用して、追加するオブジェクトを記述します。


dsml.operationaddRequest

dsml.baseDN 値 (例えば ″CN=Alice,OU=HR,DC=Example,DC=COM″)


$dn DN 値 (例えば ″CN=Alice,OU=HR,DC=Example,DC=COM″)

削除AssemblyLine に受け渡される初期作業項目には、以下のプロパティーがあります。

dsml.operationdeleteRequest

dsml.baseDN 値 (例えば ″CN=Bob,OU=HR,DC=Example,DC=COM″)


$dn DN 値 (例えば ″CN=Bob,OU=HR,DC=Example,DC=COM″)

検索DSMLv2 の検索エンコード方式は、LDAP 検索エンコード方式に基づいています。searchRequest エンコードのプロパティーは以下のとおりです。

baseObjectDSMLv1 規則に従い、検索ベースの識別名は XML 属性 dn として表されます。例えば、次のようにします。

<searchRequest dn="OU=Marketing,DC=Example,DC=COM" />

attributesattributes は属性名のシーケンスであり、属性名を含むエレメントのシーケンスに変換します。これらの属性名は、応答内の戻り属性です。例えば、次のようにします。

<attributes><attribute name="sn"/><attribute name="givenName"/><attribute name="title"/></attributes>

RootDSE 検索要求の場合、EventHandler は AssemblyLine を開始しません。 EventHandler は、ユーザーが構成したルート・ネーミング・コンテキストのリストを戻します。


dsml.operationsearchRequest


dsml.baseDN 値 (例えば ″ou=Marketing,dc=example_company,dc=com″)

dsml.filterフィルター要素に基づいて構成された、正規表現形式のフィルター・ストリング。

dsml.attributes戻り属性 (例えば ″cn″)


$dn DN 値 (例えば ″ou=Marketing,dc=example_company,dc=com″)

ModifyDNAssemblyLine に受け渡される初期作業項目には、以下のプロパティーがあります。

dsml.operationmodDnRequest

dsml.baseDN 値 (例えば ″CN=Alice Johnson,DC=Example,DC=COM″)


$dn DN 値 (例えば ″CN=Alice Johnson,DC=Example,DC=COM″)

newrdnnewrdn 値 (例えば ″Alice Weiss″)

比較AssemblyLine に受け渡される初期作業項目には、以下のプロパティーがあります。

dsml.operationcompareRequest

dsml.baseDN 値 (例えば ″CN=Johnson,OU=HR, DC=Example,DC=COM″)

dsml.compare_nameアサーション名 (例えば ″sn″)

dsml.compare_valueアサーション名の値 (例えば ″Johnson″)


$dn DN 値 (例えば ″CN=Johnson,OU=HR, DC=Example,DC=COM″)

compare_nameアサーション名 (例えば ″sn″)

compare_valueアサーション名の値 (例えば ″Johnson″)

compare_result比較操作の結果。この属性は AssemblyLine からのものです。値は true または false である必要があります。



HTTP ポートこの EventHandler が listen する TCP ポート。

認証コネクターオーセンティケーター・コネクター。コネクターを指定する場合は、そのコネクターはコネクター・ライブラリー内に存在し、ルックアップ用として構成されていなければなりません。この EventHandler は、このサービスにアクセスしようとするクライアント (例えば Web ブラウザー) に対して認証要求を発行します。クライアントがユーザー名とパスワードを提示すると、EventHandler は、オーセンティケーター・コネクターのルックアップ・メソッドを呼び出して、そのユーザー名属性とパスワード属性を提供します。したがって、オーセンティケーター・コネクターは、$username および$password を指定したリンク基準を使用して構成する必要があります。一般的なリンク基準は、以下のようになります。

username equals $usernamepassword equals $password

検索が失敗した場合は、EventHandler は要求を拒否し、認証要求をクライアントに送り返します。検索が成功した場合は、要求は許諾され、EventHandler の中のコードが処理されます。ユーザー名には、HTTP 属性またはプロパティー http.remote_user を検索することによりアクセスできます。オーセンティケーター・コネクターが戻す項目にアクセスするには、次のようなコードを使用して auth.entry プロパティーを検索します。

var auth = event.getProperty("auth.entry");var fullName = auth.getString("FullName");

プロパティーとしてのヘッダーこのチェック・ボックスにチェックマークを付けた場合は、イベント・オブジェクトの getProperty メソッドを使用して、すべての HTTP ヘッダーにアクセスできます。チェックマークを付けていない場合は、すべての HTTP

ヘッダーが属性 (例えば、getAttribute) として表示されます。

SSL の使用SSL を使用する場合は、このチェック・ボックスにチェックマークを付けます。

注: SSL を使用するには、鍵ストアの中に独自の証明書を生成する必要があります (keytool を使用)。クライアントは、この証明書をインポートする必要があります。

コメントユーザー自身が使用するためのコメント。

自動始動サービスこのチェック・ボックスにチェックマークを付けると、IBM Tivoli Directory


詳細ログこのチェック・ボックスにチェックマークを付けると、追加のログ・メッセージが生成されます。


チャンク転送コーディングこのチェック・ボックスにチェックマークを付けると、応答メッセージの本文が一連のチャンクとして転送されます。

追加のバイナリー属性名このフィールドを使用して、以下の事前定義 LDAP バイナリー属性に加えてユーザー定義のバイナリー属性を指定します。

v photo

v personalSignature

v audio

v jpegPhoto


v thumbnailPhoto

v thumbnailLogo

v userPassword

v userCertificate





v objectGUID

v objectSid

各属性には、バイナリー属性であるかどうかを判別するためにチェックマークを付けます。この属性がバイナリー属性である場合は、デコードされてから (またはエンコードされていない場合はエンコードされてから)

AssemblyLine に送信され、次に応答がクライアントに送信されます。

ネーミング・コンテキストAssemblyLine の一連の操作に関連するルート・ネーミング・コンテキスト。要求内の DN 値は、適切なルート・ネーミング・コンテキストの突き合わせに使用されます。

検索用 AssemblyLine選択したルート・ネーミング・コンテキストの検索操作に使用されるAssemblyLine の名前。AssemblyLine はサーバーの検索を行い、要求された値を戻します。LDAP サーバーの検索に LDAP コネクターを使用する場合は、「プロローグ内」 -> 「初期化前」フックで以下のようなコードを使用できます。

ldap_search.connector.setParam("ldapSearchFilter",work.getProperty("dsml.filter"));

ldap_search.connector.setParam("ldapReturnAttributes",work.getProperty("dsml.attributes"));

ldap_search.connector.setParam("ldapSearchBase",work.getProperty("dsml.base"));

ここで、ldap_search はユーザーが作成したコネクターです。コネクターはイテレーター・モードでなければなりません。


追加用 AssemblyLine選択したルート・ネーミング・コンテキストの追加操作に使用されるAssemblyLine の名前。AssemblyLine はサーバーに項目を追加します。LDAP サーバーへの追加に LDAP コネクターを使用する場合は、「データ・フロー」 -> 「追加専用」 -> 「追加前」フックで以下のようなコードを使用できます。

conn.setAttribute("$dn",work.getString("$dn"));

コネクターは AddOnly モードでなければなりません。

変更用 AssemblyLine選択したルート・ネーミング・コンテキストの変更操作に使用されるAssemblyLine の名前。AssemblyLine はサーバー内の項目を変更します。LDAP サーバー内の項目の変更に LDAP コネクターを使用する場合は、リンク基準を次のようにする必要があります。

$dn equals $$dn

出力マップに、変更または追加する属性を追加します。コネクターは更新モードでなければなりません。

削除用 AssemblyLine選択したルート・ネーミング・コンテキストの削除操作に使用されるAssemblyLine の名前。AssemblyLine はサーバーから項目を削除します。リンク基準を次のようにする必要があります。

$dn equals $$dn

コネクターは削除モードでなければなりません。

比較用 AssemblyLine選択したルート・ネーミング・コンテキストの比較操作に使用されるAssemblyLine の名前。AssemblyLine は、突き合わせる項目の値を比較します。比較に LDAP コネクターを使用する場合は、「プロローグ内」 ->「初期化前」フックで以下のようなコードを使用できます。

name = work.getString("compare_name") + "";value = work.getString("compare_value") + "";

また、「データ・フロー」 -> 「ルックアップの上書き」フックでは以下のようなコードを使用できます。

if(compare_conn.connector.compare($dn,name,value))conn.setAttribute ("compare_result", "true");

elseconn.setAttribute ("compare_result", "false");

コネクターはルックアップ・モードでなければなりません。

DN 変更用 AssemblyLine選択したルート・ネーミング・コンテキストの modifyDN 操作に使用される AssemblyLine の名前。AssemblyLine はサーバー内の項目の DN を変更します。LDAP サーバー内の項目の DN の変更に LDAP コネクターを使用する場合は、リンク基準を次のようにする必要があります。

$dn equals $$dn


出力マップに、変更する $dn を追加します。コネクターは更新モードでなければなりません。

Exchange 変更ログ EventHandlerExchange 変更ログ EventHandler は、Exchange Directory Service 内で発生した変更を検出し、それらの変更についてユーザーに通知します。この EventHandler は変更された Exchange オブジェクトを報告するので、他のデータ・ソースは Exchange

と同期することができます。

変更済みオブジェクトの検索には、LDAP プロトコルが使用されます。

この EventHandler は、Exchange 変更ログ・コネクターを内部で使用して、Exchange Directory Service から変更済みオブジェクトを取得します。変更済みオブジェクト検索は、「USN-Changed」メカニズムに基づいて行われます。

変更の検索順序、送達済み項目の構造、および削除済みオブジェクトの処理の詳細については、 66ページの『Exchange 変更ログ・コネクター』を参照してください。

注:

1. Exchange 変更ログ EventHandler は Exchange 5.5 の場合のみ使用できます。Exchange 2000 に接続しようとしている場合は、代わりに Active Directory 変更ログ EventHandler を使用してください。

2. Exchange Server に Exchange 5.5 Service Pack 4 をインストールしてあることが必要です。

動作この EventHandler は、始動後、Exchange Directory Service に接続し、すべての新しいディレクトリー変更 (この EventHandler がオフライン中に発生したもの) を検索します。次に、EventHandler は構成可能な期間の間スリープし、その後再びExchange に新たな変更をポーリングする、という動作をします。

EventHandler が稼動していないときに通知が失われることはありません。EventHandler は、始動のたびに、オフライン中に発生した変更を検索します。

Exchange 変更ログ EventHandler には、同期プロセス中のどの時点でも割り込むことができます。この EventHandler は同期プロセスの状態を IBM Tivoli Directory

Integrator のユーザー・プロパティー・ストアに保管するので (各項目の検索後)、次回に EventHandler を開始したときには、割り込まれた位置から正しく同期が続行されます。

Exchange がオフライン状態になると、EventHandler は停止せずに、成功または停止が要求されるまで再接続を試行します。

ユーザー・プロパティー・ストア内の USN 同期値へのアクセス任意の時間の同期状態は、4 つの USN 番号で表されます。

v START_USN

v END_USN






// Retrieve USN values from User Property Storevar usn = system.getPersistentObject("exchange_sync");var startUsn = usn.getString("START_USN");var endUsn = usn.getString("END_USN");var currentUsnCreated = usn.getString("CURRENT_USN_CREATED");var currentUsnChanged = usn.getString("CURRENT_USN_CHANGED");


"exchange_sync" は、ユーザー・プロパティー・ストアに既に保管されているパラメーターの名前です。この値は、永続パラメーター名パラメーターで指定します。上記の例では値を画面にダンプしていますが、他に希望するアクションを実行できます。例えば、値をファイルに保管して、このファイルをバックアップすることもできます。


// Store USN values in the User Property Storevar usn = system.newEntry();usn.setAttribute("START_USN", startUsn);usn.setAttribute("END_USN", endUsn);usn.setAttribute("CURRENT_USN_CREATED", currentUsnCreated);usn.setAttribute("CURRENT_USN_CHANGED", currentUsnChanged);system.setPersistentObject("exchange_sync", usn);

このコードでは、変数 startUsn、endUsn、currentUsnCreated、およびcurrentUsnChanged にストリングとして USN 番号が含まれると想定されています。この例では、"exchange_sync" パラメーターに USN 値が保管されるので、希望する時点から同期を続行するためには、EventHandler の永続パラメーター名パラメーターに "exchange_sync" を指定する必要があります。

ランタイム EventHandler の USN 同期値へのアクセスExchange 変更ログ EventHandler には、現在の USN 値にアクセスするために以下の共通メソッドがあります。


v START_USN

v END_USN




各属性の値のタイプは java.lang.Integer であり、対応する EventHandler

の USN 値を表します。

public void setUsnValues (Entry usnEntry);EventHandler の現在の USN 同期値を、usnEntry パラメーターに指定された値に設定します。usnEntry パラメーターの構造は、getUsnValues() により戻された項目の構造と同じにする必要があります。usnEntry 属性の値は、java.lang.Integer か、対応する数のストリング表現にする必要があります。





ログイン・ユーザー名サービスへの認証に使用する識別名。例えば、cn=administrator,ou=domain_name,o=organization_name。







SSL の使用Exchange Server との LDAP 通信に Secure Sockets Layer を使用するかどうかを指定します。

LDAP 検索ベース変更の有無を調べるためにポーリングされる指定された Exchange サブツリー。例えば、cn=recipients,ou=domain_name,o=organization_name。

永続パラメーター名IBM Tivoli Directory Integrator のユーザー・プロパティー・ストアに現在の


同期状態を保管するパラメーターの名前を指定します。この名前は、IBM


開始位置EOD または 0 を指定します。EOD は、EventHandler の開始後に発生した変更のみを報告することを意味します。0 は、完全同期の実行を意味します。つまり、Exchange Directory サービス内の使用可能なすべてのオブジェクトを報告します。このパラメーターを考慮するのは、永続パラメーター名パラメーターに指定されたパラメーターがユーザー・プロパティー・ストアに見つからない場合のみです。

″Is-Deleted″ 属性を可視Exchange Server が LDAP を介して Is-Deleted オブジェクト属性を公開するかどうかを指定します。

注: サーバーが Is-Deleted 属性を公開する場合は、″Is-Deleted″ 属性を可視が false に設定されていても EventHandler は正しく機能しますが、″Is-Deleted″ 属性を可視を true に設定することにより、EventHandler

の処理速度を速めることができます。サーバーが Is-Deleted 属性を公開しない場合に、″Is-Deleted″ 属性を可視が true に設定されているときは、EventHandler は変更済みオブジェクトと削除済みオブジェクトを区別できないため、削除をすべて変更操作として報告します。

スリープ間隔変更のための連続したポーリング間で、EventHandler がスリープする秒数を指定します。

詳細ログ詳細なデバッグ情報をログ・ファイルに書き込むかどうかを指定します。



HTTP EventHandlerHTTP EventHandler は、TCP EventHandler より簡単に HTTP 接続を取り扱う手段を提供する単純な Web サーバーです。 HTTP EventHandler は、HTTP パーサーを使用して自動的にクライアント要求を解析し、イベント・オブジェクトを作成します。さらに、認証コネクターを指定した場合は、この EventHandler は HTTP 基本認証をインプリメントします。

イベントを扱うとき、EventHandler は新規インスタンスを fork するので、プロローグおよびエピローグは、HTTP イベントが受信されるたびに開始されます。

この単純な Web サーバーの機能を利用するには、この EventHandler が要求への応答として戻す http.body および http.content-type 属性を設定する必要があります。また、http.* 属性を設定して、HTTP ヘッダーを追加することもできます。例えば、http.my-header の値を設定したとすれば、この EventHandler は、応答にmy-header: value を組み込みます。


http.body プロパティーは、次のいずれかに設定できます。

任意のストリング (java.lang.String)このストリングは、そのままの形で要求に含めて送られます。

任意の入力ストリーム (java.io.InputStream )この入力ストリームは、content-length HTTP ヘッダーを計算するために、メモリー内のバッファーに入れられます。入力ストリーム・データは、そのままの形で要求に含めて送られます。

Java ファイル・オブジェクト (java.io.File)ファイル・オブジェクトから取得したファイル・サイズに基づいて、content-length が生成されます。そして、ファイルの内容はそのままの形で要求に含めて送られます。

例次の例では、クライアントが要求するファイルが戻されます。

var base = event.getProperty("http.base");if ( base == "/" )base = "/index.html";

// Construct the full pathpath = "/home/httpd/documents" + base;

// Construct the Java file objectfile = new java.io.File ( path );

// Set the response propertyevent.setProperty ( "http.body", file );

構成HTTP ポート

この EventHandler が listen する TCP ポート。

認証コネクターオーセンティケーター・コネクター。コネクターを指定する場合は、そのコネクターはコネクター・ライブラリー内に存在し、ルックアップ用として構成されていなければなりません。この EventHandler は、このサービスにアクセスしようとするクライアント (例えば Web ブラウザー) に対して認証要求を発行します。クライアントがユーザー名またはパスワードを提示すると、EventHandler は、オーセンティケーター・コネクターのルックアップ・メソッドを呼び出して、そのユーザー名属性とパスワード属性を提供します。したがって、オーセンティケーター・コネクターは、$username および$password を指定したリンク基準を使用して構成する必要があります。一般的なリンク基準は、以下のようになります。

username equals $usernamepassword equals $password

検索が失敗した場合は、EventHandler は要求を拒否し、認証要求をクライアントに送り返します。検索が成功した場合は、要求は許諾され、EventHandler の中のコードが実行されます。ユーザー名には、HTTP 属性またはプロパティー http.remote_user を検索することによりアクセスできます。オーセンティケーター・コネクターが戻す項目にアクセスするには、次のようなコードを使用して auth.entry プロパティーを検索します。


var auth = event.getProperty("auth.entry");var fullName = auth.getString("FullName");

プロパティーとしてのヘッダーこのパラメーターにチェックマークを付けた場合は、イベント・オブジェクトの getProperty メソッドを使用して、すべての HTTP ヘッダーにアクセスできます。チェックマークを付けていない場合は、すべてのヘッダーがHTTP 属性 (例えば、getAttribute) として表示されます。

SSL の使用SSL を使用する場合は、このチェック・ボックスにチェックマークを付けます。

注: SSL を使用するには、鍵ストアの中に独自の証明書を生成する必要があります (keytool を使用)。クライアントは、この証明書をインポートする必要があります。





関連情報「IBM Tivoli Directory Integrator 5.2 ユーザーズ・ガイド」の『EventHandler』、および 153ページの『HTTP パーサー』を参照してください。

IBM Directory Server EventHandlerIBM Directory Server EventHandler は、LDAP 非送信請求イベント通知を使用して、LDAP ディレクトリー内の変更を検出します。 IBM Directory Server

EventHandler を使用するには、LDAP サーバーが LDAPv3 非送信請求通知イベントをサポートしていなければなりません。

この EventHandler は、始動後、LDAP サーバーに接続し、すべての新しいディレクトリー変更 (この EventHandler がオフライン中に発生したもの) を検索し、非送信請求イベント通知を受信するために登録します。 LDAP ディレクトリー内でイベントが発生すると、EventHandler は非送信請求通知イベントを受信し、次の変更ログ項目を検索します。この変更ログ項目には、イベント項目オブジェクトとしてアクセスできます。イベント項目オブジェクトには、以下の属性があります。

changenumber提供側が割り当てる変更番号。この整数は、新しい項目が追加されるたびに増加し、1 つのサーバー内では常に固有の値でなければなりません。

この属性は必須です。


targetdn追加、変更、または削除された項目の識別名 (DN)。modrdn 操作の場合は、targetdn は、変更前の項目の DN を示します。


changetype変更のタイプ (add、delete、modify、または modrdn).


changesディレクトリー・サーバーに対して行われた変更。これらの変更は LDIF

形式で、changetype が add または modify の場合に使用できます。

この属性はオプションです。

newrdn項目の新規 Relative Distinguish Name (RDN)。changeType が modrdn である場合、または changeType 属性の値に modrdn がない場合は、newrdn 属性に値は含まれません。


deleteoldrdn項目の旧 RDN を、項目の識別属性として保存するか、それとも削除するかを指示するフラグ。


newsuperiorこの属性 (存在する場合) は、既存項目の直属の上位になる項目の名前を示します。


changetime変更が行われた時刻。


modifiersname変更を行う DN。


IBM Directory Server EventHandler の重要な特長の 1 つは、この EventHandler が実行されていない間の通知は失われないということです。これは、このEventHandler が始動されるたびに、オフライン中に行われた変更が検索されるからです。

構成LDAP URL

LDAP URL (ldap://hostname:port)。

ログイン・ユーザー名サーバーへの認証に使用する識別名 (例えば、cn=root)。


注: この EventHandler は変更ログを読み取る必要があるので、この識別名は管理者特権を持っていなければなりません。


変更ログ検索ベース変更ログが保管される検索ベース。標準 DN は cn=changelog です。

検索ベース関連の通知を受け取りたいディレクトリー・ツリー・ブランチのベース。識別名を指定します。ディレクトリーによっては、ブランク・ストリングを指定することができます。その場合は、デフォルトにより、サーバーについて設定されている処置がとられます。ディレクトリー・サービスによっては、そのディレクトリー内の有効な識別名を指定しなければならないこともあります。

検索範囲関連の通知を受け取りたいイベントの範囲。サブツリー、レベル、および基礎のいずれかです。

変更番号ファイル名最後の変更番号が保管されるファイルの名前。ファイル形式は、読み取り可能なテキストです。このファイルは、イベント通知が発生するたびに更新されます。

初期変更番号ChangeNumber Filename パラメーターに指定したファイルが存在しない場合は、EventHandler は、InitialChangeNumber から始まる変更ログ項目を検索します。



v MD5-CRAM (CRAM-MD5 (RFC-2195) を使用する)

v SASL (SASL を使用する)



この属性を指定しない場合は、デフォルト (無名) が使用されます。ログイン・ユーザー名またはログイン・パスワード・パラメーターがブランクの場合は、無名が使用されます。

SSL の使用LDAP サーバーとの通信に SSL を使用するかどうかを指定します。





関連情報「IBM Tivoli Directory Integrator 5.2 管理者ガイド」の『EventHandler』、および126ページの『LDAP EventHandler』を参照してください。

JMX EventHandlerJava Management Extensions (JMX) EventHandler は、JMX イベント通知を処理します。この EventHandler は、始動時に、処理対象として構成されているイベントのための登録をします。通知が到着すると、この EventHandler はそれに対応するイベント項目オブジェクトを作成し、EventHandler プロローグ、アクション・マップ、およびエピローグという標準シーケンスに、そのオブジェクトを引き渡します。また、JMX EventHandler では通知タイプの動的追加および除去が可能です。

注: JMX EventHandler が機能するためには、内部 JMX マネージャーが実行されていることが必要です。この JMX マネージャーを始動するためには、コマンド行パラメーター -m を指定して IBM Tivoli Directory Integrator Server を始動する必要があります。

動作の説明JMX EventHandler は、始動時に、この EventHandler の構成内でユーザーが指定した通知タイプを登録します。これらの通知タイプは、現在この EventHandler が受信している通知タイプのリストを形成します (この EventHandler では、ランタイムにこのリストを変更できるので、さらに複雑な動作をインプリメントできます)。通知タイプは、通知タイプに関する JMX 標準に指定されているように、「任意数のドットで区切られたコンポーネントとして解釈される」ストリングで、「通知タイプの命名にはユーザー定義の任意の構造を使用できる」ものです (詳しくは JMX 仕様を参照。http://java.sun.com/products/JavaManagement/download.html)。

JMX EventHandler は、通知ブロードキャスターであるすべての登録済み MBean が含まれたリストから、すべての通知タイプについて登録をします (新規ブロードキャスター MBean のランタイム登録または登録抹消は、この EventHandler により行われます)。

JMX EventHandler が通知を受け取るのは、EventHandler のリスト内にその通知のタイプが存在するか、または、それより包括的な通知タイプが含まれている場合のみです (例えば、リストに mobj.AssemblyLine が含まれているとすれば、EventHandler は mobj.assemblyline.started イベントとmobj.assemblyline.finished イベントの両方を受け取ります)。

EventHandler が受け取った各通知は、それぞれ独立したスレッドの中で処理されます。EventHandler は、多数の通知を同時に受け取り、それらを並行処理することができます。

EventHandler の使用イベント項目オブジェクトには、以下の属性があります。

event.originatorこのイベントを処理している JMX EventHandler インスタンス。


event.rawNotificationJMX EventHandler が受け取った、ロー JMX 通知インスタンス(javax.management.Notification)。この通知をブロードキャストするコンポーネントが javax.management.Notification を拡張し、このサブクラスに何らかの追加データを含めた場合は、このプロパティーを使用してその追加情報を検索できます。

event.typeイベント通知のタイプ・ストリング (java.lang.String)。

event.message通知のメッセージ (java.lang.String)。

event.userDataJMX 通知ユーザー・データ (java.lang.Object)。

event.sequenceNumber通知ディスケット番号 (java.lang.Long)。

event.sourceこの通知が最初に発生した MBean オブジェクト名(javax.management.ObjectName)。

event.timestampミリ秒単位での通知のタイム・スタンプ (java.lang.Long)。

event.mbean.objectName登録または登録抹消された MBean のオブジェクト名(javax.management.ObjectName)。このプロパティーが使用できるのは、event.type が JMX.mbean.registered または JMX.mbean.unregistered の場合だけです。

event.mbean.nameMBean オブジェクト名のストリング表現 (java.lang.String)。このプロパティーが使用できるのは、event.type が JMX.mbean.registered またはJMX.mbean.unregistered の場合だけです。

IBM Tivoli Directory Integrator の通知タイプIBM Tivoli Directory Integrator 自体が発行する通知のタイプには、以下のものがあります。

mobj.assemblyline.startedAssemblyLine が開始されたことを示します。 AssemblyLine ID は、java.lang.String タイプのオブジェクトとして event.userData に保管されます。

mobj.assemblyline.finishedAssemblyLine が終了したことを示します。 AssemblyLine ID は、java.lang.String タイプのオブジェクトとして event.userData に保管されます。

mobj.eventhandler.startedEventHandler が開始されたことを示します。 EventHandler ID は、java.lang.String タイプのオブジェクトとして event.userData に保管されます。


mobj.eventhandler.finishedEventHandler が終了したことを示します。 EventHandler ID は、java.lang.String タイプのオブジェクトとして event.userData に保管されます。

mobj.server.reloadedIBM Tivoli Directory Integrator サーバーが、現行の構成を再ロードしたか、新規の構成をロードしたことを示します。構成ファイルのパスは、java.lang.String タイプのオブジェクトとして event.userData に保管されます。

mobj.server.shutdownIBM Tivoli Directory Integrator サーバーがシャットダウンしようとしていることを示します。IBM Tivoli Directory Integrator サーバー ID は、java.lang.String タイプのオブジェクトとして event.userData に保管されます。

JMX システムの通知タイプJMX エンジン (JMX MBeanServer) がブロードキャストする特殊な通知タイプが 2

つあります。

JMX.mbean.registeredMBean が登録されたことを示します。

JMX.mbean.unregisteredMBean が登録抹消されたことを示します。

EventHandler が上記のいずれかのイベントを受け取ると、event.rawNotification プロパティーに javax.management.MBeanServerNotification タイプのオブジェクトが入ります。 getMBeanName() メソッドを使用すると、javax.management.ObjectName タイプのオブジェクトを戻すことができます。このオブジェクトは、登録または登録抹消された MBean の名前を表します。

構成通知タイプのリスト

EventHandler が listen する通知タイプのリスト。通知タイプは、以下のいずれかの通知タイプ区切り文字で区切る必要があります。

v タブ

v 改行

v 復帰

v スペース

v コンマ

v セミコロン

ここに通知タイプを指定すると、EventHandler は、指定されたタイプと同じか、より限定されたタイプのすべての通知を listen します。例えば、mobj.AssemblyLine を指定すると、EventHandler は mobj.AssemblyLineで始まるタイプのすべての通知を listen します


(mobj.assemblyline.started、mobj.assemblyline.finished など)。リストが空の場合は、EventHandler はすべてのタイプの通知を listen します。

注: 通知タイプには、大文字小文字の区別があります。

コメント任意のコメントを入力します。




通知タイプの動的追加/除去ランタイムに以下のメソッドを使用して、追加イベントの受信の開始、または一部のイベントの受信の停止を、JMX EventHandler に指示することができます。

void addNotificationType(String notificationType)指定した通知タイプを、EventHandler の通知タイプ・リストに追加します。通知タイプに空ストリングを指定した場合は、すべての通知タイプが登録されます。

注: このメソッドは、指定した通知タイプを EventHandler のリストに追加するだけで、通知タイプ階層内でそれより上位にある通知タイプがリストに含まれているかどうかはチェックしません。

void removeNotificationType(String notificationType)指定した通知タイプを、EventHandler の通知タイプ・リストから除去します。指定した通知タイプが EventHandler のリスト内に存在しない場合は、何も除去されません。すでにすべての通知タイプの登録が行われている場合は、空ストリングを指定してこのメソッドを呼び出して、この動作をキャンセルしてください。

注: 特定の通知タイプを指定してこのメソッドを呼び出した場合、その通知タイプは EventHandler のリストから除去されますが、通知タイプ階層内でそれより上位にある通知タイプがリストに含まれている場合は、ここで除去したタイプの通知が以後も受信されます。

String[] getNotificationTypes()EventHandler が現在登録されている通知タイプのリストを表すストリングの配列を戻します。

これらの JMX EventHandler のメソッドは、スクリプトからも Java コードからも呼び出すことができます。また、これらのメソッドのどれも、JMX EventHandler の内部のスクリプトから呼び出すことができます。以下の例に示すスクリプトは、AssemblyLine の開始を知らせる通知の受信を停止し、AssemblyLine の終了を知らせる通知の受信を開始するよう、EventHandler に指示します (このスクリプトは、EventHandler のアクション・マップ内に配置されます)。


var eh = event.getProperty("event.originator");eh.removeNotificationType("mobj.assemblyline.started");eh.addNotificationType("mobj.assemblyline.finished");

注: これらのメソッドは、EventHandler のリストへの通知タイプの追加およびリストからの通知タイプの除去を行います。したがって、EventHandler のリスト内にすでに存在する通知タイプより限定度の高い通知タイプを追加すると、新しい通知を受信できなくなります。ただし、後で包括度の高い通知タイプを除去したとしても、限定度の高い通知タイプは、依然として受信されることになります。例えば、次のようにします。

var eh = event.getProperty("event.originator");eh.addNotificationType("mobj.AssemblyLine");

このスクリプト・コードの実行後は、EventHandler は mobj.AssemblyLine で始まるすべての通知タイプを受け取ります。

eh.addNotificationType("mobj.assemblyline.started");

このスクリプト・コードを実行しても、EventHandler が受け取る通知タイプが増えることはありません。ただし、次のスクリプト・コード行を実行した場合は、EventHandler は mobj.assemblyline.started 通知を依然として受け取ることになります。

eh.removeNotificationType("mobj.AssemblyLine");

これは、最後のメソッド呼び出しにより、EventHandler の通知タイプ・リストからmobj.AssemblyLine は除去されますが、mobj.assemblyline.started はまだ EventHandler

リスト内に残っているからです。

LDAP EventHandlerこの EventHandler は、LDAP イベント通知メカニズムを使用して、LDAP ディレクトリー内の変更を検出します。この EventHandler を使用するには、LDAP サーバーが持続検索をサポートしていることが必要です。この EventHandler によりテストされた LDAP サーバーは、Netscape/iPlanet ディレクトリー・サーバーだけですが(iPlanet については、51を参照)、他の LDAP サーバーも正常に機能します。

注: LDAP データベース内の変更検出を、持続検索メカニズムを使用した LDAP データベースによるイベントの通知に依存せずに、変更ログの読み取り (適切な変更ログ・コネクターを使用) に基づいて行うことができれば、ソリューションはより堅固になります。持続検索メカニズムは非常に一時的なものであり、変更を確認できるのは、変更が発生したときにユーザーが実際に listen している場合のみです。接続がダウンすると、変更を確認できません。その一方で、変更ログは大容量記憶装置に支えられているので、正確なシステム変更番号を指定すれば、最後に停止した時点の処理を常に検出できます。

この EventHandler は、始動時に LDAP サーバーに接続し、イベント通知の選択基準を指定します。この EventHandler が戻すすべての DN は、指定した検索ベースに関連しています。柔軟性の高い方法で完全 DN を構成するには、例えば、カスタム・スクリプトの中で次のようなコードを使用して、新しい DN に検索ベースを付加することができます。


event.setProperty("ldap.newdn", event.getProperty("ldap.newdn") +"," + task.getParam("ldapSearchBase"));

LDAP ディレクトリー内にイベントが発生すると、EventHandler は、ldap.operation プロパティーを次のいずれかの値に設定します。

objAdded新規項目がディレクトリーに追加されたことを示します。

objRenamed既存項目が名前変更されたことを示します。

objModified既存項目の属性が変更されたことを示します。

objRemoved既存項目が除去されたことを示します。

handleErrorエラーが見つかったことを示します。

この EventHandler は、ldap.operation の値に応じて以下のプロパティーを設定します。

オブジェクト追加 (_objAdded)ldap.newdn

名前変更操作の場合の新しい DN。

ldap.newentry変更が適用された新規項目。

オブジェクト名前変更 (_objRenamed)ldap.dn

旧 DN。

ldap.newdn新規 DN。

オブジェクト変更 (_objModified)ldap.dn

変更操作前の DN。

ldap.entry変更操作の前の LDAP 項目の内容。この機能が適用されるのは、まずオブジェクトを削除してから、変更後の属性を使用してそのオブジェクトを再作成するという方法で、変更操作が行われる LDAP データベースのみです。

ldap.newdn変更操作後の DN。

ldap.newentry変更操作後の LDAP 項目の内容


オブジェクト除去 (_objRemoved)ldap.dn

除去操作前の DN

ldap.entry除去操作の前の LDAP 項目の内容

ldap.entry および ldap.newentry プロパティーは項目クラスのインスタンスなので、次の例に示すように、AssemblyLine 内で conn および作業オブジェクトにアクセスするのと同じ方法で、これらのプロパティーにもアクセスできます。

var old = event.getProperty ("ldap.entry");task.logmsg ("Old common name = " + old.getString("cn") );

注: LDAP EventHandler の重要な性質の 1 つは、この EventHandler が実行されていない間の重要な通知を失うおそれがあるという点です。この EventHandler を使用するのが最も適切なのは、情報を失うおそれがあってもディレクトリー内の変更をトラップする場合です。

エラー検出 (_handleError)ldap.error

EventHandler がスローした Java 例外。

注: iPlanet Directory 5.0 では、変更ログがプロプラエタリー形式に変更されています。以下の URL を参照してください。

http://docs.iplanet.com/docs/manuals/directory/51/html/ag/replicat_new.htm#1)

変更ログにアクセスするには、Retro Change Log Plug-in をインストールする必要があります。以下に示すのは、iPlanet の資料の中の変更ログに関する説明からの抜粋です。

「iPlanet Directory Server 5.0 では、変更ログの形式が変更されました。旧バージョンの Directory Server では、LDAP を介して変更ログにアクセスできました。しかし、現在では、これはサーバーによる内部使用に限定されています。変更ログの読み取りが必要なアプリケーションがある場合は、後方互換性を維持するために Retro Change Log Plug-in を使用する必要があります。詳細については、Retro Change Log Plug-In を参照してください。」








検索範囲このパラメーターは、コネクターがイテレーター・モードの場合のみ使用されます。指定できる値は、以下のとおりです。




認証メソッドLDAP 認証のタイプ。これは、次のいずれかです。

v 単純 (ldapUsername/ldapPassword を使用。ユーザー名およびパスワードが指定されない場合は、「無名」と見なされます。)

v MD5-CRAM

v SASL

v 無名 (ユーザー名およびパスワードが指定されている場合は、「単純」と見なされます)。

SSL の使用これにチェックマークを付けると、LDAP サーバーとの通信に Secure

Sockets Layer が使用されます。

コネクター・フラグ特定の動作を使用可能にするフラグ。

deleteEmptyStrings: このフラグを使用すると、コネクターは、ディレクトリーを更新する前に、値として空ストリングのみを含んでいる属性を削除します。LDAP バージョン 3 サーバーを使用している場合は、属性の値を空ストリングにすることはできないので、このフラグを使用してください。





関連情報「IBM Tivoli Directory Integrator 5.2 ユーザーズ・ガイド」の『EventHandler』、および 58ページの『IBM ディレクトリー変更ログ・コネクター』を参照してください。

LDAP サーバー EventHandlerLDAP サーバー EventHandler は、LDAP クライアントから LDAP 接続要求を受け入れます。LDAP サーバー EventHandler は、自身のコピーを生成して、この接続がLDAP クライアントによってクローズされるまで接続を管理します。 LDAP サーバー EventHandler が終了するのは、TCP 接続がクローズするときだけです。接続上で受け取られた各 LDAP メッセージは、1 サイクルの LDAP サーバーEventHandler 論理を駆動します。メイン・スレッドは、他の LDAP クライアントからの同様の LDAP 要求の listen に戻ります。メッセージ内の LDAP 操作は、LDAP サーバー EventHandler の項目オブジェクトに解析されます。LDAP サーバーEventHandler コードが実行されると、戻りメッセージが作成され、クライアントに送信されます。 LDAP 検索コマンドの場合は、ユーザーは add メソッドを呼び出して、クライアントに送信するデータ構造を構築することになります。LDAP サーバー EventHandler は、既存の接続上で次の LDAP コマンドの listen に戻ります。

LDAP 操作の値は、LDAP サーバー EventHandler 作業項目内の LDAP.operation属性に指定します。有効な値は、SEARCH、BIND、UNBIND、COMPARE、ADD、DELETE、MODIFY、および MODIFYRDN です。LDAP メッセージは、指定された LDAP 操作に対して多数の属性を提供します。スクリプト記述を容易にするため、パーサーは LDAP メッセージを LDAP サーバー EventHandler の作業オブジェクトにコピーします。

スクリプトLDAP サーバー EventHandler は、LDAP メッセージの望ましい結果を決定するために作業を行う必要があります。コードを LDAP サーバー EventHandler 内に置くことも、LDAP サーバー EventHandler が AssemblyLine を開始して作業を行うこともできます。基本的な LDAP 操作 (SEARCH、BIND、UNBIND、COMPARE、ADD、DELETE、MODIFY、および MODIFYRDN) は、LDAP サーバーEventHandler スクリプト環境で値として指定して、スクリプト記述を容易にします。例えば、LDAP.operation を BIND にします。ユーザー・コードは、LDAP サーバー EventHandler 内で add ( entry ) メソッドを呼び出して、検索結果項目をクライアントに送信します。項目は、有効な LDAP 属性名に特殊属性 $dn (項目の識別名) を付けた形式にする必要があります。

LDAP メッセージ戻り値のリターンLDAP サーバー EventHandler 内のユーザー提供コードが各要求に応答するようにするには、ldap.status、ldap.matcheddn、および ldap.errormessage 項目属性を設定します。ldap.matcheddn と ldap.errormessage はオプションです。

LDAP サーバー EventHandler 実行サイクルの最後に、LDAP サーバーEventHandler は作業項目の一部の属性をフォーマット設定して戻します。属性は次のとおりです。


v LDAP.status

v LDAP.errormessage

注: ストリングのみがサポートされます。resultCode は、デフォルトで 0 (成功) に設定されます。成功以外を示す resultCode は、ユーザーが個々に設定する必要があります。

エラー処理受け取ったメッセージが LDAP v3 形式に準拠しない場合は、LDAP サーバーEventHandler は接続を終了し、エラーを記録します。

注: LDAP サーバー EventHandler は、着信属性に対していかなる検証も行いません。したがって、すべての操作またはパラメーター値が受け入れられます。


LDAP ポートこの EventHandler が listen する TCP ポート。

文字エンコード文字エンコード方式を指定します。デフォルトは UTF-8 です。

バイナリー属性バイナリーとして扱われる属性のリスト (バイナリー属性は、ストリングではなくバイト配列として戻されます)。1 行に 1 つずつ属性を入力してください。

注: 1 つの AssemblyLine が持つことのできるバイナリー属性のリストは 1

つだけです。1 つの AssemblyLine 内に複数の LDAP コネクターがあるときに、デフォルトのリストを変更する必要がある場合は、最後のコネクターで、その AssemblyLine 内のすべての LDAP コネクター用のバイナリー属性のリストを定義してください。





メールボックス EventHandlerこの EventHandler は、メールボックス内の変更を listen します。このハンドラーは、プロトコルに応じて、メールボックスに再接続する方法で定期的にメールボックスをポーリングするか (pop3)、または接続上で定期的にアイドル・メッセージを発行します (imap4)。



サーバー名メールボックスのホストとして稼働するメール・サーバー。

プロトコルPOP3 または IMAP を指定します。

ログイン・ユーザー名ユーザー名。

ログイン・パスワードログイン・ユーザー名のパスワード。

メール・フォルダーモニターするメール・フォルダー。 POP3 の場合は、指定できるのはINBOX のみです。 IMAP4 サーバーの場合は、これはサーバーで使用できるどのフォルダーでもかまいません。

ポーリング間隔 (秒単位)ポーリングの間隔を示す秒数。POP3 の場合は、この秒数ごとに新規の接続が発生するという点に注意してください。






mailbox.sessionJava セッション・オブジェクト (javax.mail.Session)。

mailbox.storeメッセージ・ストア・オブジェクト (javax.mail.Store)。

mailbox.folderフォルダー・オブジェクト (javax.mail.Folder)。

mailbox.messageメッセージ・オブジェクト (javax.mail.Message)。

mailbox.operationmailbox.message に関連した操作。 pop3 接続の場合は、既存項目のみが報告されます。 imap 接続の場合は、このプロパティーの値は new またはdeleted になります。

mail.subjectmail.message からのサブジェクト・ヘッダー。


mail.frommail.message からの送信者ヘッダー。

mail.tomail.message 内の最初の宛先。

例ご使用の IBM Tivoli Directory Integrator システムのroot_directory/examples/event_handler_mailbox ディレクトリーにあります。

関連情報「IBM Tivoli Directory Integrator 5.2 ユーザーズ・ガイド」の『EventHandler』を参照してください。

SNMP EventHandlerSNMP は、リモート・システム内のパブリッシュ済み属性を照会および設定する際に使用する、標準ワイヤー・レベルのプロトコルです。通常、SNMP はモニター・コンソールにより使用され、広範な SNMP 準拠システムから状況情報を構成および取得します。

SNMP EventHandler は特定のポートで UDP パッケージを受け取り、適切にフォーマット設定された応答を発信元に戻します。デフォルトで、インプリメンテーションは非ブロッキングに設定されます。これは、SNMP EventHandler が自身のコピーを作成して作業を行う一方で、メイン・スレッドが新たなパケットの listen に戻ることを意味します (メイン・スレッドをブロッキングに設定することもできます)。

コミュニティー・ストリングを設定すると、その特定のストリングを含まない着信SNMP 要求を SNMP EventHandler が無視するようにできます。コミュニティー・ストリングをブランクのままにすると、すべての SNMP パケットが SNMP

EventHandler に受け入れられます。

SNMP 操作の値は、SNMP EventHandler 作業項目内の SNMP.operation 属性に指定します。有効な値は、GET、GETNEXT、SET、および TRAP です。単一のSNMP メッセージで、複数の OID での操作を要求できます (OID とは、ターゲット・システム内で読み取りまたは変更が行われる特定の変数または属性を示す、MIB 構造へのアドレスです)。GET には OID のリストを含めることができ、SET

にはターゲット・システム内のそれらの変数に対して設定される対応する値も含めることができます。ただし、多くの場合、SNMP 配置で使用するのは SNMP メッセージごとに 1 つの OID のみです。

スクリプト記述を容易にするため、パーサーは OID テーブルを SNMP

EventHandler の作業オブジェクト内の 2 つの多値属性にコピーします。一つは、希望する OID が含まれる SNMP.OID、もう一つは対応する値が含まれるSNMP.OIDvalue です。OIDValue には、java.lang.Integer 値またはjava.lang.String 値が含まれます。解析が終わると、SNMP EventHandler の作業オブジェクトには以下が含まれるようになります。

v コミュニティー・ストリング (SNMP.community 内)

v 発信 IP アドレス (SNMP.remoteIP 内)


v SNMP シーケンス番号 (SNMP.requestId 内)

v 属性 SNMP.errorcode (値 2 に設定) および SNMP.errorindex (値 0 に設定)

TRAP メッセージには、以下の追加の値が含まれます。

v SNMP.enterprise: オブジェクト生成トラップ用の OID

v SNMP.agentAddress: オブジェクト生成トラップのアドレス

v SNMP.specificTrap、SNMP.genericTrap: specificTrap = 6 の場合に値を持つ

v SNMP.timeTicks: オブジェクト生成トラップが最後に初期化されてからの時間

希望するアクションのスクリプト記述SNMP EventHandler は、SNMP メッセージの望ましい結果を決定するために作業を行う必要があります。コードを SNMP EventHandler 内に置くことも、SNMP

EventHandler が AssemblyLine を開始して作業を行うこともできます。

基本的な SNMP 操作 (GET、GETNEXT、SET、および TRAP) は、SNMP

EventHandler スクリプト記述環境で値として指定して、スクリプト記述を容易にします。例えば、SNMP.operation を GET にします。SNMP.OID およびSNMP.OIDvalue 属性を変更すると、戻りメッセージに含まれる内容を作成できます。戻りエラー・コードを操作するには、SNMP EventHandler の SNMP.errorcode属性と SNMP.errorindex (エラーが含まれる OID テーブル内の項目) の値を設定します。

エラー処理SNMP では、GET-RESPOND 戻りメッセージの一部である戻りエラー・コードがサポートされます。SNMP 形式に準拠しないメッセージは SNMP EventHandler で処理されませんが、制御はエピローグに与えられます。ユーザーは、エピローグにカスタマイズしたコードを追加できます。

v デフォルトのエラー・コードは 2 です。これは、作業が何も行われなかったことを示します。成功を示すエラー・コード 0 は、ユーザーが個々に設定する必要があります。

v ユーザーが設定できるのは、標準 SNMP 準拠のエラー・コードのみです。値がサポートされる範囲外の場合は、SNMP EventHandler はエラー・コードを値 5(他のエラーと同様に解釈) に上書きしてから、発信元にメッセージを戻します。

SNMP パケット戻り値のリターンSNMP EventHandler は、作業項目の一部の属性をフォーマット設定して戻します。属性は次のとおりです。

v SNMP.OID

v SNMP.OIDValue

注: ストリング、整数、および NULL のみがサポートされます。java.lang.String は OctetString にマップされ、java.lang.Integer は整数にマップされます。

v SNMP.errorcode


注: デフォルト値は 2 です。ユーザーが SNMP.errorcode を 0 から 5 以外の値に設定すると、SNMP.errorcode は 5 に設定されて戻されます。

v SNMP.errorindex

注: エラーを引き起こした OID 値の OID テーブル内の (ゼロ・ベースの) 索引に設定します。

注: SNMP プロトコルに従い、報告されるエラーは 1 つのみです。複数のエラーの場合は、SNMP.errorindex はエラーを示す最も低い索引でなければなりません。ユーザーは、この値を正確に設定する必要があります。


UDP ポートSNMP のデフォルト UDP ポートは 161 ですが、構成可能でなければなりません。通常、TRAP はポート 162 で受信します。

コミュニティーの検査設定すると、このコミュニティー・ストリングに一致しないメッセージがすべて廃棄されます。ブランクにすると、すべてのコミュニティー・ストリングが有効になります。

マルチスレッドチェックマークを付けると、各イベントごとに新規のスレッドが作成されます。




TCP ポート EventHandlerこの EventHandler は、指定されたポート上で着信 TCP 接続を待ち、着信要求を取り扱うための新規のスレッドを作成します。新規のスレッドが開始されると、元のEventHandler は listen モードに戻ります。その新規作成のスレッドが完了すると、そのスレッドは停止し、TCP 接続はクローズされます。

この EventHandler は fork するので、プロローグおよびエピローグは、HTTP イベントが受信されるたびに開始されます。

構成TCP ポート

着信接続を listen する TCP ポート。







event.inputstreamTCP ソケット入力ストリーム。

event.outputstreamTCP ソケット出力ストリーム。

tcp.remoteIPリモート IP アドレス (ドット表記)。

tcp.remotePortリモート TCP ポート番号。

tcp.remoteHostリモート・ホスト名。

tcp.localIPローカル IP アドレス (ドット表記)。

tcp.localPortローカル TCP ポート番号。

tcp.localHostローカル・ホスト名。

tcp.socketTCP ソケット・オブジェクト (java.net.Socket)。

例ご使用の IBM Tivoli Directory Integrator システムのroot_directory/examples/event_handler_tcp ディレクトリーにあります。

関連情報「IBM Tivoli Directory Integrator 5.2 ユーザーズ・ガイド」の『EventHandler』を参照してください。

汎用スレッド (プリミティブ EventHandler)汎用スレッドは始動時に開始され、スクリプトが実行されている限り実行され続けます。スクリプトは、task.sleep(milliseconds) を呼び出して定期的に作業を行うことができます。

構成このポート・リスナーは、以下のパラメーターを必要とします。




スクリプト言語スクリプト言語 (javascript など)。

詳細ログ詳細なログ情報をログ・ファイルに書き込むかどうかを指定します。

スクリプト実行するスクリプト。

関連情報131ページの『メールボックス EventHandler』

タイマー EventHandler (プリミティブ EventHandler)タイマーは、指定された時間が経過するまで待ってから、スクリプトまたはAssemblyLine を開始します。スクリプトは、管理者またはユーザーが提供する必要があります。




スクリプト言語スクリプトのスクリプト・エンジン (例えば、javascript、vbscript)。

スケジュールこのパラメーターには、この EventHandler をいつ実行するかを指定します。形式は次のとおりです。

<月> <日> <曜日> <時> <分>

各フィールドの値は、以下のような数値です。

v 月 = 0 から 11 (1 月から 12 月)

v 日 = 1 から 31

v 曜日 = 1 から 7 (日曜日から土曜日)

v 時 = 0 から 23

v 分 = 0 から 59

フィールド間は空白文字で区切ります。不特定の値を指定するには ″*″ を入力してください。どのフィールドでも、複数の値をコンマで区切って指定できますが、これらの値は昇順に並べる必要があります。

現在時刻が schedule のすべてのフィールドの値と一致した時点で、指定した AssemblyLine が実行されます。例:

v * * 5 22 0: 毎木曜日の 22:00 時に実行されます。


v * 3 * 22 0: 毎月 3 日の 22:00 時に実行されます。

注:

1. 「月」フィールドの値は 0 ～ 11 ですが、「日」および「曜日」の値は1 から始まります。

2. 「日」と「曜日」の両方を指定したことが原因で、混乱が生じることがしばしばあります。その場合、この 2 つの属性が一致しなければならないため、このイベントが発生しないことがあります。

AssemblyLine の実行開始する AssemblyLine。


スクリプト指定すると、スクリプトには ontimer という関数が含まれます。スケジュール・パラメーターに指定した時刻に達するとこの関数が呼び出され、AssemblyLine が開始されます。 EventHandler のスケジュールは、タイマー・オブジェクトを使用して変更できます。ontimer 関数からスケジュール・パラメーターを設定することにより、タイマーを再構成することができます。例:

function ontimer(){timer.setParam ("schedule", "* * * 22 0");}

例ご使用の IBM Tivoli Directory Integrator システムのroot_directory/examples/event_handler_timer ディレクトリーにあります。

Web サービス EventHandlerWeb サービス EventHandler は、IBM Tivoli Directory Integrator の AssemblyLine

を Web サービスとして公開します。この EventHandler から Web サービスとして公開されたすべての AssemblyLine は、Web サービス記述言語 (WSDL) 文書内で記述されます。この EventHandler はこの文書を読み、現行の IBM Tivoli Directory

Integrator 構成の中でこれらの AssemblyLine を検索します。

現在サポートされているオブジェクトおよびトランスポート・プロトコルは、SOAP

および HTTP です。したがって、インターネット上のどの SOAP または HTTP クライアントでも、IBM Tivoli Directory Integrator の AssemblyLine を起動し、その結果を取得することができます。

Web サービス EventHandler は、「要求/応答」タイプの操作のみをサポートしています。

AssemblyLine と WSDL のマッピングWSDL とその用語について不明な点がある場合は、http://www.w3.org/TR/wsdl に掲載されている WSDL の仕様を参照してください。


v WSDL 文書はいくつかの操作を発行します。

v 1 つの WSDL 操作は 1 つの IBM Tivoli Directory Integrator AssemblyLine を記述します。操作の名前は AssemblyLine の名前と一致していなければなりません。

v WSDL 操作はどれも「要求/応答」タイプでなければなりません。入力メッセージは、AssemblyLine の始動時に AssemblyLine に渡される初期項目の構造を記述します。出力メッセージは、AssemblyLine が生成する結果項目の構造を記述します。

v 1 つの WSDL メッセージは、1 つの項目の構造およびその属性を記述します。

注: Web サービスの EventHandler およびコネクターを操作するときに、属性名の最初の 1 文字には、特殊文字 ([0 から 9] [- ’ ( ) + , . / = ? ; ! * # @$ %] など) を使用することはできません。また、特殊文字 ([ ’ ( ) + , / =?; ! * # @ $ % ] など) を属性名の中で使用することもできません。これは、Web サービスは SOAP (つまり XML) を基礎として作成されているためです。XML は、タグ内の文字として $ を受け入れません。

v 1 つの WSDL メッセージ部分は、名前とタイプを指定する 1 つの属性を記述します。メッセージ部分の名前は、属性の名前と一致していなければなりません。

SOAP 操作のスタイルWeb サービス EventHandler が生成する WSDL ファイル内の SOAP 操作は、すべて RPC スタイルを使用します。

サポートされるスキーマ/ネーム・スペースのタイプWeb サービス EventHandler は、http://www.w3.org/2001/XMLSchema (またはhttp://www.w3.org/1999/XMLSchema) で定義されているタイプのサブセットをサポートしています。 Web サービス EventHandler は、その他のスキーマはサポートしていません。

WSDL メッセージ・パート・タイプと Java タイプのマッピングこの EventHandler がサポートするデータ・タイプは、標準の XML スキーマ組み込みデータ・タイプのサブセットです。各タイプには、xsd の接頭部が付いています。xsd 接頭部は、標準 XML スキーマ URL、「http://www.w3.org/2001/XMLSchema」に関連付けられます。XML スキーマ・データ・タイプの詳細説明については、http://www.w3.org/TR/xmlschema-2/ を参照してください。現在、Web サービス EventHandler は、以下の XML スキーマ組み込み(xsd) データ・タイプをサポートしています。

xsd:stringjava.lang.String

xsd:booleanjava.lang.Boolean

xsd:bytejava.lang.Byte

xsd:shortjava.lang.Short


xsd:intjava.lang.Integer

xsd:longjava.lang.Long

xsd:numberjava.lang.Long

xsd:integerjava.lang.Long

xsd:doublejava.lang.Double

xsd:decimaljava.lang.Double

xsd:floatjava.lang.Float

xsd:dateTimejava.util.Date

xsd:hexBinarybyte[]

xsd:base64Binarybyte[]

注:

1. XSD 仕様に従い、dateTime 直列ストリングは以下の形式に準拠しなければなりません。

yyyy-MM-ddTHH:mm:ss

ここで、

v yyyy は 4 桁の西暦年を指定します。

v MM は 2 桁の月を指定します。

v dd は 2 桁の日を指定します。

v T は分離文字を指定します。

v HH は 2 桁の時間を指定します。

v mm は 2 桁の分を指定します。

v ss は 2 桁の秒を指定します。

例えば、1990-10-10T18:10:00 のようになります。

2. XSD dateTime タイプは、日付のみを指定したストリングは受け入れませんが(例えば 1990-10-10 は有効な xsd:dateTime ストリングではありません)、Web サービス EventHandler はこの種の日付ストリングを受け入れ、時刻を 00:00:00 に設定して java.util.Date オブジェクトを作成します。

3. Web サービス EventHandler は、現在、単純データ・タイプのみをサポートしています。複合データ・タイプは現時点ではサポートされていません。

4. 以下の例は、IBM Tivoli Directory Integrator のスクリプトでバイト配列を作成する方法を示しています。


var byteArray = java.lang.reflect.Array.newInstance(java.lang.Byte.TYPE, length_of_the_array);

EventHandler の使用1. Web サービス EventHandler により Web サービスとして公開する AssemblyLine

を作成します。AssemblyLine の「呼び出し/戻り」タブの「初期作業項目」属性および「結果項目」属性を確実に指定します。初期項目および結果項目は、AssemblyLine によって示されている Web サービスの入出力を実際に定義します。「呼び出し/戻り」タブで新規属性を追加するには、必ず、「構文」列に属性の Java クラス・タイプを入力してください (例えばjava.lang.String、java.lang.Integer など)。「構文」列の値は、WSDL 生成ツールが WSDL ファイルを作成するときに使用されます。

2. AssemblyLine とその入力項目および結果項目の属性タイプを識別した後で、AssemblyLine を記述する WSDL 文書を作成する必要があります。そのためには、この EventHandler の「WSDL」タブから、WSDL 生成のためのユーティリティーを使用します ( 144ページの『WSDL の自動生成』を参照してください)。

3. 作成した WSDL ファイルへの URL と、Web サービス EventHandler がクライアント要求を受け入れる TCP ポートを指定して、Web サービス EventHandler

を構成します。

4. Web サービス EventHandler を実行します。EventHandler はクライアント(SOAP/HTTP) 要求の受け入れを開始します。Web サービス EventHandler が開始するアクションのフローについては、次の『Web サービス EventHandler の処理シーケンス』のセクションを参照してください。

5. これで、どの SOAP クライアント (Web サービス・コネクターも含む) からでも、Web サービス EventHandler の Web サービスにアクセスできるようになりました。

Web サービス EventHandler の処理シーケンス

注: Web サービス EventHandler は、他の EventHandler と異なり、アクション・マップを持っていません。

Web サービス EventHandler は、2 つのタイプのクライアント要求を処理できます。それは、SOAP 要求と、ホスティングされている WSDL ファイル ( 144ページの『WSDL のホスティング』を参照) に対する HTTP 要求です。以下に、このEventHandler が各タイプの要求を処理するときのシーケンスを示します。

SOAP 要求

1. SOAP 要求が解析されます。

2. WSDL 定義に照らして SOAP 要求の妥当性が検査されます。

3. EventHandler プロローグが実行されます。

4. SOAP 要求の入力値に基づいて作成された初期項目を使用して、AssemblyLine が実行されます。

5. EventHandler は AssemblyLine が完了するまで待ち、その結果項目を検索します。

6. EventHandler エピローグが実行されます。


7. WSDL 定義に照らして、AssemblyLine の結果項目の妥当性が検査されます。

8. AssemblyLine の結果項目に基づいて SOAP 応答が生成され、HTTP を介してクライアントに送り返されます。

WSDL 要求

1. EventHandler プロローグが実行されます。

2. WSDL ファイルの内容が検索されます (EventHandler が WSDL ファイルのホストとして稼働するように構成されている場合)。

3. EventHandler エピローグが実行されます。

4. WSDL の内容が HTTP を介してクライアントに送り返されます。

イベント・プロパティーWeb サービス EventHandler は、要求の処理中に、その要求に関連したイベントをプロローグ・スクリプトとエピローグ・スクリプトに渡します。イベント・オブジェクトには、以下のプロパティーが割り当てられます。

接続プロパティー:

tcp.remoteIP接続のリモート IP アドレス。

tcp.remotePort接続のリモート・ポート。

tcp.remoteHost接続のリモート・ホスト名。

tcp.localIPローカル IP アドレス。

tcp.localPortEventHandler が要求を listen するローカル・ポート。

tcp.localHostローカル・ホスト名。

Web サービス・プロパティー:

event.originator要求を処理している Web サービス EventHandler のインスタンス。

ws.requestedResourcejava.lang.String オブジェクト。このオブジェクトの値は、WSDL 要求を処理している場合は WSDL で、SOAP 要求を処理している場合は AL です。

ws.wsdl戻す WSDL を含む java.lang.String オブジェクト。 EventHandler が WSDL

のホストとして稼働していない場合は、このプロパティーは NULL です。このプロパティーは、WSDL 要求のエピローグの中でのみ設定されます。

ws.rawSoap解析されなかった SOAP 要求 (SOAP ヘッダーを含む) が入っているjava.lang.String オブジェクト。このプロパティーは SOAP 要求の場合のみ設定されます。


ws.requestMatchesWsdljava.lang.Boolean 値。SOAP 要求が WSDL 定義と一致する場合は、この値は true です。そうでない場合は、この値は false です。このプロパティーは、SOAP 要求のプロローグの中でのみ設定されます。

event.assemblyLineName開始される AssemblyLine の名前。このプロパティーは、SOAP 要求を処理しているときのみ設定されます。

event.inputEntrySOAP 要求の入力パラメーターに対応する属性を持つ項目オブジェクト。このプロパティーは、SOAP 要求を処理しているときのみ設定されます。

event.outputEntry応答の出力パラメーターに対応する属性を持つ項目オブジェクト。このプロパティーは、SOAP 要求のエピローグの中でのみ設定されます。

event.successfulALExecutionjava.lang.Boolean 値。要求された AssemblyLine が正常に開始した場合は、この値は true です。そうでない場合は、この値は false です。このプロパティーは、SOAP 要求のエピローグの中でのみ設定されます。

注: プロローグまたはエピローグの中でのスクリプト処理の結果として、クライアントに SOAP 障害を戻す必要がある場合は、次のようにして、Web サービスEventHandler の setError(java.lang.String aMsg) メソッドを使用することができます。

var wsEventHandler = event.getProperty("event.originator");wsEventHandler.setError("Some message...");

この 2 行のコードにより、Web サービス EventHandler は、プロローグまたはエピローグ・スクリプトの終わりに達するまでそのスクリプトの実行を続け、その後で、"Some message..." を含む faultstring を伴う SOAP 障害メッセージを生成します。これらの 2 行の挿入が必要になるのは、例えばプロローグ内にセキュリティー・メカニズムをインプリメントする場合などです。

構成WSDL URL

WSDL 文書の URL。

TCP ポートEventHandler が SOAP/HTTP 要求を受け入れるポート。

SSL の使用このプロパティーにチェックマークを付けると、Web サービスEventHandler は SSL を使用します。

注: SSL を使用するには、鍵ストアの中に独自の証明書を生成する必要があります (keytool を使用)。そして、クライアントはこの証明書をインポートする必要があります。

コメントここにはユーザー独自のコメントを入力します。





WSDL のホスティングWeb サービス EventHandler は WSDL のホストとして機能できます。WSDL に対する要求が到着すると、Web サービス EventHandler は HTTP を介して WSDL を戻します。

WSDL ホスティングを構成するには、次のようにします。

1. Web サービス EventHandler の「構成...」タブで、「TCP ポート」および「SSLの使用」構成パラメーターを入力します。

2. Web サービス EventHandler の「WSDL」タブで、「ホスト WSDL」チェック・ボックスにチェックマークを付けます。こうすると、「Web サービスURL」編集ボックスが読み取り専用になるので、その内容をhttp://your_computer_IP:port/ (または、「構成...」タブで「SSL の使用」にチェックマークを付けた場合は https://your_computer_IP:port/) に設定します。your_computer_IP は、IBM Tivoli Directory Integrator の Config Editor が実行されているコンピューターの IP アドレスです。port は、「構成...」タブで入力した「TCP ポート」構成パラメーターです。「ホスト WSDL」にチェックマークを付けてある場合は、WSDL URL も表示されます。WSDL URL は、クライアントが WSDL ファイルを検索するために使用する必要がある URL です。Web

サービス EventHandler の実行中に、HTML ブラウザーでこの URL を入力すると、ブラウザーは WSDL ファイルの内容を検索します。WSDL URL の形式は、http://your_computer_IP:port/?WSDL= (または、「SSL を使用」にチェックマークを付けた場合は https://your_computer_IP:port/?WSDL=) です。

3. 「WSDL の作成」をクリックします。WSDL ファイルが生成されて保管され、エディター・ボックスに表示されます。生成された WSDL に変更を加えたい場合は、このエディター・ボックスの中で変更を行うことができます。「WSDLの保管」をクリックして変更を保管するのを忘れないでください。

注: 「ホスト WSDL」を使用していて、「TCP ポート」を変更したり、「SSL

の使用」をオンまたはオフに切り替える場合は、「ホスト WSDL」チェック・ボックスのチェックマークを外してから再びチェックマークを付けて、「Web サービス URL」と「WSDL URL」を更新してください。

WSDL の自動生成Web サービス EventHandler の「WSDL」タブで、WSDL ファイルが自動的に生成されるようにすることができます。「使用可能な AssemblyLines」リスト・ボックスには、現行の IBM Tivoli Directory Integrator 構成に含まれているAssemblyLine のうち、WSDL 文書に含めて公開することができる AssemblyLine が表示されます。「公開 AssemblyLines」リスト・ボックスには、作成する WSDL

文書内の Web サービス操作として公開される AssemblyLine が表示されます。WSDL 文書内で特定の AssemblyLine を公開する場合は、「使用可能な


AssemblyLines」リスト・ボックスからその AssemblyLine を選択し、左矢印 (<)

ボタンをクリックします。AssemblyLine が「公開 AssemblyLines」リストに移動します。すでに「公開 AssemblyLines」リストに移動している AssemblyLine のどれかを公開したくない場合は、リストからその AssemblyLine を選択し、右矢印 (>)

ボタンをクリックします。AssemblyLine が「使用可能な AssemblyLines」リストに移動します。

WSDL ファイルを生成するには、次のようにします。

1. Web サービスとして公開するすべての AssemblyLine を、「公開AssemblyLines」リスト・ボックスに移動します。

2. 「WSDL ファイル名」フィールドで、作成する WSDL ファイルのファイル・パスを入力するか、参照から選択します。

3. 「Web サービス URL」フィールドで、次のようにします。

v WSDL ホスティングを使用しない場合は、「Web サービス URL」フィールドに Web サービスの URL を入力します。Web サービスの URL には、Web

サービス EventHandler を実行するコンピューターとポートを示す URL を指定してください (例えば、http://215.50.1.100:8080/)。

v WSDL ホスティングを使用する場合は、「ホスト WSDL」チェック・ボックスにチェックマークを付けてください。

4. 「WSDL の作成」ボタンをクリックします。WSDL ファイルが生成されて保管され、内容がエディター・テキスト・ボックスに表示されます。

属性タイプこのユーティリティーは、以下のようにして、操作の入力パラメーターおよび出力パラメーターのタイプを、WSDL のメッセージ部分に入れます。

ユーティリティーは、各属性について、対応する AssemblyLine の「呼び出し/戻り」タブで定義されている「構文」フィールドの値を調べます。ユーティリティーは、この値が Java クラスの名前 (例えば、java.lang.Integer) であることを予期します。ユーティリティーは、 139ページの『WSDL メッセージ・パート・タイプとJava タイプのマッピング』に示したタイプ・マップに従って、この値を XML スキーマにマップします。そして、その XML スキーマ・タイプが、WSDL メッセージ部分のタイプとして WSDL に書き込まれます。

注: 属性行の「構文」列を空のままにした場合は、WSDL 生成ユーティリティーは、その属性のタイプが java.lang.String であるものと見なします。

SOAP 操作のスタイルWeb サービス EventHandler が生成する WSDL ファイル内の SOAP 操作は、すべて RPC スタイルを使用します。

zOS LDAP 変更ログ EventHandlerzOS LDAP 変更ログ EventHandler は、zOS LDAP サーバー内の変更レコードを対象として繰り返しを行います。この EventHandler は、IBM Directory Server

EventHandler に非常に類似しています ( 119ページの『IBM Directory Server

EventHandler』を参照してください)。相違点は、この EventHandler は、非送信請求イベント通知を使用する代わりに変更ログのポーリングを行うことです。


注: 現在、zOS LDAP 変更ログ EventHandler では、非送信請求イベント通知はサポートされていません。

LDAP ディレクトリー内でイベント (追加、変更、削除など) が発生すると、zOS

LDAP サーバーは変更レコードを作成します。この EventHandler は、これらの変更レコードを対象として繰り返しを行い、ユーザーが構成したように AssemblyLine

を開始します。

この EventHandler は、IBM Directory Server EventHandler と同様に使用してください。zOS LDAP 変更ログ EventHandler は、既存の IBM Directory Server

EventHandler の代わりに、IBM Directory Server と同様に効果的に使用することができます。


LDAP URLzOS LDAP サーバーへの URL。この URL の形式は、ldap://hostname.domain:port です。

ログイン・ユーザー名LDAP サーバーへの認証を行うための DN。

ログイン・パスワードLDAP サーバーへの認証を行うためのパスワード (ログイン・ユーザー名用)。

変更ログ検索ベース変更ログに使用するサフィックス。zOS の場合は、常に cn=changelog(cn=changelog はデフォルト) です。

検索ベース変更を検索するディレクトリー・ツリーの一部。例えば、検索ベースがo=ibm,c=us である場合は、EventHandler は o=ibm,c=us ツリー内のすべての変更に応答しますが、o=ms,c=us ツリー内の変更には応答しません。

検索範囲検索ベースに関連して使用する範囲 (デフォルトはサブツリー)。前述の例(検索ベース) を参照してください。範囲を baseObject に設定すると、指定したオブジェクトへの変更のみがトリガーされます。

変更番号ファイル名最後に処理された変更番号を保管するファイル (プレーン・テキスト・ファイル)。

初期変更番号変更番号ファイル名が存在しない場合は、この番号は変更ログ処理の開始点となります。変更番号ファイル名が存在する場合は、このフィールドは無視されます。

ポーリング間隔変更ログのポーリング間に EventHandler がスリープする時間 (秒)。

コメント任意のコメントを入力します。


認証メソッドLDAP 接続に使用する認証メソッドのタイプ。

SSL の使用LDAP サーバーに対して SSL を開始します (必ず LDAP URL のポートを変更してください)。

自動始動サービスサーバー始動時にこの EventHandler を自動的に始動する場合は、このチェック・ボックスにチェックマークを付けます。

詳細ログEventHandler のデバッグ・ロギングをオンにします。

ポーリング・ロジック現在、zOS LDAP サーバーではイベント通知がサポートされていないので、変更ログ内の新規項目のチェックにはポーリング・メカニズムが使用されます。

EventHandler は、開始すると、構成に指定したファイルから最後に処理された変更番号を読み取ろうとします。このファイルが存在しない場合は、「構成 ...」パネルに指定した初期変更番号が使用されます。

lastchangenumber 属性を検索するには、ルート DSE 検索を実行します。現在の変更番号 (ファイルまたは「構成 ...」から) が lastchangenumber よりも小さい場合は、EventHandler は、LDAP コネクターを使用して次の順次変更番号を zOS

LDAP に要求します。

変更ログ項目に記述されている項目が検索範囲内に収まる場合は、そのイベントはディスパッチされ、変更番号が増加します。項目が検索範囲に収まらない場合や、項目が存在しない場合は、変更番号が増加し、項目は無視されます。

この lastchangenumber との比較は、変更番号が lastchangenumber と等しくなるまで行われます。この条件が真になると、システムの最後の変更番号とEventHandler は、「構成...」パネルに指定したポーリング間隔の期間だけスリープします。この間隔が経過すると、ルート DSE の lastchangenumber が再び検索され、サイクルが繰り返されます。

任意の時点で lastchangenumber 属性が 0 になると、変更ログは空であり、EventHandler はポーリング間隔の期間だけスリープすることを意味します。


第 4 章パーサー

パーサーはトランスポート・コネクターと一緒に使用され、コネクターのバイト・ストリームを介して送受信されるコンテンツを解釈または生成します。

解析しようとしているバイト・ストリームが選択したパーサーに適合しない場合は、ユーザーは sun.io.MalformedInputException エラーを受け取ります。このエラー・メッセージは、例えば、「スキーマ」タブを使用してファイルをブラウズしているときなどに表示されます。

基本パーサーv 150ページの『CSV パーサー』

v 151ページの『DSML パーサー』

v 152ページの『固定パーサー』

v 153ページの『HTTP パーサー』

v 155ページの『LDIF パーサー』

v 156ページの『行リーダー・パーサー』

v 157ページの『スクリプト・パーサー』

v 159ページの『単純パーサー』

v 160ページの『SOAP パーサー』

v 162ページの『XML パーサー』

文字エンコード変換Java2 は、内部文字エンコードとして Unicode を使用します。 AssemblyLine およびコネクター内でストリングおよび文字を操作するときは、ストリングおよび文字は常に Unicode であるものと見なされます。ほとんどのコネクターは、文字エンコードを変換するための何らかの手段を備えています。ローカル・システムでテキスト・ファイルを読み取るときには、Java2 は、すでにデフォルトの文字エンコード変換を確立しています。このデフォルトの変換は、実行しているプラットフォームによって異なります。

ただし、テキスト・ファイルからのデータの読み取り、またはそこへのデータの書き込みを行うとき、ファイルによって文字エンコードの方式が異なる場合がしばしばあります。パーサーを必要とするコネクターは、通常、パーサー構成のcharacterSet パラメーターを受け入れます。このパラメーターを設定する場合は、Java2 ランタイム内にある、受け入れられる変換テーブルの 1 つに設定してください。このパラメーターを設定しない場合は、ほとんどのパーサーはローカル文字エンコード方式を使用します。一部のパーサーには、特定のデフォルト文字エンコード方式があります。個々のパーサーの詳細については、この章を参照してください。


可用性使用可能な変換テーブルのリストについては、Java2 の資料を参照してください。http://developer.java.sun.com/developer/infodocs/ を参照してください。

CSV パーサーComma Separated Values (CSV) パーサーは、CSV 形式のデータの読み取りおよび書き込みを行います。

注: Config Editor では、パラメーターはファイル・コネクターの「パーサー」タブで設定します。フィールド分離文字として TAB を使用する場合は、¥t を使用する必要がありますが、複数のフィールド名を指定するときは、フィールド名の間に実際のタブ文字を使用する必要があります。

出力では、多値属性の値は最初の 1 つだけが出力されます。

構成このパーサーは、以下のパラメーターを必要とします。

フィールド分離文字このパラメーターには、各列を分離するために使用する文字を指定します。指定しない場合は、パーサーは読み取り時には自動判別を試み、書き込み時にはコンマを使用します。エスケープ文字として円記号 (¥) を使用すると、印刷不能文字を指定できます。たとえば、( ¥t ) はタブ文字を表します。

フィールド名このパラメーターは、パーサーが読み取りまたは書き込みを行う各列の名前を指定します。指定しない場合は、パーサーは最初の行を読み取り、その値をフィールド名として使用します。フィールド名の間にフィールド分離文字を使用することも、別個の行にそれぞれの名前を指定することもできます。

引用符の使用可能このパラメーターを true に設定すると、フィールドが以前のバージョンと同じ条件で引用符で囲まれて出力されます。このとき、引用符付きフィールドの中の引用符は 2 つ繰り返されます。

注: 引用符の使用可能を false に設定すると、フィールドはそのまま出力され、問題が発生する場合があります。

このパラメーターを true に設定すると、読み取り時にフィールドを囲む引用符が取り除かれ、パーサーが引用符で囲まれた属性 (列区切り文字を含む属性など) を読み取ることができます。このパラメーターを false に設定すると、引用符で区切られたフィールドが入力に含まれる場合に、パーサーが予期しない値を戻します。

ヘッダーの書き込みこのパラメーターのデフォルト値は true です。ヘッダーの書き込みを設定すると、パーサーによって出力される最初の行に、列区切り文字で分離されたすべてのフィールド名が出力されます。


長い行のログ1 行の最大バイト数を定義します。この最大数より長い行の行番号がログに記録されます。

文字エンコード文字エンコード変換。このパラメーターは、パーサー構成からは直接使用できません。このパラメーターを設定するには、構成ファイルを手動で編集する必要があります。


DSML パーサーDSML パーサーは、XML 文書の読み取りと書き込みを行います。このパーサーは、スキーマ項目を警告なしに無視します。


DN 属性識別名 DSML 属性 ($dn) に使用する属性。

DSML 接頭部XML エレメントが DSML ネーム・スペースに属することを指示する接頭部。デフォルトは dsml です。

DSML ネーム・スペース URIこのネーム・スペースを識別する URI。デフォルトはhttp://www.dsml.org/DSML です。

XML 宣言の省略これにチェックマークを付けた場合は、出力ストリームから XML 宣言が省かれます。

文書の妥当性検査これにチェックマークを付けた場合は、このパーサーは DTD/Schema 妥当性検査パーサーを要求します。

ネーム・スペースを意識これにチェックマークを付けた場合は、このパーサーはネーム・スペース認識パーサーを要求します。

文字エンコード文字エンコード変換。


例以下の例は、DSML 文書を動的に生成する方法を示しています。

第 4 章パーサー 151

var dsml = system.getParser ( "ibmdi.DSML" );var entry = system.newEntry();

entry.setAttribute ("$dn", "uid=johnd,o=doe.com");entry.setAttribute ("mail", "[email protected]");entry.setAttribute ("uid", "johnd");entry.setAttribute ("objectclass", "top");entry.addAttributeValue ("objectclass", "person");

dsml.setOutputStream ( new java.io.StringWriter() );// Uncomment if you dont want the "<?xml version= ...." header// dsml.setOmitXMLDeclaration ( true );dsml.initParser();dsml.writeEntry ( entry );dsml.closeParser();

var result = dsml.getXML();task.logmsg ( result );

以下の例は、スクリプトを使用して DSML 文書を読み取る方法を示しています。

var dsml = system.getParser ("ibmdi.DSML");dsml.setInputStream ( new java.io.FileInputStream("dirdata.dsml") );dsml.initParser ();

var entry = dsml.readEntry();while ( entry != null ) {task.dumpEntry ( entry );entry = dsml.readEntry();}

関連情報162ページの『XML パーサー』, 160ページの『SOAP パーサー』

固定パーサー固定パーサーは、固定長レコードの読み取りおよび書き込みを行います。


列記述これは複数行パラメーターであり、それぞれフィールド名、オフセット、および長さを指定します。例:

field1, 1, 12field2, 13, 4field3, 17, 3

値のトリム入力フィールドの先行スペースまたは末尾のスペースを切り捨てます。




HTTP パーサーHTTP パーサーは、HTTP 仕様に従ってバイト・ストリームを解釈します。このパーサーは、HTTP クライアント・コネクターおよび HTTP サーバー・コネクターにより使用されます。


プロパティーとしてのヘッダー設定した場合は、ヘッダー値はプロパティーとして取得され、プロパティーとして設定されます。設定しない場合は、ヘッダー値は属性として読み取られ、属性として戻されます。

クライアント・モード設定した場合は、パーサーはクライアント・モードで動作します。設定しない場合は、パーサーはサーバー・モードで動作します。



属性またはプロパティーパーサーは、ページを作成するときに、プロパティーとしてのヘッダーの値に基づいて、以下の属性またはプロパティーのうちの該当するものを使用して、ヘッダーを作成します。ページを読み取るとき、パーサーはヘッダーを解析して、可能であればこれらの属性またはプロパティーに入力します。

http.methodこの情報をクライアント・モードで送信するときの HTTP メソッド (デフォルトは GET)。この属性またはプロパティーは、サーバー・モードで戻されます。HTTP メソッドについての詳細は、http://www.w3.org/Protocols/HTTP/Methods.html を参照してください。

http.url使用する URL。この属性またはプロパティーは、クライアント・モードでは必須です。

http.content-type戻される http.body のコンテンツ・タイプ (存在する場合)。これをapplication/x-www-form-urlencoded に設定した場合は、さらにヘッダーを見つけるために http.body も解析されます。書き込みの場合 (http.bodyに何か含まれている場合) のデフォルト値は、text/plain です。

http.responseCode整数オブジェクトとしての HTTP 応答コード。クライアント・モードでの読み取り。


http.responseMsgストリング・オブジェクトとしての HTTP 応答メッセージ。クライアント・モードでの読み取り。


http.content-lengthhttp.body のバイト数。この属性またはプロパティーは、読み取り時には戻され、書き込み時には無視されます。これはパーサーによって再計算されます。

http.body読み取りの際には、このオブジェクトは、データのコンテンツ・タイプに応じて、戻される本文を含む java.lang.StringBuffer のインスタンス、char[]、または byte[] です。コンテンツが StringBuffer である場合は、次のようなコードを使用できます。

var body = conn.getObject ("http.body");task.logmsg ("Returned text: " + body.toString() );

char[] または byte[] の処理の詳細については、「IBM Tivoli Directory

Integrator 5.2 ユーザーズ・ガイド」の『Using binary values in scripting』を参照してください。書き込みの際には、http.body には、java.io.File のインスタンスか (この場合はそのファイルが本文として使用されます)、または本文として使用される何らかのテキストが入ります。

http.text-body読み取りの際に、http.content-type が text/ というシーケンスで始まっている場合は、コネクターは本文がテキスト・データであるものと判断し、http.body ストリーム・オブジェクトをこの属性に読み込みます。

http.redirectサーバー・モードで書き込みを行っているときに、この属性またはプロパティーに値が存在する場合は、その値を指し示すリダイレクト・メッセージが送信されます。

http.statusサーバー・モードでの書き込みの場合に使用されます。デフォルトは OKです。指定できる値は以下のとおりです。

v OK または 200 OK: 200 OK 応答を戻します。

v FORBIDDEN または 401 Forbidden: http.auth-realm 属性またはプロパティーを使用して、認証を試行します。

v NOT FOUND または 404 File Not Found: 404 File Not Found 応答を戻します。

http.auth-realm追加認証を要求するときに使用されます。デフォルト値はIBM-Directory-Integrator です。

http.authorizationサーバー・モードで読み取られる認証が含まれます。多くの場合、http.remote_user および http.remote_pass を使用する方が簡単です。


http.remote_userサーバー・モードで読み取りを行う際に戻されるユーザー名、またはクライアント・モードで書き込みを行う際に使用するユーザー名。

http.remote_passサーバー・モードで読み取りを行う際に戻されるパスワード、またはクライアント・モードで書き込みを行う際に使用するパスワード。

http.base基本 URL。サーバー・モードで読み取りを行っているときに戻されます。

http.qs.*サーバー・モードで読み取りを行っているときの照会ストリングのパート。キーは、http.qs. の後に続く名前のパートです。

この値は属性またはプロパティーに含まれます。

http.* http. で始まるその他のすべての属性またはプロパティーは、書き込み時にヘッダー行を生成するために使用します。読み取りの際には、ヘッダーは、名前が http. で始まりその後にヘッダーの名前が続く属性またはプロパティーに入れられます。

関連情報28ページの『HTTP クライアント・コネクター』, 32ページの『HTTP サーバー・コネクター』

LDIF パーサーLDIF パーサーは、LDIF スタイルのデータの読み取りおよび書き込みを行います。LDIF パーサーは、通常、LDAP ディレクトリーとの間でファイル交換を行うために使用されます。

LDIF パーサーは、MIME BASE64 でエンコードされたストリングを正しく解析し、書き込みます。そして、必要な場合は、BASE64 エンコードを行おうとします。例えば、属性値の後に末尾のスペースがある場合、このパーサーは、他の LDIF

パーサーがそのスペースを確実に取得できるように、BASE64 で属性をエンコードします。

注: 準拠する LDIF ファイルは、常に文字エンコードが UTF-8 に設定されていることが必要です。文字エンコード・パラメーターは、BASE64 エンコード・ストリングをエンコードまたはデコードするときにも適用されます。

BASE64 エンコードは、デコードの方法を知らない限り、文字化けしたテキストのように見えます。


DN 属性名使用する属性名。


バージョン番号これにチェックマークを付けた場合は、出力の始めにバージョン属性が表示されます。デフォルトでは、このパラメーターは On です。

注: LDIF パーサーは、バージョン番号パラメーターを使用して LDIF バージョン番号を抑止できるようになりました。

バイナリー属性バイナリーとして扱われる追加属性を指定する必要がある場合は (バイナリー属性はストリングではなくバイト配列として戻されます)、このパラメーターに追加属性を指定します。デフォルトでは、バイナリーと見なされるのは以下の属性です。

v photo

v personalSignature

v audio

v jpegPhoto


v thumbnailPhoto

v thumbnailLogo

v userPassword

v userCertificate





v objectGUID

v objectSid



関連情報http://www.ietf.org/rfc/rfc2849.txt

行リーダー・パーサー行リーダー・パーサーは、単一行のデータを読み取ります。読み取られた行は単一の属性として戻されます。他に linenumber という属性もあり、これには 1 から始まる行番号が入ります。

注: 行リーダー・パーサーは、テキスト・ファイルのみをコピーする場合に使用します。バイナリー・ファイルをコピーする場合は、 174ページの『例』でバイナリー・ファイルをコピーする方法の例を参照してください。


行リーダー・パーサーは、テキスト・ファイルのみを読み取るときに便利です。


属性名このパラメーターは、行を含む属性の名前を指定します。デフォルトはline です。



スクリプト・パーサースクリプト・パーサーを使用すると、使い慣れているスクリプトを使用して独自のパーサーを作成することができます。

スクリプト・パーサーが機能するためには、いくつかの関数をインプリメントする必要があります。これらの関数は、パラメーターを使用しません。これは、一部のスクリプト言語では必ずしもパラメーターの使用をサポートしていないためです。ホストとして稼働するコネクターとスクリプトの間のデータの受け渡しには、事前定義済みのオブジェクトが使用されます。これらの定義済みオブジェクトの 1 つに結果オブジェクトがあり、これは状況情報を伝達するために使用されます。いずれかの関数に入る時点では、状況フィールドは通常に設定されており、その場合ホスト・パーサーは呼び出しを続行します。入力終了またはエラーを通知するには、このオブジェクト内の状況フィールドおよびメッセージ・フィールドを設定します。項目オブジェクトは、writeEntry の呼び出し時に移植され、readEntry 関数で移植されると予期されます。項目を読み取るときは、ストリームからの文字データの読み取りのために inp BufferedReader オブジェクトを使用できます。項目を書き込むときは、ストリームへの文字データの書き込みのために out BufferedWriter オブジェクトを使用できます。

ユーザーは、構成に独自のパラメーターを追加し、パーサー・オブジェクトを使用してそれらのパラメーターを取得することができます。

オブジェクトスクリプト・パーサーからアクセスできるオブジェクトは、以下のものだけです。

結果オブジェクト

setStatusコード

v 0: 入力終了

v 1: 状況 OK

v 2: エラー


setMessageテキスト

項目オブジェクト

addAttributeValue (name, value)属性に値を追加します。

getAttribute (name)指定した属性を戻します。

使用できるすべてのメソッドのリスト (パラメーターおよび戻り値を含む) は、javadocs (root_directory¥docs¥api¥com¥ibm¥di) にあります。

inp オブジェクト

read() ストリーム内の次の文字を戻します。

readLine()入力ストリーム内の次の CRLF 終了行を戻します。

out オブジェクト

write (str)出力ストリームにストリングを書き込みます。

writeln (str)CRLF を伴うストリングを出力ストリームに書き込みます。

パーサー・オブジェクト

getParam(str)パラメーター名 str に関連したパラメーター値を戻します。

setParam(str, value)パラメーター str の値を value に設定します。

logmsg(str)パラメーター str をログ・ファイルに書き込みます。

すべてのメソッドのリストは、インストール・パッケージにあります。

コネクター・オブジェクト詳細については、インストール・パッケージに収められている Javadocs の資料を参照してください。

関数このパーサーは、以下の関数を提供する必要があります。

readEntry()入力ストリーム内の次の論理項目を読み取り、項目オブジェクトに移植します。

writeEntry()項目オブジェクトの内容を出力ストリームに書き込みます。



スクリプト言語リストから使用可能なスクリプト言語を選択します。

外部ファイル実行時に外部スクリプト・ファイルを組み込む場合は、それらのファイルを指定します。これらのファイルは、スクリプトの前に実行されます。

グローバル・スクリプトの組み込みスクリプト・ライブラリーからスクリプトを組み込みます。



スクリプト実行するユーザー定義スクリプト。

注: スクリプト・コネクターまたはパーサーを使用するとき、スクリプトは、それが入っているライブラリーから構成ファイルにコピーされます。これには、スクリプトをカスタマイズできるという利点がありますが、AssemblyLine が新規バージョンを認識しないという欠点もあります。

この欠点に対処するには、AssemblyLine から旧スクリプト・パーサーを除去し、再導入します。その際、フックからコードをコピーするようにしてください。

例ご使用の IBM Tivoli Directory Integrator システムのroot_directory/examples/script_parser ディレクトリーにあります。

関連情報92ページの『スクリプト・コネクター』、および「IBM Tivoli Directory Integrator

5.2 ユーザーズ・ガイド」の『JavaScript Parser』を参照してください。

単純パーサー単純パーサーは、項目の読み取りおよび書き込みを行います。形式は、attributename:value のペアの複数行です。ここで、attributename は属性名、value は値です。

多値属性には複数の行を使用します。単一のピリオドがある行は項目の終わりを示します。 value の中の \r および \n は、CR および LF のエンコードです。





SOAP パーサーSOAP パーサーは、SOAP XML 文書の読み取りと書き込みを行います。このパーサーは、単純かつ直接的な方法で、SOAP XML 文書を項目オブジェクトに、そして項目オブジェクトを SOAP XML 文書に変換します。 XML 文書を作成するとき、パーサーは項目からの属性を使用して文書を作成します。SOAP_CALL 属性には、SOAP 呼び出しの値が含まれます。同様に、読み取りの際には、この属性はSOAP-ENV:Body タグの後の最初のタグを示すように設定されます。そして、項目内の各属性について、その名前と値を持つタグが作成されます。文書の読み取りの際には、SOAP_CALL タグの下の各タグは項目オブジェクト内の属性に変換されます。

注: Web サービスの EventHandler およびコネクターを操作するときに、属性名の最初の 1 文字には、特殊文字 ([0 から 9] [- ’ ( ) + , . / = ? ; ! * # @ $%] など) を使用することはできません。また、特殊文字 ([ ’ ( ) + , / = ?; !* # @ $ % ] など) を属性名の中で使用することもできません。これは、Web

サービスは SOAP (つまり XML) を基礎として作成されているためです。XML

は、タグ内の文字として $ を受け入れません。

以下の例は、読み取りおよび書き込みの際の項目および SOAP XML 文書を示しています。

項目の例*** Begin Entry DumpSOAP_CALL: ’updateLDAP’mail: (’[email protected])’uid: ’johnd’*** End Entry Dump

SOAP 文書の例<SOAP-ENV:Envelopexmlns:SOAP-ENV="(http://schemas.xmlsoap.org/soap/envelope/)"xmlns:xsi="(http://www.w3.org/1999/XMLSchema-instance)"xmlns:xsd="http://www.w3.org/1999/XMLSchema"><SOAP-ENV:Body><ns1:updateLDAP xmlns:ns1="" SOAP-ENV:encodingStyle=

"http://schemas.xmlsoap.org/soap/encoding/"><uid xsi:type="xsd:string">johnd</uid><mail xsi:type="xsd:string">[email protected]</mail></ns1:updateLDAP></SOAP-ENV:Body></SOAP-ENV:Envelope>



XML 宣言の省略出力ストリーム内の XML 宣言ヘッダーを省略します。

文書の妥当性検査DTD/XSchema 妥当性検査 XML パーサーを要求します。

ネーム・スペースを意識ネーム・スペース認識 XML パーサーを要求します。



パーサー固有の呼び出しSOAP パーサーには、ユーザーのスクリプトからアクセスできます。そのためには、このパーサーを動的にロードし、SOAP 文書の読み取りまたは書き込みを行うメソッドを呼び出します。以下の例は、項目から XML 文書を生成する方法を示しています。

var e = system.newEntry();e.setAttribute ("soap_call", "updateLDAP");e.setAttribute ("uid", "johnd");e.setAttribute ("mail", "([email protected])");

// Retrieve the XML document as a stringvar soap = system.getParser ("ibmdi.SOAP");soap.initParser();var soapxml = soap.getXML ( e );

task.logmsg ( "SOAP XML Document" );task.logmsg ( soapxml );

// Write to a filevar soap = system.getParser("ibmdi.SOAP");soap.setOutputStream ( new java.io.FileOutputStream("mysoap.xml") );soap.writeEntry ( e );soap.close();

// Read from filesoap.setInputStream ( new java.io.FileInputStream ("mysoap.xml") );var entry = soap.readEntry();

// Read from string (from soapxml generated above)var entry = soap.parseRequest( soapxml );task.dumpEntry ( entry );

例ご使用の IBM Tivoli Directory Integrator システムの root_directory/examples/soap ディレクトリーにあります。


XML パーサーXML パーサーは、XML 文書の読み取りと書き込みを行います。このパーサーは、Apache の Xerces ライブラリーおよび Xalan ライブラリーを使用します。このパーサーでは、xmldom というスクリプト・オブジェクトを使用して XML 文書にアクセスできます。xmldom は、org.w3c.dom.Document インターフェースのインスタンスです。このインターフェースの詳細については、http://java.sun.com/xml/jaxp-1.0.1/docs/api/index.html を参照してください。

XPathAPI (http://xml.apache.org/xalan-j/apidocs/index.html およびスクリプト内のアクセス Java クラス) を使用して、XML 文書からノードを検索して選択することもできます。 selectNodeList (システム・オブジェクト内の便利なメソッド) を使用すると、XML 文書からサブセットを選択できます。

コネクターが初期化されると、XML パーサーは、文書タイプ定義 (DTD) 検査を行おうとします (DTD タグが存在する場合)。

ユーザーが自分で XML 文書を解釈または生成するには、コネクターの指定変更関数を使用します。AssemblyLine のフック定義に GetNext の指定変更またはGetNext 成功を使用して、必要なスクリプトを作成します。指定変更しない場合は、パーサーは、項目オブジェクト・モデルに似たきわめて単純な XML 文書の読み取りまたは書き込みを行います。デフォルトのパーサーでは、深度 2 レベルまでの XML ファイルの読み取りまたは書き込みしかできません。デフォルトのパーサーは、自身が作成したファイルであっても、多値属性を読み取ることはできません。多値属性を読み取る方法の例については、 163ページの『例』を参照してください。

setAttribute など一部のメソッドは、IBM Tivoli Directory Integrator の項目と、xmldom.createElement から戻されるオブジェクトの両方で使用できるという点に注意してください。これらの関数は、同じ名前またはシグニチャーを持ちます。xmldom のオブジェクトと IBM Tivoli Directory Integrator のオブジェクトを混同しないようにしてください。

注:

1. 大きい XML ファイル (4MB 以上) を読み取るか、または大きい XML ファイル (14MB 以上) に書き込もうとすると、Java VM でメモリー不足が発生します。この対処方法については、「IBM Tivoli Directory Integrator 5.2 ユーザーズ・ガイド」の『Increasing the memory available to the Virtual Machine』を参照してください。

2. このパーサーは、空の項目を警告なしに無視します。

3. $ などの一部の文字は、XML タグでは無効です。XML パーサーを使用するときは、属性名にこのような文字を使用しないでください。使用すると、無効なXML が作成されることがあります。

4. LDAP ディレクトリーまたは LDIF ファイルから読み取るとき、通常、識別名(DN) は $dn という属性に入ります。$dn は XML 文書用の有効なタグではないため、名前を XML ファイルに変更せずにこの属性をマップしようとすると失敗します。明示的マッピングを行う場合は、出力コネクター内で、″$dn″ を ″dn″(または特殊文字を含まないその他の値) に変更する必要があります。暗黙的マッピング (例えば、*、または AssemblyLine の「構成...」タブの AssemblyLine


設定で「自動的にすべての属性をマップ」にチェックマーク) を行う場合は、識別名 (例えば $dn) を別の名前に変換するように XML パーサーを構成することができます。例えば、GetNext 前フックに次のような行を追加します。

conn.setAttribute("dn", work.getAttribute("$dn"));conn.removeAttribute("$dn");

5. IBM Tivoli Directory Integrator で使用される XML のインプリメンテーションは DOM モデルを使用するので、メモリー・ベースであると言えます。メモリーが有効であるためには、メモリー内にツリー全体が含まれる必要があります。このことは、コネクターがイテレーター・モードで XML パーサーを使用することに関して問題ありません。再始動や通常の操作時に、パーサーはメモリー内のツリー全体を読み取りますが、再始動時に正しい項目までスキップするようチェックポイント・リスタート・フレームワークに指定している場合は、そのように動作します。


ルート・タグルート・タグ (出力)。

項目タグ項目用の項目タグ (出力)。

値タグ項目属性用の値タグ (出力)。


XML 宣言の省略これにチェックマークを付けた場合は、出力ストリームから XML 宣言が省かれます。

文書の妥当性検査これにチェックマークを付けた場合は、このパーサーは DTD/Schema 妥当性検査パーサーを要求します。

ネーム・スペースを意識これにチェックマークを付けた場合は、このパーサーはネーム・スペース認識パーサーを要求します。

インデント出力このフィールドにチェックマークを付けると、出力がインデントされます。


例追加の指定変更フック

var root = xmldom.getDocumentElement();var entry = xmldom.createElement ("entry");var names = work.getAttributeNames();

for ( i = 0; i < names.length; i++ ) {


xmlNode = xmldom.createElement ("attribute");xmlNode.setAttribute ( "name", names[i] );xmlNode.appendChild ( xmldom.createTextNode ( work.getString(

names[i] ) ) );entry.appendChild ( xmlNode );}root.appendChild ( entry );

選択後フック

//// Set up variables for "override getnext" hook//

var root = xmldom.getDocumentElement();var list = system.selectNodeList ( root, "//Entry" );var counter = 0;

GetNext の指定変更フック

//// Note that the Iterator hooks are NOT called when we override the

getnext function// Initialization done in After Select Entries hook

var nxt = list.item ( counter );

if ( nxt != null ) {var ch = nxt.getFirstChild();while ( ch != null ) {

var child = ch.getFirstChild();while (child != null ) {

// Use the grandchild’s value if it exist, to be able toread multivalue attributes

grandchild = child.getFirstChild();if (grandchild != null)

nodeValue = grandchild.getNodeValue();else nodeValue = child.getNodeValue();

// Ignore strings containing newlines, they are just fillersif (nodeValue != null && nodeValue.indexOf(’¥n’)

== -1) {work.addAttributeValue ( ch.getNodeName(), nodeValue );

}child = child.getNextSibling();

}ch = ch.getNextSibling();}

result.setStatus (1); // Not end of input yetcounter++;} else {result.setStatus (0); // Signal end of input}

前記の例では、以下のような項目を含むファイルが解析されます。

<DocRoot><Entry>

<firstName>John</firstName><lastName>Doe</lastName><title>Engineer</title>

</Entry><Entry>

<firstName>Al</firstName>


<lastName">Bundy</lastName><title">Shoe salesman</title>

</Entry></DocRoot>

その代わりに、入力が以下のようなものであったとします。

<DocRoot><Entry>

<field name="firstName">John</field><field name="lastName">Doe</field><field name="title">Engineer</field>

</Entry><Entry>

<field name="firstName">Al</field><field name="lastName">Bundy</field><field name="title">Shoe salesman</field>

</Entry></DocRoot>

この場合は、属性名はフィールド・ノードの属性から検索できるので、GetNext の指定変更フックの中で次のようなコードを使用します。

var nxt = list.item ( counter );

if ( nxt != null ) {var ch = nxt.getFirstChild();while ( ch != null ) {if(String(ch.getNodeName()) == "field") {attrName = ch.getAttributes().item(0).getNodeValue();nodeValue = ch.getFirstChild().getNodeValue();work.addAttributeValue ( attrName, nodeValue );}ch = ch.getNextSibling();}

result.setStatus (1); // Not end of input yetcounter++;} else {result.setStatus (0); // Signal end of input}

例のパッケージでは、GetNext の指定変更フックおよび追加の指定変更フックを使用して、深度が 2 レベルを超える XML を読み取れるように基本 XML パーサーの機能を拡張する方法を示しています。

例ご使用の IBM Tivoli Directory Integrator システムのroot_directory/examples/xmlparser ディレクトリーにあります。

関連情報160ページの『SOAP パーサー』, 151ページの『DSML パーサー』

ユーザー定義パーサーIBM Tivoli Directory Integrator にすでに組み込まれているパーサーに加えて、ユーザーは独自のパーサーを作成し、それらをシステムに追加することができます。


ユーザー定義パーサーの一例として、正規表現の解析が可能なパーサーが Examples

ディレクトリーに提供されています。ご使用の IBM Tivoli Directory Integrator システムの root_directory/examples/regexp_parser ディレクトリーにあります。この例は、Java で作成されました。

ユーザー定義パーサーのもう一つの例は、root_directory/examples/script_parser にあります。これは、スクリプトを使用してパーサーを作成する方法を示しています。この例の詳細については、「IBM Tivoli Directory Integrator 5.2 ユーザーズ・ガイド」の『JavaScript Parser』を参照してください。


第 5 章スクリプト言語

IBM Tivoli Directory Integrator は、さまざまなスクリプト言語をサポートしています。これらの言語に関する情報の一部は 149ページの『第 4 章パーサー』でも紹介しましたが、そのほとんどは、パーサーを作成するためにどのような関数が必要かという点に関するものでした。しかし、特定のスクリプト言語を使用するために、IBM Tivoli Directory Integrator はその言語をインストールします (その言語が存在する場合)。

AssemblyLine 自体の中で使用できるのは 1 つのスクリプト言語だけですが、コネクターの中ではサポートされるどの言語でも使用できます (ただし、コンポーネント内でサポートされる言語はありません)。AssemblyLine をセットアップするときは、スクリプト言語を選択し、その言語のみを使用します。スクリプト言語を変更しても、既存のコードは変更されません。このことは、IBM Tivoli Directory

Integrator がユーザーの代わりに作成するコード (単純な属性マッピングなど) でも同様です。

IBM Tivoli Directory Integrator 製品の内部では、新しいスクリプト言語を組み込むために Beans Scripting Framework (BSF) が使用されます。BSF は Windows

Scripting Hosts (WSH) をサポートしており、一部のスクリプト言語は WSH を介してサポートされます。このような言語の例としては、Visual Basic と Perl があります。 WSH を介してサポートされるスクリプト言語は、Windows プラットフォームでのみ使用できます。

BSF ベースのスクリプト言語提供されているデフォルトの言語は JavaScript です。ほかには特別の要件はありません。詳細については、「IBM Tivoli Directory Integrator 5.2 ユーザーズ・ガイド」の『Comparing JavaScript strings』を参照してください。

WSH ベースのスクリプト言語以下に示すのは、IBM Tivoli Directory Integrator で使用可能な WSH ベースのスクリプト言語です。

v Perl

v Visual Basic

BeanShellBeanShell の詳細については、http://www.beanshell.org/ を参照してください。

注: BeanShell は、標準の IBM Tivoli Directory Integrator では認定されておらず、組み込まれてもいません。この IBM Tivoli Directory Integrator リリースでは、BeanShell はサポートされていません。


PerlScriptPerlScript は、ActiveX スクリプト・ホストで Perl を使用できるようにするActiveX スクリプト・エンジンです。 PerlScript は、ActivePerl インストーラーを起動したときに、オプションとしてインストールできるコンポーネントの 1 つです。PerlScript を使用するには、ActivePerl をインストールしてあることが必要です。

Perl パーサーが稼働できるようにするには、Windows Scripting Host (WSH) エンジンをサポートする PerlScript のバージョンが必要です。ActivePerl のみが検査済みです。 ActivePerl には、http://www.activestate.com/ からで無料でアクセスできます。

また、WSH は Windows 2000 プラットフォームでのみ稼働可能であり、現時点では、UNIX サーバーからは Perl パーサーは実行できないという点にも注意してください。

注: http://www.activestate.com/ から入手できる無料の ActivePerl は、読者の便宜のために紹介しているにすぎません。 IBM はこのサイトから入手できるコードをサポートしてはいません。また、この種のコードの継続的な可用性についても、この種のコードを使用した場合の結果についても、責任を負いません。

PerlScript からは標準 Java オブジェクトにアクセスできるので、汎用 Java 文書を使用できます。PerlScript では Java オブジェクト JavaObject には $JavaObject としてアクセスでき、$JavaObject->Method() を使用して JavaObject.Method() にアクセスできます。

例えば、イテレーター・モードのコネクターでは、inp オブジェクトを使用して入力動作が行われます。したがって、

$_ = $inp->readLine();

は、入力ストリームの次の行を $_ に割り当てます。

コネクターの属性は、(entry) 属性により設定されるか読み取られます。

$entry->setAttribute("Number", $number);

これは、自己選択コネクター属性 Number を、PerlScript 内部スカラー $numberに設定します。

パーサーを作成するときには、通常、サブルーチン readEntry および writeEntryを作成する必要があります。これらは入出力用に呼び出されるサブルーチンです。

以下の例は、属性 (″Multi1″ および ″Multi2″) の中に複数の値 (″foo″ および″bar″) を作成する方法を示しています。

# Multi1 属性を作成 ( 173ページの『項目オブジェクト』を参照)

$entry->setAttribute("Multi1", "foo");

# この属性に別の値を追加 ( 171ページの『属性オブジェクト』を参照)

$attr = $entry->getAttribute("Multi1");$attr ->addValue("bar");

以下の例は、属性を作成する別の方法を示しています。


# ″Multi2″ 属性を作成 (存在していない場合)

$entry->addAttributeValue("Multi2", "foo");

# この属性に別の値を追加

$entry->addAttributeValue("Multi2", "bar");

PerlScript の例以下の 2 つのプロシージャーは、単に 1 つの行全体の読み取りおよび書き込みを行います。さらに高度なスクリプトでは、$_ オブジェクトを取り扱うことができます。

この例では、Line という名前のコネクター属性があり、パーサーの作成に必要なwriteEntry および readEntry を作成してあるとします ( 157ページの『スクリプト・パーサー』を参照)。

sub writeEntry{$result = $entry->getString("Line");$out->write ( $result );

}

sub readEntry{$_ = $inp->readLine();$entry->setAttribute("Line", $_);

}

例ご使用の IBM Tivoli Directory Integrator システムの root_directory/examples/perl ディレクトリーにあります。

VBScriptシステム・オブジェクトを取り扱うときは、VB で書かれた Dim (Dimension) をVBScript で書き直す必要があります (次のリストを参照)。変数に関する Dim 指定は受け入れられます。

VB

Dim x as Excel.ApplicationSet x = CreateObject ("Excel.Application")

VBScript

Set x = CreateObject ("Excel.Application")

JavaScriptJavaScript を使用する際には、考慮すべき問題がいくつかあります。下記を参照してください。

v 「IBM Tivoli Directory Integrator 5.2 ユーザーズ・ガイド」の『Comparing

JavaScript strings』

v 「IBM Tivoli Directory Integrator 5.2 ユーザーズ・ガイド」の『JavaScript string

methods』

v 170ページの『Java および JavaScript』

第 5 章スクリプト言語 169

Java および JavaScriptJavaScript では Java オブジェクトにアクセスできます。 IBM Tivoli Directory

Integrator の内部オブジェクトはすべて Java オブジェクトなので、これは非常に便利です。

ただし、JavaScript で予約語または演算子として使用されている語を名前とするメソッドを持つ Java オブジェクトがあると、問題が生じます。このような場合、JavaScript インタープリターは、Java メソッドを呼び出さずに、予約語を処理しようとします。

このようなケースの一例として、delete メソッドを持つ java.io.File クラスが挙げられます。delete は JavaScript の演算子でもあります。したがって、以下は失敗します。

var myFile = java.io.File("file.txt"); myFile.delete();

代わりに、以下のいずれかを実行できます。

v myFile[’delete’]();

これは、Java メソッドには配列エレメントとしてアクセスできるという事実を利用しています。

v system.deleteFile("file.txt");

これは、システム・ライブラリーに deleteFile メソッドがあることを利用してうまく機能します。


第 6 章オブジェクト

この章で取り上げるオブジェクトは、ご使用のシステムの root_directory¥docs¥api

ディレクトリー内にある JavaDocs の中で、詳細に説明されています。使用可能なメソッドについては、JavaDocs を参照してください。

AssemblyLine コネクター・オブジェクトAssemblyLine コネクター・オブジェクトは、ロー・コネクターへの追加機能を提供するラッパーです。ロー・コネクターには、AssemblyLine コネクターからコネクター・オブジェクトとしてアクセスできます。

AssemblyLine コネクターは、AssemblyLine 内に定義するフック関数を呼び出すコネクターであると同時に、属性マッピングを行うコネクターでもあります。AssemblyLine 内の各 AssemblyLine コネクターに名前を付けると、コネクターは自動的にその名前でスクリプト内で使用できるようになります。ある AssemblyLine

コネクターに ldap という名前を付けると、そのコネクターはスクリプト・オブジェクト名としても使用されます。コネクターには、必ず、選択したスクリプト言語と互換性のある方法で命名するようにしてください。通常は、空白文字および特殊文字は使用しないでください。

AssemblyLine コネクターは、com.ibm.di.server.AssemblyLineComponent で説明されているメソッドおよびプロパティーを持っています。

属性オブジェクト通常、属性オブジェクトは項目オブジェクトに含まれています。属性は、関連の値を持つ名前付きオブジェクトです。属性の各値は、それぞれ何らかのタイプの 1 つの Java オブジェクトに対応します。属性名に大文字小文字の区別はありませんが、名前の一部にスラッシュ (/) を含めることはできません。一部のコネクター (例えばデータベースにアクセスするものなど) では、ほかにも無効と見なされる文字があるということを忘れないでください。できれば、属性名には英数字のみを使用してください。

属性マップにより属性にコネクターの値が移植された場合は、その値は、コネクターが提供した値と同じデータ・タイプになります。

詳細については、インストール・パッケージに含まれている Javadocs の資料を参照してください (com.ibm.di.entry.Attribute クラス)。

例

新規の属性オブジェクトの作成var attr = system.newAttribute("AttributeName");


この例では、AttributeName という名前の属性オブジェクトが作成され、この属性に attr 変数が割り当てられます。初期作成時には、この属性には値はないという点に注意してください。 attr 変数を使用して、新規に作成したこの属性にアクセスし、操作することができます。

属性への値の追加attr.addValue("value 1");

attr.addValue("value 2");

この例では、attr 属性にストリング値 ″value 1″ および ″value 2″ が追加され、その結果複数値属性が作成されます。addValue(obj) を連続して呼び出すことにより、同じ順序で属性に値が追加されます。

属性の値のスキャンvar values = attr.getValues();for (i=0; i<values.length; i++) {

task.logmsg("Value " + i + " —> " + values[i]);}

この例では、単一値か複数値かに関係なく、属性オブジェクトが処理されます。単一値属性と複数値属性の間には、実質的な違いはありません。すべての属性は、0

個、1 個、または複数の値を持つことができます。したがって、単一値属性は、単に値の少ない複数値属性であると言えます。

関連情報173ページの『項目オブジェクト』

ロー・コネクター・オブジェクトロー・コネクター・オブジェクトを取得するには、ロー・コネクターを明示的にロードするか (system.loadConnector)、または名前付きの AssemblyLine

Connectors.Connector を検索します (myConnector.connector)。通常、AssemblyLine 内のスクリプトを書くときは、他のメソッドのセットにアクセスできる AssemblyLine

コネクター・オブジェクトを使用します。

ロー・コネクターについては、Javadocs の中のコネクターに関するセクションで詳しく説明されています。詳細については、インストール・パッケージに含まれている Javadocs の資料を参照してください (com.ibm.di.connector.Connector)。

メソッドよく使用されるメソッドには、以下のものがあります。

getNextEntry()次の入力項目を戻します。

putEntry ( entry )entry を追加または挿入します。

modEntry ( entry, search )search に指定されている項目を entry の内容で変更します。


deleteEntry ( entry, search )search で識別される entry を削除します。

findEntry ( search )search で識別される項目を検索します。該当項目が見つからない場合は、NULL 値が戻されます。

findEntry ( attribute, value )attribute equals value の条件を使用して検索を行い、見つかった項目を戻します。該当項目が見つからない場合、または複数の該当項目が見つかった場合は、NULL 値が戻されます。

項目オブジェクト項目オブジェクトは、AssemblyLine および EventHandler により使用されます。項目オブジェクトは、属性とプロパティーを持つ Java オブジェクトです。属性には不特定数の値が含まれます。プロパティーには単一の値が含まれます。詳細については、インストール・パッケージに含まれている Javadocs の資料を参照してください (com.ibm.di.entry.Entry)。

使用できるすべてのメソッドのリスト (パラメーターおよび戻り値を含む) については、インストール・パッケージに含まれている Javadocs の資料を参照してください。

スクリプトの中で使用できるグローバル項目インスタンスconn AssemblyLine 内のコネクターに含まれるローカル・ストレージ・オブジェ

クト。このオブジェクトは、コネクターの存続期間のうちの属性マッピング・フェーズの間のみ存在します。「IBM Tivoli Directory Integrator 5.2

ユーザーズ・ガイド」の『Attribute Mapping』を参照してください。

作業（work）AssemblyLine のデータ・コンテナー・オブジェクト。したがって、すべてのコネクター内で、AssemblyLine からこのオブジェクトにアクセスできます。

イベント（event）イベントオブジェクトは、EventHandler 内部のスクリプトを書く場合の作業オブジェクトです。これは、属性マッピングのときの conn オブジェクトに似ています。

現在の（current）更新モードおよび削除モードのコネクターでのみ使用できます。このオブジェクトには、追加操作か変更操作かを判別するためにコネクターがデータ・ソースから読み取る項目が格納されます。

エラー (error)この項目オブジェクトはコネクターのフック内で使用できますが、それは名前が Fail で終わっているフックのみです。エラー・オブジェクトは、以下の属性内にエラー状況情報を保持します。

第 6 章オブジェクト 173

status (java.lang.String)例外がまったくスローされない場合は OK (この場合、これがエラーの唯一の属性になります)。例外がスローされる場合は Fail で、以下の属性も使用できます。

exception (java.lang.Exception)スローされる java.lang.Exception (またはその後続クラス)

オブジェクト

class (java.lang.String)例外クラス (java.lang.Exception またはその後続の一部)

の名前

message (java.lang.String)例外のエラー・メッセージ

operation (java.lang.String)コネクターの操作タイプ (例えば、AddOnly、更新、ルックアップ、イテレーターなど)

connectorname (java.lang.String)フックが呼び出されるコネクターの名前

関連情報171ページの『属性オブジェクト』

FTP オブジェクトFTP オブジェクトは、スクリプト可能オブジェクトとして使用できます。このオブジェクトは、FTP クライアント・コネクターから必要な機能が得られない場合に役立ちます。 JavaDocs の中の com.ibm.di.protocols.FTPBean に関する詳細説明を参照してください。

例var ftp = system.getFTP();

if ( ! ftp.connect ("ftpserver", "username","password") )

{task.logsmg ("Connect failed: " +ftp.getLastError());

}

ftp.cd ("/home/user1");var list = ftp.dir();

while ( list.next() ){if (list.getType() == 1)task.logmsg ("Directory: " +list.getName());

elsetask.logmsg ("File: " + list.getName());

}


ftp.setBinary();ftp.get ("remotefile", "c:¥¥localfile");ftp.put ("c:¥¥localfile", "remotefile");

メイン・オブジェクトメイン・オブジェクトは、トップレベル・スレッドです (JavaDocs の中の Interface

RSInterface を参照)。このオブジェクトには、AssemblyLine の動作を操作するためのメソッドがあります。最も一般的なメソッドには、以下のものがあります。

void dump(entry)項目の内容をコンソールにダンプします。

void logmsg (String msg)メッセージを、コンソールのほかシステム・ログ・ファイルに書き込みます。

startAL ( name, initial-work-entry )、startAL ( name,runtime-provided-Connector )、startAL ( name, initial-work-entry,runtime-provided-Connector )、startAL ( name, java.util.Vector )

name パラメーターに指定されている AssemblyLine を開始します。「IBM

Tivoli Directory Integrator 5.2 ユーザーズ・ガイド」の『IBM Tivoli

Directory Integrator concepts - The AssemblyLine』を参照してください。

検索 (基準) オブジェクト検索 (基準)オブジェクトは、総称検索基準を指定するために、AssemblyLine およびコネクターで使用されます。JavaDocs の中の com.ibm.di.server.SearchCriteria を参照してください。検索基準をどのように解釈してどのようにコネクター固有の検索に変換するかは、コネクターによって異なります。検索基準は非常に単純な多値オブジェクトであり、各値は、属性、オペランド、および値を指定します。

オペランド検索基準オブジェクトで使用するために定義されているオペランドには、以下のものがあります。

= 等しい

~ 含む

^ これで始まる

$ これで終わる

! 等しくない

例for ( i = 0; i < search.size(); i++ ) {var sc = search.getCriteria ( i );task.logmsg ( sc.name + sc.match + sc.value );}

第 6 章オブジェクト 175

shellCommand オブジェクトshellCommand オブジェクトには、コマンド行プロセスの結果が入ります。

Microsoft Windows プラットフォームでは、シェル・コマンドは開始されますが、そこから出力または状況を取得することはできません。使用可能なメソッドについては、JavaDocs の中の com.ibm.di.function.ExecuteCommand を参照してください。

例:

var cmd = system.shellCommand ("/bin/ls -l");if ( cmd.failed() ) {task.logmsg ( "Command failed: " + cmd.getError());} else {task.logmsg ( cmd.getOutputBuffer() );}

状況オブジェクト状況オブジェクトには、AssemblyLine のコネクターおよびエラー・コードに関する情報が入ります。これは task.getStats() の同義語です。

システム・オブジェクトシステム・オブジェクトは、すべてのスクリプト記述コンテキストの中でスクリプト可能オブジェクトとして使用できるもので、基本関数セットを提供します。Java

オブジェクトは com.ibm.di.function.UserFunctions ですが、スクリプト・オブジェクト system にリンクします。すべてのメソッドのリストは、Javadocs にあります。

タスク・オブジェクトタスク・オブジェクトは、com.ibm.di.server.TaskInterface をインプリメントするクラスのインスタンスで、現行の実行スレッドを表します。

v AssemblyLine の場合は、これは AssemblyLine スレッドで、これによりAssemblyLine 固有の情報およびメソッドにアクセスできます。JavaDocs の中のcom.ibm.di.server.AssemblyLine クラスを参照してください。

v EventHandler の場合は、これは EventHandler スレッドで、これによりEventHandler 固有の情報およびメソッドにアクセスできます。JavaDocs の中のcom.ibm.di.eventhandler.Switchboard クラスを参照してください。


付録 A. パスワード同期プラグイン

パスワード同期プラグインの README ファイルは、pwsync_install_directory ディレクトリーにあります。これらのプラグインは個別にインストール可能なエンティティーであり、README ファイルはそれぞれのインストール・ディレクトリーに格納されます。以下のプラグインがあります。

IBM Directory Server Password Synchronizer の README ファイル

v pwsync_install_directory¥IDS¥readme_idspwsync_ismp.htm

v pwsync_install_directory¥IDS¥readme_ldapstore_ismp.htm

v pwsync_install_directory¥IDS¥readme_mqepwstore_ismp.htm

IBM Tivoli Directory Server Password Synchronizer は、IBM Tivoli Directory

Server 5.2 の LDAP パスワードへの変更をインターセプトします。

IBM Tivoli Directory Server のパスワードは、userPassword LDAP 属性に保管されます。パスワード・シンクロナイザーは、userPassword LDAP

属性の更新をインターセプトします。

IBM Tivoli Directory Server パスワード・シンクロナイザーは、あらゆるオブジェクト・クラスの項目の userPassword 属性への変更をインターセプトします。

以下のタイプの項目変更に対して、パスワード更新がインターセプトされます。

v ディレクトリーに新規項目が追加され、項目に userPassword 属性が含まれる場合。

v 既存の項目が変更され、変更された属性の 1 つが userPassword 属性である場合。以下のケースが挙げられます。

– userPassword 属性が追加される (例えば、それまで項目にuserPassword 属性が存在しなかった場合)

– userPassword 属性が変更される (例えば、項目にこの属性が存在し、その値が新たに変更された場合)

– userPassword 属性が項目から削除される

Windows 用 IBM Tivoli Directory Integrator パスワード・シンクロナイザー・プラグインの README ファイル

v pwsync_install_directory¥IDI¥readme_winpwsync_ismp.htm

v pwsync_install_directory¥IDI¥readme_ldapstore_ismp.htm

v pwsync_install_directory¥IDI¥readme_mqepwstore_ismp.htm

Windows 用パスワード・シンクロナイザーは、Windows NT、Windows

2000、および Windows XP オペレーティング・システムにおけるユーザー・アカウントのパスワード変更をインターセプトします。

以下の場合に、パスワード変更がインターセプトされます。


v ユーザーが Windows ユーザー・インターフェースを使用してパスワードを変更する場合。

v 管理者が Windows 管理ユーザー・インターフェースを使用してユーザーのパスワードを変更する場合。

v LDAP を介して Active Directory へのパスワード変更要求が行われる場合。

Sun ONE Directory Server パスワード・シンクロナイザーの README ファイル

v pwsync_install_directory¥SunOne¥readme_sundspwsync.htm

v pwsync_install_directory¥SunOne¥readme_ldapstore_ismp.htm

v pwsync_install_directory¥SunOne¥readme_mqepwstore_ismp.htm

Sun ONE Directory Server パスワード・シンクロナイザーは、Sun ONE

Directory Server の LDAP パスワードへの変更をインターセプトします。

Sun ONE Directory Server のパスワードは、userPassword LDAP 属性に保管されます。パスワード・シンクロナイザーは、userPassword LDAP

属性の更新をインターセプトします。

Sun ONE Directory Server パスワード・シンクロナイザーは、あらゆるオブジェクト・クラスの項目の userPassword 属性への変更をインターセプトします。

以下のタイプの項目変更に対して、パスワード更新がインターセプトされます。

v ディレクトリーに新規項目が追加され、項目に userPassword 属性が含まれる場合。

v 既存の項目が変更され、変更された属性の 1 つが userPassword 属性である場合。以下のケースが挙げられます。

– userPassword 属性が追加される (例えば、それまで項目にuserPassword 属性が存在しなかった場合)

– userPassword 属性が変更される (例えば、項目にこの属性が存在し、その値が新たに変更された場合)

– userPassword 属性が項目から削除される

注:

1. 項目に userPassword 属性が含まれる場合でも、Sun ONE Directory

Server パスワード・シンクロナイザーは、項目の削除のインターセプトは行いません。

2. Sun ONE Directory Server の userPassword 属性は、多値属性です。ユーザーは複数のパスワードを持つ場合があります。Sun ONE Directory

Server パスワード・シンクロナイザーは、あらゆるパスワード値のあらゆる変更をインターセプトし、報告します。

Domino HTTP パスワード・シンクロナイザーの README ファイル

v pwsync_install_directory¥readme_dominopwsync_ismp.htm

v pwsync_install_directory¥readme_ldapstore_ismp.htm


v pwsync_install_directory¥readme_mqepwstore_ismp.htm

Domino HTTP パスワード・シンクロナイザーは、Notes ユーザーのインターネット・パスワード (HTTP パスワードとも言われる) の変更をインターセプトします。

以下のタイプのパスワード変更がインターセプトされます。

管理パスワードのリセット必要な権限を持つユーザー (通常は管理者) は、旧パスワードを求められることなく、以下のようにして自身または別のユーザーのパスワードを変更できます。

v Lotus Domino Administrator クライアントを使用して、ユーザーのユーザー文書の「インターネットパスワード」フィールドを編集することにより、HTTP パスワードを変更します。

v Web ブラウザー・インターフェースを使用して、ユーザーのユーザー文書の「インターネットパスワード」フィールドを編集することにより、HTTP パスワードを変更します。

通常のユーザー・パスワード変更ユーザーが自身のパスワードを変更する場合は、旧パスワードを求められます。

v ユーザーは、domcfg.nsf (Domino Web サーバー設定) データベースの「パスワードの変更」フォームを使用して、Web ブラウザーから自身のパスワードを変更します。

v ユーザーは、iNotes™ から自身のパスワードを変更します。

これらの新規プラグインと IBM Tivoli Directory Integrator との関係について説明している、高レベルの README ファイルがあります。「Password Synchronization

for IBM Tivoli Directory Integrator 5.2」 (readme_password_sync_ismp.htm) を参照してください。

詳細については、/plugins ディレクトリー (root_directory/plugins) を参照してください。

付録 A. パスワード同期プラグイン 179

付録 B. AssemblyLine およびコネクター・モードのフローチャート

以下に示すのは、AssemblyLine およびコネクター・モードのフローチャートのコンポーネントに関する凡例です。

黒の矢印は通常のフローを示します。

先が分かれた赤の矢印は、エラーまたは例外のフローを示します。エラーは、スクリプト化されたフロー・コンポーネントと、IBM Tivoli Directory Integrator 操作のどちらでも発生します。

フロー端点シンボルは、コネクター・フロー・チャートのフローの始めまたは終わりを示します。このシンボルに含まれているテキストは、その時点でのシステムの状態および動作に関する情報を提供します。

このボックスはスクリプト化されたフロー・コンポーネントを表すもので、属性マップとフックの両方に使用されます。

注: フックが使用可能にされている場合は、制御はそのフック内のスクリプトに渡されます。フックが使用可能にされていない場合は、フローは、フックを実行せずに、フックを飛び越えて続行されます。

このボックスは必須のフックを表します。フックには、スクリプトが何も入っていなくても、必須であり使用可能にしなければならないものがいくつかあります。必須のフックが使用可能にされていない場合は、フローがこのポイントに達した時点でエラーと見なされ、デフォルトによりエラー処理プロセスに制御が渡されます。


このボックスは、IBM Tivoli Directory Integrator の操作を表します (これらの操作は、ロー・コネクター・オブジェクト内で関数として使用できるものです)。

注: IBM Tivoli Directory Integrator の操作は、エラー・フローになる場合もあります。

この図は決定コンポーネントを表します。決定コンポーネントは、フロー内の現時点での状態情報に応じた、コネクター・プロセスの論理ブランチを表します。一般に、Yes ブランチは決定コンポーネントの右側に示され、No ブランチは下向きのフローになります。この規則に従っていない決定コンポーネントの場合は、フロー・チャートの中で該当のブランチ・ラベルが太字のテキストで示されます。

黄色の台形は、どこかで説明されているフローを示します (例えば、この文書の別のページ)。オプションの丸い青のボックスには、説明が入ります (この例の場合では、指定されたフローは、AssemblyLine 内のイテレーター・モードではない各コネクターのものです)。

この継続シンボルは、1 つ以上のモードに共通の別のページにフローが続くことを示します。参照先のページは、このシンボルの下のラベルに示されます。

この継続シンボルは、参照先のページが同じコネクター・モードの一部である場合に使用されます。参照先のページは、このシンボルの下のラベルに示されます。

AssemblyLine フロー以下のダイアグラムは、メイン・スレッドから開始される AssemblyLine フローを示しています。


AssemblyLine フローは、以下のとおりです。

1. IBM Tivoli Directory Integrator の AL 構成のロード操作を実行します。

2. IBM Tivoli Directory Integrator の TCB の処理操作を実行します。

付録 B. AssemblyLine およびコネクター・モードのフローチャート 183

3. スクリプト化されたフロー・コンポーネント、グローバル・プロローグに進みます。

4. スクリプト化されたフロー・コンポーネント、プロローグ: 初期化前に進みます。

5. コネクターを初期化します。 185ページの『コネクターの初期化』に進みます。

注: このコネクターは、受動または使用可能のいずれかです。コネクター・フローを初期化します (例えば、更新、AddOnly、Call/Reply、ルックアップ、削除など)。

6. スクリプト化されたフロー・コンポーネント、プロローグ: 初期化後に進みます。

7. 決定コンポーネント: 初期作業項目?

a. はいの場合は、非イテレーターの各コネクターに対する使用可能コネクター・フローを続行します。

1) 作業項目のゼロ設定操作を実行します。

2) イテレーター・コネクター・フローを続行します。

b. いいえの場合は、決定コンポーネント: 使用可能イテレーターの追加? に進みます。

1) はいの場合は、次のイテレーターのアクティブ化操作を実行します。

a) イテレーター・コネクター・フローを続行します。

b) 決定コンポーネント: getNext は成功したか? に進みます。

i. はいの場合は、この章にあるモード固有のフロー・チャートを参照してください。

ii. いいえの場合は、決定コンポーネント: 使用可能イテレーターの追加? (7b) に戻ります。

2) いいえの場合は続行します。

8. スクリプト化されたフロー・コンポーネント、エピローグ: クローズ前に進みます。

9. 各コネクターのフローをクローズします。 186ページの『クローズ・フロー』に進みます。

10. スクリプト化されたフロー・コンポーネント、エピローグ: クローズ後に進みます。



コネクターの初期化

1. フロー端点: スクリプト化されたフロー・コンポーネント、プロローグ: 初期化前から続きます。

2. IBM Tivoli Directory Integrator のコネクター初期化操作を実行します。

3. 決定コンポーネント: コネクターはイテレーター・モードか?

a. いいえの場合は、7 (186ページ)に進みます。

b. はいの場合は続行します。

4. スクリプト化されたフロー・コンポーネント、プロローグ: 選択前に進みます。


5. IBM Tivoli Directory Integrator の selectEntries() 呼び出し操作を実行します。

6. スクリプト化されたフロー・コンポーネント、プロローグ: 選択後に進みます。

7. スクリプト化されたフロー・コンポーネント、プロローグ: 初期化後に進みます。

8. AssemblyLine フローに戻ります (6 (184ページ))。

クローズ・フロー1. フロー端点: スクリプト化されたフロー・コンポーネント、エピローグ: クローズ前から続きます。

2. IBM Tivoli Directory Integrator のコネクターのクローズ操作を実行します。

3. スクリプト化されたフロー・コンポーネント、エピローグ: クローズ後に進みます。

4. AssemblyLine フローに戻ります (10 (184ページ))。

AddOnly モード他の場合と同様に、作業オブジェクトは、現在 AssemblyLine 内にある属性へのアクセスを提供します。

conn オブジェクトに保管されている情報は、追加操作により、データ・ソースに書き込まれます。


AddOnly フローは、以下のとおりです。

1. フロー端点: 前のイテレーターからの続き、または AssemblyLine の開始。


2. スクリプト化されたフロー・コンポーネント、実行前に進みます。このスクリプト化されたフロー・コンポーネントは、作業オブジェクトにアクセスします。

a. エラーの場合は、エラー時フロー端点に進みます。

b. 成功の場合は続行します。

3. 決定コンポーネント: AddOnly の指定変更を使用可能にする?

a. はいの場合は、スクリプト化されたフロー・コンポーネント、AddOnly の指定変更スクリプトに進みます。このスクリプト化されたフロー・コンポーネントは、作業オブジェクトにアクセスします。

1) エラーの場合は、エラー時フロー端点に進みます。

2) 成功の場合は、成功時フロー端点に進みます。

b. いいえの場合は続行します。

4. スクリプト化されたフロー・コンポーネント、属性マップに進みます。このスクリプト化されたフロー・コンポーネントは、work および conn オブジェクトにアクセスします。



5. スクリプト化されたフロー・コンポーネント、追加前に進みます。このスクリプト化されたフロー・コンポーネントは、work および conn オブジェクトにアクセスします。



6. IBM Tivoli Directory Integrator の追加操作を実行します。



7. スクリプト化されたフロー・コンポーネント、追加後に進みます。このスクリプト化されたフロー・コンポーネントは、work および conn オブジェクトにアクセスします。


b. 成功の場合は、成功時フロー端点に進みます。

Call/Reply モード他の場合と同様に、作業オブジェクトは、現在 AssemblyLine 内にある属性へのアクセスを提供します。

このモードでは、conn オブジェクトに保管される情報は、他のモードの場合と少々異なります。

注: Call/Reply モードでは、conn オブジェクトは 2 つの役割を果たします。

v 出力属性マップ内で定義されていて、Call/Reply 操作により伝送される呼び出し属性およびパラメーターを保管する。

v Call/Reply 操作の後で入力属性マップによりアクセスされる戻り属性およびパラメーターを受信する。


Call/Reply フローは、以下のとおりです。






3. 決定コンポーネント: Call/Reply の指定変更を使用可能にする?

a. はいの場合は、スクリプト化されたフロー・コンポーネント、Call/Reply の指定変更スクリプトに進みます。このスクリプト化されたフロー・コンポーネントは、work および conn オブジェクトにアクセスします。




4. スクリプト化されたフロー・コンポーネント、出力属性マップに進みます。このスクリプト化されたフロー・コンポーネントは、work および conn オブジェクトにアクセスします。



5. スクリプト化されたフロー・コンポーネント、Call/Reply 前に進みます。このスクリプト化されたフロー・コンポーネントは、work および conn オブジェクトにアクセスします。



6. IBM Tivoli Directory Integrator の Call/Reply 操作を実行します。



7. スクリプト化されたフロー・コンポーネント、Call/Reply 後に進みます。このスクリプト化されたフロー・コンポーネントは、work および conn オブジェクトにアクセスします。詳細については、188 ページを参照してください。



8. スクリプト化されたフロー・コンポーネント、入力属性マップに進みます。このスクリプト化されたフロー・コンポーネントは、work および conn オブジェクトにアクセスします。



削除モード他の場合と同様に、作業オブジェクトは、現在 AssemblyLine 内にある属性へのアクセスを提供します。

リンク基準作成操作が終わると、search と呼ばれるスクリプト・オブジェクトが使用可能になり、これを使用してこの情報にアクセスできます (例えば指定変更フックの中で使用します)。


リンク基準と一致するレコードまたは項目 (これから削除されるもの) は、conn オブジェクトとしてスクリプト用に使用でき、属性マッピングが実行されて、AssemblyLine は削除対象項目の属性を使用できるようになります。

複数項目時リンク基準と一致するレコードまたは項目が複数検出された場合は、複数項目時フックも使用可能にされている必要があります。そうでない場合、エラーが発生します。

検出されたレコードまたは項目には、次の 2 つのコネクター関数のいずれかを使用してアクセスできます。

v getFirstDuplicateEntry()

v getNextDuplicateEntry()

どちらの関数も項目オブジェクトを戻し、このオブジェクトを使用してコネクターのデータ・アクセス・メソッド (update()、delete() など) を呼び出すことができます。

削除操作を続行したいときは、次のコネクター関数を使用して現行項目を設定する必要があります。

myConnector.setCurrent( myEntry )

現行項目を設定しなかった場合は、プロセスは以後のこのモード固有のフローをバイパスし、成功時に進みます。

注: 複数の項目が操作されるときは、データ・ソース (そして関連のコネクター) の動作が異なります。前に述べたように特定項目を選択した場合でも、削除フローを続行することはお勧めできません。続行すると、エラーが起きるか、複数の項目に対してこの削除操作が行われるおそれがあります。


削除フローは、以下のとおりです。






3. 決定コンポーネント: 削除の指定変更を使用可能にする?

a. はいの場合は、IBM Tivoli Directory Integrator のリンク基準の作成操作を実行します。


2) 成功の場合は、スクリプト化されたフロー・コンポーネント、削除の指定変更スクリプトに進みます。このスクリプト化されたフロー・コンポーネントは、作業オブジェクトにアクセスします。

a) エラーの場合は、エラー時フロー端点に進みます。

b) 成功の場合は、成功時フロー端点に進みます。


4. スクリプト化されたフロー・コンポーネント、ルックアップ前に進みます。このスクリプト化されたフロー・コンポーネントは、作業オブジェクトにアクセスします。



5. IBM Tivoli Directory Integrator のリンク基準の作成操作を実行します。



6. IBM Tivoli Directory Integrator のルックアップ操作を実行します。



7. 決定コンポーネント: 複数の項目がある?

a. はいの場合は、必須の複数項目時フックに進みます。


2) 成功の場合は、決定コンポーネント: 現在の項目を設定? に進みます。

a) いいえの場合は、成功時フロー端点に進みます。

b) はいの場合は続行します。


8. 決定コンポーネント: 一致がある?

a. いいえの場合は、必須の一致なしの場合フックに進みます。このスクリプト化されたフロー・コンポーネントは、作業オブジェクトにアクセスします。




9. スクリプト化されたフロー・コンポーネント、ルックアップ後に進みます。







11. スクリプト化されたフロー・コンポーネント、削除前に進みます。このスクリプト化されたフロー・コンポーネントは、work および conn オブジェクトにアクセスします。



12. IBM Tivoli Directory Integrator の削除操作を実行します。



13. スクリプト化されたフロー・コンポーネント、削除後に進みます。このスクリプト化されたフロー・コンポーネントは、work および conn オブジェクトにアクセスします。



イテレーター・モード他の場合と同様に、作業オブジェクトは、現在 AssemblyLine 内にある属性へのアクセスを提供します。

各 GetNext 操作で読み込まれたデータは、conn オブジェクトに保管されます。

注: イテレーター・モードのコネクターが、実行開始の時点で有効な work オブジェクトが存在すること (例えば、同じ AssemblyLine 内でこのイテレーターより前に別のイテレーターがあること)、または呼び出し元のプロセスまたはシステムから初期作業項目が AssemblyLine に渡されていることを検出した場合は、このコネクターは開始されず、この項目は AssemblyLine 内の次のコネクターに渡されます。

以下の図は、イテレーターがデータの終わりに達したときに何が起きるかを示しています (6 (197ページ)を参照してください)。データの終わりとは、繰り返しで使用可能なデータがなくなる時点です。この時点で、イテレーターは次のコネクターに作業オブジェクトを渡さず、それが別のイテレーターの場合は、そのイテレーター独自の繰り返しを開始するよう指示します。


GetNext 関数がデータの終わり (繰り返しに使用可能なデータがないこと) を検出すると、フローは続行します。

イテレーター・フローは、以下のとおりです。






3. 決定コンポーネント: GetNext の指定変更を使用可能にする?

a. はいの場合は、スクリプト化されたフロー・コンポーネント、GetNext の指定変更スクリプトに進みます。このスクリプト化されたフロー・コンポーネントは、作業オブジェクトにアクセスします。




4. スクリプト化されたフロー・コンポーネント、GetNext 前に進みます。このスクリプト化されたフロー・コンポーネントは、作業オブジェクトにアクセスします。



5. IBM Tivoli Directory Integrator の GetNext 操作を実行します。



6. 決定コンポーネント: データの終わり?

a. はいの場合は、スクリプト化されたフロー・コンポーネント、データ終わりに進みます。このスクリプト化されたフロー・コンポーネントは、作業オブジェクトにアクセスします。

1) 決定コンポーネント: AssemblyLine にイテレーターを追加する?

a) はいの場合は、次のイテレーターに進みます。

b) いいえの場合は、AssemblyLine プロセスの終了です。


7. スクリプト化されたフロー・コンポーネント、GetNext 後に進みます。このスクリプト化されたフロー・コンポーネントは、work および conn オブジェクトにアクセスします。






ルックアップ・モード他の場合と同様に、作業オブジェクトは、現在 AssemblyLine 内にある属性へのアクセスを提供します。


リンク基準作成操作が終わると、search と呼ばれるスクリプト・オブジェクトが使用可能になり、これを使用してこの情報にアクセスできます (たとえば「Override」フックの中で使用します)。

リンク基準と一致するレコードまたは項目 (これから削除されるもの) は、conn オブジェクトを介してスクリプト用に使用できます。


このフックのランタイムには、コネクターの setCurrent() 関数を呼び出して、conn を所要の項目オブジェクトに設定しておく必要があります。





これらの関数は、setCurrent() 呼び出しで使用できる項目オブジェクトを戻します。

setCurrent() が呼び出されない場合 (例えば、現行項目が設定されていない場合)

は、以後のこのモード固有のフローをバイパスし、成功時に移ってフローが続行されます。


ルックアップ・フローは、以下のとおりです。






3. 決定コンポーネント: ルックアップの指定変更を使用可能にする?



2) 成功の場合は、スクリプト化されたフロー・コンポーネント、ルックアップの指定変更スクリプトに進みます。このスクリプト化されたフロー・コンポーネントは、作業オブジェクトにアクセスします。




4. スクリプト化されたフロー・コンポーネント、ルックアップ前に進みます。










a. はいの場合は、必須の複数項目時フックに進みます。このスクリプト化されたフロー・コンポーネントは、作業オブジェクトにアクセスします。







a. いいえの場合は、必須の一致なしの場合フックに進みます。このスクリプト化されたフロー・コンポーネントは、作業オブジェクトにアクセスします。




9. スクリプト化されたフロー・コンポーネント、ルックアップ後に進みます。このスクリプト化されたフロー・コンポーネントは、work および conn オブジェクトにアクセスします。







更新モード他の場合と同様に、作業オブジェクトは、現在 AssemblyLine 内にある属性へのアクセスを提供します。

リンク基準作成操作が終わると、search と呼ばれるスクリプト・オブジェクトが使用可能になり、これを使用してこの情報にアクセスできます (例えば指定変更フックの中で使用します)。





どちらの関数も項目オブジェクトを戻し、このオブジェクトを使用してコネクターのデータ・アクセス・メソッド (更新、削除、AddOnly など) を呼び出すことができます。

さらに、コネクターの setCurrent() 関数を呼び出すことにより、conn を所要の項目オブジェクトに設定することができます。


項目オブジェクトが設定されていない場合は、以後のこのモード固有のフローを飛び越して、On Success に移って実行が続けられます。

注: 複数の項目が操作されるときは、データ・ソース (そして関連のコネクター) の動作が異なります。前に述べたように特定項目を設定した場合でも、更新操作を続行することはお勧めできません。操作を続行すると、エラーが発生するか、複数の項目に対して操作が行われるおそれがあります。


更新フローは、以下のとおりです。






3. スクリプト化されたフロー・コンポーネント、更新前に進みます。このスクリプト化されたフロー・コンポーネントは、作業オブジェクトにアクセスします。



4. 決定コンポーネント: 更新の指定変更を使用可能にする?



2) 成功の場合は、スクリプト化されたフロー・コンポーネント、更新の指定変更スクリプトに進みます。このスクリプト化されたフロー・コンポーネントは、作業オブジェクトにアクセスします。




5. スクリプト化されたフロー・コンポーネント、ルックアップ前に進みます。このスクリプト化されたフロー・コンポーネントは、作業オブジェクトにアクセスします。










a. はいの場合は、必須の複数項目時フックに進みます。このスクリプト化されたフロー・コンポーネントは、作業オブジェクトにアクセスします。






9. スクリプト化されたフロー・コンポーネント、ルックアップ後に進みます。このスクリプト化されたフロー・コンポーネントは、work および conn オブジェクトにアクセスします。





a. いいえの場合は、1 (206ページ)に進みます。

b. はいの場合は、1 (207ページ)に進みます。

他の場合と同様に、作業オブジェクトは、現在 AssemblyLine 内にある属性へのアクセスを提供します。

更新の結果として追加操作が発生する場合は、データ・ソースに書き込まれるデータが conn オブジェクトに保管されます。


1. 10a (205ページ)から続きます。

2. 決定コンポーネント: 追加の指定変更を使用可能にする?


a. はいの場合は、スクリプト化されたフロー・コンポーネント、追加の指定変更スクリプトに進みます。このスクリプト化されたフロー・コンポーネントは、作業オブジェクトにアクセスします。


2) 成功の場合は、更新後 (8 (208ページ)) に進みます。





4. スクリプト化されたフロー・コンポーネント、追加前に進みます。このスクリプト化されたフロー・コンポーネントは、work および conn オブジェクトにアクセスします。



5. IBM Tivoli Directory Integrator の追加操作を実行します。



6. スクリプト化されたフロー・コンポーネント、追加後に進みます。このスクリプト化されたフロー・コンポーネントは、work および conn オブジェクトにアクセスします。


b. 成功の場合は、更新後に進みます。

他の場合と同様に、作業オブジェクトは、現在 AssemblyLine 内にある属性へのアクセスを提供します。

更新の結果変更操作が発生する場合は、現行オブジェクトを使用して、接続されているデータ・ソース内のリンク基準と一致するレコードまたは項目にアクセスできます。追加の場合と同様に、conn オブジェクトには、この場合は変更操作によりデータ・ソースに書き込まれる情報が保管されます。

注: 一部のデータ・ソースは、変更を自動的に計算し、何も検出されない場合は、「無変更」例外を伴って復帰します。その結果、フローは「On NoChanges」フックに渡されます。

1. 10b (205ページ)から続きます。

2. 決定コンポーネント: 変更の指定変更を使用可能にする?

a. はいの場合は、スクリプト化されたフロー・コンポーネント、変更の指定変更スクリプトに進みます。このスクリプト化されたフロー・コンポーネントは、work および current オブジェクトにアクセスします。


2) 成功の場合は、スクリプト化されたフロー・コンポーネント、更新後に進みます。



3. スクリプト化されたフロー・コンポーネント、属性マップに進みます。このスクリプト化されたフロー・コンポーネントは、work、current、およびconn オブジェクトにアクセスします。



4. スクリプト化されたフロー・コンポーネント、変更前に進みます。このスクリプト化されたフロー・コンポーネントは、work、current、およびconn オブジェクトにアクセスします。



5. 決定コンポーネント: 変更の計算?

a. はいの場合は、決定コンポーネント: 変更を検出した? に進みます。

1) はいの場合は、スクリプト化されたフロー・コンポーネント、無変更に進みます。このスクリプト化されたフロー・コンポーネントは、work、current、およびconn オブジェクトにアクセスします。


b) 成功の場合は、スクリプト化されたフロー・コンポーネント、更新後に進みます。

2) はいの場合は、スクリプト化されたフロー・コンポーネント、変更の適用前に進みます。このスクリプト化されたフロー・コンポーネントは、work、current、およびconn オブジェクトにアクセスします。


b) 成功の場合は続行します。


6. 変更操作を実行します。



7. スクリプト化されたフロー・コンポーネント、変更後に進みます。このスクリプト化されたフロー・コンポーネントは、work、current、およびconn オブジェクトにアクセスします。



8. スクリプト化されたフロー・コンポーネント、更新後に進みます。このスクリプト化されたフロー・コンポーネントは、work、current、およびconn オブジェクトにアクセスします。


b. 成功の場合は、成功時に進みます。

すべてのモードの場合のフローの終わり他の場合と同様に、作業オブジェクトは、現在 AssemblyLine 内にある属性へのアクセスを提供します。


conn および current オブジェクトは、「On Error」フックおよび「OnSuccess」フックの中で使用できます (フロー内にすでに存在している場合)。

フロー終わりこのフローは、正常に停止したコネクターおよびエラーが原因で終了したコネクターのすべてに適用されます。ただし、イテレーター・モードのみは例外で、データの終わりに達したときに、制御を渡すイテレーターがほかにない場合は、AssemblyLine は停止します。

エラー処理

注: エラー時フックが使用可能にされている場合は、コネクターが正常に停止した場合と同様に、制御は次のコネクターに渡されます。そうでない場合は、AssemblyLine は打ち切られます。

エラー時フックでエラーが起きた場合も、AssemblyLine は打ち切られます。

エラー・オブジェクト (タイプは項目) は、AssemblyLine 全体で使用でき、属性によりエラーの状況に関する情報 (状況、例外、クラス、メッセージ、操作、コネクター名) を提供します。

状況属性は、エラーが発生するまではストリング値 OK をとり、エラーが発生した時点で fail の値が割り当てられ、他の属性がエラーに追加されます。


1. エラー時フロー端点から続きます。

2. スクリプト化されたフロー・コンポーネント、エラー時 (モード固有) に進みます。このスクリプト化されたフロー・コンポーネントは、work および error オブジェクトにアクセスします。


a. エラーの場合は、AssemblyLine の打ち切り (AL エピローグ: クローズ前に進みます。


3. スクリプト化されたフロー・コンポーネント、エラー時 (デフォルト) に進みます。このスクリプト化されたフロー・コンポーネントは、work および error オブジェクトにアクセスします。

a. エラーの場合は、AssemblyLine の打ち切り (AL エピローグ: クローズ前に進みます。


4. 決定コンポーネント: 少なくとも 1 つのエラー時フックが使用可能になっている?

a. はいの場合は、AssemblyLine の継続に進みます。

b. いいえの場合は、AssemblyLine の打ち切り (AL エピローグ: クローズ前に進みます。

成功時1. 成功時フロー端点から続きます。

2. スクリプト化されたフロー・コンポーネント、成功時 (モード固有) に進みます。このスクリプト化されたフロー・コンポーネントは、作業オブジェクトにアクセスします。



3. スクリプト化されたフロー・コンポーネント、成功時 (デフォルト) に進みます。このスクリプト化されたフロー・コンポーネントは、作業オブジェクトにアクセスします。



4. AssemblyLine を続行します (AssemblyLine フローに戻ります)。


付録 C. MOBJ 管理エンジン

IBM Tivoli Directory Integrator 管理エンジン MOBJ には、Java クラスからプログラマチックにアクセスすることも、IBM Tivoli Directory Integrator からのスクリプト記述によってアクセスすることもできます。

MOBJ へのメイン・エントリー・ポイントを表すのは、次の 2 つのオブジェクトです。

v JMX MBean Server オブジェクト

v MOBJ オブジェクト

JMX MBean Server オブジェクトJMX MBean Server オブジェクトは、MOBJ インプリメンテーションにより提供されるすべての管理機能にアクセスするための、純粋な JMX インターフェースを表します。このオブジェクトは、JMX 仕様バージョン 1.1 に定義されているように、javax.management.MBeanServer のタイプです。

IBM Tivoli Directory Integrator でのスクリプト記述では、このオブジェクトはjmxServer として宣言されます。Java クラスは、com.ibm.di.management.Manager.getMBeanServer() を呼び出すことにより、このオブジェクトを検索できます。

MOBJ オブジェクトMOBJ オブジェクトは、以下を提供します。

v 一部の JMX 操作を容易にするヘルパー・メソッド。

v 管理オブジェクトへの直接アクセス。これにより、JMX メソッドの呼び出し方式を使用せずに、オブジェクトを直接呼び出すことができます。したがって、IBM

Tivoli Directory Integrator スクリプトからの管理オブジェクトの使用が容易になります。

IBM Tivoli Directory Integrator でのスクリプト記述では、このオブジェクトはmobj として宣言されます。Java クラスは、com.ibm.di.management.Manager.getManager() を呼び出すことにより、このオブジェクトを検索できます。

MOBJ オブジェクトは、IBM Tivoli Directory Integrator 管理オブジェクト (実際には JMX MBeans) へのアクセスを (直接または JMX オブジェクト名を使用して)

提供します。これらのオブジェクトにより、AssemblyLine、EventHandler、コネクター、パーサー、構成、IBM Tivoli Directory Integrator Server 自体などの IBM Tivoli

Directory Integrator オブジェクトを管理するためのインターフェースが提供されます。


MOBJ オブジェクトを介して使用可能な呼び出しは、com.ibm.di.management.IManager Java インターフェースの JavaDoc 文書に明記されています。

IBM Tivoli Directory Integrator オブジェクトの管理に使用可能な呼び出しは、com.ibm.di.management.mbeans パッケージの Java インターフェースの JavaDoc 文書に明記されています。

例えば、以下のスクリプトでは、現在のサーバー構成内のすべての AssemblyLine

の名前が出力されます。

alConfigAdmin = mobj.getAssemblyLinesCfgAdmin();alNames = alConfigAdmin.retrieveAssemblyLinesNames();for (i=0; i<alNames.length; i++) {main.logmsg("AssemblyLine: " + alNames[i]);

}


付録 D. 特記事項

本書は米国 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 licenseThe Apache 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

DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF

付録 D. 特記事項 217

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 Tivoli DB2 WebSphere OS/390

Lotus Domino iNotes Notes CloudScape

Java、JavaScript、およびすべての Java 関連の商標およびロゴは、Sun Microsystems,

Inc. の米国およびその他の国における商標または登録商標です。

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

UNIX は、The Open Group がライセンスしている米国およびその他の国における登録商標です。

他の会社名、製品名およびサービス名などはそれぞれ各社の商標または登録商標です。


��

Printed in Japan

SC88-9897-00

IBM Tivoli Directory Integrator 5.2...

Documents

Transcript of IBM Tivoli Directory Integrator 5.2...