BRFplus in Big Data scenarios
Hello SCN-Community,
this is my first blog here in SCN. May I introduce myself first. I’m Daniel Ridder and I‘m at AOK Systems GmbH, Germany and project manager and lead architect in SAP development projects. In the last time my focus was on business rule management, development of HANA-ready solutions and operational analytics in context of Big Data scenarios.
In this blog I want to give you a brief look into work and experiences I made. In hope you are not getting bored I would split this blog into a few more articles. I guess the following structure would be fine:
- Introduction – What is it all about? – „A brief intro to our business we have to deal with“
- Rulesets for calculating prices in context of Big Data Scenarios – „BRFplus and our suggestions about working with big decision tables and usage of paralllelism techniques to deal with a huge amount of data“
This article deals with both topics. Further topics would be:
- Explorative search techniques to determine anomalies in invoices – how could we support the end user during his daily work?
- Operative analytics with BW in ERP
But first things first – hope being able to handle it… 🙂
Introduction – What is it all about?
The Project deals with the processing of medical invoices (ambulatory medical and dental care). Such collective invoices are being sent quarterly from the present medical association to each single statutory health insurance. Each invoice is supported by additional information about diagnostic data and medical procedures especially surgeries.
A single data delivery contains about approximately 7.000.000 invoices supported by an average 120.000.000 medical treatment. Due to that an invoice and it’s provided documentations is modeled by an 1:n relationship. Over a year an average health insurance Company deals with 28.000.000 invoices and 480.000.000 medical procedures. This huge amount of data has to be inspected and billing errors have to be detected. Additionally the billing amount of each invoice has to be calculated by the system. To determine a billing error you have to concatenate more than five billing quarters (needed to prove about overlapped bills of an insured person). For now you could imagine what the runtime is going to take.
Rulesets for calculating prices in context of Big Data scenarios
After this brief introduction and in face of the described amount of data to process we may talk about Big Data I presume.
One goal is to calculate the amount of each invoice. To do this we’ll have determine the price for every medical service. It sounds easy but we‘ll have to do it in each quarter collection for about 120.000.000 medical procedures. After that we could sum the prices and define the cost of an invoice.
The calculation of a price is not being done by a simple look up in a price list. The price of a medical service is defined by a regional contract of billing which is dealt between the health insurance and the present medical association. If a single service not provided in such a contract a general standard contract has to be taken.
So let me summarize our requirements: We have a huge set of medical data that has to be checked according standard and individual contracts that include billing rules. The management of these rules have to be transparent, flexible and operations using those rules have to be scalable and high-performing.
On our first try we chose the BRFplus – and it turned out to be the right decision 😉
With this article I want to share our experience and solutions to the problems we were faced with. In advance I want to thank Carsten Ziegler, Wolfgang Schaper and Tobias Trapp for the provided support.
Regionally billing contracts and raised problems by dealing with them
Slightly simplified, a billing contract is represented by a logical concatenation of expressions – by AND connected. This construction is perfectly represented by the use of a decision table.
Unfortunately a few problems raised at this point:
The whole billing contract for a quarter year contains about 37.000 rules if all 17 medical associations were included. So we were faced with the following problems:
- Decision tables of such a size are able to get handles by the BRFplus. But we determined the BRFplus Workbench is no longer the right tool to maintain these rules. We recognized noticeable latencies while browsing in the decision table and during the modification of a single row.
During rule execution the generated code of a decision table the rows consecutively passed line by line from top to bottom. So it can the order of rows becomes important, otherwise two problems will occur:
- If the current invoice being processed is subject to the rules of the 17th of 17 medical associations we have to validate about 34.000 rows before we reach the correct section of a decion table.
- If the order of the rows in the decision table is arbitrary, it is possible that a rule for a high frequently supported medical service will be found in the middle or even worse, at the bottom of the decision table which leads to bad processing times.
- And last but not least we mentioned an improvement in growth about the loadsize of the generated ABAP class of the BRFplus function. On a yearly basis we’ll expect a loadsize about 85MB.
Our chosen solutions
We could solve topic 2 with numerous attempts of creating a suitable maintenance of the decision table. In view of the end user it would be better to separate the quarterly contracts of billing for each medical association. So we provide for each quarter and medical association a single decision table which we could trigger by a gate expression in the corresponding ruleset. All other rules are not be validated in this case.
With this approach we could solve topic 1 by providing a new frontend for maintenance of rules. Additionally the power user is still able to use the workbench i.e. to redefine or modify the whole ruleset.
Please remark that is approach is quite usual in the BRFplus/DSM world. Since the framework contains an API it is easy to provide a alternative frontend for maintenance of rules. Moreover this you can implement additional checks and integration with other dialogs.
We solved topic 3 by analyzing the underlying data automatically and rearranging the rules. By creating an internal hit list (provided by a SQL aggregation) about the count of each medical service in the invoice collection we were able to sort the billing contracts in die ALV grid and generate the decision table in BRFplus in an optimized way.
The topic left over was the issue with the load size of the generated BRFplus class. By providing four decision tables in one ruleset we examined a load size of the generated ABAB class by approximately 5MB.
If we extrapolate this for a whole year and for all medical associations we would expect a load size round about 85 MB (5 MB x17 medical associations).
Currently the BRFplus does not provide some aesthetically convincing mechanisms to deal with it. We mentioned the separation of each decision table in a separate function which has to be set in function mode. As a result we modularize the rule system into different functions. To call the right one another BRFplus function has to be created. This function evaluates the medical association and billing quarter to choose the right function to call.
Another very nice solution to face the problem would be a function which evaluates a decision table. The decision table contains in its single result column the ability to call another function and to return a whole structure not just a single value (mention the following screenshot). Unfortunately this is currently not an option in BRFplus.
How to parallelize the calculation of Prices
The calculation of prices was settled by a single processing paradigm. The function context in BRFplus was defined by a single invoice. Our tests showed a negative performance impact when fetching data into BRFplus. Even building a function context with more than one invoice showed a negative impact. Since we are convinced the examined system behavior is related to our own special use case we would not generalise for other use cases.
For parallelizing the workload we chose the FPP in ABAP package BANK_PP_JOBCTRL. With this framework we are able to easily wide spread the workload onto several server groups. I think you could find great articles about FPP here in SCN so there is no need to deal with it in this blog.
OSS-Notes
Thanks to the support of Carsten Ziegler the following oss notes are recommended to observe if you want to deal with big decision tables or facing with performance issues:
1930741: Performance Improvements in the BRFplus Design Time
1936926: Runtime improvements for decision tables
1940360: Changes to the Application Server Buffering for BRFplus Meta Data Tables
1938697: BRFplus: Remove unnecessary data conversion
1901192: Syntax error in generated code for decision table
1980560: Performance Improvement for Table Operation Expression
And we implemented 2022076 (Issues in using reserved namespaces starting with /) to prevent that the rule execution gets into interpretation mode.
Summary
Decision tables are one of the most useful expressions in small and large scale use cases. In large use cases you can use them to code complex rules that are parts of insurance contracts. When you use them for huge decision tables don’t forget to optimize the order of decision tables and think about splitting huge rule systems into different functions since the work load of a single ABAP class is limited.
Moreover, search the OSS for notes that optimize DSM/BRFplus performance. And last but not least: use the API of BRFplus/DSM build a pleasing UI for the user who maintenance the rule system.
I hope this first article give you an impression about what we are currently working on and you got some inspiration to work with the BRFplus/DSM especially with decision tables.
Hi Daniel,
Lots to digest here, and cool that you blogged your real live scenario and experiences!
Welcome to SCN, and looking forward to your next posts. An endorsement from Tobias Trapp counts!
Cheers, Fred
Welcome to SCN, Daniel
I agree with Fred, an endorsement from Tobias Trapp really counts here.
This is a great first blog.
I honestly didn't think of BRFPlus with big data scenarios, but you describe an excellent use case for it.
I am looking forward to reading more contributions from you.
Tammy
Hi Tammy,
I am surprised that you never thought about usage of BRFplus in those situations. In fact the use case Daniel describes is at use case at the borderline between analytical and operational scenarios. Usage of BRFplus/DSM in operational scenarios is a best practice but it is also useful in analytical processes. The reason is simple: SAP BW is good for simple calculations like aggregations but for complex calculations or conditions (especially in transformations) BRFplus is the better choice. I know many scenarios where people developed their own “rules framework” but I think using SAP standard is better.
One might question whether it is a Big Data scenario. I think the data volume is extremely high since there are multiple data sets per year and some business cases need historical data. Moreover statutory health insurance companies in Germany are merging so that the data volume increases more and more.
There might be the case that DSM expressions for HANA are the better choice. And yes: HANA has decision tables and those can be created automatically from DSM decision tables and work on a database view. There are many use cases for this like customer segmentation or simulation of changes of business rules.
So BRFplus/DSM has potential to scale in many dimensions: it can work with huge rule systems and work with at large scale and not only for occasional checks. This was one topic of my talk at SAP Inside Track Hamburg end of last month. Maybe I should blog about it?
Cheers,
Tobias
Yes, Tobias, a blog would be great. Or maybe you can do a Mentor Monday webcast?
A Mentor Monday webinar about BRFplus/DSM would be fine. But I think we should start with a simple beginner scenario. The goal should be that ABAP programmers start to learn that BRFplus/DSM is nothing that requires much training. I think it is a technology that every developer can apply after a short time and that can reduce TCO and TDO of an SAP solution.
This blog entry is quite advanced since it discusses usage of BRFplus/DSM at large scale: rule as part of insurance contracts as well as performance of huge decision tables. But most developers will use it for much simpler use cases: reduction of custom code and customizing as making different rules more explicit (and so a business solution easier to maintain and to change). And this is we should focus on Mentor Monday in ma opinion.
Cheers,
Tobias
Well,
after sharing my practical experiences it seems to be time for enterprise architecture.
Cheers,
Daniel
Thank you very much for your friendly welcome!
I'm pleased that the blog yields such a nice feedback.
Well, with a SAP Mentor as a colleague I can build on very good support. What I haven't focused on in this blog, is a complex scenario of replicating these calculation rules from a master ERP into several dependent ERP systems. I hope to eliminate this complexity by the use of DSM. But currently we have to deal with it.
Best regards
Daniel
Well, I think support is the wrong word – maybe encouragement is better. I think it is necessary that we discuss practical examples from business to learn from each other. And I think is absolutely possible without violating business secrets.
Unfortunately many companies are too paranoid since they consider everything which has to do with business rules as mission critical and top secret. This is really weird: So when I’m on my way to my office in Frankfurt sometimes other SAP experts are in the same train and some of them read my blogs and are asking me questions about BRFplus/DSM which I usually answer. But when I’m asking in which context they would like to apply this information I get the answer that they are not allowed to talk about it. Of course it is clear that they are can’t talk about any details of business rule but on the other hand it is no secret which SAP solutions are necessarily using BRFplus/DSM.
And yes, you are right – often management and deployment of complex rule sets is much more challenging than just the initial creation. So I would like to read to more about this topic – but you are right, this is topic for a separate, follow-up blog entry.
Cheers,
Tobias
Your statement about company information policies is very true.
There are very good examples how companies like Apple, BASF etc use DSM/BRFplus but it seems to be impossible to get them write or speak about it. Everyhting is mission critical. 😥
Therefore I am very happy about any blogging or talking like done by you guys.
Hi Daniel,
Thanks for sharing your experience.
As I cannot see much from the attached screenshot, I have two questions:
1. Was the hugh decision table really essential in your case? Did you make use of any of its advantages over standard maintenance table?
2. Why did you have to develop you own report for decision table maintenace? Couldn't you use the export/import from Excel options?
Regards,
Shai
Hello Shai,
I described the structure of such a regional contract. It is a repeating pattern where you
have to combine column for column as a logical cascade of expressions, i.e.: Combine expression A with B, C, D, and E. If all expressions match return a result structure of attributes. That’s what a decision tables is for, isn't it? You could replace a decision table by a ruleset within each rule replaces one row of the decision table but then you'll face with the following problems:
medical procedure for optimizing rules processing.
The maintenance of a decision table in Excel with the upload and download function
is a very nice feature. But as I explained the ui interaction – especially of big decision tables – is slow which cause by a significant delay in user action. With the report we are able to let the user maintain the rules in a standardized way (the average customer is known to work with SAP GUI in our scenarios) and do some performance optimization under the hood.
Cheers,
Daniel
Hi Daniel,
Thanks for the detailed response.
However, I would like to have some more technical details.
1. Regarding the decision table, my question was if you used any complex cell value, like value range or embedded BRFplus expression.
If it's not the case, you could have used standard DB lookup expression.
If it is, you probably had to develop a sophisticated maintenance table, similar to decision table UI. I'm not sure if it worth the effort/how is it different from the standard UI.
2. Regarding the Excel, as far as I know, you should be able to upload/download Excel files also via custom UI (using the API: Class CL_FDT_DT_EXCEL?) instead of the standard UI.
Regards,
Shai
Hallo Shai,
BRFplus is a framework where you do what ever you want. As like any framework you have the right to chose it or write it on your own. I understand your questions but the decision of using BRFplus or not is up to you.
Remember if you write such a framework on your own, you have to take care of the maintenance processes especially the you have to decide if your “rules table” contains master rules (not changeable) and custom rules. You have to think twice about your design. On the other hand a BRFplus decision table Expression is defined and filled in less than a few minutes.
To answer your questions (I hope for 🙂 ):
also use ranges in the cells. Please let me give you an advice: do not let your aspect of an “easy” designed decision table (where you only have some kind of simple value comparisons) decide whether to use BRFplus or not. The major problems you have to deal by building a rules framework are already addressed and solved. Even think about code generation which replaces an interpretation of rules (even in your own framework) with abap code or think about HANA expressions.
Cheers,
Daniel
Hi,
Thanks again for the info.
For the matter of fact, I don't wonder about the decision to use BRFplus, but about your need to implement your own maintenance/UI for it.
If it's just an issue of performance issues for hugh decision tables, I think that suitable solution should be provided by the official SAP BRFplus team (Performance tuning, "lean" decision table interface, external upload/export option or any other solution).
Regarding the "easy"/simple decision table, I just wondered if you actually developed the whole mechanism by yourself or relied on simple cell values.
Regards,
Shai
Well Shai,
I don't think the BRFplus team is responsible for an investigation in such a performance tuning. In fact BRFplus is fast. But in this special business case we have to rearrange the data by examine the frequency of a medical treatment. Due to the coding underneath our own UI we are able to reorder the table in other situations in the same way. Think of receiving a correction of the delivered data from a medical association.
Cheers,
Daniel
Daniel gave already a response but one aspect is perhaps hidden between the lines:
And this allows you to have even complex values of the input structure of the decision table since you can evaluate it using BRFplus formulas or even your own formulas.
And this can help you to expose complex rules systems in decision tables. The benefits are transparency, readability and scalability.
Regards,
Tobias
Hi,
I don't see how these expression columns extend any functionality, which isn't available in DB lookup, for example (via "With Condition").
Regards,
Shai
A formula can work on arbitrary data types sometimes using extremly fast features like REGEX expressions for example. Within a formula you can access DB or even a HANA using a secondary DB connection. A simple DB lookup is a completely different use case.
Regards,
Tobias
Hi,
I'm not sure I got the difference.
How BRFplus expression used in decision table column is evaluated differently from comparison check in Database lookup condition?
(I was talking specifically about Daniel's scenario, in which they have created custom maintenance table, of course)
Hello Shai,
the answer is very easy (isn‘t it 😆 ?)! You could not implement it with Open SQL.
One reason to that is you have to split the decision columns in different tables. And then think about customizing and transporting...
For example one expression column determines whether a special other medical treatment is also listed in this invoice. With a DB-Lookup you may get several rows which match your rule. So you have to implement a ranking.
But at this point I can’t tell you more about the implemented rules… Hope you will understand that.
Best regards
Daniel
Well,
I'm probably missing something.
Since I don't see the whole picture I'll have to rely on your conclusions.
Hello Shai,
I had to think twice. I can't give you more details about our implementation.
But I think you are on the right way because you are asking the right questions 😉
If you are in the same situation, you will analyze the problem and find a good
solution for it. That's for sure. Remember, there are always quite a few possible solutions...
Cheers
Daniel
Hi Daniel,
because of holiday a late feedback (I decided to give it inside SCN and not via company email).
Very well written blog, I like this kind of blogs about "Real World" requirements (in opposite to "Hello World" Tutorials).
While it is a really interesting use case for BRFPlus and decision tables, there always are multple solutions of a problem (see the discussion with Shai). The "intrusions" into the BRF internals that were necessary to get this running are manageable but must not be neglected in respect of later maintanance.
The most important goal of architecture is to build software robust against later change, so we have to anticipate and decide which changes are likely to come and which are not.
Your BRFPlus approach is best suited if we expect changes and enhancements in the business - pricing - rules. In this case it is worthwhile to tailor, enhance and customize the BRF Plus framework to this somehow unusual use case and to live with the possible trade-offs: possible changes in SAP's API and internal matters of the framework, efforts to build and test "workarounds" like reordering of decision tables and user interface, potential performance and support issues with SAP because of using a framework like BRF Plus in a rare and somehow exotic "pioneer" scenario. (And never forget: SAP may declare any framework to be "mature" some day 🙂 )
On the other hand, the most important rule for (your own) framework development is "Don't", so the BRF Plus approach seems promising and viable 🙂
Best regards
Rolf
Hi Rolf,
to give the answer on SCN too:
Well, you are right. SAP may declare a framework to be mature when ever they want. As we can see, more and more new features of the Business Suite are using the BRFplus internally so we do not expect it for BRFplus in the next time. On the other case time after time the declaration to be mature forces the software to go further. I think Darwin called it evolution. Without evolution in software development, we cannot calculate far beyond the dimension of a GameBoy.
Why use BRFplus in such a scenario? BRFplus produces ABAP-Coding. So the rules are not interpreted and we can choose such a framework to calculate on mass data.
Why BRFplus and not an own framework e.g. with a simple maintenance table?
The legacy application is used by only one customer. The rules do not change frequently. But this is a result of high costs, generated by such a change. The new application can be used by every customer we have. The current calculation rules are closed source and can not be used by other customers. Currently we have no picture about other calculation rules, so the customers must be able to develop their own rules. If we take a look at current statutory changes we must be able to react fast and flexible with our business rules.
And last but not least the BRFplus offers us some very important featues like versioning und simulation.
Hope this helps for understanding. I'll pay the next coffee 🙂
Cheers,
Daniel
Dear Daniel,
thanks for providing such a wonderful example and explain your architecture and motivation in such a detail!
Having had the time to read the whole blog including all the questions raised and answered in the meatime (thx also to Shai and Tobias), there is only one question remaining (majorly directed towards Carsten Ziegler:
If I got you right, you modularized the function per medical association in order to optimize the performance of the load generated. If you had different rulesets within the same function with different preconditions, these rulesets are actually indedependent from each other. So should not BRF+' load generation be able to generate separate classes for them?
Cheers,
Oliver
Hello Oliver,
you’re right. The DT upload-function is powerful and easy to use. But in this case we
had to implement some additional functionalities to satisfy the user.
First we have to convert the user input to a format which can be interpreted by the system. In some columns the input is representing an identifier of a medical treatment. This number has to be converted into an expression – eg. a range condition. Something like „contains string [input]“.
Another case is the re-arrangement of the rules. By sorting the rules before filling the DT we will get the best runtime performance.
Well, we see an ABAP load of 85 MB per year. I can’t tell you what will happen when the
software was in production for 4 years. So I care about the load size and split each quarter in a separate function.
Yes, the execution flow is defined by preconditions in the ruleset. For testing purposes
it gives us another benefit. We could easily export a single function with its dependencies and import it into a test system without transferring the whole application with all of its rules of other medical associations.
Cheers
Daniel