Data Map Error:
Push Data failed. Error: Exported data size of data map that is being executed from groovy is more than permissible amount: 100 MB.
If you are confused, join the club. The results are inconsistent as some data pushes are successful that are over the 100MB limit. So, why the following error? Read more
If you have jumped into Groovy Calculations, one of the things you likely would try to do is grab a value for a sub var. Hopefully, you haven’t spent too much time before reading this. I wasted a ton of time trying to get this to work before I opened a ticket with Oracle. This class is NOT available yet and was inadvertently included in the public docs at https://docs.oracle.com/cloud/latest/epm-common/GROOV/. The development team told me they are going to remove it from the API docs. Read more
Oracle has confirmed a bug related to the deployment of security with a planning application maintained in EPMA in version 11.1.2.x. When the Shared Members checkbox is selected in an EPMA deployment of a Planning application, it ignores this option. Even if the Shared Members box is checked, the user still only gets access to Ohio Region, and not the children, in the example below. Oracle is currently working on a patch. Read more
When using Workspace to view reports, some users have seen excessively large numbers that don’t belong. If you are having this issue, it could very well be because the default Essbase query engine in 11.1.1.x is the MDX query engine, which can cause documented bug 9062413. Essentially, this bug will cause users to see the same astronomical number in every cell that sits on an intersection to which the user does not have security access. Understandably, this can cause some concern. This issue is expected to be fixed in a future release, but until then, the query engine will need to be manually changed.
The first option is to fix the issue at a report level. This is a relatively quick process and is a good idea if you only have a handful of reports. To change the query engine setting for a particular report, follow the steps below:
1. Open the report.
2. For each grid, select the entire grid.
3. Right-click and select Data Query Optimization Settings.
4. Deselect the option “Essbase Queries Use MDX.”
5. Save the report.
Repeat the above process for each report.
For users that have a larger number of reports, a better option may be to change the query engine in the properties file on the server. The benefit to fixing the issue in the properties file is that changes only need to be made once, and all reports will reflect this change.
The file that needs to be edited is located on the Financial Reporting (app) server, typically on the path D:\<Hyperion Home>\products\biplus\lib where <Hyperion Home> represents the root location of the Hyperion install. The file that needs adjusted is the fr_global.properties file.
Open the properties file and add these lines:
# MDX Query Engine has been set as the default in Essbase 11.1.1.x. This can cause bug 9062413
# which may cause unauthorized users to see a long series of numbers in each cell when running
# reports. To solve this issue, the below line was added, which switches the query engine.
EssbaseUseMDX=false
Any line preceded by “#” is commented out. Therefore, these can say whatever you prefer, but should give anyone that views this file a good indication why this text is in the file.
Once the properties file has been updated, the following services must all be stopped in the following order, then started in the same order for the changes to take effect.
1. Hyperion Financial Reporting – Print Server
2. Hyperion Financial Reporting – Report Server
3. Hyperion Financial Reporting – Scheduler Server
4. Hyperion Financial Reporting – Web Application (Note – This service may be on the FR (Web) server, not the FR(App) server like the other three services.)
Note – This modification will apply to everyone using the server on which they are made, so be careful when making changes to a shared server.