In this article we will discuss how a Oracle Form runs in a server and how the client machines access them.
Oracle Forms applications are deployed to the web through a three-tier architecture. Application logic and the Forms Services Runtime Engine reside on the middle-tier application server. All trigger processing occurs on database and application servers, while user interface processing occurs on the Forms client. End users can run Forms Developer applications in a Web browser.
Before discussing the runtime process, lets go through the Forms Services Architecture in brief. Forms Services consists of four major components: the Forms Servlet, the Java client (Forms Client), the Forms Listener Servlet, and the Forms Runtime Engine.

Forms Services Architecture
The Forms Servlet is a Java servlet(class) that is capable of creating a dynamic HTML file in the client browser.
The Java client or Forms client(applet) is nothing but a set of Java classes that are downloaded to the client machine when any Form application is called in the client machine for the first time. This component is only responsible to display the Form in the Browser and send the user interactions to the middle tier. You do not have to deploy a separate Java applet for each application. The same generic applet is used to run any Forms Services application, regardless of its size and complexity.

The Forms Listener Servlet is a Java servlet that runs in a Web server equipped with a servlet engine, such as OC4J. The Forms Listener Servlet is in charge of managing the creation of the Forms Runtime process for each client and managing the network communications that occur between the client and its associated Forms Runtime process, through the Web server.
The Forms Runtime Engine is a process on the Application Server that is started by the Forms Listener Servlet. The Forms Runtime Engine handles all the application logic and Forms functionality and executes the code written into the application.
Users request a Form application in their Web browsers by entering a URL that points to the application. Forms Services then generates an HTML file that downloads a Java applet to the client machine. This small applet is capable of displaying the user interface of any form, while the application logic is executed on the middle tier.
The URL to invoke an application must have the following format:
http://host[:port]/forms servlet or html file[parameters] (optional portions of URL enclosed in brackets)
For Example:http://dummysite.com:8888/forms90/f90servlet
Where http is a protocol, dummysite.com is the host, 8888 is the port number and forms90/f90servlet is forms servlet alias.
We should have a Java Runtime Environment(JRE) in the client machine to run our Forms. We can use JInitiator, a plug-in that provides a JRE capable of running the Forms applet.
The below is the complete process how we can access a Form application through web:

Oracle Forms Runtime
1] The user accesses the Forms application through a URL in the web browser.
http://dummysite.com:8888/forms90/f90servlet
2] In the middle tier, Oracle HTTP Server or OC4J receives an HTTP request from the browser client and contacts the Forms Servlet.
3] The Forms Servlet dynamically creates an HTML page in the client machine containing all the information to start the Forms session.

Oracle Forms Runtime
4] The Oracle HTTP Server or OC4J downloads a generic applet to the client machine if the Form is called for the first time. The client machine caches the applet so that it can run future Forms applications without downloading it again.
5] The applet in the client machine contacts the Forms Listener Servlet in the middle tier to start the session. The Forms Listener Servlet starts an instance of the Forms Runtime Engine on the Forms Server (middle tier).
6] The Forms Listener Servlet establishes a connection with the Runtime Engine, which connects to the database if needed and loads application executable files.

Oracle Forms Runtime
7] The Forms applet displays the Form in the main window of the user’s Web browser.
8] The Forms Listener Servlet, working through OC4J or the HTTP Server, manages communication between the Forms applet and the Runtime Engine.

Form Name: Customers.fmb
Deployed Application: Custom AR Application
Responsibility: US Receivables Super User
Step 1: COPYING FILES FROM THE SERVER
a) Copy TEMPLATE.fmb file from $AU_TOP/forms/US folder to a local directory. Also downloadAPPSTAND.fmb file and place it in D:DevSuiteHome_1forms
b) Copy All PL/SQL Libraries from $AU_TOP/resource/US folder (one time only). Download all the .pll and .plx files to D:DevSuiteHome_1forms
Step 2: DESIGN THE FROM IN ORACLE FORMS BUILDER
a) Remove the Defaults
                        >Open Oracle Forms Builder
                        >Open the form TEMPLATE.fmb
                        >Rename the form (ex XXARCUST_1)
                        >Delete the followings from object nevigator.
                                    >Go to Data Blocks and delete BLOCKNAME, DETAILBLOCK
                                    >Go to Windows and delete BLOCKNAME
                                    >Go to Canvases and delete BLOCKNAME
b) Create a new Window (ex WINDOW10)
c) Create a new Canvas (ex CANVAS10) and attached it to the new Window via Property Palate
d) Create a new Datablock (ex CUSTOMERS) wth items  from a table.
e) Create a frame in the Canvas and attached the items
f) Modify the PRE-FORM Trigger
                        >Go to triggers—PREFORM
                        >Original Code:                    
FND_STANDARD.FORM_INFO(‘$Revision: 120.0 $’, ‘Template Form’, ‘FND’,
‘$Date: 2005/05/06 23:25  $’, ‘$Author: appldev $’);
 app_standard.event(‘PRE-FORM’);
 app_window.set_window_position(‘BLOCKNAME’, ‘FIRST_WINDOW’);
                     
                        >Modified Code:                     
  FND_STANDARD.FORM_INFO(‘$Revision: 1.0 $’, ‘XXARCUST_1’,’CUST_FORM’,
  ’$Date: 2010/01/06 16:25  $’, ‘$Author: Dibyajyoti $’);
   app_standard.event(‘PRE-FORM’);
    app_window.set_window_position(‘WINDOW10′, ‘FIRST_WINDOW’);
                     
                        > Compile the code

g) Modification for Program unit
                        > Go to APP_CUSTOM*(Package Body)
                        >Type your First window name in place of <your first window>
                        > Compile the code
h) If any Item in the Datablock is of Date type and you want to attach a standard calender to it
    (ex Orderdate item of Customers datablock), do the following
                        > Go to Orderdate > Property palate > Subclass Information > Property Class
                        > Give property class name as TEXT_ITEM_DATE
                        > Attach LOV as ENABLE_LIST_LAMP
                        > Create KEY-LISTVAL item level trigger & add following code into it
                           calendar.show; and compile the trigger.
Step 3: DEPLOY THE FORM IN THE SERVER
                         > Upload your .fmb file
Step 4: CREATE THE .fmx FILE IN THE SERVER
>Type the code
$ORACLE_HOME/bin/frmcmp_batch module=$XXAR_TOP/forms/US/CUSTOMERS.fmb         userid=<username>/<password>  output_file=$XXAR_TOP/forms/US/ CUSTOMERS.fmx module_type=form  compile_all=special
Step 5: REGISTARING THE FORM IN ORACLE APPS
a) Registaring the FORM in Oracle Apps
                        > Go to Application Developer  —> Application —> Form
                        > Give the details:
                     
                         FORM: CUSTOMERS(name of the custom form)
                         APPLICATION: Custom AR Application
                         User Form Name: CUSTOMERS_DETAIL
                         Description: Customer Detail form
                        > save
b) Registaring the FORM to a form function
                        > System Administrator —->Application —-> Function
                        > Give the details:
                         Form—->form:CUSTOMERS_DETAIL
                         Function:XX_CUSTOMER_DETAIL
                         APPLICATION: Custom AR Application
                         Properties —> Type: Form
                         User Function Name: CUSTOMERS_DETAIL_FUNCTION
                        > save
c) Finding the menu to which the above form function is to be attached. Again the menu is attached to a responsibilty. So we have go in the reverse order to find the menu name.
                        > System Administrator —->Security —-> Responsibility —->Define
                        > Press F11
                        > Responsibility Name: %US%Rec (searching for US Receivables Super User)
                        > Press Ctrl + F11
                        > This things will come in the form
                         Responsibility Name: US Receivables Super User
                          Application:Receivables (will come automatically )
                        >Take the Menu name   —>AR_NAVIGATE_GUI
                     
d) Attaching the function to a Submenu of the above Main menu
                        > System Administrator —->Application —> Menu
                        > Press F11
                        > Menu: AR_NAVIGATE_GUI
                        > Press Ctrl+F11
                        > Promt: Custom Interfaces
                        > Submenu: XXAR_CUSTOM
                       
                        >System Administrator —->Application —> Menu
                        > Press F11
                        > Menu: XXAR_CUSTOM
                        > Press Ctrl+F11
                        > Create a new
                        > Promt: Customer Detail Form (It will display in the nevigator)
                        >Function: CUSTOMERS_DETAIL_FUNCTION (Attach the function to the submenu)
                        > save
                        >One request has been submitted to recompile your menus in the database
e) Viewing the request submitted in the background to recompile the menus to attach the function
                        > Go to View——–>Requests———>Find
                        >The status should be :Compiled  Normal
Step 6: VIEWING THE FORM IN ORACLE APPLICATION:
                        >Go to Oracle apps front end.
                        >Login with username and password
                        >Go to US Receivables Super User—>Custom Interfaces —>Customer Detail Form

Oracle Forms…What is it?
•A software product for creating screens that interact with an Oracle Database.
•Has a typical IDE including an object navigator, property sheet and code editor that uses PL/SQL.
•Primary focus of Forms is to create data entry systems that access an Oracle database.
•Originally sold as standalone product , now bundled into a package suite called Oracle Developer Suite.
History
•Interactive Application Facility (IAF)
-Block Mode
-Oracle Database 2
•FastForms
-Character Mode
-Oracle Database 4
•SQL*Forms version 2, 2.3
-Character Mode
-Oracle Database 5
•SQL*Forms 3
-Character Mode
-Oracle Database 6
-New IDE, PL/SQL
•Oracle Forms 4.0/4.5
-4.0 was the first “true” GUI based version
-Oracle Database 6/7
-Optimized for client server.
-4.0 interface was slow, buggy and un-popular with client base.
-4.5 was a popular one with enhanced GUI.
•Oracle Forms 5
-Oracle Database 7
•Oracle Forms 6/6i
-Forms server and web forms were introduced.
-Oracle Database 8/8i
•Forms 7 to 8 did not exist. These numbers were jumped over in order to allow the Oracle Forms version number to match the database version.
•Oracle Forms 9i
-Oracle Database 9i
-Stable one with many bug fixes.
-Three-tier, browser based delivery
•Oracle Forms 10g
-Oracle Database 10g
-Actually a Forms release (9.0.4.0.19)
•Oracle Forms 11g
-Oracle Database 11g
-Latest One.

SRW (Sql Report Writer) Package is a built in package in Oracle Reports Builder. It is a collection of PL/SQL constructs that include many functions, procedures, and exceptions you can reference in any of your libraries or reports.
The PL/SQL provided by the SRW package enables you to perform such actions as change the formatting of fields, run reports from within other reports, create customized messages to display in the event of report error, and execute SQL statements. There are nearly 70 functions, procedures, and exceptions are there in this package. Here I am giving brief information and uses of few important functions, procedures, and exceptions.
SRW.MESSAGE:
It is a Procedure that displays a message with the message number and text that you specify. It is mainly used to debug a report in Reports Builder.
SRW.MESSAGE(msg_number NUMBER, msg_text CHAR);
Example:
function foo return boolean is
begin
if :sal < 0 then
SRW.MESSAGE(100, 'Found a negative salary. Check the EMP table.');
raise SRW.PROGRAM_ABORT;
else
:bonus := :sal * .01;
end if;
return(true);
end;

SRW.PROGRAM_ABORT:
This exception stops the report execution and raises the following error message: REP-1419: PL/SQL program aborted. SRW.PROGRAM_ABORT stops report execution when you raise it.
SRW.DO_SQL:
This procedure executes the specified SQL statement from within Reports Builder. The SQL statement can be DDL (statements that define data), or DML (statements that manipulate data). DML statements are usually faster when they are in PL/SQL, instead of in SRW.DO_SQL.
Since you cannot perform DDL statements in PL/SQL, the SRW.DO_SQL packaged procedure is especially useful for performing them within Reports Builder.
Example:

FUNCTION CREATETABLE RETURN BOOLEAN IS
BEGIN
SRW.DO_SQL('CREATE TABLE TEST_EMP (EMPNO NUMBER NOT NULL
PRIMARY KEY, SAL NUMBER (10,2)) PCTFREE 5 PCTUSED 75');
RETURN (TRUE);
EXCEPTION
WHEN SRW.DO_SQL_FAILURE THEN
SRW.MESSAGE(100, 'ERROR WHILE CREATING TEST_EMP TABLE.');
RAISE
SRW.PROGRAM_ABORT;
END;

SRW.DO_SQL_FAILURE:
Reports Builder raises this exception when the SRW.DO_SQL packaged procedure fails. This exception stops the report execution and raises the following error message:
REP-1425: Error running DO_SQL package – REP-msg ORA-msg.
SRW.GET_REPORT_NAME:
This function returns the file name of the report being executed.
SRW.GET_REPORT_NAME (report_name);
Example:

function AfterPForm return boolean is
my_var varchar2(80);
BEGIN
SRW.GET_REPORT_NAME (my_var);
SRW.MESSAGE(0,'Report Filename = '||my_var);
RETURN (TRUE);
END;

SRW.RUN_REPORT:
This procedure synchronously executes the specified report within the context of the currently running report.
SRW.RUN_REPORT (“report=test.rdf … “)
SRW.SET_FIELD:
This procedure sets the value of a character, number, or date field. This is useful when you want to conditionally change a field’s value.
SRW.SET_FIELD (object_id, text CHAR | number NUM | date DATE);
Example:
Suppose you want to conditionally change the number of a field, based on each employee’s salary. In the format trigger for the field, you could type the following:

FUNCTION CHGFIELD RETURN BOOLEAN IS
TMP NUMBER;
BEGIN
if :sal >= 5000 then
tmp := :sal * 1.10;
srw.set_field (0, tmp);
else
srw.set_field (0, 4000);
end if;
RETURN (TRUE);
END;


SRW.SET_FIELD should be used only to change the contents of a field’s datatype, not change the field to a different datatype.


Others in Brief:


  • SRW.SET_FONT_FACE: This procedure specifies font face for a CHAR, DATE, or NUMBER field. SRW.SET_FONT_FACE(‘arial’);

  • SRW.SET_FONT_SIZE: This procedure specifies font size for a CHAR, DATE, or NUMBER field. SRW.SET_FONT_SIZE(10);

  • SRW.SET_FONT_STYLE: This procedure specifies font style for a CHAR, DATE, or NUMBER field. SRW.SET_FONT_STYLE(SRW.ITALIC_STYLE);

  • SRW.SET_FORMAT_MASK: This procedure specifies the format mask for the DATE or NUMBER field. SRW.SET_FORMAT_MASK(‘mask’);

  • SRW.SET_TEXT_COLOR: This procedure specifies the global text color of the CHAR, DATE, or NUMBER field. SRW.SET_TEXT_COLOR(‘color’);


Bind Parameters:
Bind references (or bind variables) are used to replace a single value in SQL or PL/SQL, such as a character string, number, or date. Specifically, bind references may be used to replace expressions in SELECT, WHERE, GROUP BY, ORDER BY, HAVING, CONNECT BY, and START WITH clauses of queries. Bind references may not be referenced in FROM clauses or in place of reserved words or clauses. You create a bind reference by entering a colon (:) followed immediately by the column or parameter name. If you do not create a column or parameter before making a bind reference to it in a SELECT statement, Report Builder will create a parameter for you by default.
Lexical Parameters:
Lexical references are placeholders for text that you embed in a SELECT statement. You can use lexical references to replace the clauses appearing after SELECT, FROM, WHERE, GROUP BY, ORDER BY, HAVING, CONNECT BY, and START WITH. You cannot make lexical references in a PL/SQL statement. You can, however, use a bind reference in PL/SQL to set the value of a parameter that is then referenced lexically in SQL.