Application Integration Between Forms
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 Services is always initiated by the Forms client via a request-reply model.
To provide better support for application integration, Oracle Forms supports synchronous and asynchronous server-centric events.
Synchronous Communication
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 Services dies, the Forms client ceases to function as well. The synchronous communication model is also in use when the Forms Services 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
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 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.
Configuring Asynchronous Communication
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 information about configuring these parameters using the Enterprise Manager, see Managing Parameters.