With the advent of SAP HANA, more and more calculation & application logic are pushed to the database layer for faster results by leveraging the power of the multi-core CPU’s. But during such a calculation, when an application wants to make an operational decision, either the control has to come back to the application layer to execute the rules (BRFplus, NW BRM, etc.) or the rules are codified as SQL scripts/procedures by the experts.
In the first case, the turnaround times and the ETL process (of transferring the data to and from the rule engine) consumes quite a bit of time, and hence your HANA-based application might not respond to your action in the sub-second time that you might expect, which is more evident with a large data set.
In the second case, there is no problem with the turnaround time, but the rules cannot be defined by someone who doesn’t know SQL, say a business user. So there will be latency in setting up the rules and hence less agile and high cost for change. So, there is a pressing need for a rule engine that sits natively inside SAP HANA.
The Decision Tables are now available in SAP HANA SP05 and above (Whats new with SAP HANA SP05 by Daniel Wroblewski) and with that, a non-technical user can define or codify operational decisions & rules in simple language that they understand which can be transformed into SQL procedures in SAP HANA.
The decision tables lets you to model rules based on data that comes from different SAP HANA artifacts like one or more HANA tables, Modeler views (like attribute view, calculation view), HANA Table Types and the determined decisions could either be updated in the underlying tables or it could also be sent back to the calling application. For more information on how to create decision tables in SP05, refer to this PDF document (Chapter 12).
All that said, in this blog I would like to talk about what can be done with the decision tables.
If you had read the above pdf document, you should be aware that on activating a decision table the rules that you have defined are translated into SQL procedure which any application can call. Also, for those decision tables that do not update the data set, a column view is also generated. When you have rules codified as procedure & column view you can do lots of magics 😉
1. Apply operational business rules – Pricing rules, Credit decisions, Credit score rules, Claims, Fraud detection, Data cleansing rules, ETL rules, and the list is endless and i wont explain this in too much detail since this is the very basic need for any decision table.
3. Consume in other procedures. Since the decision tables generate SQL procedure, you can consume it from other HANA SQL procedures.
2. Consume in a calculation view. Add the column view generated by the decision table to the calculation view and add your logic on top that. Change the rules, activate, and refresh the calculation view to simulate how the rules change your result (and then adapt to the optimal rule).
Example: This can be used to simulate or foresee how your discount rule will alter your profit and margin.
3. Consume in HANA Analytics and get the best possible decision, determine patterns and trends.
4. You can develop a mobile app that consumes the procedure generated by the decision table (using jersey client or HANA XS). For example, claims officer at the customer location can check if the claim is readily approved or does it need further investigation based on the rules that checks for regularity/irregularity in historical records of the person claiming insurance.
The Decision Table that is available SAP HANA can be used not only to apply your operational rules in the ‘traditional’ way (to increase agility as well as automation of business rules), but you can also create other HANA artifacts (like a calculation view) or a mobile application that consumes your rules to explore, simulate and adapt your rules.
Happy ‘ruling’!! 🙂