What is Customization in Oracle Business Intelligence Applications?
In Oracle Business Intelligence Applications, customization is defined as changing the preconfigured behavior to enable you to 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 type of customization that you can do. Data sources can be one of the following types:
-
Packaged applications (for example, Oracle Fusion or EBS), 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 source systems that have pre-packaged adapters and load the data into existing Oracle Business Analytics Warehouse tables. For more information about performing Category 1 customizations, 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 SDE and SIL mappings. For more information about performing Category 2 customizations, 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. For more information about performing Category 3 customizations, see Category 3 Customizations: Adding New Data as a Whole Row into a Standard Dimension Table.
For detailed information about tables and naming conventions, see Oracle Business Analytics Warehouse Data Model Reference.
When you customize ETL Packages and Interfaces, you usually work in the \Oracle BI Applications\Mappings folder in the Projects view in ODI Studio's Designer Navigator.
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, a datastore in the Fact Staging folder should not be moved to the Dimension Staging folder, or a packaged index named W_EXAMPLE_F_U1 should not be renamed 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 need to 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 need to determine the technical changes you need to make, by identifying source tables, staging tables, target tables, and ODI Packages and Interfaces that you need to modify.
-
RPD Modification — having made the customizations in the ETL functionality, you need to modify your RPD to expose the new data in your dashboards. For more information about RPD modification, refer to the Oracle Business Intelligence Enterprise Edition documentation library.
Patching Customized Objects
This section explains what you must do to re-apply a customization to an object that has been patched. For example, if you install an Oracle Business Intelligence Applications patch that modifies the Supply Chain and Order Management application, you might need to 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 only need to 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 only need to manually re-apply customizations that you have made to the Supply Chain and Order Management application. Customizations in other applications are not affected by the patch.
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 again to capture the customized state. For information about modifying and versioning ETL customizations, refer to Typical Steps to Extend Mappings in the Oracle Business Analytics Warehouse.
Different ODI objects can be customized and patched. Depending on the object, different steps need to be followed to merge the patch and customizations.
If an object was customized but is not being patched, this section does not apply. Similarly, if an object is patched but was not customized, there is no 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 the ETL task to be patched was customized, you should follow these steps. Note that there are two use cases where an ETL task may 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 the customization was performed at the direction of Oracle as a means to manually implement a fix, you should 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 the load plan runs.
Customization Performed as an Extension of Functionality
If the object being patched was customized to introduce new behavior, the fix and the customizations need to be merged into a single ETL task. When originally customizing 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 ODI’s version compare utility to note the changes that have been introduced.
Prior to patching the out-of-the-box ETL task, you need to 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 ptched 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, you would then 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 a datastore was customized and needs to be patched, the patching process should merge the datastore so that the custom and patch changes are reflected in the same datastore. While not required, you may want to create another version of the datastore prior to applying the patch, which would represent the patched and customized state.
Patching Other Objects
Generally speaking, Oracle does not recommend directly customizing commonly used objects such as Knowledge Modules, Variables and User Defined Functions. If such an object needs to be customized to manually apply a fix at Oracle’s direction or to enhance out-of-the-box functionality, a copy should be made of the object, versioned to freeze the original state, and then versioned 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.