Skip Headers
Oracle® Fusion Middleware Reference Guide for Oracle Business Intelligence Applications
11g Release 1 (11.1.1)
Part Number E16816-03
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Index
Index		 Go to Feedback page
Contact Us
Go to previous page
Previous		 Go to next page
Next
PDF · Mobi · ePub

4 Oracle BI Applications Patching

This chapter describes how to apply Oracle BI Applications patches.

This chapter contains the following topics:

4.1 Introduction to Oracle BI Applications Patching

For Oracle Fusion Applications source systems, this chapter supplements the information provided in Oracle Fusion Applications Patching Guide.

This chapter also supplements information provided in Oracle Fusion Middleware Patching Guide for patching Oracle Fusion Middleware products.

Patching involves using OPatch to copy a small collection of files over an existing installation. A patch is normally associated with a particular version of an Oracle product. A patch set contains a collection of patches that are designed to be applied at the same time.

Oracle Fusion Middleware Patching Guide provides a full description of the types of patches available and the instructions to apply them. Before applying a patch to an Oracle Business Intelligence Applications system, make sure to review Oracle Fusion Middleware Patching Guide, as well as the readme.txt file provided with the patch. The readme file will describe the content of the patch and may contain additional information and instructions.

4.2 What Is Included in Oracle BI Applications Patches?

An Oracle BI Applications patch can include bug fixes, metadata, and binary file updates. The exact updates made will depend on the patch contents, and can include any of the following:

Note: An Oracle BI Applications patch does not include the following:

4.3 Where Updates Are Made by Oracle BI Applications Patches

The exact updates made by a patch depends on what is in that particular patch, but it can consist of a combination of the content types described in Section 4.2.

If the content of the patch contains just binary updates, then these updates are made directly to the Oracle home, and only to the Oracle home.

If the content of the patch contains metadata updates it is important to note that it is not only the Oracle home that will be updated. For each metadata type that can be patched (for more information, see Section 4.2), one copy is kept in the Oracle home and another is deployed for use at runtime. A patch containing metadata updates will update both the Oracle home content as well as the runtime, or deployed content.

For example, patch updates to the Oracle BI Presentation Catalog will be copied to the Oracle home location that keeps track of the version of the Oracle BI Presentation Catalog last delivered by Oracle, and will also update the Oracle BI Presentation Catalog that has been deployed for use at runtime.

4.4 Applying Oracle BI Applications Patches

You can apply a patch to Oracle BI Applications or Oracle BI Applications Configuration Manager using the following procedure:

4.4.1 Applying an Oracle BI Applications Patch

To apply an Oracle BI Applications patch:

  1. Copy or download the OPatch archive.

    For example, you might copy a downloaded archive called 1234567.zip, to the folder /scratch/patchBase.

    For information about what is included in the patch:

    • See the README.txt file in the OPatch archive.

    • Run the 'opatch query' command (for example, opatch query 123456789.zip) to list bugs fixed, and the contents of the patch.

  2. (Required for metadata patches only.) Prepare the Patch Properties file (apply-patch.properties).

    To apply changes to the metadata types being patched, you specify values in the apply-patch.properties file for the different metadata types. For example, the location of the runtime Oracle BI Presentation Catalog.

    A sample properties file described in Section 4.8, "Sample Patch Properties File", lists each metadata type. You only need to supply values that correspond to the metadata types being patched.

    Once the property values are completed, save this to: /scratch/patchBase/apply-patch.properties

    Note: If you do not specify this file in the OPatch command, properties that are required will be requested when you are applying the patch.

  3. Back up all metadata.

    Metadata must be backed up using your normal backup mechanisms.

  4. Stop the Oracle Business Intelligence components.

    Since the patch will make updates to the runtime metadata, you must do this to avoid locking issues; the patch might fail if you do not do this. In addition, not all metadata updates will be visible until Oracle Business Intelligence is restarted.

    Use Fusion Middleware Control to stop Oracle Business Intelligence components. For more information, see 'Starting and Stopping Oracle Business Intelligence' in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

    Note: If the patch contains RPD updates only, you need stop only the BI Server component. If the patch contains Oracle BI Presentation Catalog updates only, you need stop only the BI Presentation Services component.

  5. Apply the Oracle BI Applications metadata patch.

    Apply the patch using the copy of OPatch in the Oracle home, as follows:

    For UNIX use the following syntax:

    ./opatch apply -pre <path to patch properties file> -opatch_pre_end <path to unzipped patch dir>

    For example, if you copied your patch archive to /scratch/patchBase/1234567.zip, and your properties file is in /scratch/patchBase/apply-patch.properties, enter the following command:

    ./opatch apply -pre /scratch/patchBase/apply-patch.properties -opatch_pre_end /scratch/patchBase/1234567.zip

  6. If the patch contains changes to JAZN settings, then follow the steps in Section 4.4.1.1, "How to Apply Changes to JAZN Settings".

    The task described in Section 4.4.1.1, "How to Apply Changes to JAZN Settings" must be performed using a copy of system-jazn-data.xml that is made before the patch is applied in Step 5 above.

    Tip: To determine whether a patch includes changes to JAZN settings, look for a biapps_policystore.xml file in the patch file, or look in the readme file that accompanies the patch for changes to JAZN settings.

  7. If the patch includes Oracle BI Repository (RPD) updates and the environment is clustered, you must scale out the RPD so that the repository can be shared by all Oracle BI Servers participating in a cluster.

    For more information, see 'Uploading and Sharing the Oracle BI Repository' in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

  8. Re-start the Oracle Business Intelligence components.

    For more information, see 'Starting and Stopping Oracle Business Intelligence' in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

    Note: If the patch contained only RPD updates, and you stopped only the BI Server in step 4, then you need only restart the BI Server. If the patch contained only Oracle BI Presentation Catalog updates, and you stopped the BI Presentation Services in step 4, then you need only restart the BI Presentation Services.

4.4.1.1 How to Apply Changes to JAZN Settings

Note: This task forms part of Step 6 in Section 4.4.1, "Applying an Oracle BI Applications Patch". After completing this task, continue from Step 7 in Section 4.4.1, "Applying an Oracle BI Applications Patch".

If you are applying an Oracle BI Applications patch that contains changes to JAZN settings (that is, in the biapps_policystore.xml file), then you must follow the steps below.

Notes:

  • You must make a backup of the production policy store before applying the changes included in a JAZN patch. For more information about backing up a policy store, see Section 8.6.2 'Migrating with the Script migrateSecurityStore' in Oracle Fusion Middleware Application Security Guide.

  • During patching, only the system-jazn-data.xml file in the Oracle Home is patched. The changes to BI JAZN data need to be applied to the production JAZN policy store using either:

    - the WLST script patchPolicyStore() - see Steps 5, 6, and 7 in the task below.

    - Oracle Authorization Policy Manager (Oracle APM). If you use Oracle APM to apply JAZN changes to the production JAZN policy store, then you can omit Steps 5, 6, and 7 in the task below.

How to Apply Changes to JAZN Settings:

  1. Make a copy of the production jps-config.xml file.

    For example, you might use the following command:

    cp ${ORACLE_HOME}/BIDomain/config/fmwconfig/jps-config.xml  
${ORACLE_HOME}/BIDomain/config/fmwconfig/copy-jps-config.xml

  2. Edit the copy of the jps-config.xml, and commenting out all service instances in the default JPS context so that only the policystore service instance remains.

    For example:

    <jpsContext name="default">
             <!--serviceInstanceRef ref="credstore.ldap"/-->
              <!--serviceInstanceRef ref="keystore.ldap"/--> 
              <serviceInstanceRef ref="policystore.ldap"/>
              <!--serviceInstanceRef ref="audit"/-->
              <!--serviceInstanceRef ref="idstore.ldap"/-->
              <!--serviceInstanceRef ref="trust"/-->
              <!--serviceInstanceRef ref="pdp.service"/-->
      </jpsContext>

  3. Start the WLST interactively using $ORACLE_HOME/common/bin/wlst.sh.

  4. If SSO is used to connect to the policy store then set the following properties:

    java.lang.System.setProperty("javax.net.ssl.trustStore",'<truststore>');
java.lang.System.setProperty("javax.net.ssl.trustStorePassword", '<password>');

    Where <truststore> is the location of the truststore. For example: /scratch/aime1/APPTOP/fusionapps/wlserver_10.3/server/lib/fusion_trust.jks.And where <password> is the truststore password.

  5. Call the patchPolicyStore script as follows:

    patchPolicyStore(phase="analyze", baselineFile=<previous_jazn>, patchFile=<system_jazn>,
productionJpsConfig=<copy_of_jps_config>, patchDeltaFolder=<delta_dir>, baselineAppStripe="obi")

    Where:

    • <previous_jazn> = a copy of the biapps_policystore.xml from before the patch is applied (see Step 1 above) e.g. ${ORACLE_HOME}/bifoundation/admin/provisioning/biapps_policystore.xml

      Opatch stores the copy of the biapps_policystore.xml file at:

      ${ORACLE_HOME}/.patch_storage/<patch_number>_<date>/backup/bifoundation/admin/provisioning/biapps_policystore.xml

    • <system_jazn> = the new biapps_policystore.xm in the Oracle Home. E.g. ${ORACLE_HOME}/bifoundation/admin/provisioning/biapps_policystore.xml

    • <copy_of_jps_config> = the jps-config edited as mentioned above e.g. ${ORACLE_HOME}/BIDomain/config/fmwconfig/copy-jps-config.xml

    • <delta_dir> = a directory to store the results of the analysis e.g. $tmp/jazn_patch_delta

  6. Resolve any conflicts.

    For more information, refer to OPSS Patching Tool documentation.

  7. Call patchPolicyStore() with 'apply', that is:

    patchPolicyStore(phase="apply", productionJpsConfig=<jps_config>, patchDeltaFolder=<delta_dir>, 
baselineAppStripe="obi")

4.4.2 Applying an Oracle BI Applications Configuration Manager Patch

To apply an Oracle BI Applications Configuration Manager patch:

  1. Copy or download the OPatch archive.

    For example, you might copy a downloaded archive called 1234567.zip, to the folder /scratch/patchBase.

  2. Backup all metadata.

    Metadata must be backed up using your normal backup mechanisms.

  3. Stop the Oracle Business Intelligence components.

    Since the patch will make updates to the runtime metadata you must do this to avoid locking issues; the patch might fail if you do not do this. In addition, not all metadata updates will be visible until Oracle Business Intelligence is restarted.

    Use Fusion Middleware Control to stop Oracle Business Intelligence components. For more information, see 'Using Fusion Middleware Control to Start and Stop Oracle Business Intelligence System Components and Java Components' in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

  4. If the patch contains BI Applications Configuration Manager binary updates, you must also stop the Admin server.

    Use Oracle WebLogic Server Administration Console to stop the Admin server. For more information, see 'Using Oracle WebLogic Server Administration Console to Start and Stop Java Components ' in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

  5. Apply a BI Applications Configuration Manager patch.

    You apply a BI Applications Configuration Manager patch using the copy of OPatch in the Oracle home.

    Note: A data warehouse schema must have already been created using the Repository Creation Utility (RCU).

    For UNIX use the following syntax:

    ./opatch apply -post <hostname:port:servicename/SID> <data_warehouse_schema_username> <data_warehouse_schema_password> -opatch_post_end <path to unzipped patch dir>

    For example, if you copied your patch archive to /scratch/patchBase/456789.zip, enter the following command:

    ./opatch apply -post mycomputer.mycompany.com:1521:mydatabase mydbusername mydbpassword -opatch_post_end /scratch/patchBase/456789.zip

  6. Re-start the Oracle Business Intelligence components

    For more information, see 'Using Fusion Middleware Control to Start and Stop Oracle Business Intelligence System Components and Java Components' in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

  7. Re-start the Admin server (if stopped in step 4).

    For more information, see 'Using Oracle WebLogic Server Administration Console to Start and Stop Java Components' in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

4.5 Diagnosing Whether Oracle BI Applications Patches Are Applied Correctly

During the application of a patch, OPatch will output status results to the command window. If the patch was applied correctly, the last statement will be "OPatch succeeded". If there are any errors, these will be reported and captured in the log file located in <ORACLE_HOME>/cfgtoollogs/opatch/opatch<timestamp>.log.

4.6 Rolling Back Failed Oracle BI Applications Patches

If you roll back a patch with metadata updates, different steps are required compared to if you roll back a patch with just binary file updates.

To rollback a failed Oracle BI Applications patch:

  1. Rollback the OPatch archive.

    This step removes the OPatch inventory metadata, allowing the patch to be applied again in the future. However, it does not update the changes made to the metadata (see next step).

    ./opatch rollback -ID 1234567

    Where 1234567 is the patch id.

  2. Replace the updated metadata from your backup area.

    Only complete this step if the patch contains metadata updates to the Oracle Business Intelligence Repository (RPD), Oracle BI Presentation Catalog, Informatica Repository, or DAC.

    In order to get the metadata that was updated by the patch to be as it was before the patch, you need to manually copy the metadata from your backup area (see step 3 of the 'apply' flow above). You must copy this to both the Oracle home and the runtime locations.

    Warning: If you roll back, you will lose any customizations made since the patch was applied.

4.7 What Happens if Conflicts Are Detected When Applying an Oracle BI Applications Patch?

For DAC and Informatica PowerCenter metadata patches, the updates included in the patch will replace metadata in customer repositories. If customers have made any changes to the metadata since the initial install, these changes are lost, and will need to be reapplied after the patch. For this reason there are no conflicts during the patch apply cycle itself for these metadata types.

When you patch the Oracle BI Repository (RPD) and Oracle BI Presentation Catalog, updates are merged into the existing customer runtime repositories. However, there will be cases where the metadata included in the patch cannot be merged without user intervention, that is, a choice needs to be made.

Where such a conflict occurs the patch will fail to apply, and details of the conflicts will be given in the log file. These conflicts need to be resolved first and then the patch re-applied.

In order to resolve the conflicts customers can use the standard Oracle Business Intelligence platform tools appropriate for the metadata type in questions. For example, for conflicts in the Oracle Business Intelligence Repository (RPD) use the Oracle BI Administration Tool, and for conflicts in the Oracle BI Presentation Catalog use the Catalog Manager. Using these tools customers need to resolve the conflicts, re-apply the patch, and then apply their customizations on top of the patched metadata.

4.7.1 Resolving Conflicts for Oracle BI Presentation Catalog Updates

Follow the instructions outlined here to resolve conflicts for the Oracle BI Presentation Catalog updates.

For more information, see 'Configuring and Managing the Oracle BI Presentation Catalog' in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

To resolve conflicts for Oracle BI Presentation Catalog updates:

  1. Start the Catalog Manager (CatMan1), and open your runtime Oracle BI Presentation Catalog in offline mode.

  2. Open a second instance of the Catalog Manager (CatMan2), and open the Oracle home Presentation Catalog in offline mode.

  3. Review the list of objects with conflicts in the patch log.

  4. Archive the runtime Oracle BI Presentation Catalog:

    For instructions, see "Archiving and Unarchiving Using Catalog Manager," in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

  5. For each object with a conflict, do the following:

    1. In the Oracle home Presentation Catalog (CatMan2) copy the object.

    2. Paste the object into the runtime Oracle BI Presentation Catalog (CatMan1) using the "Force" paste option.

      For more information about copying and pasting objects, see "Copying and Pasting Objects" in Oracle Fusion Middleware System Administrator's Guide for Oracle Business Intelligence Enterprise Edition.

    The runtime Oracle BI Presentation Catalog now has its conflicting objects reset to the Oracle home equivalent.

  6. Re-apply the patch.

4.7.2 Resolving Conflicts for Oracle BI Repository (RPD) Updates

Follow the instructions outlined here to resolve conflicts for Oracle BI Repository (RPD) updates.

For more information, see 'Applying a Repository Patch' in Oracle Fusion Middleware Metadata Repository Builder's Guide for Oracle Business Intelligence Enterprise Edition (Oracle Fusion Applications Edition).

To resolve conflicts for Oracle BI Repository (RPD) updates:

  1. Retrieve the Oracle BI Repository 'diff' file from the location in the log.

  2. Open the Oracle BI Administration Tool.

  3. Open the modified/customer repository.

  4. Select File, and Merge from the menu.

  5. Select merge type as Patch Repository Merge.

  6. Select the patch 'diff' file.

    The location for this file is specified in the patch apply logs.

  7. Choose the original repository to be the "original" Oracle Business Intelligence Repository (RPD) in the Oracle home.

  8. Enter the password for the original RPD.

  9. Display the next page of the Wizard to see a list of conflicts.

  10. For each conflict mentioned in the patch log, select "current", (accepting the change from the patch).

  11. Re-apply the patch.

4.8 Sample Patch Properties File

You can modify the example apply-patch.properties file described in this section, to reference in the OPatch apply command.

The OPatch command must include the full file path, for example if the file is in: /scratch/biapps/mwhome/Oracle_BI1/apply-patch.properties, then you would enter the following opatch command:

./OPatch/opatch apply -pre /scratch/biapps/mwhome/Oracle_BI1/apply-patch.properties -opatch_pre_end 1234567.zip

Note: The latest version of this file is available in the patch archive at custom/ patch.properties.

The contents of the apply-patch.properties file is as follows:

#
#BI Applications Apply Patch Properties
#

#RPD
#The following properties are required if the patch contains updates to the RPD (aka Oracle Business Intelligence Repository)

#Full path to target RPD File (that is, the RPD file used in the runtime system)
rpd.targetRPDFile =

#password for the target RPD
rpd.targetPassword = 

#password for the original RPD (that is, the RPD file shipped by Oracle, in Oracle home)
rpd.originalPassword = 



#Web Catalog
#The following properties are required if the patch contains updates to the Web Catalog (aka Oracle BI Presentation Catalog)

#Root Directory of target Web Catalog (that is, the Web Catalog used in the runtime system)
webcat.target.root =

#Root Directory of target Oracle Instance (under instances)
oracle.instance.root =



#Informatica Content
#The following properties are required if the patch contains updates to the shipped Informatica content

#Informatica Home Directory (under which server/bin/pmrep lives)
infa.home =

#Informatica Repository Name
infa.repo.name =

#Informatica Repository Domain
infa.repo.domain =

#Informatica Repository Username
infa.repo.username =

#Informatica Repository Password
infa.repo.password =

#Informatica Repository Hostname
infa.repo.hostname =

#Informatica Repository Server Port (default is 6001)
infa.repo.port =



#DAC Content
#The following properties are required if the patch contains updates to the shipped DAC content

#DAC repository hostname
dac.repo.hostname =

#DAC repository server port (default is 1521)
dac.repo.port =

#DAC repository server servicename/SID
dac.repo.serviceName =

#DAC repository username
dac.repo.username =

#DAC repository password
dac.repo.password =
Go to previous page
Previous		 Go to next page
Next
Go to Documentation Home
Home		 Go to Book List
Book List		 Go to Table of Contents
Contents		 Go to Index
Index		 Go to Feedback page
Contact Us