nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Oracle Communities

Oracle Analytics and AI

Child Item

Oracle Analytics Cloud Data Visualization Issue with Essbase Cube

Ajinkya Vyawahare

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:

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

Any insights or guidance would be greatly appreciated.

Find more posts tagged with

Essbase

OAC

EPM

Accepted answers

All comments

Ajinkya Vyawahare

Can someone please help

Steve F-2

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.

Wayne Van Sluys

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?

Ajinkya Vyawahare

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?

Santhosh_N

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

Wayne Van Sluys

https://community.oracle.com/products/oracleanalytics/discussion/comment/66158#Comment_66158

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

Ajinkya Vyawahare

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

Carter Beaton

@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).

Ajinkya Vyawahare

Thanks, will try this approach.