Review formats for business rules in PEL

Most business rules in Planning Business Modeler are written in PerformancePoint Expression Language (PEL). PEL is a unique language that is designed specifically to create business rules, and to work with multi-dimensional information in Planning Server.

For reference information about PEL, see PerformancePoint Expression Language Reference.

When you write a business rule in PEL, the PEL compiler automatically applies several optimizations. In addition, the PEL compiler detects many error conditions at compile time. This makes it possible to debug a rule before the rule is integrated into a model and encountered by a user

PEL provides lots of flexibility

  • The PEL compiler can generate SQL or MDX. In fact, from the same PEL source, you can generate both and then compare the results. For more information, see Review methods for creating a rule.

  • Input data can reside in Online Analytical Processing (OLAP) cubes or in relational databases.

  • Rule calculations can be performed in the cube by using MDX, or in a relational database by using SQL. You can also perform calculations in main memory by using one of the specialized components in Planning Business Modeler. In addition, PEL supports dozens of powerful functions that you can use to customize your rule. For more information, see Specify the implementation type.

  • Results of calculations can be returned without storage or written to fact tables in the relational database.

As with programming in any language, PEL syntax is very important. For example, each basic component of the rule must end in a semi-colon, and all brackets and parenthesis must consist of a matching pair.

Common formats for a business rule

Although PEL is very flexible, business rules typically follow one of several standard formats.

  • Assignment rule with This keyword

    The following example shows a very common form of a business rule, which pushes the result of an action on context_scope_expression to destination_scope_expression, represented by the This keyword.

    SCOPE(destination_scope_expression)

    This= (action)(Context_scope_expression)

    END SCOPE

    The next example shows how this form can be used in an assignment rule that seeds a monthly budget.

    SCOPE(
       [BusinessProcess].[Standard].[INPUT],
       [Currency].[All Members].[USD],
       [Entity].[ResortOps].[Resort Corp],
       [ParentEntity].[All Members].[Resort Mgt],
       [Scenario].[All Members].[Budget],
       [Time].[Monthly].[Month 1 Year 2005]:[Time].[Monthly].[Month 12 Year 2005)];
    
      THIS = ([Scenario].[All Members].[Actual],
              [Time].[Monthly].CurrentMember.Lag(12));
    
    END SCOPE;
    
  • Consolidation rule or Currency rule with SCOPE operator

    Consolidation and currency rules use a SCOPE operator such as () instead of the This keyword. For example, the following code shows a snippet from the currency conversion rule that uses the SCOPE operator.

    SCOPE ([Account].ClassificationFilterInclude("Income statement"));
          () += AVE * CURRENTTUPLE;
    END SCOPE;
    
  • Assignment rule without This function

    An Assignment rule can also have a scope expression in source that is specified relative to destination or to the member set defined by the SCOPE statement.

    The following code uses this format to record the difference in current and prior exchange rates in a Flow dimension member, FXF. Note that [Flow].[All Members].[FXF] is a relative scope that is evaluated in the context of the earlier SCOPE statement.

    SCOPE [Flow].TypeFilterExclude("PY Adj", "Opening", "Appropriation", "Closing");
        [Flow].[All Members].[FXF] += CLO * CURRENTTUPLE; 
        [Flow].[All Members].[FXF] -= AVE * CURRENTTUPLE; 
    END SCOPE;
    

See Also

Concepts

Review methods for creating a rule
Best practices for writing rules
Using variables and parameters
Making a rule more general with #if - #else

Other Resources

Choose a rule type
Specify the implementation type