1. Oracle Formsの使用
  2. 統合
  3. サーバーおよびシステム・イベントでの作業
  4. Forms間におけるアプリケーションの統合

Forms間におけるアプリケーションの統合

多くのエンタープライズ・アプリケーションは、大量のフォームで構成されています。それらのフォームは、購買、経理および販売部隊の管理などの特定の作業を実行するために定義されているものです。また、これらのアプリケーションは、フォーム・ベースでない他のアプリケーションと作業実行の一環として対話的に処理される場合があります。

企業のアプリケーション(データを渡すアプリケーションも含まれる)を、パートナ、仕入先および卸売業者のアプリケーションと簡単に統合できる統合モデルを用意する必要性は、非常に重要です。

以前のリリースのOracle Formsでは、user_exitコールを使用したものから、タイマー経由でポーリングするもの、さらにプラガブルなJavaコンポーネントを使用したものまで様々なメカニズムを利用して、疎結合されたアプリケーションの統合が試みられていました。これらの方法はすべて、限定された状況において便利ですが、エンタープライズ・アプリケーションの統合では、一様なインフラストラクチャは実現されません。

配布の問題やパフォーマンスの問題を別にすると、これらの方法で完全にアプリケーションが統合されない主な理由としては、ほとんどすべてのイベントがFormsビジュアル・コンポーネントにバインドされているときにForms Developerを介してのみ統合が実現されることにあります。また、Forms Servicesとの通信は、リクエストとリプライの組合せのモデルを介して必ずFormsクライアントが開始します。

アプリケーション統合のサポートを改善するために、Oracle Formsは、同期型と非同期型のサーバー中心型イベントがサポートされています。

同期型通信

同期型通信は、リクエストとリプライの組合せのパラダイムに従っています。このパラダイムでは、あるプログラムで別のプログラムにリクエストを送信し、そのリプライを受信待ちします。HTTPはこのパラダイムに従っています。この通信モデル(別名としてオンラインまたは接続済と呼ばれる)は、処理を続行する前にリプライの受信が必要なプログラムに最適です。従来のクライアント/サーバー型アーキテクチャは、このモデルに基づいています。以前のリリースのOracle Formsクライアント/サーバー・アーキテクチャも、このモデルの一例です。同期型通信モデルの短所の1つは、アプリケーションが処理を行うためにすべてのプログラムが実行している必要がある点です。ネットワークやマシンに障害が発生すると、プログラムの機能は停止します。たとえば、Forms Servicesが停止すると、Formsクライアントも機能が停止します。PL/SQLやデータベースなどの他のシステムとForms Servicesが対話的に処理する際にも、同期型通信モデルを使用します。Formsシステムでは、処理が続行する前に、現在の処理は停止してブロックされ、受信待ち状態になります。また、コールするプログラムはレスポンスを待つ必要があり、予期しないイベントはそれをポーリングするまで処理できないことも同期型通信の短所です。

非同期型通信

ユーザーやフォームがリクエストをキューに置き、そのリプライを待たずに作業を続行する場合や、最初のリクエストなしで非同期イベントを受け取る場合は非同期型通信です。コンシューマのロールのプログラムでは、リクエストをキューから取得してから処理を行います。リクエストをキューに登録した後で処理を続行できるアプリケーションは、リプライの受信待ちで処理がブロックされないので、このモデルが最適です。取得するメッセージがあるまで処理を続行できるアプリケーションにも最適です。

Oracle Formsでは、データベース・イベントを活用して非同期型通信をサポートしています。軽いキューイング・メカニズムにより、非同期型イベント用のメカニズムが実現されます。現在の処理対象操作がないと、キューにメッセージがあるかどうかがチェックされます。

たとえば、ある特定の条件が満足した後に、アプリケーションでデータの入力が必要な場合や、後で実行する操作が存在する場合があります。受信プログラムでは、リクエストをキューから取得してから処理を行います。

非同期型通信の構成

Oracle Formsでは、アプリケーション・レベルでポーリング手法を使用します。クライアントでは、指定された時間間隔でサーバーの更新がポーリングされます。ポーリングの頻度は、MaxEventWaitパラメータおよびHEARTBEATパラメータを使用して変更できます。ポーリングの頻度が高いと、クライアントでサーバーの更新がより頻繁にポーリングされますが、これは非常に多くのリソースを消費します。

ポーリング頻度の値は、formsweb.cfgで設定します。この定数に関連付けた値は、ミリ秒単位の正の整数です。

構成ファイルが設定されていないと、現在のOracle FormsのHEARTBEAT設定が使用されます。ただし、MaxEventWaitを設定して使用するには、注意が必要です。MaxEventWaitが設定されていないデフォルト設定では、HEARTBEATメカニズムがポーリングに使用されます。HEARTBEATメカニズムが使用される場合のデフォルトの遅延は2分です。MaxEventWait(ミリ秒単位)をHEARTBEATよりも小さい値に設定すると、レスポンス時間を短縮できます。

Enterprise Managerを使用してこれらのパラメータを構成する方法の詳細は、「パラメータの管理」を参照してください。