| ドキュメントのダウンロード | サイト マップ | 用語集 | |
|
|||
| BEA ホーム | 製品 | デベロッパ・センタ | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Portal > 管理者ガイド > システム管理 |
|
管理者ガイド
|
システム管理
WebLogic Portal でのシステム管理は、バックアップと回復処理などの従来のシステム管理タスクと、データベースの切り替えやクラスタ化された環境のコンフィグレーションの手助けなど、WebLogic Portal に必要なタスクを呼び出します。
この節では、以下の内容について説明します。
Configuration Wizard 後のタスク
Configuration Wizard を使用して、クラスタ化された WebLogic Portal ドメインを作成すると、ドメインを作成した後で行わなければならない作業がいくつかあります。 http://edocs.beasys.co.jp/e-docs/platform/docs70/template/wlptemp.html#1008419 の「WebLogic Portal ドメイン テンプレート」を参照してください。
サーバの起動と停止
この節では、WebLogic Portal サーバの起動と停止について説明しますが、Configuration Wizard を使用して WebLogic Portal ドメインを作成したという前提で話を進めます。
WebLogic Portal サーバの起動と停止を行うスクリプトはすべて、WebLogic Portal ドメイン ディレクトリに置かれます。以下の節では、さまざまなサーバ コンフィグレーションで、そのサーバの起動と停止を行うためのスクリプトとコマンドライン引数を示します。
この節では、Windows サービスとしての WebLogic Portal サーバの起動についても説明します。
この節では、以下の内容について説明します。
WebLogic Portal サンプル ドメインのWebLogic Portal起動と停止
表11-1 は、BEA が提供する WebLogic Portal サンプル アプリケーションの起動スクリプトと停止スクリプトのある場所を示したものです。
Windows では、以下の基本となる [スタート] メニュー パスを使用して、これらのサンプル サーバを [スタート] メニューから起動することもできます。
[スタート｜プログラム｜BEA WebLogic Platform 7.0｜WebLogic Portal 7.0｜Portal Examples｜...]
サンプル サーバは、ログインしなくても起動できます。 注意: また、コマンド ウィンドウの [閉じる] アイコンをクリックすれば、サーバを停止できます。 Configuration Wizard で作成したドメインの起動と停止 表11-1 に Configuration Wizard で作成した WebLogic Portal ドメインの起動/停止のスクリプトを示します。 起動/停止のスクリプトのデフォルト位置は、<BEA_HOME>¥user_projects¥portalDomain です。 Windows サーバにドメインを作成し、ウィザードのオプション選択で [スタート] メニューにショートカットを作成することを選択した場合は、 [スタート] メニューからサーバを起動できます。 デフォルトのショートカット位置は、[スタート｜プログラム｜BEA WebLogic Platform 7.0｜User Projects｜<ドメイン名>｜Start Portal Server] です。
ログインのプロンプトが表示されたら、WebLogic Server のシステム管理者としてログインします。 デフォルトのユーザ名とパスワードは、以下のとおりです。
ユーザに WebLogic Server システム管理者権限を与えるには、WebLogic Server Console ツールを使用して、ユーザをそのドメインの Administrators グループに追加します。 詳細については、WebLogic Server システム管理者の作成を参照してください。
注意: また、コマンド ウィンドウの [閉じる] アイコンをクリックすれば、サーバを停止できます。
Windows サービスとしての WebLogic Portal の実行
Windows NT または 2000 のサービスとして WebLogic Portal を実行し、Windows サーバを起動する際に、WebLogic Portal ドメインを自動的に起動することができます。 この方法は、プロダクション モードでは推奨されますが、開発モードでは推奨できません。
PointBase について
Windows サービスとしてサーバを起動する場合、PointBase データベース サーバは自動的には起動されません。 そのため、次のいずれかの操作を行う必要があります。
Windows サービスとしてのインストール
最も確実なのは、サーバを通常どおりに起動し、正常に起動したことを確認してから、Windows サービスとしてインストールすることです。
コマンドラインで、コマンドライン引数の先頭に、-installService を指定します。 例:
表11-1 および 表11-2 にある起動スクリプトはすべて、指定したサーバを Windows サービスとしてインストールする機能をサポートしています。
Windows サービスとしてのアンインストール
インストールしてあるサービスを削除するには、コマンドライン引数として代わりに -uninstallService を使用します。 例:
E-Business Control Center の設定
E-Business Control Center は、ローカル マシン上で実行されるアプリケーションです。 E-Business Control Center の機能の多くは、サーバとの接続を必要としません。 しかし、サーバとのデータの同期やパーソナライゼーションやキャンペーン ロジックを作成するためのサーバサイド リソースへのアクセスなど、機能によっては 1 つまたは複数のサーバに接続する必要があります。
Configuration Wizard を実行して新しいドメインを作成した後、E-Business Control Center はサーバ マシン上で実行されている E-Business Control Center を使用してシングル サーバ環境で実行するよう正しくコンフィグレーションされます。
この節では、特に、サーバ以外のマシンで E-Business Control Center を実行している場合や、マルチサーバ環境を使用している場合に、E-Business Control Center がサーバに接続して同期できるようにするためのガイドラインを説明します。
多くの管理手順では、E-Business Control Center のツールバーにある [同期] ボタンをクリックして、サーバと E-Business Control Center の同期を行う必要があります。 以下の手順は、[同期] ボタンをクリックしたときに、同期が正常に行われるようにするものです。
図11-1 エンタープライズ アプリケーション ディレクトリへのパス設定
データベース管理
この節では、以下の内容について説明します。
サポートされるデータベース
このリリースでサポートされるデータベースについては、http://edocs.beasys.co.jp/e-docs/platform/docs70/support/index.html の『サポート対象プラットフォーム』を参照してください。
PointBase について
PointBase は、BEA が提供するデフォルトのデータベースです。 BEA が提供するサンプル ドメイン用に使用され、Confituration Wizard でドメインを作成する際に使用されるデフォルトのデータベースです。
PointBase は、それ自身のサーバ上で実行されます。 アプリケーションが PointBase にアクセスするためには、PointBase サーバが実行されていることが必要です。 アプリケーション実行のために WebLogic Portal サーバを起動すると、PointBase サーバも自動的に起動します。
注意: Windows サービスとして WebLogic Portal を実行している場合、PointBase は自動的には起動しません。 詳細については、Windows サービスとしての WebLogic Portal の実行を参照してください。
PointBase の起動と停止
メンテナンスのために、WebLogic Portal サーバを実行しないで PointBase データベースを起動する場合、または Windows サービスとして WebLogic Portal を実行しているために手動で PointBase を起動する必要がある場合は、以下の手順で起動します。
startPBServer.bat <ドメインへのパス>¥db_settings.properties
PointBase を停止するには、起動スクリプトと同じディレクトリから、スクリプト stopPBServer.bat または stopPBServer.sh を実行します。
PointBase Console の起動
PointBase には Console ツールがあり、PointBase データベースの表示や管理を行うことができます。 PointBase Conosle を起動するには、以下の手順に従います。
注意: Windows システムでは、各 WebLogic Portal サンプル ドメインのための PointBase Console を起動する [スタート] メニューのショートカットが用意されています。
startPBConsole.bat <ドメインへのパス>¥db_settings.properties
他のデータベースへの切り替え
この節では、デフォルトの PointBase から Oracle など他のサポート対象のデータベースへと切り替える際の手順を説明します。 Configuration Wizard を使用して作成したドメインには、PointBase データベースが含まれています。
ステップ 1: データベースのコンフィグレーション
デフォルトの PointBase データベースから、他のサポート対象のデータベースに切り替える前に、データベースのコンフィグレーションが必要です。 コンフィグレーションの詳細については、以下の場所にある各種データベース用の README.html ファイルを参照してください。
<BEA_HOME>¥weblogic700¥portal¥db¥<データベース タイプ>¥<バージョン>¥admin
ステップ 2: データベース環境に合わせた db_settings.properties の編集
ドメイン ディレクトリで、db_settings.properties ファイルを開き、使用しているデータベース タイプに合わせて、@...@ 変数を実際の値に変更して、ファイルを保存します。
例として、リスト 11-1 に、db_settings.properties ファイルの Oracle セクションの修正前後の様子を示してあります。
コード リスト 11-1 db_settings.properties ファイル
修正前:
#------Oracle Thin Driver------------------------#
#
#@IF_USING_ORACLE_THIN@
#database=ORACLE_THIN
#db_version=817
#jdbcdriver=oracle.jdbc.driver.OracleDriver
#server=@ORACLE_NET_SERVICE_NAME@
#port=@ORACLE_PORT@
#dblogin=@ORACLE_USER@
#dbpassword=@ORACLE_PASSWORD@
#connection=jdbc:oracle:thin:@@ORACLE_SERVER@:@ORACLE_PORT@:
@ORACLE_SID@
#@ENDIF_USING_ORACLE_THIN@
修正後:
#------Oracle Thin Driver------------------------#
#
#database=ORACLE_THIN
#db_version=817
#jdbcdriver=oracle.jdbc.driver.OracleDriver
#server=MY817SVC
#port=1521
#dblogin=WEBLOGIC
#dbpassword=WEBLOGIC
#connection=jdbc:oracle:thin:@myhost:1521:MY817SID
#@ENDIF_USING_ORACLE_THIN@
注意: 今はまだ、このファイルのどの行も（# を使用して）コメント化したり、コメントを解除したりしないでください。 後のステップで行います。
db_version の値によって使用する DDL が制御されるので、正確な番号を設定することが重要です。 表11-3 に、各データベース タイプに対して使用する db_version の番号を示してあります。
注意: 表11-3 には、現在サポートされていないデータベースを示してあります。 現在サポート対象となっているデータベースについては、http://edocs.beasys.co.jp/e-docs/platform/docs70/support/index.html の『サポート対象プラットフォーム』を参照してください。
ステップ 3: サーバの起動 サーバを起動します。 サーバの起動と停止を参照してください。 ステップ 4: WebLogic Server Console での接続プールとレルムのセットアップ このステップでは、ドメイン フォルダの db_settings.properties ファイルをオープンし、このファイルの値を WebLogic Server Console にコピーします。
ステップ 5: サーバの停止
サーバを停止します。 サーバの起動と停止を参照してください。
ステップ 6: 使用するデータベースのコメントを解除するための db_settings.properties の編集
db_settings.properties ファイルを開き、使用するデータベース用のプロパティのコメントを解除（各行先頭の # を削除）し、PointBase データベース用の設定をコメント化（拡張の先頭に # を付加）して、ファイルを保存します。
ステップ 7: create_db の実行
ドメイン フォルダにある create_db スクリプトを実行して、データベースを作成し、データを登録します。 create_db.log に書き込まれた出力に致命的エラーがないことを確認します。
ステップ 8: サーバの起動
サーバを起動します。 サーバの起動と停止を参照してください。
ステップ 9: loadads および loaddocs の実行
コンテンツとメタデータのロードは、次の手順で行います。
ステップ 10: sync の実行
ドメイン フォルダにある sync コマンドを実行し、新しいデータベース データでサーバを更新します。
以上でセットアップは完了です。 それぞれのデータベースに対して Portal アプリケーションを起動して実行できるようになりました。
ステップ 11: Oracle の場合のみ − インデックスの再構築
create_db スクリプトは、WebLogic Portal ドメインのインデックスをデフォルトの表領域 (WEBLOGIC_DATA) に格納します。 WEBLOGIC_INDEX 表領域のインデックスの再構築は、以下の手順で行います。
<PORTAL_HOME>/db/oracle/817/admin
sqlplus username/password@net_service_name
@rebuild_indexes.sql
データベース スキーマについて
WebLogic Portal で提供されるテクノロジのより良いカスタマイズや拡張のためにデータベースを再構築する方法については、「データベース スキーマ」の項を参照してください。
データベース スキーマのすべてを網羅したリファレンスは、データベース スキーマを参照してください。
バックアップと回復処理
WebLogic Portal のバックアップと回復は、他のデータに対して使用したのと同じ手順で行います。 以下にガイドラインをいくつか挙げておきます。
パフォーマンス チューニング
以下のガイドラインに従って、アプリケーションのパフォーマンス向上を図ってください。
この節では、以下の内容について説明します。
起動時に利用可能なデータベース接続の調節
Web サイトのデータベース プールのパフォーマンスを最適化する手順は、以下のとおりです。
データベース接続プールの詳細については、WebLogic Server Console のオンライン ヘルプを参照してください。
カタログ サイズ
カタログ テーブルに入っている商品アイテムとそれぞれの属性の数は、特にカタログ検索の場合、応答時間に大きな影響を与えることがあります。 商品の検索は、ブラウジングの重要な側面であることから、この商品情報の処理に見合った大きさのデータベースにすることが重要です。
キャンペーン
以下の要因が、キャンペーンや関連する項目のパフォーマンスに影響します。
イベント参照 ― シナリオ ルールは常に、特定のイベントに依存するように作成する。 このようにすると、シナリオ ルールで参照するイベント タイプを基に最適化することができます。
無関係なイベントの発生回避 ― できる限り、無関係なイベントの発生を回避する。 Campaign サービスは、すべてのイベントをリスンする必要があります。 イベントを使用して、サイト上で発生する重要な事象を知らせます。
広告表示カウント バッファ サイズの拡張
Campaign サービスは、表示カウントを使って、キャンペーンの最終目標が達成されたかどうかを判断します。 シナリオ アクションの結果として広告プレースホルダが表示する広告を発見するたびに、Campaign サービスは表示カウントを更新します。
デフォルトでは、1 つ以上のシナリオ アクションの結果として広告プレースホルダにより発見された表示広告が 10 件に達するまで、Campaign サービスはデータベースの表示カウントを更新しません。 Campaign サービスがこの表示カウント バッファをデータベースにフラッシュする前にサーバがクラッシュすると、最大でバッファに入っている表示カウント数までの表示カウント更新情報を、失う可能性があります。
WebLogic Server Console では、以下の手順を使って、Campaign サービスがデータベースを更新するまでにメモリに格納される表示カウントの数を指定できます。
Java 仮想マシン (JVM) の場所
クラスタ環境はロード バランシングとフェイルオーバの両方に関して利点がありますが、アプリケーションのスケーラビリティに影響があるので、クラスタ ノードの場所を考慮することが重要です。 シングル マシンに複数の IP アドレスを割り当てた場合、HTTP セッション データのレプリケーションがネットワークを移動する必要がないため、スケーラビリティが向上します。 ただし、フェイルオーバが重要な場合（たとえば、顧客のショッピング カートが失われてはならない場合）は、これはお薦めできません。 複数のマシンで Java 仮想マシン (JVM) を実行してフェイルオーバを保証した場合、アプリケーションのスケーラビリティにはマイナスの影響があります。
JRockit Virtual Machine の使用
BEA WebLogic JRockit は、非常に優れたパフォーマンスを備えた仮想マシンです。 JRockit は、大規模なエンタープライズ サーバサイドで Java アプリケーションを実行するために設計されたもので、I/O、メモリ管理、マルチスレッドを使用するテクノロジを備えています。
JRockit の詳細とダウンロードについては、http://www.beasys.co.jp/products/weblogic/jrockit を参照してください。 JRockit のマニュアルについては、http://edocs.bea.com/ を参照してください。
HotSpot Virtual Machine の使用
HotSpot は、JDK 1.3 のパフォーマンスを向上させます。 HotSpot の実装は、オペレーティング システムによって異なります。 HotSpot は VM を最適化したもので、いくつかのバリエーションがあります。
HotSpot のバリエーションは、以下のオプションを使って設定します。 これらのオプションは、コマンド内の他のオプションより先に指定しなければなりません。
サーバ起動時にホットスポットを呼び出すには、使用する起動スクリプトに以下に示す行のいずれかを追加します。
set JAVA_VM=-hotspot または
set JAVA_VM=-server
WebLogic Portal は、PointBase および -hotspot クライアント用にコンフィグレーションされます。 適切なオプションを使用することにより、さまざまなバージョンの HotSpot に切り替えることができます。 各プラットフォームでサポートされているバリエーションの一覧については、http://edocs.beasys.co.jp/e-docs/platform/docs70/support/index.html の『サポート対象プラットフォーム』を参照してください。
HotSpot に関する詳細は、http://java.sun.com/products/hotspot を参照してください。
インターナショナライズのパフォーマンスのチューニング
<i18n> JSP タグを使用してインターナショナライズされたコンテンツを提供するときは、リソース バンドルにおけるコンテンツの更新を WebLogic Portal がチェックする頻度を指定できます。
<BEA_HOME>¥weblogic700¥portal¥weblogiccommerce.properties ファイルで、i18n.bundle.reload.seconds プロパティに適切な値を設定します。 例:
# I18N タグに対するリソース バンドルについてのタイムアウトを変更するための
パーソナライゼーション コンフィグレーション
#
i18n.bundle.reload.seconds=300
デフォルト値は 300 秒 (5 分) です。 この値を変更する際には、柔軟性とパフォーマンスのバランスを考慮します。 リソース バンドルのコンテンツが頻繁に変化する場合は、この値を小さくすることで、WebLogic Portal がコンテンツを頻繁に更新するようになります。ただし、パフォーマンスは低下します。 リソース バンドルのコンテンツが比較的安定している場合は、86400 (24 時間) のように大きな値を指定することで、パフォーマンスを向上させることができます。
行動追跡データの永続化
オンラインの訪問者が Web サイトとどのようにやり取りしているかを記録するために、イベント情報をデータベースに記録することができます。 この種のイベントは、行動追跡イベントと呼ばれます。 データ分析システムや e マーケティング システムでは、これらのイベントをオフラインで分析して、訪問者の行動およびトランザクションに関するデータを評価することができます。 分析によって得た情報は、パーソナライゼーション ルールの作成と最適化、商品ラインアップの見直し、双方向的なマーケティング キャンペーンの立案などに利用できます。 この節では、イベント データをログに記録して分析で利用するために必要な作業およびデータベース スキーマについて説明します。 各ステップは、以下に挙げたとおりです。
ステップ 1: データ ストレージとテーブル構造の理解
行動追跡データの記録用データベースのセットアップと使用を開始する前に、行動追跡がリレーショナル データベースを使用する方法についての背景情報を多少知っておく必要があります。 行動追跡データを永続化する最初のステップは、行動追跡データベースのスキーマとテーブルの構造を理解することです。 この情報は、サード パーティ ベンダにとっても、データ解析に使用する行動追跡データの抽出に関して有益なものです。
以下の節では、行動追跡データの永続化に関して説明します。
リレーショナル データベース
リレーショナル データベースは、論理構造と物理構造の両方を持ちます。 論理的には、1 つまたは複数のデータベースを定義できます。 各データベースには 1 つまたは複数のテーブルおよびインデックスを定義でき、各テーブルには複数のカラムおよび行を定義できます。 データベースの論理構造は、ベンダ間でおおむね共通しています。 一方、データベースの物理構造はベンダごとに大きく異なります。 物理構造は本質的に、データが格納されるディスク ドライブ上の領域を定義します。 各データベース環境は、独自の用語と実装を使用して、オペレーティング システム レベルでデータを格納します。 たとえば、同じ概念に対して Oracle では表領域 (tablespace) という用語を使用し、Microsoft SQL Server ではファイル グループ (filegroup) という用語を使用します。
推奨事項 データベース構造を定義する際、データベース管理者は個別のテーブルの位置に注意を払う必要があります。 テーブルの中には、あまり更新されない静的なものもあれば、多数の行が断続的に追加および削除される動的なものもあります。また、頻繁に読み取られるテーブルもあれば、あまり読み取られないテーブルもあります。 個々のテーブルは、その利用状況に適した物理位置に配置することが理想的です。 WebLogic Portal で最も頻繁に利用されるテーブルのいくつかは、行動追跡に使われるものです。 1 人の訪問者がサイト内を行き来するアクティビティによって、複数のテーブル エントリが生成される場合があります。 したがって、これらのテーブルはコンピュータ内の最も高速なドライブ上に配置することをお勧めします。
経験を積んだデータベース管理者は、インストールされたデータベースの状況をモニタし、設定を調整して最適なパフォーマンスを得るための多くのテクニックを身に付けています。 管理者を置かずにデータベースを運用していて、サイトに関するほかの仕事で手一杯であるような場合は、十分な技術を持ったデータベース管理者を置いてシステムの定期的なメンテナンスを行う必要があります。
データベース ディレクトリのパス
デフォルトのデータベース ディレクトリのパスは次のとおりです。
<BEA_HOME>¥weblogic700¥portal¥db¥db_vendor¥db_version¥...
たとえば、UNIX 上で Oracle 8.1.7 を使用している場合、パスは次のようになります。
<BEA_HOME>/weblogic700/portal/db/oracle/817/...
スクリプト WebLogic Portal に関連するデータだけでなく、行動追跡イベントのデータを記録するために必要なデータベース スキーマのセットアップを支援するスクリプトも用意されています。 データベースには、注文、カタログ、商品、ポータル、ポートレットなどに関するさまざまな情報データが記録されます。 スクリプトの詳細については、ステップ 2: 行動追跡データベースの作成を参照してください。
Oracle データベースの場合、WebLogic Portal 関連のデータを格納するため作成される表領域は、WEBLOGIC_DATA および WEBLOGIC_INDEX です。
注意: WEBLOGIC_DATA と WEBLOGIC_INDEX は、BEA が提供するスクリプトによって作成される表領域の名前です。 特定の命名規則を適用する場合、それに合わせて表領域の名前を変更できます。
行動追跡に使われる表領域の名前は WEBLOGIC_EVENT_DATA です。 この表領域には、行動追跡関連のすべての表、インデックス、および制約が格納されます。 データが大量になる可能性があるため、この表領域は注意深く監視する必要があります。
行動追跡用データベース スキーマ
行動追跡データを格納するための 3 種類のテーブルが用意されています。 EVENT テーブルには、すべてのイベント データが格納されます。 EVENT_ACTION テーブルには、記録されたイベント データに対してサード パーティのツールが実行するアクションが記録されます。 EVENT_TYPE テーブルは、EVENT テーブルに格納されるイベント タイプおよびイベント カテゴリを参照します。図 11-5 に、行動追跡用データベースの論理エンティティ リレーションシップ ダイアグラムを示します。
図11-5 行動追跡用データベースのエンティティ リレーションシップ ダイアグラム
EVENT データベース テーブル 表11-5 は、EVENT テーブルのメタデータについての説明です。 このテーブルには、すべての行動追跡イベントのデータが格納されます。 EVENT テーブルには 6 つのカラムがあります。各カラムは特定のイベント要素に対応します。 EVENT テーブルのカラムのうち 5 つには、すべてのイベント タイプに共通するデータが格納されます。 XML_DEFINITION カラムには、これら 5 つのカラムの全情報に加えて、イベント タイプごとにユニークなイベント データが格納されます。 このテーブルで定義されている制約については、制約とインデックスを参照してください。 主キーは EVENT_ID です。
XML ドキュメントは、イベント タイプごとに固有の形式で作成されます。 各イベント タイプに対応するデータ要素は、EVENT テーブルの XML_DEFINITION カラムに記憶されます。 これらの要素集合の一覧を表11-6 に示します。
EVENT_ACTION データベース テーブル 表11-7 は、EVENT_ACTION テーブルのメタデータについての説明です。 このテーブルには、記録されたイベント データに対してサード パーティのツールが実行するアクションが記録されます。 これは静的なテーブルです。 主キーは、EVENT_ACTION と ACTION_DATE です。
EVENT_TYPE データベース テーブル 表11-8 は、EVENT_TYPE テーブルのメタデータについての説明です。 このテーブルは、EVENT テーブルに格納されるイベント タイプとイベント カテゴリを参照します。 これは静的なテーブルです。 このテーブルで定義されている制約については、制約とインデックスを参照してください。 主キーは EVENT_TYPE です。
注意: カスタム イベントを記録するには、このテーブルにエントリを作成する必要がある。 カスタム イベントのレコードがこのテーブルに存在しない場合、そのイベントを EVENT テーブルに永続化することはできない。 制約とインデックス EVENT テーブルと EVENT_TYPE テーブルの EVENT_TYPE カラムの間には、単一の外部キー制約が存在します。 前に述べたように、カスタム イベントのレコードが EVENT_TYPE テーブルに存在しない場合、そのイベントを EVENT テーブルに永続化することはできません。 各テーブルの主キー以外に、EVENT テーブルに 2 つのインデックスが存在します。 一方のインデックスは EVENT.EVENT_DATE カラムに対するもので、もう一方のインデックスは EVENT.EVENT_TYPE カラムと EVENT.EVENT_DATE カラムの組み合わせです。 ステップ 2: 行動追跡データベースの作成 BEA では、行動追跡に使うスキーマとテーブルを作成するスクリプトを、PointBase を除くすべてのデータベースについて提供しています。 （PointBase については、行動追跡データベース オブジェクトはすでに存在しています。create_db.bat/sh を実行すると、オブジェクトが再作成されます。） このステップは、以下の環境でのデータベース構造について説明します。
開発環境のためのデータベースの作成
開発環境においては、行動追跡イベントを記録するためのデータベースまたは表領域を、WebLogic Portal 用に使われるデータベースまたは表領域と分離する必要はなく、それによって得られる利点もありません。 したがって、行動追跡用のデータベース オブジェクトを、これらの製品のデータベース オブジェクトと混在させることが可能です。 これを行う最も簡単な方法は、データベースのインストール先の event ディレクトリにある create_all スクリプトを実行することです。
SQL*Plus を使って Oracle にログインし、次の場所にある create_all.sql スクリプトを実行します。
%BEA_HOME%/weblogic700/portal/db/oracle/817/event/create_all.sql
event サブディレクトリ内の create_all スクリプトは、以下のスクリプトを実行します。
プロダクション環境用のデータベースの作成
このシナリオは、Oracle 運用環境での利用を想定しています。この環境では、個別の表領域とそれに対応する要素（表や索引など）をそれぞれ独立させて配置でき、また WebLogic Portal 用のデータベース オブジェクトとは異なるデータベース サーバ上に配置できます。
行動追跡イベントを有効にする前に、以下の作業を行います。
ステップ 3: 行動追跡リスナを有効にする
行動追跡イベントをデータベースに記録できるようにするには、行動追跡リスナを有効にする必要があります。 そのためには、リスナ クラスを追加します。
注意: このステップでは、Sample Portal にリスナ クラスを追加する方法を説明します。 それぞれのアプリケーションについても、同様の手順で行ってください。
各アプリケーションのサービスとして Event サービスがない場合は、WebLogic Server Administration Console を使用して追加します。
行動追跡リスナを追加するには、次の手順を実行します。
http://hostname:port/console—> sampleportalDomain—> [デプロイメント]—> [アプリケーション]—> sampleportal—> [サービス コンフィグレーション]—> [Event サービス]—> [コンフィグレーション] タブ—> [同期型リスナ]
図11-6 WebLogic Server Administration Console ― Event サービス
注意: 行動追跡を有効化する前に、データベースをコンフィグレーションする必要があります。 この作業の詳細については、プロダクション環境用のデータベースの作成を参照してください。
ステップ 4: 行動追跡サービスのコンフィグレーション
行動追跡イベントはいったんバッファに送られてから、データベースの Event テーブルに断続的に格納されます。データベースに格納されたイベントは、オフラインでの分析が可能です。 非同期サービスを使用すると、実行時間の長いイベント ハンドラを、アプリケーションを利用している Web サイトの訪問者を待たせることなく動作させることができます。
注意: 行動追跡イベントの各プロパティは、WebLogic Server Administration Console でコンフィグレーションする必要があります。
接続プール バッファに置かれた行動追跡イベントは、データ接続のプールを使用してデータベースにスイープされます。 デフォルトのデータ ソースは weblogic.jdbc.jts.commercePool です。 別のデータ ソースも使用できます。 そのためには、新しいデータ ソースを作成およびコンフィグレーションし（データ ソースのコンフィグレーション（省略可能）を参照）、WebLogic Server Administration Console で、デフォルト データ ソースの名前を新しいデータ ソースの名前に置き換えます。
プロパティ データベースに永続的に保存する特定のイベントは、PersistEventTypes プロパティで指定します。 WebLogic Server Administration Console では、永続化するイベントのリストを表示したり変更したりできます。 このリスト内のタイプは、イベントに指定されたタイプと一致する必要があります。たとえば、SessionBeginEvent のタイプを表す文字列は「SessionBeginEvent」です。
パフォーマンスの最適化 イベントをバッファからスイープする（データベースに移動する）頻度は、行動追跡サービスの以下のプロパティで制御します。
これらのプロパティを調整して、パフォーマンスを最適化します。 バッファのスイープは、データベースへの書き込みに要する時間が長くなりすぎないような頻度で行う必要がありますが、回数が多すぎて処理が無駄にならないようにしなければなりません。
手順 行動追跡サービスのコンフィグレーションは、以下の手順で行います。
注意: 以下のステップでは、Sample Portal でのパフォーマンス最適化の方法を説明します。 それぞれのアプリケーションについても、同様の手順で行ってください。
各アプリケーションのサービスとして Event サービスがない場合は、WebLogic Server Administration Console を使用して追加します。
データ ソースのコンフィグレーション（省略可能）
この節では、Sample Portal でイベントの永続化に使用する新しいデータ ソースを接続プールにコンフィグレーションする方法について簡単に説明します。 それぞれのアプリケーションについても、同様の手順で行ってください。
新しいデータ ソースをコンフィグレーションするには、次の手順に従います。
注意: WebLogic Server Administration Console の使い方の詳細については、http://edocs.beasys.co.jp/e-docs/wls/docs70/index.html の WebLogic Server のマニュアルを参照してください。
http://hostname:port/console—> sampleportal—> [サービス]—> [JDBC]—> [データ ソース]—> [JDBC データソース ファクトリ]
図11-8 WebLogic Server Administration Console ― JDBC データ ソース
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
