|
|
この章では、WebLogic Portal 伝播に関連する様々なトピックについて説明します。ポータルの伝播を試みる前に、この章を読むことをお勧めします。
図 6-1 は、伝播セッションの基本フローを示しています。伝播セッションの基本手順は次の通りです。
以下の節では、ポータル アプリケーションを伝播する前に実行する準備タスクについて説明します。伝播計画プロセスの詳細については、「伝播方針の開発」を参照してください。
| 注意 : | ソース システムと送り先のシステムが異なるデフォルトのロケールで JVM を実行する場合、両者の間で伝播を行うことは推奨していません。ロケールがソース システムと指定先システムで異なる場合は、パフォーマンスが低下し、すべてのポータル フレームワーク資産のローカライゼーションは変更マニフェストで常に異なって表示されます。 |
伝播を実行して特定の LDAP データを更新できるようにする場合は、管理サーバを実行しておく必要があります。伝播を実行すると、訪問者ロール、委託管理ロール、資格ポリシー、委託管理ポリシーなどの LDAP データが追加、削除、または更新される可能性があります。
WebLogic Server ドキュメントの「障害が発生したサーバの回復」の節の手順を使用して、WebLogic LDAP リポジトリをバックアップします。
ご使用の環境に対応したベンダ ツールを使用して、データベースをバックアップします。伝播するデプロイ済みアプリケーションのコピーを保存します。既存のアプリケーションに EAR をデプロイして現在のコンフィグレーションを上書きします。
最終インベントリを送り先システムにインポートする前に、ユーザがポータル データを変更するのを防止する手順を実行します。最終インベントリが送り先サーバにコミットされているとき、WebLogic Portal Administration Console を通じて行われた変更は、データの紛失のように、望ましくない悪影響をもたらす可能性があります。
OnlineMaintenanceModeTask Ant タスクは、送り先サーバに対する変更を防止するのに使用できます。WebLogic Portal Administration Console を使用して、サーバをメンテナンス モードにすることもできます。これを実行するには、[コンフィグレーション設定｜サービス管理｜メンテナンス モード] を選択します。OnlineMaintenanceModeTask の詳細については、「OnlineMaintenanceModeTask」を参照してください。Workshop for WebLogic は、メンテナンス モード機能を備えていません。
Workshop for WebLogic 伝播機能は、WebLogic Portal のインストール時に (明示的に除外しない限り)、自動的にインストールされます。伝播 Ant タスクは、使用する前に、追加のコンフィグレーションが必要です。Ant タスクのインストールと使用に関しては、「伝播 Ant タスクの使用」を参照してください。
Workshop for WebLogic での詳細ログ ファイルのコンフィグレーションについては、「詳細ロギングの有効化」を参照してください。
Workshop for WebLogic を使用して、Web アプリケーションに対してポートレット、ポータル、ブック、ページ、カスタム レイアウト、ルック アンド フィール、メニュー、シェル、テーマ、JSP、Java クラスなどの新規リソースを作成した場合は、伝播ツールで変更をコミットする前に、ソース システムから送り先システムに J2EE アプリケーションをデプロイする必要があります。
| 注意 : | ポータルをソース システムからターゲット システムに伝播する前に、ポータル EAR ファイルをターゲット システムに少なくとも 1 回はデプロイする必要があります。さらに、EAR をソース システムにデプロイしたときと同じ名前で、ターゲット システムにデプロイする必要があります。同じ名前で EAR をデプロイしないと、伝播は失敗する可能性があります。 |
| ヒント : | 送り先インベントリをエクスポートする前に、EAR ファイルをデプロイすることをお勧めします。これを実行することにより、最終インベントリを送り先にコミットした後、手動で実施しなければならない変更の数を減らすことができます。 |
J2EE アプリケーションをデプロイするときに、サーバがプロダクション モードと開発モードのどちらであるかに応じて、EAR ファイルに反映された変更が自動的に伝播されるかどうかが決まります。詳細については、「一般的な伝播のシナリオ」および「シナリオ 2 : EAR ファイルの再デプロイ」を参照してください。EAR ファイルのデプロイの詳細については、「ポータル アプリケーションのデプロイ」を参照してください。
J2EE アプリケーションをデプロイしないで伝播の変更をコミットした場合、インベントリ リストには新しいリソースは含まれますが、リソースは送り先システムのポータル ライブラリに表示されず、以下の送り先データベース テーブルが新しいデータで更新されません。
これらのデータベース テーブルの詳細と使用方法については、『BEA WebLogic Portal のデータベース管理ガイド』を参照してください。
伝播ツールはほとんどのポータル データを伝播しますが、いくつかの例外があります。伝播されないポータル資産は、WebLogic Portal Administration Console を使用して送り先サーバに追加する必要があります。
新しいコンテンツ リポジトリ内のコンテンツを伝播する前に、それらのリポジトリを送り先システムに作成する必要があります。
スコープ指定メカニズムを使用して、他の資産が依存する資産を除外する場合、送り先サーバに依存関係を手動で追加する必要があります。詳細については、「スコープについて」を参照してください。
| ヒント : | 伝播および非伝播ポータル リソースの包括的リストについては、「伝播の参照表」を参照してください。 |
伝播されたデータが、伝播されないその他のデータに依存する場合があります。たとえば、委託管理ロールは送り先に伝播されますが、関連ユーザおよびグループは伝播されないため、これらの関連ユーザおよびグループを送り先システムに手動で追加する必要があります。
表 6-1 は、ポータルを構成するデータのカテゴリとタイプの包括的リストと、伝播ツールがそのデータを移動するかどうかを示しています。伝播ツールで伝播されないデータのタイプは、[メモ] の列に記載されています。伝播されないデータは、送り先サーバで手動変更が必要な場合があります。手動変更の詳細については、「必要な手動変更」を参照してください。
|
|||||||
|
|||||||
|
|||||||
|
|||||||
|
セキュリティ情報は、一般に認証データと認可データから構成されます。表 6-2 に示すように、認可データはロールとポリシーから構成され、認証データはユーザとグループから構成されます。
ユーザとグループは伝播ツールで伝播されません。ユーザおよびグループ情報の他に、伝播ツールは次のものを伝播しません。
ロールにはユーザおよびグループ情報が含まれているため、ユーザおよびグループ情報をステージング システムとプロダクション システムに格納する方法を検討する必要があります。この 2 つのシステムは、同じ認証リポジトリを共有する場合と共有しない場合があります。
これらのシステムが、ユーザとグループを管理する認証リポジトリを共有しない場合は、ポータルを伝播した後で、各ロールを手動で編集して、適切なユーザおよびグループを送り先システムに追加する必要があります。システムが同じ認証リポジトリを共有する場合は、伝播後にロールに対して手動変更を行う必要はありません。
伝播の手動変更の詳細については、「必要な手動変更」を参照してください。
| 注意 : | ベスト プラクティスは、ロール内の特定のユーザではなく、グループを参照することです。それによって、システムでユーザを追加または削除したときのロールの保守が簡単にできるようになります。 |
WebLogic Portal インベントリを、複数レベルの親ノードと子ノードによる、大きなツリー構造として考えることができます。ツリーの各ノードは、ポータル アプリケーションの一部に対するインベントリを表します。ノードがスコープに入るように宣言されると、そのノードとその下位ノードのすべてがスコープ内に入ります。すなわち、それらは、エクスポートされるインベントリ ファイルに含まれます。
ポータル アプリケーション全体を伝播しない場合は、スコープを使用して、伝播される資産を限定することができます。スコープ指定の最も一般的な使用例には次のようなものがあります。
Workshop for WebLogic ベースの伝播ツールと伝播 Ant タスクの両方が、スコープ指定をサポートします。伝播ツールでは、マージ済みインベントリ ツリーでノードを選択または選択解除することにより、手動でスコープ指定を判断できます。Ant タスクでは、どのポータル項目がスコープ内にあるとみなされるかを指定する scope.properties ファイルにより、スコープ指定を管理できます。
| ヒント : | どのポータル アーティファクトが伝播に含まれるかを定義するのは、スコープであることを忘れないでください。デフォルトでは、スコープは、コンテンツ リポジトリ データを含むエンタープライズ アプリケーション全体に設定されます。手動またはプロパティ ファイルでスコープを指定するとき、何を含めるかを指定します。たとえば、1 つのデスクトップを指定した場合は、そのデスクトップとそのコンテンツ (ブック、ページなど) のみが伝播されます。ポータル内のそれ以外のデスクトップ、コンテンツ、および他の項目は伝播されません。スコープを 1 つのコンテンツ フォルダに限定した場合は、当該フォルダ、当該フォルダのコンテンツ、当該フォルダの親フォルダが伝播されますが、親フォルダのコンテンツは伝播されません。 |
パフォーマンスはスコープ指定の主要な理由です。スコープ指定インベントリは、エクスポートされる WebLogic Portal インベントリの全体のサイズを減らすので、伝播タスクは一般に高速で実行されます。大きなコンテンツ リポジトリがある場合、ポータル伝播時に、そのリポジトリをエクスポートしたくない場合があります。この場合、コンテンツ リポジトリとそのコンテンツすべてを、スコープ外に移動できます。
スコープ指定の別の理由は、セキュリティ関連です。インベントリを安全でないチャネルを通じて転送することを計画している場合、そのインベントリから特定の慎重を期するコンテンツを除外することができます。
スコープの指定に関わる主要なリスクは、スコープ内に含まれるインベントリ ファイルに、解決不可能な依存関係がある資産が含まれる可能性があることです。インベントリがスコープ内に指定されると、ノード全体 (および当該ノードの派生ノード) がインベントリから除外されます。結果として、含まれているアーティファクトが除外されたアーティファクトに依存する場合、このような依存関係は解決不可能であり、伝播されたポータルが正常に機能しない場合があります。
| ヒント : | 特定のノードをインベントリから除外する場合、スコープ指定の代わりにポリシーを使用することを推奨します。ポリシーについては、「ポリシーの使用」で説明されています。 |
インベントリのスコープ指定を考える場合のベスト プラクティスは、次のとおりです。
Workshop for WebLogic ベースの伝播ツールおよび Ant タスクで、伝播のスコープを設定できます。
伝播ツールは 2 種類のスコープ指定を提供します。新しい伝播セッション ウィザードとマージ済みインベントリ ビューです。
| ヒント : | 伝播ツールの使用の詳細については、「Workshop for WebLogic 伝播ツールの使用」を参照してください。 |
新しい伝播セッションを作成するとき、マージするソースおよび送り先インベントリを選択します。図 6-2 に示されているように、マージ前に、[グローバル スコープの選択] ダイアログで、スコープ設定の判断をする機会が与えられます。図に示されているように、スコープに入れるノードを選択するとき、そのノードの上位ノードが自動的に選択されます。
| 注意 : | [グローバル スコープの選択] ダイアログで項目を選択するとき、スコープ内に含める項目を選択していることになります。エンタープライズ アプリケーション内のそれ以外のすべての項目は伝播のスコープ外になります。したがって、図 6-2 では、選択したシェル定義とその上位ノードのみが伝播されます。たとえば、コンテンツ項目の親フォルダは含まれますが、そのコンテンツ項目が依存するコンテンツ タイプは、自動的には含まれません。 |
[グローバル スコープの選択] ダイアログで選択するには、最初に [指定されたノードにスコープを限定] を選択する必要があります。
![[グローバル スコープの選択] ダイアログ](wwimages/prop-82.gif)
マージ済みインベントリ ビューでマージ済みインベントリのスコープを調整できます。このビューにより、最終インベントリ ファイルを生成する前に、マージ済みインベントリのスコープに最終変更を行うことができます。[グローバル スコープの選択] ダイアログとは違って、マージ済みインベントリ ビュー内の全ノードが選択されています。すなわち、デフォルトでは、それらすべてがスコープ内に入るとみなされます。図 6-3 では、Desktop_update_1 デスクトップが選択解除されています。これにより、そのデスクトップとその下位ノードが、伝播のスコープから除外されます。
OnlineDownloadTask を使用して、インベントリ ファイルのスコープを設定できます。このタスクは、scope.properties ファイル属性を取得します。このファイルを編集して、インベントリ ファイルに含める項目が含まれるようにできます。scope.properties ファイルを指定しない場合、エンタープライズ アプリケーション全体がスコープ内にあるとみなされます。OnlineDownloadTask とその他の伝播 Ant タスクの詳細については、「伝播 Ant タスク リファレンス」を参照してください。
WebLogic Portal では、かなり自由にポータル インベントリのスコープを指定できます。インベントリ ノードをスコープ内またはスコープ外になるように選択するとき、その選択は通常、選択したノードに依存しているか、選択したノードの従属ノードであるその他のノードに影響します。WebLogic Portal は自動的にこれらの依存関係を判断します。Workshop for WebLogic では、視覚的に依存関係を見ることができます。ノードを選択すると、関連するその他のノードが自動的に選択されます。
この節では、次の 4 種類のスコープ指定の影響について説明します。
| 注意 : | 開発モードでサーバに EAR ファイルをデプロイするとき、datasync データと一部のポータル フレームワーク データは自動的に抽出されて、データベースに配置されます。datasync データの一部またはすべてをスコープ指定によって除外する予定だった場合、そのデータは EAR デプロイメントにより自動的に追加され、事実上、スコープ指定が無効になることがわかります。 |
デフォルトでは、すべての伝播は、エンタープライズ アプリケーション レベルにスコープ指定されます。これは、伝播可能なポータルを構成するすべてのアーティファクトが伝播されることを意味します。図 6-4 に示すように、デフォルトでは、エンタープライズ アプリケーション全体がスコープ内にあります。
事前に設定されたスコープ指定レベルはありません。伝播ツールと Ant タスクの両方で、必要に応じてスコープを指定できます。Ant タスクにより scope.properties ファイルを指定して、そこでどのアーティファクトを伝播するかを指定できます (「スコープ プロパティ ファイルについて」も参照)。
Workshop for WebLogic では、インベントリ ツリー内のノードを選択または選択解除することにより視覚的にスコープ指定します。選択したノードは、スコープ内にあるとみなされ、伝播されます。その他すべてのノードは伝播されません。
スコープ指定できる 4 つの主要なカテゴリのポータル アーティファクトがあります。
これらの最上位レベルの各ノードは、図 6-5 に示されているように、[新しい伝播セッション] ウィザードの [グローバル スコープの選択] ダイアログに表示されます。このダイアログを使用して、最上位レベルのカテゴリの 1 つを掘り下げて、スコープ指定のレベルを調整できます。ただし、前述のように、ベスト プラクティスは、コンテンツ サービスなどの最上位カテゴリの 1 つのみにスコープ指定することです。
![[グローバル スコープの選択] ダイアログ](wwimages/prop-85.gif)
最も一般的なスコープ指定使用例の 1 つは、デスクトップ レベルへのスコープ指定です。これは、1 つまたは複数の特定デスクトップがスコープ内に入るように指定することを意味します。残りのエンタープライズ アプリケーションは、スコープ外とみなされ、伝播されません。図 6-6 に示すように、Desktop_1 にスコープ指定すると、そのデスクトップとその子 (ブック、ページなど) は、スコープ内に配置されます。その他のデスクトップと残りのエンタープライズ アプリケーションは、スコープ外に配置されます。このレベルでのスコープ指定のリスクについては、「スコープ指定のリスクとは」を参照してください。
もう 1 つの一般的な使用例は、リポジトリへのスコープ指定です。リポジトリにスコープ指定すると、図 6-7 に示すように、すべてのタイプ、フォルダ、およびコンテンツを含むリポジトリ全体が伝播されます。その他のリポジトリは伝播されず、エンタープライズ アプリケーションのその他の部分も伝播されません。
コンテンツ リポジトリ内のフォルダにスコープ指定する場合、そのフォルダ、そのコンテンツ、およびそのフォルダの親フォルダのすべてが伝播されます。図 6-8 に示すように、親フォルダのコンテンツは伝播されず、親フォルダ自体のみが伝播されることに注意してください。このレベルでのスコープ指定のリスクについては、「スコープ指定のリスクとは」を参照してください。
ページとブックを含むデスクトップなどのポータル資産を伝播するとき、新しいページとブックが既にポータル ライブラリに存在していない場合は、それらが追加されます。
WebLogic Portal Administration Console は、ライブラリ リソースとデスクトップ リソースから構成されるツリーにポータル リソースを編成します。ライブラリ リソースとデスクトップ リソース間の関係を理解すると、伝播の影響と結果を理解するのに役立ちます。
.portal ファイルまたは .portlet ファイルに格納されます。
WebLogic Portal Administration Console を使用して新しいデスクトップを作成する場合は、既存のポータル テンプレートを使用できます。テンプレートの使用は、Workshop for WebLogic で作成された .portal ファイルからデスクトップのポータル リソースを直接取得することを意味します (.portal ファイルはプライマリ インスタンスとも呼ばれます)。デスクトップを作成すると、ポータル資産が .portal ファイルから削除され、データベースに配置されて、WebLogic Portal Administration Console のライブラリ ツリーとデスクトップ ツリーの両方に表示されます。新しいデスクトップ インスタンスから資産を取得し、それらをライブラリに配置することを逆アセンブルと呼びます。
この時点で、ライブラリ (ライブラリ インスタンス) 内の資産 (ブック、ページなど) は、対応するデスクトップ インスタンスの階層に関連しています。名前の変更など、ライブラリ リソースに対する変更は、対応するデスクトップ インスタンスに自動的に継承されます。一方、デスクトップ インスタンスに対する変更は、階層構造に反映されません。
| 注意 : | 資産に対する変更が階層構造に「逆継承」されることはありません。デスクトップ資産に対する変更が、対応するライブラリ インスタンスに継承されることはありません。同様に、訪問者インスタンスに対する変更がデスクトップまたはライブラリ インスタンスに継承されることはありません。 |
デスクトップに作成した新しいブックとページは、逆アセンブルされません。これらはそのデスクトップに固有のものと見なされます。
管理者または訪問者が (訪問者ツールを使用して) デスクトップ内のブックのブック プロパティまたはページのページ プロパティを変更した場合、これらのプロパティ設定は、ライブラリ内の親ブックまたはページの設定から分離されます。ページ プロパティにはレイアウトとテーマが含まれ、ブック プロパティにはメニューとレイアウトが含まれます。これらのプロパティは、WebLogic Portal Administration Console で変更できます。ポータルが伝播されると、ソース アプリケーション内で分離された資産は送り先でも分離されたままになります。
伝播される特定のデータの詳細については、「伝播の参照表」を参照してください。
ポリシーを設定すると、ソース インベントリと送り先インベントリが最終的に 1 つのインベントリ ファイルにマージされる方法を管理できます。この節ではポリシーを説明し、ポリシーを適用する方法を理解するのに役立つ例を示します。
ポリシーにより、次の 3 つのマージ例の処理方法を指定できます。
伝播ツールを通じて、次の 2 種類のポリシーを設定できます。
図 6-9 は、単純で一般的な例を示しています。この場合、デフォルトのグローバル ポリシーは 2 つのインベントリがマージされる方法を定義します。Desktop A 上の Portlet 2 と Portlet 3 は、送り先の Desktop A に追加されます。Desktop B からの Portlet 5 も追加されます。ただし、送り先の Portlet 6 は、ソース システムの Desktop B に存在していなかったので、削除されます。
| ヒント : | デフォルトでは、グローバル ポリシーが、追加、削除、および更新を受け入れるように設定されます。 |
図 6-10 は、同じソースおよび送り先システムを示していますが、この例では、グローバル ポリシーが追加を無視するように設定されています。この場合、Portlet 6 は、ソース デスクトップに存在していなかったので、送り先デスクトップから削除されます。グローバル ポリシーで、追加が無視されるように指定されているので、ソースからの追加のポートレットはどれも追加されません。
図 6-11 は、ローカル ポリシーがグローバル ポリシーをオーバーライドする方法を示しています。この例では、グローバル ポリシーは追加を受け入れますが、ローカル ポリシーが Desktop A の Portlet 1 に配置されています。ローカル ポリシーは、ポートレットを送り先から削除するように指定します。この場合、Desktop A の Portlet 1 は伝播されません。ローカル ポリシーがグローバル ポリシーをオーバーライドします。
WebLogic Portal で、複数のデスクトップに、ポートレットなどの同じライブラリ オブジェウトのインスタンスを含めることができます。
| ヒント : | ポートレットのように、アーティファクトのライブラリ インスタンスとデスクトップ インスタンス間の違いを理解することが重要です。この違いの詳細については、「スコープとライブラリの継承」および「エクスポートとインポートのスコープ」を参照してください。 |
グローバル ポリシーはデスクトップ レベルでオーバーライドされる可能性があるので、(ポートレットなどの) 同じライブラリ オブジェクトのインスタンスに対するポリシーが衝突する可能性があります。伝播ソフトウェアはこのような衝突を次のように解決します。
たとえば、次のシナリオを検討します。ユーザが Page 1 をソース システムの Book 2 に追加しますが、別のユーザが同じ Page 1 を送り先システムの Book 3 に追加します。ソースへの追加は送り先に追加され、ソースでの「削除」は無視されるというルールが定義されています (つまり、ある資産が送り先にあり、ソースにはない場合、その資産は送り先に残ります)。WebLogic Portal では、ある特定のページが複数のブックに存在できないため、伝播ツールは Page 1 を Book 2 に追加し、送り先システムの Book 3 から Page 1 を削除することで衝突を解決します。
このシナリオでは、図 6-12 に示すように、Desktop A に対するローカル ポリシーと Desktop B により継承されるグローバル ポリシー間で、追加に関して衝突があります。Desktop B は、Portlet X を含んでいるので、Portlet X は Desktop B の伝播に必要です (Desktop B は、このポートレットなしでは正確に伝播できません)。したがって、前述のルールに従って、Desktop A に適用されるポリシー オーバーライドが、追加を無視することを示すにもかかわらず、Portlet X に対するライブラリ オブジェクトが伝播に含まれます。
伝播の衝突が伝播 Ant タスクにより解決されるとき、解決は処理中に作成されるログ ファイルに一覧表示されます。Workshop for WebLogic ベースのインタフェースは、コンソール ビューに、衝突を解決するために発生した変更を一覧表示します。
ログ ファイルの詳細については、「ログ ファイルの確認」を参照してください。
基本的な伝播プロセスは、ソース インベントリと送り先インベントリで開始します。次のこれらの 2 つのファイルを、Workshop for WebLogic または伝播 Ant タスクのいずれかを使って、マージ済みインベントリ ファイルにマージします。
最終インベントリ ファイルを生成してコミットする前に、送り先サーバで行われる予定の保留中の変更を検討する機会があります。次のようにして、これらの変更を表示できます。
通常の伝播は、ステージング環境からプロダクション システムに対して行われます。このシナリオでは、ユーザは一般にステージング環境に対するアクセス権を持たず、伝播を必要とするユーザ カスタマイズ変更はありません。このため、ユーザ カスタマイズは伝播されません。
一般に、ステージング システムに対する変更をプロダクション システムに伝播する場合、ステージングされた変更とユーザ カスタマイズの移行は、ステージングされた変更が Administration Console を使用してプロダクション システムに対して直接行われた場合と同じように行われます。
ユーザ カスタマイズは送り先システムで保持されますが、送り先システムに伝播すると、これらのカスタマイズは一定の状況で送り先サーバ上で削除または変更されることがあります。たとえば、管理者が WebLogic Portal Administration Console を通じて、特定のユーザのカスタマイズと衝突する可能性のある変更を行うことがあります。ユーザが訪問者ツールを使用してページの 1 つに追加した特定のポートレットを、管理者がポータルから削除したとします。この場合、そのポートレットは存在しなくなり、次のログイン時にユーザのポータルに表示されません。つまり、ユーザのカスタマイズは「失われます」。
伝播業務とタスクは、次の場所にログ メッセージを生成します。
伝播ツールはトランザクション対応ではないので、ロールバック機能はサポートしていません。伝播前の環境に戻す必要がある場合は、伝播プロセスを開始する前に作成したバックアップを使用します。詳細については、「データ バックアップの実行」を参照してください。
Web Services for Remote Portlets (WSRP) の主な利点の 1 つは、WSRP モデルによって、リモート ポートレットのプロデューサとコンシューマが分離されることです。この節では、コンシューマ ポータル アプリケーション (リモート ポートレットを含んでいるポータル) を伝播する正しいテクニックについて説明します。WebLogic Portal での WSRP の使用については、『連合ポータル ガイド』を参照してください。
現在、WSRP コンシューマであるステージングされたポータル アプリケーションをプロダクション環境に伝播できる唯一のサポートされたコンフィグレーションを、図 6-13 に示します。このコンフィグレーションでは、ステージングとプロダクション両方のコンシューマ アプリケーションが同じプロデューサを「ポイント」します。
リモート ポートレットの伝播のしくみを理解するには、プロデューサとコンシューマ アプリケーションの関係についての基本を見直しておくと役立ちます。リモート ポートレットをコンシューマ ポータル アプリケーションに追加する前に、プロデューサの登録が必要な場合は、コンシューマをプロデューサに登録する必要があります。登録が必要な場合は、プロデューサ ハンドルと呼ばれるプロデューサの名前を供給しなければなりません。このハンドルは、コンシューマがプロデューサを認識するための名前です。図 6-13 では、プロデューサ ハンドルは myProducer です。
管理者が WebLogic Portal Administration Consol を使用してリモート ポートレットをカスタマイズする場合、コンシューマはリモート ポートレットを複製することができます。コンシューマがリモート ポートレットを複製すると、プロデューサから新しいポートレット ハンドルを受け取ります。続いて、プロデューサは、コンシューマに割り当てた登録ハンドルに対して複製したポートレットの状態を保存します。プロデューサにより管理されるポートレットの状態には通常はポートレット プリファレンスが含まれます。このシナリオは、プロデューサの登録が必要であるかどうかにかかわらず、発生します。図 6-13 では、複製されたプロデューサ ハンドルは XYZ01 です。伝播の際に、このポーレット ハンドルはソースから送り先へ伝播されます。リモート ポーレットの追加に関する詳細については、『連合ポータル ガイド』を参照してください。
ステージング環境およびプロダクション環境が図 6-13 に示すようにコンフィグレーションされたら、伝播ツールを使用してコンシューマ アプリケーションをステージングからプロダクションに移動できます。コンシューマ ポータル アプリケーションを伝播するには、次の手順に従います。
| 注意 : | 次の手順は、プロデューサがそれ自体を登録するコンシューマを必要としたかどうかにかかわらず、適用されます。 |
たとえば、プロデューサをプロデューサ ハンドル myProducer を持ったステージングのコンシューマに追加または登録した場合は、myProducer をプロダクション領域のプロデューサ ハンドルとしても使用しなければなりません。プロデューサの追加および登録に関する詳細については、『連合ポータル ガイド』を参照してください。
伝播が完了すると、プロダクション環境のコンシューマ ポータルはステージング環境のコンシューマ ポータルと機能的に同等になります。
| 注意 : | プロデューサ データの伝播は不要です。これは、ソースおよび送り先システムの両方が同じプロデューサを指すためです。 |
WSRP を使用するポータルの伝播には、前の節の「WSRP 伝播の概要」で説明したコンフィグレーションだけがサポートされています。この節では、この伝播モデルの既知の問題について記載します。リモート ポートレットを使用するポータルを伝播する場合は、これらの問題を配慮する必要があります。
| 注意 : | 現在、WebLogic Portal ではプロデューサが伝播の発生を認識しないモデルをサポートしています。このモデルでは、プロデューサ管理状態は伝播されません。将来は、WebLogic Portal は WSRP 2.0 標準をサポートします。その時点で、WebLogic Portal は、コンシューマがプロデューサ管理ポートレット状態を伝播できるモデルをサポートするようになります。新しい WSRP 2.0 ベースのモデルでは、この節で記載された制限はなくなります。 |
伝播管理サーブレットのコンフィグレーション設定により、Dos 攻撃を軽減することができます。サーブレットは、アップロード ファイル (HTTP 経由でアップロードされるファイル) に許可される最大サイズでコンフィグレーションされます。デフォルトでは、1MB に設定されます。インベントリ ZIP ファイル内でこの値を超えたファイルは拒否されます。この節では、この制限を回避する方法、または伝播サーブレットのコンフィグレーションを変更してより大きなファイルを許可するように変更する方法を説明します。
このファイル サイズ制限を回避する最も簡単な方法は、物理的にファイルを FTP またはその他の手段を使って、ソースから送り先サーバにコピーすることです。ファイルを送り先にコピーした後、OnlineUploadTask の readFromServerFileSystem 属性を使用して、アップロードを実行できます。このタスクの詳細については、「OnlineUploadTask」を参照してください。
デプロイメント計画を使って、1MB のデフォルトのファイル アップロード制限をオーバーライドできます。デプロイメント計画は、WebLogic Server へのデプロイメントのためのアプリケーションをコンフィグレーションするオプションの XML ファイルです。デプロイメント計画を使用するには、通常は WebLogic Server デプロイメント記述子に定義されるプロパティ値を設定するか、または WebLogic Server デプロイメント記述子に定義済みのコンテキスト パラメータ値をオーバーライドします。
| ヒント : | デプロイメント計画の作成と使用については、WebLogic Server ドキュメントに詳しく記載されています。詳細については、「デプロイメント プランのリファレンスおよびスキーマ」および「プロダクション環境でのアプリケーションの更新」を参照してください。 |
デプロイメント計画を使ってファイル サイズ制限を変更するには、次の手順に従います。
| ヒント : | デプロイメント計画の場所は、ドメインの config.xml ファイルで指定する必要があります。コード リスト 6-2 は、サンプル スタンザを示しています。詳細については、『WebLogic Server ドキュメント』を参照してください。 |
<variable-definition> と <variable-assignment> 要素を追加して、コンテンツ デプロイメント記述子の parameter maximum_inventoryfile_upload_size を変更します。これらの要素は、コード リスト 6-1 で太字で強調表示されています。例では、アップロード ファイル サイズ制限が 3MB に変更されています。オーバーライドされた記述子が、アプリケーションの web.xml ファイルに関連付けられています。 <deployment-plan xmlns="http://www.bea.com/ns/weblogic/90" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<application-name>drtApp</application-name>
<variable-definition>
<variable>
<name>CHANGEUPLOAD</name>
<value>3000000</value>
</variable>
</variable-definition>
<module-override>
<module-name>propagation.war</module-name>
<module-type>war</module-type>
<module-descriptor external="false">
<root-element>weblogic-web-app</root-element>
<uri>WEB-INF/weblogic.xml</uri>
</module-descriptor>
<module-descriptor external="false"></module-override>
<root-element>web-app</root-element>
<uri>WEB-INF/web.xml</uri>
<variable-assignment>
<name>CHANGEUPLOAD</name>
<xpath>/web-app/context-param/
[param-name="maximum_inventoryfile_upload_size"]/param-value</xpath>
</variable-assignment>
</module-descriptor>
</deployment-plan>
<app-deployment>
<name>drtApp</name>
<target>portalServer</target>
<module-type>ear</module-type>
<source-path>/myProject/myApplication</source-path>
<deployment-order>101</deployment-order>
<plan-dir>/myProject/applications/plan</plan-dir><security-dd-model>Advanced</security-dd-model>
<plan-path>plan.xml</plan-path>
</app-deployment>
| 注意 : | この方法は推奨されていません。 |
伝播アプリケーションの web.xml ファイルで直接ファイルのアップロード サイズをコンフィグレーションできます。このファイルを変更するには、次の手順に従います。
WEBLOGIC_HOME/portal/lib/modules/wlp-propagation-web-lib.war
web.xml ファイルを開きます。 web.xml ファイルにスタンザを追加します。この例では、デフォルトのファイル サイズが 3MB に変更されています。 <context-param>
<description>Maximum upload size (in bytes), if not specified
defaults to 1 MB.
</description>
<param-name>maximum_inventoryfile_upload_size</param-name>
<param-value>3000000</param-value>
</context-param>
伝播サーブレットに影響するいくつかのコンフィグレーション パラメータは、伝播 Web アプリケーションの web.xml ファイルで指定されます。これらのパラメータの変更方法としては、デプロイメント計画の使用を推奨します。
デプロイメント計画は、WebLogic Server へのデプロイメントのためのアプリケーションをコンフィグレーションするオプションの XML ファイルです。デプロイメント計画を使用するには、通常は WebLogic Server デプロイメント記述子に定義されるプロパティ値を設定するか、または WebLogic Server デプロイメント記述子に定義済みのコンテキスト パラメータ値をオーバーライドします。
| ヒント : | デプロイメント計画の作成と使用については、WebLogic Server ドキュメントに詳しく記載されています。詳細については、「デプロイメント プランのリファレンスおよびスキーマ」および「プロダクション環境でのアプリケーションの更新」を参照してください。 |
| ヒント : | デプロイメント計画を使用した伝播サーブレットのコンフィグレーションの詳細については、「デフォルトのアップロード ファイル サイズの増加」の節を参照してください。 |
次の節で、伝播アプリケーションの web.xml ファイルに対するコンテキスト パラメータを示します。これらのパラメータをオーバーライドするには、デプロイメント計画を使用します。パラメータは次のコンフィグレーションを設定するのに使用されます。
コード リスト 6-4 に表示されるスタンザ例は、エクスポートされるインベントリ ZIP ファイルを配置する一時ディレクトリを指定するのに使用されます。
context-param>
<description>Base folder path for runtime data, such as
inventory exports.
</description>
<param-name>inventoryWorkingFolder</param-name>
<param-value>D:\dev\src\wlp\propagation\test\inventories</param-value>
</context-param>
コード リスト 6-5 に表示されるスタンザ例は、export.properties ファイルに配置される短い説明を指定するのに使用されます。このファイルには、エクスポートを行うユーザ、エクスポート日時、エクスポートに含まれるノード数などのインベントリの概要情報が格納されています。
<context-param>
<description>The name of the operating environment.</description>
<param-name>environment_name</param-name>
<param-value>Staging</param-value>
</context-param>
コード リスト 6-6 に表示されるスタンザ例は、詳細ロギングを有効または無効にするのに使用されます。
<context-param>
<description>Enable verbose logging for the servlet.</description>
<param-name>enable_verbose_logging</param-name>
<param-value>true</param-value>
</context-param>
コード リスト 6-5 に示されるスタンザ例は、詳細ログ ファイルの場所を指定するのに使用されます。デフォルトで、このファイルはドメインの一時ディレクトリに保存されます。
<context-param>
<description>Specify the folder to put verbose logs.</description>
<param-name>verbose_log_folder</param-name>
<param-value>D:/dev/src/wlp/propagation/test/inventories</param-value>
</context-param>
以下の節では、伝播ツールを使用して最も予測可能で正確な結果を実現するための実践例を説明します。
WebLogic Workshop で新しいポータルおよびポータル リソースを作成する場合は、定義ラベルとインスタンス ラベルをその時点で変更して、これらのリソースについて意味のある名前を作成することをお勧めします。伝播ツールを使用して環境間で変更を伝播した後は、これらのリソース名を変更しないことが非常に重要です。伝播ツールは、ソース システムと送り先システム間の差分を識別するために定義ラベルとインスタンス ラベルを使用します。これらのラベルを Workshop for WebLogic または Administration Console で変更した場合は、矛盾が生じるおそれがあります。
ポータル フレームワークとセキュリティ資産を 1 つの環境のみで作成します。ソースとターゲット環境両方の環境で同一の変更をした場合は、伝播ツールはそれらを同じ変更として識別できず、2 つの異なるリソースであるかのように伝播が行われます。この助言は、datasync およびコンテンツ管理資産に適用されませんが、ベスト プラクティスは、1 つの環境のみで資産を作成することです。
最上位レベルのスコープを選択して伝播すると、ソース環境が送り先環境に確実に反映されます。Web アプリケーションやデスクトップなどの下位レベルにスコープを設定した場合は、本質的にはソースと送り先が異なる状態になります。この場合は、送り先で追加の品質保証テストが必要になることがあります。
伝播のスコープは限定できますが、より狭いスコープでの変更が上位レベルで行われた変更に依存している場合は、上位レベルの変更を実装することが必要になる場合があります。たとえば、ライブラリ内の資産に依存するデスクトップを伝播し、これらのライブラリ資産に変更が行われた場合、スコープをデスクトップ レベルに設定した場合でも、伝播ツールによって他のデスクトップが変更される場合があります。ポータル リソース間の関係の詳細については、「スコープとライブラリの継承」を参照してください。
このプラクティスの例外は、コンテンツ管理システムを含めるまたは除外するのに、スコープを使用することです。一般的なプラクティスは、コンテンツ管理システムのみを伝播するか、コンテンツ管理システムを除くすべてを伝播することです。
  
|
