| Oracle® Fusion Middleware Forms Servicesデプロイメント・ガイド 11gリリース1 (11.1.1) B61388-05 |
|
 前 |
 次 |
この章には、次の項が含まれています。
タイマーを除いて、Oracle Formsのイベントのほとんどは、ユーザーの操作介入により発生します。以前のリリースのOracle Formsでは、フォームのグラフィカル・ユーザー・インタフェースにバインドできない場合に、外部イベントを簡単に受信することができませんでした。開始していなかった外部イベントを処理するには、Formsクライアントでポーリングなどの手法を使用して、これらのイベントに応答するためのコードを記述する必要がありました。
Oracle Forms 11gおよびOracle Databaseでは、データベース・キューを使用して、非同期イベントなど、外部イベントを処理できます。Oracle Forms 11gでデータベース・キューを使用するには、Oracle Database 10g リリース2以上を使用している必要があります。非同期のキューイング機能であるOracle Streamsアドバンスト・キューイング(AQ)は、メッセージを異なるプログラム間で交換できるようにします。AQ機能は、PL/SQLパッケージであるDBMS_AQ、DBMS_AQADM、DBMS_AQELMなどのインタフェースを使用して実装されます。アドバンスト・キューイングの詳細は、http://www.oracle.com/technology/documentation/index.htmlにある『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください。
通常、イベントとデータベース・キューの統合に必要な手順は次のとおりです。
データベース
キュー表の作成: アドバンスト・キューイングを設定するユーザーの管理権限とアクセス権限(AQ_ADMINISTRATOR_ROLE、AQ_USER_ROLE)を定義します。ペイロードのオブジェクト・タイプと、そのオブジェクト・タイプを使用するメッセージのペイロードを定義します。ペイロードを使用して、キュー表を定義します。
キューの作成: キュー表のキューを定義します。キュー表には、同じペイロード・タイプを持つ複数のキューを保持できます。
キューの開始: キューに対するエンキュー/デキューを有効化します。
メッセージのエンキュー: DBMS_AQ.ENQUEUEプロシージャを使用して、キューにメッセージを記述します。
Forms Builder
イベント・オブジェクトの作成: Forms Builderのオブジェクト・ナビゲータで、「イベント」ノードに新しいイベントを作成します。
キューへのイベント・オブジェクトのサブスクライブ: キューの名前は、「サブスクリプション名」プロパティに指定します。
必要な通知のコード化: Formsによって実行されるためにキューに入れられ、クライアントからのリクエストをサーバーが受信したときに実行されるイベント処理ファンクションを記述します。「イベント」ノードに接続されるイベント発生処理トリガーのトリガー・コードを記述します。
Forms Services
フォームを実行して、サブスクリプションを登録します。
イベント通知を受信したら、イベント発生処理トリガーを起動します。
以前のリリースのFormsでは、外部イベントを処理するには、カスタムのプログラムを作成する方法でのみ可能でした。これは一般的に、FormsのJava Beanサポート機能を使用してJavaで実現していました。Oracle Forms 11gでは、アドバンスト・キューイング(AQ)と対話的に処理できる手法(Java Message Service (JMS)など)からFormsにコールすることが可能です。
図8-1に、アプリケーションと連携する各種コンポーネントの統合の向上を活用したイベントのフローを示します。図の左側に示されているOracle Formsは、Oracle DatabaseのAQ機能と双方向で通信します。図の中央に示されているOracle DatabaseのAQ機能は、Forms内部イベントをトリガーできる外部イベントとも双方向で通信します。図の右側に示されている外部イベントには、動的コンテンツを含むファイル、Webサービス、メール、JMS、データベース・コンテンツなどのテクノロジがあり、これらの外部イベントはBPELプロセスと対話し、BPELプロセスはAQと対話します。ただし、BPELは必ずしも必要ではありません。たとえば、JMSはBPELを経由しなくても、AQと直接対話できます。
|
注意: ウイルス対策ソフトウェアやセキュリティ・ソフトウェアなどのサード・パーティ・ツールが稼働していると、Oracle Formsではアドバンスト・キューイングが正しく機能しないことがあります。対策として、サード・パーティのセキュリティ・ツールをすべて停止します。 |
Oracle Forms Developerでは、イベント・オブジェクトを作成して管理する宣言的環境が用意されています。既知の外部イベントの場合、Forms Developerでは、使用可能なサブスクライブ・イベントの一覧が用意されています。イベント・オブジェクトのプロパティは、実行時または設計時に設定できます。特定の外部イベントに対してサブスクリプションを終了することも、イベント・オブジェクトのプロパティを動的に設定する機能でできます。
また、新しいイベント機能のほとんどは、標準のOracleインタフェースを介して使用できます。クライアント側とサーバー側のPL/SQLの両方で、データベース・イベントの作成、サブスクライブおよび公開を行う必要な機能がすべて用意されています。Oracle Formsでは、データベース・イベントを登録するために宣言的で使いやすい方法が用意されています。Oracle Formsでは、ほとんどの複雑な処理をエンド・ユーザーから隠すことで、イベントを処理する標準的方法が用意されています。
関心があることを登録しているイベントがイベント・キューに追加されると、Forms Servicesは通知を受け取ります。登録は、そのイベントの種類に応じて、ランタイムの起動時またはデータベースとの接続時に行われます。データベース・イベントの場合、イベント・キューのタイプ(永続タイプか非永続タイプ)も、イベントを作成する処理の一部として保存されます。
図8-2は、Formsクライアントがアイドル状態にある状況を示しています。Oracle FormsはHTTPプロトコルによって駆動されますが、これはリクエストとレスポンスのプロトコルのみであり、クライアントがアイドル状態の場合にクライアントで変更できません。新しいアプレット・プロパティMaxEventWaitは、イベントが発生しているかどうかをチェックするまでアプリケーションが待機する時間を制御するもので、ミリ秒で指定します。つまり、クライアントからサーバーにリクエストを送信する頻度を指定できます。このリクエストによって、イベントへのレスポンスとして指定したPL/SQLが実行されます。
ただし、サーバー側では、Forms Servicesはポーリングせずにすべてのイベントを受け取ります。一方、サーバーは、Formsクライアントからの通知を受け取らないかぎり、WHEN_EVENT_RAISEDトリガーの実行を開始しません(これは、FormsクライアントのHTTPリクエストとHTTPリプライの組合せのパラダイムによってMaxEventWaitプロパティが必要になることに起因しています)。
Oracle Formsでは、トリガーに対して応答したり、様々なイベントに対してトリガーを起動します。Forms Developerと内部イベントの両方に対して、Formsではトリガーのためにエントリ・ポイントが用意されています。これによって、アプリケーション開発者は、イベントを処理するコードを関連付けて実行することができます。
たとえば、定義されているトリガーは、フォームの特定オブジェクトに接続されます。トリガーが接続されるオブジェクトは、トリガーの有効範囲を定義します。たとえば、WHEN-BUTTON-PRESSEDトリガーは、ボタンが押されたときに発生するイベントに応答しますが、このイベントは、オペレータがボタンを選択したときに発生します。トリガーの名前により、イベントとトリガー・コードとの間における対応付けが確立されます。ユーザーがボタンをクリックすると、WHEN-BUTTON-PRESSEDトリガーでコードが実行されることでFormsで応答処理が行われます。
この新しいイベント・オブジェクトには、イベント・オブジェクトのレベルで定義された対応トリガーがあります。サブスクリプションが設定されたデータベース・イベントが発生すると、それに応答してそのWHEN-EVENT-RAISEDトリガーが起動します。新しいトリガーの起動は、トリガーの内部処理に似ています。ただし、この場合のイベントの発生源は、データベース・イベントのように動作の結果として起動する外部イベントであり、フォームとユーザーとの対話の結果や内部フォーム処理の結果ではありません。
Oracle Formsのトリガーは一般的に、特定のオブジェクト(項目、ブロック、フォームなど)に接続されます。トリガーが接続されるオブジェクトによって、オブジェクト階層内におけるトリガーの定義レベルが決まります。トリガーの定義レベルによって、トリガーの有効範囲が決まります。トリガーの有効範囲は、Formsオブジェクト階層内部のドメインであり、これによって、イベントに応答するトリガーに対応するイベントが発生する場所が決まります。WHEN-EVENT-RAISEDトリガーがイベント・オブジェクトに接続されていても、サーバー中心型イベントの特性により、アプリケーション・レベルの有効範囲があります。登録済データベース・イベント用の非同期コールバック・メカニズムの結果としてイベント通知が起動されると、アプリケーション内部で実行していてそのイベントのサブスクリプションのあるフォームで通知を受信します。これによって、イベントを処理するためにアプリケーション開発者が複雑なロジックのコードを記述する必要性が軽減します。
また、フォーム・レベルの有効範囲もあります。これによって、イベントが定義されている場所からアプリケーションで特定のフォームが実行している場合にのみ、イベントが処理されます。
標準のPL/SQLインタフェースを使用して、データベース・イベントをFormsから公開します。たとえば、エンキュー・インタフェースをコールして、必要な引数をすべて指定すると、SalaryExceedイベントを公開できます。また、ストアド・プロシージャをコールすると、この作業を実行できます。
キュー名を渡すと、WHEN-BUTTON-PRESSEDトリガーで、次のプログラム・ユニットをコールできます。キューをデータベースにおいて定義した方法に応じて、イベントを実際に公開するために、コミット処理が必要な場合と不要な場合があります。次のサンプル・コードでは、コミットが発行されていないので、イベントは実際に公開されません。
Declare
msgprop dbms_aq.message_properties_t;
enqopt dbms_aq.enqueue_options_t;
enq_msgid raw(16);
payload raw(10);
correlation varchar2(60);
begin
payload := hextoraw('123');
correlation := 'Jones';
enqopt.visibility := dbms_aq.IMMEDIATE;
msgprop.correlation := correlation;
DBMS_AQ.ENQUEUE( queue, enqopt, msgprop, payload, enq_msgid);
end;
データベース・イベントの詳細は、Oracle Database PL/SQLリファレンスを参照してください。
多くのエンタープライズ・アプリケーションは、大量のフォームで構成されています。それらのフォームは、購買、経理および販売部隊の管理などの特定の作業を実行するために定義されているものです。また、これらのアプリケーションは、フォーム・ベースでない他のアプリケーションと作業実行の一環として対話的に処理される場合があります。企業のアプリケーション(データを渡すアプリケーションも含まれる)を、パートナ、仕入先および卸売業者のアプリケーションと簡単に統合できる統合モデルを用意する必要性は、非常に重要です。
以前のリリースのOracle Formsでは、user_exitコールを使用したものから、タイマー経由でポーリングするもの、さらにプラガブルなJavaコンポーネントを使用したものまで様々なメカニズムを利用して、疎結合されたアプリケーションの統合が試みられていました。これらの方法はすべて、限定された状況において便利ですが、エンタープライズ・アプリケーションの統合では、一様なインフラストラクチャは実現されません。
配布の問題やパフォーマンスの問題を別にすると、これらの方法で完全にアプリケーションが統合されない主な理由としては、ほとんどすべてのイベントがFormsビジュアル・コンポーネントにバインドされているときにForms Developerを介してのみ統合が実現されることにあります。また、Forms Servicesとの通信は、リクエストとリプライの組合せのモデルを介して必ずFormsクライアントが開始します。
アプリケーション統合のサポートを改善するために、Oracle Forms 11gでは、同期型と非同期型のサーバー中心型イベントがサポートされています。
同期型通信は、リクエストとリプライの組合せのパラダイムに従っています。このパラダイムでは、あるプログラムで別のプログラムにリクエストを送信し、そのリプライを受信待ちします。HTTPはこのパラダイムに従っています。この通信モデル(別名としてオンラインまたは接続済と呼ばれる)は、処理を続行する前にリプライの受信が必要なプログラムに最適です。従来のクライアント/サーバー型アーキテクチャは、このモデルに基づいています。以前のリリースのOracle Formsクライアント/サーバー・アーキテクチャも、このモデルの一例です。同期型通信モデルの短所の1つは、アプリケーションが処理を行うためにすべてのプログラムが実行している必要がある点です。ネットワークやマシンに障害が発生すると、プログラムの機能は停止します。たとえば、Forms Servicesが停止すると、Formsクライアントも機能が停止します。PL/SQLやデータベースなどの他のシステムとForms Servicesが対話的に処理する際にも、同期型通信モデルを使用します。Formsシステムでは、処理が続行する前に、現在の処理は停止してブロックされ、受信待ち状態になります。また、コールするプログラムはレスポンスを待つ必要があり、予期しないイベントはそれをポーリングするまで処理できないことも同期型通信の短所です。
ユーザーやフォームがリクエストをキューに置き、そのリプライを待たずに作業を続行する場合や、最初のリクエストなしで非同期イベントを受け取る場合は非同期型通信です。コンシューマのロールのプログラムでは、リクエストをキューから取得してから処理を行います。リクエストをキューに登録した後で処理を続行できるアプリケーションは、リプライの受信待ちで処理がブロックされないので、このモデルが最適です。取得するメッセージがあるまで処理を続行できるアプリケーションにも最適です。
Oracle Forms 11gでは、データベース・イベントを活用して非同期型通信をサポートしています。軽いキューイング・メカニズムにより、非同期型イベント用のメカニズムが実現されます。現在の処理対象操作がないと、キューにメッセージがあるかどうかがチェックされます。
たとえば、ある特定の条件が満足した後に、アプリケーションでデータの入力が必要な場合や、後で実行する操作が存在する場合があります。受信プログラムでは、リクエストをキューから取得してから処理を行います。
Oracle Formsでは、アプリケーション・レベルでポーリング手法を使用します。クライアントでは、指定された時間間隔でサーバーの更新がポーリングされます。ポーリングの頻度は、MaxEventWaitパラメータおよびHEARTBEATパラメータを使用して変更できます。ポーリングの頻度が高いと、クライアントでサーバーの更新がより頻繁にポーリングされますが、これは非常に多くのリソースを消費します。
ポーリング頻度の値は、formsweb.cfgで設定します。この定数に関連付けた値は、ミリ秒単位の正の整数です。
構成ファイルが設定されていないと、現在のOracle FormsのHEARTBEAT設定が使用されます。ただし、MaxEventWaitを設定して使用するには、注意が必要です。MaxEventWaitが設定されていないデフォルト設定では、HEARTBEATメカニズムがポーリングに使用されます。HEARTBEATメカニズムが使用される場合のデフォルトの遅延は2分です。MaxEventWait(ミリ秒単位)をHEARTBEATよりも小さい値に設定すると、レスポンス時間を短縮できます。
Enterprise Managerを使用してこれらのパラメータを構成する方法の詳細は、第4章「パラメータの管理」を参照してください。
