Oracle Forms in R12/R12.2

We are explaining here Oracle Forms Architecture Features in R12/R12.2

Table of Contents

Features of Forms in R12

-forms are deployed as a one One OC4J instance of 10.1.3 Oracle home
-It uses the utility from 10.1.2 Oracle home/bin
-Forms.EAR 10.1.2 is deployed to the OC4J container in Application Server 10.1.3
-Run time form executable f60webmx has been replaced by frmweb
-Forms Servlet is default deployment / communication mode
-FORMS_ environment variables replace FORMS60_
-New environment variables e.g. FORMS_TRACE_DIR
-$ORACLE_HOME/bin/frmbld.sh replaces f60desm for design
-frmcmp.sh and frmcmp_batch for generation

Features of Forms in R12.2

-forms are deployed as a one managed server in Oracle weblogic server
-It uses the utlity from 10.1.2 Oracle home/bin
-Forms.EAR 10.1.2 is deployed to the managed serve in Oracle weblogic Application Server
-Run time form executabale f60webmx has been replaced by frmweb
-Forms Servlet is default deployment / communication mode
-FORMS_ environment variables replace FORMS60_
-New environment variables e.g. FORMS_TRACE_DIR
-$ORACLE_HOME/bin/frmbld.sh replaces f60desm for design
-frmcmp.sh and frmcmp_batch for generation

Forms Servlet Architecture

The Forms Listener Servlet is responsible for managing the Forms Runtime processes, and routing all communication with the clients. All traffic between the Forms client applet and the Forms server runtime process is now routed via the Apache listener and the Forms Listener Servlet.

-The URL generated by the Forms Applet will run the Forms Listener Servlet. The Oracle http server (Apache) listener receives the request, recognizes it as a request to run a servlet and delegates it to mod_oc4j to execute.
-Mod_oc4j passes the request on to the Forms Listener Servlet(Forms OC4J instance). The Forms Listener Servlet forks a new forms runtime process (frmweb).
-The Forms message layer sends back a message containing the form meta data, and data required to display the UI. The message structure is the same as used by the Forms Listener Process, however this time it’s returned via the forms listener servlet and apache listener.
-The Forms Servlet wraps the Forms message data as http (using http tunneling) and sends it back to the client via the Apache listener.

All subsequent Forms client Forms server communication follow the same path.

Advantage of Servlet Mode

HTTP and HTTPS traffic is easily recognizable by routers, while socket mode communications is generally considered suspect and treated on an exception basis.
Existing networking hardware can be used to support basic functions such as load-balancing and packet encryption for network transit.
More resilient to network and firewall reconfigurations.

More robust: servlet connections can be reestablished if network connections drop unexpectedly for Forms, Framework, and JSP-based pages.
Is the only supported method for generic Oracle Forms customers, and therefore is more thoroughly tested by the Forms and E-Business Suite product groups.
Performance traffic can be monitored via tools like Oracle Real User Experience Insight (RUEI).

Socket mode is not supported on Windows-based server platforms.
No port needs to open to access forms in firewall in case servlet.
Simple SSL Configuration in case of servlet (as no separate ssl configuration is required for Forms as connections are via web/http server)

The Forms Listener Servlet communicates through the HTTP server port, and does not need extra ports to handle the communication between the client and the Oracle Application Server Forms Services. The Forms Servlet architecture is also compatible with web applications industry standards, and supports different advanced network configurations such as load balancing.

Forms Socket Architecture

Initial releases of the Oracle Forms Server product used a simple method for connecting the client to the server. The connection from the desktop client to the Forms Listener process was accomplished using a direct socket connection.

Basically client Desktop connection is established with the Forms Listener process. A new Forms runtime process is forked, or, if applicable, the next free pool process is used. The socket connection between the Forms Applet and Forms Listener is handed off to the Forms runtime process, so the Applet communicates directly with the runtime process. Unless HTTP is being used, the listener is no longer required, except to service other new connections.

In 11i, CGI was used to generate the initial page which help in creating the socket connection

In Oracle E-Business Suite Release 12, the initial request that dynamically generates the HTML page to start the forms applet is processed by the Forms Servlet, although the servlet only receives one request per forms session

Advantage of Socket Mode

1.Uses up to 40% less bandwidth than Forms servlet mode. This may be perceived by Wide Area Network (WAN) users as causing slower responsiveness, depending upon network latency.
2.Uses fewer application-tier JVM resources than servlet mode, due to fewer TCP turns and lack of overhead associated with HTTP POST handling.

Difference between the Version 11i & R12

We have Oracle forms 6i in 11i Oracle E-buisness Suite while Oracle forms 10g in R12.0/R12.1/R12.2 Oracle E-buisness Suite.

The basics remains same in all these. The executable differs between different version

Forms Artifact Definitions

-The .fmb file is a Form source file. It’s a binary file, which contains metadata, source and compiled PLSQL.
-The .fmx file is the generated version of the Form used at runtime
-The .mmb file is the Menu source file. It’s a binary file.
-The .mmx file is the generated version of the Menu used at runtime
-The .pll file is the client side attached library source file. It can also be used at runtime, although Oracle Applications should use plx files. It contains source, and compiled PLSQL.
-The .plx file is a source stripped version of the .pll, used at runtime. It contains compiled PLSQL.
–f60webmx is the middle tier forms runtime process on Unix. (11i)
–frmweb is the middle tier forms runtime process on Unix. (R12.0/R12.1/R12.2)
–f60srvm is the Forms Listener Process on Linux
-The Forms Applet is generic across platforms. The Forms Applet is also generic in that a single applet is used to run all Forms.
-Java Beans are used to implement Oracle Applications client side logic by extending the Forms Applet.

Forms, Libraries and Menus

On the middle tier, a Forms application consists of forms, menus and libraries. There are also database objects and server side packages and procedures on the RDBMS, but these will not be considered in this document.
A form source file is a binary file and has a .fmb suffix, e.g. XYZ.fmb. It contains all the relevant metadata, PL/SQL program units and compiled PL/SQL. The fmb file is not used at runtime, but can be opened in the Form Builder or used to generate the runtime version (.fmx) of the form.

The .fmx file is essentially a binary parameter file that is read by the Forms runtime executable. It is not an executable itself, although generating the .fmx is sometimes referred to as ‘compiling’ and the .fmx is often called the ‘executable’.
A .fmx file cannot be reverse engineered back into the corresponding .FMB.
Application forms are translated, so each language has its own set of forms. For example, ~/forms/US is for users where the language on the middle tier (NLS_LANG) set to American English.

Similar principles apply to menus, where an mmb suffix denotes a source file, and an mmx suffix a generated version. Applications only uses one menu, FNDMENU. Like a form, this menu is translated into different languages, located for under ~/resource/US.
Libraries follow slightly different rules to forms and menus. The source file has a .pll suffix, and the stripped source has a .plx suffix. The .pll can be loaded in the Builder, generated, and used at runtime; it contains both source and compiled PL/SQL. The .plx has the source stripped out and just contains compiled PL/SQL, so can only be used at runtime. Oracle Applications uses the .plx at runtime, as it is much smaller and therefore more efficient.
Libraries do not contain any translatable strings, so there is one version for all languages, which is saved in the ~/resource directory.

Libraries are dynamically linked in at runtime. The Applications standard is for the developer to attach a library without path or .pll/.plx suffix. Forms searches for a library first in the current directory, and then in each directory specified in FORMS60_PATH. It searches for a .plx first, then a .pll.
As stated, Applications uses the .PLX because it is smaller and requires less memory. However, sometimes problems with the environment, especially when used for custom development, can lead to the .PLL being found first. Again, truss can quickly identify this type of problem.

Forms

forms is a user interface to insert, update and delete data into and from the database

While developing Oracle Applications forms, we follow some development standard
After development, a form must be registered with Oracle Application Object Library
FND_FORMS is a table in APPLSYS schema that stores information about forms

Custom forms needs to be registered in the Application
Custom Form can be defined using the

Responsibility:- System Administrator
Navigation Path ->Application ->Forms

How to Register a Custom Form in Oracle Applications

Log into the Applications Developer responsibility.
Navigate to Application > Form.
Enter the form name under the “Form” column: TECHRPT
4 Enter the Application under the “Application” column using the list of value button, or the “List of Values” function under the “Edit” menu option:
Application Object Library

Enter a name for the form under the “User Form Name” column:
My Technical Report Form
Enter a description for the form under the “Description” column:
Custom Technical Report Form
Save.

Also Reads
Oracle HTTP Server in EBS
OC4J Container