Oracle 9iAS Forms Deployment



Oracle9i Forms Services Deployment : Multiple OC4J instances

Inderpal S. Johal, PR Newswire

Introduction

This paper is a detailed discussion on the deployment options available for Forms Services. It will give full details and steps to create multiple OC4J instances for Forms deployment. This is very good feature for Oracle 9iAS release 2 to create multiple OC4J instances like to implement both Dev and Test environment of Forms application in single installation of 9iAS. You will be able to know as how the bouncing of Dev OC4J instance will not affect the Test Instance users and vice versa.

The document also gives the technical aspects of Oracle 9iAS Architecture, OC4J Architecture along with Oracle 9iAS Forms services architecture

Oracle9iAS provides the latest in J2EE technology with it's J2EE 1.3 compatible server. It delivers the performance, scalability, high availability, security, and ease-of-use required to support e-Business today by providing full support for the J2EE platform, XML, and emerging Web services standards.

J2EE Overview

Java2 Platform, Enterprise Edition (J2EE) has rapidly become the industry platform of choice for new enterprise computing applications. The J2EE component-based approach to the design, development, assembly, and deployment of enterprise applications produces applications that are more reusable, extendable, and adaptable.

J2EE is built on the base of J2SE (Java 2 Standard Edition). Meaning that all of the advantages of J2SE are also available in J2EE. These advantages are Write once, run anywhere portability, JDBCTM API for database access, CORBA technology for interaction with existing enterprise resources, and a security model that protects data even in internet applications. J2EE extends this base by providing full support for Enterprise JavaBeans components, Java Servlets API, JavaServer Pages and XML technology.

In order to achieve full J2EE compatibility, Oracle has enhanced its feature-rich application server product by including a compatible J2EE Server implementation, Oracle9iAS Containers for J2EE (OC4J).

What is OC4J?

Oracle9iAS Containers for J2EE (OC4J) is Oracle’s fast, lightweight, high performance, highly scalable, easy-to-use and fully certified J2EE Server implementation. The J2EE server, Oracle9iAS Containers for J2EE (OC4J), is J2EE 1.3 compatible and is written entirely in Java. It executes using the standard Java Development Kit (JDK) virtual machine. Applications residing in OC4J are completely portable and can therefore be deployed to any J2EE-compliant application server. The latest release of OC4J, 9.0.3, provides a fully J2EE 1.3 certified environment.

[pic]

OC4J is based on technology licensed from Ironflare Corporation, which develops the Orion server--one of the leading J2EE containers. Although OC4J is integrated with the Oracle9iAS infrastructure, the product and some of the documentation still contains some reference to the Orion server.

Oracle9iAS Containers for J2EE is distributed in two different ways - as a pure Java standalone distribution, and as a part of the full Oracle9iAS product.

The pure Java standalone distribution is ideally suited for use in development and testing environments, as well as small scale production systems. It is distributed as single zip file and can be easily downloaded and installed. It is configured and managed through the manual manipulation of a set of simple XML files. In this usage model, OC4J runs as a single process, and HTTP requests are processed directly by the J2EE container itself.

For large scale production systems which require the use of a world class HTTP server, single-sign-on capabilities for security, automatic process management for system availability, and browser based server management, Oracle9iAS Containers for J2EE can be used within the Oracle9iAS product environment. Oracle9iAS Containers for J2EE is tightly integrated with the entire Oracle9iAS technology stack. In this configuration, server management and application deployment is performed using the HTML console of Enterprise Manager. Incoming HTTP requests are serviced with Oracle HTTP Server, and processes are managed automatically by the high availability services provided in Oracle9iAS.

Both of these usage models use the same Oracle9iAS Containers for J2EE code therefore providing a consistent level of J2EE support. This enables developers to use the standalone distribution to develop and test applications, and then deploy the completed applications to Oracle9iAS, safe in the knowledge that the two environments are compatible with one another.

OC4J Architecture

The OC4J Architecture uses the Oracle Http Server and a module called mod_oc4j to forward HTTP requests to the OC4J Server (see Diagram below).

[pic]

Oracle Http Server and mod_OC4J

The following describes the architecture during an HTTP Request where mod_oc4j sits within Oracle HTTP Server and perform the following actions

1. Identifies the requests it needs to act on,

2. Determines which OC4J to route those requests to, and

3. Communicates with that process.

Identifies the requests

• Every J2EE based (web) application, when deployed, needs to be associated with a root context. This root context (i.e. URL prefix) acts as the identifier of requests that need to be handled by mod_oc4j.

Client sends an HTTP request to the OC4J server. For example:



Oracle HTTP Server determines from the URL which modules are configured for this request. In this case, the Oracle HTTP Server resolves that mod_oc4j is responsible for this request, because the /j2ee virtual path is mapped to the OC4J server. This mapping can be configured in either the httpd.conf or mod_oc4j.conf configuration file present in $ORACLE_HOME/Apache/Apache/conf directory.

Determines which OC4J

The mod_oc4j routing algorithm for stateless requests is simple round robin. If this is a new request (with no valid routing cookie), it picks the next OC4J process from the list as the destination.

If an attempt to send the request to that OC4J process fails, mod_oc4j picks the next process from the list, until all OC4J processes in that instance are exhausted. And if so, it returns failure to the client.

If it is a request with a valid routing cookie, the cookie already identifies the process to route to uniquely. This target process is changed only if the target OC4J process is dead. In that case, mod_oc4j picks the next OC4J process from the same island and routes to it.

Communicates with OC4J

mod_oc4j then contacts OC4J using Apache JServ Protocol (AJP 1.3). AJP is the protocol used to communicate between a Web server module and the servlet engine over a TCP socket.

Mod_oc4j analyzes the response from OC4J and takes appropriate actions - ex. If a single sign on redirect is required.

The request is then executed in the context defined in the OC4J server and the response is sent back to the client.

NOTE: OC4J EJB clients can also communicate using Oracle Remote Method Invocation (ORMI). RMI allows an object running in one Java Virtual Machine (VM) to invoke methods on an object running in another Java VM. RMI provides for remote communication between programs written in Java.

What is Oracle 9iAS Forms Services

Oracle 9iAS Forms Services is the collective name for the Forms components used to deploy a forms application on the web. These components are

➢ The Forms Services Web client, a generic Java applet that, after being loaded, renders any number and sizes of Forms applications

➢ The Forms Servlet, accepting incoming Web requests and returning the Forms applet HTML start page

➢ The Forms Listener Servlet, dispatching the communication between Forms generic Java client and the runtime process on the middle-tier server

➢ The Forms Web runtime, executing the business logic stored in Forms application modules and performing the database connect.

Oracle Containers for J2EE (OC4J) is the powerful new servlet engine in Oracle 9iAS. Forms services support the servlet engine by using the new Apache mod_oc4j module. This module integrates the OC4J servlet engine with Apache, as did Apache Jserv previously

Oracle 9iAS Forms Services Architecture

Broadly speaking, the two main components of Oraclei9iAS that concern us here are the HTTP Server and Forms Services. Forms Services is itself comprised of two sub-components: the Forms servlets and the Forms Runtime Processes. Here is the list:

• HTTP Server

• Forms Services:

o Forms Servlet + Forms Listener Servlet

(Both of these run in the OC4J Servlet Engine)

o Forms Runtime Processes

The principles are as follows:

1. The two components of Forms Services must reside on the same server. Namely, the Forms Servlet and the Forms Listener Servlet must be on the same machine as the Forms Runtime Processes they interact with.

These servlets run in the OC4J Servlet Engine.

2. The HTTP Server and Forms Services can be on the same machine, or separate machines.

3. The HTTP Server should point to any of OC4J Servlet Engines where you want Forms to run. This is done in MOD_OC4J, which is contained in the HTTP Server.

The Figure below shows how Oracle Forms on the web is deployed using a three-tier architecture:

• The Client Tier

• The Application Tier or Middle Tier

• The Database Tier

[pic]

The Client Tier

The Forms Client is a thin 100% Java Applet that runs in the user's browser. Anyone with a Java-enabled browser can run a Forms application, over any network: Internet, intranet, or extranet. It receives messages from the server about what to display, and reports back to the server what actions the user performed, so they can be processed. No business logic is executed on the client; it is responsible for rendering the screen. All logic is processed on the application tier.

When a user runs a Forms session, Java Applet - dynamically downloaded from the Oracle9i Application Server. This Java applet is used for any Forms application, therefore it is downloaded only once and cached on the client and so is available for subsequent Forms applications and is renewed automatically only when a new Forms client version is detected on the Application server.

In order to run a Java applet in a browser, it is necessary to have a Java Virtual Machine (JVM) installed. Depending on the client platform the browser is running, we are supporting the following JVMs:

• Windows32

o Oracle JInitiator (with Netscape and Internet Explorer)

o Internet Explorer 5.x native JVM

• Macintosh

o Apple MRJ 2.2.3 (with Internet Explorer 5.0)

• Solaris

o Sun JDK and Java plug-in

The Oracle JInitiator provides these major benefits:

• Allows the latest Oracle-certified JVM to run in older browser releases.

• Ensures a consistent JVM between different browsers.

• Provides functional extensions to the basic JVM such as HTTPS/SSL support.

• Provides a reliable deployment platform. Oracle JInitiator has been thoroughly tested and certified for use with the Oracle9iAS Forms Services and for Oracle Applications E-Business suite.

• JInitiator is the preferred deployment environment. Application class files are automatically cached by JInitiator, providing faster application startup.

• JInitiator is a self-installing and self-updating deployment environment.

The Application Tier

The Forms Client communicates to the Forms Runtime process, not directly, but via the HTTP Listener within Oracle9iAS. By default, HTTP communication is used, but you may configure Oracle9iAS to use SSL (HTTPS) for secure networking.

The application tier is made up of following major Forms components, which are discussed in details in the Forms Services in Action

1. Forms Servlet

2. Forms listener Servlet

3. Forms runtime processes

The Database Tier

The database typically runs on a dedicated machine, or on a cluster of machines. A Forms application will usually connect to one database instance. However there may be many different Forms applications running on the one Application Server, each connecting to a different database.

Interaction Between The Forms Client And Forms Services

1. The user starts up their Web browser on the Client Tier and call he Forms application by using the URL like the following



2. Oracle HTTP listener receives the request.

• OHS forwards the request to OC4J, since the path "/forms90/f90servlet" matches one of the OC4J mount directives in the $ORACLE_HOME/forms90/server/forms90.conf file (the one for the Forms Servlet as shown below).

# Config. for OC4J

Oc4jMount /forms90 OC4J_BI_Forms

Oc4jMount /forms90/f90servlet OC4J_BI_Forms

Oc4jMount /forms90/f90servlet/* OC4J_BI_Forms

Oc4jMount /forms90/l90servlet OC4J_BI_Forms

Oc4jMount /forms90/l90servlet/* OC4J_BI_Forms

• OHS passes the request to the OC4J server through the mod_oc4j module using Apache Jserv Protocol (AJP). Each OC4J process needs one port for AJP13 communication with mod_oc4j. These ports are specified in the opmn.xml file, which is located in ORACLE_HOME/opmn/conf/ directory.. AJP is faster than HTTP, through the use of binary formats and efficient processing of message headers.

[pic]

Fig. HTTP Application Listener

3. OC4J maps the request to the Oracle9i Forms application (whose context root is /forms90). It read the Forms servlet setting in the web.xml and finds the alias match for the Forms Servlet (f90servlet). Then it checks the parameter "configfilename" in web.xml(by default it is formsweb.cfg). Check the Note:219822.1 on Metalink if you want to change the name for the servlet from f90servlet to something else

Web.xml is available in /j2ee/OC4J_BI_Forms/applications/forms90/forms90web/WEB-INF

Where high level folder is ‘OC4J_BI_Forms”corresponds to the instance name,

Lower level folder is ‘/forms90’ points the application name).

Default web.xml File

f90servlet

oracle.forms.servlet.FormsServlet

configFileName

f90servlet

/f90servlet*

4. The Forms Servlet (running in OC4J Servlet Engine) processes the request as follows:

a. Opens the servlet configuration file (formsweb.cfg by default). If the parameter configFileName is not set in above web.xml, the default configuration file (/forms90/server/formsweb.cfg) is used.

b. Determines which configuration section to use in the formsweb.cfg file. Since the URL contains no Config query parameter , the default will be used

c. Determines which baseHTML file to use, based on

i. What browser made the request,

ii. What platform the browser is running on, and

iii. The settings of various parameters in the formsweb.cfg file (specifically, baseHTMLie, baseHTMLjinitiator, baseHTMLjpi, baseHTML, and IE).

|Browser detected |IE parameter |Setting Base HTML file used |

|Internet Explorer 5.x or 6* |Native VM |baseie.htm |

|Internet Explorer 5.x or 6* |jinitiator |basejini.htm |

|Netscape Navigator or Internet Explorer version |not applicable |basejini.htm |

|preceding version 5 | | |

|All other browsers |Not applicable |base.htm |

* Internet Explorer 6 that has been upgraded from 5.5 only (IE 6 is not certified in the base release)

d. Finally Reads the baseHTML file, and sends the contents back as dynamically generated HTML page to the user's Web browser, after doing variable substitution as follows:

i. Whenever a variable (like %myParam%) is encountered, the Forms Servlet looks for a matching URL query parameter (for example, &myParam=xxx), or, failing that, looks for a matching parameter in the formsweb.cfg file. If a matching parameter is found, the variable (%myParam%) is replaced with the parameter value.

For example, the baseHTML file contains the text %form%. In our example, this is replaced with the value "test" as defined in formsweb.cfg file with “form=test.fmx” in the default section.

5. Depending on which baseHTML file the Forms Servlet selected, the dynamically generated HTML page sent back to the Web browser will contain an Applet, Object or Embed tag to start up the Forms applet (thin client). The Forms applet runs in a JVM (either the Web browser's native JVM, or a "plugged in" JVM like Oracle JInitiator or Sun's Java plug-in)

6. If the baseHTML file selected was for a plug-in (Oracle JInitiator or Sun's JDK Java plug-in), and if the user does not already have that plug-in installed on their machine, they are prompted to install the plug-in. In the case of JInitiator, the download location is under the virtual path /forms90/jinitiator (a virtual path defined in the forms90.conf file).

7. In order to start up the Forms applet, its Java code must first be loaded. The Browser then asks the HTTP Listener for the Java Class files from the location specified in the HTML file. The CODEBASE parameter in the HTML file is used to define this. The files may be downloaded individually or as an “Archive”. This archive will have an extension of .JAR and can be best thought of as a .ZIP file containing all of individual CLASS files required by the Applet. The ARCHIVE parameter defines which (if any) .JAR should be used.. For example, if the user is running with Oracle JInitiator, the applet code is loaded from the file . Below is some portion of the Dynamically generated HTML file sent to Forms client browser

The virtual path definition in the forms90.conf file for "/forms90/java" allows the applet code to be loaded from the Web server.

Note: The Forms applet code (for example, f90all_jinit.jar) is only to be loaded over the network the first time the user runs an Oracle9i Forms application (or if a newer version of Oracle9i Forms is installed on the Web server). Otherwise, it is to be loaded from the Web browser's (or the Java plug-in's) cache on the local disk.

8. Once the Forms applet is running, The Java Client applet sends a request to start a Forms session through the HTTP Listener to the Forms Listener Servlet at URL . . The Forms Listener Servlet is defined by the serverURL parameter in the HTML file’s APPLET tag as shown above in Step 7.

9. After receiving the connection request from the Java Client, The Oracle HTTP listener forwards the request to OC4J, since the path "/forms90/l90servlet" matches one of the OC4J mount directives in the forms90.conf file (the one for the Forms Listener Servlet).

10. The Forms Listener Servlet (l90servlet) starts up a Forms runtime process (ifweb90.exe (Windows or f90webm( UNIX) for the Forms session.

[pic]

11. The user is prompted for database login information, if this had not already been supplied, and the connection to the database server is established.

12. Communication continues between the Forms applet (running in the user's Web browser) and the Forms runtime process, via the Listener Servlet, until the Forms session ends.

13. The Forms sessions ends when one of the following occurs:

a. The top-level form is exited (for example, by PL/SQL trigger code which calls the "exit_form" built-in function). In this case, the user is prompted to save changes if there are unsaved changes. "exit_form(no_validate)" exits the form without prompting.

b. The user quits their Web browser (in this case, any pending updates are lost).

Basic 9iAS Forms Services Configuration

• Oracle HTTP Listener Configuration File for Forms

• Forms Service Configuration Files

• OC4J Configuration Files

Oracle HTTP Listener Configuration Files

httpd.conf

Location: $ORACLE_HOME./Apache/Apache/conf

The http.conf file contains the following include statement and define the Port and other Admin tasks.

include "ias20/Apache/Apache/conf/mod_oc4j.conf”

mod_oc4j.conf

Location: $ORACLE_HOME./Apache/Apache/conf

The mod_oc4j.conf file contains the Oc4jMount directives to map Oracle Http Server virtual paths to OC4J destinations.All mod_oc4j related configuration information is kept in /Apache/Apache/conf/mod_oc4j.conf

OHS uses an Oc4jMount command to map the root context to the OC4J instance into which the application was deployed:

[pic]

This causes OHS to route a request that contains the regular expression (such as /j2ee/*) to the home OC4J instance.

Mod_oc4j uses AJP to talk to the OC4J processes. Each OC4J process needs one port for AJP13 communication with mod_oc4j. These ports are specified in the opmn.xml file, which is located in ORACLE_HOME/opmn/conf/ directory.

A section of the file is cut-and-paste here for analysis purposes.

[pic]

The port tag lists all the port in use. The ajp attribute lists all the ports to be used for ajp communication by this particular

OC4J instance (OC4J_Demos in this example).

There are two ways to specify the port:

• A range, as is done in the example file above. In this case, at startup time, OPMN assigns OC4J one of the available ports from the range. The firewall then needs to be configured to open all the ports in this range for this particular OC4J instance. The range needs to include at least as many ports as the number of processes in this particular OC4J instance.

• Specific Ports (comma separated list) – If it is undesirable to specify a range, an exact number of ports may be specified, such as: port1, port2, port3. OPMN picks a port from this list when starting OC4J. This allows a more stringent firewall configuration, since only these specific ports have to be opened for communication from the OHS machines to the OC4J machines.

forms90.conf

Location: forms90/server.

This is the Oracle HTTP listener configuration file for Oracle9i Forms and is been specified in $ORACLE_HOME/Apache/Apache/conf/oracle_apache.conf which in turn is included into httpd.conf (the master HTTP listener configuration file). Forms90.conf defines virtual directors (aliases) and servlet mount points to map URL requests to the Forms Servlets running in the OC4J servlet engine.

Oracle9iAS Containers for J2EE (OC4J) Configuration Files

web.xml

Location: j2ee/ProductGroup2/applications/forms90app/forms90web/WEB-INF/web.xml.

Once Oracle9i Forms has been installed and configured, the web.xml file is located in the directory

$OH/j2ee/ProductGroup2/applications/forms90app/forms90web/WEB-INF. It defines the aliases "f90servlet" and "l90servlet" for the Forms Servlet and the Forms Listener Servlet.

Forms Services Configuration File

formsweb.cfg

Location: forms90/server.

This is the Forms Servlet configuration file that contains the following:

• Values for Forms applet and runtime command line parameters, as well as the name of the environment file to use (envFile setting).

• Most of the servlet configuration parameter settings that you set during installation. You can modify these parameters, if needed.

base.htm, basejini.htm, basejpi.htm, and baseie.htm

Location: forms90/server.

The baseHTML files (base.htm, basejini.htm, basejpi.htm, and baseie.htm) are used as templates by the Forms Servlet when generating the HTML page used to start up an Oracle9i Forms application.

We recommend that you make configuration changes in the formsweb.cfg file and avoid editing the baseHTML files. If you need to change the baseHTML files, create your own versions and reference them from the formsweb.cfg file by changing the

appropriate settings.

default.env

Location: forms90/server.

This file contains environment settings for Forms runtime and can be found in the same directory as the formsweb.cfg file. On UNIX, default.env should include the PATH and LD_LIBRARY_PATH.

OC4J Management Options

In Oracle9iAS Release2, Oracle the following options to manage and deploy applications to OC4J

Oracle Enterprise Manager

OEM is a browser-based, graphical user interface console that enables the deployer or administrator to perform basic management tasks such as starting OC4J, stopping OC4J, managing OC4J clusters, deploying J2EE applications, or editing OC4J configuration files. It can be accessed by the following URL



Distributed Configuration Management Command-line Utility

The Distributed Configuration Management (DCM) is a command-line utility represented as “dcmctl”. Some of the important facts and commands about dcmctl is defined at the end of the document. This utility works much faster than OEM in 9iAS Release2.

Standalone OC4J Management (Development Mode)

The Standalone OC4J Management should only be used with a stand-alone install of OC4J. Stand-alone OC4J does not include OHS and is recommended for development only.

Deploying Forms to the Web using OC4J

Now I am going to present step-by-step details for the deployment of Forms services by creating new OC4J instances. The following instruction will give details for one of the new OC4J Instance creations for the deployment of forms and you can use the same methodology to create as many OC4J instance

Assumptions

| |Development Instance |Testing Instance |

|Instance Name |OC4J_DEV90 |OC4J_TEST90 |

|Application Name |DEV |TEST |

|URL | | |

|Form-Config FileName |formsDev90.cfg |FormsTest90.cfg |

|[formsweb.cfg –Default] | | |

|Application Files Directory |$OH/forms90/DEVApp |$OH/forms90/TESTApp |

|[ fmx, plx] | | |

Some More Assumptions

$OH ( $ORACLE_HOME or /oracle/ora9iAS in this document

Steps

1. Create an OC4J instance

a. Invoke OEM by using the following URL and then providing username as ias_admin and the password as been defined during the 9iAS installation



[pic]

b. Then select the Oracle 9ias Instance as shown “openworl.devindy.” in figure below. The other instance corresponds to Oracle 9iAS infrastructure.

[pic]

c. Now Click on Create OC4J Instance to create new instance and we will name it as per our Assumption defined above

[pic]

d. This will ask for the Instance Name

[pic]

2. Start the newly created Instance

Start the OC4J_TEST90 instance by selecting the newly created OC4J_TEST90 instance and then click Start button

[pic]

3. Deploy the J2EE application packaged within an EAR

Deploy the EAR as been supplied by Oracle as “forms90app.ear” present in $ORACLE_HOME/j2ee/applications directory and if you are not running the browser on the server, then copy it by using “ftp or scp” or by other method on your Workstation and then will be used

a. Click the newly created OC4J_TEST90 Instance to start deploying process

[pic]

b. Click the “Deploy EAR File” button

To deploy a J2EE application packaged within an EAR file, click Deploy Ear File in the Applications section of the OC4J Home Page. This will start an eight-step application deployment wizard that guides you through deploying an application

[pic]

i. Introduction

The first page is an introduction to these steps. It reminds you to provide an EAR file with any OC4J-specific XML configuration files, if necessary. It also outlines some of the other steps in the deployment process. Click Next to go to the next step in the wizard deployment process.

[pic]

ii. Select Application

Figure shows the second page, which enables you to browse your system for the EAR file to be deployed and provide a name to be identified with this application. The application name is user-created and will be the identifier for the application in the OC4J Home Page.

[pic]

iii. Provide The URL Mappings For All Web Modules

Map any Web modules in your application to a specific URL for its servlet context. All OC4J servlet contexts must be prefixed with a slash "/". When you try to access any Web applications, you provide the host, port, and Web context.

[pic]

iv. Provide Any Resource Reference Mappings

Map any resource references in your application, such as data sources or mail queues, to physical entities currently present on the OC4J container. This is not required in our case and Click Next to go to the next step in the wizard deployment process.

v. Specify Any User Manager

You can specify what User Manager to use for security. This is not required in our case and Click Next to go to the next step in the wizard deployment process.

Note That this may give an Error Screen like shown below and can be ignored by pressing OK button

[pic]

1 Provide Any Security Role Mappings

Map any security roles defined in your application to existing users and groups. If you have defined a security role within your application, you can map this role to a security group or role. You do not define security groups and users in this screen. Click Next to go to the next step in the wizard deployment process

vi. Publish Web Services

Publish any Web services defined in your application. If you have defined any Web services, they are displayed on the Publish Web Services Page. Click Next to go to the next step in the wizard deployment process

vii. Summary of Deployment

At this point, you will receive a summary of your application deployment modules and configuration, as shown in Figure

In order to deploy this application, click Deploy. The wizard displays a message that tells you that your application is deployed.

[pic]

So Finally you will get the OC4J_TEST90 Home showing the Deployed Applications as shown below

[pic]

4. Post-Deployment Application Modifications

a. Create the Application Forms Directory

Create the new directory that will be used for placing all of the Application .fmx as well as .plx files

$ cd $OH/forms90

$ mkdir TESTApp

b. Copy the Test forms to Application Forms directory

$ cp $OH/forms90/test.fmx $OH/forms90/TESTApp

c. Create the Forms Configuration file

This can be done by copying the default configuration file named formsweb.cfg present in $OH/forms90/server directory

$ cd $ORACLE_HOME/forms90/server

$ cp formsweb.cfg formsTest90.cfg

d. Modify the Newly created Forms Configuration file

Edit the newly created forms configuration named “formsTest90.cfg” file for the following modifications

working directory=/oracle/9iAS/forms90/TESTApp

form=test.fmx (or whatever form you want run);

ServerURL=/TEST/l90servlet [ old value is /forms90/l90servlet ]

serverhost=devindy. [ Put your host name ]

e. Pointing Newly Created OC4J instance to new Forms configuration file

Modify the file named “web.xml” present in $OH/j2ee/OC4J_TEST90/applications/TEST90/forms90web/WEB-INF directory to point the ConfigFileName to newly created “formsTest90.cfg”

Uncomment and made the following change

configFileName

/oracle/9iAS/forms90/server/formsTest90.cfg

configFileName

/oracle/9iAS/forms90/server/formsTest90.cfg

f. Verify the Mod_Oc4J entry

Check if the following entry exist in the file named “mod_oc4j.conf” present in $OH/Apache/Apache/conf directory. This entry is automatically populated while deploying the Application EAR file

$ vi $OH/Apache/Apache/conf/mod_oc4j.conf

verify that it has the following entry in it

Oc4jMount /TEST OC4J_TEST90

Oc4jMount /TEST/* OC4J_TEST90

g. Modify the Forms90.conf file

Modify the file names “forms90.conf” present in $OH/forms90/server directory. Its purpose is already been explained in the Forms Services in Action section as point #9. Add the following in already existing module

# Config. for OC4J

Oc4jMount /TEST OC4J_TEST90

Oc4jMount / TEST /f90servlet OC4J_ TEST90

Oc4jMount / TEST /f90servlet/* OC4J_ TEST90

Oc4jMount / TEST /l90servlet OC4J_ TEST90

Oc4jMount / TEST /l90servlet/* OC4J_ TEST90

5. Restart the OHS and OC4J Instance

You can restart the OHS [ Oracle HTTP Server ] as well as OC4J_TEST90 instance by using OEM or as well as “dcmctl” utility. Below is the information using “dcmctl” utility as it is faster than OEM

# This will stop the Newly Created OC4J instance for Test environment

$ dcmctl stop –co OC4J_TEST90

# This will stop the Oracle HTTP Server

$ dcmctl stop –ct OHS

# This will give the detailed information of all of the instance status with name

$ dcmctl getstate –v

# This will start the Oracle HTTP Server

$ dcmctl start –ct OHS

# This will start the Newly Created OC4J instance for Test environment

$ dcmctl start –co OC4J_TEST90

$ dcmctl getstate –v

6. Check the newly created OC4J instance

The following will check the Listener Servlet



This following URL will actually called the Test.fmx forms or any form as per the configuration in Step 2d [ Form=]



Recovering From Deployment Errors

If the deployment process is interrupted for any reason, you may need to clean up the temp directory, which by default is:

• (UNIX) /var/tmp

• (Windows) The directory defined by the TEMP system variable

The deployment wizard uses 20 MB of swap space in the temp directory for storing information during the deployment process. At completion, the deployment wizard cleans up the temp directory by removing its files. However, if the wizard is

interrupted, it may not have the time or opportunity to clean up the temp directory. Thus, you must clean up any additional deployment files from this directory yourself. If you do not, this directory may fill up, which will disable any further deployment. If you receive an Out of Memory error, check for space available in the temp directory.

If the temp directory does not have enough space, you can configure OC4J to use a different temp directory using the Enterprise Manager Web site:

1. Navigate to the OC4J Home Page. Scroll to the Administration Section.

2. Select Server Properties in the Administration section. This opens the Server Properties Page.

3. Scroll to the Command Line Options section. Add the following variable definition to the OC4J Options line:

java.io.tmpdir= new_temp_dir

where new_temp_dir is the full path to the new temporary directory.

All new OC4J processes will use the new temp directory.

Undeploying J2EE Applications

You can undeploy a J2EE Web application using the Enterprise Manager Web site:

1. Navigate to the OC4J Home Page that contains the application you would like to undeploy. Scroll to the Applications section.

2. Click the radio button in the Select column for the application.

3. Click Undeploy.

This operation results in the following:

• The application is removed from the OC4J runtime.

• All bindings for the Web modules are removed from all the Web sites to which the Web modules were bound.

• The application files are removed from both the applications and application-deployments directories.

Note: You can also undeploy applications with dcmctl, the DCM command-line utility.

More Fact about FORMS services

1. The previous release of Forms was called Oracle Forms 6i [ that comes with Oracle 9iAS 1.0.2] , compared to Oracle 9iAS Release 2, where it is called Oracle9i Forms. Only migrations from Oracle Forms 6i to Oracle9i Forms are supported. If you wish to migrate from an earlier version of Forms, you need to first migrate to Oracle Forms 6i, and then to Oracle9i Forms.

2. Change the Timeout setting for the OC4J_TEST90 instance by making the following change in “web.xml” file present in $OH/j2ee/OC4J_TEST90/applications/TEST90/forms90web/WEB-INF directory

    

    180

3. Oracle Forms 6i and Oracle Reports6i will be desupported effective 12/31/04. Extended support will be offered through 12/31/07

4. In the Oracle9i Forms release, the Forms Listener Servlet is the only supported way of deploying Forms applications, providing a robust mechanism for deploying applications over the Internet and across multiple network topologies. In previous Release, cgi-bin is also supported along with Listener servlet

5. Types of Files in Forms Application

.fmb is a design time file that can only be opened in Oracle9i Forms Developer.

.fmx is the runtime file created when you compile the .fmb and is used for Web deployment.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download