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