Customization Manager automates the process of packaging, releasing and reporting customizations for a single Oracle E-Business Suite instance or multiple Oracle E-Business Suite instances. It provides capabilities to integrate with third-party source control repositories to access customizations that need to be packaged. It also integrates with Patch Manager for deployment of custom patches to one or more Oracle E-Business Suite instances.
Customization Manager also provides a dashboard to manage custom applications across Oracle E-Business Suite instances. It provides capabilities to not only register and validate custom applications across instances, but also a drill down to the custom objects associated with any registered custom application on a given instance. Registration and validation of the custom application ensures that custom packages associated with the custom application can be deployed on the given Oracle E-Business Suite instance.
Automates creation of customization packages that are deployable with Patch Manager or standard Oracle E-Business Suite Applications DBA (AD) Utilities
Provides repository to manage/catalog customizations.
Validates custom code against software coding best practices using a standards checker.
Integrates with most source control systems.
Supports National Language Support (NLS) patches.
Generates reports on customization packages or manifests in these formats: rich text format (RTF) for Microsoft Word, PDF, or Microsoft Excel.
Leverages Oracle Enterprise Manager infrastructure for distributed processing.
Provides an interface to manage custom applications across the enterprise.
Customization Manager allows you to package custom files of a variety of file types, including the following:
Oracle Application Object Library (FND) objects - menus, responsibility, concurrent programs, and so on
Forms
Reports
Database objects - views, tables, triggers, packages, and so on
Oracle Application Framework components
For more information on file types, see the appendix.
For more information on making customizations, see the Oracle E-Business Suite Developer's Guide and the Oracle Application Framework Developer's Guide.
Ensure that the Preferred Credentials are set for each user as described in the section Setting Preferred Credentials for Change Management.
Ensure that the Stage Directory is specified in the Preferences page. This property specifies the OMS stage directory for package creation. To set this, navigate to Targets > Oracle E-Business Suite > Administer > Preferences. For more information, see: Setting Preferences.
A package is a fundamental unit of work of Customization Manager. A package consists of all the relevant objects that constitute a customization along with all the necessary metadata relevant for the given customization. A customization package can have one or more custom patches associated which can be deployed to promote customizations.
The file manifest contains a list of files to be included in a package.
The File Metadata Repository stores metadata information of custom files used to create customization packages. This information can be used to manage and catalog customizations within the system.
The Technology Stack Details for a package is a snapshot of the technology stack properties for the Oracle E-Business Suite instance where the package was compiled.
Customization Manager provides several methods for generating reports on packages:
Generate a Standard report on a single package.
Compare two packages using a Comparison report.
The Instance Comparison report can be used to compare a given package against an instance with respect to technology stack, files with versions, missing entries for file driver file, custom products involved, and so on. It can be used to assess the likely impact before actually applying the custom patch on the given instance
Reports can be generated in RTF for Microsoft Word, PDF, and Microsoft Excel.
Once a customization package is created and tested successfully, it might need to be shared with other users. This is possible by updating the package metadata and setting the package status as "Released".
For scenarios where the given customization is no longer valid, the customization package may be retired by updating the package metadata and setting the package status to "Obsoleted".
For information on diagnostic tests for this feature, see: Diagnostic Tests for Customization Manager.
Customization Manager has a standards checker to check that the files included in a custom package meet certain coding standards. This checker tests all code for standards compliance and cannot be turned on or off.
Some standards are mandatory and will result in failure when Customization Manager attempts to build the package. Other standards are recommended, and the standards checker will give a warning but the package will be built.
For example, Customization Manager mandates that each file included within a customization package has an Oracle-compliant source header present within the file. If a file in a package is missing this header, the package cannot be built.
Each file included within a customization package is recommended to have an Oracle-compliant source header present within the file.
The following is an example of an Oracle-compliant header:
$Header: sample.txt 10.1 2012/04/06 09:38 lmathur ship $
The header contains the following elements:
Filename
Revision ID - This needs to be incremented every time a file is checked in
Date and time of checkin
Author
Shipment state - ship/noship. For custom files, use the value ship.
This option can be enabled while defining or updating the "File Source Mapping" used for package creation. When the "Automatic header update" option is selected, Customization Manager takes care of querying the source control repository to derive the revision number and updates the Oracle-compliant header present within the file with the same, during the process of package creation.
It is important to ascertain that the correct "Version command" is provided to lookup/query the revision number from the given source control repository, except when using CVS or File System. This feature is not supported when the source repository is 'File System'. Also, for CVS there is no need to specify the version command as the header is always looked up from the $Header string present within the file.
Important: When using the automatic header update feature with CVS, you must have a $Header placeholder within each source file. The placeholder header must be embedded in the source file before the file is checked in into CVS.
Also ensure that you change the file name with the correct case within the $Header before embedding the header in the file.
Important: When using Subversion, it is required to use Subversion client version 1.2 or above for automatic header update.
Automatic header update is supported for all file types. For binary files like forms, reports, and so on, you must provide a dummy placeholder for the header with enough appropriate offset (space). It is recommended to leave at least 40% extra offset (space) to accommodate incrementing revision numbers. During the process of package creation, the system uses this as a placeholder and updates it with the correct header. Again, the automatic header update option should be enabled and the correct version command should be specified within the file source mapping. The header is calculated based on the release and the version in the source control. For example, if you are building a package for Release 12 and the version of the file in the subversion repository is 29, then the header version calculated would be 120.29.
Automatic header insertion is supported only for selected file types when using Subversion as the source control system. In this case, Customization Manager inserts a valid Oracle compliant header into the source file during the process of package creation, even when there is no $Header present in the file. The following file types are supported for automatic header insertion in case the file does not contain a proper $Header:
.css
.drvx
.htm
.html
.ildt
.java
.jlt
.jsp
.ldt
.msg
.odf
.pdt
.pkb
.pkh
.pks
.pl
.plb
.pls
.sh
.slt
.sql
.tpl
.wft
.wfx
.xdf
You can add a header to a custom RTF file by adding it to the file's "Comments" property. For example, in Microsoft Word, navigate to the File menu, select Properties, and enter the header in the Comments field as shown in the figure below.
You can upload a custom patch to Customization Manager repository:
The upload option is provided to upload existing custom patches created in the Customization Manager repository. On upload, a package with status "Succeeded" is created. The status can move to status "Released" or "Obsoleted" as other customization packages. One or more NLS patches can be uploaded for a given package. Once uploaded, the patches can be deployed using Patch Manager. Also, attachments can be added for the uploaded packages.
Note: Reporting and update capabilities are not available for the uploaded packages.
A file driver file is a master file for adpatch to identify valid Oracle E-Business Suite files for a given product (including a custom product). It is required to have an entry within the file driver file for selected file types like forms, reports, and so on. If not, then the following error is thrown during patching: "File in patch is not a known Oracle Applications file".
Customization Manager takes care of this file driver file requirement automatically. Customization Manager implicitly generates a file driver file for the relevant files in a package. During deployment with Patch Manager, these entries are automatically added to the custom product master file driver file. In case a user applies a patch manually with adpatch, he or she can run updateFileDriver.pl within the <package>/meta-inf folder before invoking adpatch.
Note that if you get the error "File in patch is not a known Oracle Applications file" while applying a custom patch built with Customization Manager, then it could be due to a missing entry in file driver file for the custom product for one or more custom files.
The file driver file for a custom product is located under:
$<custom_product_top>/admin/driver/<custom_product_short_name>file.drv
For example, if XXCO is the custom product, then you can find the file driver file under
$XXCO_TOP/admin/driver/xxcofile.drv
All custom files would require an entry in the respective file driver file depending on the custom product they belong, EXCEPT files which have destination path beginning with any of the following:
admin
sql
mds
lib
patch
help
def
as well as any java file under destination path beginning with "java".
The usual format for an entry into the file driver file is:
<product> <subdirectory> <filename>
Sample entries are as below:
xxco admin/sql XXCONLADD.sql
xxco forms/<LANG> XXCOFORM.fmb
The main page for Customization Manager lists packages that are registered in the system. For each package, the following is given:
Name - The name of the package.
ID - The ID of the package. This is always unique across packages.
Release - The Oracle E-Business Suite release level for the package.
Product - The owning product or custom application.
Type - The type of package. Valid values include AOL, FORMS, PL/SQL, XML Publisher, OAF, and Others. This is purely for classification purposes and has no bearing on the functionality of the package.
Status - The status of the package. Valid values include Saved, In Progress, Failed, Succeeded, Released, Pending Approval, and Obsoleted. Note that some actions are restricted based on the status of a package.
Owner - The owner of the package. Note that some actions are restricted based on the owner of a package.
Last Updated - The date and time the package was last updated.
Update - Use this icon to update a package.
Delete - Use this icon to delete a package.
You can search for a package based on its name or ID, or click the "Advanced Search" link to perform a search on other criteria.
The following functions are available for a given package (depending on its status and ownership):
Using the procedure specified, deploy the package as a patch job in Patch Manager using the Deploy button. Packages with statuses "Succeeded" or "Released" can be deployed.
Update the package metadata using the Update Metadata button. Packages with the statuses Succeeded or Released only can be updated for metadata changes, provided they are owned by the user currently logged in.
Run a report on the package using the Report button. Packages with statuses Succeeded, Released or Obsoleted can be used for reports.
Create a copy of a package using the Create Like button.
You can also create a new package using the Create button or upload an existing package using the Upload button.
Use the Related Links at the bottom of the page to access the following features:
File Source Mapping
E-Business Suite Mapping
Package Report
File Metadata Repository
Custom Applications
Custom Application Requests
File Source Mapping captures all the required metadata for retrieving custom files from a source control or file system repository. Creating a File Source Mapping is usually performed once as a setup step. You may create one or more File Source mappings, if required.
The main File Source Mapping page allows you to search for a File Source Mapping by name. The table lists each mapping with the following:
Name - The name given to the mapping. Click on the link to go to the Update File Source Mapping page.
Host Name - The name of the host from where the source control or file system is accessible.
Source Type - The type of the source control system. Valid values are: SubVersion, CVS, File System, or Others.
Owner - The user who created this File Source Mapping.
Last Updated - The date and time the mapping was last updated.
Enabled - Specifies if the mapping is enabled or disabled. You can enable/disable a mapping in the Update File Source Mapping page.
Public - Whether the given mapping is public. If a mapping is public, all users can view it, but only the owner and Super Administrators can edit it.
Delete - Use the icon provided to delete a mapping. You can delete a mapping only when no package is associated with it.
To create a File Source Mapping
Perform the following steps to create your File Source Mapping. Note that for the checkout command, you should follow the checkout command syntax provided on the page.
Enter the name for the file source mapping.
Enter the host name of the file source mapping. You can select the host from the list of values.
Enter the stage path. This should be a folder on the given host with read/write access which is used for temporary processing during checkout.
Select the source control type. Possible values are:
SubVersion
CVS
File System
Others
The source control type is used to default the checkout command. However, the checkout command can be modified based on your source control or file system configuration. If your source control system is not among CVS, SubVersion or File System, then you may choose "Others" and enter your checkout command.
Enter the complete command, with required parameters, to be used to check out files. The parameters that can be used to construct the checkout command are mentioned under the "Checkout Command Syntax: section. Oracle strongly recommends that you to test the checkout command by using the “Test Checkout Command” option. It is also important to ascertain that the user provided within the “host” credentials has the correct permissions on the given host selected for checkout.
Optionally enter the environment script to be run before files are checked out, to set any environment parameters ore preprocessing, if required.
Enter a description for your reference.
Mark the file source mapping as Public if desired.
If a file source mapping is marked as Public, any user can view it and use it to create a package. However, only the owner and Super Administrators can edit the file source mapping.
This feature is typically useful when you would want the system administrator to create one mapping and enable all developers to use them, without having them know the details of the source control system.
Note that a Super Administrator can see all transactions. A Super Administrator can access all file source mappings, Oracle E-Business Suite mappings, reports, and packages. A Super Administrator can also modify and delete them.
The “Test Command” feature allows you to test the checkout command and the version command provided on the remote checkout host. It is strongly recommended that you test the checkout command and version command to help prevent any failures during checkout while creating a package. Enter Test Checkout Command information
Enter the following:
Product
Source Path
File Name
Version
Language
Branch - If your source control system requires it and if %branch% token is included within the checkout command.
Tag - If your source control system requires it and if %tag% token is included within the checkout command.
User Name - If your source control system requires it and a %user_name% token is included within the checkout command.
Password - If your source control system requires it and a %password% token is included within the checkout command.
Use the Preview or Test button to preview or test the checkout command and version command. The results will be shown in the Command Preview or Test Results field.
To create a File Source Mapping using the "Create Like" option
Select the "Create Like" button to create a file source mapping by copying the details from an existing file source mapping. This procedure can be used typically to create a mirror copy of the file source mapping or create another file source mapping with minor modifications without having to enter all the relevant details about the file source mapping.
To update a File Source Mapping
You can update a File Source Mapping by clicking on its name listed in the main File Source Mapping page. You can only update the fields described below. It is not possible to update the host for a given file source mapping.
Note that you can check or uncheck the Enabled box to enable or disable a file source mapping.
Enter the source control type. Possible values are:
SubVersion
CVS
File System
Others
Enter the complete command, with required parameters, to be used to check out files.
Enter the stage path. The stage path is the location of the directory, with write permissions, to where the files would be checked out.
Optionally enter the environment script to be run before files are checked out, to set environment parameters.
Enter a description.
Mark the file source mapping as Public if desired. If it is marked as Public, all users can view the mapping. However, only the owner and Super Administrators can edit it.
The separate preview and test section is provided so that you can preview the checkout command and test it on the remote checkout host. It is strongly recommended that you test the checkout command before actually using it to create a package.
Enter the following:
Product
Source Path
File Name
Version
Language
Branch
Tag
User Name
Password
Use the Preview or Test button to preview or test the checkout command. The results will be shown in the Command Preview or Test Results field.
The following table provides information on the file source mapping parameters and sample values for each parameter.
Name | Description | Related User Interface Page | Sample Value |
---|---|---|---|
%product_code% | Substitution variable for the product code | Create/Update Package - File Listing | xxco |
%file_path% | Substitution variable for source path | Create/Update Package - File Listing | patch/115/import |
%file_name% | Substitution variable for file name | Create/Update Package - File Listing | Custom_Responsibilities.ldt |
%version% | Substitution variable for version | Create/Update Package - File Listing | 115.32 |
%lang_code% | Substitution variable for language | Create/Update Package - File Listing | US |
%branch% | Substitution variable for branch | Create/Update Package - General | Prod13 |
%tag% | Substitution variable for tag | Create/Update Package - General | Release12c |
%user_name% | Substitution variable for username | Create/Update Package - General | developer1 |
%password% | Substitution variable for password | Create/Update Package - General | welcome1 |
Here is the syntax of a checkout command with the parameters:
svn cat file:///usr/local/svn/%product_code%/%file_path%/%lang_code%/%file_name% --username %user_name% --password %password% > %file_name%
Here is the above checkout command with values substituted for the parameters:
svn cat file:///usr/local/svn/xxco/patch/115/import/US/Custom_Responsibilities.ldt --username developer1 --password <password> > Custom_Responsibilities.ldt
Creating an E-Business Suite Mapping is an optional setup step. This mapping is used if Java or PLD file compilation is required. It is also used for report generation. The E-Business Suite Mapping indicates the Oracle E-Business Suite instance which would be used to compile Java or PLD files or used for report generation. Please note that all operations on this instance are read-only and using an instance for E-Business Suite mapping cannot cause any kind of change on the given instance via Customization Manager.
The main E-Business Suite Mapping page allows you to search for an E-Business Suite Mapping by name. The table lists each mapping with the following:
Name - The name given to the mapping. Click on the link to go to the Update E-Business Suite Mapping page.
Instance Name - The name of the Oracle E-Business Suite instance.
Release - Release level of the Oracle E-Business Suite instance.
Owner - The user who created this mapping.
Last Updated - The date the mapping was last updated.
Enabled - Specifies if the mapping is enabled or disabled. You can enable/disable a mapping in the Update E-Business Suite Mapping page.
Public - Whether this E-Business Suite Mapping is available for all users. If a mapping is marked as Public, all users can view it, but only the owner and Super Administrators can edit it.
Delete - Use the icon provided to delete a mapping. You can delete a mapping only when there are no packages associated with it.
Select the Create button to create a new mapping.
To create an E-Business Suite Mapping
Use the following steps to create an E-Business Suite Mapping.
Enter a name for the mapping.
Enter the name of the reference Oracle E-Business Suite instance. Options for this instance are automatically discovered by Oracle Application Management Pack for Oracle E-Business Suite.
Mark the mapping as Public, if desired.
If an E-Business Suite Mapping is marked as Public, any user can view it and use it to create a package, but only the owner and Super Administrators can edit it.
This feature is typically useful when you would want the system administrator to create one mapping and enable all developers to use them, without having them know the details of the source control or Oracle E-Business Suite system.
Note that a Super Administrator can see all transactions, including E-Business Suite mappings. A Super Administrator can access all file source mappings, E-Business Suite mappings, reports, and packages. A Super Administrator can also modify and delete them.
Enter the stage path. The stage path is the location of the directory with write permissions used for temporary processing during compilation and build process.
Enter the prepend classpath. This field is valid only with Java files; this classpath is prepended to these files when a package is built. This can be used to specify any third party libraries if you custom java files have dependencies on them.
Enter a description for the mapping.
To create an E-Business Suite Mapping using the "Create Like" option
Select the Create Like button to create an E-Business Suite Mapping by copying the details from an existing E-Business Suite Mapping. This procedure can be used typically to create a mirror copy of the E-Business Suite mapping or create another E-Business Suite Mapping with minor modifications without having to enter all the relevant details about the E-Business Suite Mapping.
To update an E-Business Suite Mapping
To update an E-Business Suite Mapping, click on its name in the main E-Business Suite Mapping page. Note that you cannot update the E-Business Suite Mapping name or the instance mapping here.
Check the Enabled box if you want the E-Business Suite Mapping to be active.
Check or uncheck the "Public" box depending on whether the mapping should be viewable by all users.
Enter the stage path. The stage path is the location of the directory with write permissions to where files would be compiled.
Enter the prepend classpath. This field is valid only with Java files; this classpath is prepended to the environment classpath during package compilation.
Enter a description for the mapping.
Use the following procedures to create packages:
To create a package
Enter general information for the package. The Package ID is an auto-generated unique number.
Package Name - Enter a user-friendly name for the package.
Product - Enter the owning product application. This product can be a custom product created in Oracle E-Business Suite (not in Customization Manager).
Package Type - Enter the package type. This value is for your own classification and convenience for searching and cataloging. No validation is performed on this field.
Description - Enter a description for your reference. This description becomes part of the package readme.
File Source Mapping - Enter the File Source Mapping for this package. Select from the list of previously-defined mappings.
Branch - Enter the branch for the source control system, if required. The branch will be substituted for the %branch% token within your checkout command.
Tag - Enter the tag for the source control system, if required. The tag will be substituted for the %tag% token within your checkout command.
User Name - Enter the user name to connect to the source control system, if required. The User Name will be substituted in the "%user_name%" parameter of the checkout command.
Password - Enter the password for the above user name, if required. The password entered here would be substituted for the %password% token within your checkout command.
Upload Manifest - If you have a file manifest in a comma-separated value (CSV) format on your computer, you can upload it here.
The following is an example of a file manifest:
#Product,SourcePath,FileName,Version,Type,DestPath,LangCode xxco,java\r12\reporter\cpserver,XXCOCustomCp.java,115.1,java,java/r12/reporter/cpserver,Generic xxco,patch\115\import,XXCOConcprog.ldt,115.9,software ldt,patch/115/import,US xxco,patch\115\import,XXCOMenu.ldt,,software ldt,patch/115/import,US xxco,patch\115\import,XXCOReqGroup.ldt,115.3,software ldt,patch/115/import,US xxco,patch\115\import,XXCOResp.ldt,115.7,software ldt,patch/115/import,US xxco,patch\115\import,XXCOUser.ldt,115.6,software ldt,patch/115/import,US xxco,forms,XXCOFRM.fmb,,fmb,forms,US
Enter the file listing.
You may add or remove file entries manually from the File Listing page. Alternatively, you may also include file entries from the File Metadata Repository using the Include Files button.
For each file, enter the following:
Product - The owning product application. This product can be a custom product created in Oracle E-Business Suite (not in Customization Manager). This would be substituted in the "%product_code%" parameter in the checkout command.
Source Path - The source directory for the file on the source control system or file system. This would be substituted in the "%file_path%" parameter in the checkout command.
File Name - The name of the file. This would be substituted in the "%file_name%" parameter in the checkout command.
Version - Optional. The version of the file. The version is only needed if the checkout command will use the version information. This would be substituted to the “%version%” parameter in the checkout command.
Type - The type of the file. Ensure that correct type is selected for the file entry. The Oracle Applications DBA (AD) patch driver instructions are based on the type selected. For details, please refer to the appendix describing the file types.
Destination Path - The destination path for the file in the Oracle E-Business Suite instance excluding the language subdirectory relative to the product top.
For common file types, a default destination path is provided automatically but this default value can be overridden.
The destination path must be an AD-compliant destination path according to Oracle E-Business Suite standards.
The destination path in the patch driver is automatically suffixed with the language code chosen with exception to "Generic".
Note: For "Generic" files, ensure that the destination path is entered correctly: For example,
Product: XXCO Source Path: forms/US File Name: IDC.fmb Destination Path: forms Language: US
The final destination path is "forms/US" but the values are entered separately.
Language - Optional. The language code for the file. Select the language code as needed to generate the respective NLS patch.
Status - The status can be one of the following:
Valid - Indicates that the entry is valid.
Review - Indicates that the entry needs to be reviewed.
Duplicate - Indicates that the entry is duplicated.
Blank - Indicates that one of the required fields is blank.
Important: Customization Manager strongly recommends that each file included within a customization package has an Oracle-compliant source header present within the file.
The following is a sample Oracle compliant header:
$Header: sample.txt 10.1 2012/04/06 09:38 lmathur noship $
The header contains the following elements:
Filename
Revision ID - This needs to be incremented every time a file is checked in
Date and time of checkin
Author
Shipment state - ship/noship
Enter in additional information for your package.
Enter the E-Business Suite information (Conditionally required). The E-Business Suite mapping information is only required when the package contains at least one Java or PLD file. You can select the Oracle E-Business Suite Mapping from the list provided.
Enter the Package Metadata. You can enter the instructions for package application here. These instructions will become part of the package readme.
Enter Comments. These comments will be recorded as part of the package history for tracking changes made to the package.
Enter Prerequisite Information.
For Release 11i packages, you can enter one or more prerequisite patch numbers that can be used for deployment validation with AD utilities.
For Release 12 (and higher) packages, enter in the prerequisite patch numbers that will be used in validation when the package is deployed through Patch Manager. Note that this validation is done only if you use the Check Prerequisites button in the Patch Details page when creating a patch run in Patch Manager.
Note: Prerequisite information entered here for Release 12 packages is only used in deployment by Patch Manager.
Enter Mailing List information.
You can enter e-mail addresses for people who should be sent notifications about the package's creation status on the event of success or failure. It is recommended to have e-mail notifications set so that the appropriate users can be notified about the package success or failure.
Click Submit.
To create a package using the "Create Like" option
Customization Manager allows you to create a package by copying the details from an existing package. This procedure can be used typically to create a mirror copy of the package or create another package with minor modifications without having to enter all the relevant details about the package.
Note: If you are using a version of Mozilla Firefox higher than 5, the Create Like page is not loaded automatically. To work around this issue, click the Refresh button on the page.
To create a package using the Upload option
If you have any legacy custom patches, the same can be uploaded to the Customization Manager repository in context to a new customization package. Click the Upload button from the package search page to upload an existing custom patch. While uploading a custom patch, the following information is required:
Package Name
The release to which the custom patch belongs to.
The custom product/application associated with the custom patch
Package type: only for classification purposes
Description for your reference
Any specific instructions for applying the custom patch
You can upload one or more custom patches (NLS patches) to this customization package. However, it is important that all of them must be associated with the same unique patch number. Clicking the Submit button creates a customization package with the status "Succeeded". This customization package can now be deployed just like any other customization package and can be "Released" or "Obsoleted", when required.
To update a package, find the package listing in the main Customization Manager page and select the icon in the Update column.
To update a package's definition
Enter general information for the package. The Package ID is an auto-generated unique number and cannot be updated. The Package Name cannot be updated as well.
Release - Choose the release for the package.
Product - Enter the owning product application. This product can be a custom product created in Oracle E-Business Suite (not in Customization Manager).
Package Type - Enter the package type. This value is for your own classification and convenience for searching and cataloging. No validation is performed on this field.
Description - For your reference.
File Source Mapping - Enter the File Source Mapping for this package. Select from the list of previously-defined mappings.
Branch - Enter the branch for the source control system, if required. The branch will be substituted for the %branch% token within your checkout command.
Tag - Enter the tag for the source control system, if required. The tag will be substituted for the %tag% token within your checkout command.
User Name - Enter the user name to connect to the source control system, if required. The User Name and Password (below) will be substituted in the "%user_name%" and "%password%" parameters of the checkout command.
Password - Enter the password for the above user name, if required.
Upload Manifest - If you have a file manifest as a comma-separated value (CSV) format on your computer, you can upload it here.
You may add or remove file entries manually from the File Listing page. Alternatively, you may also include file entries from the File Metadata Repository using the Include Files button.
For each file, enter the following:
Product - The owning product application. This product can be a custom product created in Oracle E-Business Suite (not in Customization Manager).
Source Path - The source directory for the file on the source control system or file system. This would be substituted in the "%file_path%" parameter in the checkout command.
File Name - The name of the file. This would be substituted in the "%file_name%" parameter in the checkout command.
Version - Optional. The version of the file. The version is only needed if the checkout command will use the version information. This would be substituted in the "%version%" parameter in the checkout command.
Type - The type of the file. Ensure that correct type is selected for the file entry. type. The Oracle Applications DBA (AD) patch driver instructions are based on the type selected.
Destination Path - The destination path for the file in the Oracle E-Business Suite instance excluding the language subdirectory. This must be an AD-compliant destination path according to Oracle E-Business Suite standards. The destination path in the patch driver is automatically suffixed with the language code chosen with exception to "Generic". The destination path for a file entry is defaulted to the source path, which may be modified if necessary.
Language - Optional. The language code for the file. Select the language code as needed to generate the respective NLS patch.
Enter in additional information for the package.
Enter the E-Business Suite mapping information (Conditionally required). The E-Business Suite mapping information is only required when the package contains at least one Java or PLD file. You may select the E-Business Suite Mapping from the list provided.
Enter the Package Metadata. You can enter the instructions for package application here. These instructions will become part of the package readme.
Enter Comments. These comments will be recorded as part of the package history for tracking changes made to the package. As a best practice, it is recommended to add comments describing the changes done to the package and other details. Any comments added are tracked with the package history information.
Enter Prerequisite Information.
For Release 11i packages, you can enter one or more prerequisite patch numbers that can be used for deployment validation with AD utilities.
For Release 12 (and higher) packages, enter in the prerequisite patch numbers that will be used in validation when the package is deployed through Patch Manager. Note that this validation is done only if you use the Check Prerequisites button in the Patch Details page when creating a patch run in Patch Manager.
Note: Prerequisite information entered here for Release 12 packages is only used in deployment by Patch Manager.
Enter in Mailing List information. You can enter e-mail addresses for people who should be sent notifications about the package's update status on the event of success or failure.
Click Submit.
If, in the process of creating or updating a package definition, you want to save the package definition before submitting a request to have Enterprise Manager actually build the package, click the Save button on the File Listing page or the Submit page of the Create/Update process. Your package definition will be saved and it will appear on the main Customization Manager page with a status of Saved.
You can perform an Advanced Search for packages with the following criteria:
Name
ID
Product
Instruction Contains
Prerequisite Patch
Description Contains
Owner
Release
Package Type
Standards Check Results
Status
Language
Public (Choose whether you want results with only Public packages, no Public packages, or either)
Contains File
Contains File with Version (Used in conjunction with "Contains File")
Updated within (Days)
File Source Mapping Name
Branch
Tag
E-Business Suite Mapping Name
Last Updated By
View package details by selecting its name in the search results table on the main Customization Manager page.
The following details are shown in this region:
Package ID
Release
Standard Checker Results - For detailed results, click on the link.
Created - The date and time the package was created.
Last Updated - The date and time the package was last updated.
Last Updated By - The user who last updated the package.
Status - The status of the package. Possible values are: In Progress, Succeeded, Saved, Failed, Released, and Obsoleted.
Product
Package Type
E-Business Suite Mapping Name – If applicable.
File Source Mapping Name
Owner
Uploaded: Whether this package was created as a result of a patch upload.
Public: Whether this package is shared across all users.
The package history provides a chronological view of all the important events in the lifecycle of a package.
Select the History Details button to go to the View Package History page, which provides high-level history tracking of the package, including the timestamp and user-entered comments for the following events:
Creation of package
Update of package
Release of package
You can also drill down to the Oracle Enterprise job details for the package creation and any updates.
Use the View Log button to view the most recent Oracle Enterprise Manager job details for the package.
Use the Download Log button to download the consolidated log for the package creation.
Any description entered for the package is shown here.
Instructions entered in the Package Metadata field are shown here.
For each patch generated, the following information is shown here:
File Name - Click on the patch file name link to download the patch.
Language - The language of the patch.
Size - The size of the patch.
Readme - Click on the icon to download the readme. The readme file is in HTML format and includes the package description and package metadata.
Typically, each customization package could be associated with one or more language patches.
The file manifest is shown here. Details for each file include Product, Source Path, File Name, Language, Destination Path, Version, and Last Updated timestamp.
Use the Download Manifest button to download the manifest as a comma-separated values (CSV) file, viewable in Microsoft Excel.
You can search for a specific file by entering in the file name in the "Locate File" field and clicking Go. Wildcard characters “%” and “*” are supported here.
The Technology Stack details for a package provide a snapshot of the technology stack properties for the Oracle E-Business Suite instance where the package was compiled. Patch Manager, when deploying the patch, checks the compatibility of the details specified here with the environment to which the package is being deployed. You can first check Technology Stack compatibility yourself by running "Instance Comparison" reports.
You may add or remove any associated documentation like project plan, design documents, and so on. For each attachment, the following is listed:
File Name
Description
Last Updated timestamp
You can remove an attachment from the package using the Delete icon. If the package is Released or Obsoleted, then the attachments cannot be deleted.
Any prerequisite patches are listed here along with any comments.
View the e-mail addresses for people who should be sent notifications about the package, on the event of success or failure.
View the history of the package by clicking the History Details button. The package history captures a trail of all major actions upon the package with the comments captured.
Package metadata can be updated to change the status of the package or to push the file entries metadata in the package to the File Metadata Repository. The "Update Package Metadata" page enables you to do the following:
Change the status of the package. You can release or obsolete a package by changing its status to "Released" or "Obsoleted". Once a package is updated to the "Released" status, it can no longer be updated and becomes accessible to other users. Once a package is updated to the "Obsoleted" status, it can no longer be updated or deployed.
Note: With the Change Approval Framework, once an approver approves a request to release/obsolete a customization package from a user, the package is released/obsoleted. The user does not need to release/obsolete the package explicitly after the approval.
Tip: Add comments for future reference when you release or obsolete a package. For example, state the reason why you are obsoleting a package.
Add file metadata entries to the File Metadata Repository.
If you are the owner of the package or super administrator, you can mark the package as “Public” which entitles the package to be shared across all users for view/update.
Add comments which are recorded in the package history for the above changes.
The results of the standards checker can be accessed by clicking on the standards checker status.
The standard checker results can also be downloaded as a CSV format file by clicking the Download Results button.
To view details about the standard checker validations for a given file, click on the overall status against each file. The details about the standard checker validations include the standard name, result and the message.
In case the standard checker completes with "Error", the package processing is aborted and there are no patches generated.
Customization Manager offers powerful reporting capabilities to help you document, compare and track your customizations. You can generate three types of reports on packages:
A Standard report gives you details on a single package, including technology stack requirements and the file manifest. You might use this to document customizations.
A Comparison report allows you to compare two packages. For example, you might want to compare their technology stack snapshots or the versions of the files included in the packages.
An Instance Comparison report allows you to compare the details of the package with that of an actual Oracle E-Business Suite instance. The details which are compared include custom application, file driver file entries, file manifest and versions, and the technology stack snapshot of a package to the technology stack properties of a given instance. By doing this comparison you can determine possible compatibility issues of the package with the instance and assess the possible impact/possible issues before actually applying the patch.
The technology stack compatibility information and the report is also available from the Patch Manager interview process by clicking the "Technology Stack Report" icon on the Patch Details page.
Important: Oracle strongly recommends that you generate an Instance Comparison report for each custom package and the instance where it is intended to be deployed to identify any technology stack incompatibilities before actually applying the patch.
Reports can be accessed from the Reports link on the Change Management dashboard, or from the Reports link under Related Links on the Package Search page.
To create a report, you can
Select a package from the Package Search results page and click Report
Click Report button on the View Package page, or
Click the Create button on the Package Report page.
To create a Standard Report
A Standard report gives you details on a single package, including technology stack requirements and the file manifest.
Enter in a user-friendly name for your report.
Choose Standard for the Report Type.
Enter the package you want the report to be based on in the Package field. This package must have the status of Succeeded, Released, or Obsoleted.
Enter the Report Format. Options are:
PDF (Portable Document Format)
RTF (Rich Text Format)
XLS (Microsoft Excel format)
Enter the Oracle E-Business Suite Mapping to be used for the report generation.
Click Submit.
To create a Comparison Report
A Comparison report allows you to compare two packages. For example, you might want to compare technology stack requirements or versions of the files included in the packages.
Enter in a user-friendly name for your report.
Choose Comparison for the Report Type.
Enter the package name in the Primary Package field. This package must have the status of Succeeded, Released, or Obsoleted.
Enter the package name in the Secondary Package field. This package must have the status of Succeeded, Released, or Obsoleted.
Enter the Report Format. Options are:
PDF (Portable Document Format)
RTF (Rich Text Format)
XLS (Microsoft Excel format)
Enter the Oracle E-Business Suite Mapping to be used for the report generation. Please note that this instance would be only used to publish the report using BI Publisher.
Click Submit.
To create an Instance Comparison Report
An Instance Comparison report allows you to compare the technology stack properties of a package to the technology stack properties of a given instance. By doing this comparison, you can tell if the package can be properly deployed on the instance.
In addition, the report lists any missing entries in the file driver file, and compares files and versions within the package to those of the instance.
Enter in a user-friendly name for your report.
Choose Instance Comparison for the Report Type.
Enter the package you want the report to be based on in the Package field. This package must have the status of Succeeded, Released, or Obsoleted.
Enter the Report Format. Options are:
PDF (Portable Document Format)
RTF (Rich Text Format)
XLS (Microsoft Excel format)
Enter the Oracle E-Business Suite Mapping to be used for the report comparison. The Oracle E-Business Suite instance referred by this mapping would be the one which would be compared against the package. As a best practice, it is recommended to generate an instance comparison report for every instance where you intend to deploy the package, to identify any possible incompatibilities/issues before actually applying the package.
Click Submit.
To access reports, navigate to the Change Management tab > Package Report, or to the Customization Manager home page > Package Report (under Related Links).
In the Package Report search results table, the following is shown for each report:
Name - The name of the report.
Type - The type of the report; either Standard, Comparison, or Instance Comparison.
Primary Package - The primary package on which the report is based.
Secondary Package (if any) - For Comparison reports, the second package used in the comparison.
E-Business Suite Mapping - The E-Business Suite Mapping used in the report generation or comparison.
Format - The format of the report; either PDF, RTF, or XLS.
Status - The status of the report.
Owner - The user who created the report.
Last Updated - The Last Updated timestamp for the report.
Download - Click on the link provided to download a ZIP file containing the report.
Details - Click on the Details icon to view details on the report submission job. This link takes you to the Oracle Enterprise Manager Deployments Status page for the report submission.
Delete - Click on the Delete icon for the report to delete the report.
The Standard Report output file has three sections:
Package Details - Information pertaining to the package's definition.
Technology Stack Information - Properties and values of the technology stack of the instance mapped through the Oracle E-Business Suite Mapping for the package.
File Manifest - The listing of the files in the package, including their respective product, source path, name, version, language, and type.
The Comparison Report output file has three sections:
Package Details - Information pertaining to the packages' definitions.
Technology Stack Information - This section shows a comparison of the values of the two packages' technology stack details.
File Manifest - This section shows a comparison of the versions of each given file in the two packages.
The Instance Comparison Report output file has six sections:
Package Details - Information pertaining to the package's definition.
Oracle E-Business Suite Instance Information - Basic information for the instance used in the report comparison. Information includes name, patch level for Applications DBA (AD), patch level for Oracle Application Object Library (FND), and the database release information.
Missing custom products/applications.
Missing entries in file driver file.
File comparison to report missing files or version differences.
Technology Stack Details - For each given property, this table lists the value for the package and the Oracle E-Business Suite instance, and how they compare to each other.
You can search for a report by its name on the main Package Report page, or click the Advanced Search link to search based on additional criteria, including:
E-Business Suite Mapping - The E-Business Suite mapping used for the report generation or comparison.
Primary Package - The primary package for the report.
Secondary Package - The secondary package, if any. The secondary package would be used in Comparison Reports.
Type - The type of report; either Standard, Comparison, or Instance Comparison.
Report Format - The format chosen for the report; either PDF, RTF, or XLS.
After a package is released, it is implicitly shared with other users to deploy. Use the Update Package Metadata page to release a package. See: Updating Package Metadata.
Note: With the Change Approval Framework, once an approver approves a request to release a customization package from a user, the package is released. The user does not need to release the package explicitly after the approval.
Before you deploy a custom package in Patch Manager, you should run the Instance Comparison Report to compare the technology stack properties of the package with those of the instance to which the package is being deployed. Patch Manager does not stop the deployment of a patch if the technology stack properties are not compatible, so you should make your best judgement based on the Instance Comparison Reports.
The File Metadata Repository stores metadata information on each file. It can be used as a cataloging repository for all custom files within your enterprise.
The File Metadata Repository is also aware of the objects within the custom files. This capability typically applies to SQL scripts and PL/SQL packages where the objects are tables, indexes, sequences, views, and so on.
The system can parse and discover objects within custom files when added to the File Metadata Repository. This can be initiated from the “Update Package metadata” screen on clicking the box "Add file metadata to file repository".
Examples of custom objects include:
Tables
Views
Mviews and Mview logs
Triggers
PL/.SQL package names
Indexes
You can view and updates objects populated for a give file. You can also search for files containing specified objects and include them during package creation or update.
Search capabilities are limited to:
PL/SQL spec and body (all formats)
SQL files
Oracle Application Framework XML files
XDF
The information on a file can be uploaded to the repository in one of three ways:
By uploading a package's file manifest in CSV format to the repository.
By adding metadata for an individual file manually to the repository.
By updating the metadata for a file already in the repository.
You can add metadata to the repository using the "Add file metadata to file repository" option in the Update Metadata page.
The File Metadata Repository can be accessed from its link on the Change Management Dashboard under Customization Manager.
You can search for a file by entering the filename in the Search field on the main File Metadata Repository page. Alternatively, use Advanced Search to search for its file using one or more of the following: Filename, Product, Language, Source Path, Destination Path, or Object Name.
Also, during the package create/update flow, you can search for files or files referring to objects within the file metadata repository using the Include Files button.
To upload a file manifest
Select the Upload Manifest button from the main File Manifest Repository page.
Select your file manifest file using the Browse button for the File Manifest field.
Optionally add a description.
Click Submit.
To upload an individual file
Enter the name of the file.
Enter the product to which the file belongs.
Enter its source path.
Enter the destination path.
Enter the language for the file.
Optionally enter a description.
Click Submit.
To update the metadata for a file already in the File Metadata Repository
Select the Update icon for the file in the Search results table in the main File Metadata Repository page.
Update the file name, product, source path, destination path, language, and/or description as desired.
Click Submit.
You can associate one or more customization objects to a given file in the Related Objects region. For instance, a PLS file might be associated with a PL/SQL procedure name as one of the objects. You might update a given file entry to associate one or more customization objects to it. This capability allows you to catalog and later search for customization objects using the Advanced Search option within the File Metadata Repository. However, there are currently no validation checks built into the system that use this information during package creation or deployment.
You can manage your custom applications via the dashboard. The common dashboard allows you to:
View custom applications and instance associations
Hide and unhide the custom applications within Customization Manager
Register a new custom application
Validate an already registered custom application
If a validation request fails, run the Auto-Correct feature for the application
Navigation: The Custom Applications page is accessible from the Change Management Dashboard > Customization Manager region > Custom Applications link.
A custom application "definition" is de-coupled from registration. Once an application is defined, it can be registered on one or more instances.
A user must have the "Approve splice request" privilege to hide and unhide custom applications. By default, hidden custom applications will be invisible. A user can check "show hidden custom applications" box to view the hidden custom applications.
To define a new custom application
Navigate to the Custom Applications page. Select "New Custom Application" from the Add drop-down list and click Go. The Define Custom Applications page appears.
Specify an Application Short Name for your application. Note that only alphanumeric characters are allowed, and letters must be lowercase. The application short name is recommended to be prefixed with "xx".
Specify an Application Name for your application.
Optionally provide a description.
Click Submit to save your work.
Note that a custom application definition is not associated with any specific Oracle E-Business Suite instance but can be used to register the given custom application on one or more Oracle E-Business Suite instances.
To discover an existing custom application
Navigate to the Custom Applications page. Select "Existing Custom Application" from the Add drop-down list and click Go. The Discover Custom Applications page appears.
Select the custom application you wish to discover and click Submit. You can use the Search feature to narrow down the results the table.
To validate a custom application
Existing registered applications can be validated.
For more information on validation, see: Validation of Custom Applications: Examples.
Navigate to the Custom Applications page. Click the "Custom Application Requests" link under Related Links. The Custom Application Requests page appears. Select a request, and click the Validate button. Alternatively, you can also select the instance and click the Validate button from the custom application view details screen.
Enter in the Application Short Name for the application. You can use the LOV provided. Note that the Application Name defaults in.
Enter in the Oracle E-Business Suite instance. You can use the LOV provided. Note that the Preferred Credentials need to be set for this Oracle E-Business Suite instance.
Select "Generate Readiness Report for Online Patching" if desired. It reports Edition-Based Redefinition (EBR) violations in the specified custom schema that include objects not complying with the EBR rules about non-editioned objects (data storage objects such as tables and materialized views), and referencing editioned objects (code objects such as: packages, triggers, object types, and so on). This report also lists several naming standard violations that must be fixed prior to applying the online patching enablement patch for Release 12.2.
Click Submit. A job to validate the custom application will be submitted. Validation is based on certain standards and is provided by Oracle Applications DBA (AD) utilities.
To run Auto-Correct on a custom application request
If your request to validate a custom application fails, you can use the Auto-Correct feature to help you make the custom application conform to Oracle E-Business Suite standards.
Note: This feature can only be used on failed validation requests.
The user who submits the auto-correction request must have the splice request privilege.
The request must be approved for execution using Change Approval.
Navigate to the Custom Applications page. Click the "Custom Application Requests" link under Related Links. The Custom Application Requests page appears. Select a request and click the Auto-Correct button.
Note: If you choose a request that did not fail in the Validation step, you will receive the error "Only failed validation requests are shown for auto-correction."
In the Auto-Correct Custom Application page, enter the following:
Custom Application's Schema Password. If you do not enter a value, the application short name is used by default.
Email addresses for users to be notified regarding this request. (Optional)
Justification (Required)
Click Submit.
You can view your request in the Change Management dashboard, under Change Approval Requests.
Click on the name of the request to view details.
You can download the splice log if the corresponding job for your request has been purged and no longer exists in the Enterprise Manager system.
To register a custom application on an Oracle E-Business Suite instance
Navigate to the Custom Applications page. Click the "Custom Application Requests" link at the bottom of the page. The Custom Application Requests page appears. Select a request, and click the Register button. Alternatively, you can also click the Register button on the Custom Application details page.
Enter in the Application Short Name for the application. You can use the LOV provided. Note that the Application Name defaults in.
Enter in the Oracle E-Business Suite instance. You can use the LOV provided. Note that the required APPLSYS schema, APPS schema and system schema Preferred Credentials need to be set for this Oracle E-Business Suite instance.
Enter in an Application ID. Oracle recommends you use an application ID greater than 50000. Customization Manager automatically generates and defaults the recommended application ID.
Select "Run AutoConfig" if desired. AutoConfig execution is necessary for the custom application to be available for patching. Please run AutoConfig manually if you do not chose to run it during the custom application registration.
When change approval is enabled, enter e-mail addresses for Notification E-mail(s). In registering a custom application, you first submit a request to register the application. This request must then be approved (either automatically or manually, depending on your Change Approval Framework setup).
Enter a justification.
Click Submit. A request to register the custom application will be submitted.
To view details of custom application
View details of a custom application by navigating to Custom Applications, selecting the application name, and clicking the View button. Details include:
List of instances where custom application is present with status validated/not validated. If the status is not validated, it is recommended to use the Validate button to launch a validation request. A valid status ensures that custom patches for the given custom application can be applied on that instance.
Custom objects associated with the given custom application which are present on the given instance can be viewed by clicking on the "View Objects" icon. Customization Manager automatically discovers and relates the following objects associated with a custom application:
Custom Forms
Profile Options
Request Sets
Custom Database Objects
Alerts
Audit Group Information
All files in the File Metadata Repository for the given custom application.
List of packages that have been created for the custom application.
To track details of a custom application request
A custom application request can be used to register or to validate a custom application on a given instance.
Navigate to the Custom Applications page. Click the "Custom Application Requests" link at the bottom of the page. The Custom Application Requests page appears. Select a custom application request from the table and click View.
Details for the request will be shown.
Tip: To debug or view logs of a custom application request, click on “Job Details” icon against the specific custom application request. This would navigate to the EM job log associated with the custom application request. Click and view details on the “DO_JOB” step to view the detailed log of the given custom application request. In case of a failure of a custom application request, a new request should be submitted after rectifying the errors/failures listed in the job details log.
To execute a job to register or validate a custom application when the change approval system is enabled
Confirm that the request to execute the job to register or validate the custom application has been approved. To do this, navigate to the Custom Applications page. Click the "Custom Application Requests" link at the bottom of the page. The Custom Application Requests page appears. Approved requests will be listed with the Status "Approved".
Select an Approved custom application request from the table and click Execute.
At the Execute Custom Application Request page, ensure that the displayed information is correct and click Submit.
The system will attempt to execute a job to register or validate the custom application. If the system cannot execute the job, details regarding the job will be shown.