| Oracle® Fusion Middleware Forms Services Deployment Guide 11g Release 1 (11.1.1) E10240-01 |
|
 Previous |
 Next |
| Oracle® Fusion Middleware Forms Services Deployment Guide 11g Release 1 (11.1.1) E10240-01 |
|
Previous |
Next |
This chapter contains the following:
With the exception of timers, most events in Oracle Forms occur from some kind of user interaction. In previous versions of Oracle Forms, there was no easy support to receive an external event if it could not be bound to the Form's graphical user interface. Forms clients had to use techniques such as polling through a great deal of coding to respond to these events to deal with external events that it did not initiate.
In general, the necessary steps required to use database events are as follows:
Database
Create a queue table
Create a queue
Start the queue
Enqueue a message
Forms Builder
Create an event object
Subscribe the event object to the queue
Code necessary notification
Forms Server
Run the form and register the subscription
Invoke the When-Event-Raised trigger upon event notification
In earlier versions of Forms, handling external events was only possible through custom programming, usually done in Java with the help of Forms' Java Bean support. In Oracle Forms 11g it is possible to call into Forms from any technology that can interface with Advanced Queuing (AQ), for example Java Messaging (JMS).
Figure 8-1 shows the flow of events that take advantage of the improved integration of the different components your application might work with. In the left side of the image, the Oracle Forms server has two-way communication with the AQ functionality of Oracle Database. In the center of the image, the AQ function of Oracle Database also has two-way communication with the possible outside events that can trigger internal Forms events. In the right side of the image, these external events can include technologies such as files with dynamic content, Web services, mail, JMS, or database content that interact with BPEL processes which in turn interact with AQ. BPEL, however, is not necessary. JMS, as an example, can interact with AQ directly without having to go through BPEL.
Oracle Forms Developer provides a declarative environment for creating and managing event objects. For known external events, Forms Developer provides a list of available events that can be subscribed to. The property of the event object can be set at runtime or at design time. The ability to end a subscription to a particular external event is also provided through a dynamic setting of the event object property.
Most of the new event functionality is also available through standard Oracle interfaces. Both client and server-side PL/SQL provide all the necessary functionality to create, subscribe, and publish a database event. Oracle Forms provides a declarative and user-friendly way of registering a database event. Oracle Forms provides a standard way of responding to the event by hiding most of the complexity from end-users.
The Forms Server gets notified when events it has registered interest in are added to the event queue. Registration is done either when the runtime starts up or when connecting to the database, depending on the type of the event. For database events, the type of the event queue (persistent or non-persistent) is also saved as part of the event creation.
Figure 8-2 shows a situation where a Forms client is idle. Since Oracle Forms is driven by the HTTP protocol, which is a request/response protocol only, nothing can change on the client if the client is idle. A new application property MaxEventWait, expressed in milliseconds, governs how long the application should wait before checking for an event. In other words, you can specify how often the client should send a request to the server, thus causing the execution of the PL/SQL that is specified as a response to an event.
Note, however, that, on the server-side, Forms Server receives all the events without polling. However, the server does not start running the WHEN_EVENT_RAISED triggers until it receives the notification from the Forms Client (because of the HTTP request/reply paradigm of the Forms Client and hence the need for the MaxEventWait property).
Oracle Forms responds to or fires a trigger in response to a variety of events. For both Forms Developer and internal events, Forms provides entry points in terms of triggers so that an application developer can associate and execute some code in response to an event.
For example, a defined trigger is attached to a specific object in a form. The object to which a trigger is attached defines the scope of the trigger. For example, the WHEN-BUTTON-PRESSED trigger corresponds to the Button Pressed event which occurs when an operator selects a button. The name of the trigger establishes the association between the event and the trigger code. When a user clicks on a button, Forms responds by executing the code in the WHEN-BUTTON-PRESSED trigger.
This new event object has a corresponding trigger defined at the event object level. The WHEN-EVENT-RAISED trigger fires in response to the occurrence of a database event for which it has a subscription. The firing of the new trigger is similar to the internal processing of triggers. However, the source of the event is, in this case, an external event such as a database event (firing as a result of an operation) and not the result of any user interaction with forms or as a result of an internal form processing.
Oracle Forms triggers are usually attached to a specific object, such as an item, block, or Form. The object to which a trigger is attached determines the trigger's definition level in the object hierarchy. A trigger's definition level determines the trigger's scope. The scope of a trigger is its domain within the Forms object hierarchy, and determines where an event must occur for the trigger to respond to it. Although the WHEN-EVENT-RAISED trigger is attached to an event object, it has an application level scope because of the nature of the server-centric events. When the event notification is invoked as a result of an asynchronous callback mechanism for registered database events, any number of forms running within that application and with a subscription for that event receive the notification. This alleviates the need for the application developer to code complex logic to deal with the event.
There is also a Form-level scope so that the event will only be handled if the application is running the specific form from where the event is defined.
You use the standard PL/SQL interface for publishing a database event from Forms. For example, you can publish the SalaryExceed event by calling the enqueue interface and providing all the necessary arguments. You can also call a stored procedure to perform this task.
The following program unit can be called from a WHEN-BUTTON-PRESSED trigger by passing the queue name. Depending on how you have defined the queue in the database, a commit might or might not be necessary to actually publish the event. The following sample code will not actually publish the event since there is no commit issued.
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;
For more information about database events, see Oracle Database PL / SQL Reference.
Many enterprise applications are made of a large number of forms which are defined to perform specific tasks such as purchasing, accounting, and sales force management. These applications may also interact with other non-Forms based applications as part of performing a task. The need to provide an integration model where an enterprise can easily integrate its applications (including passing data) with those of its partners, suppliers, and distributors is extremely important.
In previous releases, Oracle Forms attempted to integrate loosely coupled applications through mechanisms ranging from using user_exit calls and some polling via timers to using pluggable Java components. These methods are all useful in some limited circumstances, but they do not provide a formal infrastructure for enterprise application integration.
Apart from the deployment concerns and performance issues, the main reason why these methods do not fully integrate applications is that the integration is only provided through Forms Developer as almost all events are bound to Forms visual components. Also, the communication with the Forms server is always initiated by the Forms client via a request-reply model.
To provide better support for application integration, Oracle Forms 11g supports synchronous and asynchronous server-centric events.
Synchronous communication follows a request-reply paradigm, where a program sends a request to another program and waits until the reply arrives. HTTP follows this paradigm. This model of communication (also called online or connected) is suitable for programs that need to get the reply before they can proceed with their work. Traditional client-server architectures are based on this model. Earlier releases of Oracle Forms client-server architecture is also an example of this model. One of the drawbacks of the synchronous model of communication is that all the programs must be available and running for the application to work. In the event of network or machine failure, programs cease to function. For example, if the Forms server dies, the Forms client ceases to function as well. The synchronous communication model is also in use when the Forms server interacts with other systems such as PL/SQL or the database. The Forms system would be blocked waiting for the current operation to end before continuing with its work. Another drawback of synchronous communication is that the calling program has to wait for a response and unexpected events cannot be handled without first polling for them.
Asynchronous communication is when a user or form places a request in a queue and then proceeds with its work without waiting for a reply or when an asynchronous event is received without any initial request. Programs in the role of consumers retrieve requests from the queue and act on them. This model is well-suited for applications that can continue with their work after placing a request in the queue because they are not blocked waiting for a reply. It is also suited to applications that can continue with their work until there is a message to retrieve.
Oracle Forms 11g supports asynchronous communication with the help of database events. A thin queuing mechanism provides the mechanism for asynchronous events. The queue is checked for messages once there are no more current operations to be performed.
For example, an application might require data to be entered or an operation executed at a later time, after specific conditions are met. The recipient program retrieves the request from the queue and acts on it.
Oracle Forms uses a polling technique at the application level. The client polls the server for an update after specified intervals of time. The frequency of polling can be modified using the parameters - MaxEventWait and HEARTBEAT. A higher frequency of polling may ensure that a client polls the server more frequently for updates; however, this may result in consumption of considerable resources.
The frequency value for polling is set in formsweb.cfg. The value assigned to this constant is in milliseconds and is a positive number.
In the absence of the configuration file setting, the current Oracle Forms HEARTBEAT setting is used. However, special attention and care should be made with regards setting and using of MaxEventWait. In a default setting where MaxEventWait is not set, the HEARTBEAT mechanism is used for polling. The default delay when the HEARTBEAT mechanism is used is two minutes. You can set the MaxEventWait (which is in milliseconds) to a value smaller than the HEARTBEAT for faster response.
For more information on configuring these parameters using the Enterprise Manager, see Chapter 4, "Managing Parameters".
