Stat 6.2 - Install Notes

Administration

A separate instance of the agent must be started on the server for each Oracle® E-Business Suite environment. The Stat® Oracle Agent must be started as the Oracle E-Business Suite user (e.g. applmgr) for the environment (not the user created during the installation). Set the <STAT_HOME>, STAT_JAVA_HOME, and PATH in the profile of the Oracle E-Business Suite user on each server. The <STAT_HOME>/bin/statctl.sh utility should be used to control the Stat Oracle Agent.

NOTE: The statctl.sh is a UNIX based utility. MKS is required on Windows platforms to administer the Stat Oracle Agent.

A log of the agent can be found in <STAT_HOME>/log. A separate log file is created for each instance of the agent.

The following command can be used to start an instance of the Stat Oracle Agent for the Dev Oracle E-Business Suite environment

The following command can be used to stop the instance of the Stat® Agent for Ora Apps for the Test Oracle E- Business Suite environment. This command will send a shutdown request to the administration port on the local server. The agent will terminate after all queued events are processed.

If the Stat Central Agent is shut down or disabled, the Stat Agents for Ora Apps are unable to execute any commands or processes. Before re-starting the Stat Central Agent, shut down each Stat Agent for Ora Apps. Then re-start the Stat Central Agent, wait for the startup process to complete (in the server console, you will see the line, “Stat Central Agent is started”), and re-start each Stat Agent for Ora Apps.

The following command can be used to display the status of the Stat Agent for Ora Apps for the Production Oracle E-Business Suite environment.

The following command can be used to abort the Stat Oracle Agent for the Test Oracle E-Business Suite environment. The agent will be terminated immediately. Caution: This could potentially leave events in an unstable state. It may be necessary to re-processes events in-progress or pending when the agent process was aborted. This option should only be used as a last measure for terminating the agent.

The following command can be used to show the Stat Oracle Agent is alive along with the number of queued and in process messages.

Dynamically changing log level

The default logging level for an instance of the Stat® Oracle Agent is determined by the <ENV>.log.level parameter. You can change the logging level for a running agent using the <STAT_HOME>/app/bin/setLogLevel.sh utility.

Stat Oracle Agent version

The build (i.e., version) for the Stat Oracle Agent is included with header block in the log file when starting an instance of the agent. A listing of the build is displayed with the <STAT_HOME>/app/bin/getversion.sh utility.

Custom products and file locations

Stat® Agents for Oracle® Apps use the stat.conf file and the Oracle E-Business Suite environment file to resolve the top-level directory for each product. In the case of custom products, you may need to add an entry in the stat.conf file for each Agent. For example, if you created an application named XXXGL for customizations to GL, you would add the following entry to utilize Stat functionality for these custom objects:

For R12.2 environments, if these base directories are under the Edition-based File System, then the value for each Base Directory must come from the Context File. In that case, you do not need to add an entry to the stat.conf file anymore.

Also Note that in general if a value is defined for any parameter in stat.conf, it always overrides the value read from the Context File.

When you define a custom product, Oracle requires that you create certain directories and sub-directories for the form and report files to work properly with the application. The rules for other file types (e.g. SQL) are not strictly enforced by Oracle. But if you want to use Stat to maintain all file types, you must adhere to the Oracle file storage conventions.

Stat provides support for other file types not listed (e.g. ODF and DRV) that are unique for Oracle's patching process. Stat inactivates these object types since they are unlikely to be used for custom Oracle E-Business Suite development.

The FMB files for forms defined for a custom product can exist in AU_TOP/forms/<lang>, <custom top>/forms/<lang>, or <custom top>/forms. When migrating a FMB file for a custom product, the FMB file will be updated if it already exists in one of these directories. If the file does not exist, Stat creates the FMB file in either <custom top>/forms/<lang> (preferred) or <custom top>/forms. The form FMX file is generated in either <custom top>/forms/<lang> (preferred) or <custom top>/forms.

The PLL files for form libraries for a custom product can exist in AU_TOP/resource or <custom top>/resource. When listing all PLL objects, the PLL files from the resource sub-directory of the selected product are displayed. PLL files are always migrated to the AU_TOP/resource directory. The form library PLX file is always generated in <product top>/resource.

NOTE: For users that plan to compare form library files that have attached libraries, there are special configuration steps that must be performed. For more information, see Object Compare Support for Form Library Files.

The RDF files for reports for a custom product must exist in either <custom top>/reports/<lang> (preferred) or <custom top>/reports. The RDF file is generated in the same directory.

All PL/SQL File objects for custom products must be maintained in <custom top>/admin/sql (preferred) or <custom top>/sql. If directory <custom top>/admin/sql exists, Stat only processes SQL and PLS files in this directory. Otherwise, Stat processes SQL and PLS files in the <custom top>/sql directory.

Stat executes PL/SQL files against the database using SQL*Plus during migration. These files must not contain any parameters. If a substitution parameter is included, SQL*Plus will prompt the Stat Oracle Agent. However, the Stat Oracle Agent will not reply and timeout after a few minutes and fail the migration.

All SQL Script objects for custom products must be maintained in <custom top>/admin/sql. These files are executed against the database using SQL*Plus during migration. These files must not contain any parameters. If a substitution parameter is included, SQL*Plus will prompt the Stat Oracle Agent. However, the Stat Oracle Agent will not reply and timeout after a few minutes and fail the migration.

All SQL Report files for custom products must be maintained in <custom top>/sql. These files are not executed against the database.

Any file contained in the <custom top>/bin directory is classified as an executable. Executable files can be archived and migrated. No additional post-processing is performed on these files.

Oracle maintains object files (*.o) and product archive files (*.a). Stat supports archiving and migrating object files (not archive files). No post-processing is performed on these files. You can also use Stat to support custom object files that are maintained in a product archive file.

The product archive file exists in <product top>/lib and must be defined as “lib<product code>.a” (e.g.

$GL_TOP/lib/libgl.a). The archive file serves as a container for all object files for a product. Although object files may exist in <product top>/lib, Stat uses the object files contained in the archive file when archiving and migrating these files. A generic object type can be created to support change management of the source code files for custom object files.

NOTE: A typical installation of Stat comes with a number of Setup objects. These objects are referred to as AOL objects. These objects support archiving and migration of data from the FND (Application Object Library) product top. In addition, Stat provides Oracle Apps Resource Kit, which gives customers the option of adding support for object types from 10 other product tops, including ALR, AP, AR, BOM, FA, FF, GL, INV, ONT, and PA.