Working with Server Events 8-3
Figure 8–1 Oracle Forms Handles Outside Events with Advanced Queueing in Oracle Database
8.2 Creating Events
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 PLSQL 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.
8.3 Subscribing to Events
The Forms Services 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.
8.4 Event Propagation
Figure 8–2 shows a situation where a Forms client is idle. Since Oracle Forms is driven
by the HTTP protocol, which is a requestresponse protocol only, nothing can change on the client if the client is idle. A new applet 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 PLSQL that is specified as a response to an event.
Note, however, that, on the server-side, Forms Services receives all the events without polling. However, the server does not start running the WHEN_EVENT_RAISED triggers
Forms BPEL
Advanced Queuing
Files with Dynamic Content
Web Service Mail, Wireless
JMS Database Data
.Net B2B, EDI
8-4 Forms Services Deployment Guide
until it receives the notification from the Forms Client because of the HTTP requestreply paradigm of the Forms Client and hence the need for the
MaxEventWait property.
Figure 8–2 Notification flow with idle or active clients
8.4.1 About the When-Event-Raised Trigger
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.
8.4.2 About Trigger Definition Level and Scope
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 triggers definition
level in the object hierarchy. A triggers definition level determines the triggers 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
Working with Server Events 8-5
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.
8.5 Publishing Database Events
You use the standard PLSQL 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 raw16;
payload raw10; correlation varchar260;
begin payload := hextoraw123;
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.
8.6 About Application Integration Between Forms
