プロダクション業務ユーザーズ ガイド
|
 |
 |
|
ポータル コンフィグレーションをある環境から別の環境に正しく移行する手順は、多くの変動要素によって異なります。すべての状況に適用される単一の手順を規定することは不可能です。したがって、ポータル アプリケーションの移行または伝播を試行する前に、方針の計画、適切なツールの選択、および推奨されるベスト プラクティスに基づいた一連の手順の開発を行うことが重要です。この章では、ポータル資産の移行または伝播を試行する前に考慮する必要のある項目について説明します。
伝播とは、具体的に言うと、ポータル アプリケーションのデータベース コンテンツをあるサーバ環境から別のサーバ環境に移行することです。この処理を行うために、BEA では、Propagation Utility というツールを用意しています。このツールについては、「Propagation Utility の内部」および「Propagation Utility の使用」で詳細に説明します。BEA では、ステージング環境のデータベースから、WebLogic Workshop にインポートできるファイルにポータル資産を移行するためのエクスポート/インポート ユーティリティも用意しています。エクスポート/インポート ユーティリティについては、「エクスポート/インポート ユーティリティの使用」を参照してください。このユーティリティでは、WebLogic Workshop 環境からステージング環境のデータベースへのポータル資産の移行と結合も行うことができます。
図 6-1 に、ポータル資産が相互に移行される 3 つの典型的な環境を示します。
一般には、WebLogic Portal アプリケーションは EAR ファイル、LDAP リポジトリ、およびデータベースから構成されます。EAR ファイルには、JSP や Java クラスなどのアプリケーション コードと、ポータル、ポートレット、および datasync データを定義するポータル フレームワーク ファイルが含まれています。組み込み LDAP には、資格、ロール、ユーザ、グループなどのセキュリティ関連データが含まれています。データベースには、ポータル フレームワークと datasync 要素の表現が含まれています。
この節では、ポータル データを 4 つのカテゴリに分割し、各カテゴリに分類されるデータのタイプを一覧表示します。カテゴリは次のとおりです。
/data サブディレクトリにエクスポーズされます。このデータは EAR ファイルと共にデプロイされます。送り先サーバがプロダクション モードで稼働している場合、datasync データはデータベースに配置されます。 表 6-1 に、これらの各カテゴリを構成するデータの種類を示します。
注意 : EAR データは、開発者が WebLogic Workshop を使用して生成するファイルから構成されます。WebLogic Workshop で EAR データに変更を加えた場合 (たとえば、テーマの変更など)、これらの変更をステージング環境に移行する唯一の方法は、EAR ファイルを再デプロイすることです。ただし、Administration Portal で作成されたデスクトップ、ブック、ページには、通常は EAR データへの参照が含まれています。たとえば、管理者は、Administration Portal を使用して特定のテーマをページに割り当てることができ、実際のテーマ ファイルへの参照はデータベース内で管理されます。Propagation Utility を使用してデスクトップを別の環境に伝播すると、これらの参照が伝播されますが、参照が指している実際のファイル (たとえば、.theme ファイルなど) は伝播されません。EAR デプロイメントと Propagation Utility については、以下の節で説明します。
以下の節では、環境間でポータル データを移行するために BEA が提供しているツールについて説明します。
伝播方針を開発する際に、ある環境から別の環境にポータルを伝播するのに役立つツールを知っておくことが重要です。この節では、自由に使用できる主要ツールとその目的を紹介します。
WebLogic Server Administration Console を使用して、エンタープライズ アプリケーションの EAR ファイルを対象サーバにデプロイします。どの伝播でもほぼ必ず、最初の手順は EAR デプロイメントです。EAR ファイルは、WebLogic Workshop を使用して変更が行われたときには必ず再デプロイする必要があります。たとえば、開発者が .portal ファイルのページの追加または削除、コンテンツ セレクタの定義、新しいポートレットと関連 Java リソース (JSP など) の追加を行った場合は、EAR ファイルを構築およびデプロイして、これらの変更を新しい環境に伝播する必要があります。
EAR デプロイメントの詳細については、「EAR ファイルの準備とデプロイ」を参照してください。
Propagation Utility は、ポータル フレームワーク、datasync、セキュリティ データなど、あるポータル ドメイン環境のコンフィグレーション コンテンツを別のポータル ドメイン環境に伝播するプロセスをガイドします。たとえば、ステージング環境からプロダクション環境にポータル アプリケーションを移行する場合に、Propagation Utility が役立ちます。
ヒント : Propagation Utility を使用してポータルを伝播する前に、必ず最初に対象環境で EAR ファイルをデプロイしてください。
Propagation Utility には以下の機能があります。
GUI ベースの Propagation Utility の使用の詳細については、「Propagation Utility の使用」を参照してください。
Datasync データには、キャンペーン、カタログ定義、コンテンツ セレクタ、割引、プレースホルダ、ユーザ セグメント、ユーザ プロファイル定義などのパーソナライゼーション コンポーネントがあります。これらのコンポーネントは、エンタープライズ アプリケーションの /data ディレクトリに格納されます。
注意 : datasync データは、Propagation Utility または Datasync Web アプリケーションを使用して伝播できますが、通常は Propagation Utility をお勧めします。Datasync Web アプリケーションを使用する必要があるのは、キャンペーン データを伝播する必要がある場合だけです。Propagation Utility ではキャンペーン データが無視されます。
Datasync Web アプリケーションを使用するには、最初に EAR ファイルを送り先サーバにデプロイする必要があります。Datasync Web アプリケーションは、ファイルベースの datasync データをアプリケーションのデータベースと同期させます。つまり、Web アプリケーションは、コンテンツ セレクタ ファイル (.sel ファイル) などの datasync データをデプロイされた EAR から取得し、そのデータをデータベースに結合します。
datasync データおよび Datasync Web アプリケーションの使用の詳細については、「Datasync Web アプリケーションの使用」を参照してください。
エクスポート/インポート ユーティリティでは、デスクトップ、ブック、およびページをデータベースから .portal ファイルにエクスポートできます。この .portal ファイルは、開発者によって WebLogic Workshop で開かれ、変更されてから、エクスポート/インポート ユーティリティを使用してデータベースに再結合されます。したがって、このユーティリティを使用すると、開発者は開発環境とステージング環境の間、または開発環境間でポータル資産を「ラウンド トリップ」で移行できます。
このユーティリティでは、操作のスコープを以下のレベルに設定できます。
また、このユーティリティでは、オブジェクトの結合方法を決定するルールのセットを指定できます。エンタープライズ アプリケーション スコープ (最上位レベル) からブック内のページまで、さまざまなスコープ設定ルールを指定することもできます。この柔軟性により、資産が結合された場合でもユーザおよび管理者のカスタマイズが失われないことを保証できます。
エクスポート/インポート ユーティリティの詳細については、「エクスポート/インポート ユーティリティの使用」を参照してください。
BEA が提供している各伝播ツールでは、ポータル Web アプリケーションをある環境から別の環境に移行するために必要な作業の大部分が処理されます。ただし、移行を成功させるために実行する必要のある手動手順があります。これらの手順は、設計上必須の場合があります。たとえば、一部のセキュリティ データは意図的に伝播されません。ツール自体の既知の制限に関連するケースもあります。たとえば、キャンペーン データとコンテンツ管理システムからのデータの伝播は現在サポートされていません。これらのケースについては、できるだけ明確に文書化し、対処方法を説明しています。
手動伝播手順の詳細については、「伝播の前の手動変更」を参照してください。
BEA では、あるデータベース環境から別のデータベース環境に WebLogic Portal 資産を伝播する手段としてデータベース ベンダ ツールの使用をサポートしていません。
表 6-2 に、伝播のタイプと伝播する変更の種類に応じて使用する適切な伝播ツールを示します。「伝播する変更」カラムの項目については「伝播できるデータの種類」で定義し、示されているツールについては「BEA 提供の伝播支援ツール」に要約しています。
たとえば、表の最初の行は、開発環境からステージング環境への初期デプロイメントを行う場合には EAR ファイルのデプロイのみ行うことを示しています。
* 「プロダクション モードと開発モード」を参照してください。
伝播方針を計画する際には、システムのロードマップを開発することが重要です。この節では、開発環境、ステージング環境、およびプロダクション環境を含む典型的なシステムの相互関係を説明します。図 6-2 のロードマップは、ポータルがこれらの環境でどのように移行されるか、またそれらを移行するために使用されるツールを示します。
この節は、ポータルが置かれているさまざまなシステム間の接続だけでなく、これらのシステム間でポータルを移行または伝播するために使用されるツールと方法を理解できるようにすることを目的としています。図の番号の付いた部分については、この節の残りの部分で詳細に説明します。以下の節を読むときに、この図を参照してください。
開発環境ポータル開発は、通常は個々のクライアント マシンで WebLogic Workshop を使用しているチームのメンバーが分担します。複数開発者ポータル開発環境の設定の詳細については、「チーム開発環境の管理」を参照してください。
ファイルが、IDE ベース環境の主要な、場合によっては唯一の成果です。開発者は、WebLogic Workshop を使用して、Java Pageflow、コントロール、JSP など、ポータルで使用される Java コンポーネントを作成できます。WebLogic Workshop で、開発者はポートレット、ポータル、ルック アンド フィール、レイアウトなども作成できます。これらすべてのコンポーネントは、.java、.jsp、.jpf、.jcs、.portal、.pinc、.portlet、.laf などのファイルに格納されます。
ソース コントロール通常、開発はソース コントロール システムと関連して行われます。「チーム開発環境の管理」で説明しているように、共通ドメインはチームに対して設定されますが、Web アプリケーション自体はソース コントロールにチェックインされます。個々の開発者は、ファイルをチェックアウトして変更し、ソース コントロールに再びチェックインできます。構築された EAR ファイルもソース コントロールにチェックインできます。
「チーム開発環境の管理」では、チーム開発環境でのソース コントロールの使用について説明しています。
開発からステージングへの移行開発が完了したら、EAR ファイルをステージング環境にデプロイできます。この処理を最も簡単に行う方法は、FTP を使用して EAR をステージング サーバに移行し、WebLogic Server Deployment 機能を使用して EAR を J2EE サーバ環境にデプロイすることです。詳細については、「EAR ファイルの準備とデプロイ」を参照してください。
注意 : WebLogic Workshop から Administration Portal を実行できます。Administration Portal が使用されるたびに、出力がファイルではなくデータベースに格納されます。したがって、開発で Administration Portal を使用してデスクトップ、ユーザ、グループ、資格、またはその他の管理機能を作成する場合は、その情報がデータベースに格納されます。データベース内の資産は EAR ファイルに組み込まれず、EAR を移行およびデプロイするときに転送されません。
ヒント : ポータル開発でのベスト プラクティスは、ステージング環境またはプロダクション環境でのみ WebLogic Administration Portal を使用することです。Administration Portal を開発環境で使用する場合は、Propagation Utility を使用してデータベース資産を移行する必要があります。
ステージング環境 ステージング環境では、Administration Portal を使用して、開発で作成されたポータル コンポーネントのデスクトップへの組み立て、ユーザとグループの作成、管理特権の割り当て、委託管理権のコンフィグレーション、ブックやページの変更などを行います。Administration Portal を使用してポータルを変更する場合は常に、その時点以降すべてのポータル資産がデータベースに格納されることに注意してください。WebLogic Workshop で作成された .portal および .pinc ファイルへの接続は失われます。
ヒント : エクスポート/インポート ユーティリティを使用して、データベースに格納されているポータル資産をファイルに戻すことができます。ポータル資産をプロダクション環境に (データベースからデータベースに) 移行する場合のベスト プラクティスは、Propagation Utility を使用することです。
エクスポート/インポート ユーティリティの詳細については、「エクスポート/インポート ユーティリティの使用」を参照してください。Propagation Utility の詳細については、「Propagation Utility の使用」を参照してください。
ステージング環境でのソース コントロールステージング環境ではソース コントロールを使用することがベスト プラクティスです。ソース コントロールに格納する 2 つのコンポーネントは、Web アプリケーションの EAR ファイルとアプリケーションのポータル固有資産、つまりインベントリです。Web アプリケーションからインベントリを最も簡単に抽出する方法は、Propagation Utility を使用してインベントリを ZIP ファイルにエクスポートすることです。
Propagation Utility の詳細については、「Propagation Utility の使用」を参照してください。
プロダクション環境への移行Propagation Utility では、ステージングされたポータル アプリケーションを実際のプロダクション環境に移行できます。
注意 : Propagation Utility は、ステージングで作成されたポータル インベントリ ZIP ファイルを読み取り、ステージング インベントリと現在のプロダクション インベントリ間の差分をレポートします。この時点で、これらの差分を表示し、伝播に進むかどうかを決定できます。差分には、追加、削除、または更新されたポータル資産などがあります。たとえば、ステージングでページがデスクトップに追加された場合、そのページがプロダクション環境になければ、そのページが追加されたことが Propagation Utility によってレポートされます。同様に、ページがプロダクション環境から削除された場合は、そのページが削除されたことが Propagation Utility によってレポートされ、再び追加するかどうかを選択するオプションが与えられます (まだステージング サーバにある場合)。
EAR デプロイメントの詳細については、「EAR ファイルの準備とデプロイ」を参照してください。
Propagation Utility の詳細については、「Propagation Utility の使用」を参照してください。
WebLogic Portal をデプロイする各サイトについて、ある環境から別の環境にポータル アプリケーションを伝播する方針を開発することが重要です。伝播方針を計画する際には、サイトの構造とポータル開発の方法を慎重に評価することが役立ちます。考慮する必要のある問題として、以下のものがあります。
次の節では、一般的な伝播のシナリオと、それぞれのシナリオで使用されるツールおよび方法について説明します。
使用可能な伝播ツールについて理解したら、次の課題はそれらのツールをいつどこで使用するかを決定することです。この節では、複数の一般的な伝播のシナリオを示し、ベスト プラクティスを提案します。
この節で概説するシナリオでは、図 6-3 に示すように、別々の開発サーバ、ステージング サーバ、およびプロダクション サーバがある環境を想定します。
開発環境では、開発者は WebLogic Workshop を使用してポータルとポートレットを作成します。この環境では、すべてのポータル関連データがファイルベースです (.portal ファイルや .portlet ファイルなどの XML ファイルに格納されています)。開発の完了時に、Java ファイルと JSP ファイル、コンフィグレーション ファイル、datasync ファイルなどのこれらのファイルベース資産がまとめられて EAR ファイルに圧縮されます。
ステージング環境は、開発環境とは別のサーバに設定されています。ステージング サーバは、アプリケーションをテストし、さらにコンフィグレーションするために使用されます。ステージング環境では、管理者は Administration Portal を使用してポータル デスクトップの作成と配置、ポータル リソースの資格の付与、テストを目的としたユーザとグループの作成などを行います。
プロダクション環境は、「実稼働」の Web サイトです。この環境では、ユーザがポータル アプリケーションにアクセスしてこれを使用します。管理者とユーザの両方が、プロダクション環境でポータルに変更を加えることができます。管理者は、Administration Portal を使用して変更を有効にし、ユーザは訪問者ツールを使用して個々のポータル ビューをカスタマイズします。
EAR ファイルをサーバに初めてデプロイする場合の手順は比較的簡単です。通常、開発者は WebLogic Workshop を使用してポータル、ポートレット、およびその他のアプリケーション機能を作成し、新しいアプリケーションをステージング サーバにデプロイします。
EAR ファイルのデプロイの詳細については、「EAR ファイルの準備とデプロイ」を参照してください。
注意 : WebLogic Administration Portal を使い始めると、EAR に格納されているデータは EAR から自動的に取得され、ステージング サーバのデータベースに格納されます。この時点以降、ポータルに対するすべての変更はデータベースでのみ行われます。変更は EAR ファイルに反映されません。
再デプロイの場合は、対象サーバがステージング サーバまたはプロダクション サーバであると想定されます。前に説明した初回デプロイメントの場合と同様に、再デプロイの最初の手順は EAR ファイルを構築してステージング サーバに移行し、WebLogic Server コンソールを使用して EAR をステージング サーバにデプロイすることです。
ヒント : WebLogic Server コンソールを使用したアプリケーションの再デプロイの詳細については、「アプリケーションの再デプロイ」を参照してください。
アプリケーションを再デプロイする場合は、デプロイ先のサーバが開発モードとプロダクション モードのどちらであるかに応じて注意事項があります。ドメインの作成時にサーバのモードを選択することを思い出してください。プロダクション モードのサーバは、開発モードのサーバよりも効率的に稼働するように最適化されています。
エンタープライズ アプリケーションを再デプロイする場合は、EAR ファイルと展開された EAR ファイルのどちらをデプロイするかを選択できます。デプロイメント時に datasync データが処理される方法は、(a) 展開された EAR ファイルと EAR ファイルのどちらをデプロイするか、また (b) サーバが開発モードとプロダクション モードのどちらであるかによって決まります (「プロダクション モードと開発モード」も参照してください)。
図 6-4 に示すように、エンタープライズ アプリケーションをデプロイする場合は、EAR ファイルをプロダクション モードのサーバに再デプロイする場合を除いて、datasync データが /data ディレクトリ (ファイルシステムにデプロイされています) に配置されます。プロダクション モードのサーバに再デプロイする場合は、Propagation Utility または Datasync Web アプリケーションを使用して datasync 資産を対象サーバのデータベースに移行する必要があります。
図 6-4 エンタープライズ アプリケーションにデプロイする場合に Datasync データが配置される場所
EAR ファイル (展開された EAR ではない) をプロダクション モードのサーバに再デプロイする場合は、datasync データを別の操作で伝播する必要があります。
ヒント : ベスト プラクティスは、常に Propagation Utility を使用して datasync データを移行することです。ただし、Datasync Web アプリケーションを使用する必要のある状況もあります。たとえば、Propagation Utility のスコープがデスクトップ レベルに設定されている場合、datasync データは伝播されません (datasync データはエンタープライズ アプリケーション レベルにあるため、この場合はスコープの範囲外になります)。
エンタープライズ アプリケーションをステージング環境からプロダクション環境に伝播する場合は、対象サーバがプロダクション モードにあると想定されます。プロダクション サーバをプロダクション モードにすることがベスト プラクティスです。ただし、サイトが「実稼働」のプロダクション サーバを開発モードで実行することを妨げるものはありません。対象サーバが開発モードで実行されている場合は、EAR のデプロイ時に datasync データが自動的に移行されることに注意してください。対象がプロダクション モードで実行されている場合、EAR ベースの datasync データは無視されます。
ステージング環境からプロダクション環境への伝播の基本的な手順は次のとおりです。
注意 : 通常、2 つの環境は同期していません。前回の伝播以降、プロダクション サーバとステージング サーバの両方に対して変更が行われた可能性があります。「シナリオ 5 : プロダクションからステージングへの伝播 : 両方とも変更されている場合」を参照してください。
ヒント : 設計上、ユーザとグループは Propagation Utility によって伝播されないことに注意してください。したがって、通常、グループ (ユーザを含む) などの項目は、プロダクション サーバで手動で再作成する必要があります (ただし、ステージング サーバとプロダクション サーバが同じ LDAP ディレクトリを共有し、この認証情報が LDAP に格納されている場合、ユーザとグループの再作成は不要です)。LDAP 伝播の詳細については、「セキュリティ情報と伝播」を参照してください。
エンタープライズ アプリケーション全体を伝播しない場合は、スコープを調整できます。たとえば、Propagation Utility を使用してデスクトップのみ伝播できます。この場合、datasync データはエンタープライズ アプリケーション スコープにあり、デスクトップ スコープには含まれないため、伝播されないことに注意してください。したがって、この状況では datasync データを伝播するための方針が必要です。
デスクトップ スコープでの伝播の基本手順は、前の節で説明したエンタープライズ スコープの場合と同じです。
ヒント : ベスト プラクティスとして、最初にスコープをエンタープライズ アプリケーション レベルに設定してから、デスクトップ レベルに設定することをお勧めします。
デスクトップ スコープ外にある datasync データを伝播するには、Datasync Web アプリケーションを使用します。この処理を行うための推奨方法は、新しい datasync ファイルを JAR ファイルに配置して、JAR ファイルをプロダクション サーバに移行することです。次に、Datasync Web アプリケーションをその JAR ファイルに対して実行します。Datasync Web アプリケーションは、指定されたファイルをプロダクション サーバのデータベースに挿入 (ブートストラップ) します。Datasync Web アプリケーションの使用の詳細については、「Datasync Web アプリケーションの使用」を参照してください。
プロダクション環境コンフィグレーションをステージング環境に戻すことが必要な場合があります。通常はこの操作により、管理者と開発者が新しい機能の追加や既知の問題の修正を行うことができます。この伝播に関連する問題は、管理者とユーザの両方のカスタマイズがプロダクション システムに対して行われている場合があることです。たとえば、管理者が新しいデスクトップの追加またはページの削除を行っている場合があります。ユーザは、訪問者ツールを使用して個々のポータルのビューをカスタマイズしている場合があります。
このシナリオが複雑になるのは、アプリケーションが最後に伝播された後で追加の開発とカスタマイズがステージング環境で行われている可能性があるためです。そのため、2 つの環境の差分を識別して、どの変更を保持し、どの変更を削除するかを決定することが問題になります。
Propagation Utility では、ソース環境と対象環境の間の差分がレポートされます。Propagation Utility のポリシーでは、ポータル資産を結合する場合のルールを設定できますが、その差分を確認し、対象に対して意図した変更が行われていることを確認する必要があります。
注意 : ユーザのカスタマイズは伝播されませんが、送り先で保持されます。Propagation Utility では、別の変更によって衝突が発生する場合などの特定の状況でのみ、送り先サーバでユーザ カスタマイズが変更または削除されます。たとえば、ユーザがポートレットをカスタマイズし、ポートレットが削除された場合、削除されたポートレットを参照するユーザ カスタマイズは削除されません。詳細については、「ユーザ カスタマイズと伝播」を参照してください。
ヒント : Administration Portal を使用してステージング環境に変更を加えた場合、EAR ファイルが圧縮されていると、行った変更はデータベースに保存されます。EAR が圧縮されていない (展開されている) 場合、変更はファイルシステムに書き込まれます。EAR ファイルを後で再デプロイする場合は、変更した datasync 要素を伝播する必要があります。Propagation Utility または Datasync Web アプリケーションを使用して datasync データを移行できます。詳細については、「Datasync Web アプリケーション」および「プロダクション モードと開発モード」を参照してください。
エクスポート/インポート ユーティリティでは、デスクトップ、ブック、およびページを開発 (WebLogic Workshop) 環境とステージング環境の間で相互に伝播できます。開発からステージングへの伝播と開発への再伝播をラウンド トリップと呼びます。
エクスポート/インポート ユーティリティでは、ステージング データベースのデスクトップ、ブック、およびページが、WebLogic Workshop に読み込むことのできる .portal ファイルと .pinc ファイルにエクスポートされます。このユーティリティでは、.portal ファイルと .pinc ファイルをステージング データベースにインポートすることもできます。インポートおよびエクスポートのスコープは、ライブラリ、デスクトップ、または訪問者のレベルに設定できます。
警告 : 新しいブックやページなどの新しい資産が Administration Portal で作成された場合は、その資産に対してユニークな識別子が生成されます。これらの定義ラベルが初めて伝播された (またはエクスポート/インポート ユーティリティで移行された) 後は、これらの定義ラベルを変更しないことがベスト プラクティスです。リソースの定義ラベルを変更した場合、エクスポート/インポート ユーティリティは、リソースを更新されたリソースではなく新しいリソースと見なします。その結果、エクスポート/インポート ユーティリティでは、更新操作ではなく追加操作が実行されます。
ヒント : エクスポート/インポート ユーティリティの重要機能は、ファイルベースの資産を開発環境からデータベースベースのステージング環境に結合できることです。つまり、アプリケーションをファイルベースの開発環境にエクスポートし、開発環境で変更を加えた場合は、エクスポート/インポート ユーティリティを使用して、これらの変更をステージング環境のデータベースに結合できます。
ドメインをコンフィグレーションする場合は、開発モードまたはプロダクション モードを選択できます。ベスト プラクティスとして、プロダクション (実稼働) 環境はプロダクション モードでの方が効率的に稼働するため、このモードにすることが有効です。ただし、実際のプロダクション サーバを開発モードで実行するサイトもあります。サーバのモードを知ることは、特定のポータル資産がどのように伝播されるかを理解するために重要です。たとえば、EAR ファイルをプロダクション モードのサーバにデプロイする場合は、datasync データが無視されます。
|
|
|
