| Oracle Identity Managerベスト・プラクティス・ガイド リリース9.1.0.2 B56034-01 |
|
 戻る |
 次へ |
デプロイメント・マネージャを使用すると、開発者は、移行時に発生しやすい問題を最小限に抑えつつ、Oracle Identity Managerのデプロイをあるサーバーから別のサーバーに移動できます。デプロイメント・マネージャでは、デプロイメント全体が再作成されるまで待つのではなく、複数の開発者が1つのデプロイの別々の部分を作業し、各自が変更した部分のみをアップロードできます。
|
注意: 以前のデータは、インポートされた最新のデータによって上書きされます。他の開発者の作業を上書きするようなデータはエクスポートしないでください。 |
Oracle Identity Managerのデプロイをあるサーバー環境から別のサーバー環境に移行する場合、たとえばテスト環境からステージング環境、あるいはステージング環境から本番環境に移行する場合に、デプロイメント・マネージャが役立ちます。
デプロイメント・マネージャでは次のことができます。
デプロイの個々のコンポーネントを、異なるテスト環境で更新
リソースに含めることができるように、エクスポートするコンポーネントに関連するオブジェクトを特定
エクスポート済ファイルの情報の提供
コメントの追加
デプロイメント・マネージャは、次のタイプの情報を処理します。
リソース・オブジェクト
アダプタ
ITリソース・タイプ
ユーザー定義フォーム
組織
ユーザー定義フィールドの定義
ルール定義
電子メール定義
システムおよびエラー・コード
参照定義
ユーザー・グループ
パスワード・ポリシー
アクセス・ポリシー
スケジュール済タスク
デプロイメント・マネージャには、次のような重要な制限があります。
マージ・ユーティリティ: デプロイメント・マネージャはマージ・ユーティリティではありません。
本番環境とテスト環境の両方の変更の処理はできません。ターゲット・システムのオブジェクトはXMLファイル内のオブジェクトに置き換えられます。
バージョン管理ユーティリティ: デプロイメント・マネージャでは、インポートしたファイルのバージョンを追跡せず、ロールバック機能は提供されません。
環境間でデータを移動する手段としてのみ使用します。
コードの移動: デプロイメント・マネージャでは、JavaTasksディレクトリまたはその他の場所にあるJARファイルを移動しません。
これらの移動は手動で行ってください。
カスタム・ラベルの移動: デプロイメント・マネージャでは、customResources.propertiesファイルまたはconnectorResourcesディレクトリのプロパティ・ファイルで定義されたラベルを移動しません。これらの移動は手動で行ってください。
リクエスト、Xellerateユーザー、システム管理者などのシステム・オブジェクトのエクスポートまたはインポートは、本当に必要な場合にのみ行ってください。システム・オブジェクトをテスト環境やステージング環境から本番環境にエクスポートすると、問題が発生する場合があります。可能であれば、データのエクスポートまたはインポートの際には、システム・オブジェクトを除外してください。
Xellerateユーザー・リソース・オブジェクトで信頼できるソースのリコンシリエーションを定義する場合などに、システム・オブジェクトをエクスポートまたはインポートすることがあります。
|
注意: デプロイメント・マネージャでは、インポートしたコンポーネントおよび構造を追跡しますが、終了したインポートの追跡は行いません。インポートが完了した後は、前のバージョンにロールバックできません。新たにインポートする必要があります。 |
デプロイメント・マネージャを使用して、関連するオブジェクトをセットにしてエクスポートすることをお薦めします。グループ化する論理項目を1つにまとめて、エクスポートの単位にしてください。
1回の操作でデータベース内のすべてをエクスポートしたり、1回に項目を1つずつエクスポートしたりすることは避けてください。たとえば、プロセス、リソース・オブジェクト、アダプタ、ITリソース・タイプ定義、ITリソース定義、スケジュール済タスクなどを含むターゲット・システムと、Oracle Identity Managerとの間の統合を管理するとします。このような環境では、エクスポートの前に関連するオブジェクトのグループを作成します。
たとえば、複数の統合で同一の電子メール定義を使用する場合、電子メール定義を1つの単位としてエクスポートし、統合は別の単位としてエクスポートする必要があります。これにより、電子メール定義の変更を、ターゲット・システム統合の変更とは別にインポートできます。また、複数のリソースで同一のITリソース・タイプ定義を使用する場合、タイプ定義をその他のデータとは別個にエクスポートおよびインポートできます。
エクスポート済データの1つ以上のセットを一度にインポートできます。たとえば、リソース・オブジェクト定義、電子メール定義およびITリソース・タイプ定義を、1回の操作でインポートできます。
定義データおよび操作データは、別々のグループに分けてエクスポートしてください。
定義データは、テスト環境およびステージング環境で構成します。定義データには、リソース・オブジェクト、プロセスおよびルールが含まれます。
一般的に、操作データは、本番環境で構成します。操作データには、グループおよびグループ権限が含まれます。テスト・サーバーおよびステージング・サーバーには、通常このデータは含まれません。
変更される場所に応じてデータをグループ化すると、どのデータがテストおよびステージングに属し、どのデータが本番に属するかを判別できます。たとえば、本番で承認プロセスが変更された場合、承認プロセスをグループ化してその他の操作データと一緒にエクスポートします。
エクスポートする前に、フォームを何度も修正することがあります。「v23」のような一般的な名前で、フォームのバージョンを区別しないでください。「Before Production」または「After Production Verification」など、意味のある名前を作成します。バージョン名には二重引用符などの特殊文字を使用しないでください。
組織階層内のリーフや組織をエクスポートすると、1つの依存性レベルのみがエクスポートされます。組織階層を完全にエクスポートするには、階層のルートをエクスポートする必要があります。
デプロイメント・マネージャでは、エクスポート日、エクスポートの実行者、ソース・データベースなどの一部の情報は自動的に記録されます。また、「xxx属性がリコンシリエーションに追加された後のリソース定義」など、エクスポートのコンテンツのわかりやすい説明も指定する必要があります。ファイルのインポート担当者は、これを元にインポートされるデータのコンテンツを把握します。
右上ペインのウィザードには、ターゲット・システムで使用可能であることが必要なリソースが表示されます。
次のタイプの依存性について考慮します。
ターゲット・システムですでに使用可能なリソースは、エクスポートする必要がありません。
（ターゲット・システムにない）新規のリソースは、エクスポートする必要があります。
再利用される参照、ITリソース定義またはその他のリソースがターゲット・システムに含まれていない場合は、必要に応じてインポートできるように、データを記録して別個のファイルでエクスポートします。
|
注意: リソースをエクスポートする際に、そのフォームに対してデータ・オブジェクト権限を持つグループはリソースと一緒にエクスポートされません。 |
スケジュール済タスクが正しく実行されるかどうかは、特定のパラメータに依存します。スケジュール済タスクのパラメータを、本番サーバーにインポートできます。表1-1に、スケジュール済タスクのインポート方法を決定するためのルールを示します。パラメータは、ターゲット・システムに存在しないタスクでも使用できる場合があります。
インポート操作の後、アダプタは再コンパイルするように設定され、スケジュール済タスクは無効化されます。これにより、関連するリソースや設定を構成する前に、これらが実行されることがなくなります。
クラスをインポートしてタスク属性を調整してから、手動でアダプタを再コンパイルし、スケジュール済タスクを有効化してください。
エンティティ・アダプタを変更すると、エンティティ・アダプタのみが更新され、使用方法は更新されません。エンティティ・アダプタの使用方法をエクスポートする場合は、データ・オブジェクトをエクスポートすることにより、各使用方法をデータ・オブジェクトとともに個別にエクスポートする必要があります。データ・オブジェクトをエクスポートすると、オブジェクトにアタッチされたすべてのアダプタとイベント・ハンドラ、およびオブジェクトに対する権限がエクスポートされます。データ・オブジェクトのエクスポートには、細心の注意が必要です。たとえば、フォームをエクスポートする場合、フォームに関連するデータ・オブジェクトも必ず追加するようにしてください。これにより、関連付けられたエンティティ・アダプタでフォームを使用できます。
グループをエクスポートする際に、異なるデータ・オブジェクトに対するグループ権限もエクスポートされます。ただし、データをインポートする際は、欠落しているデータ・オブジェクトに対する権限はすべて無視されます。グループ権限の設定をエクスポートする手段としてグループをエクスポートする場合は、権限の要件が満たされるように、警告を慎重にチェックしてください。たとえば、グループにオブジェクトA、B、Cに対する権限があるが、ターゲット・システムにはオブジェクトA、Bしかない場合、オブジェクトCの権限は無視されます。後でオブジェクトCを追加した場合、Cのグループ権限を手動で追加するか、グループを再インポートする必要があります。
特定のレポートの表示権限を持つグループのエクスポートでは、そのレポートがターゲット環境に存在することを確認してください。レポートがない場合、グループのエクスポートの前に権限を削除することを考慮してください。
データを本番環境にインポートする前に、データベースをバックアップします。これにより、インポートで問題が発生しても、データをリストアできます。データベースをバックアップしておくことは、大きな変更を行う前の大切な予防措置です。
|
注意: フォームおよびユーザー定義フィールドをインポートする際は、データベースにエントリを追加します。これらのデータベース・エントリは、ロールバックまたは削除できません。各インポート操作の前に、フォームの正しいバージョンがアクティブになっていることを確認してください。 |
インポート操作はスキーマの変更を伴うため、単一のトランザクションでは完了できません。これらの変更は、現在システムで実行中のトランザクションに影響を与えます。インポート操作の影響を抑えるためには、一般使用のためのWebアプリケーションを一時的に無効化し、システムのアクティビティが低下する夜間などに操作を行うようにしてください。
SDK表には、ユーザー定義データ・オブジェクトのメタデータ定義が含まれます。XMLファイルからSDK表にデータをインポートすると、SDK_SCHEMA列の値は、XMLファイルが作成されたソース・システムのスキーマ名で変更されることがあります。このため、XMLファイルからSDK表にデータをインポートした後には、SDK_SCHEMA列のスキーマ名をチェックし、必要に応じてOracle Identity Managerデータベースが稼働しているターゲット・システムのスキーマ名に手動で変更する必要があります。SDK_SCHEMA列のスキーマ名を更新するには、Oracle Databaseインストール環境でSQL*Plusを使用するか、Microsoft SQL Serverインストール環境でSQL Query Analyzerを使用して、次のようなSQL問合せを実行します。
UPDATE SDK SET SDK_SCHEMA='target system schema name'
SDK_SCHEMA列のスキーマ名を更新しない場合は、ユーザー定義フィールド（UDF）の定義を変更する別のXMLファイルのインポート時に次のようなエラーが生成されることがあります。
CREATE SEQUENCE UGP_SEQ java.sql.SQLException: ORA-00955: name is already used by an existing object
イベント・ハンドラを依存性としてインポートする場合、デプロイメント・マネージャでは、データ・オブジェクト・フィールドを含むイベント・ハンドラはインポートされません。このため、デプロイメント・マネージャを使用して、依存性としてインポートする必要があるすべてのイベント・ハンドラからデータ・オブジェクト・フィールドを削除してください。
