WebUtil - A simplified guide to understanding WebUtil.

Introduction

This paper is a high level introduction of WebUtil which provides you with many of the client side utilities taken for granted in a client/server Forms environment but not natively available when deployed over the Web.

Some background

Oracle Forms has evolved through character mode mainframe applications, onto the desktop with client/server, and is further evolving to take advantage of the benefits of web deployment. As part of the evolution of Forms, Oracle has always been committed to ensure the upgrade through versions of the product should be a seamless as possible.

Nonetheless, it has been the tight integration that Forms developers have built in with the client desktop that have proven most challenging when deploying your Forms application to the Web. Platform specific features such as OLE as well as business requirements to access data from the local machine have introduced architectural dependencies which need innovative solutions in order to provide the same functionality on the Web as client/server.

Figure 1

For example, Figure 1 shows that calling Host to perform an operating system copy command, is executed on the client machine since it is on the client machine where the Forms application is running.

Figure 2

However, the same code running in a 3-tier environment will mean that the Host command is executed on the application server (which may not be the desired behaviour if you are trying to copy a file from the local drive).

This is a typical example of the kind of issue WebUtil seeks to help the Forms developer resolve.

How does WebUtil help you overcome these issues?

The Generic Solution

Running a Forms application, in terms of the runtime architecture, is very similar to client/server. The only difference is the that the UI portion of the Forms runtime, is rendered on the client by the Forms Java Applet. This piece of Java code is then responsible for rendering the screen and communicating with the Forms runtime on the application server.

Because the client tier of this architecture is implemented in Java, it can be easily extending to provide additional functionality. This means that if you want to access the local machine then by writing Java in the UI you will be able to access local resources on the PC. If you want to achieve this functionality you would use a Java Bean or Pluggable Java Component to give you the "hooks" into the client side Java Virtual Machine (JVM).

The Components of WebUtil

WebUtil is basically made up of three main components. The library WebUtil.pll and the object library webutil.olb.

• WebUtil.pll - Provides a set of PL/SQL functions/procedures, each of which maps to an equivalent "native" Forms built-in. E.g. Client_Host is the equivalent call to the Host built in. If you want to host out to the operating system on the client you would change your code to call Client_Host instead of Host.
• WebUtil.olb - Provides the Java Beans which implement the functionality. In Forms, the mechanism for calling out to Java is through extending UI components. Hence, this library provides some beans which are hidden since they are not providing "visual" features but purely functional.
• WebUtil.jar - Contains the Java classes which perform Java "layer" of WebUtil.

Configuring WebUtil

The details for configuring WebUtil are fully documented in WebUtil Familiarization Manual, however, the high level details are as follows:

From within the form itself, you need to attach the WebUtil.pll and reference an object group from the WebUtil.olb. This gives the form the code and the Java Beans to perform the WebUtil functionality. At runtime, a reference is made to the WebUtil.jar file which is downloaded onto the client machine. The developer would then simply change any calls to Forms built-ins which should be executed on the client side. For example:

• Calls to OLE2 would change to Client_OLE2
• Calls to Host would change to Client_Host
• Calls to Text_IO would change to Client_Text_IO

Tracing through a Simple Example

The following section describes the flow of information between all the components that make up the application. From the user pressing a button on the screen, back to the Form, the WebUtil library and the Java Bean which implements the client side functionality.

Figure 3

Figure 3 shows a high level flow of what happens when you want to display a file selection dialog (in client/server this was done by making a call to Get_File_Name). This will assume that WebUtil has been correctly configured and that the Get_File_Name call has been changed to Client_Get_File_Name

1. The user presses a button and the UI calls the Forms runtime to execute the When-Button-Pressed trigger.
2. The button executes a call to Client_Get_File_Name which is part of the WebUtil Library; passing the parameters for Client_Get_File_Name (e.g. file_name, title).
3. The WebUtil library calls the Forms built-in Set_Custom_Property to set the properties (file_name, title) in the FileFunctions Java Bean (which is a hidden UI side bean)
4. The WebUtil library then calls the Forms built-in Get_Custom_Property to get the filename selected from the dialog (see step 5)
5. Calling Get_Custom_Property calls the FileFunctions Java Bean's getProperty method which creates an instance of a JFileChooser dialog.

More than just client/server

As well as providing means of performing many of the desktop integration requirements taken for grantedin client/server, WebUtil also provides a number of additional features such as a D2KWUTIL port, access to client PC information, C APIs for accessing client side libraries and file transfer and manipulation. See the familiarization manual for full details.