About rule implementations
The rule implementation attribute specifies how Planning Business Modeler implements a rule. Implementation choice determines how Planning Business Modeler processes the rule and how the rule interacts with the underlying data.
Implementation choice is often one of the primary factors in performance. However, performance is also strongly affected by other factors. For example, the number and complexity of data queries have a strong effect 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.
The options for implementation depend on the rule type that you select. When you select a rule type, Planning Business Modeler displays the implementation options in the Creating a new rule dialog box.
Implementation choice also determines the storage location, and the operating system on which the rule will be run. For example, definition rules are implemented as MdxScript. Planning Server stores a formula in the cube that corresponds to each definition rule. The stored formula runs every time that the affected cells in the cube are queried, and Planning Server caches the calculated values in the cube memory. In contrast, an assignment rule can have a SQL implementation or MdxQuery implementation. If an assignment rule has a SQL implementation, Planning Server stores the rule as a stored procedure in the SQL database.
To process a business rule, Planning Business Modeler first creates an intermediate form of the business rule. Then, by using an intelligent subsystem that recognizes the rule type and implementation, Planning Server passes the intermediate form of the rule to its destination component for execution.
The following table describes the kinds of implementations that rules can have and notes the rule types that offer a particular implementation.
| Implementation type | Description | Rule set type | Permitted rule types |
|---|---|---|---|
Rules are written in PEL. The destination subsystem generates a SQL stored procedure from the rule that will be run against the relational database. |
|
and |
|
Rules are written in PEL. The destination subsystem generates an MDX Query statement. When the rule is run, the MDX Query statement is run against the underlying SQL Server Analysis Services (SSAS) system. The query result is written to the relational database. |
|
|
|
Rules are written in PEL. The destination subsystem generates MDX script language from the rule. Planning Server installs the script statement in the SSAS system when the model is deployed. |
Definition |
||
This category includes a group of specialized implementations that are each specific to a selected rule type. The PEL compiler generates an intermediate result that is customized for the destination component. |
|
Rule types with specialized implementations: |
You can also code rules directly in SQL, MDX Query, or MDX Script. Planning Business Modeler passes rules written in native SQL or MDX to the designated underlying system without change.
Note
To create and run rules in native SQL or MDX code, you must obtain approval from the PerformancePoint Server Global Administrator and the SQL Database Administrator. For detailed information, see Security for business rules.