Do you hardcode values into business rules?

[lukasbartek]

I'm trying to break into the BRFplus space but I feel that my ABAP experience might steer me into a wrong implementation pattern.

We try not to hardcode any values when implementing a business logic in ABAP, rather we code something like a function and populate inputs of the function with transactional and configuration values, where the configuration values can come from standard or custom tables. The function then produce an output.

Would this approach also apply when a business rule (a function) is implemented with BRFplus? Should a rule hold hardcoded values like material or customer number?

I did some reading and found A Business Rules Engine should not replace Z-Tables… blog but Glen is addressing different point, BRFplus should not be used only as a container for rule data but it needs to contain a rule definition.

Does it make sense to use custom configuration table in a business rule? Is this a common scenario?

I would love to hear form anyone but would appreciate if tobias.trapp, carsten.ziegler, christian.lechner could share their experience.

Thanks for your feedback,
Lukas

[christianlechne · Accepted solution]

Hi Lukas,

you will have to have these "hardcoded" values in BRFplus as BRFplus comprises business configuration i.e. business rules. However, there are certainly some things you want to avoid:

• Hardcoding all over the place: If you have a fixed value that you want to use in BRFplus I would go for a constant expression to hold it and use the expression in the rules and expressions. This way you can give it a reasonable name and can change it in one place
• Mixing responsibilities: probably there are some values that you want to compare against that origin from customizing in your system. Do not try to duplicate the customizing in BRFplus but hand over the values from outside (as context parameters) or fetch them from the backend via a procedure call

Hope that helps

Best regards,

Christian

[lukasbartek · Accepted solution]

Hi Christian,

Thank you for your answer. May I have a follow up question?

Maintenance of config values with SM30 is quite straight forward and the activity is mostly carried out by functional folks and even by the business. The repository view in the BRF+ might be too complex or overwhelming as a entry point for the business users to maintain values and probably even for the functional consultants.

Is there a way to expose only a decision table to the business users for maintenance and shield them from all the other BRF+ artifacts? Something like assigning a t-code to a generated maintenance view?

I have found FDT_WD_START_CATALOG_BROWSER program. Is the right approach to assign a decision table to a catalog and then expose the catalog through the program to business users?

What is the best practice?

Best regards,
Lukas

[christianlechne · Accepted solution]

Hi Lukas,

yes, there is a way to adopt BRFplus so that the user can edit only the things that he is responsible for.

One thing is to group the objects into catalogs that can be designed in accordance with the roles that work with them. You can then assign custom transactions to allow the users to enter the right "area" of BRFplus (like catalogs) immediately and also connect them to custom authority checks.

See also: https://blogs.sap.com/2012/12/18/controlling-the-ui-appearance-of-the-brfplus-workbench/

Best regards

Christian

[pokrakam]

Do your values form part of the rule or part of the data?

I read "populate inputs of the function with transactional and configuration values", and don't agree with the second part. To me configuration is part of the rule, otherwise what's the point in using BRFplus?

There are of course exceptions. But in principle if it's business relevant and/or relevant for those maintaining the rule then it should be there.

[lukasbartek]

Thanks Mike for your comment!