Difference between BRF+ application usage and a FM / class method

[Former Member]

Hello all,

I had been going through the BRF+ framework and developed few test examples. But i am still not sure what is the need to have a special tool with graphic interface if same thing can be done in a FM / class method?

I thought of following points and hence asked this question on the forum to get the better understanding of the BRF+

1. Same rules can be written using ABAP in FM/class method

2. Both BRF+ app and FM/Class method can be reused in the development

3. Both BRF+ and FM/class method can be called from an external Non SAP-systems

So what is the benefit of using BRF+ over FM/class method apart from saving IF ELSE and coding lines ?

Appreciate your responses.

BR

Nilesh Puranik

[Former Member]

One instant thing that springs to mind when considering a rules engine in an enterprise is who do you think wants to own, maintain and be able to change the rules in the system?  The clue is in the name of both BRF+ and BRM (the Java stack equivalent) - where B stands for Business.

In your suggestion, if you create a BRF+ or BRM rule for say "CREDIT_CHECK_NEW_CUSTOMER" you can define it to have various ways of determining if a user will pass the credit check.  It might be a simple comparison of the user's credit history with an absolute threshold value (it could of course be much more complex.)

In your function module alternative, you build the logic to compare the two values and return a boolean.  Great.  What happens when the threshold value changes?  A code change and transport?  Maybe an update is needed to a table somewhere?  If you have lots of rules, that's a lot of tables and maintenance transactions to maintain, support and develop.  Suddenly, you are in to the realms of development of your SAP system, which isn't something that typical business users will be interested in or want to take responsibility for.  However, the BRF+ or BRM options give the business users all of the power and control they need to make changes such as this, directly in their productive environments (albeit in a controlled manner) and in a standardised and familiar environment.

Ok, you could argue that you could replicate lots of the functionality with good old fashioned programs, database objects and some form of objects/classes to interact.  The problem with that approach is the effort to create and maintain all of the required tools and framework to support more than 1 rule.  What you are doing then is building a rules engine...  Guess what, that's what SAP have done with BRF+ an BRM

Cheers,

G.

[Former Member]

Only coders are comfortable writing code.

We prefer keyboard shortcuts over mouse actions.

We prefer looking at table entry in SE16N instead of going through steps/tabs in relevant transaction.

Almost everybody else prefers GUI based approach. This is the advantage of BRF+. It lets functional consultants and business owners tweak rules without involving coder.

We debug code with test data. Debugging is very technical in nature.

BRF+ counterpart is "simulate", which shows how rules are processed step by step to reach certain outcome.

BRF+ runs in browser, that also adds to comfort level.