Analyze implementation options

Rule implementation specifies how PerformancePoint Planning Business Modeler processes and stores a business rule, and how the rule interacts with underlying data.

Read this article for background information and general guidelines that can help you decide which implementation makes the most sense for a given business rule.

  Implementation and performance

Implementation choice is one of the primary factors in performance, but performance is also strongly affected by other factors. For example, the number and complexity of data queries has a strong impact on performance, as do dependencies that may exist between rules. As a result, performance can vary significantly between different implementations of the same business rule.

Important: We recommend that, whenever possible, you compose your business rules in PerformancePoint Expression Language (PEL). When you use PEL to write a rule, you can write the rule one time, run the rule with different implementations, and then compare the performance of each implementation, and choose the most efficient implementation.

  Implementation and storage location

Implementation choice determines the storage location. For example, when you implement a rule with MdxScript, PerformancePoint Planning Server stores a formula in the model cube that corresponds to the rule. The stored formula executes every time that the affected cells in the cube are queried, and Planning Server caches the calculated values in the cube memory.

Alternatively, when you select SQL implementation, Planning Server stores the rule as a stored procedure in the SQL Server database. Rules with an SQL implementation must be specifically invoked in a scheduled job, or executed by user command.

  Implementation and processing

To process a business rule, Planning Business Modeler first creates an intermediate form of the business rule. Then, Planning Server passes the intermediate form of the rule to its destination component for execution.

Use the following table to determine which implementation option is most appropriate to a given set of circumstances.

How should your rule operate?

Then explore

Will the rule be part of the model definition? Should Planning Business Modeler run the rule every time that the model is queried?

MdxScript implementation in a definition rule set.

Should the rule run as a scheduled job, or as part of a larger process?

SQL or MdxQuery implementation in a procedural rule set.

Should Planning Business Modeler run the rule automatically for you?

SQL or MdxQuery implementation in an automatic rule set.

Does your rule have to write values back to the fact table?

SQL or MdxQuery implementation in an automatic or procedural rule set.

Does your rule perform calculations on data in the model cube?

MdxQuery implementation in an automatic or procedural rule set.

Should your rule generate a very large member set?

SQL implementation in an automatic or procedural rule set.

Should your rule use functions that may not be supported by PerformancePoint Expression Language?

MdxQuery implementation in an automatic or procedural rule set.

Important: You cannot select an implementation for a specialized rule type, such as a consolidation rule or a currency rule. Each specialized rule type has a fixed, specialized implementation.

Top of Page

Share Facebook Facebook Twitter Twitter Email Email

Was this information helpful?

Great! Any other feedback?

How can we improve it?

Thank you for your feedback!