プロダクション業務ユーザーズ ガイド
|
 |
 |
|
Propagation Utility では、あるポータル環境のコンフィグレーションを別の環境に伝播させることができます。この章では、Propagation Utility を使用する前に知っておく必要のある情報を示します。このユーティリティの使用方法については、「Propagation Utility の使用」を参照してください。Propagation Utility の最新リリースでの制限事項の説明については、WebLogic Portal SP4 Propagation パッチのリリース ノートを参照してください。
Propagation Utility を使用した伝播は、次の 2 つの主要タスクから構成されます。
以下の節では、Propagation Utility を使用する準備を行うときに念頭に置くべき一般的な考慮事項を説明します。
クラスタ化された環境で、ソース サーバから、送り先の特定の管理対象サーバに伝播します。
Propagation Utility は、インポートまたはエクスポートするサーバ上で稼働する Web ベースのアプリケーションです。ソース システムと送り先システムの間に、クライアント ブラウザからのアクセスをブロックするファイアウォールがある場合は、クライアント マシンにアクセス権を付与するか、送り先マシンからインポート プロセスを実行します。
以下の節では、Propagation Utility を使用する前に実行する伝播タスクについて説明します。伝播計画プロセスの詳細については、「伝播方針の開発」を参照してください。
WebLogic Server ドキュメントの「障害が発生したサーバの回復」の節の手順を使用して、WebLogic LDAP リポジトリをバックアップします。
ご使用の環境に対応したベンダ ツールを使用して、データベースをバックアップします。伝播するデプロイ済みアプリケーションのコピーを保存します。既存のアプリケーションに EAR をデプロイして現在のコンフィグレーションを上書きします。
Propagation Utility には、システムを静止する機能 (つまり、Administration Portal でのポータル データの変更を無効にする機能) がありません。WebLogic Administration Portal の URL を保守ページにリダイレクトすることで、伝播中にユーザがポータル データを変更できないようにする必要があります。伝播のインポート部分でインベントリ リストのロードおよび検証を行った後は、プロダクション システムに変更を加えないことが非常に重要です。詳細については、「静止要件への同意」を参照してください。
Propagation Utility を実行するには、適切なソフトウェアがインストールされている必要があります。手順については、「Propagation ソフトウェアのインストール」を参照してください。
冗長ログ ファイルおよびインベントリ ファイルのデフォルトの場所の変更、およびセッション タイムアウト期間の変更を行うことができます。
これらの値を編集するには、次のディレクトリにある propagation.war ファイルの圧縮を復元します。
patchpath\8.1 SP4 Patch\Propagation Tool
patchpath は、パッチの解凍先のルート ディレクトリです。
web.xml ファイルを編集して、目的の変更を加えます。このファイルは次の場所にあります。
patchpath\8.1 SP4 Patch\Propagation Tool\WEB-INF
ファイルの編集が終了したら、ファイルを圧縮して propagation.war ファイルを再作成します。
分単位のタイムアウト期間を変更するには、web.xml ファイルを編集して、session-timeout 値を変更します。
Propagation Utility で生成されるインベントリのデフォルトの場所、および Propagation Utility の冗長ログ ファイルのデフォルトの場所を変更するには、web.xml ファイルを編集して param-value を変更します。
Propagation Utility で生成されるログ ファイルの詳細については、「Propagation Utility のエクスポート ログ ファイルの確認」および「インポート ログ ファイルの確認」を参照してください。
WebLogic Workshop を使用して、Web アプリケーションに対してポートレット、ポータル、ブック、ページ、カスタム レイアウト、ルック アンド フィール、メニュー、シェル、テーマ、JSP、Java クラスなどの新規リソースを作成した場合は、Propagation Utility で変更をコミットする前に、ソース システムから送り先システムに J2EE アプリケーションをデプロイする必要があります。J2EE アプリケーションをデプロイするときに、サーバがプロダクション モードと開発モードのどちらであるかに応じて、EAR ファイルに反映された変更が自動的に伝播されるかどうかが決まります。詳細については、「一般的な伝播のシナリオ」および「シナリオ 2 : EAR ファイルの再デプロイ」を参照してください。EAR ファイルのデプロイの詳細については、「EAR ファイルの準備とデプロイ」を参照してください。
ヒント : Propagation Utility を開始する前に J2EE アプリケーションを必ずしもデプロイする必要はありません。Propagation Utility の Web ベース インタフェースで、伝播プロセスの必要なステージにリマインダ ページが含まれています。ただし、アプリケーションを事前にデプロイすることをお勧めします。
J2EE アプリケーションをデプロイしないで伝播の変更をコミットした場合、インベントリ リストには新しいリソースは含まれますが、リソースは送り先システムのポータル ライブラリに表示されず、以下の送り先データベース テーブルが新しいデータで更新されません。
これらのデータベース テーブルの詳細と使用方法については、『BEA WebLogic Portal データベース管理ガイド』を参照してください。
Propagation Utility ではソース システムから送り先システムにポータル リソースの完全なセットは伝播されないため、伝播されたデータが伝播されていない他のデータに依存している場合があります。以下に例を示します。
伝播されるリソースと伝播されないリソースのリストについては、「伝播のスコープの参照表」を参照してください。
Propagation Utility の Web ベース インタフェースには、関連付けられた手動更新を必要とする待ち状態の変更の一覧を示すページがあります。この変更リストを参照して、すべての必要な手動変更を実行したことを確認してください。
手動変更リストの例を表示するには、「伝播の前の手動変更」を参照してください。
ポータル資産がどのように伝播されるかを理解するには、伝播のスコープを理解することが不可欠です。Propagation Utility では、ソース システムと送り先システムの間の差分が検出され、設定可能なスコープのネストされたリストが作成されます。リストから、伝播に対して特定のスコープを選択できます。たとえば、Web アプリケーション スコープを選択した場合は、Web アプリケーション内のすべての資産が伝播されます。デスクトップ スコープを選択した場合は、特定のデスクトップに関連付けられている資産のみ伝播されます。
インポート プロセス中に、伝播のスコープを指定します。2 つのシステム間のどこが異なるかに応じて、伝播のスコープを複数のレベルで選択できます。
注意 : Propagation Utility では、同じエンタープライズ アプリケーションの異なるインスタンス間でデータを移行できます。あるアプリケーションから別のアプリケーションへの伝播はサポートされません。
ヒント : Propagation Utility を使用する場合のベスト プラクティスは、最上位レベル (エンタープライズ アプリケーション) にスコープを設定することです。こうすると、ソース環境が送り先環境に正確に反映されます。下位レベルの Web アプリケーションまたはデスクトップにスコープを設定した場合は、ソースと送り先が異なる状態になることがあります。この場合は、送り先で追加の品質保証テストが必要になることがあります。詳細については、「スコープをエンタープライズ アプリケーション レベルに設定する」を参照してください。
WebLogic Administration Portal は、ライブラリ リソースとデスクトップ リソースから構成されるツリーにポータル リソースを編成します。ライブラリ リソースとデスクトップ リソース間の関係を理解すると、伝播の影響と結果を理解するのに役立ちます。
.portal ファイルまたは .portlet ファイルに格納されます。 Administration Portal を使用して新しいデスクトップを作成する場合は、既存のポータル テンプレートを使用できます。テンプレートの使用は、WebLogic Workshop で作成された .portal ファイルからデスクトップのポータル リソースを直接取得することを意味します (.portal ファイルはプライマリ インスタンスとも呼ばれます)。デスクトップを作成すると、ポータル資産が .portal ファイルから削除され、データベースに配置されて、Administration Portal のライブラリ ツリーとデスクトップ ツリーの両方に表示されます。新しいデスクトップ インスタンスから資産を取得し、それらをライブラリに配置することを逆アセンブルと呼びます。
この時点で、ライブラリ (ライブラリ インスタンス) 内の資産 (ブック、ページなど) は、対応するデスクトップ インスタンスの階層に関連しています。名前の変更など、ライブラリ リソースに対する変更は、対応するデスクトップ資産に自動的に継承されます。一方、デスクトップ資産に対する変更は、階層構造に反映されません。
注意 : 資産に対する変更が階層構造に「逆継承」されることはありません。デスクトップ資産に対する変更が、対応するライブラリ インスタンスに継承されることはありません。同様に、訪問者インスタンスに対する変更がデスクトップまたはライブラリ インスタンスに継承されることはありません。
デスクトップに作成した新しいブックとページは、逆アセンブルされません。これらはそのデスクトップに固有のものと見なされます。
ポータルまたはデスクトップ スコープを使用してポータルを伝播する場合、新しいページとブックは、まだポータル ライブラリになければ、ポータル ライブラリに逆アセンブルされます。
管理者または訪問者が (訪問者ツールを使用して) デスクトップ内のブックのブック プロパティまたはページのページ プロパティを変更した場合、これらのプロパティ設定は、ライブラリ内の親ブックまたはページの設定から分離されます。ページ プロパティにはレイアウトとテーマが含まれ、ブック プロパティにはメニューとレイアウトが含まれます。これらのプロパティは、Administration Portal で変更できます。ポータルが伝播されると、ソース アプリケーション内で分離された資産は送り先でも分離されたままになります。
この節では、Propagation Utility で処理されるポータル資産の種類の一覧を示し、各資産タイプで使用可能なスコープ設定レベルを示します。表 7-1 は、実行する伝播の適切なスコープを選択し、目的の資産が確実に伝播されるようにするのに役立ちます。たとえば、dataync データなどの一部の資産はエンタープライズ スコープでのみ伝播されます。
この表には、Propagation Utility で伝播できるデータと、Datasync Web アプリケーションを使用するか EAR をデプロイすることで伝播できるデータが含まれます。推奨されているように Propagation Utility を使用する前に EAR をデプロイすると、Propagation Utility で実際に処理される変更の数が少なくなります。Datasync Web アプリケーションの詳細については、「Datasync Web アプリケーションの使用」を参照してください。EAR デプロイメントの詳細については、「EAR ファイルの準備とデプロイ」を参照してください。
資産の手動伝播の詳細については、「必要な手動変更」を参照してください。
データの伝播は、インポート タスク時に設定したスコープに依存します。表内の以下のインジケータは、各データ タイプに適用できる伝播スコープを示します。
伝播スコープの詳細については、「スコープの設定」を参照してください。
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
|
|
||
セキュリティ情報は、一般に認証データと認可データから構成されます。表 7-2 に示すように、認可データはロールとポリシーから構成され、認証データはユーザとグループから構成されます。
|
|
伝播される特定のデータの詳細については、「伝播のスコープの参照表」を参照してください。
認証情報 (ユーザとグループ) は、Propagation Utility では伝播されません。多くの場合、ユーザおよびグループ情報は、WebLogic Portal によって管理されない独立した外部認証リポジトリに保持されます。
ユーザおよびグループ情報に加えて、Propagation Utility は次のものを伝播しません。
ロールにはユーザおよびグループ情報が含まれているため、ユーザおよびグループ情報をステージング システムとプロダクション システムに格納する方法を検討する必要があります。この 2 つのシステムは、同じ認証リポジトリを共有する場合と共有しない場合があります。
これらのシステムが、ユーザとグループを管理する認証リポジトリを共有しない場合は、ポータルを伝播した後で、各ロールを手動で編集して、適切なユーザおよびグループを送り先システムに追加する必要があります。システムが同じ認証リポジトリを共有する場合は、伝播後にロールに対して手動変更を行う必要はありません。
手動伝播変更の詳細については、「必要な手動変更」を参照してください。
注意 : ベスト プラクティスは、ロール内の特定のユーザではなく、グループを参照することです。それによって、システムでユーザを追加または削除したときのロールの保守が簡単にできるようになります。
通常の伝播は、ステージング環境からプロダクション システムに対して行われます。このシナリオでは、ユーザは一般にステージング環境に対するアクセス権を持たず、伝播を必要とするユーザ カスタマイズ変更はありません。このため、Propagation Utility はユーザ カスタマイズを伝播するように設計されていません。
ユーザ カスタマイズは送り先で保持されますが、送り先システムに伝播すると、これらのカスタマイズは一定の状況で送り先サーバ上で削除または変更されることがあります。たとえば、管理者が Administration Portal を通じて、特定のユーザのカスタマイズと衝突する可能性のある変更を行うことがあります。ユーザが訪問者ツールを使用してページの 1 つに追加した特定のポートレットを、管理者がポータルから削除したとします。この場合、そのポートレットは存在しなくなり、次のログイン時にユーザのポータルに表示されません。つまり、ユーザのカスタマイズは「失われます」。
一般に、ステージング システムに対する変更をプロダクション システムに伝播する場合、ステージングされた変更とユーザ カスタマイズの移行は、ステージングされた変更が WebLogic Administration Portal を使用してプロダクション システムに対して直接行われた場合と同じように行われます。
datasync 資産は、エンタープライズ アプリケーション スコープでのみ伝播されます。datasync 伝播の詳細については、「Datasync データの移行」を参照してください。
Propagation Utility は、結合ルールとも呼ばれるポリシー ルールに基づいて、ソースと送り先のデータを結合します。このルールは、要件に合わせてコンフィグレーションできます。伝播時にポリシー ルールをアクティブにするか無視するかを選択できます。ポリシーについてここで選択した内容によって、伝播の実行中に衝突が発生した場合は、次に示す順序で優先順位が決定されます。
以下の節では、Propagation Utility がポリシーの優先順位付けと実装を行う方法を説明し、これらの伝播ポリシーの設定方法を決定するときに念頭に置く必要のある考慮事項を説明します。
Propagation Utility は、ソース システムと送り先システムにある 2 つの資産が同一かどうかを区別できるように、ポータル資産にユニークな識別子を作成します。この識別子の一部は定義ラベル (インスタンス ラベル) に基づいています。この定義ラベルは、WebLogic Workshop のエディタ ペインと WebLogic Administration Portal のページ プロパティに表示されます。図 7-1 に、WebLogic Administration Portal に表示される定義ラベルの例を示します。
伝播プロセス中に変更をプレビューすると、2 つのシステム間に検出された差分に基づいて計画された変更を表示できます。
伝播の処理中に衝突が発生した場合、Propagation Utility は前に示した優先順序で、作成されたポリシーに従って衝突を処理します。
Propagation Utility が衝突を解決した場合、処理時にユーティリティによって作成されるログ ファイルにその解決処理が記録され、衝突を解決するために行われた変更が Web ベースの Propagation Utility インタフェースにリストされます。
衝突が発生した場合、ポリシーは、Propagation Utility のポリシー ページに表示された順序で優先されます。次の例で、ソースと送り先にある異なるブックに同じページが追加された場合に Propagation Utility が衝突をどのように解決するかを説明します。
あるユーザがソース システムの Book2 に Page1 を追加しますが、別のユーザが同じ Page1 を送り先の Book3 に追加します。ソースへの追加は送り先に追加され、ソースでの「削除」は無視されるというルールが定義されています (つまり、ある資産が送り先にあり、ソースにはない場合、その資産は送り先に残ります)。WebLogic Portal では、ある特定のページが複数のブックに存在できないため、Propagation Utility は Page1 を Book2 に追加し、送り先システムの Book3 から削除することで衝突を解決します。
伝播前の環境に戻す必要がある場合は、伝播プロセスを開始する前に作成したバックアップを使用します。詳細については、「データ バックアップの実行」を参照してください。
Web Services for Remote Portlets (WSRP) の主な利点の 1 つは、WSRP モデルによって、リモート サービスをホストおよび管理するプロデューサと、リモート サービスを使用するコンシューマが分離されることです。コンシューマにリモート ポートレットを作成する場合、コンシューマに関する登録情報がプロデューサに格納されることに注意する必要があります。登録情報には、登録ハンドル、WSDL の URL、およびその他の任意指定の情報が含まれます。コンシューマをステージング環境からプロダクション環境に伝播する場合、プロデューサや、プロデューサが管理するコンシューマの登録情報は、Propagation Utility では直接認識されません。
ステージング環境とプロダクション環境間の WSRP 伝播の処理には、共有登録とデュアル登録という 2 つのモデルがあります。
注意 : 現在、WebLogic Portal では共有登録モデルのみサポートされています。
WebLogic Portal では、共有登録モデルのみサポートされます。登録ハンドルがステージング環境とプロダクション環境で共有されるため、両方の環境から同じプロデューサが参照されます。このため、プロデューサのデータの伝播は不要です。
このモデルの欠点は、プロデューサのポートレットを「ステージング」できないことです。プロデューサ ポートレットに対する変更は、ステージング システムとプロダクション システムの両方に自動的に反映されます。
将来的には、WebLogic Portal は、デュアル登録モデルでのプロデューサの状態の伝播をサポートする WSRP 2.0 をサポートする予定です。
以下の節では、Propagation Utility を使用して最も予測可能で正確な結果を実現するための実践例を説明します。
WebLogic Workshop で新しいポータルおよびポータル リソースを作成する場合は、定義ラベルとインスタンス ラベルをその時点で変更して、これらのリソースについて意味のある名前を作成することをお勧めします。Propagation Utility を使用して環境間で変更を伝播した後は、これらのリソース名を変更しないことが非常に重要です。Propagation Utility は、ソース システムと送り先システム間の差分を識別するために定義ラベルとインスタンス ラベルを使用します。これらのラベルを WebLogic Workshop または WebLogic Administration Portal で変更した場合は、矛盾が生じるおそれがあります。
アーティファクトは 1 つの環境でのみ作成します。両方の環境で変更した場合は、それらが同一の変更であっても、ユーティリティはそれらを同じ変更として識別できず、2 つの異なるリソースであるかのように伝播が行われます。
最上位レベルのスコープを選択して伝播すると、ソース環境が送り先環境に確実に反映されます。Web アプリケーションやデスクトップなどの下位レベルにスコープを設定した場合は、本質的にはソースと送り先が異なる状態になります。この場合は、送り先で追加の品質保証テストが必要になることがあります。
伝播のスコープは限定できますが、より狭いスコープでの変更が上位レベルで行われた変更に依存している場合は、上位レベルの変更を実装することが必要になる場合があります。たとえば、ライブラリ内の資産に依存するデスクトップを伝播し、これらのライブラリ資産に変更が行われた場合、スコープをデスクトップ レベルに設定した場合でも、Propagation Utility によって他のデスクトップが変更される場合があります。ポータル リソース間の関係の詳細については、「スコープとライブラリの継承」を参照してください。
|
|
|
