Rules in BRFplus – Naming and Isolation

[ttrapp]

The concept of named vs. unnamed objects objects seems to be the most confusing one in ABAP programming. Unlike in other programming languages so far ABAP knows only named objects: development objects are defined by the object catalog (TADIR entry). And development objects without representation in the object catalog like local classes have a name, too. But in BRFplus there is the concept of unnamed objects that can only used locally but can’t be reused.

What is the reasons nor naming objects? When you create rule systems bottom up, most objects will have names. At first you create expressions, then you use them in rules and there are used in rule sets. If you create rule systems top-down then it is likely that you create BRFplus artifacts on thy fly and often without names. Since this can lead to a refactoring process sometimes it can be easier when you work with named objects. So the design methodology can propose certain best practices. But are there other aspects to consider?

When BRFplus applications contain many objects they become complex and vulnerable to side effects of changes and this is what my blog is about.

What about naming Rules?

Functions and rule sets are named BRFplus artifacts - but what about rules? Rules can exist either locally (and so unnamed) within a rule set or can be reusable and so have a name. My experience is the following:

• In general rules have little potential for reuse. So there’s no real need to name them. Moreover reuse can be harmful because of unwanted side effects. So if you want to prevent side effects you should avoid naming rules.
• Nevertheless, rules and expressions can be qualified for reuse due to subject-related reasons. In this case they should of course have names. If you want encourage people to build their rule sets bottom up from existing rules and to use rules as templates for modification after copying you should name them to make this process easier.

Should a Rule use only named Content (= Expressions and Rules) internally?

In general I don’t think so although I mentioned an exception in the last sentence: if there are rules and expressions as part of a reuse library they shouldbe used in the rule. But in general I don’t consider this as useful and isolation of rules is the better choice since rules should be save from unwanted changes in other parts of the BRFplus application.

A rule is a very complex object: a rule consists of a condition, a true-action and a false-action. A condition is TODO. A true- resp. false-action is a set of

• BRFplus actions
• assignment of context objects
• assignment of values
• executions of expression
• nested rules
• expression assignments and assignment of results

The complexity of a rule is hidden behind a very sophisticated UI – and the UI hides the ID of the condition, the true- and false-actions.

So my advice is: try to work with unnamed objects. Only if there are already artifacts where reuse makes sense, use them in rules. But using many names object to build up a rule can make a BRFplus application very complex and you have to consider side effects when doing changes. I made the experience that “spaghetti” BRFplus applications are hard to understand and to change.

I made the experience that a little bit redundancy can simplify changes because you can change rules independently.

Simplify your Life!

Reuse and isolation are two contradictory paradigms and both can be used to simplify a BRFplus application. If central objects like expressions and perhaps in rare occasions even rules are named you can reuse. If they provide reasonable calculations having a precise meaning then reuse can lead to simplification. In other cases naming objects could lead to unmotivated reuse and nasty side-effects when changing the BRFplus application. Give unnamed rules a chance!