Optimizing Hyperion Planning Web Forms

Optimizing Hyperion Planning Web Forms

Hyperion Planning Data Form Design Considerations
Recommended Design:

Keep dense dimensions in rows and columns.

Place sparse dimensions in the Page and Point of View (POV).

Place static dimensions in POV and hide these dimensions where not relevant to the form.

Place Scenario, Version, and Year dimensions in the Page wherever possible.

Use dynamic user variables and substitution variables as much as possible. Use Run on Save
and Run on Load for business rules on data forms only where business rules can complete execution
within a short timeframe (say less than 30 sec.). All other business rules should be set to launch
manually.

For planning release 9.3.1 and later, set long-running business rules to run in the background.
Limit composite data forms to two data forms where possible

Use the Suppress Missing Data option to skip #MISSING values from resultant data forms.

Split single larger data forms into multiple smaller data forms with fewer rows and columns.

Minimize using account annotations on data forms.

For planning release 9.3 and later, enable the Mass Allocate feature on data forms only where
absolutely necessary. This feature runs calculation scripts that can impact data values at intersections to
which the end user may not have access.

Optimal Design Example:

Account - Rows
Time Period - Columns
Entity and other dimensions - Page/POV
Sub-Optimal Design Example:

Entity - Rows
Year - Columns
Account, Time Period, and other dimensions - Page/POV
Performance Considerations:

The Run on Save and Run on Load calculation options place an additional demand on resources
within the Essbase server for each save or load operation performed by end users. If it is necessary to
use Run on Save or Run on Load, runtime prompts should be used to restrict the scope of the calculation
and minimize the impact on users of the Essbase server.

Execution of large calculations in batch mode. For example, we can set Planning properties to
have business rules switch to background processing after a threshold that we configure. In addition, we
can run business rules in batch mode using the options under Tools > Business Rules.

When users access data form members that are dynamically calculated or have member
formulas, an additional load is placed on the Essbase server. The impact is more acute during heavier
user load.

The biggest impact on data form performance is the grid size. Grid size consists of the number of
rows, multiplied by the number of columns. The grid size doubles if an application uses multiple
currencies.


Adjust the number of cells retrieved to the memory on end users' client machines. To determine
the number of cells, multiply the number of rows by the number of columns.

The Suppress Missing Blocks option for rows allows placing large sparse dimensions in rows,
while providing good response time if the density of the query is low. Only blocks with data are
retrieved. For example, when using this option, we can place an employee dimension consisting of
thousands of members in the rows, and place the entity in the page or POV. Then, only employees of the
selected entity are retrieved.

Using Suppress Missing Data can improve performance. Before using this feature however it is
recommended that we test the impact on performance.

Using account annotations impacts performance. Use this option only if account annotations are
required. If the Supporting Detail Detection Cache reaches 75% or higher, the cache size should be
increased.

Enabling shared member security impacts performance. Use this option only if we want the base
member's security to be based on its own security and that of all of its shared members. If this option is
not enabled, users with access to the base member still have access to all of its shared members.

The administrator should define data forms using dynamic user variables, to narrow the data form
display to the dimensionality required by users. End users can set the value for the user variable in
preferences.

When Planning is first loaded, the first few requests to Planning can take longer because caches
might not be loaded. It is recommended that an administrator or power user pre-load the most commonly
used data forms before the general community uses the Planning server after each reboot to the Planning
server.

It is highly recommended that administrators conduct performance tests on data forms to ensure
that they meet user expectations. Data forms should be tested in both single and multi-user environments
before they are deployed to production.

Data form definitions are cached when users log on to a Planning application. Because one
cache is created for data form definitions, memory usage is not affected by the number of users viewing
data forms. However, memory usage goes up if multiple users enter data in data forms at the same time.
Data Form Size Estimation:
To get a rough estimate of data form size, open the data form and select File > Save As from the
browser. The size of the .HTML file is the portion of the data form that changes based on grid size. The
.JS files remain the same size and can be cached, depending on browser settings. Information such as
data form definitions, pages, and .gif files are not compressed when data forms are opened and sent to
the Web browser.
About Suppression

Planning follows this basic sequence to suppress information in data forms, depending on
suppression settings for Suppress Missing Blocks and Suppress Missing Data.

First, Planning evaluates the data form definition and creates a grid to send to Essbase.

If Suppress Missing Blocks is selected for data form rows:

Planning queries Essbase to determine which members in the data form

definition have data blocks and filters out members for which the user does not have access permissions.
This query typically takes only a few milliseconds. (This setting is most effective for sparse dimensions,
and should not be used for dense dimensions.).
Next, Planning constructs a grid, and sends information to Essbase to fill in the data. (The constructed
grid is generally very small, so the result is returned quickly from Essbase.)

If Suppress Missing Data is selected, Planning suppresses data for any #MISSING data element.
(This operation generally occurs quickly. However, if a large volume of data is set to #MISSING, or blocks
are created but have no data, this can take some time.)

The Web data form is then presented to the user.