Introduction

When Support handles Service Requests (SRs), it is common to encounter cases where basic information is missing, or clarification is required to effectively address the reported issue.

In such instances, Support follows a structured process to clarify and validate the problem before proceeding with a resolution.

This blog will be specific to the Oracle Access Manager product, but parts of it can apply to an product or issue.

The goal of this blog is that after reading it, much of the information a Support Analyst would typically request can be provided when creating the SR, helping to reduce the time needed to resolve the issue.

Issue Categories

At the highest level the most common issues can be divided into 2 categories. The first is what is referred to a “How To” and the second is refer to as “Problem Solve”.

Common Issue Types

How to

 
  • Type of issue where a question is being asked

Problem Solve
  • Type of issue where the functionality is not working and potentially generates an error

Regardless of the issue type, the first step is to verify the OAM version and the patches that are installed. This can be done by checking the output of the OPatch lsinventory command, which provides both version and patch details. This information is crucial for identifying known issues, applying the right patches, or diagnosing new problems, as the product’s functionality depends on the version and patches applied.

Data Collection

Version and Patching Information

OAM Server

1. On the OAM server, prepare the command line session for data collection:

. setDomainEnv.sh

2. Collect the version and patch inventory details:
a. Navigate to the OPatch directory in the Middleware Home, then run the opatch lsinventory command to print the results to a text file. Note that the example below writes the opatch output to your home directory and names the file ‘opatch_<host>_YYYY-MM-DD.txt.

ORACLE_HOME=$MW_HOME
cd /$MW_HOME/OPatch
./opatch lsinventory > “${HOME}””/opatch_”${HOSTNAME%%.*}”_$(date +”%Y-%m-%d”).txt”

b.  In the OPatch directory in the Middleware Home run the below command which will get the latest/last opatch report from the cfgtoollogs/opatch/lsinv directory.

cp -p — $(ls -tr1d $MW_HOME/cfgtoollogs/opatch/opatch*.log 2>/dev/null | tail -1) $HOME

3. Upload the opatch file(s) to the SR when it is created.

WebGate Server (If applicable)

1. Navigate to the OPatch directory in the Middleware Home, then run the opatch lsinventory command to print the results to a text file. Note that the example below writes the opatch output to your home directory and names the file ‘opatch_<host>_YYYY-MM-DD.txt.

./opatch lsinventory > “${HOME}””/opatch_”${HOSTNAME%%.*}”_$(date +”%Y-%m-%d”)_WG.txt”

2. In the OPatch directory in the Middleware Home run the below command which will get the latest/last opatch report from the cfgtoollogs/opatch/lsinv directory.

./opatch lsinventory > “${HOME}””/opatch_”${HOSTNAME%%.*}”_$(date +”%Y-%m-%d”)_WG.txt”

3. Upload the opatch file(s) to the SR when it is created.

Specific To “How-To”

When submitting a Service Request (SR), it’s important to provide basic information related to the question. Ensure that it is clearly stated and includes as many relevant details as possible. In addition to the OPatch lsinventory information from the section titled “Collect The Version and Patching Information” provide the following:

  • What is the specific question?
  • If applicable:
    • What Oracle Documentation has been reviewed (include link)?
    • What KM notes have been reviewed?

Specific To “Problem Solve”

When submitting a Service Request (SR), it’s important to include key details about the issue or error. Providing as much relevant information as possible when creating the SR will help the Support analyst quickly understand the problem and the steps needed to reproduce it.

OPatch

Upload to the SR the OPatch lsinventory information from the section titled “Collect The Version and Patching Information”

General Questions

Provide the answers to the below questions:

  • Has this ever worked?
  • If yes, when did it stop?
  • Does issue occur for all users or just certain ones?
  • Does the issue occur for all protected resources or just certain ones?
  • Does it occur for all browser types?
  • What Oracle Documentation was followed?
  • What is the protected resource URL being called?

Clarification

Include the steps you followed, along with relevant screenshots, to help clarify the issue. For instance, if you’re experiencing a login problem:

  • Open a new browser session and turn on http headers.
  • Enter the URL that is being called…before pressing enter take a screen capture.
  • This should redirect you to a login page…take a screen capture.
  • Enter username/password…before pressing enter take a screen capture.
  • This should return you back to the requested resource. In your case it does not…take a screen capture.
  • Save the http headers to a file.
  • Zip the http headers and the screen captures that support the issue to a file called issue<date>.zip and upload.

Configuration Files

Upload the following configuration files:

  • oam-config.xml
    MW_HOME/user_projects/domains/DOMAIN_NAME/config/fmwconfig/oam-config.xml
    <INSTALL_LOCATION>/user_projects/domains/<DOMAIN_NAME>/config/fmwconfig/oam-config.xml
  • config.xml
  • MW_HOME/user_projects/domains/DOMAIN_NAME/config/config.xml
    <INSTALL_LOCATION>/user_projects/domains/<DOMAIN_NAME>/config/config.xml

Log files

Collect and upload the OAM Log files that encompass the last or most recent occurrence of the problem:

To collect the logs, identify the managed server(s) from OAM where the issue occurs. If the environment is clustered with multiple OAM nodes, it may be necessary to collect the logs from multiple managed servers to capture all related events. Calculate the time when the problem last occurred. The following shell commands will identify all server logs and out files updated in the last hour for oam_server1, collect them into an archive, and save the archive in your home directory. The zip file will be named “<managed_server_name>_logs_<hostname>_<date>.zip”

Change the duration and managed server name, as needed to collect logs for different durations or servers. Durations can be in minutes, hours, or days (ie. 3 days ago, 30 minutes ago)

duration=”1 hour ago”
mservername=”oam_server1″
find $DOMAIN_HOME/servers/$mservername/logs -newermt “${duration}” | xargs zip -j “${HOME}”/”${mservername}”_logs_”${HOSTNAME%%.*}”_$(date +”%Y-%m-%d”).zip

WebGate Specific Data

OPatch

OPatch lsinventory output– Provides version and patching information.  Helpful for pairing known issues and appropriate patches, or for defining new issues. This is detailed in the section titled “Collect The Version and Patching Information”.

Configuration File

<WEBGATE INSTANCE LOCATION>/webgate/logs/webgate.log and <WEBGATE INSTANCE LOCATION/webgate/config/ObAccessClient.xml

Log files

The WebGate log file location is determined by the WebGate type. The Webgate log file Name by default is (12c = webgate.log) (11g = oblog.log). The below examples reflect the OHS WebGate.

12c:
<OHS_DOMAIN_HOME>/servers/OHS_INSTANCE_NAME/logs

11g:
<ORACLE_OHS_INSTANCE>/diagnostics/logs/OHS/OHS_INSTANCE_NAME

Wrap up

To resolve issues more efficiently and provide the necessary information, follow these best practices: understand your environment, simplify it as much as possible while still replicating the issue, and enable logging and tracing to help identify the root cause of the problem.

No matter what your issue is at a minimum provide …

  • An OPatch lsinvnetory output
  • Information that helps clearly identifies and validate the issue