What Is Customization in Oracle BI Applications?
In Oracle BI Applications, customization allows you to change the preconfigured behavior and analyze new information in your business intelligence dashboards.
For example, you might want to add a column to a dashboard by extracting data from the field HZ_CUST_ACCOUNTS.ATTRIBUTE1 and storing it in the Oracle Business Analytics Warehouse in the X_ACCOUNT_LOG field.
The type of data source that you have determines the types of customization available for you. Data sources are one of the following types:
-
Packaged applications (for example, Oracle Fusion or Oracle E-Business Suite), which use prepackaged adapters.
-
Non-packaged data sources, which use the Universal adapter.
The figure summarizes the category of customization that you can perform for each type of data source and type of modification.
Customizations are grouped into the following categories:
-
Category 1. In a Category 1 customization, you add additional columns from the source systems that have pre-packaged adapters and load the data into the existing Oracle Business Analytics Warehouse tables. See Category 1 Customizations: Adding Columns to Existing Fact or Dimension Tables.
-
Category 2. In a Category 2 customization, you use pre-packaged adapters to add new fact or dimension tables to the Oracle Business Analytics Warehouse. Category 2 customizations normally require that you build new Source Dependent Extract (SDE) and Source Independent Load (SIL) mappings. See Category 2 Customizations: Adding Additional Tables.
-
Category 3. In a Category 3 customization, you use the Universal adapter to load data from sources that do not have pre-packaged adapters. See Category 3 Customizations: Adding New Data.
When you customize ETL Packages and Interfaces, you usually work in the \Oracle BI Applications\Mappings folder in the Projects view in the Designer of Oracle Data Integrator (ODI).
Note:
The customization methodology is to make a copy of the ETL task and version both the original and copy while a datastore is simply versioned. These versions allow you to revert functionality if required as well as identify changes that have been introduced through customization, patches, or upgrades.Note:
You must not rename, delete, or move packaged objects in the ODI repository unless you are directed to do so by Oracle Support. For example, you must not move a datastore in the Fact Staging folder to the Dimension Staging folder, or must not rename a packaged index named W_EXAMPLE_F_U1 to W_EXAMPLE_F_U2, unless directed by Oracle Support. You can make copies of packaged ODI objects and place them in custom folders, but do not delete, rename, or move the original objects.About the Customization Process
You can customize your ETL functionality after you have performed a Business Analysis and Technical Analysis.
However, this information does not cover the other typical tasks that you must perform:
-
Business Analysis — before you start customization, you typically analyze your current BI dashboards to determine the changes you need to support your business or organization.
-
Technical Analysis — when you have identified your business requirements, you must determine the technical changes you need to make, by identifying source tables, staging tables, target tables, and ODI Packages and Interfaces that you must modify.
-
Repository (RPD) Modification — having made the customizations in the ETL functionality, you must modify your repository to expose the new data in your dashboards.
Patching Customized Objects
This section explains how to re-apply a customization to an object that has been patched. For example, if you install an Oracle BI Applications patch that modifies the Supply Chain and Order Management application, you must manually re-apply customizations that you have made to the Supply Chain and Order Management application.
A patch only installs changed repository objects, not the whole Work Repository. Therefore, you must re-apply customizations to mappings that have been changed by the patch. For example, if a patch only modifies the Supply Chain and Order Management application, you must manually re-apply customizations that you have made to the Supply Chain and Order Management application. The patch does not affect customizations in other applications.
As part of customizing an ETL task (including interfaces and package under a specific task folder), you copy the task folder to be customized to a Custom folder, version the copy once to freeze the original state, and version the copy again to capture the customized state. To modify and version ETL customizations, see Extending Mappings in Oracle Business Analytics Warehouse.
You can customize and patch different ODI objects. Depending on the object, you must follow different steps to merge the patch and customizations.
If an object is customized, but is not being patched, this section does not apply. Similarly, if an object is patched but is not customized, you don’t need to follow these steps.
Note:
All customization steps have you create a Custom adaptor folder where customized ETL tasks are stored. This is not required, but is considered a best practice to make identifying customized content easier.Patching Customized ETL Tasks
If you have customized the ETL task to be patched, follow these steps. Note that there are two use cases where an ETL task might have been customized, either at the direction of Oracle to quickly apply a fix before a patch becomes available or as the result of normal implementation activities to enhance Oracle BI Applications with additional functionality.
Customization Performed at Direction of Oracle
If you have customized at the direction of Oracle as a means to manually implement a fix, you must have a separate copy of the original object in a separate Custom or Patch folder. The ETL task has a scenario associated with it whose version is set to a value higher than 001. To apply a patch, simply delete this scenario. The patched out-of-the-box scenario is automatically used the next time when the load plan runs.
Customization Performed as an Extension of Functionality
If you have customized the object being patched to introduce new behavior, merge the fix and the customizations into a single ETL task. When you first customize the task, the customization methodology requires that you create a copy of the ETL task and version it, for example to version 001. This version represents the original state of the ETL task. Prior to customization, you version the ETL task again, for example to version 002. You then apply your customizations to the new version. You can use the version compare utility of ODI to note the changes that have been introduced.
Prior to patching the out-of-the-box ETL task, you must version the out-of-the-box ETL task, to version 001 for example, then version it again, for example to 002. You then apply the patch. The 001 version represents the original state of the ETL task and 002 now represents the patched state. You can compare the out-of-the-box 002 version to the out-of-the-box 001 version to determine the changes introduced by the patch.
Note that you now have two original, or 001, versions, both representing the original state of the ETL task. You also now have two 002 versions, one a custom version and the other a patched version.
To get the fixes from the patch to appear in the custom folder, one approach is to manually apply the changes noted in the patched 002 version directly in the customized 002 version and then regenerate the scenario. This is the simplest approach and is recommended when a patch fix is relatively simple to determine and deploy.
If the patch fix is relatively complex while the customizations are relatively simple, an alternate approach is to re-apply the customizations to a new copy of the patched version. In this case, you rename the 002 custom version of the ETL task, for example to include Old or Prior as a suffix, copy the 002 patched version to the Custom adaptor, version it, version it again, then re-apply your customizations to the latest version. Generate the scenario with a larger number. If the original ETL task uses 001 and your prior customized ETL task uses 002, then you use 003 with this latest copy.
Patching Customized Datastores
As part of the customization methodology, datastores that are customized are first versioned to represent the original out-of-the-box state and versioned again to represent the customized state. If you have customized a datastore and want to patch the datastore, the patching process merges the datastore to reflect the custom and patch changes in the same datastore. You might want to create another version of the datastore prior to applying the patch, which represents the patched and customized state.
Patching Other Objects
Oracle does not recommend directly customizing commonly used objects such as Knowledge Modules, Variables, and User Defined Functions. If you need to customize such an object to manually apply a fix at Oracle’s direction or to enhance out-of-the-box functionality, make a copy of the object, version to freeze the original state, and then version again to reflect the customized state. At this point, ETL tasks follow the same customization steps and are modified to use the custom copies of these objects. Follow the same steps as patching customized ETL tasks.