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.
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. |
Base directory codes
After defining a new base directory or editing an existing one in the File Object Maintenance table, you need to update the configuration file of the Stat® Oracle® Agent. The Stat Oracle Agent must be able to resolve the base directory codes when processing generic file objects. For example, if in the File Object Maintenance table you defined a base directory code COMMON_TOP, you must add the following parameter to all the Oracle Agents that will process the generic objects using this base directory code:
The syntax for the parameter is <EnvCode>.env.<BaseDirectory>=<value>. The parameter in this example is added to the Oracle Agent for the “Dev” environment. The parameter can be set to a different directory for each agent.
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. An example of these types of Base Directories would be OA_HTML. This parameter is defined in the Context file with a value for both the fs1 and fs2 file system. To retrieve values from the Context File, you always need an XPath expression. A new column called Context Pattern is defined in Stat which stores the XPath expression for retrieving the value from the Context File. (You may need to consult with your DBA and refer to documentation for EXTRACTVALUE command). For example the expression for retrieving OA_HTML from the Context file is:
Note that if these Base Directories are not under the Edition-based File System, then the value for the Base Directory is defined in stat.conf as before.
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.
