Oracle® Fusion Applications Patching Guide 11g Release 1 (11.1.1.5) Part Number E16602-08 |
|
|
View PDF |
This chapter describes how Oracle Fusion Applications Patch Manager supports middleware and database artifacts. It also provides detailed steps for the manual deployment of artifacts. For more information about applying patches, see Section 3.6, "End-to-End Patching Process".
This chapter contains the following topics:
Oracle Fusion Applications Patch Manager Middleware Artifact Support
Oracle Fusion Applications Patch Manager Database Artifact Support
Patching Oracle Business Process Management (Oracle BPM) Templates
Patching Oracle Forms Recognition and Oracle Document Capture Artifacts
Patching Sales Prediction Engine (SPE) Inline Service Artifacts
The online mode of Oracle Fusion Applications Patch Manager supports most of the deployment actions required for patching middleware and database artifacts used by Oracle Fusion Applications. Depending on the type of artifact included in a patch, the artifact deployment may require manual actions. Some manual actions are required only if you apply the patch in offline mode, while others are always required. Before applying any patch, Oracle recommends that you run the Patch Impact report to determine what artifact types are included in the patch and what actions are required by the patch. For more information, see Section 3.5.1, "Patch Impact Report".
Table 4-1 provides a quick reference that depicts how Oracle Fusion Applications Patch Manager supports the Oracle Fusion Middleware artifacts that could be included in a patch. This table assumes that online patching is used unless otherwise specified.
An explanation of the information presented in this table follows:
Automated Actions Performed by Oracle Fusion Applications Patch Manager
Oracle Fusion Applications Patch Manager always copies the artifacts from the patch to the appropriate location on your system. This column describes additional actions that are performed automatically in online mode for each artifact.
Actions to Be Performed Manually
This column describes the actions you must perform when the patch includes the specified artifact. These actions are required after the patch applies in online mode and are described in more detail in this chapter.
Actions to Be Performed Manually in Offline Mode and in the Case of Failures
This column describes the actions you must perform when the patch includes the specified artifact and you apply the patch in offline mode. If you apply the patch in online mode and there is a failure, these actions may also be required.
What Must Be Running During Online Patching Mode and Manual Actions
This column describes what servers must be running while applying the patch in online mode and when you perform manual actions.
After you apply a patch, review the Diagnostics report to find out which manual steps are required for the artifacts included in the patch and where the artifacts were copied in FA_ORACLE_HOME
. For more information, see Section 3.5.5, "Diagnostics Report". For more detailed information about manual actions for each artifact, refer to the relevant sections in this chapter.
Table 4-1 Oracle Fusion Middleware Artifacts Supported by Oracle Fusion Applications Patch Manager
Artifact Type | Automated Actions Performed by Oracle Fusion Applications Patch Manager | Actions to Be Performed Manually | Actions to Be Performed Manually in Offline Mode and in the Case of Failures | What Must Be Running During Online Patching Mode and Manual Actions |
---|---|---|---|---|
Applications Policies ( |
Deploy using the |
Back up the policy store before you apply the patch |
Deploy using Oracle Authorization Policy Manager |
Oracle Authorization Policy Manager, security policy server |
B2B Metadata |
None |
Deploy agreements if you want to implement the change |
Deploy agreements if you want to implement the change |
Database, see prerequisites in Section 4.3, "Patching Oracle B2B Metadata" |
Oracle Business Intelligence Publisher (Reports and Captions) |
Shut down the BI Presentation server, deploy to the Business Intelligence repository using Catalog Manager, and start the BI Presentation server after patching |
None |
Shut down the BI Presentation server, deploy to the Business Intelligence repository using Catalog Manager, and start the BI Presentation server after patching |
Shut down the BI Presentation server before patching |
Oracle Business Process Management (Oracle BPM) Template |
None |
Publish template to the Oracle Metadata Service (MDS) repository |
Publish template to the MDS repository |
Database |
C Artifact |
None |
None |
None |
Database must be running. Oracle Enterprise Scheduler Service server must be down. |
Common Resource (Activity Strings) |
None |
Stop and start all Managed Servers in all domains after patching |
Stop and start all Managed Servers in all domains after patching |
Administration Server, node manager, database |
Data Security |
Run the |
None |
Run the |
LDAP/security policy server, database |
Diagnostic Testing Framework JAR |
None |
None |
None |
None |
E-Mail and Web Marketing (EWM) |
Start and stop the relevant servers that host the Java EE application |
None |
Start and stop the relevant servers that host the Java EE application |
Administration Server, node manager, database |
Flexfield |
Stop and start the FNDSETUP Managed Servers and then deploy the flexfield |
None |
Stop and start the FNDSETUP Managed Servers and then deploy the flexfield |
Administration Server, Managed Servers hosting |
Group Space Template |
Deploy template |
None |
Deploy template |
WebCenter Managed Servers ( |
Image Routing (IPM) |
Deploy to IPM servers |
None |
Deploy to IPM servers |
See prerequisites in Section 4.12, "Patching Imaging and Process Management (IPM) Artifacts" |
Java EE |
Stop and start the relevant servers that host the Java EE application |
None |
Stop and start the relevant servers that host the Java EE application |
Administration Server, node manager, database |
Oracle Data Integrator (ODI) |
Import to ODI repository |
Drop work tables from FUSION_ODI_STAGE schema |
Import to ODI repository and drop work tables from FUSION_ODI_STAGE schema |
ODI repository import tool, database |
Oracle Forms Recognition and Oracle Document Capture (Windows) |
None |
Copy to Windows desktop and install |
Copy to Windows desktop and install |
None |
Oracle Fusion Applications Patch Manager |
None |
Apply the patch with OPatch |
Apply the patch with OPatch |
None |
Oracle Fusion Applications Help Content |
None |
Stop and restart help portal Managed Servers and start the crawl after patching |
Stop and restart help portal Managed Servers and start the crawl after patching |
None |
Data Role Template (RGX) |
None |
Deploy the template |
Deploy the template |
Administration Server, Oracle Authorization Policy Manager, database |
SOA Composite |
Deploy and merge |
None |
Deploy and merge |
Administration Server, SOA-INFRA Managed Servers, database |
SOAEXTENSION |
None |
Stop and restart all SOA-INFRA Managed Servers in all domains |
Stop and restart all SOA-INFRA Managed Servers in all domains |
None |
SOA Resource Bundle |
Deploy resource bundle and restart dependent composites |
Reset SOA-INFRA |
Deploy resource bundle and restart dependent composites |
Administration Server, SOA-INFRA Managed Servers, node manager, database |
SPE Inline Service |
None |
Deploy SPE files |
Deploy SPE files |
Oracle BI Server, database |
Table 4-2 provides a quick reference that displays the Oracle Fusion Applications database artifacts that could be included in a patch. Database artifacts typically do not require manual actions be performed during either online or offline mode. Database artifacts are copied and deployed automatically in both modes. Before patching database artifacts, the database must be in an idle state with no locks being held on any of the database objects. All background jobs, including jobs in the database, must be terminated prior to patching to avoid locks on patched objects. There should not be any active processes, such as Oracle Enterprise Scheduler Service jobs running against the database. This is to prevent locking and other data issues during patching.
Table 4-2 Oracle Fusion Applications Database Artifacts Supported by Oracle Fusion Applications Patch Manager
Artifact Type | Description | Actions to be Performed Manually |
---|---|---|
Applications Seed Data (XML,XLIFF files) |
Examples include static lists of values, functional or error messages, and lookup values. Any non-transactional data values loaded into your database can be considered seed data. |
Oracle recommends that patches containing seed data be applied from a machine that is collocated in the same subnetwork as the database server to maximize performance. |
Applications Database schema changes (SXML) |
Examples include tables, triggers, views, sequences, synonyms, queues, queue tables, policies, and contexts. |
None |
PL/SQL objects (pkh, pkb files) |
Package headers and bodies. |
Manually shut down the Oracle Enterprise Scheduler Service servers before applying patches that contain PL/SQL changes. |
SQL scripts |
Scripts that update the database. |
None |
When Oracle B2B metadata updates are introduced in a patch, and you want to implement the change, you must redeploy all Trading Partner Agreements that are affected by the metadata change. If you do not perform the redeployment, the runtime continues to use the older metadata. You can deploy the agreements using the B2B User Interface (UI) or by running the b2bdeploy
utility from the command line. Note that this is a manual process.
To deploy all agreements from the UI, follow the steps in "Deploying an Agreement" in the Oracle Fusion User's Guide for Oracle B2B.
To import the patched metadata, follow these steps:
Follow the steps in "Prerequisites for Running the Command-line Tools" in the Oracle Fusion User's Guide for Oracle B2B.
Export the entire repository for backup purposes.
ant -f ant-b2b-util.xml b2bexport -Dexportfile=/tmp/backup_export.zip
Import the patched export file.
ant -f ant-b2b-util.xml b2bimport -Dexportfile=/tmp/patch_export.zip -Dlocalfile=true -Doverwrite=true
Run the b2bdeploy
command. If there is no Trading Partner Agreement found, this step is not needed.
ant -f ant-b2b-util.xml b2bdeploy - Dtpanames="Acme_GC_Agreement1,GC_Acme_Agreement1"
If the patch introduces new documents for Trading Partner agreements, you must add the document definition. For more information, see "Adding Document Definitions" in the Oracle Fusion Middleware User's Guide for Oracle B2B.
For more information about the b2bdeploy
command, see "Deploying Agreements" in the Oracle Fusion User's Guide for Oracle B2B.
When you patch Oracle Business Intelligence Publisher (BI Publisher) artifacts (Reports and Captions) in online mode, Oracle Fusion Applications Patch Manager shuts down the BI Presentation Server before the patch applies and restarts it after successful patch application. No manual steps are required in online patching mode. If the shutdown of this server fails for any reason, you must manually deploy the BI Publisher artifacts.
Oracle recommends you do not use offline mode when a patch contains BI Publisher artifacts. If you decide to apply a patch in offline mode, you must manually deploy the changes to the Oracle Business Intelligence repository in addition to stopping and restarting the BI Presentation server. These manual steps are required to keep the Oracle home and the Oracle Instance versions of the Oracle Business Intelligence Presentation Catalog synchronized. If these manual steps are not followed as described, subsequent patches containing BI Publisher artifacts may fail.
For more information, see "Starting and Stopping Oracle Business Intelligence" in the Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.
Assumptions made for manual BI Publisher artifact deployment:
Oracle Fusion Applications Patch Manager copied one or more Oracle BI Presentation Catalog files into the Oracle home-based catalog.
Within the patch, there are some catalog diff files. These files are used with the Oracle Business Intelligence Catalog Manager tool to apply changes to a catalog. These changes must be applied to:
The run-time, or Oracle Instance, Oracle BI Presentation Catalog
The Oracle home Oracle BI Presentation Catalog
Special care must be taken when the patch being applied is a standard patch. With a standard patch, OPatch may choose to copy only a subset of the total files in the patch archive.
Before performing the following manual steps, you must first determine exactly which files were actually copied to the Oracle home during the OPatch apply stage. You can review the Patch Impact report to get this list of files. You can also capture the list of files from the messages sent to the console and to the FAPatchManager
_apply
_timestamp.log file.
After you have that list, you must apply only the diff files that correspond to the files that were actually copied to the Oracle home. The diff files are named the same as the original files, except they have a .diff extension added. If additional diff files are applied beyond the files that were actually copied to the Oracle home, then previous patch updates may be undone and the Oracle BI Presentation Catalog may be in an unsupportable state. Basically, you have partially rolled back a previous patch.
To manually deploy BI Publisher artifacts when applying patch in offline mode:
Shut down the BI Presentation server.
Unzip the middleware portion of the patch, the OPatch archive file, into a temporary location, such as C:\patch
. To see which files are included in the patch, run the Patch Impact report. For more information, see Section 3.5.1, "Patch Impact Report".
Go to the C:\patch\custom\scripts
directory.
Locate the Catalog Manager diff files listed in the subdirectories under the directory in Step 2. These files have .diff extensions.
Use Catalog Manager to apply each of these diff files to the Oracle home Oracle BI Presentation Catalog, using the following commands:
Create the Catalog Manager patch file.
oracle-instance/runcat.cmd -cmd createPatch -inputFile diff_file_location -production webcat_location -outputFile webcat_patch.out -winsConflict latest
diff_file_location is the file from Step 3.
webcat_location is the Oracle home Oracle BI Presentation Catalog location.
webcat_patch.out is a temporary file created by this step and used Step 4b.
Apply the Catalog Manager patch file.
oracle-instance/runcat.cmd -cmd applyPatch -inputFile webcat_patch.out
-outputFile -persistNewApplicationsRoles webcat_applypatch.out
webcat_patch.out is the file created in Step 4a.
webcat_applypatch.out is the output file from this deployment process.
Repeat Step 4 for the run-time catalog.
Restart the Oracle Business Intelligence system components using opmnctl
:
cd ORACLE_HOME/admin/instancen/bin ./opmnctl stopall ./opmnctl startall
When updates to Oracle BPM templates are introduced in a patch, you must manually publish the new Oracle BPM Template to the Oracle Metadata Service (MDS) repository supporting the Oracle BPM Composer instance after you apply the patch. You use the publish_template
WebLogic Scripting Tool (WLST) command from the WLST shell. The WLST publish_template
command connects to the SOA MDS data using the mds-config.xml
configuration file that you create. You must provide the location of the mds-config.xml
configuration file for one of the input parameters of the publish_template
command.
To create the mds-config.xml configuration file:
Copy the mds-config-template.xml
file from your SOA server installation to a temporary directory.
cp SOA_ORACLE_HOME/bpm/config/mds-config-template.xml /tmp/mds-config.xml
Modify the following properties in the file you just copied to the temporary directory:
Set jdbc.userid
to the database user name of the SOA MDS database
Set jdbc.passwd
to the database password of the SOA MDS database
Set jdbc.url
to the connection URL of the SOA MDS database, for example, jdbc:oracle:thin:@host2:1525:mds
Set partition.name
to obpm
To publish the new Oracle BPM template to the MDS repository:
Review the Diagnostics report to find the location of the archive file that contains the BPM template. For more information, see Section 3.5.5, "Diagnostics Report".
Expand the archive that contains the new BPM template, so the publish_template
command can find the template.
Create or use an existing temporary directory.
Untar the patched archive file, as shown in this example:
cd /tmp
mkdir preboardWorker
cd preboardWorker
jar xf FA_ORACLE_HOME/hcm/deploy/bta_HcmCommonProcessesPreboardWorkerComposite.jar
Access the WLST shell.
(UNIX) SOA_ORACLE_HOME/common/bin/wlst.sh (Windows) SOA_ORACLE_HOME\common\bin\wlst.cmd
Deploy the Oracle BPM template, passing the temporary directory, /tmp/preboardWorker
, as the directory containing the template in the example in Step 1.
Generic command syntax follows:
publish_template(templateName, fsLocation, mdsconfigLocation, [Override], [oracleHome] )
See "publish_template" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference for the publish_template
command syntax.
Note that the publish_template
command simply updates the existing Oracle BPM template with a newer version. It has no impact on the projects deployed or instantiated from the existing template.
When updates to C artifacts are introduced in a patch, no manual steps are required in either online or offline mode. Note that before applying C artifacts, all C executable files and the Oracle Enterprise Scheduler Service servers that host the C files must be shut down and the database must be running. For more information, see "Starting and Stopping Oracle Enterprise Scheduler Service Components" in the Oracle Fusion Applications Administrator's Guide.
When updates to Common Resource artifacts are introduced in a patch, the Administration Server, node manager, and database must be running. You must stop and restart all Managed Servers in all domains after you apply the patch.
No manual steps are required when patching DTF artifacts in either online or offline mode.
Oracle recommends you patch EWM artifacts in online mode. When updates to EWM artifacts are introduced in a patch, no manual steps are required in online mode. In offline mode, follow the steps in Section 4.13, "Patching Java EE Artifacts".
Oracle recommends that you patch flexfield artifacts in online mode. When flexfield changes are introduced in a patch, no manual steps are required to deploy the flexfields in online mode. The following must be running during patching:
Administration Server
Managed Servers that host the FndSetup
application
Database
Users must log out and log in after a successful patch application to see the latest flexfield changes because flexfields reload upon user logout and login.
To deploy patched flexfields manually
Follow these steps after patching flexfields in offline mode to manually deploy the patched flexfields.
Ensure that the Administration Server and database are running.
Stop and start the FNDSETUP
Managed Servers. For more information, see "Starting and Stopping".
Connect to the Oracle WebLogic Server Administration Server for the domain that hosts the FndSetup
application. This is typically the Common Domain.
Run the deployPatchedFlex()
WLST command. Because you run this on a domain that hosts the FndSetup
Application, you do not have to specify this application within the parentheses. However, the FndSetup
application must be running for the command to succeed.
Example:
connect('weblogic' , 'weblogic1' , 't3://localhost:7101') deployPatchedFlex()
Review the report for errors.
Example of confirmation that flexfield changes were successfully deployed
As an example, assume that the patch delivered a new flexfield segment to the Calculation Defaults in Payroll Definitions. To confirm that the new flexfield segment was successfully deployed, follow these steps in your Payroll application:
From your Oracle Fusion Payroll application, select Manage Payroll Definition.
Click the Create a New Payroll icon.
Select a Legislative Data Group.
Confirm that the new flexfield segment appears under Calculation Defaults.
When a Group Space template is included in a patch, the patch introduces a new template with a version number attached, which is unlike other artifacts where the patched version replaces the existing one. If you have any customizations on this template that the patched version will replace, you must manually incorporate the customizations in the new version of the template. If you have any settings or configurations that refer to the Group Space template name, ensure that you update these to reflect the new template name. For all WebCenter services configured in a Group Space template, ensure that connections are configured properly.
Oracle recommends that you patch Group Space templates in online mode. When updates to Group Space templates are introduced in a patch and you have not customized the template included in the patch, no manual steps are required in online mode, except to ensure that the following servers must be running:
WebCenter Managed and Servers: WC_Spaces,
WC_Utilities
Oracle UCM Managed Server, ucm_server1
LDAP Policy Store Server
To manually deploy Group Space Templates when patching in offline mode:
In offline mode, you must manually deploy the new Group Space template using the importGroupSpace
WLST command.
Ensure that the following WebCenter Managed Servers are running:
WebCenter Managed Servers: WC_Spaces, WC_Utilities
Oracle UCM Managed Server, ucm_server1
LDAP Policy Store Server
Access the WLST shell from the Oracle home where WebCenter is installed.
(UNIX) WC_ORACLE_HOME/common/bin/wlst.sh (Windows) WC_ORACLE_HOME\common\bin\wlst.cmd
Deploy the Group Space template.
importGroupSpaces('appName', 'fileName')
The appName
is always webcenter
and the fileName
is the name of the WebCenter archive file, from the patch, that you want to import. Refer to the Diagnostics report to get the full path and file name. For more information, see Section 3.5.5, "Diagnostics Report".
For more information about this command syntax, see "importGroupSpaces" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference. For more information about Group Space templates, see "Importing Space Templates" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.
Oracle recommends you patch IPM artifacts in online mode. When updates to IPM artifacts are introduced in a patch, no manual steps are required in online mode, other than ensuring all prerequisites are met. In offline mode, you must manually deploy the IPM artifacts.
Prerequisites for the deployment of IPM artifacts:
The imaging application must be running. The format for the IPM URL is http://
<host name>:<Port>
/imaging/.
The Financials SOA_INFRA server must be running.
The Financials Payables Invoice and Expense Report SOA composites must have been successfully deployed and be in an active state.
The FIN wsm-pm
application must be in an active state, which means your FinancialCommon
server must be running.
The IPM to UCM connection, "Fusion Applications UCM Connection", must exist.
The IPM to SOA connection, "Financial SOA Connection", must exist.
The IPM Input should be set to Offline from the Manage Inputs section of the IPM UI. For example, you can select Invoices under Manage Inputs and then deselect Online under Basic Information.
Follow these steps to back up the existing IPM application definition:
Log in to the IPM server as the IPM superuser.
From Tools, select Export Definitions.
Export your Oracle Fusion Payables Application and Expenses Application, all related searches, and inputs to a local file.
To manually deploy IPM artifacts:
Review the Diagnostics report to find the location of the IPM artifacts that were copied to FA_ORACLE_HOME
. For more information, see Section 3.5.5, "Diagnostics Report".
Access the WLST shell.
(UNIX) ECM_ORACLE_HOME/common/bin/wlst.sh (Windows) ECM_ORACLE_HOME\common\bin\wlst.cmd
Deploy the IPM artifact.
connect(IPM Server user name,IPM Server password,IPM Server hostname:port) importIPMApplication(ipmAppFile,'Update',appDefName,'None'); importIPMInput(ipmAppFile,'Update',inputDefName);
Example:
connect('FAadmin','fusion','t3://server01.us.oracle.com:17014'); importIPMApplication(exportFile='/net/server01/fusionapps/applications/fin/ap/ipm/ApInvoiceIpmApp.xml', action='Update', name='Payables Invoice Application','None') importIPMInput(exportFile='/net/server01/fusionapps/applications/fin/ap/ipm/ApInvoiceIpmApp.xml', action='Update', name='Payables Invoice Input')
If applicable, perform your customizations on the new file, based on the file you exported.
Oracle recommends you patch Java EE artifacts in online mode. When you patch Java EE artifacts in online mode, no manual steps are required. The Administration Server, node manager, and database must be running on both offline and online mode.
In offline mode, you must manually stop, patch, and restart the impacted Managed Servers that host the Java EE application. To determine which product family is affected by the patch you are applying, run the Patch Impact report. For more information, see Section 3.5.1.1, "Running the Patch Impact Report". For example, if the Patch Impact report indicates that the patch updates a Java EE artifact in the Financials Domain, then you stop and start the Financials Domain after the patch applies successfully. Examples of artifacts in this category include Oracle ADF Resource JAR files and Oracle Enterprise Scheduler Service MAR files.
For more information about stopping and starting servers, see "Starting and Stopping a Product Family Oracle WebLogic Server Domain" in the Oracle Fusion Applications Administrator's Guide.
Oracle recommends that you patch ODI artifacts in online mode. When updates to ODI artifacts are introduced in a patch, Oracle Fusion Applications Patch Manager imports the ODI changes in online mode. If you patch ODI artifacts in offline mode, you must manually import the changed ODI content to the ODI repository. In both online and offline modes, the ODI repository import tool and the database must be running and you must manually drop the work tables from the FUSION_ODI_STAGE schema.
Note:
Oracle Fusion Applications Provisioning does not install ODI Studio. You must install ODI Studio before manually importing ODI changes, for example, after you apply patches that deliver ODI changes in offline mode or when you need to manually retry a failed ODI import step in online mode. For more information, see "Installing Oracle Data Integrator" in the Oracle Fusion Middleware Installation Guide for Oracle Data Integrator.
To drop work tables after patching in online mode
After you apply a patch that contains ODI artifacts in online mode, you must manually drop the work tables from the schema, FUSION_ODI_STAGE
.
Connect to the Oracle Fusion Applications database with the correct privilege.
Drop all tables that begin with E$ from the FUSION_ODI_STAGE
schema.
To import ODI changes when patching in offline mode:
Oracle recommends that the ODI import be performed from a machine that is collocated in the same subnetwork as the database server to maximize performance.
Review the instructions in the patch README file to determine which ODI Project or Model must be deleted and reimported. The patch README file contains a list of the ODI files that are included in the patch, in the order that they must be imported.
Review the Diagnostics report to determine the location and file name for each ODI artifact that is to be imported. For more information, see Section 3.5.5, "Diagnostics Report".
Start the ODI Studio.
(UNIX) odi.sh (Windows) odi.exe
Access the ODI Studio.
Select View, then ODI Designer Navigator.
Click Connect to Repository.
Log in using the superuser name and password for the ODI repository.
For more information, see "Connecting to a Work Repository" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.
Delete the Model or Project if specified in the patch README file. The README file specifies whether any Model or Project must be deleted and in what order.
Right-click the Model or Project name and click Delete.
Import the ODI files in the order they are listed in the patch README file.
To import a project, right-click the Project name and click Import, then Import Project.
To import a model, right-click the Model name and click Import, then Import Model.
Select Synonym Mode INSERT_UPDATE from the list in the Import Dialog window.
For the File Import directory, select the directory that contains the ODI file you want to import.
Select the ODI file to import.
Click OK to import.
Repeat Steps 5 and 6 for each Model or Project in the patch.
For more information, see "Exporting/Importing" in the Oracle Fusion Middleware Developer's Guide for Oracle Data Integrator.
Close the ODI Studio after importing all the files in the order specified in the ODI patch README file.
Connect to the Oracle Fusion Applications database with the correct privilege.
Drop all tables that begin with E$ from the FUSION_ODI_STAGE
user.
Oracle Forms Recognition (OFR) and Oracle Document Capture (ODC) artifacts are used by only Windows. When you apply a patch that contains OFR and ODC artifacts, Oracle Fusion Applications Patch Manager backs up your customized files, if any, before copying the new files to FA_ORACLE_HOME. You must then manually install the OFR and ODC artifacts.
If you previously customized the AP_Packaged_Project_1004a.ini
file, then you should not install this file from the patch as the patch delivers it. Instead you should keep your existing file and copy the file from the patch to a directory with a different name. Then you should compare the files and manually update your existing file with the changes in order to preserve your customizations.
Review the Patch Impact report to find the location of the files related to OFR. For more information, see Section 3.5.1, "Patch Impact Report".
Rename the file AP_Packaged_Project_1004a.ini
to another name as a backup and copy APPLICATIONS_BASE/fusionapps/fin/ap/ofr
/AP_Packaged_Project_1004a.ini
to a new file on the Windows environment.
Move this .ini
file to the OFR AP Project directory, which is located in the OFR directory structure, Projects\AP\Global
(for example, C:\Program Files\OFR\Projects\AP\Global
). If you see the existing AP_Packaged_Projects_1004a.ini
file in this location, rename it to a backup file.
Create a data link:
Click the Windows Start menu button.
Select Run.
Enter Notepad into the Open field and click OK.
Note:
Do not right click on the desktop to create a new file. Windows will assign a hidden file type to the file that will interfere with the following steps.
Click File - Save.
Navigate to the Desktop folder.
In the File name field, enter the following, including quote marks: "odbc_dns
.udl
". Substitute the actual ODBC data source name for odbc_dns
. The data source name can be found by opening the Control Panel, then Administrative Tools, and Data Source (ODBC).
Click Save.
Find the file on the desktop and double-click it to open the Data Link Properties dialog. If a text file is opened instead, go back and carefully follow the instructions for creating this file again.
Set Data Source:ODBC data source name
Select the Use a specific user name and password option.
Enter the READ-ONLY user name and password
Select the Allow saving password option.
Select Test Connection.
Click OK. An example of the file contents follows:
Provider=MSDASQL.1;Password=fusion;Persist Security Info=True;User ID=fusion;Data Source=ffinde
Open the data link (.udl
file) that you previously created.
Click the Windows Start menu button.
Select Run.
Enter Notepad into the Open field and click OK.
Open the .udl
file.
From the .udl
file, copy the entire string, starting with Provider=.
Open the AP Packaged Project_1004a.ini
file (under C:\OFR_Projects\AP\Global) in another instance of Notepad and make the following changes:
Replace the connection string for the line starting with SQL_VL_01_ConnectionString=, with the text you copied in Step 5.
Update attribute ASA_VL_01_ImportODBCDSN
with the System DSN name of the Oracle Fusion Applications database.
Update attribute ASA_VL_01_ImportODBCUser
with the READ-ONLY user name.
Update the attribute, ASA_VL_01_ImportODBCPWD
, with the READ-ONLY account password.
Proceed with any additional customizations on the .ini
file, as required by your implementation.
Verify your changes.
Save and close the file.
To install ODC artifacts:
Install the ODC Import-Export Utility from the Companion DVD, if you have not already done so.
Copy the ODC metadata ZIP files from APPLICATIONS_BASE
/fusionapps/fin/ap/odc
and APPLICATIONS_BASE
/fusionapps/fin/exm/odc
to a temporary directory in the Windows desktop environment.
Go to Start, then Oracle Document Capture, then Import-Export Utility and log in. The user name is ADMIN
and the password is admin
.
In the utility, go to File - Import or click Import and then import the metadata files one at a time. Ensure that all files are imported.
When updates to Oracle Fusion Applications Patch Manager are introduced in a patch, you must apply the patch with the OPatch utility. For more information, see "Patching Oracle Fusion Middleware with Oracle OPatch" in the Oracle Fusion Middleware Patching Guide.
During provisioning, the data model for Oracle Fusion Applications Patch Manager is updated by running the fapmgr bootstrap
command. If the data model is updated again by a patch, the patch README file instructs you to run the fapmgr bootstrap
command.
Use this syntax to run bootstrap
:
(UNIX) lcm/ad/bin/fapmgr.sh bootstrap [-logfile log_file_name] [-loglevel level] (Windows) lcm\ad\bin\fapmgr.cmd bootstrap [-logfile log_file_name] [-loglevel level]
Oracle Fusion Applications Help requires content patches to ensure that users do not encounter a "Help Unavailable" message and to make certain the version of help is available to users for subsequent releases. There can be multiple patches required for the delivery of the latest version of Oracle Fusion Applications Help. If more than one patch is required for an update, the required patches are listed as prerequisite patches. You must apply all required patches to avoid broken links. Refer to the Oracle Fusion Applications release notes to get the patch numbers for the latest version of Oracle Fusion Applications Help.
Oracle Fusion Applications Help is delivered in patches that contain two types of content:
A Seed Data Files patch that contains updated help topics for uploading to the database
Reference content patches that may contain:
BPM diagrams
User Productivity Kit demos
Oracle Fusion Applications Middleware library
To apply Oracle Fusion Applications Help patches
Run the Patch Impact report to determine the patch content. For more information, see Section 3.5.1, "Patch Impact Report".
Apply the patches with Oracle Fusion Applications Patch Manager. For more information about applying Oracle Fusion Applications patches, see Section 3.4, "Applying Patches".
Stop and restart the help portal Managed Servers in the HelpPortalCluster
in the Common domain after the patch is successfully applied.
Manually start the crawl using Oracle Enterprise Crawl and Search Framework (ECSF) so users can see the results immediately. You can create or modify an index schedule to run manually and then start the schedule. If you do not manually start the index schedule, the content will be included during your next scheduled index schedule. For more information about ECSF scheduling, see "Managing Index Schedules" in the Oracle Fusion Applications Administrator's Guide.
In Oracle Fusion Applications, the following artifact types related to security can be patched:
Function Security Policies (Applications Policies, using the jazn-data.xml
file)
Data Security Grants (using Seed Data)
Data Role (RGX) Templates
JAR files secured by the Data Security Grants and Function Security Grants
A patch can contain one or more of these artifacts. This section describes the steps for applying security patches and recovering from patch failures. Examples of scenarios when you may need to follow the recovery steps include:
You apply a security patch that introduces a set of new policies and LDAP GUIDs, after backing up the policy store and the applications database. You have not performed the GUID reconciliation with the applications database due to an unrelated database issue. To resolve the database issue, you restore from the backup, resulting in the policy store containing extra GUIDs from the database and a synchronization issue between the policy store and the database.
You apply a security patch that includes updates to the applications policies and the patch fails, resulting in a set of LDAP GUIDs not applying correctly.
The patching and recovery scenarios for the following combinations of security artifact patches are included:
Oracle recommends that you apply security patches in online mode and run the Patch Impact report to understand which artifacts are included in the patch. The Patch Impact report displays security artifacts as JAZN
, Data Security
, and RGXTEMPLATE
. For more information, see Section 3.5.1, "Patch Impact Report".
For more information about general troubleshooting for Oracle Fusion Applications Patch Manager, see Chapter 9, "Monitoring and Troubleshooting Patches". For more information about security in Oracle Fusion Applications, see "Securing Oracle Fusion Applications" in the Oracle Fusion Applications Administrator's Guide.
Oracle Fusion Applications uses the XML file jazn-data.xml
to package function security policies through application roles, role hierarchies, grants, and policies. Function security policies are shipped as a jazn-data.xml
file that resides in the Oracle home. After provisioning, these policies are migrated to an LDAP Policy store. The file jazn-data.xml
resides in both the Oracle home and on the LDAP server. Patching function security policies requires steps to absorb changes delivered by Oracle (jazn-data.xml
in a patch), changes currently deployed, which include changes by you (policies in the LDAP server), and jazn-data.xml
contents previously shipped from Oracle (jazn-data.xml
in the Oracle home).
Oracle Fusion Applications Manager provides a comprehensive analysis tool that runs during patch validation to check for conflicts in applications policy changes before you apply the patch. If a change is considered safe, you can apply the patch in online mode. If a change is considered to be a conflict, you must follow the steps to apply the patch in offline mode, which includes manually resolving conflicts. Table 4-3 describes a summary of changes that are safe and those that cause a conflict.
Table 4-3 Changes to Applications Policies
Type of Change | Safe - Apply Patch in Online Mode | Conflict - Apply Patch in Offline Mode |
---|---|---|
Addition |
New artifacts shipped from Oracle. |
Artifacts retained by Oracle in a patch with or without modifications, but deleted by the customer. |
Modification |
Artifacts modified by Oracle in a patch but not by the customer. |
Artifacts modified by Oracle in a patch and by the customer. |
Deletion |
All artifact deletions must be applied in offline mode. |
|
For more information about what the jazn-data.xml
file contains, see the "Authorization for Java SE Applications" chapter in the Oracle Fusion Middleware Security Guide. For more information about patching applications policies, see the "Upgrading Oracle Fusion Applications Policies" chapter in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).
Prerequisites for patching applications policies in online mode
Oracle recommends that you patch applications policies in online mode because Oracle Fusion Applications Patch Manager automates the deployment of the jazn-data.xml
file by running the patchPolicyStore
silent install command.
Ensure that the following steps are completed before patching applications policies in online mode.
Validate the patch in online mode and ensure that the validation output does not contain any conflicts. For more information, see Section 3.3, "Validating Patches" and Table 4-3, "Changes to Applications Policies".
If the validation reports any conflicts, then you cannot apply the patch in online mode. Apply the patch in offline mode, as described in "To patch applications policies in offline mode".
Back up function security policies in the Oracle Internet Directory (OID) Policy store by following the steps in "Prerequisites to Patching Policies" in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).
Shut down all domains, except the APM UI and the JAZN policy server, before the patch applies.
To patch applications policies in offline mode
The following steps must be performed if you patch applications policies in offline mode.
Note:
All domains, except the APM UI and the JAZN policy server, must be shut down before JAZN patching and restarted after JAZN patching.
Run the Patch Impact report to see which artifacts are included in the patch. For more information, see Section 3.5.1, "Patch Impact Report". Note the location where jazn-data.xml
is located in the patch, because you are prompted for this location in Step 4.
Back up function security policies in the Oracle Internet Directory (OID) Policy store by following the steps in "Prerequisites to Patching Policies" in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).
Run Oracle Fusion Applications Patch Manager to apply the patch, which copies jazn-data.xml
from the patch to the Oracle home in offline mode. For more information, see Section 3.4, "Applying Patches".
Log in to Authorization Policy Manager.
Open the Policy Upgrade Management tab. Follow the steps in "The Policy Upgrade Management Tab" in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition). When you select the application to patch from the pull-down Application list, you should see choices such as the following:
fscm_system-jazn-data.xml: FSCM stripe
crm_system-jazn-data.xml: CRM stripe
hcm_system-jazn-data.xml: HCM stripe
bip_jazn-data.xml: OBI stripe
Follow the steps in "Analyzing Patch Differences" and "Resolving Patch Differences" in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition). If there are any errors during this step, restore the backup, as described in "Prerequisites to Patching Policies" in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).
Restart all Oracle Fusion Applications domains.
Oracle delivers changes to jazn-data.xml
in its own patch. Related code change patches, if any, should be applied only after all of the steps in this section complete successfully.
Oracle recommends that you patch data security grants in online mode. When data security grant changes are introduced in a patch, no manual steps are required in online mode to update the data security subsystem with the GUIDs of new application roles seeded in the policy store. In offline patching mode, you must manually run the DSDataMigrator
utility as described in "Reconciling GUIDs" in the Oracle Fusion Applications Administrator's Guide. In both online and offline patching mode, you must ensure that the prerequisites are met.
Prerequisites for patching data security grants
Run the Patch Impact report to see which artifacts are included in the patch. For more information, see Section 3.5.1, "Patch Impact Report".
Back up the data security store by using the Oracle Database data pump export tool. For more information, see Section 4.18.5, "Backing up the Data Security Store".
Patching data security grants
Run Oracle Fusion Applications Patch Manager to apply the seed data changes to the data security system. For more information, see Section 3.4, "Applying Patches". When data security changes are introduced in a patch, no manual steps are required in online mode to update the data security subsystem with the GUIDs of the new application roles seeded in the policy story. In offline mode or in the case of patch failure, you must manually run the DSDataMigrator
utility as described in "Reconciling GUIDs" in the Oracle Fusion Applications Administrator's Guide.
If there are any database errors during Step 1, such as running out of tablespace, fix the database errors that occurred and restart the patch.
If you are unable to resolve the errors that occurred while applying the seed data changes, recover the seed data from the backup export file you created in Step 2 of the prerequisites. For more information, see Section 4.18.6, "Recovering Data Security Seed Data from the Backup".
Follow the steps in this section when you apply a patch that contains data role templates, in both online and offline mode. Every data role template consists of two XML files. One is for data role generation and the other XML file is for data security policies generation. Both of these files must be deployed after you apply a patch that contains changes to data role templates, so they remain synchronized with each other.
To patch data role templates
Run the Patch Impact report to see which artifacts are included in the patch. For more information, see Section 3.5.1, "Patch Impact Report". Note that the Patch Impact report refers to data role templates as RGXTEMPLATE
.
The following must be running while patching data role templates:
Administration Server
Oracle Authorization Policy Manager
Database
Run Oracle Fusion Applications Patch Manager to copy the data role templates to FA_ORACLE_HOME
. For more information, see Section 3.4, "Applying Patches".
To create a save point before deploying the data role templates, use the createMetadataLabel
WLST command to label the MDS partition for oracle.security.apm
, using the following syntax:
createMetadataLabel(application, server, name)
The following example creates the label data_role_save_point
for the application oracle.security.apm
deployed in the Administration Server:
createMetadataLabel('oracle.security.apm', 'AdminServer', data_role_save_point')
For more information, see "createMetadataLabel" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.
Follow these steps to manually deploy the data role templates using the importMetadata
WLST command against the Administration Server in the common domain for the oracle.security.apm
application:
Access the WLST shell.
(UNIX) SOA_ORACLE_HOME/common/bin/wlst.sh (Windows) SOA_ORACLE_HOME\common\bin\wlst.cmd
Connect to WebLogic Server.
> connect ('admin user name','admin user password','URL of the AdminServer')
Deploy the data role template using the importMetadata
WLST command. Refer to the Diagnostics report to find the directory where the template was copied. For more information, see Section 3.5.5, "Diagnostics Report".
Syntax for the importMetadata
command:
importMetadata(application='oracle.security.apm', server='Name of AdminServer', fromLocation='Directory in FA_ORACLE_HOME where data role templates were copied', docs='Path to the changed data role templates starting with APM partition')
Table 4-5 displays the parameters required by the importMetadata
command.
Table 4-4 Parameters for the importMetadata WLST Command
Parameter Name | Description |
---|---|
application |
Enter the value of |
server |
Enter the name of your Administration Server |
fromLocation |
Enter the absolute path to the directory in |
docs |
Enter the directory for the APM partition, starting with |
Example 4-1 Importing the FinancialAssetBook.xml data role template
In this example, the FinancialAssetBook.xml
data role template is located in this directory:
(UNIX)/net/server01/fusionapps/applications/fin/fa/apm/oracle/apps/apm/fin/fa/rgx/template (Windows)\net\server01\fusionapps\applications\fin\fa\apm\oracle\apps\apm\fin\fa\rgx\template
Example of the importMetadata
command:
(UNIX) importMetadata(application='oracle.security.apm', server='AdminServer', fromLocation='/net/server01/fusionapps/applications/fin/fa/apm', docs='/oracle/apps/apm/fin/fa/rgx/template/FinancialAssetBook.xml' (Windows) importMetadata(application='oracle.security.apm', server='AdminServer', fromLocation='\\net\\server01\\fusionapps\\applications\\fin\\fa\\apm', docs='/oracle/apps/apm/fin/fa/rgx/template/FinancialAssetBook.xml'
Example 4-2 Importing multiple XML files in one command by using a wild card in the docs parameter
The XML file for data role generation is located in this directory:
(UNIX) /net/machine1/oracle/apps/oracle/fin/gl/rgx/template/GeneralLedger.xml (Windows) \net\machine1\oracle\apps\oracle\fin\gl\rgx\template\GeneralLedger.xml
The XML file for data security policies generation is located in this directory:
(UNIX) /net/machine1/oracle/apps/oracle/fin/gl/rgx/dataSecPolicy/fndDataSecProvider/GeneralLedger.xml (Windows)\net\machine1\oracle\apps\oracle\fin\gl\rgx\dataSecPolicy\fndDataSecProvider\GeneralLedger.xml
The following command imports both XML files at the same time:
(UNIX) importMetadata(application='oracle.security.apm', server='AdminServer', fromLocation='/net/machine1', docs='/oracle/apps/oracle/fin/gl/**' (Windows) importMetadata(application='oracle.security.apm', server='AdminServer', fromLocation='\\net\\machine1', docs='/oracle/apps/oracle/fin/gl/**'
For more information, see "Importing WebCenter Services Metadata and Data (WebCenter Portal Applications)" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.
If there are any errors in Step 5, follow these steps to recover by restoring the data role templates:
Promote the MDS label created in Step 4 using the following command:
promoteMetadataLabel(application, server, name)
The following example promotes the metadata label data_role_save_point
to the oracle.security.apm
application deployed in the Administration Server:
promoteMetadataLabel('oracle.security.apm', 'AdminServer','data_role_save_point')
For more information, see "promoteMetadataLabel" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.
Delete any new data role templates that were delivered in the patch, using the following command:
deleteMetadataLabel(application, server, name)
The following example deletes the data role templates in the metadata label data_role_save_point
from the oracle.security.apm
application deployed in the Administration Server:
deleteMetadataLabel('oracle.security.apm','AdminServer','data_role_save_point')
Assuming Steps 3 through 5 are successful, Oracle recommends that you preview the execution of your changed data role templates. Run the preview from the Summary tab after you open the data role template from the APM console. For more information, see "Running a Template" in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).
If the preview results are not correct, follow the recovery described in Step 6 to restore the data role templates. Otherwise, proceed to Step 8.
Run the changed data role template and confirm that the data roles and grants are generated correctly. Use the APM role templates summary for reconciliation of the generated artifacts. For more information, see "Running a Template" in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide.
If all steps are successful, delete the MDS label you created in Step 4, using the deleteMetaDataLabels
command:
deleteMetadataLabel(application, server, name)
The following example deletes the metadata label data_role_save_point
from the oracle.security.apm
application deployed in the Administration Server:
deleteMetadataLabel('oracle.security.apm','AdminServer','data_role_save_point')
Oracle recommends that you patch data security grants in online mode. Follow the steps in this section when a patch contains both data security grants and data role templates. Every data role template consists of two XML files. One is for data role generation and the other XML file is for data security policies generation. Both of these files must be manually deployed after you apply a patch, so they remain synchronized with each other.
To patch data security grants and data role templates:
Run the Patch Impact report to see which artifacts are included in the patch. For more information, see Section 3.5.1, "Patch Impact Report". Note that the Patch Impact report refers to data role templates as RGXTEMPLATE
.
Back up the security store by using the Oracle Database data pump export tool, as described in Section 4.18.5, "Backing up the Data Security Store".
The following must be running when patching data security grants and data role templates:
LDAP/security policy server
Administration Server
Oracle Authorization Policy Manager
Database
Run Oracle Fusion Applications Patch Manager to apply the seed data changes to the data security system and to copy the data role templates to FA_ORACLE_HOME
. For more information, see Section 3.4, "Applying Patches".
When data security changes are introduced in a patch, no manual steps are required in online mode to update the data security subsystem with the GUIDs of the new application roles seeded in the policy story. In offline patching mode or in the case of patch failure, you must manually run the DSDataMigrator
utility as described in "Reconciling GUIDs" in the Oracle Fusion Applications Administrator's Guide.
If there are any database errors during Step 4, such as running out of tablespace, fix the database errors that occurred and restart the patch. For general troubleshooting information, see Section 9.5, "Troubleshooting Patching Sessions for Database Content".
If you are unable to resolve the errors that occurred while applying the seed data changes, recover the seed data from the backup export file you created in Step 2. For more information, see Section 4.18.6, "Recovering Data Security Seed Data from the Backup".
To create a save point before deploying the data role templates, use the createMetadataLabel
WLST command to label the MDS partition for oracle.security.apm
, using the following syntax:
createMetadataLabel(application, server, name)
The following example creates the label data_role_save_point
for the application oracle.security.apm
deployed in the Administration Server:
createMetadataLabel('oracle.security.apm', 'AdminServer', data_role_save_point')
For more information, see "createMetadataLabel" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.
Follow these steps to manually deploy the data role templates using the importMetadata
WLST command against the Administration Server in the common domain for the oracle.security.apm
application:
Access the WLST shell.
(UNIX) SOA_ORACLE_HOME/common/bin/wlst.sh (Windows) SOA_ORACLE_HOME\common\bin\wlst.cmd
Connect to WebLogic Server.
> connect ('admin user name','admin user password','URL of the AdminServer')
Deploy the data role template using the following importMetadata
WLST command. Refer to the Diagnostics report to find the directory where the template was copied. For more information, see Section 3.5.5, "Diagnostics Report".
importMetadata(application='oracle.security.apm', server='Name of AdminServer', fromLocation='Directory in FA_ORACLE_HOME where data role templates were copied', docs='Path to the changed data role templates starting with APM partition')
Table 4-5 displays the parameters required by the importMetadata
command.
Table 4-5 Parameters for the importMetadata WLST Command
Parameter Name | Description |
---|---|
application |
Enter the value of |
server |
Enter the name of your Administration Server |
fromLocation |
Enter the absolute path to the directory in |
docs |
Enter the directory for the APM partition, starting with |
Example 4-3 Importing the FinancialAssetBook.xml data role template
In this example, the FinancialAssetBook.xml
data role template is located in this directory:
(UNIX)/net/server01/fusionapps/applications/fin/fa/apm/oracle/apps/apm/fin/fa/rgx/template (Windows)\net\server01\fusionapps\applications\fin\fa\apm\oracle\apps\apm\fin\fa\rgx\template
Example of the importMetadata
command:
(UNIX) importMetadata(application='oracle.security.apm', server='AdminServer', fromLocation='/net/server01/fusionapps/applications/fin/fa/apm', docs='/oracle/apps/apm/fin/fa/rgx/template/FinancialAssetBook.xml' (Windows) importMetadata(application='oracle.security.apm', server='AdminServer', fromLocation='\\net\\server01\\fusionapps\\applications\\fin\\fa\\apm', docs='/oracle/apps/apm/fin/fa/rgx/template/FinancialAssetBook.xml'
Example 4-4 Importing multiple XML files in one command by using a wild card in the docs parameter
The XML file for data role generation is located in this directory:
(UNIX) /net/machine1/oracle/apps/oracle/fin/gl/rgx/template/GeneralLedger.xml (Windows) \net\machine1\oracle\apps\oracle\fin\gl\rgx\template\GeneralLedger.xml
The XML file for data security policies generation is located in this directory:
(UNIX) /net/machine1/oracle/apps/oracle/fin/gl/rgx/dataSecPolicy/fndDataSecProvider/GeneralLedger.xml (Windows)\net\machine1\oracle\apps\oracle\fin\gl\rgx\dataSecPolicy\fndDataSecProvider\GeneralLedger.xml
The following command imports both XML files at the same time:
(UNIX) importMetadata(application='oracle.security.apm', server='AdminServer', fromLocation='/net/machine1', docs='/oracle/apps/oracle/fin/gl/**' (Windows) importMetadata(application='oracle.security.apm', server='AdminServer', fromLocation='\\net\\machine1', docs='/oracle/apps/oracle/fin/gl/**'
For more information, see "Importing WebCenter Services Metadata and Data (WebCenter Portal Applications)" in the Oracle Fusion Middleware Administrator's Guide for Oracle WebCenter.
If there are any errors in Step 7, follow these steps to recover by restoring the data role templates:
Restore the security seed data from the backup you created in Step 2. For more information, see Section 4.18.6, "Recovering Data Security Seed Data from the Backup".
Promote the MDS label created in Step 6 using the following command:
promoteMetadataLabel(application, server, name)
The following example promotes the metadata label data_role_save_point
to the oracle.security.apm
application deployed in the Administration Server:
promoteMetadataLabel('oracle.security.apm', 'AdminServer','data_role_save_point')
For more information, see "promoteMetadataLabel" in the Oracle Fusion Middleware WebLogic Scripting Tool Command Reference.
Delete any new data role templates that were delivered in the patch, using the following command:
deleteMetadataLabel(application, server, name)
The following example deletes the data role templates in the metadata label data_role_save_point
from the oracle.security.apm
application deployed in the Administration Server:
deleteMetadataLabel('oracle.security.apm','AdminServer','data_role_save_point')
Assuming Steps 2 through 7 are successful, Oracle recommends that you preview the execution of your changed data role templates. Run the preview from the Summary tab after you open the data role template from the APM console. For more information, see "Running a Template" in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).
If the preview results are not correct, follow the recovery described in Step 8 to restore the seed grants and data role templates.Otherwise, proceed to Step 10.
Run the changed data role template and confirm that the data roles and grants are generated correctly. Use the APM role templates summary for reconciliation of the generated artifacts. For more information, see "Running a Template" in the Oracle Fusion Middleware Oracle Authorization Policy Manager Administrator's Guide (Oracle Fusion Applications Edition).
If the results are not correct, restore the database from the backup created in Step 2. For more information, see Section 4.18.6, "Recovering Data Security Seed Data from the Backup".
If all steps are successful, delete the MDS label you created in Step 6, using the deleteMetaDataLabels
command:
deleteMetadataLabel(application, server, name)
The following example deletes the metadata label data_role_save_point
from the oracle.security.apm
application deployed in the Administration Server:
deleteMetadataLabel('oracle.security.apm','AdminServer','data_role_save_point')
Back up the data security store by using the Oracle Database data pump export tool. Before running the export tool, ensure that the TWO_TASK
environment variable is set to point to your Oracle Fusion Applications instance. You are prompted for the Oracle Fusion Applications database user name and password.
For setting any environment variable, run the adsetenv
script to generate the APPSORA.env
file, which when sourced, sets all environment variables.
(UNIX) sh adsetenv.sh source APPSORA.env echo $TWO_TASK (Windows, TWO_TASK is known as LOCAL) adsetenv.cmd APPSORA.cmd echo %LOCAL%
Run the data pump export tool as follows:
ORACLE_HOME/bin/expdp directory=tmp dumpfile=fndds1.dmp tables='(FND_GRANTS, FND_MENUS_TL,FND_MENUS,FND_MENU_ENTRIES,FND_COMPILED_MENU_FUNCTIONS, FND_FORM_FUNCTIONS_TL,FND_FORM_FUNCTIONS,FND_OBJECT_INSTANCE_SETS_TL, FND_OBJECT_INSTANCE_SETS,FND_OBJECTS_TL,FND_OBJECTS)' NOLOGFILE=y
For more information about Oracle Data Pump, see: http://www.oracle.com/technetwork/database/enterprise-edition/data-pump-overview-084963.html
Follow these steps only if a data security seed data patch failed and there is no way to resolve the failure and reapply the patch:
Remove the existing data security grant data from the data security tables. Connect to the fusion
account using SQL*Plus and run the following commands:
truncate table fusion.fnd_objects; truncate table fusion.fnd_objects_tl; truncate table fusion.fnd_object_instance_sets; truncate table fusion.fnd_object_instance_sets_tl; truncate table fusion.fnd_form_functions; truncate table fusion.fnd_form_functions_tl; truncate table fusion.fnd_menus; truncate table fusion.fnd_menus_tl; truncate table fusion.fnd_menu_entries; truncate table fusion.fnd_grants;
Import the data security seed data from the backup export file you previously created.
ORACLE_HOME/bin/impdp dumpfile=fndds1.dmp tables='(FND_GRANTS, FND_MENUS_TL,FND_MENUS,FND_MENU_ENTRIES,FND_COMPILED_MENU_FUNCTIONS, FND_FORM_FUNCTIONS_TL,FND_FORM_FUNCTIONS,FND_OBJECT_INSTANCE_SETS_TL, FND_OBJECT_INSTANCE_SETS,FND_OBJECTS_TL,FND_OBJECTS)' NOLOGFILE=y
When updates to SOA composites are introduced in a patch, no manual steps are required if both of the following conditions are met:
You have no SOA composite customizations in Oracle JDeveloper. If you do have customizations, follow the steps in Section 4.19.1, "Preserving SOA Composite JDeveloper Customizations Before Applying a Patch".
You apply the patch in online mode and no validation or deployment errors occurred during the application of the patch that contains SOA composites. Oracle recommends you do not use offline mode when a patch contains SOA composites. If the patch fails while attempting to deploy a SOA composite, you may have to manually deploy the composite. For more information, see Section 4.19.2, "Manually Deploying SOA Composites".
For information about resolving validation errors, see Section 9.4.2, "Troubleshooting SOA Composite Validation Failures". For information about recovering from deployment errors, see Section 9.4.3, "Troubleshooting SOA Composite Deployment Failures".
If you customized SOA composites used by Oracle Fusion Applications in JDeveloper, you must preserve these customizations when you apply a patch that includes the next revision of the composite. Other customizations to the SOA composite being patched are automatically merged by the SOA deployment command called during patching. These runtime customizations, such as design time and run-time (DT@RT) changes or property changes, do not require a manual merge process.
What must be running when you patch SOA composites
Administration Server
SOA-INFRA Managed Servers
Database
At least one server must be running the Policy Manager component from the Web Services Manager (WSM-PM) application. Typically in an Oracle Fusion Applications environment, this is the Common Cluster, for example in the CRMDomain
, it is the CRMCommonCluster
. You can find out which server is running by logging in to Oracle Enterprise Manager Fusion Applications Control to verify that the application named wsm-pm
is running with an OK
or green status. If the server is not running, see "Diagnosing Common Problems with Oracle WSM" in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services.
If you performed JDeveloper customizations, not supported by OPatch, to a SOA composite and then you deploy the composite to the SOA runtime, subsequent patches are not directly deployable. The Oracle Fusion Applications Patch Manager validation process returns the appropriate error, which instructs you to take the newer version of the composite that is in the patch, redo the same customizations that were performed on the previous version of the composite, and then apply the patch in online mode to deploy the composite.
Before applying the patch, review the recommendations in "Merging Runtime Customizations from a Previously Deployed Revision into a New Revision" in the Oracle Fusion Applications Extensibility Guide to ensure that your customizations will be merged successfully.
To preserve SOA composite JDeveloper customizations before applying a patch:
Run Oracle Fusion Applications Patch Manager validation in online mode to determine which composites have JDeveloper customizations. If any customizations are detected, the validation results display the SOA composite name, its location in the patch_top
directory, and the requirement for you to merge JDeveloper customizations into the sca_*.jar
file in the patch_top
directory before applying the patch in online mode.
Note:
You must run Oracle Fusion Applications Patch Manager validation before applying every patch, especially patches that contain SOA composites. If your JDeveloper customizations are not merged into the sca_*.jar
file in the patch_top
directory, the deployment of the SOA composite that was changed inside the patch will fail when you apply the patch.
Open the custom SOA workspace and the customized version of the Fusion Applications SOA composite in JDeveloper using "Oracle Fusion Applications Developer". For more information, see "Customizing SOA Composites with JDeveloper" in the Oracle Fusion Applications Web User Interface Developer's Guide for Oracle Application Development Framework.
Import the composite sca_*.jar
file from the patch_top
directory into the project, for example revision yy_patchnum
, in JDeveloper. Make note of this revision number in the deployment window because you will need it in Step 8. You can find the revision number on the Patch Impact report.
Restart JDeveloper in the Oracle Fusion Applications Administrator Customization role.
Verify that there are no errors in JDeveloper.
Verify that the changes introduced in both the customized version and the patched version are present.
Right-click the composite project in the Application Navigator, select Deploy, select the composite, click Deploy to SAR, and click Next.
Manually change the value in New Revision ID to the revision from Step 3, for example, yy_patchnum
, and click Finish.
If the deployment folder is set to a location different from that of the patch_top
directory, copy and replace the JAR in the patch under patch_top
/patch_mw/files/productfamily
/deploy. If your file name is different, rename it to the original name.
Now you should be able to both validate and apply this patch successfully using Oracle Fusion Applications Patch Manager in online mode.
For more information about customizing SOA composites, see "Customizing and Extending SOA Components" in the Oracle Fusion Applications Extensibility Guide.
If a customized SOA composite deployment fails during patching, you must manually deploy this composite using WLST commands. You must also manually deploy SOA composites if you apply a patch in offline mode that contains SOA composites.
To apply a SOA composite manually after a deployment failure or when patching in offline mode
In the following example, the composite FinAp
is patched from revision 1.0 to revision 2.0 and the SAR file of revision 2.0 is in FA_ORACLE_HOME/crm/deploy/sca_FinAp_rev2.0.jar
.
Note that the parameters are for illustration purposes only.
Refer to the Diagnostics report to find the name and location of the sca_*.jar
file that was copied to FA_ORACLE_HOME
by Oracle Fusion Applications Patch Manager. For more information, see Section 3.5.5, "Diagnostics Report".
If the previous revision contained JDeveloper customizations, ensure that you deploy the patched revision with the merged JDeveloper customizations. Using the sca_*.jar
file from Step 1, follow the JDeveloper customization merge instructions that are described in Section 4.19.1, "Preserving SOA Composite JDeveloper Customizations Before Applying a Patch". Then use the merged sca_*.jar for Steps 3 through 13.
Determine the default revision of the composite.
sca_getDefaultCompositeRevision(SOA_Server_host, SOA_Server_port, user, password, 'FinAp')
Export the full composite of the default revision.
sca_exportComposite('SOA-Infra URL', 'none',
'FA_ORACLE_HOME/crm/deploy/sca_FinAp_rev1.0.jar','FinAp', '1.0')
Export the run-time customizations of the SOA composite.
sca_exportUpdates('SOA-Infra URL', 'all',
'FA_ORACLE_HOME/crm/deploy/sca_FinAp_rev1.0.jar','FinAp', '1.0')
Attach a configuration plan to the newer revision of the composite, if a configuration plan is used with the composite.
sca_attachPlan('FA_ORACLE_HOME/crm/deploy/sca_FinAp_rev2.0.jar', '../configplan.xml')
Merge the run-time customizations of composite, revision 1.0 in this example, with the new revision, 2.0.
sca_mergeUpdates('/tmp/merge-log.txt', '/tmp/merge-FinAp_rev2.0.jar', '/tmp/sca_FinAp_rev1.0.jar', '/tmp/sca_FinAp_rev2.0.jar', '/tmp/all-FinAp_rev1.0.jar')
This command prints error messages if revision 1.0 has JDeveloper customizations and revision 2.0 does not. If this is the case, follow the steps in Section 4.19.1, "Preserving SOA Composite JDeveloper Customizations Before Applying a Patch" to apply the JDeveloper customization.
If other errors occur, check the log file and address the errors. No error in this step can be ignored.
Disable the Events Delivery Network (EDN) events delivery.
sca_disableEventsDelivery()
Deploy the patched composite and set the default to be false.
sca_deployComposite('SOA-Infra URL',
'/FA_ORACLE_HOME/crm/deploy/sca_FinAprev2.0.jar',forceDefault=false,
This step deploys revision 2.0, provided by an Oracle patch, plus the JDeveloper customization, if applicable. If the deployment fails, check the server log files. For more information, see "Table 22-2 SOA Log Information for Oracle Support Services" in the Oracle Fusion Applications Administrator's Guide.
Import the merged artifacts from Step 7. If an error occurs in this step, undeploy revision 2.0.
sca_importUpdates('SOA-Infra URL',
'/tmp/merge-FinAp_rev2.0.jar',
'FinAp', '2.0')
The following example shows how to undeploy a composite:
sca_undeployComposite('SOA-Infra URL', 'FinAp', '2.0')
Make the new revision the default composite of the series.
sca_assignDefaultComposite('SOA_Server_host', 'SOA_Server_port', 'user', 'password', 'FinAp', '2.0')
Retire the old revision. This step is required to prevent multiple revisions of composites from being called through EDN. EDN currently delivers the event to all active revisions of the composites. Retiring a composite ensures that it does not initiate any new instances while allowing it to complete existing instances.
sca_retireComposite('SOA_Server_host', 'SOA_Server_port', 'user', 'password', 'FinAp', '1.0')
Enable EDN events delivery.
sca_enableEventsDelivery()
When updates to SOAEXTENSION artifacts are introduced in a patch, you must stop and restart all SOA-INFRA Managed Servers in all domains. Both online and offline patching require this step.
Oracle recommends you patch SOA resource bundles in online mode. No manual steps are required when patching SOA resource bundles in online mode unless the SOA resource bundle JAR file contains translatable strings for human task-mapped attribute labels and standard view names, as indicated by a JAR name that ends with FlexFieldSoaResource.jar
. In offline mode, in case of patch failure, or if the patch contains human task-mapped attribute labels and standard view names, you must manually deploy the SOA resource bundle and restart the SOA composites that depend on the SOA resource bundle.
The following must be running when you patch SOA resource bundles:
Administration Server
SOA-INFRA Managed Servers
Node manager
Database
After you apply the patch, refer to the Diagnostics report to get a complete list of composites that depend on each SOA resource bundle and also the domains. For more information, see Section 3.5.5, "Diagnostics Report".
To manually deploy the SOA resource bundle JAR files:
From the Diagnostics report for patch validation, review the list of SOA resource bundle JAR files included in the patch and the domain where they should be deployed. Use the ant-sca-deploy.xml
script to deploy the appropriate SOA cluster for each JAR included in the patch.
Set the ANT_HOME
variable:
ANT_HOME=FA_ORACLE_HOME/modules/org.apache.ant_1.7.1; export ANT_HOME
Deploy the appropriate cluster:
ant -f Middleware_Home/SOA_Suite_Home/bin/ant-sca-deploy.xml -DserverURL=URL_to_SOA_server -DsarLocation=Location_of_resource_bundle_jar under FA_ORACLE_HOME -Duser=weblogic -Dpassword=weblogic_password
For more information about the ant-sca-deploy.xml
script that is used to deploy the SOA resource bundle, see "How to Manage SOA Composite Applications with ant Scripts" in the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
The Diagnostics report lists the composite affected by the patch and the domain where the composite is deployed. Follow these steps for each affected composite:
Log in to Oracle Enterprise Manager Fusion Applications Control in the domain where the composite is deployed.
Go to domain name, then SOA, then soa-infra (SOA cluster name), then default, and then composite name.
Click Shut Down.
Click Yes in the confirmation window.
Click Start Up.
Click Yes in the confirmation window.
Review the list of SOA resource bundle JAR files being patched. If a patch contains a JAR file with a name which starts with "jar_" and ends with "FlexFieldSoaResource.jar", for example, jar_AppCmmnCompNotesFlexFieldSoaResource.jar
, you must perform the following steps to ensure that the patched resource bundle is reflected in the Oracle BPM Worklist. These steps describe how to set the WorkflowCustomClasspathURL
MBean property to "", apply the changes, set to oramds:///apps/resource/
, and apply the changes in Oracle Fusion Applications Control.
Log in to Oracle Fusion Applications Control in the domain where the JAR was deployed.
Go to SOA, then soa-infra in the left-hand panel. Go to SOA Infrastructure, then Administration, and then System MBean Browser in the right-hand panel.
Go to Application Defined MBeans, then oracle.as.soainfra.config, then Server: SOA cluster name, then WorkflowConfig and then human-workflow.
Remove the contents in the Value column of the WorkflowCustomClasspathURL
attribute.
Click Apply.
Enter oramds:///apps/resource
/ in the Value column of the WorkflowCustomClasspathURL
attribute.
Click Apply.
For information about shutting down and starting up SOA composites in Oracle Enterprise Manager, see "Managing the State of Deployed SOA Composite Applications" in the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle Business Process Management Suite.
When updates to the SPE Inline Service artifact are introduced in a patch, you must manually deploy the changed SPE artifacts.Updates to SPE Inline Service are delivered in the SPE_ILS.zip
file and the AdfZspPredictionModuleSupportUtilities.jar
file.
Note:
SPE artifacts are provisioned only when Oracle Fusion CRM Performance Management is provisioned. If CRM Performance Management is not provisioned in your environment, you should not deploy SPE artifacts.
Prerequisites for SPE artifact deployment, before you apply the patch
You must be running JDK 1.6 or later.
You must have access to the ZIP file, rtd-deploytool-11.1.1.zip
. This ZIP file resides inside another ZIP file, FA_ORACLE_HOME/bi/clients/rtd
/rtd_client_
11.1.1
.zip.
Make a backup copy, in a temporary directory, of the existing SPE_ILS.zip
file, which is located under FA_ORACLE_HOME
in this directory:
crm/components/crmPerformance/zsp/predictionmodule/inlineservice
.
To manually deploy SPE artifacts after you apply the patch
Oracle suggests you refer to the text file that you can create during provisioning that is a textual overview of your topology as you follow these steps. For more information, see "Creating the Installation Environment" in the Oracle Fusion Applications Enterprise Deployment Guide.
Stop and start bi_server1
to include the changes in AdfZspPredictionModuleSupportUtilities.jar
.
Follow these steps to deploy the new SPE_ILS
.zip artifact.
Unzip rtd_client_11.1.1.zip
in a temporary directory. To find this file, refer to Step 2 in Prerequisites for SPE artifact deployment, before you apply the patch.
In the unzipped files, go to the folder ../client/CommandLineDeploy
and find rtd-deploytool-11.1.1.zip
.
Unzip rtd-deploytool-11.1.1.zip
and go to the folder, ../OracleBI/RTD/deploytool.
In this folder, open a command terminal. Ensure that you have the JDK class path set for this terminal.
Run this command:
java -jar deploytool.jar -deploy -server Host name of the server where BI domain is created -port Managed server port where the OracleRTD app is deployed -terminateSessions true Full directory path to SPE_ILS.zip
Example:
(UNIX) java -jar deploytool.jar -deploy -server server01.oracle.com -port 7001 -terminateSessions true FA_ORACLE_HOME/crm/components/ \ crmPerformance/zsp/predictionmodule/inlineservice/SPE_ILS.zip (Windows) java -jar deploytool.jar -deploy -server server01.oracle.com -port 7001 -terminateSessions true D:\SPE\RTD\ILS\SPE_ILS.zip
When prompted, enter the user name and password to connect to the RTD server. This user must have a role that includes ILS deploy permission. Both the BIAdministrator
and BIAuthor
have this permission.
This message indicates the deployment is complete:
deploymentStateId is 5Inline service "SPE_ILS" in "FA_ORACLE_HOME/crm/components/crmPerformance/zsp/predictionmodule/inlineservice/SPE_ILS.zip/SPE_ILS.zip" deployed to server: "server01.oracle.com" port: "7001" deployment state: "Development"
Tree artifacts are delivered as seed data in patches and therefore, do not typically require manual steps after they are patched. A process called tree flattening automatically runs during the patching process. If this process fails, you must perform the following additional steps:
To verify if the patch contains any files related to tree flattening, refer to the Patch Impact report and look for a file named FndTreeVersionSD.xml
. This is the only file that requires tree flattening. For more information, see Section 3.5.1, "Patch Impact Report".
Confirm that the tree version changes were successfully flattened by reviewing the worker logs for errors related to tree flattening. To determine the worker that executed the specific seed data task, based on the file name FndTreeVersionSD.xml, refer to the Diagnostics report generated at the end of the patching session. Note any tree versions that failed because you need the version numbers to manually flatten the tree version changes.
For more information about the Diagnostic report, see Section 3.5.5, "Diagnostics Report". For more information about log files, see Section 9.1.1, "Log Files for Patching Sessions".
Follow these steps to manually flatten tree versions:
Access the administrative area of Oracle Fusion Functional Setup Manager by logging in to Oracle Fusion Applications with a user account that is provisioned with the necessary role. Contact your security administrator for details.
From the Administration menu in the work area of Oracle Fusion Applications, choose Setup and Maintenance.
Choose the Manage Trees and Tree Versions task.
Search for the tree versions that require flattening.
Choose the appropriate tree version and optionally choose Audit from the Actions menu to diagnose the issues.
If you want to make changes to the tree version, click the tree version and edit it.
Choose Flattening, Row Flattening, then Flattening, Column Flattening from the Actions menu to flatten the selected tree version.
For more information about trees, see "Define Trees" in the Oracle Fusion Applications Common Implementation Guide.