1. Creating and Administering Analytics and Reports
  2. Overview of Flexfield Change Import

Overview of Flexfield Change Import

You can use the Import Oracle Fusion Data Extensions for Transactional Business Intelligence scheduled process to import your flexfield changes.

Use the Import Oracle Fusion Data Extensions for Transactional Business Intelligence scheduled process to automatically import the following types of changes:

  • Key Flexfield changes

  • Descriptive Flexfield changes

  • Extensible Flexfield changes

The Import Oracle Fusion Data Extensions for Transactional Business Intelligence scheduled process imports extensible data, including data in descriptive flexfield segments, key flexfield segments, and General Ledger balances in Essbase cubes.

If you have changes to key flexfields and descriptive flexfields, you can import all the changes in the same scheduled process.

This is an Oracle Applications Cloud scheduled process; it's not related to BI Applications. Detailed information on this process can be found in Oracle Applications Cloud documentation.

Note:

We strongly recommend that you backup the Oracle Transactional Business Intelligence prior to importing any flexfield changes. Running the process disconnects all users from the server. You should not run this process when maintenance operations or system updates are being performed on the server.

Performance and Flexfields

Flexfield changes and additions increase the size of the metadata repository and over time can cause performance issues or the repository size to exceed limitations. We recommend that you import and enable for BI only those flexfields that are required. To preserve performance, the following guidelines should be kept in mind:
  • Don't BI-enable extensible flexfield (EFF) attributes that aren't needed for analysis in OTBI.
  • Disable EFF attributes that are no longer being used. Limit the number of attributes that are inherited by a large number of classes to be BI enabled, as this results in increased repository size.

Extensible Flexfields and Repository Size

If all BI-enabled attributes are assigned at the root level, then the repository size calculation is the total number of item classes multiplied by the number of BI-enabled attributes. If not, the size calculation is based on the number of child item classes for an item class to which the BI-enabled attribute is assigned.

Let's look at an example. If BI-enabled attribute ABC is assigned to item class XYZ and it has 10 child item classes, it would generate a segment for each. So BI-enabled segments at item class XYZ (in this case having only one attribute, ABC) would be 10. Also note that the EFF attributes are copied in each subject area of the repository where the Item dimension is used. So, if there are 20 subject areas with the Item dimension, the ABC attribute appears in all of them, thus showing up 200 times, or 10 segments multiplied by 20.