Business Rule Classifications

OneStream provides classifications for business logic organization. At the core, all business logic is delivered and executed as compiled VB.Net or C# code. This means no matter what type of business logic is used, there is a consistency in the syntax and compilation process. The reason for different classifications has to do with when and how the business logic is invoked and how the business rule is scoped.

There are two broad business rule classifications: shared business rules and item specific business rules. Each engine in the system may support one or both business rule classifications. Whenever a processing sequence is executed in the platform, the particular engine(s) involved evaluates how and what business logic is associated with the process. This may include shared business rules (named and event handlers) as well as item specific business rules (member formulas, logical expressions, and confirmation rules).

NOTE: Shared business rules can be written in either VB.NET or C#, item specific business rules can be written in VB.NET only.

Finance Engine Example

During a consolidation process, a Named Business Rule is associated with the Cube being processed.  The Cube contains Member Formulas associated with some of its Dimensions.  In this case, the Finance Engine compiles both the Named Business Rule and each individual Member Formula in preparation for the calculation sequence.

Stage Engine Example

A similar example applies to the Stage Engine.  During a parse and transform Workflow process, a Named Business Rule is associated with the Data Source or Transformation Rules.  In addition, individual Data Source Dimensions or Transformation Rules have associated Logical Expressions that are also fired.  In this case, the Stage Engine compiles both Named Business Rules and each individual Logical Expression in preparation for execution during the parse and transform execution sequence.

Shared Business Rules

Shared Business Rules are reusable because the rule is written and stored centrally in the Business Rule Library.  This means the same rule can be called or referenced by multiple platform components.  For example, the Business Rule highlighted in the image below is a general Extensibility Rule.  This rule can be executed from the Business Rule Editor, called by a Data Management Job or called by another Business Rule.  Shared Business Rules are the code files seen in the tree when the OneStream Syntax Editor is open, they are organized by type, (see Business Rule Types in Chapter 4: Business Rules) and named by the user who created the rule.

Event Handler Business Rules

Event Handler Business Rules are a predefined set of Shared Business Rules and are always defined as an Extensibility Rule Type.  Event Handler Rules are invoked during a processing sequence by their related platform engine in order to supplement the process.  Determine/filter how/if the execution behaves for specific Workflows or the Cube POV.  When an Event Handler Business Rule is called, the calling engine supplies information about the executed process providing context about the process and information about the specific sub-event executed.

Predefined Event Handler Business Rules

The list below details the specific predefined Event Handlers available in the platform.  For details on the individual sub-events that fire for each Event Handler Business Rule, see Event Listing.

  • Data Management Event Handler

  • Data Quality Event Handler

  • Forms Event Handler

  • Journal Event Handler

  • Save Data Event Handler

  • Transformation Event Handler

  • Workflow Event Handler

  • Wcf Event Handler

Item Specific Business Rules

Item Specific Business Rules are complete rules like Shared Business Rules, however they are authored and stored with the specific platform item with which the rule is associated.  There are different reasons for using Item Specific Business Rules vs Shared Business Rules. 

For example, when creating a one-off rule without any reusable value to other components in the system, write an Item Specific Business Rule directly on the platform component because it requires a very specific piece of business logic.  Another example, which is more common when creating calculation logic for an analytic model, is to write a Member Formula that directly associates a calculation with a Dimension Member.  This creates system maintenance clarity and maintainability. 

Item Specific Rules, in particular Member Formulas, can have a positive performance impact because they allow calculations to be broken down into formula passes and processed in a parallel (multi-threaded) fashion.  The same formulas can be written in a Shared Finance Business Rule, but the calculations will always execute in the serial manner defined in the rule.

Item Specific vs Shared Code Structure

As mentioned above, an Item Specific Business Rule and a Shared Business Rule are identical in code structure.  When writing an Item Specific Business Rule, the code editor presents some hidden sections in the code window:

  • Formula Header

  • Formula Footer

  • Helper Function Header

  • Helper Function Footer

These hidden sections (i.e. Regions) keep the formula / expression as readable as possible.  In a Shared Business Rule, these sections are visible which make the rule more verbose.  The idea behind the Item Specific Business Rule is to create discrete code blocks that are easy to manage and have limited interdependencies.  If one knows how to write a Shared Business Rule, then she/he also knows how to write an Item Specific Business Rule and vice versa.

Item Specific Rules are categorized into three types: Member Formulas, Complex Expressions, and Confirmation Rues.  These relate to the platform engine with which they are associated.

Member Formulas

A Member Formula is assigned to a Dimension Member and executes within the Finance Engine during a Cube processing sequence (see the Formula Design Guide in the OneStream Design and Reference Guide for more information on processing sequences).  Member Formulas provide the same level of syntax and logic capability that exist when writing a Finance Shared Business Rule, however custom consolidation, elimination, and translation logic cannot be written. Member Formulas are a great choice for writing logic limited to calculations based on a single Member and calculations that do not span Dimensions.  If Member Formulas are written with these constraints in mind, then the Dimension Member and its formula can be reused in different Cubes without having dependencies on other Dimensions.  This does not mean that a Member Formula cannot look at other Dimensions.  Referencing Dimension Members outside of the specific Dimension where the formula exists will limit the reusability of the Dimension, or require all referenced Dimensions be used together in any new Cube.

Member Formulas are written directly on a Dimension Member within the Dimension Library.  Navigate to the specific Member’s Formula property and click the ellipsis in order to store a Member Formula.   The example below is a simple working capital Member Formula.

Complex Expressions

A Complex Expression is a Business Rule assigned to Data Source Dimensions, Derivative Rules, and Transformation Rules and execute within the Stage Engine during a transformation processing sequence.  Complex Expressions provide the same level of syntax and logic capability that exist when writing a Stage Shared Business Rule.  The primary reason for using a Complex Expression rather than a Stage Shared Business Rule is the logic being written has no reusability.  Complex Expressions isolate the logic by associating it directly with a specific item.

Using Complex Expressions in a Data Source

Apply Complex Expressions to a Data Source Dimension by selecting the Dimension requiring custom logic and setting the Logical Operator.  The Logical Operator property opens the Logical Expression Editor dialog and allows the user to either select a Shared Parser Business Rule or write a Complex Expression.  Both Shared Parser Business Rules and Parser Complex Expressions result in the exact same compiled Business Rule code.  The exception is a Complex Expression is only executed for the Dimension to which it is applied and a Shared Parser Rule is shared and can be called by many Dimensions.

Using Complex Expressions in a Derivative Rule

Apply Complex Expressions to a Derivative Rule by selecting the individual Derivative Rule requiring custom logic and setting the Logical Operator.  Clicking the Edit Rule Formulas toolbar button opens the Logical Expression Editor dialog and allows the user to either select a Shared Derivative Business Rule, write a Complex Expression, or use a Pre-Built Expression.  Both Shared Derivative Business Rules and Derivative Complex Expressions result in the exact same compiled Business Rule code.  The exception is a Complex Expression is only executed for the rule to which it is applied and a Shared Derivative Rule is shared and can be called by many rules.

Using Complex Expressions in a Conditional Transformation Rule

Apply Complex Expressions to a Transformation Rule by selecting the individual Transformation Rule requiring conditional logic and setting the Logical Operator. Clicking the Edit Rule Formulas toolbar button opens the Logical Expression Editor dialog and allows the user to either select a Shared Conditional Business Rule or write a Complex Expression.  Both Shared Conditional Business Rules and Conditional Complex Expressions result in the exact same compiled Business Rule code.  The exception is a Complex Expression is only executed for the rule to which it is applied and a Shared Conditional Rule is shared and can be called by many rules. 

NOTE: Shared Conditional Business Rules and Complex Expressions cannot be applied to One-To-One Transformation Rule Types.  One-To-One Transformation Rules are executed during the parsing process and therefore are completely processed prior to the conditional mapping process.

Confirmation Rules

Confirmation Rules are called by the Data Quality Engine and Finance Engine.  Apply Complex Expressions to Confirmation Rules by selecting the individual Confirmation Rule and clicking the Edit Rule Formulas toolbar button.  This button opens the Rule Editor dialog and allows the user to write a Complex Expression containing the Confirmation Rule logic.  A Confirmation Rule is only written on the specific rule to which it applies.  Confirmation rules do not have an equivalent Shared Business Rule because each Confirmation Rule requires specific logic.

TIP: Shared Finance Business Rules can be called from a Confirmation Rule.  Create standard helper functions in a Shared Finance Business Rule and call them from a specific Confirmation Rule creating some reusable logic and improving the overall Confirmation Rule infrastructure maintenance (see Business Rule Organization and Referencing in Business Rules).