Skip to Content

A Dicey Situation – Central or Local Instance of BRFplus

Recently, I came across a scenario where I have to a take a decision on whether to go for a central instance or a local instance of BRFplus.

All the views provided here are my personal opinions and based out of my experience with BRF and do not necessarily reflect my employer’s. Please treat the inputs in this blog as just opinions and you should definitely seek professional expertise and opinion before making your business decisions.

Aim is to centralize all business decisions within a single repository and to build a central instance for BRFplus and tightly integrate BRM with third party systems including SAP and non-SAP systems.

Central instance has its own advantages from an organizational and support perspective and also few disadvantages like
• Replication of data dictionary objects like Data elements, structures and table types in both ERP/CRM and in BRFplus system, if they have to be used in business rules
• Performance and response times might impact due to the usage of slow RFC calls with a central instance
• Since, data has to fetched outside of the context, some expressions types may not work
• To enable RFC, local functions should be wrapped, as communication with external systems to access information is possible only by RFC-enabled function module

Some other pros and cons which I thought about central and local approaches are:

Local instance
• having a BRFplus local instance for SAP systems and a main instance for third party systems 
• Performance would be better and total control of all native BRFplus expression
• WebServices can be used to trigger business rules execution, when a Non- SAP system has to call the main BRFplus instance

Central instance
• having a central instance for all SAP and Non-SAP systems
• to reduce the amount of additional data selections during processing, care should be to taken to design the signatures of all BRFplus functions (context and result).
• All updates should occur outside of the business rules engine and return a result of execution signatures of all BRFplus functions (context and result)
• When calling RFC’s across systems, care should be taken to minimize the performance loss by reducing the usage of these calls.

I felt in this scenario with multiple third party systems along with SAP systems in the landscape, using BRFplus local instance would increase performance and can effectively leverage all the features to meet the customer goals.

I am wondering how different the approach would be, if we have to design this for a new implementation.

1 Comment
You must be Logged on to comment or reply to a post.
  • It depends on the landscape and scope of usage.

    If your rules are tied 1:1 with SAP systems, then why not use a local instance of BRFplus on each system?

    If the rules are for use in non-SAP systems and SAP systems, then a blended approach might make more sense for performance reasons.  Of course, if most calling systems are non-SAP then central makes more sense.

    Whichever approach you take, you still need to make careful design decisions.  Just because you have a local instance doesn’t mean that expressions like DB Lookup and Procedure Call can’t slow you down.  Just like in programming, the rule author needs to design rules to perform in the landscape optimally. 

    With a central approach, this design would be more around the signature and scope of the functions you’re building since it will be slower to fetch additional data once you start processing, and each call over RFC will take a performance toll.