Debug Methodology for Developing Business Rules

• Always unit test the business rule on a small data set where you know the source data and the expected results, and can manually follow the calculation.
• Run the business rule in Oracle Hyperion Calculation Manager and review the log messages. Log messages are displayed in a new tab after the rule is completed and can be exported or saved. Analyzing the log files helps you identify where calculation time is being spent.
• Run each rule in a ruleset individually in Calculation Manager and review the log messages.
• Use Calculation Manager in debug mode to debug rules during development.
• If the business rule uses CALCPARALLEL or FIXPARALLEL, especially when using one of the allocate functions (@ALLOCATE or @MDALLOCATE), test by removing the parallel calculation to see if the rule runs and whether the performance improves.
• Ensure that all required data (for example, total for allocations) is present and is pre-calculated as needed before the calculation takes place.
• For lengthy scripts, start debugging at the top and work down. An issue at the beginning of the script may create issues further down. Debug section by section to ensure that all data is created correctly. Check that later sections of script do not overwrite earlier sections.

  When debugging scripts, consider the syntax length within each calculation pass. If you are unsure which part of the calculation is failing, comment out sections, one at a time, from the bottom and re-run the calculation until it runs and yields the correct results. At this point, remove comments from sections, one at a time, from the top of the calculation, testing each change as you progress.

• Use debug mode to ensure that each section of script is calculated sequentially, where required.
• To ensure that all blocks are created successfully, manually clear the data and reload. Do not use a clear script as this does not adequately test block creation.
• Always test by rerunning a script to ensure that the syntax creates correct results for input and populated data.
• Always test all data results with more than one data set. In development, always test by changing the input data from a value to another and then to #missing, and from #missing to a value and then to another value. Rerun the rule for each change and validate the results.
• Where user input may change data sets (for example, for allocations) test data changing from #missing to a value and from a value to #missing. This ensures that previously calculated results are removed, if required, during the reruns. For example, if you input data for Product A, B, and C in the first run, and for Product B, C, and D (but not A) in the second run, changing the value to #missing before the second run ensures that the allocation result for Product A is correctly removed in the second run.