Skip to Content

Best Practices for customizable Business Rules?

In a recent project, I finally had the opportunity to try out BRF+. With the help of several articles and on-line tutorials, I was able to create an application with a function and several other objects, generate the template code and integrate it into the remaining ABAP application. So far so good.

What I want to achieve next is a better separation of the rule set from the application. At the moment, the application code contains a hard-coded UUID that refers to the BRF+ function (and actually a second UUID for the import data object). This is OK as long as that application and the BRF+ function are always used in that combination. When delivering the application to another system landscape or another customer, this might not be we need: The other customer will have different business rules. At the moment, the only way to implement these rules would be to modify "our" BRF+ application, which is undesirable (especially since with every subsequent transport, there's a risk of overwriting the BRF+ objects again).

What is the recommended way to approach this? At the moment, all I can think of is some kind of customizing table that lets the customer specify another BRF+ application. However, this raises another set of questions: Can I somehow specify function names instead of (rather cumbersome) UUIDs? What do I do about the data object UUIDs? How do I ensure that the customers function has the same signature (input and output structure) so that I don't have to worry about runtime compatibility? Somehow I think that there should be something more sophisticated than a simple customizing table, but I don't know what to look for, exactly...

Thanks

  Volker Wegert

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Best Answer
    Oct 27, 2015 at 04:14 PM

    Hi Volker,

    in general you can split your application into several ones and use the visibility of the applications (and the data objects stored in there). This way you can define one (typically S-) application that is globally visible,  where you just define the function and its signature. Another application can be created that contains the data obejcts (also globally visible - like a reuse package for gloabl data elements)

    Concerning the call/delegation itself:

    You can use a BRFplus decision table to define based on some input parameters which function to call. SO you have one facade-like BRFplus function that reads the decision table and determines the function to call. It finally delegates to the desired fuction using the function call expression. I would stick to the UUID of the function as it is the only unique value. Otherwise you run into trouble with non-unique names. The search dialog should allow you to search for the name instead of the UUID.

    Concnerning the check of the signature. You can use an application exit in the application taht contains the facade function and the decision table. Within the exit you can check when storing/activating the decision table if the signature of the function stored in the decision table fits your needs using the BRFplus API.

    What I do not get is the point with the UUID of the data objct of the signature. What do ou mean by that as it is not needed when calling the BRFplus application

    BR

    Christian

    Add comment
    10|10000 characters needed characters exceeded

    • Hi Volker,

      usually it possible to  switch from functional mode to event mode (the other way round is not a that good idea). Nevertheless try it first with a "non-productive" function to test if everything works out fine (sometimes there are surprises e. g. due to missing notes). So this problem should be solvable

      BR

      Christian

      P.S. The book describes the different modes in the second chapter