Important Oracle Forms Architecture Features in R12

Last updated on September 29th, 2018 at 08:42 am

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

Features of Forms in R12

-forms are deployed as a one One OC4J instance of 10.1.3 Oracle home
-It uses the utlity 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 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/ replaces f60desm for design 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/ replaces f60desm for design 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.


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 Servlet Mode

  1. HTTP and HTTPS traffic is easily recognizable by routers, while socket mode communications is generally considered suspect and treated on an exception basis.
  2. Existing networking hardware can be used to support basic functions such as load-balancing and packet encryption for network transit.
  3. More resilient to network and firewall reconfigurations.
  4. More robust: servlet connections can be reestablished if network connections drop unexpectedly for Forms, Framework, and JSP-based pages.
  5. 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.
  6. Performance traffic can be monitored via tools like Oracle Real User Experience Insight (RUEI).
  7. Socket mode is not supported on Windows-based server platforms.
  8. No port needs to open to access forms in firewall in case servlet.
  9. Simple SSL Configuration in case of servlet (as no separate ssl configuration is required for Forms as connections are via web/http server)
  10. 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.

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.

To migrate to socket mode architecture in forms on R12
execute: $FND_TOP/bin/ -script=ChangeFormsMode -mode=socket
For more details see Oracle MetaLink Note 384241.1


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

We are presenting here the basics of Oracle Forms in  11i/R12

Summary of Forms 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 Unix
-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. XXXXX.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.

Leave a Reply