An interesting issue appeared for me recently. What happens when after a server crash / restart, Essbase refuses to start? The service shows Running, but Essbase isn’t listening and not responding. The start attempt produces no errors, no logs, it simply does not start.
In Part 1 of this blog, we discussed using the “runbatch” command to process files for three Locations. In Part 2, we will discuss using the “rundatarule” command to accomplish the same thing.
As with many solutions… it depends. “What a surprise,” you say. Your choice will probably be based upon your need, preferences, and also on how comfortable/proficient you are with writing batch scripts. If you need to execute a Data Load Rule(DLR) for one location as a part of a batch script, the answer will probably be “rundatarule.” If you need to execute DLRs for multiple locations, such as a part of a batch script to process monthly Trail Balances, then the answer becomes more subjective.
At times a developer is asked to programmatically evaluate a date and based on that date utilize the correct dimensional member. For example, we have a data point with a value of 20170630 that represents a contract date that is an important component of a contract value calculation. In this example, a calculation result must land in the Period->Years intersection determined by the YYYYMMDD date provided in the data. How would the developer achieve this end in traditional Essbase?
Executing Clear or Aggregate Calculation Script for Hyperion Planning or Essbase in FDM Classic was accomplished by writing Event Scripts. FDMEE has built-in functionality to execute Calculation Scripts for target applications. Setting up this functionality is very straightforward. I will be illustrating a simple configuration for a specific FDMEE location to execute a Clear Calculation Script Before Loading Data and an Aggregate Calculation Script After Loading Data to a Hyperion Planning application.
Maintain Custom Account Structure Requirements in Planning via Oracle DRM Sourcing: The Oracle Data Relationship Management (DRM) product has always offered impressive flexibility when it comes to meeting the metadata requirements of subscribing target systems. This flexibility extends across numerous products and systems and is not limited to just the EPM stack. This core strength goes back to the origins of the product and has been key to its evolution from its inception with Razza, on to Hyperion MDM, and now within Oracle DRM.
Anyone who has used FDMEE to automate loads via OpenBatch has come across the problem of the “openbatch” directory filling up with archive directories. FDMEE creates an archive directory each time a Batch Execution is run, whether or not any files are processed. This not only clogs up the directory, but also makes it very difficult to find previously loaded files due to FDMEE’s naming convention for archived files.
Let's discuss intra-application modular database metadata hierarchy alignment. What does that mean? When a company develops an out-of-the-box Oracle Hyperion EPBCS application such as Project, Workforce, and Capital Planning there are pre-defined dimensional members and hierarchies that probably do not align with the chart of accounts or other metadata structures specific to that organization. For example, in EPBCS Project the pre-defined account structure has separation of account types such as Revenue, Expense and then more detailed COA categories.
New Financial Reporting Web Studio and end of life for Web Analysis