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!

To report this post you need to login first.

3 Comments

You must be Logged on to comment or reply to a post.

  1. Jocelyn Dart

    Hi Tobias,

    Some interesting thoughts.  On the whole I agree, using the inline rules is often less confusing than attempting to create independent reusable rules – most of which will never be reused.  After all its easy enough to come back later and add a rule, and replace your inline rule with a call to an independent named rule afterwards. 

    I find it can be helpful sometimes though to have named rules for visibility purposes, not just reuse. Occasionally the rule has a specific business meaning and importance to the business and it can then be worth raising it to the level of an independent rule so that the business can view it explicitly. 

    That would be the exceptional case, of course, but perhaps worth noting that reuse is perhaps not the only reason for named rules.

    Still that said – I’m with you … much easier to work top down for a number of reasons, avoiding creating unnecessary rule objects is just one.

    Rgds,

    Jocelyn

    (0) 
    1. Tobias Trapp Post author

      Hi Jocelyn,

      yes, visibility is a good and important point. It is interesting that isolation and visibility are contradictory. What do you think about “private named objects”?

      Best Regards,
      Tobias

      (0) 
      1. Jocelyn Dart

        Hmmmm… wouldn’t that be against the principles of  a business rules engine though? And delving back into hiding things away from the business?  Provided we set up a catalog that should be the business entry point, and we can tailor what goes in there, so not sure we need private naming as well?

        (0) 

Leave a Reply