| ドキュメントのダウンロード | サイト マップ | 用語集 | |
|
|||
| BEA ホーム | 製品 | デベロッパ・センタ | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Portal > 開発者ガイド > ポートレットの拡張 |
|
開発者ガイド
|
ポートレットの拡張
ポートレットの高度な機能を呼び出したり、それらのポートレットを管理者から利用できるようにするために、開発者はいくつかのツールと数々の手順を用います。 この章では、以下のトピックを扱います。
ポートレットの基本的なカスタマイズ
最も基本的なカスタマイズの 1 つは、あるポータルから別のポータルへポートレットをコピーすることです。 この手順を理解しておけば、この章で取り上げるその他の作業の多くを理解する上で役に立ちます。 ここでは多くの手順とツールを紹介するからです。この節では、以下の基本的なポートレット カスタマイズを扱います。
ポータル Web アプリケーション間でポートレットをコピーする
この節では、一方のポータル Web アプリケーションからもう一方のポータル Web アプリケーションにポートレットをコピーするプロセスについて説明します。ここでは、どちらのポータルも正しくデプロイされているものとします。これら 2 つのポータルと、そのそれぞれに関連付けられている Web アプリケーションを 図 11-1 に示します。
図11-1 ポータルとそれに関連付けられている Web アプリケーション
この例では、あるポータル Web アプリケーション (NewPWApp) から別のポータル Web アプリケーション (NextPWApp) に、flowlet1 というポートレット (図 11-2 に示す) をコピーします。 図11-2 NewWPApp 内の flowLet1 ポートレット
NextPWApp ポータルへ flowLet1 ポートレットを追加するには、以下の手順に従います。
ステップ 1: J2EE リソースを新しい Web アプリケーションにコピーする
E-Business Control Center 内で flowLet1 ポートレットを開くと、それが利用可能なポートレットのリストに含まれているのがわかります。
元のポートレットではカスタム Webflow が使用されているので、コピー先のポータル Web アプリケーションでこのポートレットを使用するには、その Webflow ファイルをコピーする必要があります。NewPWApp の ¥webapps 内の flowLet1 Webflow ファイルを NextPWApp の ¥webapps ディレクトリにコピーする様子を 図 11-3 に示します。
図11-3 ナビゲーション用 Webflow のコピー
また、ポートレット フォルダ flowLet1 を NewPWApp アプリケーション フォルダから NextPWApp Web アプリケーション フォルダにコピーする様子を 図 11-4 に示します。 ポートレットを構成する JSP と画像は、このディレクトリ内に格納されます。 図11-4 J2EE リソースのコピー
これで、J2EE リソースが新しい Web アプリケーションにコピーされたので、 これらのリソースを参照するようにメタデータを編集することができます。 ステップ 2: ターゲット Web アプリケーションのメタデータを編集する 以下の手順に従って、E-Business Control Center を用いて flowLet1 ポートレットを ThatNewPortal ポータルに追加します。
図11-5 ThatNewPortal への flowLet1 ポートレットの追加
ステップ 3: プロジェクトを同期化する
以下の手順に従って、E-Business Control Center を用いてプロジェクトを同期化します。
注意: E-Business Control Center の詳細については、『管理者ガイド』の「E-Business Control Center の設定」 (http://edocs.beasys.co.jp/e-docs/wlp/docs70/admin/sysadmin.htm) を参照してください。
図11-6 [同期] ボタンのクリック
ステップ 4: 新しいポートレットを表示対象かつ利用可能にする
これで、flowLet1 という新しいポートレットがデプロイされましたが、さらに、WebLogic Portal Administration Tools を用いて、それをポータルで利用できるようにする必要があります。
図11-7 [ポータル管理] へのアクセス
図11-8 デフォルト グループ ポータルの選択
図11-9 [ページとポートレットを管理]
図11-10 [ポートレットの編集] のクリック
図11-11 flowLet1 ポートレットに対する [属性を設定] の選択
図11-12 ポートレット属性の設定
図11-13 NextPWApp での flowLet1 の表示
ドメイン間でポートレットをコピーする
両方のドメインが WebLogic Portal の最新リリースのインスタンス上に正しくインストールされデプロイされているものとすると、 そのうちの一方からもう一方にポートレットをコピーする手順は、ポータル Web アプリケーション間でポートレットをコピーする場合の手順とほとんど同じです。すなわち、
図11-14 .portlet ファイル
欠如しているリソースをエラー メッセージを通じて見つける
必要なポートレット リソースがドメイン内になければ、サーバ起動時か、それらのリソースを用いるポータル ページにアクセスしようとしたときに、エラー メッセージが表示されます。 (ポートレット リソースが欠如していても、サーバは起動されます)。
たとえば、404 エラーなどの HTTP セッション エラーや、「機能は現在利用できません。」といったレンダリング時のエラーがブラウザに表示される場合があります。 メタデータの欠如によっても、エラーが発生することがあります。
サーバのコマンド ウィンドウでエラー メッセージを探して、どのリソースが欠けているのか判断します。 たとえば、リスト 11-1 では、WebFlowPortlet というポートレットに header.jsp というファイルが足りないことを示しています。 このメッセージは、このポートレットが含まれているポータル ページにアクセスしたときにコマンド ウィンドウに出力されたものです。
コード リスト 11-1 ポートレット リソースの欠如によって発生するエラー
<Jun 12, 2002 10:38:59 AM MDT> <Error> <HTTP> <101214> <Included resource or file "/NewWebApp/portlets/WebflowPortlet/header.jsp" not found from requested resource "/NewWebApp/framework/portal.jsp".>
また、E-Business Control Center では、ポートレットの編集時にエラーがいくつか捕捉されます。 たとえば、関連付けられている Webflow ファイルが編集中のポートレットに見つからない場合には、警告ダイアログ ボックスが表示されます。
ポートレットのカテゴリを作成する
E-Business Control Center を利用すれば、ポートレットをカテゴリに分類して、より容易に管理できるようになります。 この節では、カテゴリの作成方法とカテゴリ内でのポートレットの管理方法を示します。
カテゴリを扱う準備をする
この節で示す手順に従うには、以下のものをあらかじめ準備しておく必要があります。
警告: E-Business Control Center でポータルを定義する前に新しいカテゴリを作成しようとすると、エラーになります。
ポートレットとカテゴリを作成する
図11-15 カテゴリの新規作成
その結果、図 11-16 に示すようなカテゴリ リストになるはずです。
図11-16 新しいカテゴリ
注意: カテゴリの 1 つを選択すると、図 11-17 に示すように、エクスプローラ ツールバーの右側の 3 つのアイコンが使用可能になります。 図11-17 エクスプローラ ツールバー内のカテゴリ関連アイコン
ポートレットとカテゴリを移動する この節では、E-Business Control Center を用いてポートレットとカテゴリを移動する方法について説明します。
図11-18 カテゴリの [移動] アイコンのクリック
図11-19 カテゴリとポートレット
図11-20 カテゴリ選択後の [カテゴリ名の変更] のクリック
図11-21 カテゴリ名の変更
図11-22 カテゴリへのポートレットの移動
図11-24 整理されたポートレットおよびカテゴリ
既存のカテゴリにポートレットを追加する
この節では、既存のカテゴリに新しいポートレットを追加する方法を説明します。 この例では、以下のポートレットを作成します。
既存のカテゴリにポートレットを追加するには、以下の手順に従います。
注意: ポートレットに名前を付ける際には、図 11-25 に示すように、[ポートレットのカテゴリを選択します。] をクリックします。
図11-25 ポートレット カテゴリの選択
図11-26 既存のカテゴリ内への新しいポートレットの追加
図11-27 各カテゴリ内のポートレット
ポートレットとフレームワーク
BEA WebLogic プラットフォームでは、ポートレットのカスタマイズを幅広くサポートしており、その中には、ポートレットを構成する実際の JSP 内での最小限の Java スクリプト作成が必要にはなるものの堅牢な機能を提供できるように設計された JSP タグ ライブラリなどがあります。 以下のポートレット タイプを作成する際には、この節の説明を参考にしてください。
この節ではこのあと、各ポートレット タイプについて説明し、それぞれの例をいくつか示すとともに、BEA WebLogic プラットフォームを最大限に活用するポートレットを作成するテクニックをいくつか紹介します。
単純 JSP ポートレット
WebLogic Portal プラットフォームに備わっている能力、柔軟性、および使いやすさを一部紹介するために、この節では、以下の例を扱います。
scriptDemo ポートレット
scriptDemo ポートレット (図 11-30 に示す) は、Portal Wizard を用いて作成されたサンプル ポータルの Home ページの左側に表示されます。
準備
これから紹介する例を実際に試してみるには、以下の準備が必要です。
続行する前に
ポータルは、ユーザがログインする前は図 11-28 のように、ユーザがログインしたあとは図 11-29 のように、それぞれ表示されることを確かめてください。
図11-28 匿名ユーザ時の初期画面
scriptDemo ポートレットのインストール 以上で素材が揃ったので、portlet.jsp を入れ替えて動作を変更することで、ポートレットを変えることができます。リスト 11-2 に非常に簡単なスクリプトレットを示しますが、これは、汎用的な Java スクリプトレットを用いてポートレット内でポータル フレームワークとやり取りする方法を示すものです。 コード リスト 11-2 scriptDemo ポートレット (バージョン 1) 手順 この新しいコードを scriptDemo ポートレットに組み込むには、以下の手順に従います。
<center> Test Portlet </center>
<%
<br><hr>
A Simple Java Scriptlet
<br>
/*
新しい String 変数を作成し、その値を空の文字列に設定する。
*/
String userName = "";
/*実際のユーザ名を取得するには、まず getUserPrincipal()メソッドを用いて javax.servlet.http.HttpServletRequest オブジェクトから java.security.Principal オブジェクトを取得する。 このリクエスト オブジェクトは JSP から直接利用できる。 Principal オブジェクトについては、完全パッケージ名を使用すること。
*/
java.security.Principal principal = request.getUserPrincipal();
/*プリンシパル オブジェクトが null の場合には、ユーザはまだログインしていない。この例では、ログインしていない場合を無視する。それには、if 文を用いて、値が null でない場合にのみ値の処理を行うようにする。
*/
if (principal != null)
{
/*
*/
userName = principal.getName();
}
%>
<%-- スクリプトレットを用いて、userName 変数の値を表示する。 スクリプトレットは HTML 内に埋め込まれ、<%= %> ブロックで示されることに注意。
--%>
The user name is : <%= userName %>
<br>
<BEA_HOME>¥portalDomain¥beaApps¥portalApp¥
<PortalWebApp>¥portlets¥scriptDemo¥
図11-30 匿名ユーザ時の scriptDemo ポートレット
ユーザがログインすると scriptDemo ポートレット内のコードによってポータルがどのように表示されるかを、図 11-31 に示します。 ユーザ名が表示されていることに注目してください。
図11-31 ユーザ ログイン後の scriptDemo ポートレット
注意: カスタム ポートレットでの JSP タグの使い方について詳しくは、以下の情報源を参照してください。
ポートレットから ActiveX コンポーネントを呼び出す
ポートレット内から ActiveX コンポーネントを呼び出すには、リスト 11-3 および リスト 11-4 に示すように、HTML の <OBJECT> タグを使用します。
これらのサンプルには CODEBASE パラメータが含まれているため、ローカル マシンのレジストリにコンポーネントがインストールされていない場合には、コンポーネントを Microsoft からダウンロードすることができます。
注意: これらのサンプルでは、ポータルは HTML を介して ActiveX コンポーネントと通信するだけです。HTML はポータルからブラウザに返され、ActiveX コンポーネントをロードして実行するようブラウザに命令します。
コード リスト 11-3 ActiveX を用いた Outlook の呼び出し (予定表の例)
<OBJECT CLASSID="clsid:0006F063-0000-0000-C000-000000000046"
CODEBASE="http://activex.microsoft.com/activex/controls/office/
outlctlx.CAB#ver=9,0,0,3203"
id=OVCtl1 width=100% height=200>
<param name="Folder" value="Calendar">
<param name="Namespace" value="MAPI">
<param name="Restriction" value="">
<param name="DeferUpdate" value="0">
</OBJECT>
コード リスト 11-4 ActiveX を用いた Outlook の呼び出し (受信トレイの例)
<OBJECT CLASSID="clsid:0006F063-0000-0000-C000-000000000046"
CODEBASE="http://activex.microsoft.com/activex/controls/office/outlctlx.CAB#
ver=9,0,0,3203"
id=OVCtl1 width=100% height=200>
<param name="Folder" value="Inbox">
<param name="Namespace" value="MAPI">
<param name="Restriction" value="">
<param name="DeferUpdate" value="0">
</OBJECT>
注意: ActiveX コンポーネントは、その実行が許可される適切なセキュリティ レベルに設定された Microsoft Internet Explorer 内でのみ動作します。
Webflow ポートレット
この節では、まず、Portlet Wizard で作成できる Webflow ポートレットのタイプを示します。 次に、簡単なスクリプト作成の例を用いて、Webflow の基本的側面をいくつか説明します。 この節で扱うトピックは以下のとおりです。
3 種類の Webflow ポートレット
E-Business Control Center の Portlet Wizard では、現在、以下の 3 種類の Webflow ポートレットを生成することができます。
準備
この節では、この章の随所で例として示しているように、アプリケーション NewPWApp に新しい Webflow ポートレットを追加する方法を説明します。 これらの例を実際に試してみるには、ポータル サーバが稼働しており、E-Business Control Center でポータル プロジェクトが開かれていなければなりません。.
ナビゲーション バー Webflow ポートレットの作成
Portlet Wizard を用いてナビゲーション バー Webflow ポートレットを作成する手順を以下に示します。
図11-32 Portlet Wizard の起動
図11-33 Portlet Wizard の使用を選択
図11-34 ナビゲーション ポートレットの命名
図11-35 Home ページへのポートレットの関連付け
図11-36 コンポーネントの選択
図11-37 Webflow コンテンツ タイプの選択
図11-38 「ナビゲーション バー」モデルの選択
図11-39 ページ数の選択
図11-40 リソース ファイルの格納場所の確認
図11-41 ファイル リストの確認
図11-42 次のステップの確認
図11-43 プロジェクトの同期化
図11-44 ナビゲーション バー ポートレットの表示
順次型 Webflow ポートレットの作成
Portlet Wizard を用いて順次型 Webflow ポートレットを作成する手順を以下に示します。
図11-45 Portlet Wizard の起動
図11-46 Portlet Wizard の使用を選択
図11-47 順次型 Webflow ポートレットの命名
図11-48 Home ページへのポートレットの関連付け
図11-49 ポートレット コンポーネントの選択
図11-50 Webflow コンテンツ タイプの選択
図11-51 順次型モデルの選択
図11-52 ページ数の選択
図11-53 リソース ファイルの格納場所の確認
図11-54 ファイル リストの確認
図11-55 次のステップの確認
図11-56 プロジェクトの同期化
図11-57 順次型 Webflow ポートレットの表示
階層型 Webflow ポートレットの作成
Portlet Wizard を用いて階層型 Webflow ポートレットを作成する手順を以下に示します。
図11-58 Portlet Wizard の起動
図11-59 Portlet Wizard の使用を選択
図11-60 階層型ポートレットの命名
図11-61 Home ページへのポートレットの関連付け
図11-62 コンポーネントの選択
図11-63 Webflow コンテンツ タイプの選択
図11-64 階層型モデルの選択
図11-65 ページ数の選択
図11-66 リソース ファイルの格納場所の確認
図11-67 ファイル リストの確認
図11-68 次のステップの確認
図11-69 プロジェクトの同期化
図11-70 階層型ポートレットの表示
ポートレットでの表示更新イベントの処理方法
ポートレットでの Webflow の使い方を示すために、リスト 11-5 内の太字で示したコードを例に、ポートレットで表示更新イベントがどう処理されるかを観察しましょう。
コード リスト 11-5 ポートレットへの表示更新通知の追加
<%@ taglib uri="portlet.tld" prefix="portlet" %>
<%
System.out.println("Calling refresh on flowLet1 portlet.");
%>
<center>
<font size="6" color="green">Portlet 1</font><BR>
<p>
Portlet content with Webflow
<p>
<a href="<portlet:createWebflowURL event="switch1"/>">Next Page</a>
<p>
</center>
上記の例の続きとして、以下の手順に示すように、scriptDemo ポートレットのコードを編集します。
図11-71 コンソール ウィンドウのオープン
<BEA_HOME>¥portalDomain¥beaApps¥portalApp¥<PortalWebApp>¥
portlets¥scriptDemo¥
図11-73 コンソールに出力された表示更新メッセージ
ポートレットでの Webflow 表示更新イベントの概要
Webflow では、表示更新イベントが発生すると、結果的に lastContentUrl というエンティティが呼び出されることになり、これによって、ポートレット名を指定せずにポートレットに表示を更新させることができるようになります。 この例のポータル内のさまざまなボタンやコントロールを操作しつつ、コンソール ウィンドウで表示更新メッセージを確認することで、特定のアクションによって表示更新イベントが発生するタイミングを調べることができます。 flowLet1 に関連付けられている Webflow をもう少し詳しく調べるには、以下の手順に従います。
図11-74 ポータル Web アプリケーション内の Webflow のオープン
図11-75 portal_lastContentUrl にリンクされているノード
デフォルトでは、表示更新は常にポータル全体で呼び出され、すべてのポートレットに対して呼び出すことができます。 専用の Webflow を備えたポートレットであれば、どのようなものでも、すべての表示更新イベントに応答させることができます。 このデフォルト動作をポートレットに組み込むには、Webflow エディタを用いて、ポートレットの Webflow を開き、*.refresh プロキシ ノードを lastContentUrl に設定します。
Webflow の使い方の詳細については、ポータル ナビゲーションのセットアップを参照してください。
ポートレットをカスタム イベントに応答させる
カスタム イベントの説明のために、flowLet1 ポートレットの Webflow におけるナビゲーション マッピング (図 11-76 に示す) について考えてみましょう。
図11-76 flowLet1 の Webflow におけるナビゲーション ノード
content1.jsp と content2.jsp の間のナビゲーションは、switch1 および switch2 という定義済みイベントを用いて実現されます。 これらのコンテンツ ノードの一方を選択することで、flowLet1 ポートレットで content1.jsp と content2.jsp をリンクする Webflow のプロパティを調べることができます。 プレゼンテーション ノード content2 のプロパティの詳細は、図 11-77 に示すとおりです。 図11-77 content2 のマッピング
カスタム イベントの定義 新しいプレゼンテーション ノードにカスタム イベントを割り当てる方法を図 11-78 に示します。 このイベントの名前は myCustomEvent であり、イベント コネクタ ツールを用いて、プレゼンテーション ノード content2 とプレゼンテーション ノード content3 をリンクします。 図11-78 myCustomEvent の定義
カスタム イベントを呼び出す ポートレット内でカスタム イベントを呼び出すには、JSP に以下のコードを追加します。 content3.jsp という新しいプレゼンテーション ノードを追加したあとの flowLet1 の 3 番目の画面を図 11-79 に示します。 図11-79 flowLet1 ポートレットの 3 番目のページ
<a href="<portlet:createWebflowURL event="myCustomEvent"/>">Next Page</a>
ポートレット間で状態を共有する ポートレット間で状態を共有するには、入力プロセッサ (IP) を用いて HttpSession オブジェクト内に引数を設定します。 たとえば、portletA で「foo」というフォームを用いる場合には、IP を用いて「foo」フォームのデータを抽出し、portletB では Pipeline セッションからそのフォーム データを取得することができます。 注意: 入力プロセッサの詳細については、ポータル ナビゲーションのセットアップを参照してください。 Web サービス ポートレット Web サービスは、アプリケーション間の効率的な疎結合型の相互作用を実現する再利用可能なソフトウェア コンポーネントで、迅速かつ低コストのアプリケーション統合のために内部的に用いられることもあれば、インターネットを介して顧客、サプライヤ、あるいはパートナに公開されることもあります。 内部的に、あるいはインターネットを介して、ポートレットで Web サービスを利用できるようになれば、さまざまなメリットが新たに生まれると同時に、開発上の新たな問題点もいくつか出てきます。 注意: 簡単のために、この節では、ローカル ホスト上の Web サービスに接続するポートレットの例を示します。 この節では、以下のトピックを扱います。
Portlet Wizard を用いて Web サービス ポートレットを作成する
Web サービスを利用するポートレットを Portlet Wizard で作成するには、以下の 3 通りの方法があります。
このオプションは、クライアント ポーリングを通じて非同期的に Web サービスを呼び出すポートレットを作成するのに用いることができます。 このタイプのポートレットの作成方法については、「Web サービスを非同期的に呼び出す」の節で説明します。
この節では、Portlet Wizard を用いて各タイプのポートレットを作成する方法を示します。
準備
[プログラム｜BEA WebLogic Platform 7.0｜WebLogic Workshop｜WebLogic Workshop Examples｜Start Examples Server] を選択して、WebLogic Workshop のサンプル サーバを起動します。 「scriptDemo ポートレット」の節で説明したサンプル ポータルを基に作業を始めます。
注意: 以下の例では、scriptDemo、flowLet1、および flowLet2 の各ポートレットは省略されていますが、 以前作成したこれらのポートレットをポータルから削除せずに、これらの Web サービス ポートレット サンプルを完成させます。
ネームスペースの衝突を避ける
上記の呼び出し生成とインタフェースの例ではどちらも、同一クラスのインスタンスを作成し、それらは同じポータル ネームスペース内で動作します。 ネームスペースの衝突を避けるために、各クラスのローカル インスタンスにはユニークな名前を付ける必要があります。 2 番目と 3 番目のポートレットでは、サンプル コードの前に示すように実装クラス名を変更します。
単純フォーム駆動型 Web サービス ポートレットを作成する
最初のポートレットでは、単純なフォーム入力を AccountEJBClient Web サービスに送信し、WebLogic Workshop のサンプル サーバをホストとする単純な銀行口座オブジェクトを作成します。
Portlet Wizard を用いて formLet というポートレットを作成する
図11-80 Web サービス コード タイプの選択
図11-81 サーバの場所の選択
図11-82 生成されるコード タイプの選択
図11-83 [Web サービスの追加] のクリック
図11-84 WSDL の URL の入力
図11-85 操作の取得
図11-86 createNewAccount 操作の選択
図11-87 コードのプレビュー
図11-88 リソース ファイルの格納場所の選択/確認
図11-89 ファイル一覧の確認
図11-90 次のステップの選択
注意: この例では、3 つのポートレットをまず全部作成してから、最後にそれらを一度にデプロイします。
呼び出し生成型 Web サービス ポートレットを作成する
呼び出し生成型ポートレットを使用すれば、ユーザは、WebLogic Workshop サンプル サーバをホストとする Web サービス内に用意されているクラスをリモートで呼び出すことで、銀行口座に預金することができます。
Portlet Wizard を用いて callgenLet というポートレットを作成する
図11-91 Web サービス コード タイプの選択
図11-92 [Web サービス] 画面
http://localhost:7001/samples/ejbControl/
AccountEJBClient.jws?WSDL
図11-93 別の Web サービス WSDL の追加
注意: 操作の下に表示されるパラメータ リストに注目してください。
図11-94 listBigAccounts 操作の選択
図11-95 コードのプレビュー
注意: リスト 11-6 の中では、以下のエントリ (コード内では太字で示されている) は短縮表記されています。
callImpl was originally p_sdl_AccountEJBClient_AccountEJBClient_Impl
callSoap was originally p_sdl_AccountEJBClient_AccountEJBClientSoap
コード リスト 11-6 呼び出し生成型ポートレットのコード
<%@ include file="callgenlet1_include.inc" %>
<%@ taglib uri="portlet.tld" prefix="portlet" %>
<%@ taglib uri="i18n.tld" prefix="i18n" %>
<%@ page import="com.bea.portal.appflow.PortalAppflowConstants"%>
<%@ include file="/framework/resourceURL.inc"%>
<%
sdl_AccountEJBClient.AccountEJBClient_Impl callImpl = new sdl_AccountEJBClient.AccountEJBClient_Impl();
sdl_AccountEJBClient.AccountEJBClientSoap callSoap = callImpl.getAccountEJBClientSoap();
%>
<%
double threshold = 1000;
%>
<%=cnvrtSC(String.valueOf(callSoap.listBigAccounts(threshold)))%>
図11-96 リソース ファイルの格納場所の選択/確認
図11-97 ファイル一覧の確認
図11-98 次のステップの選択
Web サービス インタフェース型ポートレットを作成する
このポートレットでは、ポートレット内に設定されたしきい値を上回る残高の口座を検索し、それらのリストをポートレットに表示します。 ここで重要なのは、このポートレットと Web サービスとの通信方法です。 このポートレットでは、listBigAccounts という自己記述型 WSDL に従って実装されるクラスを用います。
Portlet Wizard を用いて interFaceLet というポートレットを作成する
図11-99 生成されるコード タイプの選択
注意: インタフェース生成型ポートレットの [Web サービス] 画面では、利用可能な操作が表示されないことに注意してください。 その理由は、インタフェース記述を提供されたうえで、必要なメソッドを自分で実装する必要があるからです。
図11-100 interFaceLet の [コード プレビュー] 画面
コード リスト 11-7 interFaceLet のコード
<%@ include file="interFaceLet_include.inc" %>
<%@ taglib uri="portlet.tld" prefix="portlet" %>
<%@ taglib uri="i18n.tld" prefix="i18n" %>
<%@ page import="com.bea.portal.appflow.PortalAppflowConstants"%>
<%@ include file="/framework/resourceURL.inc"%>
<%
sdl_AccountEJBClient.AccountEJBClient_Impl intImpl = new
sdl_AccountEJBClient.AccountEJBClient_Impl();
sdl_AccountEJBClient.AccountEJBClientSoap intSoap =
intImpl.getAccountEJBClientSoap();
...
*/%>
図11-101 リソース ファイルの格納場所の選択/確認
図11-102 ファイル一覧の確認
図11-103 次のステップの選択
図11-104 同期の完了
Web サービス ポートレットをデプロイする
これでポートレットがすべて作成されインストールされたので、あとは、WebLogic Server インスタンスでそれらを利用できるようにする必要があります。 それには、これらのポートレットが動作するポータル Web アプリケーションを、以下の手順に従って再デプロイするだけです。
http://<host>:<port>/console
図11-105 コンソールの左タブ: [デプロイメント｜アプリケーション｜NewPWApp]
図11-106 [ポータル管理] へのアクセス
図11-107 デフォルト グループ ポータルの選択
図11-108 [ページとポートレットを管理]
図11-109 [ポートレットの編集] のクリック
Web サービス ポートレットを閲覧する
これで、ポートレットがすべてデプロイされ、同じポータル ページ内に配置されたので、以下の手順に従って、ポートレットから提供される機能を実際に確かめてみましょう。
http://<host>:<port>/NewPWApp/
図 11-110 に示すような結果になるはずです。
図11-110 口座を入力する前の Web サービス ポートレット
図11-111 口座を入力したあとの Web サービス ポートレット
注意: Web サービスの詳細については、「WebLogic Platform での Web サービスの作成」 (http://edocs.beasys.co.jp/e-docs/platform/docs70/interm/webserv.html) と「WebLogic Workshop の概要」 (http://edocs.beasys.co.jp/e-docs/workshop/docs70/index.html) を参照してください。
Web サービスを非同期的に呼び出す
BEA WebLogic Portal 7.0 では、ポートレットは Web サービスとの間で会話などの非同期通信を行うことができます。 以下の例では、ローカル サーバをホストとする Web サービスとやり取りする単純な会話ポートレットを作成する方法を示します。
図11-112 会話 Web サービス ポートレット
会話ポートレットの概要 この例で作成するポートレットには、ボタンで起動される以下の 3 つのアクションが用意されます。
準備
会話ポートレットを作成する
サンプルの会話ポートレットを作成しデプロイするには、以下の手順に従います。
図11-113 会話ポートレット conversation の作成
コード リスト 11-8 Conversation Web サービス ポートレットの content.jsp
<%@ include file="Conversation_include.inc" %>
<%@ taglib uri="portlet.tld" prefix="portlet" %>
<%@ taglib uri="i18n.tld" prefix="i18n" %>
<%@ page import="org.openuri.www.StartRequest"%>
<%@ page import="org.openuri.www.GetRequestStatusResponse"%>
<%@ page import="org.openuri.www.x2002.x04.soap.conversation.StartHeader"%>
<%@ page import="org.openuri.www.x2002.x04.soap.conversation.ContinueHeader"%>
<%@ page import="weblogic.xml.schema.binding.internal.builtin.VoidType"%>
<%@ page import="com.bea.portal.appflow.PortalAppflowConstants"%>
<%@ page import="com.bea.portal.appflow.PortalAppflowConstants"%>
<%@ include file="/framework/resourceURL.inc"%>
<%
DL_wsdl_Conversation.Conversation_Impl conversationImpl = new
DL_wsdl_Conversation.Conversation_Impl();
DL_wsdl_Conversation.ConversationSoap soap =
conversationImpl.getConversationSoap();
%>
<%
String target = request.getParameter("target");
String conversationID = session.getId();
if ( conversationID == null )
conversationID = "";
%>
<portlet:form event="<%= PortalAppflowConstants.PORTLET_REFRESH %>">
<table border="0" align="center">
<tr>
<td width="100%" align="center">
<table border="0" align="left">
<tr>
<%
if ( target != null
&& target.equals("start")
&& true )
{
try
{
StartHeader startHeader = new StartHeader(conversationID,
"http://localhost:7001/samples/async/Conversation.jws");
VoidType startResponse = new VoidType();
StartRequest begin = new StartRequest(false);
startResponse = soap.startRequest(begin, startHeader);
%>
<td><%=cnvrtSC("Conversation started with ID: " +
String.valueOf(conversationID))%></td>
<%
}
catch (java.rmi.RemoteException e)
{
%>
<td><%=cnvrtSC("Duplicate conversation id for start: " +
String.valueOf(conversationID))%></td>
<%
e.printStackTrace();
}
}
%>
</tr>
</table>
</td>
</tr>
<tr>
<td width="100%" align="center"><input type="submit" name="start"
value="Start"></td>
</tr>
</table>
<br><br>
<input type="hidden" name="target" value="start">
</portlet:form>
<portlet:form event="<%= PortalAppflowConstants.PORTLET_REFRESH %>">
<table border="0" align="center">
<tr>
<td width="100%" align="center">
<table border="0" align="left">
<tr>
<%
if ( target != null
&& target.equals("continue")
&& true )
{
try
{
ContinueHeader continueHeader = new
ContinueHeader(conversationID);
GetRequestStatusResponse status = soap.getRequestStatus(null,
continueHeader);
String result = status.getGetRequestStatusResult();
%>
<td><%=cnvrtSC("Response: " + String.valueOf(result))%></td>
<%
}
catch ( Exception e )
{
e.printStackTrace();
}
}
%>
</tr>
</table>
</td>
</tr>
<tr>
<td width="100%" align="center"><input type="submit" name="continue"
value="Continue"></td>
</tr>
</table>
<br><br>
<input type="hidden" name="target" value="continue">
</portlet:form>
<portlet:form event="<%= PortalAppflowConstants.PORTLET_REFRESH %>">
<table border="0" align="center">
<tr>
<td width="100%" align="center">
<table border="0" align="left">
<tr>
<%
if ( target != null
&& target.equals("finish")
&& true )
{
try
{
VoidType terminateResponse = new VoidType();
ContinueHeader finishHeader = new
ContinueHeader(conversationID);
terminateResponse = soap.terminateRequest(null, finishHeader);
%>
<td><%=cnvrtSC("Conversation terminated.")%></td>
<%
}
catch ( java.rmi.RemoteException e )
{
%>
<td><%=cnvrtSC("Conversation already terminated.")%></td>
<%
e.printStackTrace();
}
}
%>
</tr>
</table>
</td>
</tr>
<tr>
<td width="100%" align="center"><input type="submit" name="finish"
value="Finish"></td>
</tr>
</table>
<br><br>
<input type="hidden" name="target" value="finish">
</portlet:form>
図11-114 会話の開始
Web サービス ポートレット内でのエラー処理
実際の運用場面では、ポートレットの接続先の Web サービスは通常、他のマシンをホストにしており、利用する側の自由にはなりません。 ポータル フレームワークでは、Web サービスに関する問題を処理するために特に用意された以下の 2 つのエラーをポートレットから発生させることができます。
JAXRPCException: 実行時に Web サービスが利用できない場合には、ポートレットは javax.xml.rpc.JAXRPCException を送出します。 生成されるポートレットでこの例外を捕捉することで、JSP にエラー処理を追加します。
注意: JAXRPCException は、サービスの遅延が発生する場合ではなく、接続が拒否される場合に適用されます。
SOAPFaultException: Web サービス ポートレットの作成時に Portlet Wizard で生成された SOAP リクエストを Web サービスで処理できない場合には、javax.xml.rpc.soap.SOAPFaultException が送出されます。 JSP 内でこの例外を捕捉して、コンパイルが失敗しないようにする必要があります。
既存の Web アプリケーションのポータル化
既存の非ポータル Web アプリケーションをポータル フレームワークに移行するには、一定の修正が必要です。 この節では、インストール済みの WebLogic Platform 環境に用意されている例を用いて、このプロセスの概要を説明します。
はじめに
ポートレットに機能を追加する方法の 1 つは、既存の (非ポータル) Web アプリケーションの JSP コードを、ポートレットを構成する JSP に移植することです。 このチュートリアルでは、製品に付属している国際化ポートレットのサンプル コードを手直しして用い、その機能をポートレット内に移植します。図 11-115 と 図 11-116 に示したのは、ユーザ入力に基づいて特定言語向けのコンテンツを表示する国際化サンプル アプリケーションです。
注意: このアプリケーションの起動と操作の詳細については、WebLogic Platform マニュアルの「Personalization サンプル」の章を参照してください。
図11-115 国際化の入力
必要条件 WebLogic Portal 7.0 (サービス パック 1) が正常にインストールされている必要があります。 プロセスの概要 このプロセスは、以下のステップから成ります。
ステップ 1: ポータル Web アプリケーションを作成する
ステップ 2: 2 ページ構成の Webflow ポートレットを作成する
ステップ 1: ポータル Web アプリケーションを作成する
新しいポータル Web アプリケーションを作成して、対象とする新しいアプリケーションの基本構造として使用する手順については、『WebLogic Portal 7.0 開発者ガイド』の「ポータルの新規作成」というチュートリアルを参照してください。
この例では、このポータル Web アプリケーションを NewPWApp と呼びます。
注意: アプリケーションでパーソナライゼーションや国際化などのポータル サービスを利用する場合には、Portal Wizard を用いて作成したポータルに、そうした機能のサポートを追加する必要があります。 ポータルへのこれらの機能の追加について詳しくは、『WebLogic Portal 7.0 開発者ガイド』の「カスタム テンプレートの作成」の章の「ドメインへの全ポータル サービスの追加」という節を参照してください。
ステップ 2: 2 ページ構成の Webflow ポートレットを作成する
新しいドメインに作成したポータル サーバの稼働中に、E-Business Control Center を用いて Portlet Wizard を起動します。 2 ページ構成の Webflow ポートレットを作成し、その名前を i18n とします。 Webflow ポートレットのこうした作成方法の詳細については、「順次型 Webflow ポートレットの作成」の節を参照してください。
注意: 必ず、WebLogic Portal Administration Tools を用いて、ポートレットを表示対象かつ利用可能に設定してください。
ステップ 3: ポートレットのコードを編集する
このステップでは、ポートレット Webflow を使用しパーソナライゼーションを呼び出すように、JSP とプロパティ ファイルを編集します。
Portlet JSP を置き換える
まず、Portlet Wizard で生成された JSP を、パーソナライゼーション サービスを呼び出しコンテンツに応じた動作をする JSP に置き換える必要があります。 リスト 11-9 と リスト 11-10 の内容を以下のディレクトリに保存します。
<BEA_HOME>beaApps¥portalApp¥NewPWApp¥portlets¥i18n
コード リスト 11-9 Page1.jsp
<%---------------------------------------------------------
Copyright (c) 2000-2002 BEA Systems, Inc. All rights reserved.
--------------------------------------------------------%>
<%--------------------------------------------------------
ファイル: Page1.jsp
目的: 国際化の対象言語を選択するためのフォーム入力を収集する。
----------------------------------------------------------%>
<%@ taglib uri="webflow.tld" prefix="webflow"%>
<%@ taglib uri="portlet.tld" prefix="portlet"%>
<%----------------------------------------------------------
有効および無効なフォーム エントリの HTML フォント スタイルを宣言する。
これらは、Webflow による検証が組み込まれたフォームで使用されることになる。
---------------------------------------------------------%>
<% String validStyle = "background: white; color: black; font-family: Arial"; %>
<% String invalidStyle = "background: white; color: red; font-style: italic"; %>
<center>
<%-------------------------------------------------------
ポートレットの検証機能付きフォームを使用する
---------------------------------------------------------%>
<portlet:validatedForm event="switch2" applyStyle="message"
messageAlign="right" validStyle="<%= validStyle %>"
invalidStyle="<%= invalidStyle %>" unspecifiedStyle="<%= validStyle %>">
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td>
<table border="0" cellpadding="6" cellspacing="1" width="100%">
<tr class="header">
<td colspan="2">
Localization of Flickerstick Band Information
</td>
</tr>
<tr class="tablerow1">
<td align="right" valign="top" width="1%">Languages:</td>
<td>
<%----------------------------------------------------------
HTML の標準の select および option の代わりに <webflow:select> と <webflow:option> を使用することで、フォーム検証を可能にする。
----------------------------------------------------------%>
<webflow:select name="language" size="5">
<webflow:option value="en"/>English
<webflow:option value="fr"/>French
<webflow:option value="es"/>Spanish
</webflow:select>
</td>
</tr>
<tr class="tablerow1">
<td align="right" valign="top" width="1%"> </td>
<td>
<input type="submit" name="Submit" value="Show Me!">
</td>
</tr>
<tr class="tablerow2">
<td class="label" colspan="2">
Select the language in which you would like to view Flickerstick information.
</td>
</tr>
</table>
<input type="hidden" name="resultFile" value="Page2.jsp">
<input type="hidden" name="sample" value="<%= request.getParameter("sample") %>"></td>
</tr>
</table>
</portlet:validatedForm>
</center>
コード リスト 11-10 Page2.jsp
<%-----------------------------------------------------------
Copyright (c) 2000-2002 BEA Systems, Inc. All rights reserved.
------------------------------------------------------------%>
<%-----------------------------------------------------------
ファイル: Page2.jsp
目的: 国際化の対象言語を選択するためのフォーム入力を収集する。
----------------------------------------------------------%>
<%@ page import="com.bea.p13n.content.ContentHelper"%>
<%@ page import="com.bea.p13n.content.Content" %>
<%@ taglib uri="cm.tld" prefix="cm" %>
<%@ taglib uri="es.tld" prefix="es" %>
<%@ taglib uri="i18n.tld" prefix="i18n" %>
<%@ taglib uri="portlet.tld" prefix="portlet" %>
<%---------------------------------------------------------
クエリ文字列を合成する
例: isTrackIdentifier='true' && bandName='Flickerstick' && language='en'
----------------------------------------------------------%>
<%
StringBuffer queryStr = null;
String language = request.getParameter("language");if (language != null)
{// クエリ文字列を合成する
queryStr = new StringBuffer();
queryStr.append("isTrackIdentifier = 'true' && bandName = 'Flickerstick' && language = '");queryStr.append(language);
queryStr.append("'");}
//queryStr = new StringBuffer();
//queryStr.append("bandName = 'Flickerstick'");if (queryStr != null)
{%>
<% System.out.println("¥n¥nqueryStr=" + queryStr + "-------------------------------------------¥n¥n"); %><br>Language is: <%= language %><br>
<br>Query String is: <%= queryStr %><br>
<br>ContentHelper.DEF_CONTENT_MANAGER_HOME is : <%= ContentHelper.DEF_CONTENT_MANAGER_HOME %><br>
<%----------------------------------------------------------
選択された言語でページをローカライズする。 今後、
このリクエストで i18n タグを呼び出すと、この言語がデフォルトになる。
-----------------------------------------------------------%>
<i18n:localize language="<%= language %>"/>
<%-----------------------------------------------------------
合成されたクエリ文字列を使用すると、
Flickerstick の曲目が取得される。
-------------------------------------------------------------%>
<cm:select contentHome="<%= ContentHelper.DEF_CONTENT_MANAGER_HOME %>"
sortBy="trackNum" query="<%= queryStr.toString() %>" id="contentArray" failOnError="true"/>
<table border="0" cellspacing="0" cellpadding="0" width="100%">
<tr>
<td>
<table border="0" cellspacing="1" cellpadding="6" width="100%">
<tr class="tableheader">
<%---------------------------------------------------------
曲名と曲番号を示すローカライズ済みメッセージを取得する。
----------------------------------------------------------%>
<td><i18n:getMessage messageName="trackName" bundleName="Page2"/></td>
<td><i18n:getMessage messageName="trackNum" bundleName="Page2"/></td>
</tr>
<% int row = 0; %>
<br>contentArray length is : <%= contentArray.length %><br>
<es:forEachInArray id="nextDoc" array="<%= contentArray %>" type="Content">
<tr class="<%= (row % 2 == 0) ? "tablerow1" : "tablerow2" %>">
<%-------------------------------------------------------------
cm:getProperty タグを用いて bandName プロパティを取得し、
それを用いて、Webflow に渡すパラメータを合成する。
----------------------------------------------------------%>
<td>
<cm:printProperty id="nextDoc" name="trackName" encode="html"/>
</td>
<td>
<cm:printProperty id="nextDoc" name="trackNum" encode="html"/>
</td>
</tr>
<% row++; %>
</es:forEachInArray>
</table>
</td>
</tr>
</table>
<%
}
else
{%>
<b>Please specify one language in your request!</b>
<%
}
%>
<center>
<a href="<portlet:createWebflowURL event="switch1"/>">Previous Page</a>
</center>
国際化用のプロパティ ファイルを保存する
以下のコード リストの内容を次のディレクトリに保存します。
<BEA_HOME>beaApps¥portalApp¥NewPWApp¥portlets¥i18n
たとえば、リスト 11-11 であれば、Page2_en.properties として保存されるでしょう。
コード リスト 11-11 Page2_en.properties
trackName=Track Name
trackNum=Track Number
コード リスト 11-12 Page2_fr.properties
trackName=Nom de Piste
trackNum=Numero do Piste
コード リスト 11-13 Page2_sp.properties
trackName=Nombre de la canción
trackNum=Número de la canción
ステップ 4: コンテンツ リソースをロードする
このステップでは、コンテンツ リソースをパーソナライゼーション ドメインからインポートします。
<BEA_HOME>¥user_projects¥myNewDomain
<BEA_HOME>¥user_projects¥myNewDomain
ステップ 5: アプリケーションをテストする
さて、これで JSP が編集されたので、以下の手順に従って、新しいポートレットの機能を確認してみましょう。
http://<host>:<port>/NewPWApp/
図 11-117 に示すような結果になるはずです。
図11-117 i18n ポートレットの検証
図11-118 i18n ポートレットの結果ページ
パフォーマンス チューニング
この節では、パフォーマンス上の問題のうち、JDBC およびスレッドの設定やいくつかのキャッシュ設定など、WebLogic Portal に特に関係するものを取り上げます。 ポータル アプリケーションのパフォーマンスに影響を及ぼすさまざまな要因は、WebLogic Server に固有のものです。 これらの調整については、『WebLogic Server パフォーマンス チューニング ガイド』 (http://edocs.beasys.co.jp/e-docs/wls/docs70/perform/index.html) を参照してください。
キャッシュを用いてパフォーマンスをチューニングする
プロダクション Web サイトのキャッシングを調節するには、以下の要素について検討します。
コンテンツ管理のキャッシングを調節する
プロダクション Web サイトのコンテンツ管理性能を最適化するために、Content Manager では、キャッシング フレームワークを用いて以下のキャッシュのコンフィグレーションと管理を行います。
documentContentCache
documentMetadataCache
documentIdCache
コンテンツ管理用 JSP タグには、これら以外にも一連のキャッシュが用意されており、それらには以下の方法でアクセスすることができます。
cm:select、cm:selectById、pz:contentQuery、および pz:contentSelector の各 JSP タグの場合には、可能なかぎり useCache 属性を使用します。 そうすることで、DocumentManager (pz:ContentSelector の場合には Rules Manager) を呼び出さなくてもよくなります。
ユーザ属性やドキュメント属性が変わったときに、キャッシュされているコンテンツをクリアするには、com.bea.p13n.content.ContentCache の remove メソッドを使用します。詳細については、『WebLogic Portal Javadoc』で com.bea.p13n.content.ContentCache を参照してください。
cm:select、cm:selectById、pz:contentQuery、および pz:contentSelector の各 JSP タグの場合には、可能なかぎり cacheScope 属性を application に設定します。 この application スコープは、エンタープライズ アプリケーションではなく Web アプリケーションに適用されます。例をリスト 11-14 に示します。
コード リスト 11-14 cacheScope を application に設定
<cm:select id="myDocs" query="riskFactor = 'Low'"
useCache="true" cacheId="myDocs"
cacheScope="application"
max="10" cacheTimeout="300000" />
application というキャッシュ タイプは、ユーザ単位ではなくグローバルなものであり、それを設定するとDocumentManager EJB が呼び出されなくなるので、クエリの処理速度が上がるはずです。
pz:contentSelector の場合には、共有コンテンツを選択する場合にのみ、cacheScope 属性を application に設定します。 たとえば、アプリケーション スコープのキャッシュを用いて非認証ユーザ用のコンテンツを選択するようなアプリケーションを作成するとしましょう。 この場合、アプリケーション スコープを用いているので、すべての非認証ユーザに対して同じコンテンツが表示されます。 アプリケーションでは、認証済ユーザに対しては、セッション スコープのキャッシュに切り換えることで、パーソナライズされたコンテンツを提供します。
ユーザが次に閲覧するドキュメントを、現在閲覧中のドキュメントに基づいて予測できる場合には、常に、ユーザが要求する前に次のドキュメントをキャッシュにロードしておきます。 このような「先行キャッシング」を行うと、ユーザ リクエストに対する WebLogic Portal の応答速度は大幅に向上します (ただし、予測が正しいと仮定した場合の話です。つまり、誰も要求しないドキュメントを先行キャッシングしても、パフォーマンスとスケーラビリティが低下するだけです)。
リスト 11-15 には JSP の一部を示しますが、この中には、ドキュメントの先行キャッシングの例が含まれています。
コード リスト 11-15 ドキュメントの先行キャッシング
<%-- 最初のコンテンツ セットを取得する --%>
<cm:select id="myDocs" query="riskFactor = 'Low'"
useCache="true" cacheId="myDocs"
cacheScope="application"
max="10" cacheTimeout="300000" />
<%-- 各コンテンツの relatedDocId からクエリを生成する --%>
<% String query = null; %>
<es:forEachInArray array="<%=myDocs%>" id="myDoc" type="com.bea.p13n.content.Content">
<% String relId = (String)myDoc.getProperty("relatedDocId", null); %> <es:notNull item="<%=relId%>">
<%
if (query != null)
query += " || ";
else
query = "";
query += "identifier = '" +
ExpressionHelper.toStringLiteral(relId) + "'";
%>
</es:notNull>
</es:forEachInArray>
<%-- cm:select を通じて関係のあるコンテンツをキャッシュにロードする --%>
<es:notNull item="<%=query%>">
<cm:select query="<%=query%>" id="foo" useCache="true" cacheId="relatedDocs"
cacheScope="session" max="10" cacheTimeout="300000" />
</es:notNull>
コンテンツ管理用 JSP タグの詳細については、『JavaServer Pages ガイド』の「パーソナライゼーション JSP タグ」の章 (http://edocs.beasys.co.jp/e-docs/wlp/docs70/jsp/p13njsp.htm) を参照してください。
クラスタ環境でのプロパティ キャッシング
ユーザ、グループといったプロパティ データへのアクセスに要する時間を短縮するために、WebLogic Server の Configurable Entity および Entity Property Manager では、キャッシング フレームワークを用いて以下のキャッシュのコンフィグレーションと管理を行います。
ldapGroupCache
ldapUserCache
entityPropertyCache
entityIdCache
unifiedProfiletypeCache
propertyKeyIdCache
注意: デフォルトでは、これらのプロパティ キャッシュは有効になっています。
クラスタ環境でプロパティ キャッシングが有効になっている場合には、クラスタ内の各サーバは独自にキャッシュを保持し、そのキャッシュは他のサーバにはレプリケートされません。 このような環境では、あるサーバ上のキャッシュに格納されているプロパティが変化しても、別のサーバ上のキャッシュ内のプロパティがそれに合わせて変化するとはかぎりません。 ほとんどの場合、別のサーバ上のプロパティに即座にないしは迅速にアクセスする必要はありません。 ユーザ セッションは単一のサーバに固定されており、キャッシングが有効になっていても、そのサーバ上でユーザが自分自身の設定に対して行った変更は、すぐに反映されます。
ユーザと管理者がクラスタ内の異なるサーバに固定的に割り当てられていると、管理者がユーザのプロパティを変更した場合、現在のセッションの間、ユーザにはその変更が見えない可能性があります。 生存時間 (TTL) の設定に小さな値を指定することで、このような状況を緩和することができます。
クラスタ内の複数のサーバから変更済みのプロパティにすぐにアクセスできるようにする必要がある場合には、プロパティ キャッシングを無効にします。
Discount サービスのキャッシングを調節する
Order サービスと Shopping Cart サービスで注文と価格に関する情報 (割引など) の計算に要する時間を短縮するために、Discount サービスでは、キャッシング フレームワークを用いて以下のキャッシュの作成と管理を行います。
顧客がショッピング カートに商品を追加したり、ショッピング カートから商品を削除したり、チェック アウトを行ったり、あるいは注文を確認したりする際に、Pricing サービスは、カートに入っている商品の価格の決定を担当します。 ショッピング カートに対する割引の影響を計算するために、Pricing サービスは、すべてのグローバル割引についての情報と、現在の顧客に適用されるキャンペーン割引についての情報を取得するよう、Discount サービスに要求します。
割引情報を求める最初のリクエストでは、適用される割引ごとにデータベースへの呼び出しを個別に行う必要があります。 たとえば、グローバル割引が 1 つ定義されているほか、2 つのキャンペーン関連割引を受ける資格が顧客にある場合には、Discount サービスはデータベースへの呼び出しを 3 回行います。 それ以降のリクエストに対する応答時間を短縮するために、Discount サービスではこれらのキャッシュを使用します。
discountCache を調節する
discountCache には、キャンペーン割引のデータが格納されます。 最高のパフォーマンスを得るには、キャッシュの容量を、現在デプロイされているキャンペーン割引の数に設定します。 容量を大きくすればするほど、メモリの消費量が増える可能性があります。
Discount サービスがこのキャッシュに情報を保持する時間 (ミリ秒単位) は、[生存時間] (TTL) プロパティによって決まります。 キャッシュ内の値がタイムアウトしたあとでその値に対するリクエストを受け取ると、Discount サービスはデータベースを呼び出して情報を取得したあと、値をキャッシュに格納する必要があります。 TTL を長くすると、キャッシュに格納されているオブジェクトが要求されたときに行われるデータベース呼び出しの回数が減ります。 クラスタ環境では、TTL は、キャンペーン割引に対する変更がすべてのサーバ上で確実に利用可能になるまでに要する最大時間です。
globalDiscountCache を調節する
グローバル キャッシュの [最大エントリ数] プロパティの値を変更する必要はありません。
Discount サービスがこのグローバル割引用キャッシュに情報を保持する時間 (ミリ秒単位) は、[生存時間] プロパティによって決まります。 その生存時間 (TTL) が経過したあとでグローバル割引情報に対するリクエストを受け取ると、Discount サービスはデータベースを呼び出して情報を取得したあと、値をキャッシュに格納する必要があります。 TTL を長くすると、キャッシュに格納されているオブジェクトが要求されたときに行われるデータベース呼び出しの回数が減ります。 クラスタ環境では、TTL は、グローバル割引に対する変更がすべてのサーバ上で確実に利用可能になるまでに要する最大時間です。
クラスタ環境および非クラスタ環境での Discount サービス用キャッシュ
どちらの環境 (クラスタ環境か非クラスタ環境) でも、割引の優先順位、終了日、あるいはアクティブ/非アクティブ状態を変更すると、WebLogic Portal は該当するキャッシュから割引データをフラッシュします。 キャンペーン割引を変更した場合には、キャンペーン割引用キャッシュから特定の割引データだけがフラッシュされます。 グローバル割引を変更した場合には、グローバル割引用キャッシュからすべての割引データがフラッシュされます。
たとえば、bread という名前の WebLogic Portal ホストにログインし、CampaignDiscount1 という名前のキャンペーン割引を無効にしたとしましょう。 この場合、WebLogic Portal では、bread 上のキャンペーン割引用キャッシュから CampaignDiscount1 をフラッシュします。
クラスタ環境では、クラスタ内のほかのマシンは、キャッシュ内の割引データの TTL が経過するまでは、各マシン上のキャッシュに入っている割引データ (コピー) を引き続き使用します。
キャッシング レルムにおけるグループ メンバシップ TTL を調節する
WebLogic Server のキャッシング レルムには、成功した場合と失敗した場合の両方のレルム ルックアップの結果が格納されます。 WebLogic Portal のキャッシング フレームワークは使用しません。
キャッシング レルムでは、ユーザ、グループ、パーミッション、ACL および認証の各リクエスト用に別個のキャッシュを管理します。 ルックアップをキャッシュに格納し、それによって他のセキュリティ レルムに対する呼び出しの回数を減らすことで、WebLogic Server のパフォーマンスを向上させます。
WebLogic Portal では、キャッシング レルムはデフォルトで有効になっています。 キャッシング レルム内のすべてのキャッシュがパフォーマンスの向上に役立つのに対して、特にグループ メンバシップ キャッシュの生存時間 (TTL) の値は、WebLogic Portal のパフォーマンスに影響を及ぼす可能性があります。
さらに、ユーザを先にグループから削除せずにシステムから削除すると、グループ メンバシップ キャッシュの TTL が経過するまでは、そのユーザは引き続きシステムから認識されることに注意してください。
グループ メンバシップ TTL の調節については、『WebLogic Server 管理者ガイド』 (http://edocs.beasys.co.jp/e-docs/wls/docs70/adminguide/index.html) を参照してください。
JDBC におけるスレッド/接続パラメータをチューニングする
ポータルで発生するパフォーマンス上のある種の問題は、config.xml 内のエントリを変更して、WLS 内のデフォルト実行キューのスレッド数を、commercePool に指定されている接続プール最大容量より少な目に設定することで、是正される場合があります。 基本的には、接続プール内の接続の数がスレッド数 + 1 に等しくなるようにすべきです。
スレッドおよび接続プールの調節については、「JDBC 接続プールの最大サイズのチューニング」 (
http://edocs.beasys.co.jp/e-docs/wls/docs70/perform/WLSTuning.html#1117878) を参照してください。
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||