Finding File Versions in the Oracle Applications EBusiness Suite - Checking the $HEADER (文档 ID 858957.1)
In this Document
Goal
Solution
Diagnostic
Form Versions
... Form Versions: Help About
... Form Versions: OS/UNIX
... Form Versions: OS/UNIX Library
Java Versions
... Java Versions - Via Operating System:
... Java Versions - Via SQL:
... Java Versions - Via Application:
Report Versions
PL/SQL Packages
Definition Files
Languages
Patch Versions
... Patch Versions - Oracle Applications
... Patch Versions - Server/Database
APPLIES TO:
Oracle Inventory Management - Version: 11.5.10<max_ver> and later [Release: 11.5 and later ]
Information in this document applies to any platform.
This document includes all versions of Oracle EBS 11i and R12
GOAL
How to find file versions within Oracle Applicatins
SOLUTION
There are many ways to find file versions. This note will attempt to list some of the most common and benefits of each method listed.
Diagnostic
The quickest way to get versions is to find them all at once using a diagnostic. This is also great for providing information to Oracle Support to avoid providing one file version after another. The diagnostics often query information from the patching logs (AD... tables like AD_FILE_VERSIONS) described more below. The AppsCheck diagnostic is a great choice as it is available within the application as a concurrent program. It runs for a series of modules that the user selects and puts the information together in the same file. The AppsCheck is actually called the 'Diagnostics: Apps Check' concurrent program. Read more in Note 156860.1 Order Management Suite Diagnostic Tool (omcheck.sql) or Note 276207.1. Here is an example set of steps for submitting the program:
Steps to submit the concurrent program using an Order Management responsibility:
- Navigation: Reports, Requests > Run Requests
- Submit a Single Request
- Name: Diagnostics: Apps Check
- Parameters:
Application 1: Oracle Inventory
Application 2: Oracle Order Management
Application 3: Oracle Shipping
Application 4: Oracle Warehouse Management
- Submit the request
Form Versions
... Form Versions: Help About
Often the quickest way to get a form version is in the Oracle Application itself choosing Help > About. This works if the form is one that users directly access (although this will not work for all form objects because some are used behind the scenes as references). See the section "Current Form". For example:
----------------------------------------
Current Form
----------------------------------------
Form Application : Inventory
Form Name : INVMWBIV
Form Path : /global/oracle/visus25/apps/apps_st/appl/inv/12.0.0/forms/US/INVMWBIV.fmx
Form Version : 12.0.79
Form Last Modified : $Date: 2010/04/07 02:43 $
... Form Versions: OS/UNIX
Sometimes it is convenient to check the form version with a script maybe because a technical person is checking the version, the form server is down, the form in question is actually a sub-form, etc. In that case, there are a few places to get the version but the form's compiled code that is executing (.fmx) is often best to get this version. It is located in the product top like $INV_TOP. It is sometimes also interesting to look at the raw source code (.fmb) delivered on the environment in question. In that scenario, one looks at $AU_TOP/forms. This is where the original source code is and shows with .fmb extension. The .fmb file is generated into a .fmx file. For both of these file types, as they are binary, you would need to use the strings command then grep for the $Header information. For example, find the Material Workbench (INVMWBIV.fmb) version with something like:
$ strings -a $INV_TOP/forms/US/INVMWBIV.fmx |grep '$Header'
$Header: INVMWBIV.fmb 120.101.12000000.30 2008/07/17 07:07 ckrishna noship
... Form Versions: OS/UNIX Library
The form libraries are located in $AU_TOP/resource. The libraries include 2 files: 1) the library file (.pll), and 2) the generated library file (.plx). Both library and generated files are binary. The library file (.pll) can be opened in Oracle Forms. Oracle Forms also is the tool to generate the generated file (.plx). Often patches will mention the version of the source file (.pld). The source file (.pld) is a text version of the library that can be generated from Oracle Forms. The best way to get a library version is to use a strings command on the library file in $AU_TOP/resource. The results show the .pld version. For example:
$ strings -a $AU_TOP/resource/ INVTTMTX.pll |grep '$Header'
FDRCSID('$Header: IGI_DOS.pld 120.5 2005/10/05 08:53:29 vkilambi ship $');
fdrcsid('$Header: INVTTMTX.pld 120.26.12010000.20 2010/07/27 10:17:00 mporecha ship $');
Java Versions
... Java Versions - Via Operating System:
The most common way to get java versions is at the operating system level. The java versions of the Oracle Applications EBusiness Suite are stored in $JAVA_TOP/oracle/apps. For example:
$ strings -a $JAVA_TOP/oracle/apps/inv/transaction/server/BaseTransaction.class |grep '$Header'
$Header: BaseTransaction.java 115.235.115100.55 2008/12/19 14:09:15 rkatoori ship $
oracl
... Java Versions - Via SQL:
Some java code is also stored in the database. For these java files, one can issue a SQL command to get the version. For example:
Sql>set serveroutput on
Sql>exec fnd_aolj_util.getclassversionfromdb('oracle.apps.inv.transaction.server.BaseTransaction');
>>> Class: oracle.apps.inv.transaction.server.BaseTransaction
$Header: BaseTransaction.java 115.235.115100.55 2008/12/19 14:09:15 rkatoori
ship $
PL/SQL procedure successfully completed.
> />
>>
... Java Versions - Via Application:
1. Login to application.
2. Click on Diagnostics link on top right of the page
3. Click on "Show Pool Monitor" in drop down
4. Click on Sessions icon in the table.
5. Click on Versions link in the left of page
6. In Class Name field:
7. Enter path/filename
Examples:
oracle.apps.inv.transaction.server.BaseTransaction
oracle.apps.ego.extfwk.user.common.EgoExtFwkCache
8. Press Go button and version displays
Report Versions
A report similar to forms can be found on the file system. However, you first must determine the shortname of the report in question. You then look in the specific product directory under reports. Since the report is a binary file, you would use a strings command to convert the binary code into characters, then grep for the version looking for $Header. For example, find the Bill of Material Structure Report (BOMRBOMS.rdf) version with something like:
$ strings -a $BOM_TOP/reports/US/BOMRBOMS.rdf |grep '$Header'
$Header: BOMRBOMS.rdf 120.5.12000000.5 2008/01/30 22:16 pgandhik noship
PL/SQL Packages
A PL/SQL Package is most often a routine written in the database. The Oracle Application delivers the source code as well as installing the package into the database. It is often a good idea to check the version directly in the database to be sure what version you are using. However, checking the file system for the source code is often a good enough indicator of what is installed since they are normally synchronized.
SQL> select text from dba_source
2 where
3 name = upper( 'INV_TXN_MANAGER_GRP')
4 and line < 3;
TEXT
--------------------------------------------------------------------------------
PACKAGE INV_TXN_MANAGER_GRP AS
/* $Header: INVTXGGS.pls 120.4.12000000.1 2007/01/17 16:33:03 appldev ship $ */
PACKAGE BODY INV_TXN_MANAGER_GRP AS
/* $Header: INVTXGGB.pls 120.55.12000000.15 2007/10/25 11:02:58 ksaripal ship $
*/
You could also check the file system for the version. This is less accurate as it might not be the version currently used in the database, but generally it is close enough. Note that you do not need the 'STRINGS' command because the package details (.pls) is a string file already. Therefore, you can directly open the file in an editor like vi to see the contents and the version. Or you can "grep" the contents searching for the "$Header" that usually accompanies the version number. To get the version from the file system using "grep", you can do something like:
grep '$Header' $INV_TOP/patch/115/sql/INVTXGGB.pls
/* $Header: INVTXGGB.pls 120.55.12000000.15 2007/10/25 11:02:58 ksaripal ship $ */
Definition Files
Definition files like .ldt, .xdf, .odf, etc. are similar to PL/SQL in that they are already text files so you can directly open the file to see the version or grep for the version. These files usually store information about setup, object definitions, etc. They will be found on the file system and then are loaded into the database will a specific command like adodfcmp that is used for .odf files. (.odf loads tables and views, .ldt creates indexes, .xdf creates objects like materialized views). Another interesting command in .odf files is that you can compare the definition listed on the file system to that in the database to confirm that they are the same. Here is an example:
adodfcmp odffile=$ENG_TOP/patch/115/odf.engeeco.odf userid=eng/eng changedb=no priv_shema=system/manager mode=tables touser=apps/apps
Languages
If you are using multiple languages, remember that the objects are often distributed in each language. Therefore, you should check the version of a report, form, etc. in each language.
Patch Versions
... Patch Versions - Oracle Applications
It is sometimes useful to see if a particular patch has been applied. To avoid any confusion, it is often more helpful to first look up the version that the patch delivers and then see if you have that version or higher. However, if you want to see if an Oracle Application patch is applied you can check the patch table or if the bug is logged. Checking for the bug is generally more consistent because you might not have installed the exact patch but received the bug fix in a rollup patch or higher level fix. You could check the bug table AD_BUGS with something like:
select bug_number, application_short_name "App", bug_status, success_flag, last_update_date
from ad_bugs
where bug_number ='7425435';
Or the patch table with something like:
select substr(patch_name,1,12) patch_num
from ad_applied_patches
where patch_name like '7425435';
When a patch is applied, version information is also written for each file. This is included in the AD_FILES and AD_FILE_VERSION tables. Sometimes if a patch goes wrong, you apply a test patch, or you manually install/load a file, the versions in the AD tables will be incorrect. However, they still can be useful and the following is an example to query the latest version of a java file (RevisedItemEOImpl.class) :
select b.FILE_VERSION_ID,b.FILE_ID,b.VERSION,b.CREATION_DATE
from AD_FILES a, AD_FILE_VERSIONS b
where a.file_id = b.file_id
and a.filename like 'RevisedItemEOImpl.class';
FILE_VERSION_ID FILE_ID VERSION
--------------- ---------- -------
654136 401028 115.23
738571 401028 115.24
760052 401028 115.27
959429 401028 115.30
1018955 401028 115.32
1525148 401028 120.36
6 rows selected.
... Patch Versions - Server/Database
A server patch like a database patch is NOT stored in the same place. For database patches, you would look in the 'Inventory'. For example:
$ opatch lsinventory