| Oracle® Fusion Applications Administrator's Guide 11g Release 1 (11.1.2) Part Number E14496-03 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Administrator's Guide 11g Release 1 (11.1.2) Part Number E14496-03 |
|
|
PDF · Mobi · ePub |
This chapter discusses how to use incidents, log files, QuickTrace, and diagnostics tests to support normal operations for Oracle Fusion Applications and to prepare for future troubleshooting.
This chapter contains the following topics:
Introduction to Incidents, Log File Management, QuickTrace, and Diagnostic Tests
Configuring the Diagnostic Testing Framework for Normal Operation
For information about troubleshooting using log settings, log files, the QuickTrace feature (in-memory logging), diagnostic tests, and incidents, see Chapter 17.
Incidents, log files, QuickTrace, and diagnostic tests can all help you administer Oracle Fusion Applications. If your Oracle Fusion Applications environment includes Oracle Enterprise Manager Cloud Control (Cloud Control), then you can use Support Workbench to help you investigate, report, and resolve problems.
Incidents are collections of information about problematic error conditions. It is strongly recommended that you follow Information Technology Infrastructure Library (ITIL) best practices by establishing a help desk or service desk within your organization to support Oracle Fusion Applications, and have the help desk personnel use incidents to track the troubleshooting and resolution of all problems. Some incidents are created and gather information automatically when problems occur. For example, the information associated with an automatically created incident may include detailed operational info collected by the QuickTrace (in-memory logging) feature for Oracle Fusion Applications. For problems that do not automatically create incidents, administrators or help desk personnel can manually create incidents and manually gather and add related system information.
Log files contain information about both normal and problematic events. Log files can help you both to monitor normal operation diagnose and to address some problems, yourself. For example, log messages that state that a service cannot be reached might indicate a hardware failure. If you discover a more complex issue, Oracle Support personnel may use log files to trace the execution code paths of relevant requests, as part of diagnosing the problem. And log files are particularly helpful if your Oracle implementation contains custom code that needs debugging, especially when using a debugger is not feasible, such as on a production system
The QuickTrace (in-memory logging) feature continuously records a specified level of log detail in an area of memory. The memory is recycled on an ongoing basis, with the oldest information being deleted or overwritten first. Because QuickTrace writes to memory instead of to a log file, it can gather operational information continuously without significantly affecting system performance. The information that QuickTrace stores in memory is written to disk only when an incident occurs or when an administrator manually dumps the contents of a QuickTrace buffer.
Diagnostic tests are executables that are designed to exercise particular aspects of Oracle Fusion applications, to determine whether they are operating correctly and to help identify and resolve any problems. The Diagnostic Testing Framework for Oracle Fusion Applications lets you execute diagnostic tests and collects the results into detailed diagnostic reports. Oracle provides diagnostics tests that are installed along with Oracle Fusion Applications releases and patches.
In Cloud Control, Support Workbench helps you investigate, report, and resolve problems (critical errors). You can use Support Workbench to perform the following kinds of operations:
View summary information about recent problems and incidents
View detailed diagnostic data that was gathered automatically
Manually trigger additional dumps of diagnostic data
Connect to the Diagnostic Dashboard for Oracle Fusion Applications, which provides you with additional diagnostic tests that you can run
Create or update Service Requests with Oracle Support, including uploading diagnostic data to Oracle
For information about using Support Workbench to administer Oracle Fusion Applications targets, specifically, see Chapter 17. For general information about using Support Workbench, see the topic "Support Workbench Page" in the Cloud Control online help and the chapter on investigating, reporting, and resolving problems in Oracle Database 2 Day DBA.
The following features are designed to work together to help you administer and support Oracle Fusion Applications over time:
Logs and Error-Handling: Oracle developers use mechanisms such as application programming interface (API) calls in Oracle Fusion Applications code to record application operations in log files and to provide error messages as appropriate. You can set system log levels to determine how much information is logged.
For more information about setting log levels, see Section 13.7. For more information about using logs to help diagnose a problem, see Chapter 17. For more information about monitoring log files, see Section 13.6, Section 13.6.2, and Section 13.7.4.
Diagnostic Tests: Oracle developers create tests that you can use to help diagnose and resolve Oracle Fusion application problems. A diagnostic test may or may not be associated with a particular error message. If an Oracle Fusion application handles a particular error in a way that triggers the creation of an incident, then any diagnostic tests that are associated with the error message for the incident run automatically. The test results are associated with the incident and the identity of the user who received the error message is recorded.
For more information about diagnostic tests, see Section 13.8, Section 13.9, Section 13.10, and Chapter 17.
It is important to be familiar with the following additional concepts that are related logs and diagnostic tests:
Seed Data: Information that Oracle provides to you in the form of database records. Both error messages and diagnostic tests are included in seed data.
Profiles: Settings that you can select in order to determine details of how the application operates. Oracle Fusion applications include profile options that affect how much information to log either for an entire site or a specific user.
For more information about profiles, see Section 13.7 and the chapter on maintaining common reference objects in the Oracle Fusion Applications Common Implementation Guide.
Under ordinary circumstances, the following administrative tasks are part of necessary setup and maintenance of Oracle Fusion Applications log files:
Tuning system performance by adjusting configuration settings for logs
Reviewing log files for general monitoring of system health
Searching for specific information in log files
Managing available disk space for log files
If your Oracle Fusion Applications environment includes Cloud Control, then you may find it convenient to use Cloud Control to monitor log files in multiple domains, simultaneously.
You can use the Oracle Enterprise Manager Fusion Applications Control (Fusion Applications Control) user interface to complete all of the tasks listed in this section, but only for one WebLogic domain at a time. In particular, you can use Fusion Applications Control to configure log profile option values for Oracle Fusion Applications, although you can also configure profile options by using the Manage Administrator Profile Values screen in the Setup and Maintenance work area. You can use either Cloud Control or Fusion Applications Control for viewing and searching Oracle Fusion Applications log files.
Note:
Fusion Applications Control and Cloud Control are compliant with Information Technology Infrastructure Library (ITIL) best practices.During troubleshooting activities, additional log administration tasks may include downloading log files from servers and packaging incidents for transmittal to Oracle Support. For more information about these activities and the tools for accomplishing them, see Chapter 17.
Oracle provides settings that determine the amount of information that is gathered into the log files for your Oracle Fusion applications. You can either use the default setting values or change one or more values to adjust how much information is gathered. When your system is operating correctly, you may need log entries only for particularly important kinds of events. If your system experiences a problem, you can temporarily increase the amount of information that is logged to get more detailed information while you attempt to reproduce and resolve the problem.
Most Oracle Fusion applications write log output in Oracle Diagnostic Logging (ODL) format. For information about the attributes that appear in standard log files for Oracle Fusion Applications, see the "Understanding ODL Messages and ODL Log Files" section in the Oracle Fusion Middleware Administrator's Guide.
Some Oracle Fusion applications use nonstandard logging mechanisms that are disabled by default. For these applications, you must turn on the logging facility when you need it and specify the kind of information that you want to record in the log file. For more information about these special logging mechanisms, see Section 13.7.6.
A typical log message consists of three parts:
Attributes that are logged by the Oracle Fusion Middleware layer or the Oracle Database layer
Attributes that are logged by logging APIs for Oracle Fusion Applications, including AppsLogger
Message text
This section contains the following topics:
Log Message Attributes Supplied by the Oracle Fusion Middleware and Oracle Database Layers
Log Message Attributes Supplied by Logging APIs for Oracle Fusion Applications
Log Message Attributes Supplied by Oracle Enterprise Scheduler Job Requests
The log message attributes logged by the Oracle Fusion Middleware layer or the Oracle Database layer may include the following:
Date/Time: The date and time when the message was recorded in the log.
Component ID: The component or Oracle WebLogic Server instance from which the message originated. For the Oracle Fusion Middleware layer, a typical value is the name of the Oracle WebLogic Server that was executing the Oracle Fusion application when the message was generated. For the database layer, a typical value is rdbms.
Message Type:Level: Shows the level being logged for the particular message
Message ID: A unique identifier for a seeded message, composed of the product code and a message number. A typical value for a Message ID might be FND-12343.
Module ID: The system or application module that generated the message. This is usually the name of the logger object that generated the message. In some cases, the logger name may reflect the full Java class name of the application code module that was executing when the message was logged. In other cases, the logger object may generate messages for multiple Java classes.
Execution Context ID (ECID): A global unique identifier and a sequence number of the thread of execution that the originating component participates in. The identifier can be used to correlate messages from several components that may be involved in the same thread of execution.
Host: The host name where the message originates. For Java, this should be the value returned by java.net.InetAddress.getLocalHost().getHostName().
Thread ID (TID): A unique identifier for the thread within the Java process where the message was generated.
Java EE Application Name: Name of a Java EE application that was executing when the message was logged.
User Name: A unique identifier that the user enters when signing in to an Oracle Fusion application. This attribute is logged both by Oracle Fusion Middleware and by the logging APIs for Oracle Fusion Applications.
Selective Trace ID (labeled ODL_TRACE_ID in the log file): An identifier for operations in the Oracle Fusion Middleware layer that match criteria an administrator supplied as part of a request to log additional information.
Note:
Selective trace operations do not affect the information that is logged from the Oracle Fusion Applications layer, but the Oracle Fusion Middleware log messages that selective tracing operations obtain are stored in the same log files as log messages from the Oracle Fusion Applications layer. Similarly, log messages from the Oracle Fusion Applications layer are listed along with Oracle Fusion Middleware log messages in selective trace output if those log messages match the trace criteria that the administrator specified. For more information about selective tracing, see the "Configuring and Using Selective Tracing" section in the Oracle Fusion Middleware Administrator's Guide.The log message attributes logged by logging APIs for Oracle Fusion Applications include the following:
User Name: A unique identifier that the user enters when signing in to an Oracle Fusion application. This attribute is logged both by Oracle Fusion Middleware and by the logging APIs for Oracle Fusion Applications.
User GUID: A global unique identifier representing the user.
Role IDs: A list of IDs representing the job roles granted to the user.
Session ID: A unique identifier for the application user session.
Thread Name: A name that identifies the thread generating the log in JVM. Applies only to Oracle Fusion applications that are written in Java. Logging APIs for Oracle Fusion applications that are written in C and PL/SQL do not populate this attribute.
Apps Source: The portion of the Oracle Fusion Applications code that is executing when the message is logged.
Apps Auto Log: Indicates whether the message being logged was logged implicitly.
DB Connection URL: The URL connection string for the application database data source.
Depending on the value of the AFLOG_EXTENDED_ENABLED profile option, the following supplemental attributes may also be logged:
Message Cause: The reason that the message is being logged.
Admin Action: Recommended follow-up action for Oracle Fusion Applications administrators.
Admin Details: Additional information for administrators about the condition being logged.
User Action: Recommended follow-up action for Oracle Fusion Applications users.
User Details: Additional information for users about the condition being logged.
For more information about how the AFLOG_EXTENDED_ENABLED profile option affects the logging of these supplemental attributes, see Section 13.7.1.
The log message attributes logged by the application session include the following:
Product Family: The name of the product family that is executing when the message is logged.
Product: The name of the product that is executing when the message is logged.
The following attributes appear in the log if the log entry is written from an Oracle Enterprise Scheduler job request.
Job Request ID: The identifier of the Oracle Enterprise Scheduler job request that is being executed when this message is logged.
Job Definition Name: The name of the Oracle Enterprise Scheduler job definition. A job definition is the smallest unit of work that is performed in the context of the client application.
Job Package Name: The package location of the Oracle Enterprise Scheduler job definition that is executing when this message is logged.
Job Definition Application: The application that owns the Oracle Enterprise Scheduler job.
The following attributes appear in the log if the log entry is written from SOA:
SOA Composite Name: The name of the SOA Composite that is executing when the message is logged
SOA Component Name: The name of the SOA Component that is executing when the message is logged
SOA Composite Instance ID: The instance ID of the SOA Composite that is executing when the message is logged
SOA Component Instance ID: The instance ID of the SOA Component that is executing when the message is logged
Log Token Map: one or more primary key values for the logical entity that a BPEL process is handling when the message is logged. Oracle Support may require this information for troubleshooting purposes.
To view and search Oracle Fusion application log files effectively, it is important to be familiar with the software that is available for working with log files. From time to time you may also find it helpful to know where log files are stored for various application modules.
This section contains the following topics:
Note:
Each Oracle Fusion Applications module is written in one of the following code languages: Java, SOA, PL/SQL, or C. Details of logging vary depending on the coding language of the application module.In general, you can administer logging for Oracle Fusion Applications without knowing which programming language implements particular modules. However, it is important to become familiar with the configuration settings and log file locations used for each language, so you can monitor or adjust all relevant parts of the system when necessary.
When you want to view log files for one Oracle Fusion Applications product family or product that uses standard logging functionality, one typical way that you can view the log files is to use Fusion Applications Control.
By default, you can use Fusion Applications Control to view standard log files for the Oracle WebLogic Servers that host Oracle Fusion applications and standard log files generated by Java code within Oracle Fusion applications. In addition, you can configure your system to allow Fusion Applications Control to view log files generated by PL/SQL or C code within Oracle Fusion applications. For more information about how to configure this capability, see Section 13.7.7.
From Fusion Applications Control, you can view log messages for different system components by selecting different targets. In the product family part of the navigation tree, the following target types allow viewing of log messages for Oracle Fusion Applications:
An entire product family. When you select this target type and view log files, you view the aggregated logs for all of the servers and clusters in the selected product family's domain.
A particular Oracle Fusion application, such as Procurement, sometimes called an Oracle Fusion Applications cluster application. When you select this target type and view log files, you view the aggregated logs for all of the servers in the selected cluster.
A particular instance of an Oracle Fusion application deployed to a Managed Server. When you select this target type and view log files, you view the log for the selected individual Managed Server.
The Fusion Applications Control screen also gives you access to log files for the following target types in the farm part of the navigation tree, but the functionality used to view those logs is part of Fusion Middleware Control. For more information, see the "Viewing Log Files and Their Messages Using Fusion Middleware Control" section in the Oracle Fusion Middleware Administrator's Guide.
A particular Oracle WebLogic Server domain
A particular server cluster
A particular server within a particular server cluster
Note:
For information about viewing Oracle Fusion Middleware log files, including log files for Oracle Enterprise Scheduler and Oracle Enterprise Crawl and Search Framework, see the "Viewing and Searching Log Files" section in the Oracle Fusion Middleware Administrator's Guide.To view the contents of Oracle Fusion Applications logs from Fusion Applications Control:
From the navigation pane, select the target for which you want to display log contents.
In the part of the navigation tree for the product family, you can display logs for the following kinds of targets:
A product family target lets you display the aggregated log entries for all of the Oracle Fusion applications in the selected product family. For example, Financials is a product family target that appears as a top-level folder in the navigation tree.
An Oracle Fusion Applications cluster application target lets you display the aggregated logs for all of the Managed Servers that run the selected application, including the logs for any other Oracle Fusion applications that run on those Managed Servers. For example, if you expand the product family, Financials, and then expand Fusion Applications, then the PayablesApp listing is a cluster application target.
An Oracle Fusion application instance target lets you display just the log entries for the selected application on the selected sever. For example, if you expand the product family, Financials, and then expand Fusion Applications, and then expand PayablesApp, then the PayablesApp (PayablesServer_1) listing is an application instance target.
Note:
When you select a target, the header of the context pane displays a dropdown menu name that depends on the target type:For a product family target, the menu name is Product Family.
For an Oracle Fusion Applications cluster application target, the menu name is Fusion Cluster Application.
For an Oracle Fusion application instance target, the menu name is Fusion J2EE Application.
Alternatively, if you want to view a log file for an Oracle Fusion Middleware target, you can select such a target from the farm part of the navigation tree. For more information about viewing log files for Oracle Fusion Middleware components, see the "Viewing Log Files and Their Messages Using Fusion Middleware Control" section in the Oracle Fusion Middleware Administrator's Guide.
In the context pane, from the dynamic target menu, choose Logs > View Log Messages to display the log entries for the target you selected.
For most Oracle Fusion applications, you can use Fusion Applications Control to search for log messages that have specific characteristics. Searches that use Fusion Applications Control are very similar to searches that use Fusion Middleware Control. For more information about these searches, see the "Viewing and Searching Log Files" section in the Oracle Fusion Middleware Administrator's Guide.
By default, you can use Fusion Applications Control to search standard log files for Oracle Fusion applications that are written in Java and the Oracle WebLogic Servers that host those applications. You can configure your system to allow Fusion Applications Control to search log files for Oracle Fusion applications that are written in PL/SQL or C, as well. For more information about the necessary configuration steps for PL/SQL and C logs, see Section 13.7.7.
To search standard Oracle Fusion Applications log files using Fusion Applications Control:
From the navigation pane for Fusion Applications Control, select the target for which you want to search log contents.
For your target, you can select a product family such as Financials, an Oracle Fusion Applications cluster application such as LedgerApp, or an Oracle Fusion application instance such as LedgerApp (LedgerServer_1).
Note:
When you select a target, the header of the context pane displays a dropdown menu name that depends on the target type:For a product family target, the menu name is Product Family.
For an Oracle Fusion Applications cluster application target, the menu name is Fusion Cluster Application.
For an Oracle Fusion application instance target, the menu name is Fusion J2EE Application.
For example, if you want to search the aggregated log entries for all of the Oracle Fusion applications in the Financials product family, then you would select the Financials entry in the navigation tree. The Product Family dropdown menu appears under Financials in the context pane header.
If you want to search the aggregated logs for the Ledger cluster application, you would expand the Financials entry in the navigation tree, then expand the Fusion Applications entry, and then select LedgerApp. The Fusion Cluster Application dropdown menu appears under LedgerApp in the context pane header.
If you would rather search the Ledger application log entries for only a particular server, you would expand the Financials entry in the navigation tree, then expand the Fusion Applications entry, then expand the LedgerApp entry, and then select the individual LedgerApp Managed Server for the log you want to search. The Fusion J2EE Application dropdown menu appears under LedgerApp in the context pane header.
In the context pane, from the dynamic target menu, choose Logs > View Log Messages.
If you selected an Oracle Fusion application as your target, the content pane displays the aggregated log messages from all of the servers for the Oracle Fusion application that you selected.
If you selected an individual Oracle Fusion application instance running on a particular Managed Server as your target, the content pane displays just the log messages for the selected Oracle Fusion application operations that were handled by the selected server.
If you selected a product family such as Financials as your target, the content pane displays the aggregated log messages for all of the Managed Servers that handle Oracle Fusion applications in the selected product family.
If necessary, expand the Search area of the content pane.
Enter or select applicable search criteria in any visible search fields, such as the following fields that are visible by default:
In the Date Range fields, specify the time period for which you want to display log messages.
To specify a specific number of the most recent minutes, hours, or days, select Most Recent from the dropdown list, enter your preferred number, and select the appropriate time units.
To specify the time period using starting and ending dates and times, select Time Interval from the dropdown list and enter the starting and ending dates and times.
In the Message Types field, select one or more checkboxes to specify the kinds of log messages that you want to display.
In the Message fields specify some or all of the message text in the log messages that you want to display. No wildcard characters are necessary.
Note:
If you search using more than one criterion, the search results display only log entries that match all of the specified criteria (logical AND).If you want to use search criteria in fields that are not currently visible, complete the following substeps; otherwise, skip this step.
Click Add Fields.
Select one or more checkboxes for the additional fields you want to use in your search, and then click Add.
For example, you might select ECID to search for all log messages that are associated with a particular execution context identifier.
In each field that you added, specify the value that you want the search to match.
For example, you might enter the ECID value of 004bYSyedEi3v1A5Jb8Dyf0002kx003XFf.
Click Search.
Note:
The following information is provided for reference purposes. For maximum clarity and convenience, it is recommended that you use Fusion Applications Control to work with Oracle Fusion Applications log files, rather than working directly with the log files.Each Oracle Fusion application runs in one or more logical Managed Servers. Each Managed Server is dedicated to a single Oracle Fusion application. Different Managed Servers do not normally share log files with each other, even if they are running on the same physical server computer.
Most Oracle Fusion Applications code modules use standard logging code. On each Managed Server, all Java and SOA application code modules that use standard logging code write log entries to a single file. The location of this file is specified by a log_handler entry in a logging.xml file. The default location for the logging.xml file is as follows, where DOMAIN_HOME is the path to your Oracle WebLogic Server domain, and WebLogic_Server_Name is the name of the WebLogic Server that uses the logging.xml file:
DOMAIN_HOME/config/fmwconfig/servers/WebLogic_Server_Name/logging.xml
Example 13-1 shows a typical log_handler entry in the logging.xml file, which includes the path and file name of the log file.
Example 13-1 Typical log_handler Entry Showing Log File Name and Location
<log_handlers>
<log_handler name='apps-handler' class='oracle.core.ojdl.logging.ODLHandlerFactory'>
<property name='path' value='${domain.home}/servers/${weblogic.Name}/logs/apps/${weblogic.Name}-diagnostic.log'/>
<property name='maxFileSize' value='10485760'/>
<property name='maxLogSize' value='104857600'/>
<property name='encoding' value='UTF-8'/>
<property name='supplem8entalAttributes' value='APPS_USER_NAME,
APPS_SESSION_ID, APPS_THREAD_NAME, APPS_SOURCE, APPS_USER_ID, APPS_AUTO_LOG,
APPS_JOB_REQUEST_ID, APPS_JOB_DEFINITION_NAME, APPS_JOB_PACKAGE_NAME,
APPS_JOB_DEFINITION_APP, APPS_COMPOSITE_NAME, APPS_COMPONENT_NAME,
APPS_COMPOSITE_INSTANCE_ID, APPS_COMPONENT_INSTANCE_ID, APPS_PRODUCT_FAMILY,
APPS_PRODUCT, APPS_INDUSTRY, APPS_TERRITORY, APPS_DB_CONNECTION_URL,
APPS_MESSAGE_CAUSE, APPS_USER_ACTION, APPS_ADMIN_ACTION, APPS_USER_DETAILS,
APPS_ADMIN_DETAILS, APPS_LOG_TOKEN_MAP'/>
</log_handler>
</log_handlers>
Example 13-2 shows the default location for the standard log file is as follows, for Oracle Fusion applications that are implemented in Java and SOA, where DOMAIN_HOME is the path to your Oracle WebLogic Server domain:
Example 13-2 Default Log File Location for Oracle Fusion Applications Implemented in Java and SOA
DOMAIN_HOME/servers/domain_name/logs/apps/server_name-diagnostic.log
For Oracle Fusion Applications code modules that are implemented in PL/SQL, the location of the standard log file is set by the AFLOG_PLSQL_FILENAME profile option. By default, the value of this profile option is APPLLOG_DIR/diagnostic.log, where APPLLOG_DIR is a directory object that was defined as a custom variable through use of the Oracle Fusion Applications Repository Creation Utility during installation. For more information about directory objects, see the section about the Create Directory command in the Oracle Database SQL Language Reference
For Oracle Fusion Applications code modules that are implemented in C, the location of the standard log file is set by the AFLOG_FILENAME profile option. By default, the value of this profile option is diagnostic.log, but it is recommended that you set the value to directory_path/Cdiagnostic.log, where directory_path is a location that can be written to by all system users and by the Managed Server where Oracle Enterprise Scheduler is deployed for your Oracle Fusion applications. For example, you might set the value of directory_path to /tmp, or to an explicitly specified directory path that corresponds to the value of the APPLCP_DIR custom variable that was defined through use of the Oracle Fusion Applications Repository Creation Utility during installation.
By default, the following Oracle Fusion Applications code modules do not write log entries. If you configure these modules to write log entries, then the entries for those modules are written to nonstandard log file locations. These modules do not specify any configuration settings using the standard logging.xml file:
The following kinds of batch jobs for Oracle Fusion Incentive Compensation:
Calculation
Classification
Collection
Crediting
Rollup
Note:
For optimum performance, it is recommended that you use the logging functionality that is available for these kinds of Oracle Fusion Incentive Compensation batch jobs only when troubleshooting an existing problem. For more information about using this feature and viewing the results, see Section 17.2.9 and Section 17.5.2.The following kinds of batch jobs for Oracle Fusion General Ledger:
OpenPeriod
Posting
Translation
Close Process - Create Income Statement Closing Journals
Close Process - Create Balance Sheet Closing Journals
Note:
For optimum performance and log file sizes, it is recommended that you use the logging functionality for these kinds of Oracle Fusion General Ledger batch jobs only when troubleshooting an existing problem. For more information about using this feature and viewing the results, see Section 17.2.10.The AutoInvoice portion of the Oracle Fusion Receivables application
Note:
The amount of information that is logged for AutoInvoice depends on the value of the Log File Message Level system option setting for each business unit. Any AutoInvoice log messages that meet the level requirements are written to the standard log file for Oracle Enterprise Scheduler.For more information about configuring the Log File Message Level system option setting, see Section 13.7.6.3. For more information about adjusting this setting for troubleshooting and viewing the results, see Section 17.2.11.
Note:
The following information is provided for reference purposes. For maximum clarity and convenience, it is recommended that you use Fusion Applications Control to work with Oracle Fusion Applications log files, rather than working directly with the log files.If an Oracle Fusion application is deployed to multiple Managed Servers in a cluster domain, each Managed Server records log entries in its own log file, for just the transactions or other operations handled by that server.
For your convenience in monitoring Oracle Fusion applications that run on multiple Managed Servers, Fusion Applications Control lets you view either individual standard log files for individual Managed Servers or the aggregated contents of the standard log files of all of the servers in the cluster domain. The aggregated log is especially useful if you need to find a particular log entry but do not know which Managed Server recorded it. For more information about viewing log files, see Section 13.6.1.
However, Fusion Applications Control does not currently support viewing the contents of any nonstandard log files generated by Oracle Fusion Incentive Compensation, Oracle Fusion General Ledger, or the AutoInvoice portion of the Oracle Fusion Receivables application. For information about viewing nonstandard log files for Oracle Fusion Incentive Compensation, see Section 17.5.2. For information about viewing nonstandard log files for Oracle Fusion General Ledger, see Section 17.2.10. Log entries for the AutoInvoice portion of Oracle Fusion Receivables are placed in the standard log file for Oracle Enterprise Scheduler. For information about viewing Oracle Fusion Middleware log files, including log files for Oracle Enterprise Scheduler, see the "Viewing and Searching Log Files" section in the Oracle Fusion Middleware Administrator's Guide.
Note:
When an Oracle Fusion application is deployed to multiple Managed Servers in a cluster domain, it is generally recommended that you set the log level to the same value for all of the Managed Servers, so that all of the servers will log comparable amounts and kinds of information. However, you can configure each Managed Server's log level independently, if you have a reason to do so.Although critical business logic sections of Oracle Fusion applications may write more information to log files than less critical areas of the application code, the amount of information that Oracle Fusion applications log depends primarily on how the environment is configured. Oracle supplies default values for log settings, but you can specify different setting values if you want to adjust the amount of information to be logged. Most Oracle Fusion Applications components use a standard set of log configuration settings. For information about the selected components that use nonstandard log settings, see Section 13.7.6.
This section contains the following topics:
The concepts of logging levels and profile options apply to most Oracle Fusion applications. Logging levels are thresholds that can be set to control how much information to log.
To set logging levels either for a whole site or for a particular user, administrators change profile option values from either the Log Configuration dialog box in Fusion Applications Control or the Manage Administrator Profile Values screen in the Setup and Maintenance work area. For more information, see the chapter on maintaining common reference objects in the Oracle Fusion Applications Common Implementation Guide.
Under certain specific conditions, Oracle Fusion Applications users can set their own profile option for logging levels, from the Troubleshooting Options dialog box under the Oracle Fusion Applications Help > Troubleshooting menu. Setting a logging level for a particular user is useful if you want only that user to gather more detailed log information while attempting to reproduce a problem. However, the Help > Troubleshooting menu displays the Troubleshooting Options command only for Oracle Fusion Applications users who have a job role that is mapped to the following three duty roles:
Supportability Level Management Duty (CRM) (FND_SET_SUPPORTABILITY_LEVEL_DUTY_CRM)
Supportability Level Management Duty (FSCM) (FND_SUPPORTABILITY_LEVEL_MANAGEMENT_DUTY_FSCM)
Supportability Level Management Duty (HCM) (FND_SUPPORTABILITY_LEVEL_MANAGEMENT_DUTY_HCM)
Note:
Oracle Fusion Applications seed data does not include a preconfigured job role that maps to these three duty roles. It is recommended that you define such a job role when you first need to give an Oracle Fusion Applications user access to the Troubleshooting Options dialog box. You can reuse the same job role for other users who subsequently need the same access.For more information about making the Troubleshooting Options command and dialog box available to selected Oracle Fusion Applications users, and about working with those users to gather troubleshooting data, see Section 17.2.1.
The following types of settings affect how logging is done, including the effective logging level:
AFLOG_SettingName profile option values. For information about the AFLOG_SettingName profile options, see Section 13.7.1 through Section 13.7.5. For general information about working with profile options at both the SITE and USER levels, see the "Setting and Accessing Profile Values" and "Managing Profile Definitions" sections in the Oracle Fusion Applications Developer's Guide.
Note:
ForAFLOG_SettingName profile options, the PRODUCT level is reserved for future use.Oracle Diagnostics Logging Level: The log level for Oracle Fusion applications that are written in Java or SOA. The value for this setting is specified in each Managed Server's logging.xml file, in the oracle.apps entry. Log levels for most entries are adjusted using the Managed Server's Log Configuration screen in Fusion Middleware Control, rather than by directly editing the logging.xml file. However, the log level for the oracle.apps entry should remain set to the default value of All unless Oracle Support gives you specific instructions to change it. For more information about this setting, see "Setting the Level of Information Written to Log Files" in the Oracle Fusion Middleware Administrator's Guide.
Caution:
The logging framework for Oracle Fusion Applications is designed to work with the Log Level for theoracle.apps logger set to the default value of All. If you use other values for this setting, the diagnostic framework may not appear to work correctly, because setting values other than All can interfere with normal logging operations.The seed data for Oracle Fusion Applications contains default values for many profile option settings. Normal operation settings for log files are described in Table 13-1. For information about default system settings for incidents and QuickTrace, see Section 17.2.
Table 13-1 Profile Options for Oracle Fusion Applications Logging
| Profile Option Name(and Display Name) | Environment | Description | Possible Values or Example | Applicable Profile Hierarchy Levels | Default Value |
|---|---|---|---|---|---|
|
(FND: Buffer Mode for PL/SQL) |
PL/SQL only |
Asynchronous buffer mode for PL/SQL logging. A value of 0 disables buffering; a value greater than 0 enables buffering for messages that have levels lower than You may want to use asynchronous buffering if you have set your log levels to collect very detailed information and find that your system is running slowly. When asynchronous buffering is enabled, log messages from PL/SQL code that are at the INFO log level or below are written to a buffer rather than being immediately written to a log file. This reduces disk I/O activity. The buffer is written to the log file only when it contains the number of records specified in the |
|
|
|
|
(FND: Buffer Size for PL/SQL) |
PL/SQL only |
Number of PL/SQL log records that are buffered in memory before they are written to the log file. |
|
|
|
|
(FND: Log Enabled) |
Java, PL/SQL, C, and SOA |
Enables or disables standard logging functionality for Oracle Fusion Applications. If the value of this profile option is N, and if the profile option sets the effective logging level, then standard Oracle Fusion Applications logging does not occur at runtime for application modules written in Java, PL/SQL, SOA, or C. This profile option does not affect the configuration for Oracle Fusion Middleware. |
|
|
|
|
(FND: Log Extension Enabled) |
Java and SOA |
Determines whether or not to log the following extended attributes:
When the value of this profile option is |
|
|
|
|
(FND: Log File for C) |
C only |
Full path and file name of the log file for all of the Oracle Fusion applications that are written in C and that use standard logging functionality. It is recommended that you set the value of this profile option to If you do not set a directory path for this log file, the file is written to the default location specified by Oracle Enterprise Scheduler. |
|
|
|
|
(FND: Log Level) |
Java, PL/SQL, C, and SOA |
Minimum level of information detail to be logged for Oracle Fusion applications that use standard logging functionality. If no value is set for this profile option, the default value is For more information about log levels, see Section 13.7.3. |
|
|
|
|
(FND: Maximum size for log file in MB.) |
PL/SQL |
Specifies the size in megabytes beyond which the current standard log file for Oracle Fusion applications that are written in PL/SQL is automatically renamed and a new log file is started. |
|
|
|
|
(FND: Log Module Filter) |
Java, PL/SQL, C, and SOA |
Specifies the Oracle Fusion applications for which logging takes place. Use a comma-separated list of modules for value of this setting, and use |
|
|
|
|
FND: Number of old log files |
PL/SQL |
The maximum number of PL/SQL log files the system keeps at any one time. |
Any integer greater than zero.) |
|
|
|
(FND: Log File for PL/SQL) |
PL/SQL only |
The location and name of the log file for standard Oracle Fusion Applications log messages that are generated from PL/SQL. The location must be expressed as a directory object. By default, the If you would like the log file name to indicate that the log messages are generated from PL/SQL, you can change the For more information about directory objects, see the section about the Create Directory command in the Oracle Database SQL Language Reference. |
|
|
|
|
(Message Mode) |
Java, PL/SQL, C, and SOA |
For error conditions that use messages from the message dictionary, this setting determines whether administrator-level or user-level message details and suggested actions are displayed and logged. |
|
|
|
For PL/SQL and C processes such as scheduled jobs, changes to log file profile options take effect in the same ways as changes to any Oracle Fusion Applications profile option values. For more information, see the chapter on maintaining common reference objects in the Oracle Fusion Applications Common Implementation Guide.
For user sessions, users may need to log out from an Oracle Fusion application and log in again in order to have changes to log profile options take effect.
Seven severity levels are used for log messages in Oracle Fusion Applications, and each level is associated with a number. In circumstances where the effective logging level depends on the AFLOG_LEVEL logging profile option (rather than a lower odlLevel setting value), then, once the profile option level is set, only application messages that have a predefined severity level greater than or equal to the value of the AFLOG_LEVEL profile option are logged.
You can set the value of the AFLOG_LEVEL profile option to one value for the site as a whole, and to another value for any user whose operations you want to log at a different level of detail.
For example, setting the level to the lowest severity, 300 (FINEST), for a particular user means that messages of all seven severities are logged for that user's operations. Setting the level to 900 (WARNING) or the site means that logging occurs for 900 (WARNING)and 1000 (SEVERE) messages for all site operations initiated by other users.
Note:
The default severity level for Oracle Fusion Applications is1000 (SEVERE. For optimum performance, it is recommended that you use this logging level for your sites unless you need to investigate a problem that specifically requires a change to a site's severity level. Gathering detailed log information for an entire site (rather than a single user) can decrease system performance and make it difficult to find relevant information in a log file.Table 13-2 describes the seven severity levels that are used for log messages in Oracle Fusion Applications. The messages in the log file identify the severity of errors using the ODL Message Type/Level value.
Note:
Oracle Fusion applications that are written in PL/SQL have logging level names that start withLEVEL_. Oracle Fusion applications that are written in Java, SOA, and C do not use this LEVEL_ prefix for level names. For example, the log level that is called LEVEL_SEVERE in PL/SQL application code is comparable to the log level that is called SEVERE in Java, SOA, or C code.
Most log levels provide information that is useful to Oracle Fusion Applications administrators. However, the information that is logged at the FINER and FINEST log levels is primarily intended for use by Oracle.
Table 13-2 Severity Levels for Logging Messages
| ODL Message Type/Level (in Log Files) | Log Level Name (in Oracle Enterprise Manager Fusion Applications Control and Help > Troubleshooting > Troubleshooting Options) | AFLOG_LEVEL Profile Option Value (internal values stored in database tables) | Usage and Examples |
|---|---|---|---|
|
Log Levels for Reporting Failures and Normal Events: |
|||
|
|
|
|
Highest severity level. Unexpected errors that occur during normal execution. Fatal exceptions or any other serious problems that require immediate attention from the System Administrator. An error at this level may also create an incident. For example, the following error messages might be associated with this log level:
|
|
|
|
|
Internal software failures. Non-fatal exceptions or errors that allow processing to continue without requiring immediate attention from an administrator. Any potential problem that should be reviewed by the System Administrator. For example, the following error message might be associated with this log level:
|
|
|
|
|
Errors, warnings and other kinds of information that allow processing to continue. May include key flow steps, high-level functional progress messages, and major life cycle events such as the activation or deactivation of a primary sub-component or feature. |
|
Log Levels for Tracing and Reporting Progress: |
|||
|
|
|
|
Configuration properties and environment settings. This is a finer level of granularity for reporting normal events. |
|
|
|
|
High-level technical progress messages; more detailed than For example, the following error message might be associated with this log level:
|
|
|
|
|
Logging messages that are called at the beginning and end of a routine. Detailed trace or debug information that can help Oracle Support diagnose problems with a particular subsystem. For example, the following error message might be associated with this log level:
|
|
|
|
|
Very detailed trace or debug information that would be useful to an Oracle developer who is working on the product and who is familiar with implementation details of the sub-system that generates the message. For example, the following error message might be associated with this log level: Copying string from buffer xyz to buffer zzz. |
Note:
Whenever an incident is created, a different log level,INCIDENT_ERROR, automatically appears in the corresponding log entry. This is the only context in which the INCIDENT_ERROR log level is used. For more information about working with incidents, see Chapter 17.In busy computing environments, the amount of disk space used by log files can become a concern. Very large log files can also affect system performance. Oracle Fusion applications that are written in Java, SOA, or PL/SQL address this concern using automatic log file rotation.
This section contains the following topics:
Managing Rotating Log File Space Usage for Java and SOA Applications
Managing Rotating Log File Space Usage for PL/SQL Applications
Note:
Oracle Fusion applications that are written in C require you to monitor the space used and manually discard log files that are no longer needed.For Oracle Fusion Applications modules that are implemented using Java or SOA and that use standard logging, when a the log file reaches a specific size or when a specific time period has passed, the file is automatically renamed, and a new log file is created.
You can use any of the following methods to adjust the settings that determine the maximum log file size and the maximum length of time that a log file covers:
Use Fusion Middleware Control commands to change the log rotation policies for the oracle.apps logger. For more information, see "Specifying Log File Rotation Using Fusion Middleware Control" in the Oracle Fusion Middleware Administrator's Guide.
Edit the settings in the log_handler section of the ODL configuration file, at the following location:
DOMAIN_HOME/config/fmwconfig/servers/WebLogic_Server_Name/logging.xml
where DOMAIN_HOME is the domain home directory for the Oracle WebLogic Server domain, and WebLogic_Server_Name is the name of the WebLogic Server that uses the logging.xml file.
Use WebLogic Scripting Tool (WLST) Log Configuration commands to change the log rotation policies for the apps-handler log handler. For more information, see the section on the configureLogHandler command in the chapter on logging commands in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference and "Specifying Log File Rotation Using WLST" in the Oracle Fusion Middleware Administrator's Guide.
The maxFileSize or Maximum Log File Size setting determines the maximum size that a standard Java or SOA log file can reach before being renamed. The default value is 10485760 bytes.
The rotationFrequency or Frequency setting determines the maximum amount of time that can pass before a standard Java or SOA log file is renamed. There is no default value for this setting. If no value is specified, then the log file is not renamed after any particular time period, but only when it reaches its maximum allowed size. Valid values for the rotationFrequency setting are numbers representing the length of the time period in minutes, as well as the following case-insensitive values:
hourly
daily
weekly
When a standard Java or SOA log file is renamed, the new name is of the format log_file_name-n.log, where n is a positive integer and log_file_name is the file name specified for the path property of the apps-handler log handler in the logging.xml file. (By default, log_file_name is set to server_name-diagnostic.log).
In log_file_name-n.log, the value of n depends on the names of the log files that are already present in the directory. If the directory contains no previously renamed log files, then the first renamed log file is called log_file_name-1.log. If other log files do exist, then n is set to the next higher integer after the highest integer that is already in use. For example, if the directory contains log_file_name-1.log through log_file_name-8.log at the time when log_file_name.log reaches a time or size limit, then the log_file_name.log file is renamed to log_file_name-9.log
When the aggregated size of current and older log files reaches a specific value, older log files are deleted automatically, to keep the disk space usage of the log file directory below that specific value.
The maxLogSize or Maximum Size of All Log Files setting determines the directory size at which older log files begin to be deleted. The default value is 104857600 bytes.
For Oracle Fusion Applications modules that are implemented using PL/SQL, when a diagnostic.log file reaches a specific size, the diagnostic.log file is automatically renamed, and a new diagnostic.log file is created. If the AFLOG_PLSQL_FILENAME profile option is set so that the logging framework uses a log file name other than diagnostic.log, then the file name that the profile option specifies is used, instead of diagnostic.log.
Use the following profile options settings to specify the maximum log file size:
AFLOG_MAX_FILE_SIZE: This setting specifies the size in megabytes beyond which a PL/SQL log file name is automatically renamed and a new log file is started. The default value is 10 megabytes.
Note:
If theAFLOG_BUFFER_MODE profile option is set to a value larger than 0, enabling asynchronous buffering of PL/SQL log entries, then the actual maximum size of any single PL/SQL log file is the value of AFLOG_MAX_FILE_SIZE plus the number of megabytes that are flushed from the buffer. This value is always approximate, because the amount of information that can accumulate in the buffer is set using the AFLOG_BUFFER_SIZE setting, which specifies a specific number of log records, rather than a specific number of megabytes.AFLOG_NUMBER_OF_LOG_FILES: This setting specifies the maximum number of PL/SQL log files the system keeps at any one time. The default value is 10 files.
PL/SQL log rotation is currently done only on the basis of file size, not on the basis of the passage of a specified amount of time.
When a PL/SQL log file is renamed, the new name depends on whether or not the AFLOG_PLSQL_FILENAME profile option is set:
If the profile option is set, then the new log file name is of the format AFLOG_PLSQL_FILENAME_value-n.log, where n is a positive integer.
If the profile option is not set, then the new log file name is of the format diagnostic-n.log, where n is a positive integer.
The value of n depends on the names of the log files that are already present in the directory. If the directory contains no previously renamed log files, then the first renamed log file is called diagnostic-1.log or AFLOG_PLSQL_FILENAME_value-1.log. If other log files do exist, then n is set to the next higher integer after the highest integer that is already in use. For example, if the directory contains diagnostic-1.log through diagnostic-8.log at the time when the diagnostic.log file surpasses the size limit set in the AFLOG_MAX_FILE_SIZE profile option, then the diagnostic.log file is renamed to diagnostic-9.log.
When the number of log files reaches the value specified using the AFLOG_NUMBER_OF_LOG_FILES profile option, then older log files are deleted automatically, to prevent the disk space usage of the log file directory from growing too large.
Over time, the value of n in diagnostic-n.log or AFLOG_PLSQL_FILENAME_value-n.log can grow large enough to cause usability challenges or exceed the number of characters that the operating system allows in a file name. If you want to have the value of n start over at 1, you can move all existing log files except the currently active diagnostic.log file or AFLOG_PLSQL_FILENAME_value.log file into another directory. When the active file surpasses the size limit and the log rotation code finds no previously renamed log files in the directory, the active file is renamed using a value of 1 for n.
Note:
If your Oracle Fusion Applications environment includes multiple database nodes such as RAC systems, each database node corresponds to a server instance that has its own location for log files.If an incident is created, the server instance that creates the incident handles all subsequent jobs related to that incident. Identifiers for incidents are unique within a specific instance, but not across instances. For more information about working with incidents, see Chapter 17.
Oracle Fusion Applications modules that are implemented in C currently produce log files that continually increase in size.
To manage log file space usage for log files created by Oracle Fusion Applications modules that are written in C:
Navigate to the directory that contains the log files:
If the AFLOG_FILENAME profile option is set, navigate to the location designated by the profile option value.
If the AFLOG_FILENAME profile option is not set, navigate to the location set by Oracle Enterprise Scheduler Service.
You can use Fusion Applications Control to determine the location of Oracle Enterprise Scheduler log files, as follows:
In the navigation pane, expand the Farm listing, then expand the Scheduling Services listing, and then select an Oracle Enterprise Scheduler server as your target.
In the context pane, from the Scheduling Service dropdown menu, choose Logs > View Log Messages.
Click Target Log Files to view a list of log files associated with the selected server.
For example, a typical path and file name might be the following, where DOMAIN_HOME is the domain home directory, SERVER_HOME is the server home directory, and serverName is the name of the Oracle Enterprise Scheduler server:
DOMAIN_HOME/servers/SERVER_HOME/logs/serverName-diagnostic.log
Rename the log file that is currently in use.
For example, if the current log file is called Cdiagnostic.log, you might rename it to Cdiagnostic_MMDDYYYY.log, where MMDDYYYY is the current date.
Delete any previously renamed log files that you no longer need.
Oracle Fusion applications that use standard logging functionality use profile option values to configure how much information to log. Ordinarily, these profile options are set at the Site level, but some can also be set at the User level, to gather more information into the log file for a particular user.
Note:
For information about configuring Oracle Fusion Middleware log settings, including settings for Oracle Enterprise Scheduler and Oracle Enterprise Crawl and Search Framework, see "Configuring Settings for Log Files" in the Oracle Fusion Middleware Administrator's Guide. For information about configuring profile option values for incident and QuickTrace settings, see Section 17.2.You can use either Fusion Applications Control or the Setup and Maintenance work area to configure profile options for standard Oracle Fusion Applications logging functionality. For information about how to use the Setup and Maintenance work area for this purpose, see the chapter on maintaining common reference objects in the Oracle Fusion Applications Common Implementation Guide.
Note:
In order to set logging profile option values that affect other users, you must log in as a user who has the Manage All Application Profile Values function security privilege. By default, this privilege is carried by the Applications Common Application Profile Value Administration Duty role, which the predefined Application Administrator job role inherits. You can use Oracle Identity Manager to determine whether you have the Application Administrator job role.If you want to change profile option values for others without being provisioned with the Application Administrator job role or the Applications Common Application Profile Value Administration Duty role, you can use Oracle Authorization Policy Manager to determine which other duty roles have the Manage All Application Profile Values function security privilege and which job roles inherit those duty roles. You can use Oracle Identity Manager to make sure that you have a job role that inherits one of those duty roles.
For more information about working with roles and privileges, see the Oracle Fusion Applications Security Guide, the Oracle Fusion Middleware User's Guide for Oracle Identity Manager, and the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).
To use Fusion Applications Control to configure profile options for standard Oracle Fusion Applications logging functionality:
From the navigation pane, select one of the following target types:
A product family target that lets you configure the log profile options for all of the Oracle Fusion applications in the selected product family. For example, you could select the Financials product family target.
An Oracle Fusion Applications cluster application target that lets you configure the log profile options for the selected application on all of the servers in the selected cluster. For example, you could expand the Financials listing and the Fusion Applications listing and then select the PayablesApp cluster application target.
An Oracle Fusion application instance target that lets you configure the log profile options for the selected application on the selected sever. For example, you could expand the Financials listing and the Fusion Applications listing and the PayablesApp listing and then select the PayablesApp (PayablesServer_1) application instance target.
In the context pane, from the target type dropdown menu, choose Logs > Log Configuration.
In the Logging Profile Configuration dialog box, click one of the following tabs to determine whether you set the logging level for the whole site or for a single user:
Site-Level
User-Level
If you clicked Site-Level, skip to Step 5.
If you clicked User-Level, complete the following substeps:
Inspect the table on the User-Level tab for the user name for which you want to change logging levels.
If the user name is listed, select it and click Edit to display the Edit User-Level Configuration dialog box.
If the user name is not listed, click Add and enter it in the Name field of the Add Logging Profile Configuration dialog box.
From the Log Level dropdown list, select the log level that corresponds to the kinds of information you want to gather.
For more information, see Table 13-2.
In the Enabled field, make sure that the checkbox is selected.
In the Module Filters field, indicate if you want Oracle Fusion Applications to log only for a particular code module for the selected user—by default, log entries are written for all Oracle Fusion Applications code modules that use standard logging implementation for Oracle Fusion Applications.
Note:
If you specify that logging for the selected user should be done only for a particular code module, that setting will not affect the information that is logged for other users.If you want to change whether PL/SQL modules buffer log entries of levels lower than Warning, select Enabled or Disabled for the Buffer Mode setting.
If Buffer Mode is set to Enabled and you want to change the number of PL/SQL log records that will be buffered in memory before they are written to the log file, enter the number of records to buffer in the Buffer Size field.
If you want PL/SQL log records to be written to a log file location other than the default, enter the path and file name in the File Name field in the PL/SQL Settings section.
If you want C log records to be written to a log file location other than the default, enter the path and file name in the File Name field in the C Settings section.
Click OK.
Skip Step 5.
If you clicked Site-Level, complete the following substeps:
From the Log Level dropdown list, select the log level that corresponds to the kinds of information you want to gather.
For more information, see Table 13-2.
Make sure that Logging Enabled is selected.
In the Module Filters field, indicate if you want Oracle Fusion Applications to log only for a particular code module—by default, log entries are written for all Oracle Fusion Applications code modules that use standard logging implementation for Oracle Fusion Applications.
If you want to change whether PL/SQL modules buffer log entries of levels lower than Warning, select Enabled or Disabled for the Buffer Mode setting.
If Buffer Mode is set to Enabled and you want to change the number of PL/SQL log records that will be buffered in memory before they are written to the log file, enter the number of records to buffer in the Buffer Size field.
If you want PL/SQL log records to be written to a log file location other than the default, enter the path and file name in the File Name field in the PL/SQL Settings section.
If you want C log records to be written to a log file location other than the default, enter the path and file name in the File Name field in the C Settings section.
Click Apply.
Some functionality areas in Oracle Fusion Applications use nonstandard logging mechanisms that are disabled by default. For these areas, you must turn on the logging facility when you need it and specify the kind of information that you want to record in the log file. Some other functionality areas use nonstandard logging mechanisms that are usually set to gather minimal amounts of information. You may want to change those settings when troubleshooting.
This section contains the following topics:
Configuring Additional Log Settings for Oracle Fusion Incentive Compensation Batch Jobs
Configuring Additional Log Settings for Oracle Fusion General Ledger
Configuring Additional Log Settings for Oracle Fusion Receivables AutoInvoice
The logging functionality for certain Oracle Fusion Incentive Compensation batch jobs is separate from the standard logging functionality for Oracle Fusion Applications. By default, the following kinds of Oracle Fusion Incentive Compensation batch jobs do not write log entries:
Calculation
Classification
Collection
Crediting
Rollup
For optimum performance and log file sizes, it is recommended that you use the logging functionality for these areas only when troubleshooting an existing problem. For more information, see Section 17.2.9.
In the Oracle Fusion Financials product family, some logging functionality for the Oracle Fusion General Ledger application is separate from the standard logging functionality for Oracle Fusion Applications. By default, the following kinds of Oracle Fusion General Ledger batch jobs do not write log entries:
OpenPeriod
Posting
Translation
Close Process - Create Income Statement Closing Journals
Close Process - Create Balance Sheet Closing Journals
For optimum performance and log file sizes, it is recommended that you use the logging functionality for these areas only when troubleshooting an existing problem. For more information, see Section 17.2.10.
In the Oracle Fusion Financials product family, logging functionality for the AutoInvoice portion of the Oracle Fusion Receivables application is separate from the standard logging functionality for Oracle Fusion Applications. The amount of information that is logged for AutoInvoice depends on the value of the Log File Message Level system option setting.
To set the amount of information that the Oracle Fusion Receivables application logs for the AutoInvoice functionality area:
In the Oracle Fusion Receivables application, choose Setup and Maintenance from the Navigator menu.
Complete the following substeps to navigate to the Edit System Options screen for the Manage Receivables System Options task.
Expand the Search: Tasks pane.
Enter Manage Receivables System Options in the Name field and click Search.
In the Manage Receivables System Options row of the Search Results table, click Go to Task.
In the Search area of the Manage Receivables System Options screen, select Business Unit from the drop-down list, enter the name of a business unit for which you want to set up the amount of AutoInvoice information to be logged, and then click Search.
Alternately, you can click Search without specifying a business unit name to display a list of the available business units.
In the Search Results table, click the name of the business unit for which you want to set up the amount of AutoInvoice information to be logged.
In the Edit System Options screen, scroll down to display the AutoInvoice area of the screen, and then set Log File Message Level to the value of 0, which is the recommended value for normal operations.
Note:
For optimum performance and log file sizes, it is recommended that you keep the Log File Message Level system option set to the lowest value that meets your everyday needs, and increase the value of the setting only when troubleshooting an existing problem. For more information about using this setting when troubleshooting, see Section 17.2.11.Click Save to put your changes into effect.
Repeat this entire procedure for each additional business unit for which you want to configure AutoInvoice system options.
For information about configuring the Maximum Memory in Bytes system option for AutoInvoice, see product-specific documentation in Oracle Fusion Applications Help.
By default, you can use Fusion Applications Control to view log file entries that are generated by Java code in Oracle Fusion applications. To make it possible to view log file entries that are generated by PL/SQL or C code, you must perform the following configuration steps.
To make PL/SQL and C log file entries visible in Fusion Applications Control:
Determine the locations of the PL/SQL and C log files written by your Oracle Fusion applications.
The values of the AFLOG_PLSQL_FILENAME and AFLOG_FILENAME profile options normally determine log file locations for PL/SQL and C log files, respectively. For more information about these profile options and the log file locations that are used when these profile options are not set, see Section 13.6.3 and Section 13.7.1.
Decide which Managed Server you want to use to view PL/SQL log files, C log files, or both, and make sure that the server has read access to all log file locations that you determined in Step 1.
It is recommended that you use an Oracle WebLogic Server that runs Oracle Enterprise Scheduler for this purpose.
Note:
If you want to use more than one Managed Server to view PL/SQL log files, C log files, or both, you can do so, provided that each such server has read access to the log files that you want to view through that server. However, it is not especially valuable to use multiple servers to view a particular log file, since each server is providing access to the same data.On a Managed Server that you picked in Step 2, navigate to the following location, where DOMAIN_HOME is the domain home for the Managed Server and server_name is the name of the Managed Server:
DOMAIN_HOME/config/fmwconfig/servers/server_name/diagnostics-registration
If this location does not currently exist, create it now.
In the diagnostics-registration subdirectory, for each log file that you determined in Step 1 and want to view using this server, use a text editor to create and save a file that contains the following lines, using any file name that has the format yourChosenFileName.xml:
<?xml version='1.0' encoding='UTF-8'?>
<logs xmlns='http://www.oracle.com/iAS/EMComponent/ojdl'>
<log path="path_to_log_file">
<logreader class="oracle.core.ojdl.reader.ODLLogReaderFactory">
</logreader>
</log>
</logs>
Substitute the full path and name of the log file for path_to_log_file, using the form of the path that is correct for the current server to use when accessing the file:
For a PL/SQL log, make sure that the value for path_to_log_file corresponds to the same location and file name as the value that you have set for the AFLOG_PLSQL_FILENAME profile option.
Note:
You must resolve and enter the full path to thepath_to_log_file location, explicitly, rather than entering the directory object that is used to set the value of the AFLOG_PLSQL_FILENAME profile option.For a C log, make sure that the value for path_to_log_file indicates the same location and file name as the value that you have set for the AFLOG_FILENAME profile option.
Repeat this step as needed to create an individual .xml file for each log file that you determined in Step 1 and want to view using this server. You can save each file using any unique legal file name that ends in .xml. For example, the file name might be plsqlfndlog.xml for a PL/SQL log, and cfndlog.xml for a C log.
In Fusion Applications Control, verify that each log file from Step 1 is now listed in an appropriate Target Log Files list:
From the navigation pane, select a target for which you created a .xml file.
For example, you might expand the Financials product family entry, and then expand the Fusion Applications and PayablesApp entries, and then select the PayablesApp (PayablesServer_1) application instance target.
In the context pane, from the dynamic target menu, choose Logs > View Log Messages to display the log messages for the selected target.
Click Target Log Files.
Verify that the resulting list includes the all of the log files that are applicable for the selected target, including any applicable log files for which you created .xml files.
The View Log Message page includes information from all log files that appear on this list.
Repeat Step 5 for any other targets for which you created a .xml file.
Under ordinary circumstances, the following administrative tasks are associated with Oracle Fusion Applications diagnostic tests:
Configuring security to provide appropriate access to diagnostic tests. You can assign job roles to particular users to grant those users the ability to perform various diagnostic operations. For more information, see Section 13.9.1.
Caution:
In the current release, a job role for diagnostic operations grants the user the ability to perform the specified operations for all diagnostic tests that are provided with Oracle Fusion Applications. When choosing whether to grant a diagnostic job role to specific users, be aware that some diagnostic tests may include sensitive information in their results.Running diagnostic tests. You can use diagnostic tests for the following purposes:
Routinely checking the health of your Oracle Fusion applications
Troubleshooting a problem with an Oracle Fusion application
Collecting detailed data that may help Oracle Support to resolve a problem for you
Some diagnostic tests require a specific Oracle Fusion application to be running while the test is performed—these diagnostic tests are called internal diagnostic tests. Other diagnostic tests can perform their functions even if the Oracle Fusion application to be tested is not running—these tests are called external diagnostic tests.
The distinction between internal and external tests is important because it affects both when you can run the tests and which interfaces you can use to run the tests. The Diagnostic Testing Framework provides two interfaces:
The Diagnostic Dashboard application provides a graphical user interface that lets you perform the following tasks:
Execute and monitor both internal and external diagnostic tests for Oracle Fusion applications
Purge diagnostic test results
Register any special-purpose diagnostic tests that Oracle Support may provide to you
The diagctl command line interface lets you perform the following tasks:
Execute external diagnostic tests (tests that do not require a specific Oracle Fusion application to be running)
Note:
Technical constraints prevent thediagctl command line interface from returning useful results for internal diagnostic tests (tests that require a specific Oracle Fusion application to be running when the test is performed). You must use the Diagnostic Dashboard to run any internal diagnostic test.
You must also use the Diagnostic Dashboard to determine whether a particular test is an internal or an external test. For more information about making this determination, see Step 9 through Step 11 in Section 13.10.1.1.
View diagnostic test results
Register any special-purpose diagnostic tests that Oracle Support may provide to you
You can use diagnostic tests to check normal system health and to troubleshoot system problems. You can configure your Oracle Fusion Applications environment to run all Oracle Fusion Applications diagnostic tests using the Diagnostic Dashboard application, and to run external diagnostic tests using the diagctl command line interface.
This section contains the following topics:
Note:
Technical constraints prevent thediagctl command line interface from returning useful results for internal diagnostic tests (tests that require a specific Oracle Fusion application to be running when the test is performed). You must use the Diagnostic Dashboard to run any internal diagnostic test.
You must also use the Diagnostic Dashboard to determine whether a particular test is an internal or an external test. For more information about making this determination, see Step 9 through Step 11 in Section 13.10.1.1.
Both the Diagnostic Dashboard application and the diagctl command line interface are automatically installed and configured as part of the Oracle Fusion Applications installation. However, you must assign appropriate job roles to specific users to give them the ability to display and perform operations using the Diagnostic Dashboard application. Access to the diagctl command line interface is controlled at the level of the server operating system. For more information about granting appropriate access, see Section 13.9.1.
To help you locate diagnostic tests for specific purposes, the diagnostic tests that you receive with Oracle Fusion applications are all assigned to predefined categories.
Note:
You cannot change the tag name and tag value assignments that Oracle uses to categorize diagnostic tests, and you cannot remove those tag names or tag values from the database. The following related links in the Task pane of the Diagnostic Dashboard application are intended for use by Oracle personnel, only:Add New Tag
Add New Tag Value
Assign Tags to Tests
Unassign Tags from Tests
Remove Tag
Remove Tag Value
Caution:
Do not attempt to modify the diagnostic test seed data provided to you by Oracle. Unauthorized modification of this seed data may prevent diagnostic tests from functioning correctly, lengthening the amount of time required to resolve both current and future problems.Access to diagnostic testing functionality is controlled separately for the Diagnostic Dashboard and the diagctl command line interface.
For the diagctl command line interface, access is controlled at the level of the server operating system. If a user can log in to the server where diagctl is stored, and if that user has operating system permissions to read and execute diagctl, then that user can use diagctl to perform all diagnostic operations that the command line interface supports.
For the Diagnostic Dashboard, you can use Oracle Identity Manager to assign specific users to any of the four preconfigured job roles that grant users access to the Diagnostic Dashboard. Each of these four job roles provides access to a different amount of the functionality of the dashboard.
Note:
Oracle Fusion applications display the Troubleshooting > Run Diagnostic Tests command in the Help menu only for users who are associated with the preconfigured job roles that grant access to Diagnostic Dashboard operations.The Diagnostic Viewer job role can view and analyze diagnostic test results for Oracle Fusion applications.
The Diagnostic Regular User job role can execute diagnostic test runs and view diagnostic test results for Oracle Fusion applications, and cancel diagnostic test runs that were started by the current user.
The Diagnostic Advanced User job role can schedule and execute diagnostic test runs, view diagnostic test results, attach test results to application incidents for Oracle Fusion applications, and cancel diagnostic test runs that were started by the current user. In general, this job role is recommended for running Oracle Fusion Applications diagnostic tests, since its added capabilities allow users to work with administrators more flexibly during troubleshooting.
The Diagnostic Administrator job role can use all diagnostic testing functionality provided for Oracle Fusion applications, including purging test results from the database and canceling test runs started by other users.
Caution:
In the current release, any job role for diagnostic operations grants the user the ability to perform the role's specified operations for all diagnostic tests that are provided with Oracle Fusion applications. When choosing whether to grant any diagnostic job role to specific users, be aware that some diagnostic tests may include sensitive information in their results.To grant specific users permission to use the Diagnostic Dashboard:
The Diagnostic Dashboard application for Oracle Fusion Applications provides a graphical user interface that lets you execute and monitor diagnostic tests, display and purge test results, and register any special-purpose diagnostic tests that Oracle Support may provide to you. Each product family within Oracle Fusion Applications has its own instance of the Diagnostic Dashboard. Provided that you are assigned to an appropriate job role, you can navigate to the Diagnostic Dashboard from any Oracle Fusion application, or from Cloud Control.
If you want to use the Diagnostic Dashboard to execute or monitor diagnostic tests or display or purge test results while you are using an Oracle Fusion application, you can navigate to the Diagnostic Dashboard directly from the application.
To display to the Diagnostic Dashboard from an Oracle Fusion application:
Sign in to the relevant Oracle Fusion application as a user who has access to the specific Diagnostic Dashboard operations that you need.
For more information about the job roles that grant access to Diagnostic Dashboard operations, see Section 13.9.1.
From the Help menu in the application, choose Troubleshooting > Run Diagnostic Tests to display the Diagnostic Dashboard.
Note:
Oracle Fusion applications display the Troubleshooting > Run Diagnostic Tests command in the Help menu only for users who are assigned to the preconfigured jobs roles that grant access to Diagnostic Dashboard operations. For more information about these job roles, see Section 13.9.1If you want to use the Diagnostic Dashboard to execute or monitor diagnostic tests or display or purge test results while you are using Cloud Control, such as while you are using Support Workbench to gather additional information about an existing incident, you can navigate to the Diagnostic Dashboard directly from Cloud Control.
To display to the Diagnostic Dashboard from Cloud Control:
In Oracle Enterprise Manager, select the product family or cluster application for which you want to run diagnostic tests or view diagnostic test results.
From the dynamic drop-down menu, choose Diagnostics > Fusion Applications Diagnostic Dashboard.
A login screen for the Diagnostic Dashboard appears in a new window.
Log in using an account for the Oracle Fusion Applications product family that you intend to test.
The account that you use must also be assigned to a job role that provides access to the Diagnostic Dashboard. For more information, see Section 13.9.1.
Oracle Fusion Applications diagnostic tests are designed to help you to monitor the health of your system and to help you troubleshoot when necessary.
This section contains the following topics:
Searching for Diagnostic Tests by Name or by Categorization Tag
Identifying Diagnostic Test Launch Methods from Test Run Names
Note:
The user name that you use to sign in to an Oracle Fusion application affects which diagnostic operations are available to you. Be sure that you sign in using an account that has a job role for the diagnostic operations that you need. For more information, see Section 13.9.1.Some diagnostic tests can be used with all Oracle Fusion applications. Other tests apply to specific product families within Oracle Fusion Applications. For information about the individual diagnostic tests that are provided with this release, see the Oracle Fusion Applications Common User Guide in Oracle Fusion Applications Help.
You can use either the Diagnostic Dashboard or the diagctl command line interface to run external diagnostic tests—tests that do not depend on the availability of any specific Oracle Fusion application. However, for technical reasons, you must use the Diagnostic Dashboard to run internal diagnostic tests—tests that require a specific Oracle Fusion application to be running at the time when the test is run. For information about determining whether a particular test is an internal or an external test, see Step 9 through Step 11 in Section 13.10.1.1.
This section contains the following topics:
The Diagnostic Dashboard application provides a graphical user interface that lets you execute and monitor diagnostic tests, display and purge test results, and register any special-purpose diagnostic tests that Oracle Support may provide to you.
To run a diagnostic test from the Diagnostic Dashboard:
Navigate to the Diagnostic Dashboard for the Oracle Fusion applications you are administering, and log in using an account for the application you intend to test that has one of the following job roles:
Diagnostic Regular User
Diagnostic Advanced User
Diagnostic Administrator
For more information about these job roles, see Section 13.9.1. For more information about navigating to the Diagnostic Dashboard, see Section 13.9.2.
In the Regional area on the left side of the Diagnostic Dashboard, locate, and, if necessary, expand one of the following panels:
Search by Tests
Search by Tags
In the search panel, use standard Oracle query techniques to specify the test characteristics that you want to search for, and then click Search.
The results of the search appear in a table below the Search button.
Note:
In the current release, you can search for and display information about all diagnostic tests that are associated with a tag name that you specify. You cannot currently limit those searches to particular pairs of tag names and tag values. If you need to locate diagnostic tests that are associated with a particular tag name and tag value, you must search for the tag name and then scan the results for the tag value you require.In the search results table, select the checkbox for each test that you want to run, then click Add To Run.
The Choose Tests to Run and Supply Inputs table appears in the upper Local area of the screen, listing characteristics of the tests you selected.
From the View menu, use standard techniques to adjust how the table displays its data.
If you want to display nested tests and test steps, you can also expand the tree structure in the Choose Tests to Run and Supply Inputs table.
In the Choose Tests to Run and Supply Inputs table, inspect the Input Status column and perform the appropriate action for the value you find:
For any root level test that displays the message Required Input Values Missing, either clear the checkbox to omit that test (and its nested tests and test steps) from the test run, or click the alert icon in the Input Status column to display the Input Parameters dialog box.
For any root level test that displays the message Required Input Values Validated, consider whether you want to inspect the parameter values the test is currently set to use. If so, or if you know that you want to change an existing input parameter value, click the check mark icon in the Input Status column to display the Input Parameters dialog box.
Note:
You can use the Input Parameters dialog box to override current input parameter values, including in tests that have a valid input status.For any root level test that displays the message No Input Specified, skip to Step 8. A test that displays this message does not use input parameters.
If you clicked the alert icon in the Input Status column to display the Input Parameters dialog box, specify new parameter values as needed, according to the parameter type, as follows; otherwise, skip this step.
For Boolean parameters, select the appropriate button in the New Value field.
For numerical parameters and general text parameters, enter the appropriate value in the New Value field.
For date parameters, click the icon in the New Value field to display a calendar pop-up, and then select an appropriate year, month, and day.
For parameters that must be supplied from a list of values (LOV), click the magnifying glass icon in the New Value field to display the Search and Select dialog box. In the Search and Select dialog box, select the appropriate value for the parameter and click OK.
Note:
The values that are available in the list of values are determined in the metadata for the diagnostic test.If you want to save your current input values for convenient future use, click Save to display the Save As Input Set dialog box. Supply a name for the set of values that you are saving, plus any additional information about the input set that you want to store, and then click OK.
If you want to use a set of previously stored input values, select the appropriate set from the Input Set dropdown list, and click Load.
If you want to revert to the default values for all parameters in the current test, click Defaults. The Diagnostic Test Framework removes all values for text parameters and resets other parameter types to default values.
When you are finished setting input parameters for the current test, click OK.
Repeat Step 6 through Step 7 for any other tests that are missing input values, or that have parameter values that you want to override in your test run.
From the View menu for the Choose Tests to Run and Supply Inputs table, choose Availability to display the Diagnostic Test Availability dialog box.
In the Select a Diagnostic Test for Details table, select each test listing and inspect the icon displayed in its Availability column:
If the Availability column shows a check mark icon, then the selected test is currently available to be run.
If the Availability column shows a triangular warning icon, or if you want to determine whether the test is internal or external, click Detach in the Available Details table header to display the Available Details table in a larger window, and then proceed to Step 11.
If all listed tests are available to be run and if you do not need to know whether they are internal or external, skip to Step 13.
Inspect the expanded Detached Table for messages about whether the selected test depends on particular Oracle Fusion applications or about why the test is not available, and take the appropriate action:
If you want to know whether the selected test is internal or external, inspect the Details of Required Test Components column of the Web Applications Accessible row.
If that cell of the Detached Table contains the name of an Oracle Fusion application, then the test is an internal diagnostic test that you can run only by using the Diagnostic Dashboard when the specified application is available. You cannot run such a test by using the diagctl command line interface or when the application is not present.
If that cell of the Detached Table does not list an application, then the test is an external diagnostic test.
If the Error column says, "The following Java classes were not loadable:" This message indicates that the diagnostic testing framework cannot locate the JAR file that contains the selected test. Contact your help desk for assistance in searching for a solution in the My Oracle Support Knowledge Base. If the Knowledge Base does not yield a solution, ask your help desk to open an Oracle Support service request.
If the Error column says, "The following PL/SQL procedures were not located in the database:" This message indicates that the diagnostic testing framework cannot locate the test code for the selected PL/SQL diagnostic test in your database. Contact your help desk for assistance in searching for a solution in the My Oracle Support Knowledge Base. If the Knowledge Base does not yield a solution, ask your help desk to open an Oracle Support service request.
If the Error column says, "The following Web Applications were inaccessible:" Use the Oracle WebLogic Server console or Fusion Applications Control to check whether the listed applications are running correctly. This message indicates that the Diagnostic Testing Framework must have access to running instances of the listed Oracle Fusion applications in order to run the selected diagnostic test—the test is an internal test.
For more information about installing and deploying Oracle Fusion Applications, see the "Provisioning a New Applications Environment" chapter of the Oracle Fusion Applications Installation Guide.
If the problem persists when the listed Oracle Fusion applications and the relevant database instance are all running, contact Oracle Support for assistance.
If the Error column says, "The current user does not have execution privileges for the following tests:" You must log in as a user who has appropriate privileges to execute the selected test. For information about the privileges required, see Section 13.9.1.
If the Error column says, "The current user does not have privileges to view reports for the following tests:" You must log in as a user who has appropriate privileges to view the results of the selected test. For information about the privileges required, see Section 13.9.1.
Note:
It is possible to have the necessary privileges to view diagnostic test results without having the necessary privileges to run those tests. Use an appropriate user account for the action you want to perform.If you have not already done so, close the Detached Table window and the Diagnostic Test Availability dialog box, repeat Step 9 and Step 10 to verify that all listed tests are now available to be run, and then proceed to Step 13.
If you wish, enter a name for your test run in the Run Name field in the control bar.
Note:
Do not use the worderror in your test run name. If you use the word error, or if you leave the Run Name field blank, the Diagnostic Testing Framework automatically assigns the test run a name. For information about the formats used in automatically assigned test run names, see Section 13.10.10.When the Input Status column of the Choose Tests to Run and Supply Inputs table displays Required Input Values Validated in all of the selected rows, choose one of the following from the Run Options menu:
Run Now: Run the selected test or tests immediately after you click Run.
Run Later: Schedule when the test or tests will be run. This option is integrated with Oracle Enterprise Scheduler Service. When you select this option, the Run button on the toolbar changes to a Schedule Run button. Complete the following sub-steps to schedule when the test or tests will be run:
Click the Schedule Run button to display a Schedule Tests dialog.
Click the Schedule tab and then select Use a schedule.
From the Frequency dropdown list, select how often to run the selected test or tests.
In the Start field, specify the date and time to start the testing.
Click Submit.
Adjust option settings to determine whether or not to run the prerequisite tests for the diagnostic tests you have selected:
If you want to run prerequisite tests, make sure that the No Prerequisites option in the Run Options menu is not selected.
If you do not want to run prerequisite tests, make sure that the No Prerequisites option in the Run Options menu is selected.
Adjust option settings to determine how many threads to use when running the selected diagnostic tests:
To use multiple threads, choose Run in Parallel from the Run Options menu. Then choose Number of Threads from the Run Options menu and select a value from 2 through 5. The default number of threads for running in parallel is 3.
To use a single thread, choose Run Synchronously from the Run Options menu.
If you chose Run Now in Step 14, click Run to start executing the test run.
If you chose Run Later in Step 14, the test run will start executing at the time you set in the Schedule Tests dialog.
The Diagnostic Test Framework command line utility, diagctl, lets you specify which tests to run in several different ways: by test name, by associated product codes, by associated tag names and tag values, and by associated module IDs or module keys.
You can run one or more diagnostic tests using a single diagctl command. It is particularly appropriate to use diagctl when you do not have access to a WebLogic Server.
Note:
Technical constraints prevent thediagctl command line interface from returning useful results for internal diagnostic tests (tests that require a specific Oracle Fusion application to be running when the test is performed). You must use the Diagnostic Dashboard to run any internal diagnostic test.
You must also use the Diagnostic Dashboard to determine whether a particular test is an internal or an external test. For more information about making this determination, see Step 9 through Step 11 in Section 13.10.1.1.
To run Diagnostic Tests from the diagctl command line interface:
Obtain the user name and password for the Oracle Fusion Applications account that will run the diagnostic test or tests, and the password for that account.
A user name and password is required for any diagnostic test that you run using the diagctl command line interface. The command line syntax for specifying the user name and password is un=user_name and pwd=password.
Decide which of the following methods to use to specify the diagnostic test or tests that you want to run:
Specify a single test name: To run a single specific test without specifying input parameters, the command line syntax is test=test_name
Specify a test name and parameters: To run a single specific test with one or more input parameters, the command line syntax is test=test_name input:parameter_name1=parameter_value1 input:parameter_name2=parameter_value2
Specify multiple test names: To run several specific tests, the command line syntax is test=test_name1,test_name2,test_name3
Note:
If you are specifying multiple tests on a single command line, then you cannot specify input parameters on that command line.Specify by product codes: To run all of the tests that are associated with one or more specific product codes in the Applications taxonomy, the command line syntax is app=product_code1,product_code2,product_code3
Specify by module ID: To run all of the tests that are associated with specific module IDs in the Applications taxonomy, and all of the tests that are associated with child modules of the module that you specify, the command line syntax is modid=moduleID1,moduleID2,moduleID3
Specify by module key: To run all of the tests that are associated with specific module keys in the Applications taxonomy, the command line syntax is modkey=module_key1,module_key2,module_key3
Specify by tag name and tag value: To run all of the tests that are associated with a specific tag and tag value in the diagnostic test repository, and to run any tests that are associated with any child tag values of the tag name and tag value that you specify, the command line syntax is tag:tagname1=tagvalue1 tag:tagname2=tagvalue2 tag:tagname3=tagvalue3
You must use at least one these options in each command to run a diagnostic test from diagctl. You can include more than one of these options in a single command, if you prefer.
Decide whether to use any, some, or all of the following additional options for the test run:
Specify a test run name: To specify a particular name for the test run, use the command line syntax runname=run_name.
Note:
Do not include the word "error" in your test run name. If you include the word "error," or if you do not specify a test run name, the command line utility automatically generates a name for the test run. Automatically generated test run names start with the test name, product code, module ID, module key, or tag name and value that you specified, followed by a colon, a timestamp, another colon, and a sequence number.Specify whether to test recursively: To run all of the specified tests recursively, use the command line syntax recurse=Y. The default value is N.
Specify whether to run prerequisite tests: To identify and run any tests that are prerequisites before running the specified tests, use the command line syntax prereq=Y. The default value is N.
Specify monitoring interval: To specify how often the status of the test run is uploaded to the test repository, use the command line syntax moninterval=time_in_seconds. The default value is 30 seconds.
Specify number of threads: To specify the number of parallel threads to spawn for processing this test run, use the command line syntax nthreads=number_of_threads. The default value is 5. A value of 1 directs the utility to run the tests serially.
At a command prompt for your operating system, navigate to the location of the diagctl executable under the fusionapps Oracle Fusion Middleware home directory:
(UNIX) MW_HOME/atgpf/bin/diagctl.sh (Windows) MW_HOME\atgpf\bin\diagctl.cmd
Enter diagctl.sh run (for UNIX) or diagctl run (for Windows) followed by the user name and password from Step 1 and the options that you decided upon in Step 2 and Step 3, using the syntax described in those steps.
Note:
You can list command arguments that appear after the wordrun in any order. If you do not specify the password on the command line, the utility will prompt you to supply it. For detailed help about running diagnostic tests, enter diagctl.sh run help (for UNIX) or diagctl run help (for Windows)For example, to run a single test with two input parameter values specified, you would enter a command such as the following:
(UNIX) diagctl.sh run test=oracle.apps.fnd.appltest.sampleTest input:param1=value1 input:param2=value2 un=sysadmin (WINDOWS) diagctl run test=oracle.apps.fnd.appltest.sampleTest input:param1=value1 input:param2=value2 un=sysadmin
Note:
If you specify an invalid parameter value, the command line interface returns an error message and does not run the test.Or, to run all tests that belong to the Application Object Library (FND) and General Ledger products, and to run them recursively and with prerequisite analysis you would enter a command such as:
(UNIX) diagctl.sh run app=FND,GL recurse=Y prereq=Y un=sysadmin (WINDOWS) diagctl run app=FND,GL recurse=Y prereq=Y un=sysadmin
Or, to run all tests that are associated with the given module id, you would enter:
(UNIX) diagctl.sh run modid=module1,module2 un=sysadmin (WINDOWS) diagctl run modid=module1,module2 un=sysadmin
You can search for diagnostic tests either by specifying part of the name of the test or by specifying a categorization tag that is associated with the test.
In general, searching for diagnostic tests is done as a portion of the process of running diagnostic tests. For more information, see Section 13.10.1.
Whether or not you can run a diagnostic test at any given time depends on both the specific requirements of the test and the current state of your Oracle Fusion Applications system. Any of the following factors can prevent a test from being available:
Java class availability
PL/SQL procedure availability
Oracle Fusion Applications accessibility
Execution privileges for the test
Report viewing privileges for the test
In general, checking the availability of diagnostic tests is done as a portion of the process of running diagnostic tests. For more information, see Section 13.10.1.
Note:
Some diagnostic tests require a specific Oracle Fusion application to be running while the test is performed—these diagnostic tests are called internal diagnostic tests. Other diagnostic tests can perform their functions even if the Oracle Fusion application to be tested is not running—these tests are called external diagnostic tests.Diagnostic tests often have input parameters. Oracle supplies default values for some input parameters. When you are in the process of preparing to run one or more diagnostic tests, you can change the values for input parameters that have default values and enter values for input parameters that do not have default values. If you know that you will use the same parameter values more than once, you can save those values into an input set that you can reuse for later test runs.
All required input parameters must have values assigned before you can run a diagnostic test. If there are required parameter values missing, the Diagnostic Dashboard application displays Required Input Values Missing in the Input Status column of the Choose Tests to Run and Supply Inputs table.
To specify input parameter values, click the icon in the Input Status column to display the Input Parameters dialog box. Then you can either enter parameter values individually in the New Value column of the Edit Input Set table, or you can select a previously saved set of values from the Input Set dropdown list. For more information, see Section 13.10.1.
You can use either the Diagnostic Dashboard or the diagctl command line interface to run diagnostic tests immediately.
In the Diagnostic Dashboard, you specify that you want to run a diagnostic test immediately by choosing Run Now from the Run Options menu.
For the diagctl command line interface, you specify that you want to run a diagnostic test immediately by entering the command to run the test from an interactive session prompt.
For more information, see Section 13.10.1.
In the Diagnostic Dashboard, you can specify a particular time to run diagnostic tests by choosing Run Later from the Run Options menu. For more information, see Section 13.10.1.1.
To run a delayed diagnostic test using the diagctl command line interface, create a script that calls diagctl.sh (for UNIX) or diagctl.cmd (for Windows) and then use standard Oracle Enterprise Scheduler techniques to schedule when the script runs. For information about submitting and monitoring Oracle Enterprise Scheduler jobs, see Chapter 5.
You can check the status of a diagnostic test from the Diagnostic Dashboard or from the diagctl command line interface. The command line interface is primarily intended for use if the Diagnostic Dashboard is temporarily unavailable.
This section contains the following topics:
Using the Diagnostic Dashboard to Check the Status of a Diagnostic Test
Using the diagctl Command Line Interface to Check the Status of a Diagnostic Test
In the Diagnostic Dashboard, the Diagnostic Test Run Status table displays two types of status information:
Execution Status: This column displays status information about whether or not a test run request can be executed successfully.
Diagnostic Status: This column displays status information about whether or not individual diagnostic tests detect problems.
Note:
After running a diagnostic test using the Diagnostic Dashboard, you may need to click Refresh to display the latest status information, including rows for the following kinds of test runs:Test runs that were run immediately from the Diagnostic Dashboard
Test runs that were scheduled to be run later from the Diagnostic Dashboard
Test runs that were submitted using the diagctl command line interface.
When you click Refresh, the Diagnostic Dashboard displays listings for any additional test runs that you or other users have submitted in your current Oracle WebLogic Server domain. If your Oracle Fusion Applications deployment uses Global Single Instance (GSI), the Diagnostic Dashboard also displays listings for test runs that were submitted in other domains.
To check the status of a diagnostic test using the Diagnostic Dashboard:
If you started the diagnostic test from your current Diagnostic Dashboard application session, the Diagnostic Test Run Status table automatically displays in the lower right portion of the screen after you click Run. Skip to Step 4.
If you are not already displaying the Diagnostic Dashboard for the Oracle Fusion applications you are administering, navigate to the dashboard and log in using an account for the application you are testing. For more information, see Section 13.9.2.
In the Regional area of your screen, expand the Tasks panel and click Run Status.
If you want the Diagnostic Test Run Status table to display only certain types of rows, select one of the following options from the Find dropdown list:
All Runs Submitted in Last Hour
All Runs Submitted in Last 24 Hours
All Running
All Running Submitted in Last Hour
All Runs with Diagnostic Failures in Last 24 Hours
All Runs with Diagnostic Failures
All Runs with Diagnostic Warnings
All Runs with Execution Errors
All Completed
All Completed with No Issues
All Runs
All Runs Run By the Current User in the Last Hour
All Runs Run By the Current User
If you want to search for specific rows in the Diagnostic Test Run Status table, click the Search Test Runs icon, enter search criteria, and click OK.
Available search criteria include:
Test run dates
Test run names
Test display names
User names of those who launched test runs
Execution status
If you want to display additional columns in the Diagnostic Test Run Status table, choose the additional columns from the View menu.
Expand test run nodes as needed to view the list of test executions for each test, and then inspect the Execution Status column for information about whether tests and test runs have completed or encountered execution errors.
Inspect the Diagnostic Status column for information about whether completed tests and test runs encountered any issues before completing.
For additional information about any test execution, click the icon in the Report column of the appropriate row of the table.
The Diagnostic Test Framework command line utility, diagctl, provides three different ways that you can specify the diagnostic test for which you want status information: by test run name, by test run ID, and by test execution ID.
To check the status of a diagnostic test using the diagctl command line interface:
Obtain the user name and password for the Oracle Fusion Applications account that will run the diagnostic test or tests, and the password for that account.
A user name and password is required whenever you use the diagctl command line interface to check the status of a diagnostic test. The command line syntax for specifying the user name and password is un=user_name and pwd=password.
Decide which of the following methods to use to specify the diagnostic test run for which you want status information:
Specify a test run name: To check the status of a diagnostic test run for which you have the run name, the command line syntax is runName=run_name.
Specify a test run ID: To check the status of a diagnostic test for which you have the test run ID, the command line syntax is runid=run_ID.
Specify a test execution ID: To check the status of a diagnostic test for which you have the execution ID, the command line syntax is execid=execution_ID.
You must use at least one these options in each command to check the status of a diagnostic test using diagctl.
Decide whether you want view the status of nested test runs.
To check the status of all diagnostic tests that are nested within the specified test, the command line syntax is printtree=Y. This setting defaults to a value of N, meaning that the status is reported only for the specified test.
At a command prompt for your operating system, navigate to the location of the diagctl executable under the fusionapps Oracle Fusion Middleware home directory:
(UNIX) MW_HOME/atgpf/bin/diagctl.sh (Windows) MW_HOME\atgpf\bin\diagctl.cmd
Enter diagctl.sh status (for UNIX) or diagctl status (for Windows) followed by the user name and password from Step 1 and the options that you decided upon in Step 2 and Step 3, using the syntax described in those steps.
Note:
You can list command arguments that appear after the wordstatus in any order. If you do not specify the password as part of the command, the utility will prompt you to supply it. For detailed help about getting status information, enter diagctl.sh status help (for UNIX) or diagctl status help (for Windows).For example, to check the status of a test by using a test run name, you would enter a command such as:
(UNIX) diagctl.sh status runName=TrialRun1 un=sysadmin (Windows) diagctl status runName=TrialRun1 un=sysadmin
Or, to check the status of a test and its nested test runs by using a run ID, you would enter a command such as:
(UNIX) diagctl.sh status runid=RunID1 printtree=Y un=sysadmin (Windows) diagctl status runid=RunID1 printtree=Y un=sysadmin
Or, to check the status of a test by using an execution key, you would enter:
(UNIX) diagctl.sh status execid=TestExecID1 un=sysadmin (Windows) diagctl status execid=TestExecID1 un=sysadmin
From time to time, you may want to stop a diagnostic test or test run that is currently running. Several constraints affect your ability to cancel a diagnostic test or test run:
In the current release, you must use the Diagnostic Dashboard to cancel a diagnostic test or test run that is currently running. The diagctl command line interface does not provide this capability.
To cancel a test or test run that you started, you must use an account that has been assigned the Diagnostic Regular User, Diagnostic Advanced User, or Diagnostic Administrator job role.
To cancel a test or test run that another user started, you must use an account that has been assigned the Diagnostic Administrator job role.
When a diagnostic test is scheduled to run at a later time, it is immediately submitted to the Oracle Enterprise Scheduler Service. The procedure for canceling such a test depends on whether or not the test has already started to execute at the time when you want to cancel it:
To cancel a scheduled diagnostic test that has not yet started to execute, use standard Oracle Enterprise Scheduler techniques to cancel the job. For more information about cancelling scheduled jobs, see Section 5.7.5.
To cancel a scheduled diagnostic test that the Diagnostic Test Run Status dashboard panel indicates is already running, use the Diagnostic Dashboard to cancel it in the same way that you would cancel a test that ran immediately.
When you cancel a diagnostic test or test run, the consequences may vary slightly depending on how much of the test run has executed and the language in which the test code is written:
If you cancel a diagnostic test run while a test step from that test run is in progress, the test step that is currently running is canceled. No additional tests or test steps in the remainder of the cancelled test run are executed. The Diagnostic Test Run Status panel displays an Execution Status of Canceled for the run, and a pop-up window displays a message such as the following, but no log messages are recorded to indicate that a diagnostic test run has been canceled:
Test Run "test_name" has been canceled. Please check the test run report for further details.
When you cancel a diagnostic test step that has been implemented in Java, the diagnostic framework automatically closes the test step's database connection, using an asynchronous command to kill the thread. However, when you cancel a diagnostic test step that has been implemented using PL/SQL, the diagnostic framework cannot interrupt the test step and use the existing database connection to close that connection. To reclaim the resources allocated to a canceled PL/SQL diagnostic test step, you must establish a separate connection to the database and use an alter system kill session command to close the connection that the canceled test step was using, as described later in this section.
To cancel a diagnostic test using the Diagnostic Dashboard:
If you started the diagnostic test from your current Diagnostic Dashboard application session, the Diagnostic Test Run Status table automatically displays in the lower right portion of the screen after you click Run. Skip to Step 4.
If you are not already displaying the Diagnostic Dashboard for the Oracle Fusion applications you are administering, navigate to the dashboard and log in using an account for the application you are testing. For more information, see Section 13.9.2.
In the Regional area of your screen, expand the Tasks panel and click Run Status.
In the Diagnostic Test Run Status panel, locate and select the test run that you want to cancel, verify that its Execution Status is Running, and then click Cancel.
In the Diagnostic Test Run Status panel, click the Report icon for the canceled test run.
Inspect the test run report to determine whether the canceled test step was implemented using Java or PL/SQL.
If the canceled test step was implemented using Java, skip all of the remaining steps in this procedure.
If the canceled test step was implemented using PL/SQL, proceed to Step 7.
If the canceled test step was implemented using PL/SQL, make a note of the session ID and serial number for the database connection that the step was using.
For example, the report might display information similar to the following:
Step Report - Diagnostics_Engine_Log Session Information The test test_name is using a database connection with Session Id 944 and Serial Number 817
Using your preferred database client or database monitoring application and a separate connection to the database, determine whether the database connection for the canceled test step is still open.
For example, you could use a SQL client to execute the following query, substituting the session identifier and serial number values that you obtained in Step 7 for session_Id and serial_number:
select * from v$session where sid = session_Id and serial# = serial_number
If this query returns a row that contains the session ID and serial number that you specified, then the database connection from the canceled test is still open and consuming resources. Proceed to Step 9,
If the query does not return a row that contains the session ID and serial number that you specified, then the database connection from the canceled test has been closed. In this case, skip Step 9.
If the database connection for the cancelled test step is still open, use a command such as the following to close that connection, substituting the correct session identifier and serial number values for session_Id and serial_number.
alter system kill session 'session_Id, serial_number';
You can use either the Diagnostic Dashboard or the diagctl command line interface to view reports that show the results of diagnostic tests, whichever you prefer.
This section contains the following topics:
Using the Diagnostic Dashboard to View the Results of Diagnostic Tests
Using the diagctl Command Line Interface to View the Results of Diagnostic Tests
You can view the results of a diagnostic test in the dashboard by checking the status of the test and then clicking the icon in the Report column of the selected table row. For more information, see Section 13.10.7.1.
The diagctl command line utility provides three different ways of requesting the results of diagnostic test results: by test run name, by test run ID, and by test execution ID.
To view diagnostic test result reports using the diagctl command line interface:
Obtain the user name and password for the Oracle Fusion Applications account that you will use to view the test results, and the password for that account.
A user name and password is required whenever you use the diagctl command line interface to view the results of a diagnostic test. The command line syntax for specifying the user name and password is un=user_name and pwd=password.
Decide which of the following methods to use to specify the diagnostic test run for which you want to view results:
Specify a test run name: To view the results of a diagnostic test run for which you have the run name, the command line syntax is runName=run_name. This option includes results for all the executions in the test run.
Specify a test run ID: To view the results of a diagnostic test for which you have the test run ID, the command line syntax is runid=run_ID. This option includes results for all of the executions in the run.
Specify a test execution ID: To view the results of a diagnostic test for which you have the execution ID, the command line syntax is execid=execution_ID. This option includes results for the specified execution and any nested executions.
You must use at least one these options in each command to view the results of a diagnostic test using diagctl.
Decide whether you want to use one or more of the following additional options:
Specify a destination directory for results: To write the test results to a specific directory, the command line syntax is destdir=destination_directory. If you do not specify a directory, reports are placed in the java.io.tmpdir/user.name/diagfwk directory where java.io.tmpdir and user.name are Java system properties.
Specify a format for the result report: Valid values are XML and HTML. The default value is HTML. XML report files are created as a step toward creating HTML report files. These XML report files remain in the same directory as the HTML report files.
Specify if the report should be translated: Valid values are Y and N. If the value is Y, any NLS keys that are specified in the report are translated to your session language. If the value is N, no translation is performed. The default value is Y.
At a command prompt for your operating system, navigate to the location of the diagctl executable under the fusionapps Oracle Fusion Middleware home directory:
(UNIX) MW_HOME/atgpf/bin/diagctl.sh (Windows) MW_HOME\atgpf\bin\diagctl.cmd
Enter diagctl.sh report (for UNIX) or diagctl report (for Windows), followed by the user name and password from Step 1 and the options that you decided upon in Step 2 and Step 3, using the syntax described in those steps.
Note:
You can list command arguments that appear after the wordreport in any order. If you do not specify the password as part of the command, the utility will prompt you to supply it. For detailed help about viewing reports, enter diagctl.sh report help (for UNIX) or diagctl report help (for Windows).For example, to view the results of a test by using a run name, and to place the results in a particular directory, you would enter a command such as:
(UNIX) diagctl.sh report runName=TrialRun1 destdir=/d1/testreport un=sysadmin (Windows) diagctl report runName=TrialRun1 destdir=/d1/testreport un=sysadmin
Or, to view the results of a test run by using a run ID, with the results placed in the default location, you would enter a command such as:
(UNIX) diagctl.sh report runid=RunID1 un=sysadmin (Windows) diagctl report runid=RunID1 un=sysadmin
Or, to check the status of a test by using an execution key, with the results placed in the default location, you would enter:
(UNIX) diagctl.sh report execid=TestExecID1 un=sysadmin (Windows) diagctl report execid=TestExecID1 un=sysadmin
Navigate to the location of the results file, and use a browser or text editor of your choice to view it.
Any test run name that the Diagnostic Testing Framework supplies follows naming conventions that reflect how the test was launched, as follows:
When you submit a test run to run immediately, without specifying a run name, the name that is automatically assigned to the test run has the format TestRun_runID, where runID is a unique string of alphanumeric characters generated by the Diagnostic Testing Framework, such as TestRun_91D818BA54BB29C8E040578C495D6956. This naming convention applies both when tests are submitted from the Diagnostic Dashboard and when tests are submitted using diagctl.
When you schedule a diagnostic test run to run later, using Oracle Enterprise Scheduler Service, the name that is automatically assigned to the test run has the format [TestRunName_]ESS_requestID_timestamp, where TestRunName is an optional name that the you may specify when submitting the test, requestID is a unique identifier supplied by the Oracle Enterprise Scheduler when it schedules the job, and timestamp indicates the time when the job is scheduled to run. This naming convention applies to tests that are submitted from the Diagnostic Dashboard to run later. (Tests that are submitted using diagctl always run immediately.)
For example, if you enter a test run name of routine, the full test run name might be:
routine_ESS-417-2010-09-09T17:07:09.115-0700
When a test run is submitted automatically because an incident occurred, the name that is automatically assigned to the test run has the format AppsLogger-DiagnosticTestingFrameworkIntegration_id_timestamp, where id is a number that uniquely identifies the incident, and timestamp indicates when the diagnostic test run starts.
From time to time, you may want to remove diagnostic test run results from your database, to keep the Run Status table from becoming too large.
Note:
To remove the results of one or more diagnostic test runs from your database, you must use the Diagnostic Dashboard application with an account that has been assigned theDiagnostic Administrator job role.
The diagctl command line interface does not currently provide a way to purge test run results.
To purge selected diagnostic test run results from the database:
If you started the diagnostic test from your current application session, the Diagnostic Test Run Status table automatically displays in the lower right portion of the screen after you click Run. Skip to Step 4.
If you are not already displaying the Diagnostic Dashboard for the Oracle Fusion applications you are administering, navigate to the dashboard and log in using an account for the application that needs its test results purged. For more information see Section 13.9.2.
In the Regional area of your screen, expand the Tasks panel and click Run Status.
In the Diagnostic Test Run Status table header, use either of the following methods to locate the test run status records that represent the test results that you want to remove from the database:
Select any appropriate filter from the Find dropdown list.
Click the Search Test Runs icon, enter search criteria, and click OK.
After searching or filtering, inspect the listings displayed in the Diagnostic Test Run Status table, and decide whether you want to remove listed test results from the database individually or as a group:
To remove a single test run status result record from the database, complete the following substeps in the Diagnostic Test Run Status table:
Select the test run status record that represents the results that you want to remove from the database, and click the delete button in the Diagnostic Test Run Status table header.
In the Delete Test Run dialog box, select Delete test run "TestRunName" and click OK.
The selected record is removed from the database immediately.
To remove all of the listed test run status result records from the database, click the delete button in the Diagnostic Test Run Status table header.
Depending on whether or not you selected a record in the Diagnostic Test Run Status table, either the Delete Test Run dialog box or the Confirm Test Run Delete dialog box appears.
Complete the purge process using the appropriate instructions for the dialog box displayed on your screen:
If your screen displays the Delete Test Run dialog box, select Delete all test runs in the list and click OK to remove all of the listed test run results from the database immediately.
If your screen displays the Confirm Test Run Delete dialog box, click Yes to remove all of the listed test run results from the database immediately.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|