http://download.oracle.com/docs/cd/B25527_01/doc/frs/forms/B14032_02/tracing.htm#CEGBHAGH
http://mspdv147.us.oracle.com:7778/forms/frmservlet?config=rms_prd&record=forms&tracegroup=128-137

$ emctl stop agent && emctl stop em && dcmctl stop && opmnctl stopall
$ opmnctl startall && dcmctl start && emctl start agent && emctl start em

Last Updated: September 5, 2007 4:25 PM

In This Document

This document describes the Forms Trace diagnostics utility, and includes the following sections

Section 1: Introduction to Forms Trace
An overview of Forms Trace
Section 2: Activating Forms Trace
How to activate Forms Trace in Applications:
- Oracle Applications Manager
- Applications Profile
Section 3: Defining a Trace Group
Guidelines on what events to trace
Section 4: Trace File Location
How to locate a trace file on the instance
Section 5: Translating a Trace File
How to create an XML output file from a binary trace file
Section 6: Interpreting a Trace File
Viewing and interpreting the output of a trace file
Section 7: Forms Runtime Diagnostics (FRD)
Section 8: Known Issues
Appendix A: Reference

The most current version of this document can be obtained in OracleMetaLink Note 373548.1.

There is a change log at the end of this document.

Section 1: Introduction to Forms Trace

The Oracle Applications Release 12 technology stack introduces major enhancements to some of the most commonly used technologies in Oracle Applications, including Forms and Reports, the HTTP listener, and Java deployment.

To help accomplish this, the technology stack utilizes two new Oracle Homes:

The Oracle Application Server (OracleAS) 10.1.2 Oracle home (sometimes known as the "C home", "Tools home", "Developer home", or "Forms home") includes the Forms and Reports runtime executables. Oracle Application Server 10.1.2 includes Forms Runtime 10.1.2.0.2.
The Oracle Application Server 10.1.3 Oracle home (sometimes known as the "Java home" or "Web home") includes the Oracle Process Monitor and Notification (OPMN), HTTP listener, and Oracle Containers for Java (OC4J). This Oracle home is used for the deployment and management of applications.

This document focuses on the OracleAS 10.1.2 Oracle home.

Forms Trace was introduced with Forms 9i. It provides detailed data collection and other features to assist the user in diagnosing and investigating forms runtime problems. It has the ability to record both built-in Forms data and performance data in a single output. The data can be output in either HyperText Markup Language (HTML) or Extensible Markup Language (XML) format, depending on your specific requirements.

Forms Trace works by assigning an event id to each traceable event.
Examples:

event 66 = Trigger Start & End
event 41 = Window Close
For a complete list of events, refer to Oracle® Application Server Forms Services Deployment Oracle® Application Server Forms Services Deployment Guide, Section 8, Tracing and Diagnostics. These events can be pooled into a trace group to provide customized output that suits the problem being investigated.

Unlike the older FRD (Forms Runtime Diagnostics) utility, which wrote a text file to the application tier file system, Forms Trace uses a two-step process:

Record a binary, non-port specific trace (.trc) file.
Translate the output to the required format (HTML or XML).

When using Oracle Applications Manager (OAM), the translation is transparent to the user but the output is in XML format only.

Section 2: Activating Forms Trace

Forms trace is activated either through Oracle Applications Manager or by amending the forms launcher URL.

2.1 Via Oracle Applications Manager

Details of this functionality are being finalized, and will be included in a later revision of this document.

2.2 Via Application Profiles

Forms Trace can be activated by amending the forms launcher URL and adding the record=forms parameter.

For example:

http://hostname.domain:port/forms/frmservice?record=forms

This will activate Forms Trace. By default, it will trace errors only. To utilize the full flexibility of Forms Trace, the record=forms parameter must be used in conjunction with the tracegroup parameter. This parameter defines specific events to be traced (see Section 3: Defining a Trace Group).

The tracegroup parameter can be:

A list of events, e.g. tracegroup=1,2,3,4,5.
A range, e.g. tracegroup=1-5
A keyword that is specified in the file ftrace.cfg, e.g. tracegroup=mygroup.
A combination of some or all of the above, e.g. tracegroup=0-3,34,67,mygroup.

2.2.1 Steps to Activate Forms Trace using Application Profiles

Note: Forms Trace should only be activated as and when required, and for specific users.

Forms Level Activation

Sign on to Oracle Applications as a user with the System Administrator responsibility.
Select the System Administrator responsibility.
Select the Profile -> System function (this will launch Forms).
Search for the Applications user and the profile option Forms Runtime Parameters.
Add the required parameters, using the syntax: record=forms tracegroup=.
Examples:

record=forms tracegroup=0-97
record=forms tracegroup=medium

Note the space between the parameter/value pairs.
Commit the changes and log out of Applications.
Restart the Forms OC4J group using either adformsctl.sh (servlet) or adformsrvctl.sh (socket).
Log in to Applications as the user whose Forms Runtime Parameters profile option was amended.

The forms trace file will be written to the $FORMS_TRACE_DIR directory. By default, this directory is named forms_.trc, where is the process identifier.

Self-Service Level Activation

Sign on to Oracle Applications as a user with the System Administrator responsibility.
Select the Functional Administrator responsibility.
Select the Core Services tab.
Select the Profiles link from the Menu bar.
For the Name value enter the profile option: Forms Runtime Parameters then Click the "Go" button to proceed.
Select the listed value Forms Runtime Parameters then Click the "Define Profile Values" button.
Choose "User" from the Folder tabs available then click the Add Another Row Button if the desired user and value are not defined.
Add the required parameters, using the syntax: record=forms tracegroup=.
Examples:

record=forms tracegroup=0-97
record=forms tracegroup=medium
Note the space between the parameter/value pairs.
Commit the changes and log out of Applications.
Restart the Forms OC4J group using either adformsctl.sh (servlet) or adformsrvctl.sh (socket).
Log in to Applications as the user whose Forms Runtime Parameters profile option was amended.

The forms trace file will be written to the $FORMS_TRACE_DIR directory. By default, this directory is named forms_.trc, where is the process identifier.

Section 3: Defining a Trace Group

With the many trace events available, a trace file could quickly become a maze. After testing various combinations, Applications Development has created several recommended levels of tracing, which are predefined in the file $ORA_CONFIG_HOME/10.1.2/forms/server/ftrace.cfg:

light (0-71,192): Records user actions, error messages and form. service events.
medium (0-97,192,194,195): Includes events in the light tracegroup also captures built-in and user-exit events.
full (0-98,100-199): Captures all information that is currently available through Forms Tracing.
dbsql (32,64,98,100,101,136,137,192): All events related to the database and forms interaction with it
network (64,32,128,129,131,130,132,133,134,192): All events related to communications between client tier and Forms server.

Note: If no trace group is specified, only error events are recorded by default.

Section 4: Trace File Location

The location of the trace file is defined by the runtime environment variable $FORMS_TRACE_DIR, and is included in the file $ORA_CONFIG_HOME/10.1.2/forms/server/default.env. The variable setting is maintained by the value of s_forms_trace_dir in the Applications context file. It can be changed via the Oracle Applications Manager context editor, and instantiated by running AutoConfig.

Section 5: Translating a Trace File

The file created by Forms Trace is a platform-independent binary file that cannot be interpreted directly. It must be converted into XML or HTML by the Forms translation utility. You will need to specify an additional parameter, "OutputClass", which has two legal values: "WriteOut" and "WriteOutHTML".

With "WriteOut", the output file will be in XML format.
With "WriteOutHTML", the output file will in HTML format.

Note that these two values ("WriteOut" and "WriteOutHTML") are case-sensitive.

To perform. the translation you will need access to the Java executable, and either a OracleAS 10.1.2 (Forms) Oracle home or the Forms Developer Suite. The command used to translate is:

/bin/java -cp <10.1.2 ORACLE_HOME>/forms/java/frmxlate.jar 
  oracle.forms.diagnostics.Xlate datafile=$1.trc utputfile=$1.xml utputclass=WriteOut

An XML output file will include values that are not shown in the HTML output file. We therefore recommend using the XML-formatted output for Applications Release 12.

Section 6: Interpreting a Trace File

The default output format of a Forms Trace file is XML. Driven by the events defined by tracegroup, the XML output provides a structured layout to view actions and underlying code operation within the form.

Events may be standalone, or multiple events may be nested within each other. Recorded events within the form. itself have a tag of EventID. This value increases sequentially from the start of the Forms session.

In the following example:

Timestamp is the time in milliseconds that has passed since forms tracing was started.
Duration is the number of milliseconds that an event has taken to be processed. The timestamp at the start of an event is stored internally, and when complete is subtracted from the current timestamp to obtain the duration of that event. There are three types of event:
- Point event: An event that happens in Oracle Forms as the result of a user action or internal signal, and which has no discernible duration in time.
- Duration event: An event with a measurable start and end.
- Builtin event: An event associated with a builtin.
EventID is a sequential number based on the execution of the event.
EventNum is an assigned number value representing the event recorded.

For a complete list of events and associated numbers, see the Forms documentation reference in Appendix A.

The following example shows a trigger with nested details and error events:

- 

  27640

  24

  66

  18360

  - 

  SIGNON

  CONNECT_BUTTON

  WHEN-BUTTON-PRESSED

  FNDSCSGN(1)

  


  - 

  25

  3

  19870

  - 

  Error Message: FRM-40815: Variable GLOBAL.OPM_GML_INSTALLED1 does 
  not exist.

XML tags used in Forms Tracing

encapsulates all activities within the trace file. All recordable events occur within this tag. (Not shown in the example.)
contains a single value, for example an environment variable. This tag does not have an associated eventID. (Not shown in the example.)
may have multiple layers with sequential EventIDs, records of subsequent actions, and details of the actions associated with the trigger activation.
The forms block in which the event is recorded.
The Item on the forms block upon which the action is invoked.
The name of the trigger invoked on the item in the form. block.

Note: When viewed through a browser such as Internet Explorer, the XML document will be parsed, and the various tree levels may be expanded or collapsed to show the parent/child relationship.

Section 7: Forms Runtime Diagnostics (FRD)

Earlier versions of Oracle Forms included a diagnostic tool called the Forms Runtime Diagnostics (FRD) utility. Whilst this utility is no longer being enhanced, it is still available for use in Applications Release 12. FRD is preferred by some developers who are familiar with the output style. Also, the FRD output text file is smaller than the equivalent XML output file created by Forms Trace.

Activating Forms Runtime Diagnostics using Applications Profiles