| Oracle Identity Managerベスト・プラクティス・ガイド リリース9.0.3 E05088-01 |
|
 戻る |
 次へ |
デプロイメント・マネージャを使用すると、管理者は、移行時に発生しやすい問題を最小限に抑えつつ、Oracle Identity Managerのデプロイをあるサーバーから別のサーバーに移動できます。デプロイメント・マネージャでは、複数の開発者が1つのデプロイの別々の部分を作業し、デプロイメント全体が再作成されるまで待つかわりに、各自が変更した部分のみをアップロードできます。
|
注意: 以前のデータは、インポートされた最新のデータで上書きされるため、注意が必要です。他の開発者の作業を上書きするようなデータはエクスポートしないでください。 |
Oracle Identity Managerのデプロイをあるサーバーから別のサーバーに移行する場合、たとえばテスト環境からステージング環境、あるいはステージング環境から本番環境に移行する場合に、デプロイメント・マネージャを使用します。
デプロイメント・マネージャには、次の利点があります。
デプロイの個々のコンポーネントを、異なるテスト環境で更新します。
エクスポートするコンポーネントに関連するオブジェクトを特定し、リソースに含めることができます。
エクスポート済ファイルの情報を提供します。
エクスポートの実行者はコメントを追加できます。
デプロイメント・マネージャは、次のタイプの情報を処理します。
リソース・オブジェクト
アダプタ
ITリソース・タイプ
ユーザー定義フォーム
組織
ユーザー定義フィールドの定義
ルール定義
電子メール定義
システムおよびエラー・コード
参照定義
ユーザー・グループ
パスワード・ポリシー
アクセス・ポリシー
スケジュール済タスク
デプロイメント・マネージャには、次のような重要な制限があります。
マージ・ユーティリティ: デプロイメント・マネージャはマージ・ユーティリティではありません。
本番環境とテスト環境の両方の変更の処理はできません。ターゲット・システムのオブジェクトはXML内のオブジェクトに置き換えられます。
バージョン管理ユーティリティ: デプロイメント・マネージャでは、インポートしたファイルのバージョンを追跡せず、ロールバック機能は提供されません。
環境間でデータを移動する手段としてのみ使用します。
コードの移動: デプロイメント・マネージャでは、Javaタスクまたはその他の場所にある.jarファイルを移動しません。
これらの移動は手動で行ってください。
カスタム・ラベルの移動: デプロイメント・マネージャでは、customResources.propertiesファイルまたはconnectorResourcesディレクトリのプロパティ・ファイルで定義されたラベルを移動しません。これらの移動は手動で行ってください。
リクエスト、Xellerateユーザー、システム管理者などのシステム・オブジェクトのエクスポートまたはインポートは、本当に必要な場合にのみ行ってください。これらをテスト環境やステージング環境から本番環境にエクスポートすると、問題が発生する場合があります。可能であれば、データのエクスポートまたはインポートの際には、システム・オブジェクトを除外してください。
特定の状況では、システム・オブジェクトのエクスポートまたはインポートが必要な場合があります。Xellerateユーザー・リソース・オブジェクトに対する信頼できるソースのリコンシリエーションを定義する場合などです。
デプロイメント・マネージャを使用して、関連するオブジェクトをセットにしてエクスポートすることをお薦めします。グループ化する論理項目を1つにまとめて、エクスポートの単位にしてください。
1回の操作でデータベース内のすべてをエクスポートしたり、1回に項目を1つずつエクスポートすることは避けてください。たとえば、プロセス、リソース・オブジェクト、アダプタ、ITリソース・タイプ定義、ITリソース定義、スケジュール済タスクなどを含むターゲット・システムと、Oracle Identity Managerとの間の統合を管理するとします。このような環境では、エクスポートの前に関連するオブジェクトのグループを作成します。
たとえば、複数の統合で同一の電子メール定義を使用する場合、電子メール定義を1つの単位としてエクスポートし、統合は別の単位としてエクスポートする必要があります。これにより、電子メール定義の変更を、ターゲット・システム統合の変更から独立させてインポートできます。また、複数のリソースで同一のITリソース・タイプ定義を使用する場合、タイプ定義をその他のデータとは別個にエクスポートおよびインポートできます。
エクスポート済データの1つ以上のセットを一度にインポートできます。たとえば、リソース・オブジェクト定義、電子メール定義およびITリソース・タイプ定義を、1回の操作でインポートできます。
定義データおよび操作データは、別々のグループに分けてエクスポートしてください。
定義データは、テストおよびステージングで構成します。定義には、リソース・オブジェクト、プロセス、ルールなどが含まれます。
一般的に、操作データは、本番環境で構成します。操作データには、グループおよびグループ権限が含まれます。テストおよびステージングには、通常このデータは含まれません。
変更される場所に応じてデータをグループ化すると、どのデータがテストおよびステージングに属し、どのデータが本番に属するかを判別できます。たとえば、本番で承認プロセスが変更された場合、承認プロセスをグループ化してその他の操作データと一緒にエクスポートします。
エクスポートする前に、フォームを何度も修正することがあります。「v23」のような一般的な名前で、フォームのバージョンを区別しないでください。「Before Pre 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を使用するか、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
