The following topics are discussed:
Work with Cloud Control Problem Analysis and the Analyze Logs Options
Work with Oracle Support for Assistance in Problem Resolution
For background information about Oracle Fusion Applications incidents, log files, log file entries, and the QuickTrace (in-memory logging) feature, see Overview of Oracle Fusion Applications Incidents and Log Files.
From time to time, a user complaint or an automatically generated incident notification about a problem with a particular Oracle Fusion application may be received. For any problem that does not have an immediate and obvious solution, it is possible to diagnose and resolve the problem most effectively by becoming familiar with incident functionality and by using a systematic process for troubleshooting.
While any problem may have unique features, the information gathered systematically is likely to be useful during the troubleshooting process.
The recommended process for troubleshooting Oracle Fusion Applications consists of the following high-level steps:
Note any error messages and consult product release notes for information about any known problems.
Check for automatically created incident and associated log file excerpts, dumps, and/or diagnostic test results.
If needed, manually create an incident and associate manually-collected log file excerpts, dumps, and/or diagnostic test results with that incident.
If needed, package all info associated with the incident and transmit it to Oracle Support.
The standard tools used to troubleshoot Oracle Fusion Applications problems include the following:
Support Workbench, particularly the Problem Analysis portion
Diagnostic Dashboard for Oracle Fusion Applications, plus diagnostic tests provided by Oracle
The Log Analysis portion of Oracle Enterprise Manager Cloud Control
The Incident Manager portion of Oracle Enterprise Manager Cloud Control
Fusion Applications Control user interface
Log Viewer - part of Application Server Control, for viewing log files that may be added to incidents
Automatic Diagnostic Repository Command Interpreter (ADRCI) utility - for viewing and packaging incidents, provided with each instance of the Automatic Diagnostic Repository (ADR) in Oracle Fusion Applications, Oracle Fusion Middleware, and Oracle Database
For more information about using ADRCI, see ADRCI: ADR Command Interpreter in the Oracle Database Utilities Guide.
Oracle WebLogic Scripting Tool (WLST) commands related to incidents provided by the Oracle Fusion Middleware Diagnostic Framework.
For more information about these commands, see the WLST Commands for Diagnostic Framework in Administering Oracle Fusion Middleware Guide.
SQL Trace - for assessing the efficiency of the SQL statements that Oracle Fusion applications are running
For more information about SQL Trace, see Use SQL Tracing.
The types of information used when troubleshooting an Oracle Fusion Applications problem may include any of the following:
Results of diagnostic tests: Diagnostic tests are executables 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 Oracle Fusion Applications Diagnostic Testing Framework allows the execution of 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.
Log file entries
Various kinds of dumps (including but not limited to QuickTrace dumps (in-memory logging) and several kinds of Oracle Fusion Middleware dumps)
Incidents are collections of information about problematic system events. 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 information collected by the Oracle Fusion Applications feature called QuickTrace (in-memory logging), or results of any diagnostic tests that the problem automatically triggered to run.
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, such as screen shots, the results of diagnostic tests, additional log file excerpts. It is also possible to add manually gathered information to incidents that were created automatically.
Incidents are helpful to organize and collect information needed for troubleshooting specific problems. On any occasions when assistance from Oracle Support is needed to resolve a problem, transmitting the relevant information to Oracle is simplified if that information is already associated with an incident.
Working with incidents is a key part of administering Oracle Fusion Applications. Oracle recommends following the 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.
The following tasks are part of administering incidents:
Adjusting configuration settings for incidents
Creating incidents manually (if a problem occurs without creating an incident manually)
Using incident information to diagnose and resolve the problems that are reported in incidents
Adding additional diagnostic information (such as additional log file excerpts or screen shots) to existing incidents
Packaging incident information and sending it to Oracle Support as part of obtaining assistance in resolving problems
In addition to the troubleshooting information provided in this guide, see the Oracle Support knowledge base and the Oracle Fusion Applications Release Notes for more information.
Incidents are collections of information about problematic system events. Use incidents to diagnose and resolve problems, or to supply the help desk personnel or Oracle Support personnel with information about more complex problems.
Oracle developers set up error messages in such a way that incidents are created automatically when certain high-priority error conditions occur. If a problem occurs for which no incident is created automatically, then it is strongly recommended to create an incident manually, and then use that incident to help organize the information gathered as the problem is resolved.
Automatically created incidents are more common than manually created incidents. Monitoring for and responding to incidents is a standard activity for help desk staff who support Oracle Fusion Applications in organizations that use Information Technology Infrastructure Library (ITIL) best practices.
Most automatically created incidents contain information about the state of a particular Oracle WebLogic Server domain at the time when a specific problem occurred. One type of information that is often collected is diagnostic dump files. Dump files are provided to assist in the resolution of incidents for the organization and to assist Oracle representatives in providing the effective support when needed. The types of dump files provided depend on the nature of the incident. Some incidents include Oracle Fusion Middleware dump files such as Oracle WebLogic Server diagnostic images, Java Virtual Machine thread dumps, and Dynamic Monitoring Service metric dumps. For more information about Oracle Fusion Middleware dumps, see the Diagnosing Problems section in the Administering Oracle Fusion Middleware Guide.
Each Oracle Fusion Applications module is written in one of the following code languages: Java, SOA, PL/SQL, or C. The amount and type of information automatically included with an incident may vary depending on the coding language of the relevant application module.
In general, it is possible to administer Oracle Fusion Applications without knowing which programming language implements particular modules. However, to monitor and diagnose all types of incidents successfully, it is important to become familiar with all of the incident configuration settings and the types of diagnostic dump files that are automatically provided for different kinds of incidents.
For more information about incident configuration settings for Oracle Fusion Applications, see the Default System Settings for Incident Creation section.
Oracle Fusion Applications incidents may also contain diagnostic log excerpts and diagnostic test results that are specific to Oracle Fusion Applications. Before transmitting incident information to the Oracle Support personnel, add more information (such as screen shots or more log file information) to incidents that were created either automatically or manually.
Incidents are designed to work along with other diagnostic features in the Oracle Fusion applications:
Error-handling: The Oracle Fusion Applications code that handles errors is designed so that errors that need quick attention automatically create incidents. When an incident is automatically created, log file excerpts are collected and associated with the incident automatically. Depending on the system configuration and the type of error, QuickTrace buffer contents and the results of automatically triggered diagnostic tests may also be collected and be associated with the incident automatically.
Diagnostic tests: Oracle developers create tests that can be used to help diagnose and resolve Oracle Fusion application problems. A diagnostic test may or may not be associated with a particular error message. If Java or SOA code in 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.
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. 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. Oracle developers accomplish this by setting the value of each diagnostic test's APPS_MSG_ID tag to match the identifier of any error message that should trigger the automatic execution of that test. There is no configuration setting for disabling this automatic execution of diagnostic tests.
The results of any automatically run diagnostic test are automatically associated with the related incident, and the identity of the user who received the error message is recorded.
It is important to be familiar with the following additional concept that is related to diagnostic tests:
Seed data is information that Oracle provides in the form of database records. Diagnostic tests are included in seed data.
Log files: By default, whenever an Oracle Fusion Applications incident is created automatically, an INCIDENT_ERROR level entry is recorded in the standard Oracle Fusion Applications log file and a copy of that log file is included with the incident. If the incident occurs in Oracle Fusion Middleware code, then two different kinds of log information are automatically included with the incident: a dump file containing all log entries for the relevant execution context ID (ECID) and either a complete log file or a log file excerpt starting 5 minutes before the incident.
For some incidents, all of the information needed to resolve the problem may be found in the log or dump files automatically included with the incident. In other cases, it may be needed to configure the system to log more detailed information, attempt to reproduce the problem, and then use the more detailed information in the log to diagnose the problem.
QuickTrace: If it is needed to troubleshoot a problem that has generated an incident, and if the information in the relevant Oracle Fusion application log file is insufficient to resolve the problem, then a QuickTrace dump file included with the incident information may provide the additional information needed. If so, it is possible to avoid increasing the amount of information to be logged and then attempting to reproduce the problem. (In general, increase the level of detail collected in the Oracle Fusion Applications logs only when absolutely necessary since collecting additional information may decrease system performance.)
By default, QuickTrace continuously records a specified level of log detail in an area of memory, generally at a more granular level of detail than is recorded in Oracle Fusion application log files. The memory that QuickTrace uses is recycled on an ongoing basis, with the oldest information being overwritten first. Because QuickTrace does not format information and because it 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.
The same commands in Oracle Fusion Applications code cause messages to be logged both in Oracle Fusion application diagnostic log files and in QuickTrace dumps. However, the system may gather different amounts of detail for the two kinds of output. At default setting levels, QuickTrace stores much more detailed information than diagnostic log files do.
Version information: If assistance is requested from Oracle Support to resolve an incident, there may be a request to provide information about the Oracle product versions that are running along with the incident information. In the Oracle Fusion applications, it is possible to obtain some product version information by selecting About Applications from the Settings and Actions menu. Additional version information can be obtained from Oracle Configuration Manager (OCM) and from Remote Diagnostic Agent (RDA) reports.
We recommend using Support Workbench to work with Oracle Fusion Applications incidents, which requires the installation of Oracle Enterprise Manager Cloud Control.
The Oracle WebLogic Server on which the relevant Oracle Fusion application is running
The host machine on which that Oracle WebLogic Server is running
To view Oracle Fusion Applications incidents using Support Workbench:
In Cloud Control, select one of the following Oracle Fusion Applications target types:
Oracle Fusion Applications instance
Product family
Cluster application
J2EE application
It is possible to find cluster application and J2EE targets in navigation hierarchical trees under the product family name and the Fusion Applications folder. If the tree being viewed includes Oracle Fusion Applications instance names, click a product family name to navigate to a page that displays cluster application and J2EE targets in the navigation tree.
From the dropdown menu, choose Diagnostics, and then Support Workbench.
If a J2EE application is selected as the target, the Login to Support Workbench page appears. Skip to step 6.
If an Oracle Fusion application instance target, an Oracle Fusion product family target, or an Oracle Fusion Applications cluster application target is selected; the rollup page for Support Workbench appears, summarizing the Support Workbench problems that are related to the selected target.
To return to this Support Workbench rollup page at a later time, from another Support Workbench page (such as Incident Details or the page that summarizes problems for a selected Fusion J2EE Application target), click the Diagnostics link in the Related Links section of the page that corresponds to the selected target type:
Fusion Instance Diagnostics
Fusion Product Family Diagnostics
Fusion Cluster Application Diagnostics
From the View By dropdown list, select Deployed Application.
In order for this page to display links for the number of problems and incidents for Oracle Fusion Applications targets, view the data by deployed application, rather than by product. The links for number of problems and incidents that appear in the Support Workbench Infrastructure Problems and Incidents table at the bottom of this page are for Oracle WebLogic Server targets, rather than Oracle Fusion Applications targets.
From the View Data dropdown list, select the time frame that contains the problem or incident of interest.
In the Problems and Incidents table, click a link for the number of problems or incidents of interest.
The Login to Support Workbench page appears.
In the Host Credentials area of the page, use one of the following methods to select credentials for connecting to the machine that hosts the Oracle WebLogic Server on which the Oracle Fusion application was running when the problem or incident occurred:
If credentials were saved as preferred credentials, then select Preferred in the Credential field.
If credentials were saved as named credentials, then select Named in the Credential field, and then select the specific credentials from the Credential Name dropdown list.
If credentials were not set, then select New in the Credential field and complete the following substeps:
In the UserName and Password fields, enter credential values for connecting to the host machine.
Inspect the default credential name supplied by Support Workbench in the Save As field, and modify the credential name if that is preferred.
For the entered credentials to be the preferred credentials, select the Set as Preferred Credentials checkbox.
The Preferred Host Credential is checked against the host machine's user names and passwords, but the preference is only set for the currently selected WebLogic server, even if multiple WebLogic servers run on that host machine.
To verify that the credentials entered work correctly, click Test.
In the WebLogic Server Credentials area of the page, use one of the following methods to select credentials for connecting to the Oracle WebLogic Server where the Oracle Fusion application was running when the problem or incident occurred:
Not being prompted for WebLogic Server Credentials indicates that the relevant Oracle WebLogic Server is currently unavailable. Some operations cannot be done when the server is unavailable, such as creating user-reported problems and performing additional diagnostic dumps. For information about restarting an Oracle WebLogic Server, see the Starting and Stopping Servers section in Administering Server Startup and Shutdown for Oracle WebLogic Server.
If credentials were saved as preferred credentials, then select Preferred in the Credential field.
If credentials were saved as named credentials, then select Named in the Credential field, and then select the specific credentials from the Credential Name dropdown list.
If credentials were not set, then select New in the Credential field and complete the following substeps:
In the UserName and Password fields, enter credential values for connecting to the Oracle WebLogic Server.
Inspect the default credential name supplied by Support Workbench in the Save As field, and modify the credential name.
For the entered credentials to be the preferred credentials for the currently selected Oracle WebLogic server, select the Set as Preferred Credentials checkbox.
Click Continue.
A Support Workbench page appears, summarizing problems related to the target.
Click the Problems tab, then select the relevant time period from the View dropdown list.
In the Details column of the table, click Show for the problem of interest.
In the list of incidents for the selected problem, click the Incidents link for the incident that occurred at the time of interest.
The Incident Details page appears.
In the Dump Files table, inspect the list of dump files that are associated with this incident, click the View Contents link for any dump file of interest, and use standard operating system steps to indicate whether to open the file or download it.
To create an additional dump file, click the Additional Diagnostics tab, then select the kind of dump to be created, and then click Run.
In the Run User Action page, enter any required input parameters and choose when to create the dump, and then click Submit.
To dismiss the confirmation message that appears when the dump operation completes, click OK.
To view the new dump file, repeat Step 12.
To create additional dump files, repeat Steps 13 through 15.
For information about using Support Workbench to package an incident and send it to Oracle Support, see the Package Incidents Using Support Workbench section.
Some incidents automatically trigger specific diagnostic test runs. The results of such automatically triggered tests are automatically associated with the triggering incident.
To make sure that certain diagnostic tests run automatically when certain error conditions occur, Oracle developers set the value of each test's APPS_MSG_ID tag to match the identifier of any error message that should trigger the automatic execution of that test. There is no configuration setting for disabling this automatic execution of diagnostic tests.
If the automatic creation of an incident results from an error, then the results of any automatically run diagnostic tests are automatically associated with the incident. The identity of the user who received the error message is also recorded.
An automatically created incident may have automatically run dumps associated with it.
For Oracle Fusion Middleware components, middleware diagnostic dumps may have been executed. For information about viewing dumps of this kind, see the Understanding the Diagnostic Framework section in the Administering Oracle Fusion Middleware Guide.
For Oracle Fusion Applications components, use Support Workbench in Oracle Enterprise Manager Cloud Control to view Oracle Fusion Applications incident information, including automatically created QuickTrace dumps.
To view automatically created QuickTrace dump files using Support Workbench, perform the following steps:
odl_quicktrace.To view Oracle Fusion application log files effectively, it is important to be familiar with the software that is available for working with log files. It is also helpful to know where log files are stored for various application modules.
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, it is possible to administer logging for Oracle Fusion Applications without knowing which programming language implements particular modules. However, to monitor or adjust all relevant parts of the system when necessary, it is important to become familiar with the configuration settings and log file locations used for each language.
For information about working with log files other than automatically-created log file excerpts, see the Work with Log Files Manually section. For background information about log files and log entries, see the Overview of Oracle Fusion Applications Incidents and Log Files section.
To help users resolve incidents, Oracle representatives often examine any dump files that were automatically created when the incident occurred, including QuickTrace dump files. When a QuickTrace dump file is automatically created as part of an incident, the file is stored in the incident directory along with any other dump files that are related to that incident. QuickTrace dump file names begin with odl.quicktrace.
For information about default profile option configuration settings and additional properties for QuickTrace, see the Adjust QuickTrace Detail Levels section.
To view information about automatically created QuickTrace dump files, use the following standard Oracle WebLogic Scripting Tool commands:
To view a list of incidents, use the listIncidents command.
To view details about a particular incident, including a list of dump files associated with that incident, use the showIncident command.
To view a specified dump file such as a QuickTrace dump file, use the getIncidentFile command.
For more information about using these commands, see the Viewing Problems and Incidents and the Working with Diagnostic Dumps sections in the Administering Oracle Fusion Middleware Guide.
To view information about automatically created QuickTrace dump files, use the following standard ADRCI utility commands:
To view a list of Automatic Diagnostic Repository (ADR) home directories, use the show homes command. Depending on the configuration of your system, QuickTrace dumps may be located under one or more of these ADR home directories.
To indicate which repository to work with, use the set home directory_path command, replacing directory_path with one of the locations from the output of the show home command.
To view a list of files associated with the incident that incident_number identifies, including any QuickTrace dump files for that incident, use the show incdir -i incdir_ incident_number command. QuickTrace dump file names start with odl_quicktrace and end with .dmp.
To view a list of just the dump files associated with the incident that incident_number identifies, use the show tracefile -i incident_number command
To view the contents of the QuickTrace dump file specified, use the show trace filename command.
To inspect metrics, target status information, and logs during troubleshooting, use the Problem Analysis and Analyze Log options in Cloud Control.
If an issue is discovered with the Oracle Fusion applications for which data needs to be gathered, and if the system has not created an incident for it automatically, then it is recommended to create an incident for it. Using incidents for all problems helps with the organization of the information gathered during the troubleshooting process. To create a new incident and a new problem listing, manually, using Support Workbench, perform the following steps:
In case it has not been done already, in Cloud Control, select the Fusion J2EE Application target that is associated with the issue for which an incident is being created.
From the dropdown menu, choose Diagnostics, and then Support Workbench.
In the Host Credentials area of the page, use one of the following methods to supply credentials for connecting to the machine that hosts the Oracle WebLogic Server that is associated with the incident being created:
If credentials were saved as preferred credentials, then select Preferred in the Credential field.
If credentials were saved as named credentials, then select Named in the Credential field, and then select the specific credentials from the Credential Name dropdown list.
If credentials were not set, then select New in the Credential field, and then perform the following substeps:
In the UserName and Password fields, enter credential values for connecting to the host machine.
Inspect the default credential name supplied by Support Workbench in the Save As field, and then modify the credential name if preferred.
For entered credentials to be the preferred credentials for the relevant host, select the Set as Preferred Credentials checkbox.
To verify that the entered credentials work correctly, click Test.
In the WebLogic Server Credentials area of the page, use one of the following methods to supply credentials for connecting to the Oracle WebLogic Server that is associated with the created incident:
If a WebLogic Server Credentials area is not visible on the page, it indicates that the relevant Oracle WebLogic Server is unavailable. Some operations cannot be done when the server is unavailable, such as creating user-reported problems and performing additional diagnostic dumps. For information about restarting an Oracle WebLogic Server, see the Starting and Stopping Servers section in Administering Server Startup and Shutdown for Oracle WebLogic Server.
If credentials were saved as preferred credentials, then select Preferred in the Credential field.
If credentials were saved as named credentials, then select Named in the Credential field, and then select the specific credentials from the Credential Name dropdown list.
If credentials were not set, then select New in the Credential field, and then perform the following substeps:
In the UserName and Password fields, enter credential values for connecting to the Oracle WebLogic Server.
Inspect the default credential name supplied by Support Workbench in the Save As field, and modify the credential name if preferred.
For entered credentials to be the preferred credentials, select the Set as Preferred Credentials checkbox.
Click Continue.
A Support Workbench page that summarizes problems related to the target appears.
On the page that summarizes problems for the selected target, scroll down to the Related Links section, and then click Create User-Reported Problem.
On the Create User-Reported Problem page, select the Other issue type, and then click Continue with Creation of Problem.
On the Problem Details page, perform the following substeps, as needed:
To associate the new incident with an existing Oracle Service Request, click SR# Edit, then enter the Service Request number, and then click OK.
To associate the new incident with an existing bug, click Bug#, then enter the bug number, and then click OK.
To see more information about the incident being created, such as user impact, checker findings, and purge date; on the Incidents tab, click Show in the appropriate row of the table, or click Show All Details in the table header.
To change which incidents are displayed in the table, select a new value from the Data Dumped dropdown list, and then click Go.
To see the list of Oracle Fusion Middleware diagnostic dumps that are created automatically when an incident is created manually, or to run any additional Oracle Fusion Middleware diagnostic dumps, select the incident in the table, and then click View to display the Incident Details page.
For more information about using this page, see the topic Incident Details Page in the Cloud Control online help.
For more information about Oracle Fusion Middleware dumps, see the Diagnosing Problems section in the Administering Oracle Fusion Middleware.
Oracle Fusion Applications diagnostic tests are designed to assist in monitoring the health of the system and to assist in troubleshooting when necessary.
In addition to using the information gathered by diagnostic tests that run automatically, it is possible to run diagnostic tests manually. For manually created incidents, it is recommended to search for appropriate diagnostic tests to run manually. For automatically created incidents that automatically run certain diagnostic tests, additional diagnostic tests to run manually may be discovered, or diagnostic tests may be rerun after resolving an incident, to verify that normal operations have been restored.
For external diagnostic tests—tests that do not depend on the availability of any specific Oracle Fusion application—run tests using either Diagnostic Dashboard or the diagctl command-line interface. For technical reasons, use 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 the Use Diagnostic Dashboard to Run Diagnostic Tests section.
Both the Diagnostic Dashboard application and the diagctl command-line interface are automatically installed as part of the Oracle Fusion Applications installation. However, 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 the Configure Access to the Diagnostic Dashboard section.
For proper operation of the diagctl command-line interface, set certain environment variables. For more information about setting these variables, see Configure Required Variables for the diagctl Command Line Interface.
The user name that used to sign in to an Oracle Fusion application affects which diagnostic operations are available to that user name. Be sure to sign in using an account that has a job role for the diagnostic operations needed. For more information, see Configure Access to the Diagnostic Dashboard.
To assist in locating diagnostic tests for specific purposes, the diagnostic tests that are received with Oracle Fusion applications are all assigned to predefined categories.
Use diagnostic tests to check normal system health and to troubleshoot system problems. Configure the 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.
tag name and tag value assignments that Oracle uses to categorize diagnostic tests cannot be changed, and those tag names or tag values cannot be removed 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 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.
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 Diagnostic Dashboard. Provided that you are assigned to an appropriate job role, navigate to Diagnostic Dashboard from any Oracle Fusion application or from Oracle Enterprise Manager Cloud Control (Cloud Control).
To use Diagnostic Dashboard to execute or monitor diagnostic tests, or display or purge test results while using an Oracle Fusion application, navigate to Diagnostic Dashboard directly from the application. To display the Diagnostic Dashboard application from an Oracle Fusion application, perform the following steps:
To use the Diagnostic Dashboard application to execute or monitor diagnostic tests or display or purge test results while using Cloud Control, such as while using Support Workbench to gather additional information about an existing incident, navigate to Diagnostic Dashboard directly from Cloud Control. To display to Diagnostic Dashboard from Cloud Control, perform the following steps:
The Diagnostic Dashboard application provides a graphical user interface that allows the execution and monitoring of diagnostic tests, display and purge test results, and register any special-purpose diagnostic tests that Oracle Support may provide. To run a diagnostic test from Diagnostic Dashboard, perform the following steps:
Navigate to Diagnostic Dashboard for the Oracle Fusion applications being administered, and log in using an account for the application that is intended to test that has one of the following job roles:
Diagnostic Regular User
Diagnostic Advanced User
Diagnostic Administrator
For more information about navigating to Diagnostic Dashboard, see the Navigate to the Diagnostic Dashboard Application section.
In the Regional area on the left side of 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 need to be searched for, and then click Search.
For information about the kinds of test characteristics that can be specified, see Search for Diagnostic Tests by Name, Categorization Tag, or Module.
The results of the search appear in a table below the Search button.
In the current release, it is possible to search for and display information about all diagnostic tests that are associated with a tag name that specified. Currently, it is not possible to limit those searches to particular pairs of tag names and tag values. If there is a need to locate diagnostic tests that are associated with a particular tag name and tag value, search for the tag name and then scan the results for the tag value required.
In the search results table, select the checkbox for each test that need to be run, and 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 selected tests.
From the View menu, use standard techniques to adjust how the table displays its data.
To display nested tests and test steps, 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 found:
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 and skip to Step 8, or click the alert icon in the Input Status column to display the Input Parameters dialog and go to Step 7.
For any root level test that displays the message Required Input Values Validated or the message Input Values Validated, consider whether there is a need to inspect the parameter values the test is currently set to use. If so, or if there is a need to change an existing input parameter value, click the check mark icon in the Input Status column to display the Input Parameters dialog and go to Step 7.
Use the Input Parameters dialog 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 Inputs Required, skip to Step 8. A test that displays this message does not use input parameters.
If the alert icon was clicked in the Input Status column to display the Input Parameters dialog , specify new parameter values as needed, according to the parameter type, as follows; otherwise, skip this step.
For Boolean parameters, click 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 menu, 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. In the Search and Select dialog, select the appropriate value for the parameter, and then click OK.
The values that are available in the list of values are determined in the metadata for the diagnostic test.
To save the current input values for convenient future use, click Save to display the Save As Input Set dialog. Supply a name for the set of values being saved, plus any additional information about the input set to be stored, and then click OK.
To use a set of previously stored input values, select the appropriate set from the Input Set dropdown list, and then click Load.
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.
After finishing setting input parameters for the current test, click OK.
For any other tests that are missing input values, or that have parameter values that need to be overridden in the test run, repeat Step 6 through Step 7.
From the View menu for the Choose Tests to Run and Supply Inputs table, choose Availability to display the Diagnostic Test Availability dialog.
In the Select a Diagnostic Test for Details table, select each test 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 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 go to Step 11.
If all of the listed tests are available to be run and if there is no need to know whether they are internal or external, then 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:
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 can be run only by using Diagnostic Dashboard when the specified application is available.
It is not possible to run an internal diagnostic 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 in the expanded Detached Table contains an error message, then make a note of the message and see Ensure that Diagnostic Tests Are Available for information about resolving problems that are associated with specific error messages.
If it has not been done, close the Detached Table window and the Diagnostic Test Availability dialog, repeat Step 9 and Step 10 to verify that all listed tests are now available to be run, and then go to Step 13.
If needed, enter a name for the test run in the Run Name field in the control bar.
Do not use the word error in the test run name. If the word error is used or if the Run Name field is left 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 Identify Diagnostic Test Start Methods from Test Run Names.
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: Runs the selected test or tests immediately after clicking Run.
Run Later: Schedules when the test or tests will be run. This option is integrated with Oracle Enterprise Scheduler Service.
The ability to schedule diagnostic tests is supported only if the Oracle Fusion Applications configuration that have been provisioned includes Oracle Enterprise Scheduler.
When this option is selected, the Run button on the toolbar changes to a Schedule Run button.
To schedule when the test or tests will be run, perform the following substeps :
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.
To run prerequisite tests, make sure that the No Prerequisite option in the Run Options menu is not selected. Otherwise, select it to ensure no prerequisite tests are run.
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 Run Now is chosen in Step 14, then click Run to start executing the test run. If Run Later is chosen in Step 14, then the test run starts executing at the time set in the Schedule Tests dialog.
Use Diagnostic Dashboard to search for available diagnostic tests. One way to search is to use Search by Tags to search for diagnostic tests that are associated with a particular categorization tag name that you specify. Another way to search is to use Search by Tests to search for tests with values that are specified for one or more of the following characteristics:
Test name
Test description
Name of the Oracle Fusion Applications code module that the test checks.
The Diagnostic Testing Framework treats any search value that you enter as a case-insensitive matching pattern, returning the result if the pattern appears anywhere in the specified field. However, if you specify more than one search value to match, the framework returns results only for diagnostic tests that match all of the values that you specify (logical AND).
In general, searching for diagnostic tests is done as a portion of the process of running diagnostic tests from Diagnostic Dashboard. For more information, see the Use Diagnostic Dashboard to Run Diagnostic Tests section.
Oracle Fusion Applications provides two tools for diagnosing problems at the application level: the Diagnostic Dashboard and the diagctl command-line interface. Access to diagnostic testing functionality is controlled separately for these two tools. For Diagnostic Dashboard, it is possible to use Security Console to assign specific users to any of the four preconfigured job roles that grant users access to Diagnostic Dashboard. Each of these four job roles provides access to a different amount of the functionality of the dashboard.
Oracle Fusion applications display the Troubleshooting section and the Run Diagnostic Tests command in the Settings and Actions 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, because its added capabilities allow users to work with administrators more flexibly during troubleshooting.
The Diagnostic Administrator job role can use all of the diagnostic testing functionality provided for Oracle Fusion applications, including purging test results from the database and canceling test runs started by other users.
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 Diagnostic Dashboard, perform the following steps:
Decide which users need the capabilities of each of the four preconfigured job roles for diagnostic operations.
Use Oracle Identity Manager to assign the appropriate job role to each user.
Whether a diagnostic test can be run at any given time depends on both the specific requirements of the test and the current state of the 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 about running diagnostic tests, see the Use Diagnostic Dashboard to Run Diagnostic Tests section.
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.
If checking for availability of one or more diagnostic tests and encounter an error message in the expanded Detached Table from the Diagnostic Test Availability dialog, then one of the following actions may aid in resolving the problem. If the text in the Error column is:
"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 the help desk for assistance in searching for a solution in the My Oracle Support Knowledge Base. If the Knowledge Base does not provide a solution, ask the help desk to open an Oracle Support service request.
"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 the database. Contact the help desk for assistance in searching for a solution in the My Oracle Support Knowledge Base. If the Knowledge Base does not provide a solution, ask the help desk to open an Oracle Support service request.
"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 to run the selected diagnostic test—the test is an internal test.
For more information about installing and deploying Oracle Fusion Applications, see the Provision a New Applications Environment section 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.
"The current user does not have execution privileges for the following tests"
Log in as a user who has appropriate privileges to execute the selected test. For information about the privileges required, see the Configure Access to the Diagnostic Dashboard section.
"The current user does not have privileges to view reports for the following tests"
Log in as a user who has appropriate privileges to view the results of the selected test. For information about the privileges required, see the Configure Access to the Diagnostic Dashboard section.
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 actions that need to be performed.
Diagnostic tests often have input parameters. Oracle supplies default values for some input parameters. When preparing to run one or more diagnostic tests, it is possible to change the values for input parameters that have default values and enter values for input parameters that do not have default values. If the same parameter values will be used more than once, it is possible to save those values into an input set that can be reused for later test runs.
All required input parameters must have values assigned before running 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. Then, it is possible to either enter parameter values individually in the New Value column of the Edit Input Set table, or select a previously saved set of values from the Input Set dropdown list. After all of the required input parameters are specified , the Diagnostic Dashboard application displays a check mark icon with the message Inputs Edited: Required Input Values Validated. For more information, see the Use Diagnostic Dashboard to Run Diagnostic Tests section.
To run diagnostic tests immediately, use either Diagnostic Dashboard or the diagctl command-line interface.
In Diagnostic Dashboard, specify that there is a need to run a diagnostic test immediately by choosing Run Now from the Run Options menu. For more information, see the Use Diagnostic Dashboard to Run Diagnostic Tests section.
For the diagctl command-line interface, specify that there is a need to run a diagnostic test immediately by entering the command to run the test from an interactive session prompt. For more information, see the Use the diagctl Command-Line Interface to Run Diagnostic Tests section.
If the Oracle Fusion Applications configuration that has been provisioned includes Oracle Enterprise Scheduler, it is possible to specify a particular time to run diagnostic tests.
In Diagnostic Dashboard, schedule diagnostic tests by choosing Run Later from the Run Options menu. For more information, see the Use Diagnostic Dashboard to Run Diagnostic Tests section.
To run a delayed diagnostic test using the diagctl command-line interface, create a script that calls diagctl.sh, 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 the Manage Oracle Enterprise Scheduler Service and Jobs section.
It is possible to check the status of a diagnostic test from Diagnostic Dashboard or from the diagctl command-line interface. The command-line interface is primarily intended for use if the Diagnostic Dashboard application is temporarily unavailable. For information about using diagctl to check the status of a diagnostic test, see Use the diagctl Command-Line Interface to Check the Status of a Diagnostic Test.
In Diagnostic Dashboard, the Diagnostic Test Run Status table displays the following two types of status information:
Execution Status: This column displays status information about whether a test run request can be executed successfully.
Diagnostic Status: This column displays status information about whether individual diagnostic tests detect problems.
After running a diagnostic test using Diagnostic Dashboard, click Refresh to display the latest status information, including rows for the following kinds of test runs:
Test runs that were run immediately from Diagnostic Dashboard
Test runs that were scheduled to be run later from Diagnostic Dashboard
Test runs that were submitted using the diagctl command-line interface
When clicking Refresh, the Diagnostic Dashboard lists any additional test runs that users have submitted in the current Oracle WebLogic Server domain. If the Oracle Fusion Applications deployment uses Global Single Instance (GSI), then Diagnostic Dashboard also lists test runs that were submitted in other domains.
To check the status of a diagnostic test using Diagnostic Dashboard, perform the following steps:
From time to time, there may be a need to stop a diagnostic test or test run that is running. Several constraints affect the ability to cancel a diagnostic test or test run:
In the current release, use Diagnostic Dashboard to cancel a diagnostic test or test run that is running. The diagctl command-line interface does not provide this capability.
To cancel a test or test run you started, 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, 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 this type of test depends on whether the test has already started to execute when there is a need 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: in the Scheduling Services area of Oracle Enterprise Manager Fusion Applications Control, select the job request and click Cancel.
To cancel a scheduled diagnostic test that the Diagnostic Test Run Status dashboard panel indicates is already running, use Diagnostic Dashboard to cancel it in the same way that a test that ran immediately would be cancelled.
When cancelling a diagnostic test or test run, the consequences may vary depending on how much of the test run has executed and the language in which the test code is written:
If a diagnostic test run is cancelled 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 canceled 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 was canceled:
Test Run "test_name" has been canceled.
Please check the test run report for further details.
When cancelling a diagnostic test step that is implemented in Java, the diagnostic framework automatically closes the test step's database connection, using an asynchronous command to terminate the thread. However, when cancelling a diagnostic test step that is 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, 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 Diagnostic Dashboard, perform the following steps:
diagctl command-line interface. To view the results of a diagnostic test in Diagnostic Dashboard, perform the following steps:
diagctl, see the Use the diagctl Command-Line Interface to View the Results of Diagnostic Tests section.Any test run name that the Diagnostic Testing Framework supplies follows naming conventions that reflect how the test was started. If an unfamiliar diagnostic test run occurred at an unexpected time, then knowing the test run naming conventions can assist in understanding the circumstances in which the test run was started:
When submitting 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 Diagnostic Dashboard and when tests are submitted using diagctl.
When scheduling 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 Diagnostic Dashboard to run later. (Tests that are submitted using diagctl always run immediately.)
For example, if the test run name routine is entered, 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.
Some times, removing diagnostic test run results from the database may be needed to keep the Run Status table from becoming too large.
To remove the results of one or more diagnostic test runs from the database, use the Diagnostic Dashboard application with an account that has been assigned the Diagnostic 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, perform the following steps:
If the diagnostic test was started from the current application session, then the Diagnostic Test Run Status table automatically displays in the lower right portion of the screen after clicking Run. Skip to Step 4.
If the Diagnostic Dashboard for the Oracle Fusion applications that is being administered is not already displaying, navigate to the dashboard and log in using an account for the application that needs its test results purged. For more information see Navigate to the Diagnostic Dashboard Application.
In the Regional area of the screen, expand the Tasks panel, and then 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 may need to be removed from the database:
Select any appropriate filter from the Find dropdown list.
Click the search button, enter search criteria, and then click OK.
After searching or filtering, inspect the listings displayed in the Diagnostic Test Run Status table, and then decide if listed test results should be removed 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 may need to be removed from the database, and then click the delete button in the Diagnostic Test Run Status table header.
In the Delete Test Run dialog, select Delete test run "TestRunName", and then 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 a record in the Diagnostic Test Run Status table was selected, either the Delete Test Run dialog or the Confirm Test Run Delete dialog appears.
Complete the purge process using the appropriate instructions for the dialog displayed on the screen:
If the screen displays the Delete Test Run dialog, select Delete all test runs in the list, and then click OK to remove all of the listed test run results from the database immediately.
If the screen displays the Confirm Test Run Delete dialog, click Yes to remove all of the listed test run results from the database immediately.
To operate properly, the diagctl command-line interface requires certain environment variables to be set.
diagctl command-line interface. The commands that define these variables to the .profile or .bashrc files of all users who will run diagctl may need to be added.
To set environment variables for a user of the diagctl command-line interface, perform the following steps:
The Diagnostic Test Framework command-line utility, diagctl, allows the specification of 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.
It is possible to run one or more diagnostic tests using a single diagctl command. It is particularly appropriate to use diagctl when there is no access to a WebLogic Server.
Technical constraints prevent the diagctl 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). Use Diagnostic Dashboard to run any internal diagnostic tests.
Also, use 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 the Use Diagnostic Dashboard to Run Diagnostic Tests section.
To run Diagnostic Tests from the diagctl command-line interface, perform the following steps:
The Diagnostic Test Framework command-line utility, diagctl, provides three different ways to specify the diagnostic test for which status information is needed: 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, perform the following steps:
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, perform the following steps:
Although log file excerpts are automatically associated with many automatically created incidents, information from log files may occasionally need to be gathered manually. The following sections describe how to work with log files. For background information about log files and log entries, see the Overview of Oracle Fusion Applications Incidents and Log Files section.
By using Oracle Enterprise Manager Cloud Control, log files can be searched either by specifying search criteria interactively, or by saving and reusing search criteria.
Use Cloud Control to search for information in the log files of single or multiple domains within a single Fusion instance.
To search standard Oracle Fusion Applications log files using Cloud Control, perform the following steps:
In Cloud Control, from the Target menu, choose Fusion Applications.
In the list of Oracle Fusion instances and Oracle Fusion Applications product families, click the name of the instance of interest.
From the dynamic Fusion Instance target menu, choose Logs, then View Log Messages.
If it is collapsed, then expand the Search area of the Log Messages pane.
Expand the Selected Targets part of the Search area, and make sure that it lists the targets for all of the log files that need to be searched:
To search the log files for only some of the listed target members, then select the ones to omit from the search and click Remove.
For the log search operation to search log files that are not currently listed, then click Add, select the additional targets that need to be searched, and click Select.
Enter or select applicable search criteria in any of the visible search fields, such as the following fields that are visible by default:
In the Date Range fields, specify the time period for which 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 the 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 to display.
In the Message fields, specify some or all of the message text in the log messages to display.
If selecting either the matches search operator or the does not match search operator, then either specify the full text of the message, or use a standard Java language expression to specify the characteristics of the missing text. For example, in standard Java expressions, the period (.) acts as a wildcard that matches most single characters, and the combination of a period and an asterisk (.*) acts as a wildcard to match any string of characters.
In contrast, the following search operators contain implicit wildcard semantics. Wildcard characters or other Java expressions are not needed when using any of these operators to search for a part of the text of a message:
contains
does not contain
starts with
does not start with
ends with
does not end with
If there is a search for multiple values within a single search field, using commas to separate the values, then the search results display log entries that match any of the criteria specified for that field (logical OR). However, if criteria is specified in multiple search fields, then the search results display only log entries that match specified criteria in all of those search fields (logical AND).
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 to be used in the search, then click Add.
For example, ECID might be selected to search for all log messages that are associated with a particular execution context identifier.
In each field that was added, specify the value to match in the search.
For example, the ECID value of 004bYSyedEi3v1A5Jb8Dyf0002kx003XFf might be entered.
Click Search.
If the Oracle Fusion Applications environment includes Cloud Control, then it is possible to use Cloud Control to save log search criteria (so that repeating the same search is more convenient in the future) by performing the following steps:
Log into Cloud Control as the user who will need to reuse the criteria that is planned to be saved. Only the user who saves a set of log search criteria can reuse that set.
Decide upon the target for which repeated log searches will be needed.
For example, it might be needed to save a log search for a target about which there have been repeatedly received alert notifications.
For maximum flexibility when reusing search criteria, use the highest level target that is expected to be applicable. Such a saved log search can be reused for the selected target or any target beneath it in the hierarchical navigation tree.
For example, if saving log search criteria for a particular Oracle Fusion Applications cluster application, then it is possible to reuse those saved search criteria for that same cluster application or for any Managed Server within that cluster.
Use either of the following methods to navigate to a screen where the log search criteria can be specified for the preferred target:
From the Target menu, choose Fusion Applications, and then expand the hierarchical navigation tree, select the preferred target, and choose Logs, then View Log Messages from the dynamic target menu.
From the Enterprise menu, choose Monitoring, then Logs, and then expand the Selected Targets section and add the preferred target.
Enter or select the desired search criteria in all applicable search fields.
For more information about these fields, see the Search Oracle Fusion Applications Log Files in Single or Multiple Domains section.
Click Search.
Review the search results to ensure the target and search criteria to be saved are specified, then click Save Search.
A confirmation message appears, including the default name for the saved search, which can include lengthy information about the criteria that was used.
If the Save Search button is not available, then the system has not detected any change in target or search criteria since the last log search. To reenable the Save Search button, select a different target or specify different search criteria.
To assign the saved search a more convenient name, complete the following substeps:
From the Saved Searches dropdown list, select Manage Saved Searches.
In the Manage Favorites dialog, click the first column of the table row that lists the saved search that needs to be renamed.
If the list of saved searches is long, click the query by example button and use standard techniques to help in locating the saved search of interest.
In the Name field, enter a new name for the saved search.
Saved log search names can be up to 256 characters long. It is recommended to specify a name that will help in remembering the target that the search applies to, as well as the search criteria.
The name is the only characteristic of a saved log search that can be modified. To save different search criteria, or to save the same criteria for a different target, create a new saved search by repeating all steps of this procedure, starting with Step 1.
Click OK.
For information about reusing saved log search criteria, see the Reuse Saved Log Search Criteria section.
If the Oracle Fusion Applications environment includes Cloud Control, then it is possible to reuse saved log search criteria. For information about saving log search criteria, see the Save Oracle Fusion Applications Log Search Criteria for Reuse section.
To repeat a log search that was previously saved using Cloud Control, perform the following steps:
|Log into Cloud Control as the user who saved the search criteria to be reused.
Only the user who saved a set of log search criteria can reuse that set.
Use either of the following methods to navigate to a screen where the log search criteria can be specified for the preferred target:
From the Target menu, choose Fusion Applications, and then expand the hierarchical navigation tree, select the preferred target, and choose Logs, then View Log Messages from the dynamic target menu.
From the Enterprise menu, choose Monitoring, then Logs, and then expand the Selected Targets section and add the preferred target.
For the search to be effective, the target that is selected must be either the target for which the search criteria were originally saved, or a target that is below the original target in the hierarchical navigation tree.
For example, if the search was originally saved for a cluster application target, reuse that search only for the same cluster or for a Managed Server that belongs to that cluster.
From the Saved Searches dropdown list, select the saved search for the search criteria to be reused.
The Saved Searches dropdown list contains all of the log searches that the current user previously saved, regardless of the saved or current target contexts.
Provided that the current target is either the target for which the selected search was saved or a target that is below the original target in the hierarchical navigation tree, then the search is reexecuted as soon the saved search to be reused is selected.
If the current target is below the originally saved target in the navigation tree, then the reexecuted search uses only the saved search criteria that apply to the subsidiary target.
If the current target is not either the target for which the selected search was saved or a target that is below the original target in the hierarchical navigation tree, then the search is not executed.
If some of the saved search criteria did not apply to the currently selected target, and if there is a need to save just the applicable search criteria and current target context, then click Save Search.
To assign the new saved search a more convenient name, complete the following substeps:
From the Saved Searches dropdown list, select Manage Saved Searches.
In the Manage Favorites dialog, click the first column of the table row that lists the saved search to be renamed.
If the list of saved searches is long, click the query by example button and use standard techniques to help in locating the saved search of interest.
In the Name field, enter a new name for the saved search.
It is recommended to choose a name that will help in remembering the target that the search applies to, as well as the search criteria.
Click OK.
Some times during troubleshooting, it may be needed to configure the system to log more detailed information before reproducing the problem. The procedure for gathering more detailed log information depends on whether the relevant Oracle Fusion Applications component uses standard or non-standard logging.
For Oracle Fusion applications that use standard logging, adjust one or more of the following profile options to change the amount of information that is logged during troubleshooting:
To log more detailed information about a particular user's operations, create or change the value of the AFLOG_LEVEL profile option for that user.
To log more detailed information for an entire site, create or change the value of the AFLOG_LEVEL profile option for the site.
To specify the Oracle Fusion Applications code modules for which standard log entries will be written at the level of detail specified by the AFLOG_LEVEL profile option for a particular user, set the AFLOG_MODULE profile option for the same user. To minimize the number of unrelated log entries that will be placed in the log file during troubleshooting, it is recommended to specify a particular module whenever feasible.
For more information about these profile options, see Table 23-2.
Oracle Fusion Applications provides a Troubleshooting Options dialog that can be displayed by choosing the Troubleshooting Options command in the Troubleshooting section of the Oracle Fusion Applications Settings and Actions menu. The Troubleshooting Options dialog provides ways to adjust the following kinds of settings for the current Oracle Fusion Applications user:
Database trace (optionally capturing bind variables or wait events)
For more information about Database Trace, see the section about using application tracing tools in the Oracle Database Performance Tuning Guide.
PL/SQL profiler
For more information about PL/SQL profiler, see the section about the PL/SQL hierarchical profiler in the Oracle Database Advanced Application Developer's Guide.
Applications logging Severity Level
Applications logging Modules
However, the Settings and Actions menu displays the Troubleshooting section and the Troubleshooting Options command only for end users who have the following duty role:
Supportability Level Management (FND_SUPPORTABILITY_LEVEL_MANAGEMENT_DUTY)
By default, only the following job roles are mapped to the Supportability Level Management Duty role:
Application Administrator (FND_APPLICATION_ADMINISTRATOR_JOB)\
Application Diagnostics Administrator (FND_DIAG_ADMINISTRATOR_JOB)
These two job roles have broad administrative privileges, so it is recommended to assign them only to administrative personnel. To give other users access to the Troubleshooting Options dialog, use a job role that is specifically intended for troubleshooting and that is mapped to the Supportability Level Management Duty role. Use either the BUSINESS FLOW TROUBLESHOOTING job role, which is provided in seed data, or create such a job role. After the troubleshooting job role is chosen or made available, it is possible to assign users to that job role as needed.
To grant a user access to the Troubleshooting Options command and dialog, and assist the user to gather data for troubleshooting, perform the following steps:
Decide whether to use the BUSINESS FLOW TROUBLESHOOTING job role (also called an external role) or to use Oracle Identity Manager to create a similar job role that can be assigned to users who need access to the Troubleshooting Options command and dialog.
If a job role was created in Step 1, use Oracle Authorization Policy Manager to map the job role to the following duty role:
Supportability Level Management (FND_SUPPORTABILITY_LEVEL_MANAGEMENT_DUTY)
To make sure that the job role that was created can be used for troubleshooting any Oracle Fusion application, be sure to map the job role to the Supportability Level Management Duty role. This duty role provides the needed functionality for a different application stripe. An application stripe is a subset of policies in the policy store that is used by a particular application or group of applications.
In Oracle Identity Management (OIM) and Security Console, job roles are external roles and duty roles are application roles.
For any user who currently needs access to the Troubleshooting Options dialog, use Oracle Identity Manager to assign the job role that was chosen or created in Step 1 to the user.
For more information, see the Assigning Members to a Role section or the Adding and Removing Roles section in the Oracle Fusion Middleware User’s Guide for Oracle Identity Management.
To make sure that the user has access to the new job role assignment, direct the user to log out from their Oracle Fusion application and log back in.
Direct the user to choose Troubleshooting Options from the Troubleshooting section of the Settings and Actions menu, and to modify Troubleshooting Options settings as needed for the specific problem being resolved:
If the user does not see Troubleshooting Options or the Troubleshooting section in the Settings and Actions menu and if Step 2 of this procedure was performed within the last few minutes, direct the user to wait a few more minutes and then log out and log in again. When mapping a job role to one or more duty roles, the change may take effect a few minutes later, after Oracle Authorization Policy Manager refreshes the server cache.
To enable all of the available troubleshooting options, then direct the user to select the Enable all checkbox.
To enable Database Trace, then direct the user to select the Database trace checkbox.
For more information about Database Trace, including the options of capturing bind variables or wait events, see the section about application tracing tools in the Oracle Database Performance Tuning Guide.
To enable the PL/SQL profiler, then direct the user to select PL/SQL profiler.
For more information, see the section about using the PL/SQL hierarchical profiler in the Oracle Database Advanced Application Developer's Guide.
To log information for the user's actions at a level of detail that is different from the logging done for other users at the same site, then direct the user to select the Applications logging checkbox and to select the appropriate level of detail from the Severity Level dropdown list.
This user action is equivalent to an administrator setting the value of the AFLOG_LEVEL profile option for that user. For more information about the available logging severity levels, see the Standard Logging Levels section.
To limit the logging for the user's actions to operations that use one or more particular code modules, and if the name of those code modules is known, then direct the user to enter the module names in the Modules field, separating the names using commas without spaces.
The user can use the % wildcard to represent part of a module name or to represent all module names.
Direct the user to click OK.
Users who change the Applications logging Severity Level may need to log out from their Oracle Fusion application and log in again to have the changes take effect. It is recommended to direct the user to do so at this point in the process.
Direct the user to try to reproduce the problem.
Verify that the additional information needed was collected.
Unless the user needs ongoing access to the Troubleshooting Options dialog, use Oracle Identity Manager to revoke the user's assignment to the job role that is chosen or created in Step 1.
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.
Some logging functionality for the Oracle Fusion Global Payroll application is separate from the standard logging functionality for Oracle Fusion Applications. By default, Oracle Fusion Global Payroll processes that are submitted using Oracle Enterprise Scheduler do not write log entries.
For optimum performance and log file sizes, it is recommended that the enable logging functionality is enabled for such Oracle Fusion Global Payroll processes only when troubleshooting an existing problem in collaboration with Oracle Support. Performance is particularly critical for Oracle Fusion Global Payroll because processing must be completed quickly to make sure that payments are made on the correct banking date. Managing log file size is particularly critical for Oracle Fusion Global Payroll because, depending on the log settings chosen, Oracle Fusion Global Payroll log entries can use more than 2 GB of disk space per employee paid.
Oracle Support may require to use the logging parameter values shown in Table 12-1 to enable logging functionality and obtain certain kinds of log data for Oracle Fusion Global Payroll processes that are submitted using Oracle Enterprise Scheduler. Specify the logging parameter values in a configuration group—either the default configuration group or another configuration group. Specify the parameter values in any order.
After the logging parameter values are set, arrange for the specified Oracle Fusion Global Payroll process or processes to be run using the configuration group that includes those logging parameter values, and then provide the logged results to Oracle Support for interpretation.
Depending on the payroll size and the type of problem that is being resolved, Oracle Support may recommend to run one or more Oracle Fusion Global Payroll processes for all employees who are listed on the payroll, or that you place only a small number of employees in the payroll relationship group for which log entries will be collected. When practical, running the process for a small number of employees helps to optimize the troubleshooting process and manage the amount of disk space used by the logged information.
The complete task flow for Oracle Fusion Global Payroll typically consists of multiple processes, with only the final process in the flow involving actual payments. To troubleshoot without making unintended payments, one possibility is to use a debugging instance of the Oracle implementation, if one is available. Another possibility is to use your production Oracle implementation, but run only the processes that do not involve payment. After gathering the log data requested by Oracle Support, arrange for an Oracle Fusion Global Payroll user to roll back the processes that were run for troubleshooting purposes.
Table 12-1 Logging Parameter Values for Oracle Fusion Global Payroll Application
| Parameter | Definition |
|---|---|
|
B |
Balance maintenance information: Provides output information that shows the creation and maintenance of balances used during Oracle Fusion Global Payroll processing. |
|
C |
C cache structures information: Provides output information that shows details of the Oracle Fusion Global Payroll cache structures and changes to the entries within the structures. While working on a service request, Oracle may request to use this parameter to gather additional information. |
|
E |
Element entry information: Provides output information that shows the state of the element entries in the process memory after the entries are retrieved from the database. The information is provided whenever data for an entry is changed during processing. |
|
F |
Formula information: Provides output information that shows details of formula execution, including formula contexts, input, and output. |
|
G |
General logging information: Provides general information, rather than a specific information type. This parameter does not provide sorted output. In general, it is recommended to choose parameters that provide specific types of information. |
|
I |
Balance output information: Provides output information that shows details of values written to the database from the balance buffers. |
|
L |
Balance fetching information: Provides output information that shows the balances retrieved from the database and whether the process will use those balances. (If balances such as Year To Date totals have expired because the year has changed, the process resets them and uses the new balance.) |
|
M |
Entry or exit routing information: Provides output information that shows when any function is entered or exited, using messages such as the following: In: pyippee Out: pyippee The information is indented to show the call level, and can be used to trace the path taken through the code at the function call level. This parameter is typically used when trying to diagnose a problem such as a core dump. |
|
P |
Performance information: Provides output information that shows the number of times certain operations take place at the assignment and run levels, and why those operations took place. For example, this parameter provides information about the balance buffer array write operation. |
|
Q |
C cache query information: Provides output information that shows the queries being performed on the Oracle Fusion Global Payroll cache structures. While working on a service request, Oracle may request to use this parameter to gather additional information. |
|
R |
Run results information: Provides output information that shows details of run results and run result values just as they are about to be written to the database from the Run Results buffer or the Values buffer, to allow verification that buffer contents were correct. |
|
S |
C Cache ending status information: Provides output information that shows the state of the Oracle Fusion Global Payroll cache before the process exits, whether that process ends with success or an error. While working on a service request, Oracle may request to use this parameter to gather additional information. |
|
T |
PL/SQL detail: Provides additional details regarding PL/SQL calls, provided that parameter Z is also chosen. |
|
Z |
PL/SQL output: Provides output information that shows PL/SQL calls made by the Payroll application. This setting is typically useful for code processes that use a large amount of PL/SQL, such as Prepayments and Archive. |
|
T and Z |
PL/SQL detail and PL/SQL output: To obtain detailed information about the PL/SQL calls made by the Oracle Fusion Global Payroll application, use the combination of the T parameter and the Z parameter. This combination is typically used to obtain information about Oracle Fusion Global Payroll processes that use a large amount of PL/SQL code, such as Prepayments and Archive. The output from using these parameters is buffered while the process is running and is placed at the end of the log file after processing is complete. Each Oracle Fusion Global Payroll process instance has its own log file, located under the |
To configure logging for the Oracle Fusion Global Payroll application, perform the following steps:
Determine what kinds of information needs to be logged, and make a note of the corresponding parameter values from Table 12-1.
If there is an Oracle Fusion Global Payroll configuration group that already has logging parameters set to the values needed, then skip to Step 9.
If there is no existing configuration group that has the logging parameter values needed, then continue to Step 3.
Sign in to the Oracle Fusion Global Payroll application using an account that has the Manage Payroll Process Configuration privilege.
Accounts that have this privilege typically include Payroll Manager, Human Capital Management Application Administrator, and Payroll Administrator.
Use the following substeps to navigate to the Manage Payroll Process Configuration screen:
From the Tools section of the Navigator menu, choose Setup and Maintenance.
In the Overview screen that appears, click the All Tasks tab.
In the Match field of the Search panel, select All.
In the Search field, select Task Lists and Tasks.
In the Name field, enter Manage Payroll Process Configuration.
Click Search.
In the Search Results panel, click the Go to Task icon for Manage Payroll Process Configuration.
Decide for which configuration group the logging parameter values will be set:
To change the logging parameter values for all of the Oracle Fusion Global Payroll processes that are submitted using Oracle Enterprise Scheduler without a specific configuration group being specified, and that are submitted after changing the parameter values, then continue to Step 6 to set the parameter values for the Default Group.
To change the logging parameter values only for future Oracle Fusion Global Payroll processes that are submitted using Oracle Enterprise Scheduler and that are submitted for a particular existing configuration group that is not the Default Group, then skip to Step 7 to set the parameter values for the configuration group that is selected.
To create a new configuration group specifically to use for this troubleshooting process, then skip to Step 8 to create the group and set its logging parameter values.
Complete the following substeps to change the logging parameter values for the Default Group.
As soon as the changes are made, the new settings automatically take effect for Oracle Fusion Global Payroll processes that are submitted using Oracle Enterprise Scheduler without a specific configuration group being specified.
Click the Default Group tab.
In the Parameter Name column of the table, look for the following words:
Logging Category Detailed information that is used for investigating problems. Default: no logging.
If those words are not present, continue to substep 6.c.
If those words are present, skip to substep 6.g.
To add the parameter, click the Create icon to display the Add Parameter dialog.
From the Parameter Name dropdown list, select Logging Category Detailed information that is used for investigating problems. Default: no logging.
In the Default Value field, enter the parameter values that were noted in Step 1, as a continuous string of characters, in any order. Do not use spaces or other characters as delimiters between parameter values.
Click Save and Close, and then skip to substep 6.j.
To edit an existing Logging Category Detailed information that is used for investigating problems. Default: no logging parameter, select it in the table and click the Edit icon to display the Edit Parameters dialog.
In the Default Value field, enter the parameter values that were noted in Step 1, as a continuous string of characters, in any order. Do not use spaces or other characters as delimiters between parameter values.
Click Save and Close.
Click Done.
Skip to Step 9.
To change the logging parameter values only for future Oracle Fusion Global Payroll processes that are submitted using Oracle Enterprise Scheduler and that are submitted for a particular existing configuration group that is not the Default Group, complete the following substeps.
In the Manage Payroll Process Configuration screen, click the Group Overrides tab.
In the Configuration Groups panel, select the configuration group for which there is a need to change logging parameter values.
In the Configuration Group Details: panel, select the Logging Category Detailed information that is used for investigating problems. Default: no logging parameter and click the Edit icon to display the Edit Parameters dialog.
In the Override Value field, enter the parameter values that were noted in Step 1, as a continuous string of characters, in any order. Do not use spaces or other characters as delimiters between parameter values.
Click Save and Close.
Click Save.
Skip to Step 9.
To create a new configuration group and set its logging parameter values, complete the following substeps.
In the Manage Payroll Process Configuration screen, click the Group Overrides tab.
In the Configuration Groups panel, click the Create icon to display the Create Configuration Group dialog.
In the Name field, enter a name of your own choosing for the new configuration group.
Click Save and Close to return to the Group Overrides tab of the Manage Payroll Process Configuration screen.
In the Configuration Groups panel, select the configuration group that was just created.
In the Configuration Group Details: panel, select the Logging Category Detailed information that is used for investigating problems. Default: no logging parameter and click the Edit icon to display the Edit Parameters dialog box.
In the Override Value field, enter the parameter values that were noted in Step 1, as a continuous string of characters, in any order. Do not use spaces or other characters as delimiters between parameter values.
Click Save and Close.
Click Save.
Continue to Step 9.
Complete the following substeps to execute the payroll run or other Oracle Fusion Global Payroll process for which the logged information is needed, using the configuration group that has the desired logging parameter values.
Depending on the payroll size and the type of problem being resolved, Oracle Support may recommend to run one or more Oracle Fusion Global Payroll processes for all employees who are listed on the payroll, or to place only a small number of employees in the payroll relationship group for which log entries will be collected. When practical, running the process for a small number of employees helps to optimize the troubleshooting process and manage the amount disk space used by the logged information.
Sign in to the Oracle Fusion Global Payroll application using the account that was previously used for running the job in which the problem occurred.
From the Payroll section of the Navigator menu, choose Payroll Calculations.
In the Payroll Flows section of the Tasks panel, click Submit a Process or Report.
From the Legislative Data Group dropdown list in the Submit a Process or Report: Select Flow Pattern screen, select the appropriate value for the job that is about to be run.
In the Process or Report table, select the Flow Pattern for the job, such as Calculate Payroll.
Click Next to display the Submit a Process or Report: Enter Parameters screen.
In the Parameter Details panel, click the Search icon to the right of the Process Configuration Group field to display the Search and Select dialog.
Click Search to display a list of available Process Configuration Group values.
Select the Process Configuration Group value that has the logging parameter values to be used.
Enter any other appropriate parameters for the job, and complete the process of submitting the job as it would usually be done.
Make a note of the ProcessId value for each process being executed.
The ProcessId value might be useful when there is a need to view the logged results.
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 to use the logging functionality for these areas only when troubleshooting an existing problem.
To configure Oracle Fusion Incentive Compensation batch jobs to write nonstandard log entries, perform the following steps:
Navigate to the Setup and Maintenance work area.
In the Implementations section of the Tasks pane, click Manage Implementation Projects.
In the Manage Implementation Projects pane, use standard Oracle search techniques to locate the implementation project that includes Oracle Fusion Incentive Compensation, then click the project name in the search results.
In the Tasks Lists and Tasks table, expand the Incentive Compensation folder.
Expand the Define Incentive Compensation folder.
Expand the Define Incentive Compensation Shared Configuration folder.
Locate the Manage Incentive Compensation Profile Values row of the table and click the Go to Task icon.
In the Search: Profile Option pane of the Manage Incentive Compensation Profile Values screen, select Incentive Compensation from the Application dropdown list and click Search.
In the Search Results table, locate and select the row for the CN_DEBUG profile option.
Scroll down and inspect the CN_DEBUG: Profile Values table to determine whether it contains a record for the Profile Level and Level Value for which log entries need to be collected. If so, then select the record and click Edit; otherwise, click New, and then enter the appropriate values, as follows:
To collect log entries for a specific user's Oracle Fusion Incentive Compensation batch jobs, then edit or create a record in which Profile Level is set to User, User Name is set to the user name of the specific user, and Profile Value is set to Yes.
To collect log entries for all of the Oracle Fusion Incentive Compensation batch jobs at the site, then edit or create a record in which Profile Level is set to Site, and Profile Value is set to Yes.
Click Save or Save and Close.
Start a new user session of Oracle Fusion Incentive Compensation and try to replicate the problem.
For information about viewing the special lab output, see the View Special Log Output for Oracle Fusion Incentive Compensation section.
After enabling the non-standard logging functionality for Oracle Fusion Incentive Compensation and attempt to replicate the problem that is being resolved, perform some database queries to view the resulting log entries. For these queries, specify the name of the Oracle Fusion Incentive Compensation process that were ran when attempting to replicate the reported problem. The process names that can use in the query are as follows:
CALCULATION MAIN PROCESS
CLASSIFICATION
COLLECT_STATISTICS
Crediting
GEN_RULE_ENGINE
GET_WINNERS
PopulateSrpBatches
PopulateSrpTables
REVERT TRANSACTIONS
ROLLUP
Rollup within Crediting
These process names are case-sensitive. For more information about how Oracle Fusion Incentive Compensation processes operate, see the product-specific documentation in Oracle Fusion Applications Help.
To view special log entries for Oracle Fusion Incentive Compensation batch jobs, perform the following steps:
Use a SQL client to connect to Oracle Database and log in as a user that has permission to view the Fusion database schema.
Execute the following SQL command, replacing process_name with the name of the Oracle Fusion Incentive Compensation process that were ran when attempting to replicate the reported problem:
select process_audit_id from cn_process_audits_all
where process_type = process_name
order by creation_date desc;
Make a note of the process audit ID that is returned in the first row of the output.
Execute the following SQL command, replacing selected_process_audit_ID with the value that was noted in Step 3.
select message_type, message_text from cn_process_audit_lines_all
where process_audit_id = selected_process_audit_ID
order by process_audit_line_id asc;
If it has not been done yet, place the output of Step 4 in a file that can be inspected with a text editor or send to Oracle Support if requested.
When finishing gathering log entries, reset the value of the CN_DEBUG profile option setting to N.
For information about setting the value of the CN_DEBUG profile option, see the Configure Non-Standard Log Levels for Oracle Fusion Incentive Compensation section.
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.
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.
To configure the Oracle Fusion General Ledger application to write nonstandard log entries:
Use the following substeps to navigate to the Manage Administrator Profile Values screen:
From the Tools section of the Navigator menu, choose Setup and Maintenance.
In the Overview screen that appears, click the All Tasks tab.
In the Match field of the Search panel, select All.
In the Search field, select Task Lists and Tasks.
In the Name field, enter Manage Administrator Profile Values.
Click Search.
In the Search Results panel, click the Go to Task icon for Manage Administrator Profile Values.
From the Application dropdown list in the Search: Profile Option pane, select General Ledger.
In the Profile Display Name field, enter %Debug% and click Search.
In the Search Results table, select GL_DEBUG_MODE.
If the GL_DEBUG_MODE: Profile Values table contains a record for the Profile Level and Level Value for which you want to collect log entries, then select the record and click Edit; otherwise, click New.
Fill in the appropriate values, as follows:
If you want to collect log entries for a specific user's Oracle Fusion General Ledger batch jobs, then edit or create a record in which Profile Level is set to User, and Level Value is set to the user name of the specific user. Set Profile Value to Yes.
If you want to collect log entries for all of the Oracle Fusion General Ledger batch jobs at the site, then edit or create a record in which Profile Level is set to Site, and Level Value is blank. Set Profile Value to Yes.
Click Save.
Ask an appropriate user to start a new user session of Oracle Fusion General Ledger and try to replicate the problem.
Inspect the relevant log file for new entries.
If the value of the AFLOG_FILENAME profile option is set, then the value of the AFLOG_FILENAME profile option indicates the location of the log file.
If the value of the AFLOG_FILENAME profile option is not set, then the information is logged to the location designated for Oracle Enterprise Scheduler log files. 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 Administering Oracle Fusion Middleware.
To help manage the amount of disk space used by the logged information, set the value of GL_DEBUG_MODE to No or delete any row of the GL_DEBUG_MODE: Profile Values table that you no longer need.
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 for each business unit. The information is placed in the standard log file for Oracle Enterprise Scheduler.
For optimum performance and log file sizes, it is recommended to 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.
The available values for the Log File Message Level setting are the integers 0 through 5. The value of 0 is recommended for day-to-day business needs. The value of 5 provides the maximum amount of information for troubleshooting.
Specifically, if the Log File Message Level setting is set to a value of 0, the following kinds of information are logged:
Product version
Program name
AutoInvoice start time
AutoInvoice concurrent request arguments
Error and warning Messages
AutoInvoice End Time
AutoInvoice logical steps
If the Log File Message Level setting is set to a value of 1, then the following additional information is gathered:
Time-stamped function labels
If the Log File Message Level setting is set to a value of 2, then the following additional information is gathered:
Sizes of allocated arrays
Dynamic SQL statements
Number of rows updated, inserted and deleted
If the Log File Message Level setting is set to a value of 3, then the following additional information is gathered:
Method IV SQL array values
If the Log File Message Level setting is set to a value of 4, then the following additional information is gathered:
Values of all variables that are used to call FND or tax routines
If the Log File Message Level setting is set to a value of 5, then the following additional information is gathered:
Bad lines
Rejected lines
To change the amount of information that the Oracle Fusion Receivables application logs for the AutoInvoice functionality area in the current business unit:
In the Oracle Fusion Receivables application, select 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.
On the All Tasks tab, expand the Search 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 dropdown list, enter the name of the business unit that is being resolved, and then click Search.
Alternately, to display a list of the business units to choose from, click Search without specifying a business unit name.
In the Search Results table, click the name of the business unit that is being resolved.
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 that corresponds to the amount of information that needs to gathered.
For example, to gather the maximum amount of information for troubleshooting, set the value to 5. To gather the normal amount of information for day-to-day operations, set the value to 0.
Click Save or Save and Close to put the change into effect.
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 Administering Oracle Fusion Middleware Guide.
After gathering the detailed information that is needed, remember to repeat this procedure and return the Log File Message Level setting to the value that meets your day-to-day information needs.
The logging functionality for the application user session (ApplSession) component is different from the standard logging functionality for Oracle Fusion Applications.
The ApplSession component uses Oracle Fusion Middleware logging functionality, which allows the adjustment of the amount of detail to log for the component without requiring a server restart. Also, now it is possible to use Oracle Enterprise Manager to view ApplSession log messages. For more information about Oracle Fusion Middleware logging functionality, see the Managing Log Files and Diagnostic Data section of the Administering Oracle Fusion Middleware Guide.
By default, the ApplSession component records messages at the WARNING level. If there is a need to log additional details about ApplSession operations as part of troubleshooting, then it is possible to use Oracle Enterprise Manager Fusion Applications Control to adjust the amount of information that ApplSession gathers for a particular Managed Server.
To use Fusion Applications Control to adjust the amount of ApplSession information to be logged for troubleshooting, perform the following steps:
Occasionally, a situation in which one of the Oracle Fusion applications repeatedly logs the same error message may be encountered. In this situation, it is best to find and correct the cause of the error. However, on rare occasions, Oracle Support may recommend to use the FND_MESSAGES.LOGGABLE_ALERTABLE attribute to prevent the repeating message from being logged while efforts are underway to resolve the issue.
Caution:
Do not change the FND_MESSAGES.LOGGABLE_ALERTABLE attribute unless Oracle specifically advises to do so, because this involves permanent loss of data.
Do not change the FND_MESSAGES.LOGGABLE_ALERTABLE attribute directly in the database. Instead, use the Manage Messages task flow.
To disable logging for a particular message, perform the following steps:
Choose Setup and Maintenance from the Navigator menu.
Complete the following substeps to navigate to the Manage Messages screen.
On the All Tasks tab, make sure the Search pane is expanded.
In the Search pane, enter Manage Messages in the Name field.
Click Search.
In the Manage Messages row of the Search Results table, click Go to Task.
In the Message Name field in the Search pane, enter the name of the error message that needs to temporarily stop logging.
Select the relevant Oracle Fusion application from the Application dropdown list.
If it is known, then select the relevant code module name from the Module dropdown list.
Click Search.
Complete the following substeps to set the value of the FND_MESSAGES.LOGGABLE_ALERTABLE attribute to N for the error message that needs to temporarily stop logging:
In the search results table, select the error message that needs to temporarily stop logging.
Click the edit icon in the table header.
In the Edit Message screen, clear the Logging Enabled checkbox.
Click Save, Save and Create Another, or Save and Close to put the change into effect immediately.
Sometimes, as part of the process of troubleshooting Oracle Fusion Applications, it may be needed to find all of the log entries that result from a particular action. If the action involves multiple Oracle Fusion applications or multiple Oracle Fusion Middleware components, then the log entries are placed in multiple log files. It is possible to use certain values related to the particular action to locate the relevant log messages in those log files.
It is possible use a particular action's Execution Context Identifier (ECID) and Relationship Identifier (RID) values to locate the log entries that result from that action.
A unique ECID value is assigned to each user request. However, depending on what is involved in the request, a log entry that is related to that request may have the original ECID of the request, or a different ECID of a child process spawned by the original request. For example, if a job is submitted to Oracle Enterprise Scheduler, the request to schedule the job and the job, itself, always have different ECIDs.
For a particular ECID, if the request requires processing by multiple components, by multiple modules within a component, or by using multiple threads, then a unique RID value may be assigned when the work passes to a new thread or process.
In log entries, the ECID and RID values are typically separated by a comma. ECID values can include alphanumeric characters, colons, periods, and hyphens. RID values can include numerals and colons. The RID value indicates the relationship of the current thread or process to its creator. The first RID created for a request is RID = 0. Each shift in generation is represented by a colon. For example, the RID value for the seventh child process of the third child process of the root context for a request is represented as 0:3:7.
When a job is submitted to Oracle Enterprise Scheduler, the request to schedule the job and the job, itself, always have different Execution Context Identifiers (ECIDs).
The ECID for the job-scheduling request is displayed in the requesting user session at the time when the job is submitted. However, the ECID of the Oracle Enterprise Scheduler job, itself, is not assigned until the job starts, and it is not displayed in the requesting user session. To locate log entries related to the Oracle Enterprise Scheduler job, itself, use the job Request ID value.
To correlate log messages for Oracle Enterprise Scheduler jobs using Fusion Applications Control, perform the following steps:
In the navigation pane, expand the Farm listing, then expand Scheduling Services, and then determine whether Scheduling Services contains Oracle Enterprise Scheduler clusters that contain individual Oracle Enterprise Scheduler servers or individual Oracle Enterprise Scheduler servers without clusters.
To open the ESSAPP deployment administration page, click the listing for an Oracle Enterprise Scheduler cluster such as ESSAPP (ESSCluster), if one is available, or an individual Oracle Enterprise Scheduler server such as ESSAPP (ess_server1).
If it is possible to select a cluster, then that will allow the search of all servers in the cluster simultaneously. This is an advantage because each job request is logged only on the Oracle Enterprise Scheduler server where that request is processed.
If the job request for the action that is being resolved appears in the list of Top 10 Running Job Requests, then click its Request ID link to display the request details, then skip to Step 8.
In the context pane, from the dynamic Scheduling Service Group or Scheduling Service target menu, choose Job Requests, then Search Job Request.
Use standard search techniques to locate the job request for the action that is being resolved.
For information about searching Oracle Enterprise Scheduler job requests, see Search for Job Requests.
In the search results, make a note of the Request ID value for the job of interest.
In the search results, click the Request ID link to display the request details.
In the Request Details pane, select Request Log rom the Action dropdown list.
The Log Messages page displays all the log messages for the ECID associated with the selected job request.
Click any Log File link to display a list of the related log messages in the View Log Messages page.
At this point, it is possible to inspect the log messages on the screen or download the log file and search it for all messages containing the relevant ECID.
If the log level for a job request is set to FINER or FINEST when the job runs, then the diagnostic log entries for the job request are written to the log file specified by the AFLOG_FILENAME profile option and to the request log file that is available to the user who submitted the job request.
If there is a need to correlate log messages that are related to SOA services or BPEL processes, then obtain the ECID by first locating the relevant SOA composite instance. To correlate log messages for SOA Services or BPEL processes using Fusion Applications Control, perform the following steps:
In the navigation pane, expand the Farm listing, then expand the SOA listing, the soa_infra listing, and then select default.
In either pane, click the SOA composite instance name for which log entries need to be located.
Make sure that your browser is set to allow the display of pop-up windows.
For example, in Firefox, choose Options, then Content from the Tools menu and either make sure that the Block pop-up windows checkbox is cleared or add any relevant hosts to Exceptions.
Similarly, in Internet Explorer, choose Pop-up Blocker, then Turn Off Pop-up Blocker from the Tools menu.
In the Recent Instances table, click the relevant Instance ID link to display the Flow Trace pop-up window.
The Execution Context Identifier (ECID) is displayed in the upper right corner of the window.
Make a note of the ECID value and close the Flow Trace pop-up window.
To view the relevant log entries using Fusion Applications Control, complete the following substeps. To view the log entries using the Oracle WebLogic Scripting Tool (WLST), skip to Step 7.
In the navigation pane, select an appropriate target.
From the dynamic target menu, choose Logs, then View Log Messages.
On the Log Messages page, in the Search area, click Add Field.
In the pop-up list, select the ECID checkbox and click Add.
Enter the ECID value in the ECID field.
Adjust the other search field values appropriately and click Search.
It is possible to leave search fields blank; blank fields are not used as search criteria.
Skip Step 7.
In the Oracle WebLogic Scripting Tool (WLST), enter a command similar to the following example, but substitute the ECID value that was previously noted.
displayLogs(ecid='0000Hl9TwKUCslT6uBi8UH18lkWX000002')
Many operations within Oracle Fusion applications do not use Oracle Enterprise Scheduler, SOA services, or BPEL processes. For these operations, it is possible to correlate log entries using the Execution Context Identifier (ECID). To locate log entries that result from one particular Oracle Fusion application action that does not use Oracle Enterprise Scheduler, SOA services, or BPEL processes, perform the following steps:
For more information about using ECIDs and RIDs to correlate log entries, see the Correlating Messages Across Log Files and Components section in the Administering Oracle Fusion Middleware.
As part of the process of troubleshooting Oracle Fusion Applications problems, an Oracle Support representative may request a copy of a particular log file. It is possible to add downloaded log files to incidents to package those log files with incident information that is sent to Oracle Support.
For more information about using Support Workbench to package incidents along with external files such as log files, see Package Oracle Fusion Applications Incidents Using General Support Workbench Functionality.
To download an Oracle Fusion Applications log file using Fusion Applications Control, perform the following steps:
By default, the QuickTrace (in-memory logging) feature of Oracle Fusion Applications continuously records a specified level of log detail in an area of memory, generally at a more granular level of detail than is recorded in Oracle Fusion application log files. The memory that QuickTrace uses is recycled on an ongoing basis, with the oldest information being overwritten first.
Since QuickTrace does not format information and it 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.
The same commands in Oracle Fusion Applications code cause messages to be logged both in Oracle Fusion application diagnostic log files and in QuickTrace dumps. However, your system may gather different amounts of detail for the two kinds of output. At default setting levels, QuickTrace stores much more detailed information than diagnostic log files do.
It is possible to create QuickTrace dumps manually and to adjust the amount of detail that QuickTrace records.
Oracle Support may occasionally request a manual dump of QuickTrace buffers to be performed as part of work to resolve a problem that did not generate an incident automatically. To create a QuickTrace dump manually, perform the following steps:
By default, QuickTrace functionality for Oracle Fusion Applications is enabled at the FINE logging level. QuickTrace should ordinarily remain enabled. However, if Oracle Support gives the instruction to disable QuickTrace, or if there is a need to change the amount or organization of the information that QuickTrace collects, it is possible to adjust the values of the following profile options either by using Fusion Applications Control or by using the Manage Administrator Profile Values task in the Setup and Maintenance work area:
QuickTrace Enabled (AFLOG_QUICKTRACE_ENABLED profile option): Governs whether QuickTrace gathers any information
QuickTrace Level (AFLOG_QUICKTRACE_LEVEL profile option): Specifies the level of detail at which QuickTrace gathers information
Because the QuickTrace Enabled and QuickTrace Level profile options apply at the site level, either all of the site's Managed Servers capture QuickTrace information in memory buffers or none of the Managed Servers do so. Similarly, the QuickTrace Level value sets the level of detail that QuickTrace gathers for all of the site's Managed Servers.
For more information about these settings, see Table 12-2.
Table 12-2 QuickTrace Profile Options
| Profile Option Name (and Display Names) | Environment | Description | Possible Values or Example | Applicable Profile Hierarchy Levels | Default Value |
|---|---|---|---|---|---|
|
(QuickTrace Enabled) |
Java and SOA |
Enables QuickTrace in-memory logging to occur at runtime. |
|
|
|
|
(QuickTrace Level) |
Java and SOA |
Specifies the minimum level for tracing. This setting is similar to theAFLOG_LEVEL profile option for standard Oracle Fusion Applications logging to log files, but the two settings operate independently. |
|
|
|
In some troubleshooting situations, it may be useful to locate or obtain Oracle Fusion Middleware diagnostic dumps such as Oracle WebLogic Server diagnostic images, Java Virtual Machine thread dumps, and Dynamic Monitoring Service metric dumps.
Oracle Fusion Applications incidents that are generated from Java code (including SOA) automatically execute these kinds of dumps and include the results in the incident data. Oracle Fusion Middleware diagnostic dumps are not available for Oracle Fusion Applications incidents that are generated from PL/SQL or C code.
When troubleshooting an Oracle Fusion Applications problem that did not generate an incident automatically, it is recommended to create an incident manually, then execute diagnostic dumps manually, and examine the dump files for information that may assist in resolving the problem. If there is a need to work with Oracle Support to resolve the problem, it is recommended to include manually executed dump results in the incident data package sent to Oracle for review. For information about how to list available diagnostic dumps, view dump descriptions, and manually execute selected dumps for Oracle Fusion Middleware, see the Working with Diagnostic Dumps section in Administering Oracle Fusion Middleware Guide.
Use Support Workbench to package the problem or incident along with all relevant dump files and diagnostic test reports.
File the Service Request and transmit the package to Oracle Support.
If there is an issue with your Oracle Fusion applications and there is a need to gather data about it, and if the system has not created an incident and problem for it automatically, then it is recommended to create an incident for it.
It is recommended to use Support Workbench to work with incidents. For more information about using Support Workbench to create incidents manually, see the Create Incidents Manually section. The process of manually creating an incident using Support Workbench automatically creates an associated problem listing.
To use Support Workbench with Oracle Fusion Applications, obtain and install Cloud Control.
As part of creating and packaging incidents using Support Workbench, supply credentials both to connect to the Oracle WebLogic Server on which the relevant Oracle Fusion application is running and to connect to the host machine on which that Oracle WebLogic Server is running.
Various kinds of incidents can be packaged in Support Workbench. For Oracle Fusion Applications performance incidents, in particular, it is recommended to use the wizard that is specifically designed for packaging Oracle Fusion Applications incidents, because that wizard simplifies the process of gathering the information that Oracle Support is likely to need when working on the problem. However, it is also possible to use general Support Workbench functionality to package Oracle Fusion Applications incidents.
It is recommended to package Oracle Fusion Applications performance incidents using the special Support Workbench wizard for this incident type. The wizard provides a convenient way to include various file types that Oracle Support may need to resolve the problem.
To use the wizard for packaging Oracle Fusion Applications performance incidents, the relevant incident must already exist. To create an incident manually, see Create Incidents Manually.
When planning to package an Oracle Fusion Applications incident, it is recommended to perform the following actions before beginning the process of packaging the incident:
Use the Oracle Fusion Applications Diagnostic Dashboard application (Diagnostic Dashboard) to perform any diagnostic tests that are specific to that Oracle Fusion application and that are relevant for the selected incident. For more information, see the Run and Work with Diagnostic Tests Manually section.
Associate the diagnostic test results with the selected incident. For more information, see the Send Diagnostic Test Results to Oracle Support section.
The packaging procedure does not automatically include the results of manually run Oracle Fusion Applications diagnostic tests unless those results are already associated with the incident being packaged.
To package incidents using the Support Workbench wizard for Oracle Fusion Applications incidents, perform the following steps:
If it has not been done yet, in Cloud Control, select a target that is associated with the problem or incident that need to be packaged. Choose one of the following target types:
An Oracle Fusion Applications instance target
An Oracle Fusion Applications product family target
An Oracle Fusion Applications cluster application target
The Support Workbench wizard for Oracle Fusion Applications incidents is unavailable when an Oracle Fusion application instance (J2EE Fusion Application) target is selected.
From the dynamic dropdown menu, choose Diagnostics, then Support Workbench.
In the Support Workbench rollup page for your target, scroll down until the Problem Summary table is visible, and then select the problem that is associated with the incident to be packaged.
Click Create Package.
In the Host Credentials area of the Create Package: Credentials page, use one of the following methods to select credentials for connecting to the machine that hosts the Oracle WebLogic Server on which the Oracle Fusion application was running when the problem or incident occurred.
If appropriate credentials were saved as preferred credentials, then select Preferred in the Credential field.
If appropriate credentials were saved as named credentials, then select Named in the Credential field, and then select the specific credentials from the Credential Name dropdown list.
If appropriate credentials were not set, then select New in the Credential field, and then complete the following substeps:
In the UserName and Password fields, enter credential values for connecting to the host machine.
Inspect the default credential name supplied by Support Workbench in the Save As field, and modify the credential name if preferred.
For the entered credentials to be the preferred credentials for the Oracle WebLogic Server, select the Set as Preferred Credentials checkbox.
To verify that the entered credentials work correctly, click Test.
In the WebLogic Server Credentials area of the Create Package: Credentials page, use one of the following methods to select credentials for connecting to the Oracle WebLogic Server where the Oracle Fusion application was running when the problem or incident occurred.
If a WebLogic Server Credentials area is not visible on the page, it indicates that the relevant Oracle WebLogic Server is currently unavailable. Some operations cannot be done when the server is unavailable, such as creating user-reported problems and performing additional diagnostic dumps. For information about restarting an Oracle WebLogic Server, see the Starting and Stopping Servers section in Administering Server Startup and Shutdown for Oracle WebLogic Server Guide.
If credentials were saved as preferred credentials, then select Preferred in the Credential field.
If credentials were saved as named credentials, then select Named in the Credential field, and then select the specific credentials from the Credential Name dropdown list.
If credentials were not set, then select New in the Credential field, and then complete the following substeps:
In the UserName and Password fields, enter credential values for connecting to the Oracle WebLogic Server.
Inspect the default credential name supplied by Support Workbench in the Save As field, and modify the credential name if preferred.
For the credentials entered to be the preferred credentials for the Oracle WebLogic Server, select the Set as Preferred Credentials checkbox.
Click Next.
In the Create Package: Package Details page, specify the a name and description for the package being created, select the incidents to include in the package, and then click Next.
In the Create Package: Dumps page, select various kinds of dump files to add to the package and then click Next.
Unless Oracle Support has given other instructions, it is recommended to select all of the types of dump fields that are listed on the page. If Heap Dumps is selected, supply relevant file names and locations. If AWR Reports is selected specify the name of the relevant database instance and credentials for working with that database.
In the Create Package: Review page, decide whether to customize the package:
On the Customize Package: PackageName page, review the current contents of the package, decide how to customize the package, and use the tabs, buttons, and links on the page to make the desired changes.
For more information about the settings and controls on this page, see the Customize Package Page topic in the Cloud Control online help.
For more information about customizing actions that start on this page but complete on other pages, see any of the following Cloud Control online help topics of interest:
Add Incidents Page
Add Problems to Package Page
Exclude Problems Page
Package Manifest Page
Additional Dumps and Test Cases Page
Add External Files Page
Copy Out Files Page
Copy In Files Page
After making the desired changes, click the Finish Contents Preparation link in the Packaging Tasks area of the page.
After a short wait, the page displays information about any additional relevant files that were added automatically.
In the Packaging Tasks area of the page, click the Generate Upload File link.
On the Generate Upload File: PackageName page, select whether the upload file should contain the entire contents of the package or only an incremental addition made since the last upload file was generated.
For more information about the settings on this page, see the topic Generate Upload File Page in the Cloud Control online help.
On the same page, specify whether to generate the package immediately or at a specified later time, and then click Submit.
It may take several minutes to generate the upload file. When the process is complete, a confirmation message is displayed. Click OK to dismiss it.
On the Customize Package: PackageName page, click either the Send Upload Files link or the Send to Oracle button in the Packaging Tasks area of the page.
On the Send to Oracle page, supply the necessary credentials for logging in to My Oracle Support, make sure that the package to be uploaded is selected, and specify whether to send the package immediately or at a specified later time.
For more information about the settings on this page, see the topic Send to Oracle Page in the Cloud Control online help.
When with the composition of the package is fine and the details for sending it to Oracle Support, click Submit.
After a brief wait, Support Workbench displays a message about whether the selected package was sent to Oracle successfully.
If the attempt to send the package was not successful, address any problem that the message describes, then try to send the package again.
If the Oracle Fusion Applications environment includes Cloud Control, then it is recommended to package Oracle Fusion Applications performance incidents using the special Support Workbench wizard for that incident type, as described in Package Oracle Fusion Applications Incidents Using a Wizard. For Oracle Fusion Applications incidents that do not concern performance, it is possible to use general Support Workbench functionality to package Oracle Fusion Applications incidents.
When planning to package an Oracle Fusion Applications incident, it is recommended to perform the following actions before beginning the process of packaging the incident:
If no incident exists for the issue being investigated, then create one manually. For more information, see Create Incidents Manually.
Use Diagnostic Dashboard to perform any diagnostic tests that are specific to that Oracle Fusion application and that are relevant for the selected incident. For more information, see Run and Work with Diagnostic Tests Manually.
Associate the diagnostic test results with the selected incident. For more information, see Send Diagnostic Test Results to Oracle Support.
The packaging procedure does not automatically include the results of manually run Oracle Fusion Applications diagnostic tests unless those results are already associated with the incident being packaged.
To package incidents using general Support Workbench functionality, perform the following steps:
In Cloud Control, if the J2EE Fusion Application target that is associated with the problem or incident that needs to be packaged has not been yet selected , then select that target and skip to Step 2.
If the J2EE Fusion Application target that is associated with the problem has been selected and work with Support Workbench has started, then complete the following substeps:
Navigate to either the applicable Problem Details page or the Support Workbench rollup page that summarizes the problems that are related to the target.
If you navigated to the Support Workbench rollup page, then skip to Step 6; otherwise, continue to the following substep.
If you navigated to the applicable Problem Details page, then click either Quick Package or the Package the Problem link in the Investigate and Resolve area of the page.
For more information about the Quick Package button and the Package the Problem link, see topic Problem Details Page in the Cloud Control online help.
If the Package the Problem link was clicked, then skip to Step 9; otherwise, continue to the following substep.
If Quick Package was clicked, then skip to Step 10.
From the dynamic dropdown menu, choose Diagnostics, then Support Workbench.
In the Host Credentials area of the page, use one of the following methods to select credentials for connecting to the machine that hosts the Oracle WebLogic Server on which the Oracle Fusion application was running when the incident or issue occurred.
If appropriate credentials were saved as preferred credentials, then select Preferred in the Credential field.
If appropriate credentials were saved as named credentials, then select Named in the Credential field and then select the specific credentials from the Credential Name dropdown list.
If appropriate credentials were not set, then select New in the Credential field and complete the following substeps:
In the UserName and Password fields, enter credential values for connecting to the host machine.
Inspect the default credential name supplied by Support Workbench in the Save As field, and modify the credential name if that is preferred.
If there is a need for the credentials being entered to be the preferred credentials for the relevant host, then select the Set as Preferred Credentials checkbox.
If there is a need to verify that the credentials that were entered work correctly, then click Test.
In the WebLogic Server Credentials area of the page, use one of the following methods to select credentials for connecting to the Oracle WebLogic Server where the Oracle Fusion application was running when the problem or incident occurred.
If a WebLogic Server Credentials area is not visible on the page, then that indicates that the relevant Oracle WebLogic Server is unavailable. Some operations cannot be done when the server is unavailable, such as creating user-reported problems and performing additional diagnostic dumps. For information about restarting an Oracle WebLogic Server, see the Starting and Stopping Servers section in Administering Server Startup and Shutdown for Oracle WebLogic Server Guide.
If credentials were saved as preferred credentials, then select Preferred in the Credential field.
If credentials were saved as named credentials, then select Named in the Credential field and then select the specific credentials from the Credential Name dropdown list.
If credentials were not set, then select New in the Credential field and complete the following substeps:
In the UserName and Password fields, enter credential values for connecting to the Oracle WebLogic Server.
Inspect the default credential name supplied by Support Workbench in the Save As field, and modify the credential name if that is preferred.
If there is a need for the credentials being entered to be the preferred credentials, select the Set as Preferred Credentials checkbox.
Click Continue.
A Support Workbench page that summarizes problems related to your target now appears.
Click the Problems tab and select the relevant time period from the View dropdown list.
In the table that lists problems, select the checkbox for one or more relevant problems.
Click Package.
On the Package: Select Packaging Mode page, select the mode of packaging to be used, and then click Continue.
If multiple problems were selected in Step 7, then select the Custom Packaging mode at this point.
For more information about packaging modes, see topic Package Page in the Cloud Control online help.
If Quick Packaging was selected, then continue to Step 10.
If Custom Packaging was selected, then skip to Step 15.
On the Quick Packaging: Create New Package page, supply information about the name and description for the package, indicate whether there is a need for the package to be sent to Oracle Support automatically, and then click Next.
For more information about the fields on this page, see topic Quick Packaging Wizard in the Cloud Control online help.
On the Quick Packaging: View Contents page, review the information about the incidents that will be included in the package, and click Next when satisfied.
On the Quick Packaging: View Manifest page, it is possible to review information about the specific files to be included in the package. Click Next when ready to go to the next step in the packaging process.
On the Quick Packaging: Schedule page, specify whether to generate the package immediately or at a specified later time.
If, earlier, it was selected to send the package to Oracle Support automatically, then the timing specified for generating the package also applies to sending the package.
For more information about the fields on this page, see topic Quick Packaging Wizard in the Cloud Control online help.
When satisfied with the composition of the package, click Submit.
If Quick Packaging was selected in Step 9, skip the remaining steps of this procedure.
If Custom Packaging was selected in Step 9, on the Custom Packaging: Select Package page, then either select an existing package to modify, or supply information about the name and description for a new package, and then click OK.
For more information about the settings on this page, see topic Custom Packaging Page in the Cloud Control online help.
After a short wait, the page displays a message confirming either that the selected problem was added to an existing package, or that a new package was created.
On the Customize Package: PackageName page, review the current contents of the package, decide how to customize the package, and use the tabs, buttons, and links on the page to make the desired changes.
For more information about the settings and controls on this page, see topic Customize Package Page in the Cloud Control online help.
For more information about customizing actions started on this page but complete on other pages, see any of the following Cloud Control online help topics of interest:
Add Incidents Page
Add Problems to Package Page
Exclude Problems Page
Package Manifest Page
Additional Dumps and Test Cases Page
Add External Files Page
Copy Out Files Page
Copy In Files Page
After making the desired changes, click the Finish Contents Preparation link in the Packaging Tasks area of the page.
After a short wait, the page displays information about any additional relevant files that were added automatically.
In the Packaging Tasks area of the page, click the Generate Upload File link.
On the Generate Upload File: PackageName page, select whether the upload file should contain the entire contents of the package or only an incremental addition made since the last upload file was generated.
For more information about the settings on this page, see the topic Generate Upload File Page in the Cloud Control online help.
On the same page, specify whether to generate the package immediately or at a specified later time, and then click Submit.
It may take several minutes to generate the upload file. When the process is complete, a confirmation message is displayed. Click OK to dismiss it.
On the Customize Package: PackageName page, click the Send Upload Files link in the Packaging Tasks area of the page.
On the Send to Oracle page, supply the necessary credentials for logging in to My Oracle Support, make sure that the package to be uploaded is selected, and specify whether to send the package immediately or at a specified later time.
For more information about the settings on this page, see the topic Send to Oracle Page in the Cloud Control online help.
When the composition of the package is fine and the details for sending it to Oracle Support, click Submit.
After a brief wait, Support Workbench displays a message about whether the selected package was sent to Oracle successfully.
If the attempt to send the package was not successful, then address any problem that the message describes, and then try to send the package again.
From time to time, a diagnostic test should be run manually and then the results of the test should be sent to Oracle Support. To accomplish this, attach the results of the test to the relevant incident before packaging the incident and sending the package to Oracle Support.
It is also possible to attach other types of files to incidents, such as log file excerpts or Readme.txt files containing information for Oracle Support. For more information about using Support Workbench to package incidents along with files such as log file excerpts or readme.txt files, see the Package Oracle Fusion Applications Incidents Using General Support Workbench Functionality section.
To attach diagnostic test results to an incident, perform the following steps:
If Oracle Support is contacted for assistance in resolving a problem, the support representative may request to gather more detailed log information on the operations of one or more specific code modules in your Oracle Fusion applications. To gather more detailed log information, set the value of the AFLOG_MODULE profile option to one or more module names that Oracle Support specifies.
Unless Oracle Support specifically advises changing the value of the AFLOG_MODULE profile option at the Site level, be sure to adjust the value only for a particular user who attempts to reproduce the problem that is being investigated. Specifying one or more particular modules at the Site level prevents logging on any modules that are not specified.
Oracle Fusion Applications seed data contains many diagnostic tests. Diagnostic tests that are supplied in seed data do not require registration.
However, if an Oracle Fusion application issue is reported to Oracle Support, additional diagnostic tests to help resolve the issue may be received. Depending on the exact circumstances, those diagnostic tests may or may not require registration. If registration is required for the additional diagnostic tests, Oracle will provide detailed registration instructions. Do not attempt to register diagnostic tests unless Oracle Support suggests it.