Oracle Analytics Cloud and Server

Welcome to the Oracle Analytics Community: Please complete your User Profile and upload your Profile Picture

Oracle Analytics Cloud Data Visualization Issue with Essbase Cube

Received Response
106
Views
9
Comments

I'm experiencing a technical issue while working with Oracle Analytics Cloud (OAC) Data Visualization with Oracle EPM Essbase cube as the only source

Environment Details:

  • Data Source: Oracle EPM Essbase Cube
  • Data Preparation: Imported through RPD (Repository)
  • Subject Area: Configured with all attributes and measures
  • Measure Configuration: External aggregation set in RPD

Specific Problem:

When creating a pivot visualization with more than 22 measures, I'm observing unexpected data behavior:

  • Data starts duplicating across all attributes

Specific Questions:

  1. What could be causing this measure-related data duplication?
  2. Are there known limitations with measure counts in OAC when connecting to Essbase cubes?
  3. What troubleshooting steps would you recommend resolving this issue?

Any insights or guidance would be greatly appreciated.

Tagged:

Welcome!

It looks like you're new here. Sign in or register to get started.

Answers

  • Rank 6 - Analytics Lead

    Can someone please help

  • Hi @Ajinkya Vyawahare

    Thanks for your question.
    I am not aware of any documented limits, per se.

    There are some best practices

    Work with Cube Measures > About Externally Aggregated Measures

    Work with Oracle Essbase Data Sources

    This may require a service request so that someone can review it with you, but I will leave this open to other comments.

  • Have you turned on Developer Mode and looked at the Query/MDX that is generated?

    When you imported the cube did you flatten the measures?

  • Rank 6 - Analytics Lead

    HI @Wayne Van Sluys ,

    Thanks for the support. Our original configuration consolidated measures into a single column, resulting in complex queries that required navigating hierarchical structures to retrieve account values. This complexity created challenges when developing reports with complex calculations.

    In the new data model, after flattening the measures, individual columns for each account generate more straightforward queries by eliminating the need for hierarchical processing. This structural improvement directly addresses our data duplication issues.

    I have another question. When a new account is created in the Essbase cube at the source, how do we add that measure in the RPD? Do we need to reimport the cube and then flatten the measures again, or would a metadata refresh work, allowing us to create the same measure column manually and map it to the source?

  • Rank 3 - Community Apprentice

    Hi @Ajinkya Vyawahare

    What is the reason for building the reports via RPD approach when OAC can directly connect to EPM cloud? We have requirement to build reports in OAC for EPM cloud data, we are evaluating different approaches (Direct connection, RPD and use ODI to pull and load into DW) so want o know more about this RPD approach.

    Thanks

  • edited May 9, 2025 3:40PM

    Refresh metadata is messy and may mess up your subject area. it will also reimport and substitution variables.

    If you flattened the Account Dimension, you could manually add the new column in within the Physical Layer, then drag that new column through the BMM an Presentation Layer


    When Flattened I want to add another measure I look at properties of existing measure

    External Name is the member name in cube. Set Aggregation rule to External Aggregation

    Hope this helps

  • Rank 6 - Analytics Lead

    Thanks Wayne Van Sluys , we are doing the same thing when new accounts are added. Only downside is that we would not be able to use Account as Hierarchy in our reports as they are flattened

  • Rank 2 - Community Beginner

    @Ajinkya Vyawahare ,

    You can have both the Accounts measure and the Accounts flattened in the same logical layer. This would allow you to have "Account as Hierarchy" and account as a measure. You will need two database sources, one for the account measures and one for the flattened accounts in the physical layer. You would then only have one Business Model with two facts and each logical table dimension would have two sources (one pointing to account flattened and the other to account measure).

  • Rank 6 - Analytics Lead

    Thanks, will try this approach.

Welcome!

It looks like you're new here. Sign in or register to get started.