| Oracle® Fusion Applications Patching Guide 11g Release 1 (11.1.3) Part Number E16602-14 |
|
|
PDF · Mobi · ePub |
| Oracle® Fusion Applications Patching Guide 11g Release 1 (11.1.3) Part Number E16602-14 |
|
|
PDF · Mobi · ePub |
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 Process for Applying Individual Patches"or Section 3.7, "End-to-End Process for Applying Multiple Patches".
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 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 which artifact types are included in the patch and actions 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 in Online Mode
This column describes the actions you must perform when the patch includes the specified artifact. These actions 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 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 in Online Mode | 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, OPSS Security Store |
|
B2B Metadata |
Deploy trading partner agreements |
None |
Deploy agreements if you want to implement the change |
Database |
|
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 |
None |
|
Oracle Business Process Management (Oracle BPM) Template |
Publish template to the Oracle Metadata Service (MDS) repository |
None |
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 |
OPSS Security Store, 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.1, "Prerequisites for the Deployment of 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 after patching |
Import to ODI repository and drop work tables from FUSION_ODI_STAGE schema |
ODI repository import tool, database |
|
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) |
Deploy the template |
None |
Deploy the template |
Administration Server, Oracle Authorization Policy Manager, database |
|
SOA Composite |
Deploy and merge |
Preserve any JDeveloper customizations |
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 |
Deploy SPE files |
None |
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 co-located 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 |
Oracle recommends that you patch Oracle B2B metadata in online mode. When updates to Oracle B2B metadata are introduced in a patch, no manual steps are required in online mode to redeploy all Trading Partner Agreements that are affected by the metadata change.
If you choose to apply a patch containing Oracle B2B metadata updates in offline mode, and you want to implement the change, you must manually 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.
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 and deploy the agreements, follow these steps:
Follow the steps in "Prerequisites for Running the Command-line Tools" in the Oracle Fusion User's Guide for Oracle B2B with one exception. In Step 2 under "Create jndi.properties", you must use this command:
cd FA_ORACLE_HOME\soa\bin
instead of this command:
cd $ORACLE_HOME\bin
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="Agreement_name,Agreement_name"
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.
The following must occur before manual deployment of BI Publisher artifacts:
The opmn processes must be running. Follow these steps:
To verify if the process is running, go to the FA_ORACLE_HOME/instance/BIInstance/bin and run this command:
opmnctl status
If the opmn process is not alive, start it with this command:
opmnctl start
Oracle Fusion Applications Patch Manager copies 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 steps in Section 4.4.2, "Manually Deploying BI Publisher Artifacts", 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.
Follow these steps to manually deploy BI Publisher artifacts:
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".
Using the example in Step 2, 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 refers to the file from Step 4.
webcat_location is the Oracle home Oracle BI Presentation Catalog location.
webcat_patch.out is a temporary file created by this step and used in Step 5b.
Example of oracle-instance on Unix:
APPLICATIONS_BASE/instance/BIInstance/bifoundation
/OracleBIPresentationServicesComponent/coreapplication_obips1/catalogmanager
Example of oracle-instance on Windows:
C:\APPLICATIONS_BASE\instance\BIInstance\bifoundation
\OracleBIPresentationServicesComponent\coreapplication_
obips1\catalogmanager
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 5a.
webcat_applypatch.out is the output file from this deployment process.
Repeat Step 5 for the run-time catalog.
Restart the Oracle Business Intelligence system components using opmnctl:
cd APPLICATIONS_BASE/instance/BIInstance/bin/opmnctl ./opmnctl stopall ./opmnctl startall
Oracle recommends that you patch Oracle BPM templates in online mode. When updates to Oracle BPM templates are introduced in a patch, no manual steps are required in online mode to publish the new Oracle BPM Template to the Oracle Metadata Service (MDS) repository.
If you choose to apply a patch containing updates to Oracle BPM templates in offline mode, 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 as one of the input parameters of the publish_template command.
Follow these steps 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
Follow these steps 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 2.
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 more information about 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 automatically deploy the flexfields in online mode, except to ensure that the following are running:
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. If you decide that you do not want to implement the changes to a flexfield, you can revert to a previous version of a flexfield. For more information, see Section 11.3.9, "Revert To a Previous Flexfield Definition After It Is Updated By a Patch".
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" in the Oracle Fusion Applications Administrator's Guide.
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
In offline mode, or in the case of failure, 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, 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.
The opmn processes must be running. Follow these steps:
To verify if the process is running, go to the FA_ORACLE_HOME/CommonDomain_webtier directory and run this command:
opmnctl status
If the opmn process is not Alive, start it with this command:
opmnctl start
The imaging application must be running. The format for the IPM URL is http://<host name>:<Port>/imaging/.
The Financials SOA server (soa_server1) 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, 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.
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 that you patch Java EE artifacts in online mode. When you patch Java EE artifacts in online mode, no manual steps are required, except to ensure that the following are running:
Administration Server
Node manager
Database
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 the Financials Domain, apply the patch, and then 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.
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.
Oracle recommends that the ODI import be performed from a machine that is co-located 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 imported again. 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 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.
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) FA_ORACLE_HOME/lcm/ad/bin/fapmgr.sh bootstrap [-logfile log_file_name] [-loglevel level] (Windows) FA_ORACLE_HOME\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.
Standard patches of help content may be published from time to time. These patches contain two types of content:
A Seed Data Files patch that containing updated help topics that you apply using Oracle Fusion Applications Patch Manager.
Reference content patches that may contain:
BPM diagrams
User Productivity Kit demos
Oracle Fusion Applications Technology 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".
To apply Oracle Fusion Applications Help reference patches, unzip the patch file and move the content to the equivalent directory in your APPLICATIONS_BASE, where APPLICATIONS_BASE is the root directory under which the provisioned environment resides. 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 system-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 11, "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 system-jazn-data.xml to package function security policies through application roles, role hierarchies, grants, and policies. Function security policies are shipped as a system-jazn-data.xml file that resides in the Oracle home. After provisioning, these policies are migrated to an LDAP Policy store. Patching function security policies requires steps to absorb changes delivered by Oracle (system-jazn-data.xml in a patch), changes currently deployed, which include changes by you (policies in the LDAP server), and system-jazn-data.xml contents previously shipped from Oracle (system-jazn-data.xml in the Oracle home).
Oracle Fusion Applications Manager runs a comprehensive analysis tool 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 | Conflicts - Apply Patch in Offline Mode |
|---|---|---|
|
Additions |
New artifacts shipped from Oracle. |
Artifacts retained by Oracle in a patch with or without modifications, but deleted by the customer. |
|
Modifications |
Artifacts modified by Oracle in a patch but not by the customer. |
|
|
Deletions |
All artifact deletions must be applied in offline mode. |
|
For more information about what the system-jazn-data.xml file contains, see the "The OPSS Policy Model" 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).
This section contains information about the following methods for patching applications policies:
Prerequisites for Patching Applications Policies in Online Mode
Patching Applications Policies in Offline Mode With Authorization Policy Manager
Oracle recommends that you patch applications policies in online mode because Oracle Fusion Applications Patch Manager automates the deployment of the system-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 can choose to apply all safe changes in online mode. Later, you must apply conflicting changes in offline mode, as described in Section 4.17.1.2, "Patching Applications Policies in Offline Mode With Authorization Policy Manager".
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).
All domains that use the OPSS Policy store in OID for authorization policies must be shut down before the patch applies.
The following steps must be performed if you patch applications policies in offline mode using Authorization Policy Manager (APM).
Note:
All domains, except the OPSS Security Store and the domain that hosts APM, 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 system-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 system-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 system-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.
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.17.5, "Backing up the Data Security Store".
Follow these steps to patch data security steps:
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.17.6, "Recovering Data Security Seed Data from the Backup".
Oracle recommends that you patch data role templates in online mode. When data role template changes are introduced in a patch, no manual steps are required in online mode to deploy the changed templates.
Follow the steps in this section when you apply a patch in offline mode that contains 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 deployed after you apply a patch that contains changes to data role templates, so they remain synchronized with each other.
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-4 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)FA_ORACLE_HOME/fin/fa/apm/oracle/apps/apm/fin/fa/rgx/template (Windows)FA_ORACLE_HOME\fin\fa\apm\oracle\apps\apm\fin\fa\rgx\template
Example of the importMetadata command:
(UNIX) importMetadata(application='oracle.security.apm', server='AdminServer', fromLocation='FA_ORACLE_HOME/fin/fa/apm', docs='/oracle/apps/apm/fin/fa/rgx/template/FinancialAssetBook.xml' (Windows) importMetadata(application='oracle.security.apm', server='AdminServer', fromLocation='FA_ORACLE_HOME\\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) \\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)\\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='\\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. Proceed to Step 7 if there are no errors in Step 5.
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.17.5, "Backing up the Data Security Store".
The following must be running when patching data security grants and data role templates:
OPSS Security Store
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 11.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.17.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)FA_ORACLE_HOME/fin/fa/apm/oracle/apps/apm/fin/fa/rgx/template (Windows)FA_ORACLE_HOME\fin\fa\apm\oracle\apps\apm\fin\fa\rgx\template
Example of the importMetadata command:
(UNIX) importMetadata(application='oracle.security.apm', server='AdminServer', fromLocation='FA_ORACLE_HOME/fin/fa/apm', docs='/oracle/apps/apm/fin/fa/rgx/template/FinancialAssetBook.xml' (Windows) importMetadata(application='oracle.security.apm', server='AdminServer', fromLocation='FA_ORACLE_HOME\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) \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)\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='\\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. Otherwise, proceed to Step 9.
Restore the security seed data from the backup you created in Step 2. For more information, see Section 4.17.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.17.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.18.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.18.2, "Manually Deploying SOA Composites".
For information about resolving validation errors, see Section 11.4.2, "Troubleshooting SOA Composite Validation Failures". For information about recovering from deployment errors, see Section 11.4.3, "Troubleshooting SOA Composite Deployment Failures".
If you customized SOA composites used by Oracle Fusion Applications in JDeveloper, you must preserve these customizations before 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. For more information, see Section 3.3, "Validating Patches".
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 steps, the example 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.18.1, "Preserving SOA Composite JDeveloper Customizations Before Applying a Patch". Then use the merged sca_*.jar for Step 3.
Deploy the patched composite using single patch composite command.
sca_patchComposite('SOA-Infra URL', user, password,
'/FA_ORACLE_HOME/crm/deploy//sca_FinAprev2.0.jar', mergeLogFile='/tmp/merge-log.txt')
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".
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 null, and then set it 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.
Oracle recommends that you patch data role templates in online mode. When updates to SPE Inline Service artifacts are introduced in a patch, no manual steps are required in online mode to deploy the changed SPE artifacts.
Updates to SPE Inline Service are delivered in the SPE_ILS.zip file and the AdfZspPredictionModuleSupportUtilities.jar file. This section contains information about manual deployment of SPE artifacts, in the case of offline patching or failure during online patching.
Prerequisites Required Before Manual SPE Artifact Deployment
Manually Deploying SPE Artifacts After You Apply the Patch in Offline Mode
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.
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:
(Unix) crm/components/crmPerformance/zsp/predictionmodule/inlineservice
(Windows) crm\components\crmPerformance\zsp\predictionmodule\inlineservice
Oracle suggests you refer to the text file that was created when provisioning completed, which is a textual overview of your topology, as you follow these steps. For more information, see "Installation Process Flow" in the Oracle Fusion Applications Installation 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 Section 4.21.1, "Prerequisites Required Before Manual SPE Artifact Deployment".
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 11.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.
|
 Copyright © 2011, 2012, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|