| Oracle® Fusion Middleware Forms Servicesデプロイメント・ガイド 11gリリース2(11.1.2) B66165-02 |
|
 前 |
 次 |
この章には、次の項が含まれています。
Oracle Forms ServicesとOracle Database Server間の接続のチューニングについては、この章では扱いません。
Oracle Forms ServicesおよびJavaクライアントには、いくつかの最適化機能が含まれており、大きく次の項目に分類できます。
Fusion Middleware Controlを使用してOracle Forms Servicesを監視し、次のメトリック情報を確認します。
Forms Servicesインスタンス
イベント
ユーザー・セッション
Forms Trace
「Forms」ホームページを使用して、Forms Servicesインスタンスのメトリックを監視します。
Enterprise Manager Fusion Middleware Controlを起動します。
Enterprise Manager Fusion Middleware Controlのメイン・ページで、監視するForms Servicesインスタンスへのリンクを選択します。
Forms Servicesインスタンスの「Forms」ホームページに次の情報が表示されます。
Formsアプリケーション・インスタンスのステータス(稼動中、停止中、不明)
監視されているForms ServicesインスタンスのURL。
Formsセッションの数
さらに、次の詳細ページにもナビゲートできます。
パフォーマンス・サマリー
サーブレット・ログ
セッションの詳細
Web構成
環境構成
トレース構成
ユーザー・セッション
JVM構成
JVMコントローラ
「パフォーマンス・サマリー」ページでは、「メトリック・パレットの表示」を使用して、他のFormsのメトリックのグラフを動的にページに追加できます。複数のメトリックをオーバーレイ表示して、互いに比較することもできます。たとえば、2つのJVMコントローラで使用しているプライベート・メモリーを1つのグラフにドラッグ・アンド・ドロップして、これらを比較します。詳細は、Oracle Fusion Middlewareのパフォーマンス・ガイドを参照してください。
Enterprise Manager Fusion Middleware Controlを使用して、すべてのイベントまたは特定のイベントに対するトレースを有効にします。表14-1に、このページで実行できるタスクのリストを示します。
表14-1 Formsイベントの監視
| タスク | 関連項目 |
|---|---|
|
ユーザー・セッションのメトリックの監視 |
|
|
メトリック情報のソート |
「Formsユーザー・セッションのリストをソートするには:」 |
|
メトリック情報の検索 |
|
Formsランタイム・プーリング(Formsランタイム・プレスタート)を使用すると、構成可能な数のアプリケーション・ランタイム・エンジンを使用する前に起動できます。ランタイム・プーリングにより、サーバーのピーク時に迅速に接続できるようになり、サーバー側のアプリケーションの起動時間が短縮されます。ランタイム・プーリングは、サーバー構成の窓口が小さいにもかかわらず、そこで多くのユーザーがFormsアプリケーションに接続するような状況で役立ちます。事前に起動されたランタイム・エンジンはすべて、同じ環境で実行され、同じアプリケーションを提供します。
Enterprise Manager Fusion Middleware Controlで表14-2に示されているパラメータを使用して、Forms Servicesのランタイム・プーリングを構成します。
表14-2 Formsランタイム・プーリング・パラメータ
| パラメータ名 | データ型 | 説明 | デフォルト値 |
|---|---|---|---|
|
|
ブール |
trueに設定した場合にのみ、ランタイムの事前起動またはプーリングが有効になります。 |
false |
|
|
整数 |
最初に作成される必要のあるランタイム・プロセスの数。 |
1 |
|
|
整数 |
このプール(構成セクション)の事前起動プロセスがすべて停止するまでの時間(分単位)。クライアント接続が行われると、ランタイム・プロセスは事前起動プールから削除されるため、停止されません。 |
0(0に設定した場合、タイマーは起動しません) |
|
|
整数 |
プールに存在する必要のあるランタイム・プロセスの最小数。 |
0 |
|
|
整数 |
事前に起動されるランタイム・プロセスの数がminRuntimes未満の場合に作成されるランタイム・プロセスの数。 |
0 |
prestartMinは、特定のアプリケーションに対してランタイム・プーリングがアクティブな間は常に存在する必要のある、事前に起動されるランタイムの最小数を定義します。最小値は、prestartInitパラメータに定義した値と同等またはそれ未満に設定してください。prestartMinパラメータは、いつでも変更可能で、アプリケーション・サーバーの再起動を必要としません。クライアントが事前起動済のランタイム・プロセスへの接続をリクエストし、このランタイム・プロセスがタイムアウトしていない場合、この新しいエントリが取得されます。プロセスがタイムアウトすると、アプリケーションはデフォルトの動作になり、最小のしきい値は維持されません。
各構成セクションで、これらのパラメータの値を指定できます。prestartRuntimes = trueエントリがあっても、関連する事前起動パラメータがない場合は、デフォルト値が使用されます。
ロード・バランシングが実現されたシステムに複数のOracle WebLogic管理対象サーバーがある場合は、前述のパラメータに指定された様々な値は、アプリケーションの全体ではなく、JVMごとに対応します。
管理者は、Enterprise Manager Fusion Middleware Controlを使用して、特定のアプリケーションでランタイム・プーリングが有効になるように構成できます。アプリケーション・サーバー(Oracle WebLogic管理対象サーバー)を起動すると、アプリケーションごとに構成した数のFormsランタイム・プロセスが事前に起動されます。
Formsサーブレットの初期化フェーズで構成ファイル(formsweb.cfg)が読み取られ、prestartRuntimesパラメータが有効になっているアプリケーションがサーバーによって事前に起動されます。
ランタイム・プーリングのスケジューリング(またはランタイム事前開始のスケジューリング)は、Formsランタイム・エンジンの事前開始をスケジュールできる機能です。Oracle Formsでは、構成可能な数のFormsランタイム・エンジンを使用する前にその起動について管理できるのみでなく、より柔軟性の高い方法で適切な時間にFormsランタイム・プロセスの事前開始をスケジュールできます。Enterprise Manager Fusion Middleware Controlを使用することにより、Formsランタイム事前開始のスケジュール、既存のスケジュールの確認、既存の任意のスケジュールの削除およびスケジュールのエクスポートとインポートを行うことができます。
事前開始スケジュールの作成
事前開始スケジュールを作成するには、次の手順を実行します。
「Forms」メニューから、「スケジュール事前開始」を選択します。
「スケジュール事前開始」ページが表示されます。
「スケジュール済のジョブ」リージョンで、「作成」をクリックします。
図14-1に、事前開始のスケジューリングのために表示されるページを示します。
「ジョブ名」に、スケジュールの名前を入力します。
ジョブ名の最大長が100文字を超えないようにする必要があります。アンパサンド(&)などの特殊文字を含めることはできません。
「構成セクション」リストから、構成タイプを選択します。
このリストには、パラメータの論理セットが含まれています。
「事前開始初期」に、初期に起動する必要があるランタイム・プロセスの数を示す数値を入力します。この値が1以上であることを確認します。
「事前開始タイムアウト」に、未使用の事前開始プロセスを停止するまでの時間(分単位)を示す数値を入力します。この値にゼロを設定すると、タイマーは開始されないため、プロセスはタイムアウトしません。
「スケジュール・タイプ」オプションから、適切なスケジュール・タイプを選択します。
設定可能な3つのスケジュール・タイプを次に示します。
「1回(遅延ベース)」: 初期遅延ベースで1回の事前開始をスケジュールする必要がある場合に、このオプションを選択します。初期遅延とは、事前開始が始まるまでの時間数または分数を指定する、時間ベースのパラメータです。このオプションを選択する場合、スケジュール・タイプの下に表示される「初期遅延」フィールドに、初期遅延時間(時間単位または分単位)を入力する必要があります。
「1回(日付ベース)」: 日付ベースで1回の事前開始をスケジュールする必要がある場合に、このオプションを選択します。このオプションを選択する場合、スケジュール・タイプの下に表示される「開始日」フィールドに、日付を入力する必要があります。
「繰返し」: 繰返しの事前開始をスケジュールする必要がある場合に、このオプションを選択します。「頻度」リストから、次のオプションのいずれかを選択できます。
「繰返し日付および間隔」: このオプションを選択する場合、開始日と、事前開始を繰り返す間隔を指定する必要があります。
「繰返し初期遅延および間隔」: このオプションを選択する場合、初期遅延と、事前開始を繰り返す間隔を指定する必要があります。
「Submit」をクリックします。
「ジョブの表示」をクリックすると、作成されたすべての事前開始スケジュールを表示できます。
事前開始スケジュールの削除
事前開始スケジュールを削除するには、次の手順を実行します。
「Forms」メニューから、「スケジュール事前開始」を選択します。
「スケジュール事前開始」ページが表示されます。
「スケジュール済のジョブ」リージョンから、削除するスケジュール済のジョブの行を選択します。
削除する複数の行を同時に選択できます。
「削除」をクリックします。
選択した事前開始スケジュールが削除されます。
事前開始スケジュールのエクスポートとインポート
このユーティリティを使用すると、既存のすべてのスケジュールを特定の管理対象サーバーからエクスポートして、それらを別の管理対象サーバーにインポートできます。この機能では、スケジュールを選択してエクスポートすることができないため、既存のすべてのスケジュールをエクスポートする必要があります。事前開始スケジュールをエクスポートおよびインポートするには、次の手順を実行します。
「Forms」メニューから、「スケジュール事前開始」を選択します。
「スケジュール事前開始」ページが表示されます。
「スケジュール済のジョブ」リージョンで、「エクスポート」をクリックします。
ダイアログ・ボックスが表示されます。
ダイアログ・ボックスに新しいファイル名を入力します。
このファイル名には、.xml拡張子を含める必要があります。
「OK」をクリックします。
これで、すべての事前開始スケジュールの属性を含むxmlファイルが作成されます。ブラウザの設定に応じて、ファイルを保存する場所を選択するよう求められるか、ローカル・マシンのデフォルトの場所にファイルが保存されます。
スケジュール(前述の手順でエクスポートしたもの)を他の管理対象サーバーにインポートするには、そのサーバーの「スケジュール事前開始」ページに移動し、「インポート」をクリックします。
ダイアログ・ボックスが表示されます。
スケジュールをエクスポートしたときに作成したファイルの名前を入力します。ダイアログ・ボックスで「参照」をクリックして、ローカル・マシンからxmlファイルをアップロードすることもできます。
「OK」をクリックします。
インポートされたスケジュールが、「スケジュール済のジョブ」リージョンにリストされるようになります。
|
注意:
|
Javaクライアントは、主にアプリケーション画面のレンダリングを行います。これには、埋込みアプリケーションのロジックはありません。Javaクライアントをロードすると、複数のフォームを同時に表示できます。すべてのOracle Formsアプリケーションに汎用Javaクライアントを使用すると、アプリケーションごとにカスタマイズされたJavaクライアントよりも、クライアント上のリソースが少なくて済みます。
Javaクライアントは、多くのJavaクラスで構成されています。これらのクラスは、スプラッシュ画面の表示、ネットワーク通信およびルック・アンド・フィールの変更などの、機能サブコンポーネントにグループ化されます。機能サブコンポーネントを使用すると、Forms DeveloperおよびJava仮想マシン(JVM)は、すべての機能クラスを一度にダウンロードしなくても、必要に応じて機能をロードできます。
フォーム定義がFMXファイルからロードされる時、実行プロセスのプロファイルは次のものに要約できます。
これらの中で、データ・セグメント・セクションのみがアプリケーションの指定したインスタンスに対して一意です。暗号化されたプログラム・ユニットとボイラープレート・オブジェクト/イメージは、どのアプリケーション・ユーザーにも共通しています。Forms Servicesでは、共有コンポーネントを物理メモリーにマップし、同じFMXファイルにアクセスするすべてのプロセス間でこれを共有します。
指定したFMXファイルをロードする最初のユーザーは、そのフォームに必要な全メモリー量を使用します。ただし、後続のユーザーの場合は必要なメモリー量が大幅に減らされているので、ローカル・データのエクステントにのみ依存します。共有コンポーネントをマップするこのメソッドを使用すると、指定したアプリケーションに必要な、ユーザーごとの平均メモリー量を減らすことができます。
帯域幅は重要なリソースであり、インターネット・コンピューティングの一般的な広がりとともに、インフラストラクチャにますます大きな負担を強いるようになっています。このため、アプリケーションはネットワークの容量を節約して使用することが重要です。
Oracle Forms Servicesは、メタデータ・メッセージを使用してJavaクライアントと通信します。メタデータ・メッセージは、実行対象のオブジェクトとその実行方法をクライアントに通知する名前と値のペアのコレクションです。パラメータのみをJavaクライアント上の汎用オブジェクトに送信することで、(同じ効果になるよう新規コードを送信した場合と比較して)通信量を約90%減らすことができます。
Oracle Forms Servicesでは、データ・ストリームを次の3つの方法で効率的に圧縮します。
同じようなメッセージの集合(名前と値のペアのコレクション)を送信すると、2番目以降のメッセージには、前のメッセージとの相違点のみが含まれます。この結果、ネットワーク・トラフィックを大幅に減らすことができます。このプロセスは、message diff-ingと呼ばれます。
同じ文字列がクライアント画面で繰り返されると(たとえば、同じ企業名が記載されている複数行のデータが表示される場合)、Oracle Forms Servicesはその文字列を一度のみ送信し、後続のメッセージではその文字列を参照します。参照によって文字列を渡すことで、帯域幅の効率は向上します。
データ型はその値に必要な最小のバイト数で送信されます。
Forms Developerモデル内のトリガーを多数使用すると大きな効果がありますが、各トリガーにネットワークの往復が必要なため、待機時間の影響が大きくなります。待機時間は、アプリケーションのレスポンス時間に影響を与える最も重要な要因です。待機時間は、ネットワーク速度と同じではありません。ネットワーク速度には、時間単位あたりの転送可能ビットの測定が関連しますが、待機時間は、1ビットがあるエンドポイントから別のエンドポイントまで移動するのにかかる時間を表します。待機時間の影響をなるべく受けないようにする最もよい方法の1つは、JavaクライアントとForms Services間で、対話中に送信されるネットワーク・パケットの数を最小限にすることです。
Oracle Forms Servicesは、イベント・バンドルを通じてトリガー・イベントをグループ化することで、イベント・バンドルを実装します。イベント・バンドルは、2つのオブジェクト間をナビゲートしている間にトリガーされたすべてのイベントを集めて、それらを単一のパケットとしてOracle Forms Servicesに配布して処理します。
たとえば、ユーザーが項目Aから項目Bにナビゲートする場合(あるエントリ・フィールドから別のフィールドにタブする場合など)、PreトリガーとPostトリガーの範囲が起動対象となり、それぞれForms Services上での処理が必要です。ナビゲートによって複数のオブジェクトを横切る場合(離れているオブジェクトに対してマウスのクリックを行った場合など)、イベント・バンドルは通過されたすべてのオブジェクトからすべてのイベントを集めて、そのグループを単一のネットワーク・メッセージとしてOracle Forms Servicesに配信します。
指定したフォーム内のすべてのボイラープレート・オブジェクトは、仮想グラフィック・システム(VGS)ツリーの一部です。VGSは、すべてのForms Developer製品に共通の図形サブコンポーネントです。VGSツリー・オブジェクトは、座標、カラー、線幅およびフォントなどの属性を使用して記述します。オブジェクトのVGSツリーをJavaクライアントに送信する場合、送信する属性のみが指定したオブジェクト・タイプのデフォルトと異なる属性になります。
イメージは圧縮されたJPEGイメージとして送信および格納されます。これにより、ネットワーク・オーバーヘッドとクライアントで必要なメモリー量の両方を減らすことができます。
リソースの最小化には、クライアントおよびサーバー・プロセスのメモリー・オーバーヘッドの最小化も含まれます。ネットワークを最適な状態で使用するには、帯域幅を最小に維持し、ネットワークの待機時間の影響も含まれるため、クライアントおよびOracle Forms Services間の通信で使用するパケット数を最小化することが必要です。
アプリケーションの開発者は、Forms Servicesの組込みアーキテクチャの最適化機能により最大の利益を得ることができます。この章の後半では、多くのアプリケーションに影響を与える主要なパフォーマンスの問題、および開発者がアプリケーションをチューニングしてパフォーマンスを改善し、Forms Services機能を活用するための方法について説明します。
Forms Javaクライアントは、GUIオブジェクトを表示する役割のみを担います。Oracle Formsのすべてのロジックは、中間層のOracle Forms Servicesで実行されます。これには、データベースへのデータの挿入や更新、データベースからのデータの問合せ、データベースでのストアド・プロシージャの実行などが含まれます。そのため、アプリケーション・サーバーとデータベース・サーバー間の高速接続(高帯域幅、短い待機時間)が重要になります。
このサーバー間の対話はすべて、Forms Javaクライアントと通信することなく行われます。画面に変更があった場合のみ、クライアントとForms Services間で通信が行われます。これにより、Oracle Formsアプリケーションは、モデムや衛星を介した低速ネットワーク(待機時間が長いネットワーク)で実行することが可能です。
図14-2の構成では、Forms Servicesとデータベース・サーバーがデータ・センター内で並存する仕組みを示しています。
アプリケーションをロードするためにかかる時間は、第一印象として重要であり、またどのユーザーにとっても主要な基準となります。起動時間は、オーバーヘッドと見なされます。また、今後のパフォーマンスを期待させるものでもあります。業務でクライアント・テクノロジを使用する場合、クライアント・コードのロードに必要な追加のオーバーヘッドは、ユーザーにあまりよい影響を与えません。したがって、可能なかぎりロード時間を最小化することが重要です。
Oracle Formsアプリケーションを要求した後、アプリケーションを使用できる状態にするまでにはいくつかの手順を実行する必要があります。
Java仮想マシン(JVM)を起動します。
すべての初期Javaクライアント・クラスをロードし、クラスのセキュリティを認証します。
スプラッシュ画面を表示します。
フォームを次に示す方法で初期化します。
必要に応じて、追加のJavaクラスをロードします。
クラスのセキュリティを認証します。
ボイラープレート・オブジェクトとイメージをレンダリングします。
初期画面ですべての要素をレンダリングします。
スプラッシュ画面を削除します。
フォームを使用できます。
アプリケーション開発者は、JVMの起動にかかる時間についてほとんど何も行うことができません。ただし、Java配置モデルおよびOracle Forms Developer Javaクライアントの構造では、開発者はどのJavaクラスをどのようにロードするかを決定できます。これにより、Javaクラスに必要なロード時間を最小化します。
Javaクライアントには、基本機能のクラス(ウィンドウを開くなど)と特定の表示オブジェクトの追加クラス(LOV項目など)のコア集合が必要です。これらのクラスはサーバーに始めから常駐している必要がありますが、次の方法を使用すると、これらのクラスをクライアントのJVMにロードするために必要な時間を短縮できます。
JavaはJavaアーカイブ(JAR)メカニズムを提供して、クライアントにネットワークを介して効率的な配布を行うために、クラスをまとめてグループ化し、圧縮(Zip形式)することができるファイルを作成します。このファイルがクライアントで使用されると、今後の使用のためにキャッシュされます。
JARファイルのサイズを2倍にすることもできます。frmall.jarを使用してこれを行うと、約700Kを節約できます。オラクル社のPlug-inでは、そのファイルには接尾辞jarjarが付きます。
次の項では、一般的なデプロイメントのシナリオをサポートするためにOracle Forms Servicesが提供する事前構成済Jarファイルについて説明します。
frmall.jarには、Java Plug-inでの実行に必要なクラスがすべて含まれています。
1つ以上のJARファイルを指定するには、Forms構成ファイル(formsweb.cfg)で指定する構成セクションのarchive設定を使用します。次に例を示します。
[MyApp] archive=frmall.jar
オラクル社のJava Plug-inは、Oracle Forms ServicesでのJarファイルのキャッシュをサポートします。JVMがクラスを参照する場合、最初にローカルのクライアント・キャッシュにあるキャッシュ済JARファイル内にクラスが存在するかどうかを確認します。クラスがキャッシュ内に存在する場合、JVMはサーバーのJARファイルをチェックして、キャッシュ内のJARファイルより新しいバージョンが存在するかどうかを確認します。新しいバージョンが存在しない場合は、サーバーからではなくローカルのクライアント・キャッシュからクラスはロードされます。
キャッシュは、効率性を最大化するために適切なサイズにします。キャッシュ・サイズが小さすぎると、有効なJARファイルが上書きされてしまう場合があります。その結果、アプリケーションを再度起動すると、別のJARファイルのダウンロードが必要になります。デフォルトのキャッシュ・サイズは20MBです。このサイズは、アプリケーションを正常に実行した後のキャッシュ容量のサイズと比較する必要があります。
JARファイルはロード元のホストに関連してキャッシュされます。このため、ロード・バランシング・アーキテクチャを使用している場合、異なるサーバーからの同一のJARファイルがキャッシュされる可能性があります。JARファイルを中央に置き、ロード・バランシング構成の各サーバーでそれらを参照することで、開発者は各JARファイルの1つのコピーのみがクライアントのキャッシュでメンテナンスされていることを確認できます。この方法を使用すると、JARファイル内の特定のクラスに署名して、ロード元のサーバー以外のサーバーに接続を戻せるようにする必要があります。Oracleが提供するJARファイルでは、事前にクラスに署名してあります。
開発者は、Formsが自動的に実行する差分メッセージングと呼ばれるデータ・ストリーム圧縮を最大限利用できるようにアプリケーションを設計できます。つまりFormsは、メッセージ間で異なる情報のみを送信する差分メッセージングを使用して、データ・ストリーム圧縮を送信します。次のステップを実行すると、メッセージ間の相違部分を削減できます。
オブジェクト間の類似点を活用。似たようなオブジェクトを使用すると、(ユーザーに視覚的によりアピールする上に)message diff-ingの効率性が向上します。次の手順で、オブジェクト間の一貫性が図られます。
プロパティのデフォルト値を受け入れ、オブジェクトに必要な属性のみを変更します。
スマート・クラスを使用して、オブジェクトのグループを記述します。
視覚属性の違いが少なくなるようにルック・アンド・フィールを整えます。
ボイラープレート・テキストの使用を削減。開発者として、可能なかぎり、ボイラープレート・テキストではなくプロンプト項目プロパティを使用してください。Forms Developer 6.0以降には、プロンプトの関連付け機能が含まれており、この機能を使用して、ボイラープレート・テキストを指定した項目のプロンプトとして再設計できます。
ボイラープレート項目(円弧、円、多角形など)の使用を削減。指定したフォームのすべてのボイラープレート項目をフォームの初期化時にロードします。ボイラープレート項目をロードしてクライアント上でリソースを使用するには、表示の有無にかかわらず時間がかかります。共通のボイラープレート項目(矩形と線)は最適化されます。このため、アプリケーションをこれらの基本的なボイラープレート項目に制限すると、起動時間を短縮しながらネットワーク帯域幅とクライアント・リソースを削減できます。
ナビゲーションを最小に維持。イベント・バンドルは、2つまたはそれ以上のオブジェクト間にナビゲーションが及ぶ場合でも、ナビゲーション・イベントが完了するたびに送信されます。デフォルト値が受け入れられる場合は、フィールド間をナビゲートする必要がないようにフォームを設計します。フォームは、ユーザーが入力を終了したらスムーズに終了できるようにし、すべての追加のナビゲーション・イベントが1つのイベント・バンドルとして実行されるようにします。
初期画面を表示する時間を短縮。Javaクライアントは必須クラスをロードすると、初期画面を表示する前に、表示するすべてのオブジェクトをロードして初期化する必要があります。項目数を最小限に抑えることで、初期画面はより迅速に表示されます。初期画面を表示する時間を短縮する方法は次のとおりです。
アプリケーションのログイン画面を提供して、最初に表示されるオブジェクトを(タイトル、小さなロゴ、ユーザー名およびパスワードなどに)制限します。
Formの初回の表示時は、隠された要素はすぐには必要とされません。次のキャンバス・プロパティを使用します。
エントリでレイズ=はい(キャンバスのみ)
VISIBLE = NO
タブ・キャンバスでは、1つのシートのみ表示されますが、いくつかのシートで構成されていることに注意してください。タブ間で応答を切り替える場合、キャンバス上のすべてのシートに対するすべての項目がロードされます。この中には初期タブの後ろに隠れている項目も含まれます。この結果、タブ・キャンバスをロードして初期化するためにかかる時間は、初めに可視できるオブジェクトのみではなく、キャンバス上のすべてのオブジェクトに関連します。
|
ヒント: タブ・キャンバスを使用している場合、when-tab-page-changedトリガーでは積み重ねられたキャンバスを使用し、右のキャンバスを表示します。最初の画面に表示されないすべてのキャンバスでは、プロパティ |
MENU_BUFFERINGを使用不可に設定。デフォルトでは、MENU_BUFFERINGはtrueに設定されます。これは、メニューに対する変更内容が、変更されたメニューの完全な再送信が必要となるような今後の同期化イベントのためにバッファされることを意味します(ほとんどのアプリケーションでは、メニューに対し複数の変更を同時に行うか、まったく行わないかのどちらかです。したがって、クライアント側のメニューを更新する最も効率のよい方法は、すべてのメニューを一度に送信することです)。ただし、メニューに最小限の変更しか加えないアプリケーションもあります。この場合、変更するたびに変更内容を送信した方が効率的です。これは、次の文を使用して実行できます。
Set_Application_Property (MENU_BUFFERING, 'false');
次に示す方法を使用すると、アプリケーションの実行に必要なリソースをさらに削減できます。
タイマーの検証とJavaBeansでの置換。タイマーを起動すると、非同期イベントが生成されます。キュー内に他のイベントがない場合もあります。また、タイマーのサイズはほんの数バイトですが、毎秒実行されるので1分間で60パケットが生成され、通常の営業時間内ではおよそ30,000パケットがネットワークへ送出されます。タイマーの多くは時計やアニメーションを提供するために使用されます。これらのコンポーネントを、Forms Servicesやネットワークの介入がなくても同じ効果をもたらす、自己完結型のJavaBeansと置換します。
クライアント上での入力項目の妥当性チェックについて考慮。When-Validate-Itemトリガーを使用して項目に対する入力を処理することはよく行われます。トリガー自体は、Forms Servicesで処理されます。プラグ可能なJavaコンポーネントを使用して、標準のクライアント項目(テキスト・ボックスなど)のデフォルト機能を置換することを考慮する必要があります。次に、日付や最大/最小値などの項目の妥当性チェックを項目内に含めます。この方法を使用すると、より複雑な、入力の自動フォーマットなど((XXX) XXX-XXXXの書式を持つ電話番号など)のアプリケーション固有の妥当性チェックを行うことができます。
アプリケーションを、大きな1つのフォームではなく多数の小さいフォームに縮小。アプリケーションを細かく分けることによって、Forms Servicesからロードおよび初期化されるオブジェクトをユーザーのナビゲーションで制御できます。大きなフォームの場合、オブジェクトの初期化中にアプリケーションが遅延して、アプリケーションの多くが参照できなくなるという危険性があります。フォームをまとめて連鎖する場合は、ビルトインのOPEN_FORMおよびNEW_FORMを使用することを検討します。
OPEN_FORMを使用すると、コールしているフォームはクライアントとサーバーにオープンされたままの状態になるので、OPEN-FORMによる追加のフォームはクライアントとサーバー両方の多くのメモリーを消費します。ただし、フォームが別のユーザーによって使用中である場合、サーバーのメモリー使用量は、データ・セグメントにのみ制限されます。ユーザーが初期フォームに戻ると、フォームはすでにローカル・メモリー内に常駐し再表示の場合でもネットワーク・トラフィックは発生しません。
NEW_FORMを使用すると、コールしているフォームはクライアントとサーバー上でクローズされて、すべてのオブジェクト・プロパティが破棄されます。このため、サーバーおよびクライアント上で使用するメモリー量は少なくなります。初期フォームに戻るには、クライアントに再度ダウンロードすることが必要ですが、この場合ネットワーク・リソースが必要で、起動時間が遅延します。初期フォーム(ログイン・フォームなど)を再度コールしないかぎり、OPEN_FORMを使用して、次のフォームをアプリケーションで表示します。
不要なグラフィックとイメージの削除。アプリケーションに表示されるイメージ項目と背景イメージの数を可能なかぎり減らします。アプリケーション・ユーザーに対してイメージが表示されるたびに、イメージはアプリケーション・サーバーからユーザーのWebブラウザにダウンロードする必要があります。Webアプリケーションで会社のロゴを表示する場合には、アプリケーションの起動時にダウンロードされるHTMLファイルに会社のロゴ・イメージを含めてください。会社のロゴを背景イメージとしてアプリケーションに挿入するかわりにこれを行ってください。会社ロゴを背景イメージとして指定すると、データベースまたはファイルシステムから検索して、ユーザーのコンピュータにダウンロードするトラフィックが繰返し発生します。
Oracle Web Cacheは、Oracle Formsアプリケーションでのロード・バランサとして使用できます。
以降の設定手順では、次の状況を想定しています。
Oracle Web CacheインスタンスはホストAで実行されている。
ホストB上にあるOracle HTTP ServerインスタンスとOracle WebLogic管理対象サーバーは、Oracle FormsアプリケーションDを実行している。
ホストC上にあるOracle HTTP ServerインスタンスとOracle WebLogic管理対象サーバーは、Oracle FormsアプリケーションDを実行している。
Oracle HTTP ServerとOracle WebLogic管理対象サーバーは他にも存在する場合がありますが、ここでは説明を簡略化するために2つのインスタンス・ペアのみを取り上げます。Oracle FormsアプリケーションではOracle WebLogic Serverのアクティブなフェイルオーバーを利用できないため、Oracle HTTP ServerとOracle WebLogic管理対象サーバーはクラスタ化およびアクティブなフェイルオーバー用には構成されません。
また、Web Cache 9.0.2.xクラスタも使用できません。Oracle Web Cacheクラスタを使用すると、Oracle WebLogic Serverで起動されるOracle Formsのロード・バランシングを実現できます。
セッションの間、Formsクライアントはサーバー・プロセスの同一インスタンスと通信できる必要があります。Formsアプリケーションはステートフルであるため、セッション・バインド機能を使用してWeb Cacheを構成し、ステートフルなロード・バランシングを実現する必要があります。
Formsアプリケーションの適切なサイト情報を使用してホストA上のWeb Cacheを構成し、さらにホストBとCで実行されるOracle HTTP Serverインスタンスについて、オリジナル・サーバー情報とサイトとサーバー間のマッピング情報を構成しますホストBとCについてのオリジナル・サーバー情報を構成する場合、FormsアプリケーションDが実行されているかどうかを検出するping URLを構成してください(例: /forms/frmservlet?ifcmd=status)。
|
注意: ロード・バランシングの詳細は『Oracle Fusion Middlewareインストレーション・プランニング・ガイド』を参照してください。エンタープライズ・デプロイメント・アーキテクチャと高可用性の詳細は、Oracle Fusion Middleware Java EEエンタープライズ・デプロイメント・ガイドおよび『Oracle Fusion Middleware高可用性ガイド』を参照してください。 |
$DOMAIN_HOME/servers/WLS_FORMS/tmp/_WL_user/formsapp_11.1.2/<random_string>/war/WEB-INFにあるweblogic.xmlファイルに次のコードを追加します。
<session-tracking cookies="enabled"> </session-tracking>
次のコードを使用して、WLS_Forms管理対象サーバーを再起動します。
startserver
Web Cache Managerにログインします。
ナビゲータ・ペインで、「Origin Servers, Sites, and Load Balancing」、「Session Binding」の順に選択します。
「Session Binding」画面で、「Default Session Binding」を選択して、「Edit Selected」を選択します。
「Edit Session Binding」ダイアログ・ボックスが表示されます。
「Please select a session:」プルダウン・リストで、「JSESSIONID」を選択します。
Oracle FormsアプリケーションDのドロップダウン・リストで、セッション・バインドとして「Cookie-based」を選択します。
「Submit」をクリックします。
変更を適用してOracle Web Cacheを再起動します。
ブラウザを使用して、Web Cacheホストを指定し、Oracle FormsアプリケーションDにアクセスします。アプリケーションが適切に動作することを確認します。ブラウザ・ウィンドウは開いたままにします。
リクエストを処理したOracle HTTP ServerとOracle WebLogic管理対象サーバーを識別します。たとえば、これがホストBであるとすると、そのホスト上のOracle HTTP ServerとOracle WebLogic管理対象サーバーをシャットダウンします。これで、ホストCで実行されるOracle HTTP ServerとOracle WebLogic管理対象サーバーにのみアクセスできるようになります。
Oracle Formsクライアントを実行している同じブラウザを使用して、Oracle FormsアプリケーションDに再度アクセスします。リクエストは失敗し、Formsクライアントはセッションを失います。Oracle Formsセッションの状態は、Oracle WebLogic管理対象サーバー間でレプリケートされません。
次に、ブラウザを使用して、新しいFormsセッションを開始します。Web CacheはホストCで実行される残りのOracle HTTP ServerとOracle WebLogic管理対象サーバーにリクエストをダイレクトします。アプリケーションが適切に動作することを確認します。
ホストBでOracle HTTP Server/WebLogic管理対象サーバーを再起動します。ブラウザを使用して、Web Cache Managerにログオンします。ナビゲータ・ペインで、「Monitoring」、「Health Monitor」の順に選択します。
「Health Monitor」画面で、ホストBが「UP」にマークされていることを確認します。
Web Cacheの詳細は、Oracle Fusion Middleware Web Cacheの管理者ガイドを参照してください。
