Many IT and finance departments are being asked to make their budgets go farther on less money. The best practice...
for a full-lifecycle Hyperion enterprise performance management financial-consolidation implementation is to conduct formal testing rounds for system integration, performance and user acceptance before even getting into parallel testing of the existing and new systems. But, when the budget for a Hyperion EPM project gets squeezed, performance testing often is what's cut.
Performance testing for Hyperion is the process of running the consolidation applications and associated tools to determine how well the Hyperion system environment -- both hardware and network -- functions. There are two types of performance testing. A load test checks the environment at expected usage levels, while a stress test assesses how it performs at usage levels above the expected peak.
Recently, I was working on an implementation of Oracle EPM 184.108.40.206 (as the technology is now formally known) at a company that owned a license for Hewlett Packard Enterprise's LoadRunner testing tool. Unfortunately, LoadRunner was managed by a different department than the one implementing the Hyperion EPM software. The company had a cross-charge program under which a department requesting the use of another's IT resources would be charged for the cost of use. Since the Hyperion project budget was under tight constraints, using LoadRunner to do the performance testing was a no-go.
However, that didn't make it any less important for my client to conduct a load test. The company needed real evidence that its system environment could perform as expected when it went live with the Hyperion EPM applications. So, we came up with a way to perform load testing on the cheap. We considered our options and saw that we could utilize some of the 220.127.116.11 software's functionality to run a load test without LoadRunner. I call what we devised the "Scrappy Performance Test" -- here's how it works.
Three Hyperion tasks in need of testing
In a Hyperion EPM consolidation system, there are typically three tasks that take up significant processing resources: running the consolidations, loading data and running follow-up reports. There are robust features built into 18.104.22.168 to batch and schedule all three of these tasks. That allows you to run the tasks in high volume for a load test without needing to simulate user activities with a tool like LoadRunner.
Task flows, as Oracle terms them, are the keys to batching and scheduling consolidations in the Hyperion Financial Management (HFM) application. The task flow feature has stabilized in HFM 22.214.171.124 and is now reliable enough to use, both for testing purposes and in production applications. It allows you to create sequences of consolidations in HFM and set up multiple task flows so that you can have parallel consolidation jobs running simultaneously. Task flows can be run on demand; in addition, a scheduling function lets you pick a date and time for task flow jobs to execute.
As part of our performance test, we batched and scheduled data loading processes in Oracle Hyperion Financial Data Quality Management Enterprise Edition, or FDMEE. We did so by creating batch definitions and then using FDMEE's batch execution engine to process the data loads. The software's batch definitions feature allows you to add multiple data load rules and process all the steps in the FDMEE workbench, from import to validate to export. Batch data-loading jobs can run in both parallel and serial modes -- parallel makes the most sense for performance testing.
Rules of the data load road
Remember that data load rules are a part of the data load locations you create in FDMEE to specify where data will go in a target Hyperion EPM system. When you set up a data load location, you can attach a check entity group to it, which allows you to define the entities in the HFM application that will be calculated or consolidated after the export step. This saves time by kicking off a calculate or consolidate command in HFM immediately after the data is loaded. You can also build your batch definitions to include running consolidations in the HFM target application. Then, in executing the batches, you have the option to run them on demand or on a predetermined schedule.
Finally, we batched and scheduled reports to run in Hyperion Financial Reporting. That has been a long-standing feature in the reporting software, but an underused one. It's a perfect tool to use for load testing, since you can add as many reports as you need into a batch. Then use the software's batch scheduler functionality to specify when to run the batch job. This lets you simulate the effect of many different users running reports that pull data from the HFM application.
Used together, these different functions readily available in Oracle EPM 126.96.36.199 allow you to put together a credible load test that simulates high data volume and user activity. The icing on the cake is that you don't have to spend a chunk of your Hyperion project budget on a third-party tool to complete your performance test.
The rules for writing scripts in Hyperion Financial Management
Plan ahead for your Hyperion EPM implementation
The three faces of Hyperion project implementation