| Oracle® Fusion Middleware Forms Servicesデプロイメント・ガイド 12c (12.2.1) E70057-01 |
|
 前 |
 次 |
この章には、次の項が含まれています。
タイマーを除いて、Oracle Formsのイベントのほとんどは、ユーザーの操作介入により発生します。11gより以前のバージョンのOracle Formsでは、フォームのグラフィカル・ユーザー・インタフェースにバインドできない場合に、外部イベントを簡単に受信できませんでした。開始していなかった外部イベントを処理するには、Formsクライアントでポーリングなどの手法を使用して、これらのイベントに応答するためのコードを記述する必要がありました。
Oracle Forms 11gおよびOracle Databaseでは、データベース・キューを使用して、非同期イベントなど、外部イベントを処理できます。Oracle Forms 12cでデータベース・キューを使用するには、Oracle Database 11gリリース2以上を使用している必要があります。非同期のキューイング機能であるOracle Streamsアドバンスト・キューイング(AQ)は、メッセージを異なるプログラム間で交換できるようにします。AQ機能は、PL/SQLパッケージであるDBMS_AQ、DBMS_AQADM、DBMS_AQELMなどのインタフェースを使用して実装されます。アドバンスト・キューイングの詳細は、http://docs.oracle.com/database/121/STRMS/にある『Oracle Streamsアドバンスト・キューイング・ユーザーズ・ガイド』を参照してください
通常、イベントとデータベース・キューの統合に必要な手順は次のとおりです。
データベース
キュー表の作成: アドバンスト・キューイングを設定するユーザーの管理権限とアクセス権限(AQ_ADMINISTRATOR_ROLE、AQ_USER_ROLE)を定義します。ペイロードのオブジェクト・タイプと、そのオブジェクト・タイプを使用するメッセージのペイロードを定義します。ペイロードを使用して、キュー表を定義します。
キューの作成: キュー表のキューを定義します。キュー表には、同じペイロード・タイプを持つ複数のキューを保持できます。
キューの開始: キューに対するエンキュー/デキューを有効化します。
メッセージのエンキュー: DBMS_AQ.ENQUEUEプロシージャを使用して、キューにメッセージを記述します。
Form Builder
イベント・オブジェクトの作成: Form Builderのオブジェクト・ナビゲータで、「イベント」ノードに新しいイベントを作成します。
キューへのイベント・オブジェクトのサブスクライブ: キューの名前は、「サブスクリプション名」プロパティに指定します。
必要な通知のコード化: Formsによって実行されるためにキューに入れられ、クライアントからのリクエストをサーバーが受信したときに実行されるイベント処理ファンクションを記述します。「イベント」ノードに接続されるイベント発生処理トリガーのトリガー・コードを記述します。
Forms Services
フォームを実行して、サブスクリプションを登録します。
イベント通知を受信したら、イベント発生処理トリガーを起動します。
以前のリリースのFormsでは、外部イベントを処理するには、カスタムのプログラムを作成する方法でのみ可能でした。これは一般的に、FormsのJava Beanサポート機能を使用してJavaで実現していました。Oracle Forms 11g以降、アドバンスト・キューイング(AQ)と対話的に処理できる手法(Java Messaging (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 12gでは、同期型と非同期型のサーバー中心型イベントがサポートされています。
同期型通信は、リクエストとリプライの組合せのパラダイムに従っています。このパラダイムでは、あるプログラムで別のプログラムにリクエストを送信し、そのリプライを受信待ちします。HTTPはこのパラダイムに従っています。この通信モデル(別名としてオンラインまたは接続済と呼ばれる)は、処理を続行する前にリプライの受信が必要なプログラムに最適です。従来のクライアント/サーバー型アーキテクチャは、このモデルに基づいています。以前のリリースのOracle Formsクライアント/サーバー・アーキテクチャも、このモデルの一例です。同期型通信モデルの短所の1つは、アプリケーションが処理を行うためにすべてのプログラムが実行している必要がある点です。ネットワークやマシンに障害が発生すると、プログラムの機能は停止します。たとえば、Forms Servicesが停止すると、Formsクライアントも機能が停止します。PL/SQLやデータベースなどの他のシステムとForms Servicesが対話的に処理する際にも、同期型通信モデルを使用します。Formsシステムでは、処理が続行する前に、現在の処理は停止してブロックされ、受信待ち状態になります。また、コールするプログラムはレスポンスを待つ必要があり、予期しないイベントはそれをポーリングするまで処理できないことも同期型通信の短所です。
ユーザーやフォームがリクエストをキューに置き、そのリプライを待たずに作業を続行する場合や、最初のリクエストなしで非同期イベントを受け取る場合は非同期型通信です。コンシューマのロールのプログラムでは、リクエストをキューから取得してから処理を行います。リクエストをキューに登録した後で処理を続行できるアプリケーションは、リプライの受信待ちで処理がブロックされないので、このモデルが最適です。取得するメッセージがあるまで処理を続行できるアプリケーションにも最適です。
Oracle Forms 12cでは、データベース・イベントを活用して非同期型通信をサポートしています。軽いキューイング・メカニズムにより、非同期型イベント用のメカニズムが実現されます。現在の処理対象操作がないと、キューにメッセージがあるかどうかがチェックされます。
たとえば、ある特定の条件が満足した後に、アプリケーションでデータの入力が必要な場合や、後で実行する操作が存在する場合があります。受信プログラムでは、リクエストをキューから取得してから処理を行います。
Oracle Formsでは、アプリケーション・レベルでポーリング手法を使用します。クライアントでは、指定された時間間隔でサーバーの更新がポーリングされます。ポーリングの頻度は、MaxEventWaitパラメータおよびHEARTBEATパラメータを使用して変更できます。ポーリングの頻度が高いと、クライアントでサーバーの更新がより頻繁にポーリングされますが、これは非常に多くのリソースを消費します。
ポーリング頻度の値は、formsweb.cfgで設定します。この定数に関連付けた値は、ミリ秒単位の正の整数です。
構成ファイルが設定されていないと、現在のOracle FormsのHEARTBEAT設定が使用されます。ただし、MaxEventWaitを設定して使用するには、注意が必要です。MaxEventWaitが設定されていないデフォルト設定では、HEARTBEATメカニズムがポーリングに使用されます。HEARTBEATメカニズムが使用される場合のデフォルトの遅延は2分です。MaxEventWait(ミリ秒単位)をHEARTBEATよりも小さい値に設定すると、レスポンス時間を短縮できます。
Enterprise Managerを使用してこれらのパラメータを構成する方法の詳細は、第4章「パラメータの管理」を参照してください。
多くの場合、アプリケーションをホストしているシステム上で発生するイベントをアプリケーションに認識させ、これらのアクションに反応する機能をアプリケーションに設定することが必要です。ほとんどの場合、Formsアプリケーションの実行がこのようなイベントの直接の原因であることはありませんが、これらの発生に関する認識はアプリケーションにとって貴重な情報となる可能性があります。この頻度が最も高いのは、Oracle Formsアプリケーションのクライアント層です。このようなシステム・イベントの例としては、エンドユーザーが長時間にわたってアイドル状態であることの通知などがあります。このような状況を把握することにより、アプリケーション開発者は状況に対応し、適切なアクションを行うことができます。システム・イベントを使用すると、目的の情報を得ることができます。
Oracle Forms 12cでは、5つのシステム・イベントが用意されています。これらすべてイベントの使用にあたって、必要な構成はほとんどないか、一切ありません。これらのイベントを使用するために、アプリケーション開発者は、適切なイベント・オブジェクトを作成し、目的のアクションを実行するためにWHEN-EVENT-RAISEDトリガーをコーディングする必要があります。ただし、ここでは、それぞれについて簡単に説明します。詳細な情報は、Form Builderのヘルプを参照してください。
|
注意: システム・イベントは、Oracle Formsの外部でのアクションに依存したり、アプリケーション内でアクションが正常に完了することを前提としているため、アプリケーションのセキュリティを実装するための唯一の手段として使用しないでください。なんらかの理由によってシステム・イベントに関連付けられたアクションが正常に完了しなかったり、アプリケーションによって検出されない場合、関連するアプリケーションのトリガーが起動しない可能性があります。このような状況はめったにありませんが、システム・イベントを使用して開発を行う場合、このことは考慮する必要があります。 |
システム・クライアント-アイドル・イベントは、実行中Oracle Formsアプリケーション内のクライアント層でエンドユーザーのアクティビティを監視します。このイベントは、2つの方法で有効にできます。このイベントを有効に1つの方法は、管理者がアプレット・パラメータidleTimeoutを整数に設定する方法です。これにより、このイベントを起動するまで待機する時間が秒単位で表されます。このアプレット・パラメータを使用するには、最初に適切なFormsテンプレートbase.htmファイルおよびformsweb.cfgに追加する必要があります。
また、このイベントは、SET_APPLICATION_PROPERTY、CLIENT_IDLE_TIMEに追加された新しい引数を使用してプログラム的に有効/無効にすることもできます。アプレット・パラメータの場合と同様、CLIENT_IDLE_TIMEの値も整数の秒数で表されます。これをPL/SQLで使用する方法の詳細は、Form Builderのヘルプを参照してください。
次にいくつかの制限を示します。
クライアント-アイドルは、クライアント・アプレットがサーバーからのレスポンスを待機している間、またはモード・ダイアログが開いている場合(「アラート」、「ファイルを開く」ダイアログなど)は無視されます。ただし、アイドル時間が経過する前にサーバーが即座に応答した場合、イベントが起動する可能性があります。このような状況はめったにありませんが、開発者はアプリケーションの開発時にこのことを考慮する必要があります。サーバーがタスクを完了するのにかかる時間が長くなることが想定されるときにこの状況を回避するには、アイドル時間をプログラム的に調整することが必要な場合があります。
アイドル時間の長さは秒単位で設定しますが、サーバーとの次回の対話までアプリケーションが反応しない可能性があります。この原因はHeartbeatまたはMaxEventWaitです。
システムDB-アイドル・イベントは、Oracle Forms RuntimeとOracle Forms Runtimeが接続されているデータベース間のアクティビティを監視します。このイベントは、関連するアプリケーションによって実行されるデータベースとの対話を監視します。このイベントは、2つの方法で有効にできます。最初の方法は、環境変数FORMS_DB_IDLE_TIMEを整数に設定する方法です。この値は、このイベントを起動するまでに待機する秒数を表します。
また、このイベントは、SET_APPLICATION_PROPERTY、DB_IDLE_TIMEに追加された新しい引数を使用してプログラム的に有効/無効にすることもできます。DB_IDLE_TIMEの値は整数(秒単位)です。これをPL/SQLで使用する方法の詳細は、Form Builderのヘルプを参照してください。
次にいくつかの制限を示します。
DB-アイドル・イベントの内部タイマーは、データベース・アクションの完了後即座に開始されます。これには、アプリケーションの起動時に発生するFormsのデフォルトのログオン・アクションは含まれません。
デフォルトでは、このイベントは1回のみ起動します。たとえば、COMMITが実行された後に、データベースに対するアクティビティがこれ以上行われず、事前設定時間に達すると、このイベントが起動します。イベントの起動後にアイドル状況のままであっても、イベントが再度起動することはありません。このイベントに監視を続行させるには、アプリケーション・プロパティDB_IDLE_REPEATをTRUEに設定することにより、プログラム的に設定する必要があります。
Oracle Formsは真正のシングル・サインオン・パートナ・アプリケーションではありません。したがって、SSOを使用して認証されるOracle Formsアプリケーションはこれまで、サインオフ・リクエストが発生したかどうかを確認できませんでした。システム・シングル・サインオフ・イベントが追加された結果、このようなことはなくなりました。サインオフ・アクションは、ユーザーがSSOから明示的にログアウトした場合や、SSOセッションが期限切れになった場合に発生します。Oracle Formsアプリケーションがこのようなサインオフ状況を把握し、これに対応できるようにすることが望ましい場合があります。これにより、アプリケーション開発者は、このようなイベントが発生したとしても、それに対応する方法を決定できるようになります。
次にいくつかの制限を示します。
ログアウトが発生したときに(データベース問合せの実行時間が長いことなどが原因で)制御がサーバー上にあるために、イベントが即座に起動されないように思われる場合があります。
次回スケジュールされている対話(ハートビートなど)やユーザー・インタラクションまではイベントがサーバーに送信されない場合があります。
システム通知を使用すると、管理者は、Fusion Middleware Controlから様々なイベント・レベルを起動できます。また、これにより、開発者も、Fusion Middleware Controlから受信したメッセージまたは通知レベルに基づいて特定のタスクを作成できるようになります。たとえば、通知レベル3を受信したときにユーザーに対してメッセージを表示するようアプリケーションを設計できます。このメッセージは、システムがメンテナンスのためにシャットダウンされるのでアプリケーションを終了する必要があることをユーザーに伝えるよう事前に定義しておくこともできます。現在、5つの通知レベル(1-5)が用意されています。
ユーザー・セッション通知の送信方法の詳細は、第4章の第4.4項「ユーザー・セッションの管理」を参照してください
