1. Oracle Formsの使用
  2. トラブルシューティング、診断およびパフォーマンス・チューニング
  3. パフォーマンス・チューニングに関する考慮事項
  4. Oracle Forms Servicesアプリケーションのチューニング

Oracle Forms Servicesアプリケーションのチューニング

アプリケーションの開発者は、Forms Servicesの組込みアーキテクチャの最適化機能により最大の利益を得ることができるステップをとれます。

次の各項では、多くのアプリケーションに影響を与える主要なパフォーマンスの問題、および開発者がアプリケーションをチューニングしてパフォーマンスを改善し、Forms Services機能を活用するための方法について説明します。

データ・サーバーに対するOracle Forms Servicesの位置

Forms Javaクライアントは、GUIオブジェクトを表示する役割のみを担います。Oracle Formsのすべてのロジックは、中間層のOracle Forms Servicesで実行されます。これには、データベースへのデータの挿入や更新、データベースからのデータの問合せ、データベースでのストアド・プロシージャの実行などが含まれます。そのため、アプリケーション・サーバーとデータベース・サーバー間の高速接続(高帯域幅、短い待機時間)が重要になります。

このサーバー間の対話はすべて、Forms Javaクライアントと通信することなく行われます。画面に変更があった場合のみ、クライアントとForms Services間で通信が行われます。これにより、Oracle Formsアプリケーションは、モデムや衛星を介した低速ネットワーク(待機時間が長いネットワーク)で実行することが可能です。

次の図の構成では、Forms Servicesとデータベース・サーバーがデータ・センター内で並存する仕組みを示しています。

図-51 Oracle Application Server Forms Servicesとデータベース・サーバーの並存

図-51の説明が続きます
「図-51 Oracle Application Server Forms Servicesとデータベース・サーバーの並存」の説明

アプリケーションの起動時間の最小化

アプリケーションをロードするためにかかる時間は、第一印象として重要であり、またどのユーザーにとっても主要な基準となります。起動時間は、オーバーヘッドと見なされます。また、今後のパフォーマンスを期待させるものでもあります。業務でクライアント・テクノロジを使用する場合、クライアント・コードのロードに必要な追加のオーバーヘッドは、ユーザーにあまりよい影響を与えません。したがって、可能なかぎりロード時間を最小化することが重要です。

Oracle Formsアプリケーションを要求した後、アプリケーションを使用できる状態にするまでにはいくつかのステップを実行する必要があります。

  1. Java仮想マシン(JVM)を起動します。
  2. すべての初期Javaクライアント・クラスをロードし、クラスのセキュリティを認証します。
  3. スプラッシュ画面を表示します。
  4. フォームを次に示す方法で初期化します。
    1. 必要に応じて、追加のJavaクラスをロードします。
    2. クラスのセキュリティを認証します。
    3. ボイラープレート・オブジェクトとイメージをレンダリングします。
    4. 初期画面ですべての要素をレンダリングします。
  5. スプラッシュ画面を削除します。
  6. フォームを使用できます。

アプリケーション開発者は、JVMの起動にかかる時間についてほとんど何も行うことができません。ただし、Java配置モデルおよびOracle Forms Developer Javaクライアントの構造では、開発者はどのJavaクラスをどのようにロードするかを決定できます。これにより、Javaクラスに必要なロード時間を最小化します。

Javaクライアントには、基本機能のクラス(ウィンドウを開くなど)と特定の表示オブジェクトの追加クラス(LOV項目など)のコア集合が必要です。これらのクラスはサーバーに始めから常駐している必要があります。これらのクラスをクライアントのJVMにロードするために必要な時間を短縮する方法の詳細は、「Javaファイルの使用」を参照してください。

Javaファイルの使用

JavaはJavaアーカイブ(JAR)メカニズムを提供して、クライアントにネットワークを介して効率的な配布を行うために、クラスをまとめてグループ化し、圧縮(zip形式)することができるファイルを作成します。このファイルがクライアントで使用されると、今後の使用のためにキャッシュされます。

表-51に、実行中のアプリケーションのクライアント側機能をサポートするために提供されているForms JARファイルを示します。

表-51 FormsのJARファイル

ファイル名 説明
frmall.jar ほとんどのモジュールの実行に必要なすべてのJavaクラス・ファイルが含まれています。遅延JARロードを使用している場合は、このファイルを使用しないでください。
frmwebutil.jar WebUtil対応モジュールの実行に必要なクラス・ファイルが含まれています
frmwebsocketjsi.jar WJSI対応モジュールの実行に必要なクラス・ファイルが含まれています
frmgeneric_laf.jar "generic"ルック・アンド・フィール・オプションを使用するために必要なクラス・ファイルが含まれていますこれは、Oracle Java 8でのみサポートされています。
frmoracle_laf.jar "oracle"ルック・アンド・フィール・オプションを使用するために必要なクラス・ファイルが含まれていますこれは、Oracle Java 8でのみサポートされています。
frmmain.jar 英語を読むユーザー向けに記述されたほとんどのモジュールを実行するために必要な最小数のJavaクラス・ファイルが含まれています。このファイルは、遅延JARロードを使用している場合のみ使用してください。これは、Oracle Java 8でのみサポートされています。
frmresources.jar 英語以外の言語をサポートするために必要なクラス・ファイルが含まれていますこれは、Oracle Java 8でのみサポートされています。

必須ネットワーク帯域幅の削減

開発者は、Formsが自動的に実行する差分メッセージングと呼ばれるデータ・ストリーム圧縮を最大限利用できるようにアプリケーションを設計できます。つまりFormsは、メッセージ間で異なる情報のみを送信する差分メッセージングを使用して、データ・ストリーム圧縮を送信します。次のステップを実行すると、メッセージ間の相違部分を削減できます。

  • オブジェクト間の類似点を活用。 似たようなオブジェクトを使用すると、(ユーザーに視覚的によりアピールする上に)message diff-ingの効率性が向上します。次のステップで、オブジェクト間の一貫性が図られます。
    • プロパティのデフォルト値を受け入れ、オブジェクトに必要な属性のみを変更します。
    • スマート・クラスを使用して、オブジェクトのグループを記述します。
    • 視覚属性の違いが少なくなるようにルック・アンド・フィールを整えます。
  • ボイラープレート・テキストの使用を削減。開発者として、可能なかぎり、ボイラープレート・テキストではなくプロンプト項目プロパティを使用してください。Forms Developer 6.0以降には、プロンプトの関連付け機能が含まれており、この機能を使用して、ボイラープレート・テキストを指定した項目のプロンプトとして再設計できます。
  • ボイラープレート項目(円弧、円、多角形など)の使用を削減。 指定したフォームのすべてのボイラープレート項目をフォームの初期化時にロードします。ボイラープレート項目をロードしてクライアント上でリソースを使用するには、表示の有無にかかわらず時間がかかります。共通のボイラープレート項目(矩形と線)は最適化されます。このため、アプリケーションをこれらの基本的なボイラープレート項目に制限すると、起動時間を短縮しながらネットワーク帯域幅とクライアント・リソースを削減できます。
  • ナビゲーションを最小に維持。 イベント・バンドルは、2つまたはそれ以上のオブジェクト間にナビゲーションが及ぶ場合でも、ナビゲーション・イベントが完了するたびに送信されます。デフォルト値が受け入れられる場合は、フィールド間をナビゲートする必要がないようにフォームを設計します。フォームは、ユーザーが入力を終了したらスムーズに終了できるようにし、すべての追加のナビゲーション・イベントが1つのイベント・バンドルとして実行されるようにします。
  • 初期画面を表示する時間を短縮。Javaクライアントは必須クラスをロードすると、初期画面を表示する前に、表示するすべてのオブジェクトをロードして初期化する必要があります。項目数を最小限に抑えることで、初期画面はより迅速に表示されます。初期画面を表示する時間を短縮する方法は次のとおりです。
    • アプリケーションのログイン画面を提供して、最初に表示されるオブジェクトを(タイトル、小さなロゴ、ユーザー名およびパスワードなどに)制限します。
    • フォームの初回の表示時は、隠された要素はすぐには必要とされません。次のキャンバス・プロパティを使用します。

      エントリでレイズ=はい (キャンバスのみ)

      VISIBLE = NO

      タブ・キャンバスでは、1つのシートのみ表示されますが、いくつかのシートで構成されていることに注意してください。タブ間で応答を切り替える場合、キャンバス上のすべてのシートに対するすべての項目がロードされます。この中には初期タブの後ろに隠れている項目も含まれます。この結果、タブ・キャンバスをロードして初期化するためにかかる時間は、初めに可視できるオブジェクトのみではなく、キャンバス上のすべてのオブジェクトに関連します。

      ヒント:

      タブ・キャンバスを使用している場合、when-tab-page-changedトリガーでは積み重ねられたキャンバスを使用し、右のキャンバスを表示します。最初の画面に表示されないすべてのキャンバスでは、プロパティRAISE ON ENTRY = YESおよびVISIBLE = NOを設定してください。
  • MENU_BUFFERINGの無効化。デフォルトでは、MENU_BUFFERINGはtrueに設定されます。これは、メニューに対する変更内容が、変更されたメニューの完全な再送信が必要となるような今後の同期化イベントのためにバッファされることを意味します(ほとんどのアプリケーションでは、メニューに対し複数の変更を同時に行うか、まったく行わないかのどちらかです。したがって、クライアント側のメニューを更新する最も効率のよい方法は、すべてのメニューを一度に送信することです)。ただし、メニューに最小限の変更しか加えないアプリケーションもあります。この場合、変更するたびに変更内容を送信した方が効率的です。これは、次の文を使用して実行できます。
    Set_Application_Property (MENU_BUFFERING, 'false');
  • メニューのバッファリングは、LABEL、ICON、VISIBLEおよびCHECKEDのメニュー・プロパティにのみ適用されます。ENABLE/DISABLEイベントは常に送信されますが、メニュー全体の再送信は行われません。

パフォーマンスを改善するためのその他の方法

次に示す方法を使用すると、アプリケーションの実行に必要なリソースをさらに削減できます。

  • タイマーの検証とJavaBeansでの置換。タイマーを起動すると、非同期イベントが生成されます。キュー内に他のイベントがない場合もあります。また、タイマーのサイズはほんの数バイトですが、毎秒実行されるので1分間で60パケットが生成され、通常の営業時間内ではおよそ30,000パケットがネットワークへ送出されます。タイマーの多くは時計やアニメーションを提供するために使用されます。これらのコンポーネントを、Oracle Forms Servicesやネットワークの介入がなくても同じ効果をもたらす、自己完結型のJavaBeansと置換します。

  • クライアント上での入力項目の妥当性チェックについて考慮。When-Validate-Itemトリガーを使用して項目に対する入力を処理することはよく行われます。トリガー自体は、Oracle Forms Servicesで処理されます。プラガブルなJavaコンポーネントを使用して、標準のクライアント項目(テキスト・ボックスなど)のデフォルト機能を置換することを考慮する必要があります。次に、日付や最大/最小値などの項目の妥当性チェックを項目内に含めます。この方法を使用すると、より複雑な、入力の自動フォーマットなど((XXX) XXX-XXXXの書式を持つ電話番号など)のアプリケーション固有の妥当性チェックを行うことができます。

  • アプリケーションを、大きな1つのフォームではなく多数の小さいフォームに縮小。アプリケーションを細かく分けることによって、Oracle Forms Servicesからロードおよび初期化されるオブジェクトをユーザーのナビゲーションで制御できます。大きなフォームの場合、オブジェクトの初期化中にアプリケーションが遅延して、アプリケーションの多くが参照できなくなるという危険性があります。フォームをまとめて連鎖する場合は、ビルトインのOPEN_FORMおよびNEW_FORMを使用することを検討します。

    • OPEN_FORMを使用すると、コールしているフォームはクライアントとサーバーにオープンされたままの状態になるので、OPEN-FORMによる追加のフォームはクライアントとサーバー両方の多くのメモリーを消費します。ただし、フォームが別のユーザーによって使用中である場合、サーバーのメモリー使用量は、データ・セグメントにのみ制限されます。ユーザーが初期フォームに戻ると、フォームはすでにローカル・メモリー内に常駐し再表示の場合でもネットワーク・トラフィックは発生しません。

    • NEW_FORMを使用すると、コールしているフォームはクライアントとサーバー上でクローズされて、すべてのオブジェクト・プロパティが破棄されます。このため、サーバーおよびクライアント上で使用するメモリー量は少なくなります。初期フォームに戻るには、クライアントに再度ダウンロードすることが必要ですが、この場合ネットワーク・リソースが必要で、起動時間が遅延します。初期フォーム(ログイン・フォームなど)を再度コールしないかぎり、OPEN_FORMを使用して、次のフォームをアプリケーションで表示します。

  • 不要なグラフィックとイメージの削除。アプリケーションに表示されるイメージ項目と背景イメージの数を可能なかぎり減らします。アプリケーション・ユーザーに対してイメージが表示されるたびに、イメージはアプリケーション・サーバーからユーザーのWebブラウザにダウンロードする必要があります。Webアプリケーションで会社のロゴを表示する場合には、アプリケーションの起動時にダウンロードされるHTMLファイルに会社のロゴ・イメージを含めてください。会社のロゴを背景イメージとしてアプリケーションに挿入するかわりにこれを行ってください。会社ロゴを背景イメージとして指定すると、データベースまたはファイル・システムから検索して、ユーザーのコンピュータにダウンロードするトラフィックが繰返し発生します。