Skip to Content
Author's profile photo Former Member

Be careful when using BRFplus to take actions

In my previous Business rules on a full stomach I said

“Implement these as decision services that use rules to make a decision but which do not have side effects – that don’t change the data. This will make them easier to implement and easier to reuse while focusing on those areas where rules makes the most  difference.”

In response to this I got an interesting Business rules on a full stomach:

Does this make sense with BRFplus?  One of the big features of BRFplus is connecting actions directly to the outcome of rules.  IE: Data updates in forms, emails, workflow etc. It sounds like from your above comment though that actions such as this should be implemented independent of the rules though.

When I saw BRFplus – rules and ABAP, and spoke with Carsten Ziegler this was one of the things I had to think about. While I understand the desire to put the ability to take action into BRFplus rules – this is common to all business rules management systems, by the way – I still don’t like it.

The problem, as I say above, is that this means the Decision Service cannot be called unless you are willing to tolerate the side effets of doing so. If, for instance, a Decision Service implemented in BRFplus to determine the eligibility of a customer for a particular product updates the customer profile then you can only check the eligibility when you are processing an application – you cannot expose the functionality as part of a customer inquiry environment or to help a call center representative answer questions. In general therefore I stick to my principle – Don’t use BRFplus or any business rules management system to take actions when you are using it to make decisions.

Does this mean that there is no value to this ability of BRFplus? No – the ability to take actions can be used to update intermediate results, to log decision making for future analysis, to record how often and in what context the question is being asked and so on. It just should not be used to do things that matter to the business – it should not change the state of the business when used to implement a decision service.

Now you could use BRFplus to implement the logic that takes actions if you wanted to – you could use BRFplus as a declarative programming language. And this would be fine as long as you separated out and called the decision itself as a separate function. This separation of concerns – decision making separate from other aspects of the application – is what is critical.

Business rules and BRFplus can be used for many things. When you use them to implement Decision Services, don’t use the action functionality to change the state of the business because you will regret it.

Assigned Tags

      1 Comment
      You must be Logged on to comment or reply to a post.
      Author's profile photo Carsten Ziegler
      Carsten Ziegler
      Hi James,

      I agree to your statements. When introducing the feature of actions there was a big discussion between the architects responsible for use cases with BRFplus. As a consequence we will make configurable what actions or if atall actions can be used in a specific scenario.

      There are some scnerios where BRFplus is rather used as a "Nth generation language" and not as a business rules engine. Then, actions can make perfectly sense. But you would clearly not call this a decision service.