Increased Efficiency Utilizing Saved Objects in Financial Reporting

All developers understand the power of using objects during development activities, a concept that can be leveraged in the development of Oracle/Hyperion Financial Reports. Utilizing saved objects allows the development team to deliver a product in less time and provides the ability to quickly react to future report modifications. The information below (1) provides common saved object examples and (2) displays how saved objects are created and used.

What type of report information should be converted into saved objects?

The goal behind utilizing saved objects is to avoid the recreation of code, thus I find it valuable to turn all report header and footer information into saved objects. Items such as company logo’s, report title/sub-tile information, dimensional point-of-view selections, date & time stamps, page numbers and data source information make for great saved objects as they typically reside on all financial or management reports.

The usefulness of report objects may seem less important during the early stages of development, but as your reporting repository grows, their impact becomes increasingly important. For example, changing a company logo on a few reports is a minor incontinence, but making that same change to 50 reports could take hours to complete, resulting in the inefficient use of development/ maintenance time.

How are saved objects created and used?

Creating saved objects is a simple process that requires one additional step after the initial creation of your object. The example below walks through the process of creating a report title saved object. The same process will be used in the creation of all reporting saved objects.

Step 1 – Create your Object:

 

Step 2 – Save the Object:

Right-click the object and select Save Object…

Best practice involves the creation of a Saved Object folder in the report repository where all saved objects will reside. Notice the use of this folder below.

IMPORTANT – Be sure to place a checkmark next to “Link to Source Object”. This link enables future modifications of this object to resonate across all reports where this object exists. This checkbox allows for the increased efficiency when developing and maintaining reports.

Once the report has been saved, notice the object name changes.

 

Step 3 – Use your Saved Object:

Once the object has been saved you can reference it in future report development via the link. Create a new report and insert the saved object.

 

Be sure to select the Type of “Text” (It will always default to Grid) and place a checkmark next to “Link to Source Object”. 

FYI: When inserting saved objects you have 4 choices (Grid, Text, Image and Chart). Be sure to select the correct type in order to locate the desired saved object.

Note that when saved objects are inserted, they are placed in the body of the report by default; the developer will need to place the saved object in the correct position on the report.

 




Getting large numbers in FR Reports?

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.