プロダクション業務ユーザーズ ガイド
|
 |
 |
|
この章では、アプリケーションのエンタープライズ アーカイブ (EAR) ファイルを準備してデプロイする手順について説明します。
注意 : WebLogic Portal では、クラスタまたはスタンドアロンのサーバ コンフィグレーションへのデプロイメントのみがサポートされています。クラスタ化されていない管理対象サーバへの WebLogic Portal アプリケーションのデプロイメントはサポートされていません。
プロダクション環境でポータルをオンラインにするには、まず、ポータル アプリケーションを準備する必要があります。一般的な準備手順には、製品のデプロイメント記述子の変更、関連するすべてのコンパイル済みクラスを使用したエンタープライズ アーカイブ (enterprise archive : EAR) のビルド、その EAR をアーカイブに圧縮するかどうかの決定などが含まれます。
J2EE アプリケーションと同様に、ポータル アプリケーションにも、プロダクション環境に合わせて調整できるデプロイメント記述子があります。
ポータル アプリケーションの場合は、/META-INF ディレクトリに一連のデプロイメント記述子が格納されています。たとえば、キャッシュのコンフィグレーション、行動追跡、キャンペーン、コマースの税金などの設定を定義するポータル固有のデプロイメント記述子 application-config.xml などがあります。プロダクション環境に必要なこれらの値が既存の開発環境の設定と異なる場合は、ポータル アプリケーションをビルドする前に、このファイルを適宜変更します。
ポータル Web アプリケーションの場合は、/WEB-INF ディレクトリに、プロダクション環境に合わせて変更できる一連のデプロイメント記述子が格納されています。
web.xml : J2EE 標準のデプロイメント記述子。他の設定との間で、この記述子は Web アプリケーションのセキュリティをコンフィグレーションする一連の要素を保持します。web.xml の詳細については、「web.xml デプロイメント記述子の要素」を参照してください。注意 : 管理対象サーバ上でポータル アプリケーションを実行している場合、以下のパラメータを web.xml ファイルに追加すると、WebLogic Administration Portal のパフォーマンスを向上させることができます。
<context-param>
<param-name>portalFileDirectory</param-name>
<param-value>/</param-value>
</context-param>
このパラメータは、EAR コンテンツ情報を返す MBean に対し、最適化された呼び出しを利用します。このパラメータがないと、MBean 呼び出しは、.portal ファイルを再帰的に検索します。再帰的な呼び出しによるオーバーヘッドを回避するには、すべての .portal ファイルを 1 つのディレクトリに配置し、portalFileDirectory パラメータでそのディレクトリを指定します。上記の例では、すべての .portal ファイルが、Web アプリケーションのルート ディレクトリ (/) にあります。
このパラメータを使用する場合、すべての .portal ファイルをポータル Web アプリケーションの同じディレクトリに配置する必要があります。<param-value> を使用してディレクトリを指定します。
weblogic.xml : 多数の重要な記述子エントリが含まれる Web アプリケーション用の標準の WebLogic Server デプロイメント記述子。詳細については、「weblogic.xml デプロイメント記述子の要素」を参照してください。注意 : クラスタ化されたプロダクション環境では、weblogic.xml の <session-param> 記述子要素をコンフィグレーションして、セッション レプリケーションがクラスタ内全体で実行されるようにすることが重要です。この設定を行わないと、クラスタ内のサーバが停止したときに、ユーザの状態に関する情報がフェイルオーバされません。weblogic.xml には、次のブロックを追加します。
<session-descriptor>
<session-param>
<param-name>PersistentStoreType</param-name>
<param-value>replicated_if_clustered</param-value>
</session-param>
</session-descriptor>
デフォルトでは、PersistentStoreType が設定されていない場合、永続セッション ストレージは無効となります。
プロダクション環境に合わせて一般的に変更される他の weblogic.xml 内の要素には、<jsp-descriptor> があります。プロダクション環境では、一般に、次の変更を行います。
weblogic.xml の既存の <jsp-descriptor> セクションの内側に追加する必要があります。For example:<jsp-param>
<param-name>precompile</param-name>
<param-value>true</param-value>
<param-name>precompileContinue</param-name>
<param-value>true</param-value>
</jsp-param>pageCheckSeconds を -1 に設定し、変更に対する JSP ページのポーリングを無効化する。WebLogic Workshop には、Web サービスを開発する場合に重要なデプロイメント記述子が他にもあります。これらの記述子の詳細については、「WebLogic Workshop の内側」を参照してください。
アプリケーションを EAR ファイルにパッケージ化する前に、WebLogic Administration Portal を使用して、アプリケーションで使用するコンテンツ管理リポジトリを作成します。つまり、ルート リポジトリのみを作成し、コンテンツ ノードとコンテンツ項目は作成しません。リポジトリを作成したら、application-config.xml デプロイメント記述子に登録します。アプリケーション EAR を作成すると、application-config.xml は読み込み専用となり、EAR 内での変更ができません。つまり、アプリケーションが EAR ファイル内にある場合、WebLogic Administration Portal でリポジトリを追加または削除することができません。
リポジトリの作成については、「新しいリポジトリ接続を追加する」を参照してください。
プロダクション環境で特定の Java 仮想マシン (Java Virtual Machine : JVM) を使用する場合は、その JVM の JDK を使用して EAR アプリケーションをコンパイルした方がよいでしょう。JVM を WebLogic Workshop プロジェクト向けに変更するには、[ツール｜アプリケーション プロパティ] で [WebLogic Server] を選択し、使用する JDK ホーム (ルート ディレクトリ) のパスを指定します。
ポータル アプリケーションをプロダクション環境にデプロイするには、まず WebLogic Workshop でそのアプリケーションをビルドして、ポータル アプリケーション内の必要なクラスをコンパイルする必要があります。次の 2 つの方法があります。
ポータル アプリケーションは、コマンドラインで wlwBuild コマンドを使用してビルドできます。このコマンドを使用すると、アプリケーションのビルド プロセスをより簡単に自動化できます。詳細については、「wlwBuild コマンド」を参照してください。
この節では、ポータル アプリケーションの最初のデプロイメントの手順について説明します。
この時点で、ポータル アプリケーションのクラスタへのデプロイメントが可能になります。まず、.ear ファイル (非圧縮 EAR) を管理サーバのファイル システムに配置する必要があります。アプリケーションを変更したときに再デプロイが容易になるよう、このファイルは、アプリケーションのデプロイに常に使用するわかりやすい場所 (管理ドメインのルート ディレクトリなど) に配置します。
管理サーバおよび管理対象サーバへアプリケーションを最初にデプロイする手順、および管理対象サーバを起動する順序は、シナリオによって異なります。表 5-1 では、デプロイメントおよび起動の手順を、シナリオ別に説明します。
ほとんどのコンポーネントは、クラスタと共に管理サーバにも割り当てる必要があります。次の例外があります。
AppNameAdmin は、管理サーバでは不要 (ただし、管理サーバに AppNameAdmin をデプロイしても問題は発生しません)。AppNameDatasync は、対象サーバやクラスタでは不要 (ただし、対象サーバやクラスタに対して AppNameDatasync をデプロイしても問題は発生しません)。管理サーバやクラスタには、このような完全なデプロイメントが必要であり、これが唯一サポートされているコンフィグレーションです。WebLogic Portal のアプリケーション設計には、クラスタ化固有の課題がいくつかあり、ポータル アプリケーションをクラスタ環境で適切かつ最適に実行できるようにするには、これらの課題を解決する必要があります。上記の完全な割り当て方法は、このような設計上の課題を解決するための 1 つの方法です。
管理サーバおよびクラスタ上にデプロイするモジュールの数を減らす場合は、デプロイメント手順で [各モジュールの割り当て] をクリックして、管理サーバから AppNameAdmin の割り当てを解除し、クラスタから AppNameDatasync の割り当てを解除します。
ポータル アプリケーションは管理サーバにデプロイする必要がありますが、管理サーバがポータル アプリケーションのページ操作を提供するために使用されることは、一般的にはありません。
上記の手順では、個々のモジュールを管理サーバやクラスタに割り当てるのではなく、デプロイメント用にアプリケーション全体を割り当てました。これは推奨されるデプロイメント方法です。管理サーバにもクラスタにも、ほとんどすべてのモジュールをデプロイする必要があるため、モジュールを個々に割り当てても、パフォーマンスやディスク容量に関してそれほど大きなメリットがあるわけではありません。
ただし、何らかの理由で対象設定デプロイメントを使用する場合は、以下の推奨事項に従ってください。簡単な方法から難しい方法の順に示してあります。
weblogic.Deployer ユーティリティを実行する。weblogic.Deployer ユーティリティの使い方については、「デプロイメント ツールのリファレンス」を参照してください。weblogic.Deployer main() を呼び出す Java コードを作成して、モジュール引数を渡す。管理対象サーバを起動するシーケンスは重要であり、アプリケーションのデプロイメント状態によって異なります。どの起動シーケンスを使用するかについては、表 5-1 を参照してください。
新しいアプリケーションや更新されたアプリケーションをデプロイしない場合は、管理対象サーバをすべて並行して (同時に) 起動できます。
管理対象サーバを起動して管理サーバにバインドするには、Node Manager を使用する方法も含め、多数の方法があります。初期設定では、ドメインのルート ディレクトリにある startManagedWebLogic スクリプトを使用した方がよい場合があります。このスクリプトは、このサーバ インスタンスの管理対象サーバ名および管理サーバの URL を指定すると実行できます。スクリプトを起動する前に、これを編集して、管理対象サーバのデフォルトのメモリ容量を増やす必要があります。これには、新しい MEM_ARGS 設定を指定します。たとえば、メモリ割り当てを -Xms512m -Xmx512m に変更します。
管理対象サーバを起動したら、管理対象サーバ インスタンス上で適切な URL を表示することで、ポータル アプリケーションをブラウズできます。セッション フェイルオーバーのサポートのみでなく、クラスタへのシングル エントリ ポイントもユーザに提供するには、プロキシ サーバをコンフィグレーションする必要があります。
WebLogic Server のプロキシ プラグインをコンフィグレーションする手順については、「プロキシ プラグインをコンフィグレーションする」を参照してください。
プロキシ プラグインの設定時には、WebLogic Portal 固有のコンフィグレーション タスクはありません。
プロキシ サーバを使用したり、非セキュアなポートとセキュアなポートの間で切り替えているとき、{url:port} または {url:securePort} 変数を使用している場合は URL が解決されないことがあります。これは、その値に対する変数がリクエストから読み込まれるためです。たとえば、非セキュアな ポート (ポート番号 80) にいるユーザが {url:securePort} 変数を使用する URL テンプレートで作成されたセキュアな https リンクをクリックすると、request (80) というポート番号が {url:securePort} 変数に対して使用されますが、これは非セキュアなポートでセキュア リクエスト (https) を作成します。プロキシ サーバ (ポート 80) にいるユーザがプロキシ サーバ (ポート 443) の外にあるリソースへのリンクをクリックした場合も同様です。
どちらの場合も、正しく解決される URL を取得するように、URL テンプレートにポート番号をハード コーディングする必要があります。
URL テンプレートの使用の詳細については、http://edocs.beasys.co.jp/e-docs/workshop/docs81/doc/ja_JP/portal/buildportals/url.html の「ポータル リソースへの URL を作成する」を参照してください。
この節では、ユーザ プロファイルのプロパティ、ユーザ セグメント、コンテンツ セレクタ、キャンペーン、割引などのプロパティ セットが含まれる datasync データの再デプロイメント、部分的な再デプロイメント、および反復的なデプロイメントの手順について説明します。
http://adminserver:port/console) で、[デプロイメント｜アプリケーション] を選択します。更新されたポータル アプリケーションをプロダクション サーバに再デプロイするには、WebLogic Server Administration Console または weblogic.Deployer ツールを使用します。「weblogic.Deployer ユーティリティ」を参照してください。
「コード リスト 5-1」のバッチ ファイルは、weblogic.Deployer を使用してポータル アプリケーションをプロダクションに再デプロイする例を示しています。
コード リスト 5-1 weblogic.Deployer を呼び出すバッチ ファイル
@echo off
echo Redeploys a Portal Web Project to a Server or Cluster
echo First Parameter is the name of the Server or Cluster
echo Second Parameter is the name of the Application
echo Third Parameter is the administrative username for the Portal Server
set SERVER=%1
set APPNAME=%2
set USERNAME=%3
echo server = %SERVER%
echo appname = %APPNAME%
echo username = %USERNAME%
java weblogic.Deployer -redeploy -username %USERNAME% -name %APPNAME% -targets %SERVER%
状況によっては、weblogic.Deployer ツールを使用することで、ポータル アプリケーションの個々のコンポーネントの再デプロイメントに要する時間を削減できます。
更新範囲が特定のポータル Web アプリケーションに限られる場合は、その Web アプリケーションのみを再デプロイして、再デプロイメントに要する時間を大幅に短縮できます。この方法は、新しく更新された範囲がポートレットとページフローのみであり、エンタープライズ アプリケーションの範囲内である EJB、ライブラリ、またはモジュールが更新されていない場合に有用です。
ポータル Web アプリケーションは、WebLogic Workshop の制御クラスと依存関係があるため、これらのクラスも同様に再デプロイする必要があります。次のバッチ ファイルを使用すると、このプロセスを簡略化できます。クラスパスには weblogic.Deployer を追加する必要がありますが、これは BEA_HOME/weblogic81/common/bin/commEnv スクリプトを実行することによって追加できます。
コード リスト 5-2 WebLogic Server のコントロール クラスを再デプロイするバッチ ファイル
@echo off
echo Redeploys a Portal Web Project to a Server or Cluster
echo First Parameter is the name of the Server or Cluster
echo Second Parameter is the name of the Application
echo Third Parameter is the name of the Portal Web Application
echo Fourth Parameter is the administrative username for the Portal Server
set SERVER=%1
set APPNAME=%2
set WEBAPPNAME=%3
set USERNAME=%4
echo server = %SERVER%
echo appname = %APPNAME%
echo webappname = %WEBAPPNAME%
echo username = %USERNAME%
set TARGETS=%APPNAME%@%SERVER%
set TARGETS=%TARGETS%,.workshop/%APPNAME%/EJB/TimerControl_-livsjc6qp6ws@
%SERVER%
set TARGETS=%TARGETS%,.workshop/%APPNAME%/EJB/p13controls_k3cw9vg6497r@
%SERVER%
set TARGETS=%TARGETS%,.workshop/%APPNAME%/EJB/MDBListener_-1x0154i4jz0he@
%SERVER%
set TARGETS=%TARGETS%,.workshop/%APPNAME%/EJB/GenericStateless@%SERVER%
set TARGETS=%TARGETS%,.workshop/%APPNAME%/EJB/ProjectBeans@%SERVER%
java weblogic.Deployer -redeploy -username %USERNAME% -name %WEBAPPNAME% -targets %TARGETS%
WebLogic Portal には、JSR-168 WAR ファイルにパッケージ化された JSR-168 ポートレットを自動的にデプロイするユーティリティが用意されています。このユーティリティを使用して、JSR-168 ポートレットを含む JSR-168 WAR ファイルをインポートし、ポートレットを WSRP プロデューサで公開できます。
この節では、このインポート ユーティリティの使用方法について説明します。この節のトピックは以下のとおりです。
http://servername:port/appName/jsr168/jsr168import.jsp
servername は管理サーバの IP 名、port はポート番号、appName はサーバにデプロイされたポータル エンタープライズ アプリケーションの名前です。次に例を示します。
http://localhost:7001/myProjectAdmin/jsr168/jsr168import.jsp
図 5-1 にこのユーティリティを示します。
図 5-1 JSR-168 WAR インポート ユーティリティ
この節では、インポート ユーティリティを使用して JSR-168 WAR ファイルをエンタープライズ アプリケーションにインポートする方法を説明します。
BEA_HOME/workshop/templates ディレクトリにあります。これらのファイル名はデフォルトの名前です。サイトでこれらのファイルのカスタム バージョンが更新されている可能性があります。通常、これらのファイルの最新変更バージョンを選択します。 新しい EAR ファイルがデプロイされたら、インポートした WAR ファイルに含まれているポートレットをアプリケーションに追加できます。そのためには、Web アプリケーションを WSRP プロデューサとして追加する必要があります。Web アプリケーションをプロデューサとして追加したら、WebLogic Administration Portal を使用してアプリケーションのポートレットを任意の WSRP プロデューサに取り込むことができます。詳細については、Administration Portal オンライン ヘルプの「プロデューサを追加する」を参照してください。
|
|
|