13.5    Best Practices for Modeling Business Rules

When modeling and developing business rules in SAP BRM, you should always design those rules while applying best practices and design principles. By doing so, you’ll become aware of various aspects that may positively or negatively impact the overall quality of your business rules.

In this section, we’ll share some practical tips that have been proven to improve the quality of the rules and to mitigate other general risks, such as poor performance and difficult-to-maintain rules. However, before we look into that, we’ll share a couple of good sources of information about business rules on the Internet—namely, www.businessrulesgroup.org and, of course, the SAP Community, which has its own page dedicated to SAP PO including business rule topics (https://www.sap.com/community/topic/process-orchestration.html). There, you’ll find an entire collection of blogs, how-to documents, and lots of forum topics discussing SAP BRM.

13.5.1    Separate Decision Logic from Other Types of Logic

When implementing business rules with SAP BRM, you should always apply an important design principle: isolate decision logic (in SAP BRM) from integration logic (in SAP Process Integration [SAP PI]/AEX) and application logic (in SAP and non-SAP backend systems). Use SAP BRM to support decision-making logic and nothing else. Don’t confuse the true power of business rules with other types of logic, such as executing transformations, and calling web services/external systems, or modeling an entire process flow in a flow ruleset. You should use the right tool depending on the type of logic (i.e., SAP BPM to orchestrate and call external services via the AEX). If you fail to do so, you’ll end up introducing maintenance and performance problems in your business rules.

Tip

Here are some additional guidelines for you to consider when designing and before you start implementing your business rules.

• Use SAP BRM exclusively to support decision making.
• Think and decide which fields and (XML/Java) data types you’ll need to support the context of your business rule.
• Send only input data required to execute the business rule. The output of the rule will be updated with the results of the rule execution.

13.5.2    Reuse and Extend before Building

Before you start implementing new rules, first analyze the existing rulesets, and then choose wisely which ones you could reuse or extend before you create new rules. The following specifies when to use a rule, decision table, or rule script:

• Ruleset:
  • Execute based on the Rete algorithm, and give preference whenever possible as its footprint tends to be lower than a flow ruleset. The SAP BRM engine takes control of execution in automatic pilot mode.
  • Support execution and dynamic execution of one or more decision tables under the same ruleset.
• Rule:
  • Use for straightforward, not too complex conditions and actions.
  • Limit to a two-level condition check.
  • Create rules with common conditions, and reuse them if possible across the ruleset.
  • Reuse conditions by using the precondition feature.
  • Keep in mind that a rule when compared with other rule objects (e.g., decision table) can be less user-friendly to maintain for non-IT users.
• Flow ruleset:
  • Strongly consider introducing a flow ruleset when your business rules contain different logical steps (validate, filter values, etc.) and combine multiple rule objects such as rules, decision tables, rule scripts, and rule flows.
  • Try not to overpopulate your flow ruleset with too complex rule flows and large amounts (more than 20x rule objects) of different rule objects inside the same flow ruleset.
• Decision table:
  • Use if (similar) conditions for business rules already exist in tabular form, especially with a greenfield SAP BRM implementation.
  • Give preference if non-IT stakeholders are highly involved in the periodic maintenance of data in the decision table.
  • Size does matter is the message here; split decision tables into logically related smaller decision tables if they become too big in terms of number of conditions or actions.
  • Keep decision tables to fewer than 20,000 rows and 100,000 cells. Avoid going above that threshold; otherwise, you’ll enable potential performance issues.
  • Define aliases where possible for better understanding by non-IT folks.
• Rule script:
  • Apply for multilevel (nested), more complex conditions.
  • Use when you need to loop through a list of objects in Java or a collection of elements in XML.
  • Avoid using it when non-IT users are involved with the maintenance of business rules, as rule scripts tend to be harder to understand than other type of rules.