Now that we have began collecting vocabulary and identifying how terms relate to one another (see How to Blueprint Your BRFplus Project: Part 2) it's time to collect business rules.  To do this we will use the business goals and decisions to form the business processes, and subsequently harvest the business rules.  Please note that there is a lot more awesome stuff that is written about business motivation and business processes alone and that is not what I will be spending much time on.  Rather I will simply highlight how these things ultimately lead to business rules.

A Strategy for Understanding the Flow

In order to harvest our business rules we need to have a starting point, and the business goals from How to Scope Your BRFplus Project will serve as that starting point.  An example goal in could be to decrease manual workflow of student documentation by 80%.  Below is an example diagram modeling how we get from goals to processes.

We can see above that our tactic to achieve the goal of workflow reduction has an impact on the documentation workflow process.  That said, what exactly is the documentation workflow process?  Our decisions that we modeled during scoping will serve to describe the initial process as shown below.

As you can see above we have details at the decision level.  So from here the decisions must be sequenced into processes, which will become our inputs to harvest business rules.  The below is a simple example of taking the decisions above and creating a simple business process.

Separating the Flow from the Know

Some people in the world of SAP don't know the difference between a business process and a business rule.  To them everything is just blue screens powered by procedural ABAP code.  However in order to harvest business rules it is critical to understand that business processes and business rules are two different things.  As mentioned above, business rules are inherently declarative (no sequence), while processes are purely sequential.  One step in a business process could be to fire off one or more business rules.  Those rules however will fire off in no particular order.  If they do require order, then they should be represented separately in the process as process steps instead of as business rules.  Take the following example of determining required documents from the first step of our above process:

Since there is actually no sequence required for the steps above, this could be better represented as rules as follows:

1. A student must show documentation of their student number if a student number is not specified on their application.
2. A student must send in bank balance documentation if their bank balance changes.

These rules could then be fired off from within the 'Determine required documents for student' step itself, instead of spawning a sub process with lots of gateways.  Usually when you see lots of gateways in your business process you will find opportunities to simplify with business rules.

Here lays most of the effort in documenting the blueprint now, as each step in the business process may yield one of more business rules.  We must now document every rule we harvest in the rule repository as we iterate through the business processes.  As you iterate through the business processes the different steps which call business rules must be highlighted in the process diagram as rule tasks.  BPMN 2.0 offers an activity type called 'rule task' which is used to designate an execution of business rules.

This iterative process should yield the majority of the business rules to be documented. In my next entry I will show how to properly decompose and document those business rules in a way that makes it easy to implement them in Business Rule Framework plus, as well as other places to search for and harvest business rules.

In my last blog I showed how we use business processes to harvest business rules, and how the two are fundamentally different things.  In this entry I want to cover how to harvest even more rules from vocabulary, as well as how to decompose all of the rules we are collecting in our rulebook.

Harvesting Business Rules from Vocabulary

While most rules will be harvested through the business processes, the vocabulary should be analyzed for business rules as well.  The relationships between terms are critical for this activity to work.  Take the following example ER diagram:

There are probably some rules which constrain this relationship, such as how many applications can be submitted by a student.   A business rule for this relationship could be:

'A student may only submit one application per year'.

The business rules collected from vocabulary will be a major input to enforcing a data model within SAP.

Rule Decomposition

When iterating through business processes and vocabulary our goal is to harvest all applicable business rules and to break them down into their most atomic forms.  This leaves us with very specific rules which cannot be broken down any further than they already are.

For example, take the following rule:

'A student must send in bank balance documentation if their bank balance changes.'

This rule is not decomposed enough yet because there is still gaps that are not defined here, which usually means more rules or missing vocabulary.  What constitutes a change in bank balance?  Is there a time point on when this rule should fire off?  Right now the rule applies continuously once they have a bank balance change.  The above rule might better be written as follows below:

'A student must send in a bank balance document when their bank balance changes.'

Using the word when instead of if in this rule adds helpful context on the timing of this rule.  We don't want to continuously ask for a bank balance document over and over again, but instead only need to ask for it when their bank balance changes.  Speaking of which, bank balance change must be defined as well since there is nothing in the above rule which describes what constitutes a valid bank balance change.

'A bank balance change is any change greater than $1.00 in the total of all bank accounts which occurred since the application was last edited.'

Many rules are initially written with assumed or missed logic.  The activity of decomposition must happen for each rule to ensure all business logic is harvested and that each rule is simple to understand.  This process takes a long time, but it will pay off major dividends once you start building your business rules in BRFplus.

The next step is to find patterns in your business rules which allow the logic to be expressed more optimally in other forms than just semantic rules.  Take the below four rules as an example.

Award A must be disbursed at the midpoint of the study period for undergraduate degrees.
Award A must be disbursed at the beginning of the study period for graduate degrees.
Award B must be disbursed at the beginning of the study period.
Award C must be disbursed half at the beginning of the study period and half at midpoint of the study period.

These rules would be better represented as a decision table:

Decision tables allow logic to be represented in a very simplified format with the conditions on the left side (grey) and the results on the right side (green).  Fee tables and schedules are the obvious candidates for tabular rule logic, but with some careful analysis many business rules can be built using decision tables.  Another example of alternative rule formatting is decision trees.  Take the following rules:

The study period start date is term 1 if the student is enrolled in term 1.
The study period start date is term 2 if the student is enrolled in term 2 and not enrolled in term 1.
The study period start date is term 3 if the student is enrolled in term 3 but not in term 1 or term 2.
An agent must manually review an application which has no specified term for enrollment.

These rules would be easier to understand if the hierarchy is represented in a tree format as shown below:

While BRFplus offers a wide variety of expression types for representing rules, from a blueprint perspective I will keep the focus on semantic rules, decision tables and decision tree's since those are the most business friendly forms of representing rules and are also easily implemented in BRFplus.

So we are now harvesting our rules from processes and vocabulary and decomposing them into their most atomic parts, as well as representing them as optimally as possible in formats such as decision tables and trees.  Coming next in this blog series is the topic of rule metadata so we know what kind of additional details we need to collect per business rule aside from the rule logic itself in order to successfully implement in BRFplus.

Next Friday I will speak at the BPM Offensive Berlin which is a forum about Business Rules in German language. Participants are from universities, public and private sector.The event takes place at the SAP office in Berlin.

Another very interesting opportunity in Berlin to learn more about Business Rules is a workshop organized by Dr. Jürgen Pitschke (NCS, http://www.enterprise-design.eu/de/). He managed to organize this event with help of James Taylor - from my point of view the leading head in the space of decision management.

Contents of the workshop are:

• An introduction to Decisions and Decision Management
• Categorizing and identifying decisions
• Characteristics and design of decisions
• Managing decision logic
• The role of decisions in systems
• Getting started and first steps

All details can be found on the website: http://www.enterprise-design.eu/de/training-und-events/decision-management-james-taylor

I have expressed my appreciation for the work of James already several times. This would be a great opportunity to meet him in person.

After the event James will meet with decision makers from various companies. Maybe this is also a chance to contact him directly for a session. Finally, I need to mention his web site http://www.decisionmanagementsolutions.com/ where lots of interesting material and of course contact data can be found.

BRFplus for Dunning

My colleague Andrea Waldi wrote this document recently as many customers asked for more details on how to use BRFplus for dunning. It was also her who connected BRFplus in FI-CA in 2011.

BRFplus for HCM

Recently Wolfgang Schaper and I had a look at the rules used in HCM characteristics. For us both it was immediately clear that BRFplus would be the much better option to implement the dynamic requirements customers ask for. Today, customers use a tool called "Features". BRFplus can be plugged into it without any modification so that customers can benefit from BRFplus rules also in HCM easily. This document shows an example how to do it.

BRFplus in CRM for Calculated Fields

I found an interesting blog which describes how the Application Enhancement Tool (AET) in SAP CRM 7.0 EhP1 can be used to create calculated screen fields. When I checked the screenshots I had my déjà vu. Yes, it is true. This is the BRFplus formula.

Then I remembered the discussion I have had with one of the CRM developers about how to use BRFplus and what the formula could do etc. Another use case on our ever growing list.

Blog Series from Lee Chisholm

Lee Chisholm From Deloitte Canada is working with BRFplus since several months to deliver a BRFplus project in combination with SAP's Grants Management. I have just been to Winnipeg about one week ago to see him and gather some feedback from the project. There is also a Health/Insurance project at MBC in Winnipeg which will make use of BRFplus for the business rules part. So I had the chance to discuss their requirements and give some help for the planning and blue-printing

Lee and his team is using BRFplus in the version NetWeaver 7.0 Enhancement Package 2 (NW702). The MBC project will use Enhancement Package 3 (NW703). Based on his experience he wrote aseries of blogs that are worth reading. Hopefully, he also gets involved in the new project so that he can write an update once he knows the NW703 version well.

• How to Scope Your BRFplus Project
• How to Blueprint Your BRFplus Project: Part 1
• How to Blueprint Your BRFplus Project: Part 2
• How to Blueprint Your BRFplus Project: Part 3
• How to Blueprint Your BRFplus Project: Part 4
• How to Blueprint Your BRFplus Project: Part 5
• How to Blueprint Your BRFplus Project: Part 6

Picking up from the rule harvesting we started in part 3 and part 4 of this blog series, we should now take a look at what kind of metadata we need to record per rule in order to make the implementation in BRFplus as simple as possible.  There could be a variety of different attributes that an organization wants to capture on their business rules.  Depending on what kind of things need to be tracked this task can go from being easy to very difficult.  The following is some details on what I think are the basic attributes to track per rule as you harvest.

Rule Source Documentation

This can be as simple as stating the section of a policy document where a rule was sourced from, to as tricky as sourcing the actual program code from the legacy system.  What is important to keep in mind is the difference between details you need during the rule transformation, and details you need for long term management.  During a rule harvesting and documentation project there may be multiple translations of a rule from its source to the new documentation format.  Whether or not an organization wants to keep track of each translation explicitly, or refer to a more general source in the long term is up to them.

Associated Process Task(s)

Since every business rule is called by a business process at some point we must make the connection from the process task to the rules somehow.  It's critical to note here that only the rules which are directly called within the task should have this mapping, and not the dependent rules.  For example, if process P1 calls rule R1, and rule R1 calls rule R2, we would capture the link between P1 and R1, but not P1 to R2 since R2 is not directly called by the process.  When you document rules in a declarative repository such as a wiki, the links between rules are automatic, so all we need to consider is direct links between processes and rules.

Functions and Rulesets

While this mapping might not happen until realization depending on what blueprint methodology you follow, a business rule must be mapped to either a function or a ruleset in BRFplus.  If you are calling a BRFplus function in either 'Functional' mode or 'Event' mode with a single ruleset, then I would map the rule to the function.  In those scenarios the function is effectively your process task.  However if you configure a function in 'Event' mode and specify multiple rulesets, then I would map your rule to the specific ruleset for better traceability.  We will visit this more in my blogs on realization.

Implementation Details

To be clear here, the rules you build in BRFplus will not match 1:1 with the rules documented.  It's just not possible technically speaking.  In fact many of the documented rules might not even end up being BRFplus rules, but rather ABAP, standard SAP customizing or other things.  What you need to note for each rule, is technically how you think you will build it in SAP.  If you documented a decision table in your wiki, then it would be fairly simple to note that you will also implement it as a decision table in BRFplus.  However you might want to add some technical notes in here too around what technical requirements are needed to make this decision table work.  I.E. what kind of expressions might be called in the condition columns, what kind of actions will be fired off etc.  Once realization starts these details will be greatly expanded upon depending how you end up implementing the rules.  During blueprint you will mostly be noting ideas to get a count of certain types of rules.  I.E. we need 100 rules, 40 decision tables, 50 search trees etc.  These details will help validate the scope of realization and well as prepare for the implementation.

Overrides

Every business loves to keep the ability to manually override their rules.  On a per rule basis we must note which rules can be overridden by the business and how to achieve this override.  This is very important to understand before creating a technical architecture for the rules, as overrides can sometimes be tricky to implement.

Discussion and Comments

As business rules change the author should keep a log of what kind of changes are being made.  Somehow in your rule repository you must keep a discussion or comment log to trace back on changes that occur to each rule.

Unit Test Case(s) and Results

Finally you need to document unit test cases and results for the business rules.  This is pretty easy since if you decompose your rules to the most atomic level possible, the number of conditions for testing against in a particular rule should be relatively small.

Bringing It All Together

Below is an example of how a rule could finally be documented in a wiki with metadata included (click image for larger version):

So to summarize our progress so far in our blueprint, we have talked about which tools may work better than others and selected an appropriate rule repository.  We have ironed out the businesses vocabulary and the relationships between terms.  We also used our goals and decisions to create some business processes and began harvesting rules from these processes.  Finally we decomposed the rules into their most atomic pieces and today we added the required metadata to each rule in order to make the rule implementable in SAP.

In my next entry I will finish this series on blueprinting by looking at other considerations you must take when preparing for your BRFplus implementation.

WNABRF – Business Rules Framework plus (BRFplus)

Hundreds of organizations use BRFplus to model business logic and decision services like validations or calculations in a transparent and flexible way. BRFplus is packed into many SAP standard applications such as Master Data Governance, Tax and Revenue Management, Utilities, and many more. Do not miss this unique opportunity to learn directly from the BRFplus founder himself -- Carsten Ziegler on May 10-11 at the MicroTek training facility in Minneapolis, MN.

Business Challenges

• No transparency about critical business decisions implemented in hard-coded business processes
• Inflexible application code – traditional enterprise applications not designed for change High costs for changes
• Enforcement of policies and changed practices
• TCO of business applications
• Details lost in translation between the business and IT

Key Features

• Central, enterprise business rules and decision service repository with local or central execution
• Full transparency about mission-critical business logic, also for business experts
• High performance decision service execution based on generated code
• Full integration with SAP application portfolio and technology stack

Business Benefits

• Increased business agility at much lower initial costs and TCO
• Rapid ROI through quick build, test and deploy cycles
• Improved process quality because of full transparency of mission critical business logic for business-side experts

Audience

• Consultants, architects and developers who are responsible for designing and implement business applications
• Function and/or technical application consultants who want to make use of the decision/rules service approach
• Function and/or technical application consultants who use SAP applications with embedded BRFplus (CRM, MDG, FI, Public Sector, Utilities, Insurance SRM, ..)

This Course Will Prepare the Student to…

• Understand the basic BRFplus concepts, elements, and steps needed to apply them appropriately in the implementation of business rules
• Design business rules using the standard BRFplus elements
• Enable the creation of complex and flexible rules used by applications.

Course Code - WNABRF
Course Title -  Business Rules Framework plus (BRFplus)
Dates Offered - May 10-11 (Minneapolis, MN)

UPDATED: March 22, 2012
For more information about SAP Education, call 1-888-777-1727 or email education.northamerica@sap.com.

I attended BRFplus session in SAP DKOM 2012 Bangalore. Joydeep Paul from BRFplus Team talked about ongoing development and it was amazing.

He started with the concept of managing Business rules using BRFplus and then the upcoming stuffs which I want to share with you.

+ Decision Service Manager- This will be very useful to those customer's who are running on NW 6.4 or higher and want to make use of latest version BRFplus say NW 7.31 SP4 or higher without investing time and man force on upgrades.

How? - You need to connect the Target System where you want to deploy the rules while creating an application in the Source System. Once you are finished with the rule design, deploy it into the Target System; so that you can use it at run time without any performance issue. In future, if business users modify the rules then he/she need to deploy them again into the Target System.

Source System- NW 7.31 SP4 or Higher & Target System- NW 6.4 or Higher

+ BRFplus Powered by HANA- This demo explained how BRFplus will be using the power of HANA; and the best part is you don't need to be a HANA expert to execute rules. BRFplus internally takes care of everything to generate Call Procedure SQL scripts; which is required to process rules on HANA and this is where BRFplus and SAP NetWeaver BRM (Java based Rule Engine) have differences in their solution.

From my knowledge, you need to be a HANA studio expert to design rules in SAP NetWeaver BRM.

+ Microsoft Silverlight UI- If you are tired of using Web Dynpro UI elements and looking out for more flexibility to design rules, here is your catch.

BRFplus is going to leverage Microsoft Silverlight technology that provides a rich user experience for a business user to design and model business rules by just drag and drop; with most appealing graphical and highly responsive controls with nice visual effect like animation, zooming etc.

+ Cloud- Quite more interesting is that BRFplus is stepping into the Cloud space too, but it wasn't in detail.

SAPPHIRE 2012 + ASUG Annual Conference 2012 is a good opportunity to give birth to my newest baby, SAP NetWeaver Decision Service Management. SAP NetWeaver Decision Service Management is an add-on to BRFpluswhich makes BRFplus not only available to all ABAP-based applications (>= NetWeaver 640) but also adds a lot of capabilities to it.

About SAPPHIRE 2012 + ASUG Annual Conference 2012

"Join us for 2012 ASUG Annual Conference and SAPPHIRE® NOW, May 14-16 this year at the Orange County Convention Center in Orlando, Florida. ASUG Pre-Conference Seminars will take place Sunday, May 13. Please visit the event website www.sapandasug.com for further pre-conference session details as the event approaches."

I would like to invite you to two sessions I will do together with James Taylor from Decision Management Solutions.

Smarter, Simpler Applications with Decision Service Management

This discussion focuses on decision service management (DSM) – a strategy that helps make business processes and systems more efficient and more agile. Learn how DSM enables business experts to implement changes independently from IT, reducing both cycle times and costs. 

• Microforum Discussion, Database and Technology Campus, Application Platforms and Middleware, SAPPHIRE NOW 2012.
• Speakers: James Taylor, Carsten Ziegler
• Session ID 7699
• May 16, 03:00 p.m. - 03:45 p.m

Building Flexible, Easy-to-Change and Rock-Solid Applications with BRFplus Decision Services

SAP ABAP business applications can be rightly described as high performance, robust and rock-solid. Making them also flexible and easy to change is a challenge faced by many companies. Taking control of the critical decisions in these applications by developing BRFplus decision services resolves the challenge, giving business experts more insight into mission-critical decisions taken by the system. With BRFplus, business users can make the right change, right now without destabilizing the application or using over-stretched IT resources, improving process quality and compliance. The approach will be illustrated with real cases and TCO/ROI examples and a demo will show the creation of a decision service, implementation, and continuous improvement by business experts. Presented by a leading expert in decision management systems and the chief product owner and inventor of BRFplus, this approach can easily be applied by nearly all SAP customers to their critical business problems.

• Education Session, Enterprise Architecture, Enterprise Architecture as a Business Enabler, ASUG Annual Conference 2012
• Speakers: Carsten Ziegler, James Taylor
• Session ID 2414
• May 16, 04:15 p.m. - 05:15 p.m

Another interesting session is SAP Business Workflow and Business Rules Framework Plus (BRFPlus)

• Education Session, Business Integration, Technology & Infrastructure (BITI), ASUG Annual Conference 2012
• Speakers: Thomas Kosog (I will be there as well for questions)
• Session ID 0801
• May 14, 10:30 a.m. - 11:30 a.m

I am looking forward to discussing the new capabilities or any other topic related to business rules and decision management with customers and partners. Don't hesitate to contact me prior to the conference to reserve a private slot.

P.S. There is a new BRFplus video.

I do a lot of work with companies and organizations adopting business rules and Business Rules Management Systems (BRMS) such as BRFplus and NetWeaver BRM. I wanted to share two things.

First, I often find that when organizations start with business rules they begin by just trying to capture business rules the way they would capture any other kind of requirement in their blueprint. This is not an effective approach and results in what I call the "big bucket of rules." As I said on my blog earlier this year, you need to start with decisions not with business rules. Identifying the decisions that can and should be automated, decomposing these into their dependent pieces and then identifying the rules for each piece is a much better strategy and is the basis for my work in Decision Management and my recent book on the topic - Decision Management Systems: A Practical Guide to Business Rules and Predictive Analytics (see Carsten Ziegler's comment on the book here). Begin with the decision in mind.

Second I find that organizations often don't think about business rules and decision management as solutions to their problems. To help with this I have found a number of things are worth looking for in a project - these will make business rules and decision management a good candidate:

• The requirements are driven by policy or regulation documents
  Decisions around eligibility or validation based on these are often effective when implemented using a BRMS
• There is a requirement for regular or rapid change
  If the business want to make changes to behavior regularly, or if the pace of change is picking up for a module, it is almost certain to be a decision-making component and business rules will be a good basis for automating it.
• There are complaints about usability
  Many complaints about usability arise because the users are being forced to use the system for something it could do itself. An approval screen might be "unusable" and generate many complaints if someone has to use it for every transaction. If the Approve decision is handled by a BRMS 80 or 90% of the time then the usability of the screen may not be so much of an issue.
• There is an overcomplex process
  Mixing decision-making into process designs often results in very over-complex processes and using business rules to automate some of the decisions in the process can result in smarter, simpler and more agile processes.
• There is a plan to use analytics
  Using analytics to change the behavior of a system can be difficult unless you understand which decision the analytics are trying to improve and have control of that decision because you have implemented it in a BRMS
  
  

The good news for anyone coming to ASUG/Sapphire 2012 is that Carsten Ziegler and I have a couple of sessions on these topics. On Wednesday at 3pm he and I are hosting a micro-forum on “Smarter, Simpler Applications with Decision Service Management.” Carsten is the author of a great book on SAP’s rule engine BRFplus and the discussion will focus on decision service management (DSM) – a strategy that helps make business processes and systems more efficient and more agile.

After that, at 4:15pm, he and I are presenting on "Building Flexible, Easy-to-Change and Rock-Solid Applications with BRFplus Decision Services:"

SAP ABAP business applications can be rightly described as high performance, robust and rock-solid. Making them also flexible and easy to change is a challenge faced by many companies. Taking control of the critical decisions in these applications by developing BRFplus decision services resolves the challenge, giving business experts more insight into mission-critical decisions taken by the system. With BRFplus, business users can make the right change, right now without destabilizing the application or using over-stretched IT resources, improving process quality and compliance. The approach will be illustrated with real cases and TCO/ROI examples and a demo will show the creation of a decision service, implementation, and continuous improvement by business experts. Presented by a leading expert in decision management systems and the chief product owner and inventor of BRFplus, this approach can easily be applied by nearly all SAP customers to their critical business problems.

The session is in S310F

Decision Management and the use of business rules has tremendous potential for SAP customers. To help realize this value, Decision Management Solutions (my company) has become an SAP partner. We are already working on some BRFplus projects and we look forward to helping organizations see where Decision Management and business rules can offer a high ROI to SAP customers. If you have questions, drop me a line at jtaylor@decisionmanagementsolutions.com

Time has come to blog about recent activities and documents related to BRFplus.

ASUG Annual Conference 2012

James Taylor published an interesting blog called Business Rules, Decision Management and ASUG on May 11, 2012. He was my co-speaker for the ASUG/Sapphire 2012 session Building flexible, easy to change and rock-solid applications with BRFplus decision services. Now the slides for the session are available.

ASUG Webcast about Decision Service Management with BRFplus

The session will be repeated as an ASUG webcast on July 9, 2012 (11:00 AM CT / 12:00 PM ET / 9:00 AM PT / 10:00 AM MT).

However, this time several slides are replaced by a live demo. In the demo I want to show you how simple it is to deploy decision services in your system landscape without a need to upgrade your receiver business systems.

You can now register for the event on the ASUG website.

SAP Skills Conference 2012

Another event to learn about BRFplus and how it can be used for decision services is SAP Skills Conference, 2012, June 25/26. Event language is German.

Services zur Entscheidungsunterstützung mit BRFplus – Wie man mit weniger mehr erreicht

Services zur Entscheidungsunterstützung stellen ein neues Paradigma zur Realisierung von Geschäftsanwendungen dar. Mit entscheidungsunterstützenden Services und bestimmten Formen von Prüfmechanismen werden Sachbearbeiter in die Lage versetzt, eigenständig Berechnungen, Ableitungen und Klassifizierungen zu implementieren. Technisches Hintergrundwissen oder ABAP-Kenntnisse sind hierfür nicht erforderlich. Services zur Entscheidungsunterstützung schaffen weitestgehende Transparenz und Handlungsspielräume für alle Beteiligten. Hierdurch steigt die Prozessqualität und die Systeme können schneller produktiv genutzt werden. Services zur Entscheidungsunterstützung lassen sich in nahezu allen ABAP-basierenden Anwendungen nutzen, ohne dass hierfür ein Upgrade erforderlich wäre. In diesem Workshop stellen wir Ihnen dieses neue Paradigma für eine Anwendungsarchitektur vor. Wir demonstrieren, wie einfach Sie Services zur Entscheidungsunterstützung bauen können und wie Sie diese Services sowohl mit kundenspezifischen als auch SAP-Standardanwendungen verbinden können.

Dienstag 26. Juni 2012, 14:30 - 16:30

BRFplus Presentations in Spanish, Russian, and German

For information about BRFplus in Spanish and Russian language PDF files with BRFplus overview presentations have been created.

Para información acerca de BRFplus en español, se ha creado un archivo PDF con una presentación general de BRFplus. 

Для предоставления обзорной информации о BRFplus на русском языке был создан данный PDF документ.

• BRFplus Overview (Spanish)
• BRFplus Overview (Russian)
• BRFplus Overview (German)

I am working on an ROI study for BRFplus, SAP's ABAP business rules management system, with Carsten Ziegler. As a preliminary step I have recently published an initial brief on how to get an ROI from BRFplus that is now available on my company site without registration.

This short paper discusses the three ways to get a return from an investment in BRFplus to manage the business rules of your operational, day to day decisions.

1. Increased business value
   Reduced fraud, more targeted offers, improved productivity and faster time to value are just some of the ways the use of BRFplus can increase business value.
2. Reduced development cost
   The complex logic typical of decision-making is easier to develop and get right when you use BRFplus.
3. Reduced maintenance cost
   Once written as business rules, decision logic is much easier to maintain in BRFplus than it would be in ABAP.

If you want to learn more about BRFplus itself, check out Carsten's book "BRFplus -- Business Rule Management for ABAP Applications". If you have questions about where to start with BRFplus, what decisions to focus on, or anything else please drop me a line - info@decisionmanagementsolutions.com - or post a comment I can answer here on SCN as I am always happy to help. There's more information too on my company site (decisionmanagementsolutions.com) and my blog (JTonEDM.com)

Feel free to download the white paper and share it.

At ASUG this year Carsten Zeigler and I presented on Building flexible, easy to change and rock-solid  applications with BRFplus decision services. This was, if I say so myself, a great session but it was very late in the event and so a bunch of people missed it. To help you catch it we will be repeating it and discussing Decision Service Management with BRFplus in an ASUG webcast on July 9, 2012 (11:00 AM CT / 12:00 PM ET / 9:00 AM PT / 10:00 AM MT). Carsten will be replacing some of his slides with a live demo to show how simple it is to deploy decision services in your system landscape without a need to upgrade your receiver business systems. He has also posted our slides.

If you are interested in business rules and BRFplus, and you should be, you could also check out this paper on the ROI of BRFplus and this one on the power of business rules and decision management to improve business processes.

You can register for the event on the ASUG website.

In this post I want to introduce you to recent improvements in BRFplus that we found very helpful in customer projects.

Automatic deletion of unnamed unused objects

Such objects are created when, for example, a rule is created in a ruleset and then removed again (without writing a version). BRFplus already tries to filter out such objects when saving. In case they were saved, BRFplus deletes them automatically.
Valid for NW 7.0 Enhancement Package 2 (NW702) and NW 7.3 Enhancement Package 1 (NW703/731).

Automatic deletion of objects set to “Marked for Deletion”

Objects marked for deletion are now periodically checked for using objects. As soon as there are no references, the object is automatically deleted. This means that from now on, any object which shall be deleted but cannot, because it has using objects, can be set to “Marked for Deletion”. Manual deletion is no longer necessary.
Valid for NW 7.3 Enhancement Package 1 (NW703/731).

New versioning mode Version by Transport

The new mode gets a new version of an object whenever an object is transported. This concept is taken over from ABAP code which gets a new version when a transport is released. Valid for NW 7.3 Enhancement Package 1 (NW703/731).
Versioning is not mandatory anymore for usage of lean trace.
Valid for NW 7.0 Enhancement Package 2 (NW702) and NW 7.3 Enhancement Package 1 (NW703/731).

Simulation using generated code

Simulation can now be done using the generated code directly. In this case the lean trace protocol will be shown as the simulation output.
Valid for NW 7.3 Enhancement Package 1 (NW703/731). 

Simulation for expressions

Expressions can now be simulated directly. There is no need to create a function just for the sake of simulation.
Valid for NW 7.3 Enhancement Package 1 (NW703/731).

Execution of actions in simulation

It is now possible to define whether actions should be executed. In some situations the execution of actions is required for testing. In others it may not be a good idea because of the side effects.
Valid for NW 7.3 Enhancement Package 1 (NW703/731).

Simulation based on historic and inactive versions

Historic and inactive versions can now be used for simulation. The simulation protocol has been improved with respect to clarity and structuring (e.g. expandable rows in decision tables).
Valid for NW 7.3 Enhancement Package 1 (NW703/731).

Search in the simulation protocol (also search in lean trace output)

A free text search feature has been introduced.
Valid for NW 7.3 Enhancement Package 1 (NW703/731).

Introduction of Hot Keys

In the BRFplus workbench, you can now configure hot keys for a big part of the functionality.

Valid for NW 7.3 Enhancement Package 1 (NW703/731).

Improved code template generator

On the function UI there is a code template generator (previously only as a backend report). The code template provides various options. It has been improved several times.
Valid for NW 7.3 Enhancement Package 1 (NW703/731).

Rule improvements

A rule can now also call an expression in cases where the expression result is not a field in the context. Therefore, it is possible to define a target data object the expression result shall be copied to. The following screenshot shows an example. The formula expression “Apply Promotion” returns a result field called “Price”. In the ruleset context, there is a field called “Final Price”, which shall take the result of the formula. In the screenshot you can see how it is possible to pick a field to take the result of the expression call.

The Release to Customer of SAP NetWeaver Decision Service Management 1.0 is planned for July 31st 2012, which signals the beginning of the Ramp-Up process.

How you can cut down implementation times by 90% and still add more flexibility to your customers? SAP NetWeaver Decision Service Management will change forever the way how SAP standard and custom applications are implemented. Being available for ABAP-based releases starting with NetWeaver 640 it provides the technology to cut down project times by >90% through full empowerment of business experts for continuous decision optimization. SAP NetWeaver Decision Service Management stands for immediate ROI but also for many use cases that have never been possible before without any need for customers to upgrade their system landscape.

The Decision Service Manager (integral part of SAP NetWeaver Decision Service Management where you define and maintain your rules) allows for central definition of decision services that then are being deployed to and processed in managed systems (where your application resides for optimal execution performance).

Superior Technology

• Decision Service Manager provides access to metadata, code and values (master data, customizing) to Managed Systems such as ECC or CRM for “local” modeling
• From the modeled service Decision Service Manager compiles an executable service on the Managed System for local execution
• The Managed System does not required upgrades, Decision Service Manager can be upgraded independently

Immediate Business Value / ROI

• Super-fast change cycles in the hand of the domain experts
  • Analyze,  Optimize,  Implement; service execution testing, tracing, analytics
• No IT involvement, no downtime, planned service availability, test deployments to any number of systems
• Automated business decisions with full transparency for better decision quality

Highest deployment flexibility, fastest change cycle, best performance, lowest TCO

By participating in the Ramp-Up program, customers will be among the companies that will enjoy the benefits of first-mover advantages in their industry. Through SAP involvement in each Ramp-Up customer project, customers also benefits from the coordinated efforts of SAP Development, Quality Assurance and Service & Support teams, who in conjunction with the dedicated Ramp-Up team, will support the implementation and give priority attention to the project - resulting in successful implementations and very satisfied customers.

I will personally support ramp-up customers either onsite or remotely to ensure a fast and successfull go-live. Decision Service Management will be presented at TechEd in Las Vegas, Madrid and Bangalore. Watch out for the respective sessions. Get in touch with me for a demo!

Familiarize yourself with the SAP NetWeaver Decision Service Management 1.0 Ramp-Up program, and nominate yourself using the Online Scoping Tool.

Recently a couple of notes have been released for performance improvement in BRFplus rules processing.

The imrpovements mainly optimize the runtime for data transfer to BRFplus or from BRFplus back to the caller.

• 1737847 Huge size of generated code for 'move to ext'
• 1740669 BRF+: Buffering for currency decimals
• 1748948 BRF+: Performance improvement in data transfer
• 1743329 and 1749719: Performance Optimizations for Text Reading

In case you experience a not satisfying runtime, consider implementation of all those notes. Unfortunately, some improvements and corrections made during the last months had a negative effect on performance.

Sorry for that.

SAP NetWeaver Process Orchestration is an innovative suite of SAP NetWeaver BPM, BRM, and PI with the enhanced capabilities of dual stack in a single Java stack. We have recently published a presentation on SCN to keep you up-to-date on the latest happenings in the BRM space of SAP NetWeaver Process Orchestration.

What is New in BRM with SAP EHP1 of SAP NetWeaver Process Orchestration 7.3 is a short walkthrough of the latest updates to the Rules Manager and Rules Composer and gives an introduction to how to use these new features to model rules effectively.

Rules Manager already got a few improvements in SAP NetWeaver Process Orchestration 7.3. It includes feature enhancements, such as importing and exporting decision tables with other conditions and other actions and editing common definitions and reusable rulesets. These features improve the business user experience to manage rules. Other features such as “Diff" of ruleset entities in Rules Manager and fine-grained access control features also improve the governance of ruleset entities in Rules Manager. However, EHP1 focused mainly on reducing redundancy in Rules Manager by creating reusable definitions.

The SAP NetWeaver Process Orchestration 7.3 EHP1 update also features major improvements to Rules Composer. The 7.3 release enables you to download business rules from Rules Manager and to extract and deploy the Lean Rules Engine decentrally on a Java Virtual Machine. However, the EHP1 update also supports the integration of rules content from Rules Manager to SAP NetWeaver Developer Studio.

The update also added a public API for reading and modifying decision tables. It also explains the types of literals and best practices used in rules projects and how to set rules preferences for rules to execute them during runtime. You can view this presentation here: https://scn.sap.com/docs/DOC-31686.

Abstract

In a recent development project, I successfully employed the Business Rules Framework BRFplus as the rules engine for voucher-based rebates in a retail scenario. In this blog, I describe my experiences and some implementation details. The bottomline is that I fully achieved my goal of implementing the rules in the business rules framework, keeping it separate from the ABAP code, which only calls the rules with the actual parameters. The rules are integrated into the classical SD pricing procedure which now functions as a façade. The processing of the rules is of highly satisfactory performance.

The Rules of the Game

This was the requirement: customers, when ordering goods in a store, could  pass some rebate vouchers to the sales person, who, by scanning the vouchers, adds them as value items to the same SD customer order that contained his ordered items, resulting in a reduction of the order's total amount.

A potpourri of rules had been invented to handle these vouchers, like the following:

• A voucher is valid for a certain assortment, for a certain label, or even for a certain article number, or a combination of these criteria.
• A voucher can result in a percentage reduction, or in an absolute reduction.
• Some vouchers require a minimum sales total for the ordered articles to which they refer.
• There are vouchers that can be applied only once. Another voucher kind counts multiple times, if the sales total for the ordered articles to which it refers is a multiple of its minimum amount.
• Yet another kind of vouchers can be applied multiple times, but not more than N times, where the number N is a property of the voucher.
• There may be restrictions on date and time: Some vouchers apply only during certain "Happy hours", others only on certain days of the week.

When I read these rules, it was clear to me that they will soon be modified or extended by new rules. If the rules are deeply hidden in the ABAP code, it would be cumbersome to extend them. If the rules could somehow be written down in a more business-like manner, it would be easier to modify or extend them later on.

Ideally, a program implementing a certain development request should read "almost" like the rules as they are written in that request. It is an advantage if the business rules can expressed in a language which is as near as possible to natural language. Even when we decide to let only programmers change the code, it is of value to have it business-readable, as Martin Fowler points out in an interesting article on this topic:

If business people are able to look at the DSL code and understand it, then we can build a deep and rich communication channel between software development and the underlying domain. Since this is the Yawning Crevasse of Doom in software, DSLs have great value if they can help address it.

Indeed, business-readable code can be seen as a contract between programmer and business expert: A reference point for discussions on the actual system behaviour and on its possible future changes. From another viewpoint, it is a machine-readable specification. Basically, this is true for source code in general, as Jack W. Reeves pointed out in his now famous essay The Code is the Design (1992). But what turns a design document into a specification is that, in addition to being machine-readable, it is business-readable (which is not the case for the average source code of a project).

Since I am interested in this kind of questions, I thought this was a good topic to give the Business Rules Framework BRF+ a try.

Project Situation

We are on SAP_BASIS 702, so some features of BRF+ were missing. It came out that these gaps were insignificant and not essential for the rules at hand. There was only one OSS note to apply, concerning the internal handling of floated decimals. But even that note was not really essential, it only made the life easier.

Sales orders are created as normal SD orders, the vouchers representing a new kind of articles, resulting in value items of the sales order. Since we are in SD, prices are determined by a pricing procedure. Wouldn't it be wiser to stick to the pricing procedure and use the "formula and conditions" exits (transaction VOFM) to implement all these rules?

Not necessarily! Bringing BRF+ into play brings the advantage that the rules determining the rebates are more transparent. If they are hidden in some ABAP form routines, the rules are difficult to find and will potentially become too complex.

Linking SD Pricing with BRF+

The idea was to use pricing formulae in the way of a façade for BRF+:

• Certain events of the sales order, e.g. if an item has been added or removed, if an ordered quantity or article number has been changed, and the like, trigger the BRF+ (re-)evaluation of the complete sales document.
• The results of the BRF+ computations are captured as attributes of an adapter class, which then effectively calls the BRF+ function.
• When the pricing procedure is propagated, certain formulae retrieve the amount for their condition line from the BRF+ adapter class attributes.

To illustrate this, consider the following formula which links the condition values with the results of BRF+ (it's not precisely how it is implemented in our system, but it exposes the basic idea). This is the code for a custom formula 930, which is attached to the relevant conditions ZFRC and ZPRC in the SD pricing procedure:

form frm_kondi_wert_930.
 
   data: lo_rebates   type ref to zcl_rebate_voucher.
 
 * Default values
   clear xkwert.
 
 * Instance contains the computed reductions
   lo_rebates = zcl_rebate_voucher=>get_instance( ).
 
   case xkomv-kschl.
     when 'ZFRC'.
       xkwert = lo_rebates->get_absolute_reductions( komp-kposn ).
     when 'ZPRC'.
       xkwert = lo_rebates->get_relative_reductions( komp-kposn ).
   endcase.

 endform.                    "FRM_KONDI_WERT_930

For this to work, it is essential that the single instance of zcl_rebate_voucher has processed the BRF+ rules before the pricing is called. This can be assured within the programming model of the SD sales order.

I am leaving aside for simplicity some peculiarities: For example, we are keeping track of the price bases of all sales items in an intermediate item pricing sum (VBAP-KZWI5 in our case). This is filled after the pricing of an individual item, but before the pricing of the complete document is processed (in subroutine PREISFINDUNG_GESAMT) later on. This way, the problem of reciprocal dependency (BRF+ needing SD pricing, and SD pricing needing BRF+ results) is circumvented.

The Benefit

To give you an impression of  how fluent the rules read in the BRFplus environment, the following is a copy/paste from a central Loop Expression of the rebate ruleset. No tricks! The text is almost precisely what you read in the BRF+ detail view for that expression. In a sense, this is the source code of the new rules. If something has to be changed, it has to be done on this level.

In the BRFplus UI, the underlined terms are in fact hyperlinks, pointing to other BRFplus objects, mainly to expressions or data objects. The whole source code of the rebate rules can therefore be considered as a hypertext document, consisting of various expressions, rules and functions referring to each other. Each part of this web consists of some lines of text in natural (although formal) language.

I consider this a highly important shift in programming: On top of the host language ABAP, the business rules framework enables a new way of implementing business logic. The new meta level is fully devoted to the business domain, providing a directly readable specification of how the program works, in terms of the domain itself - whereas the host language is reserved for the technical and implementation details.

In my eyes, this is the value and the main benefit of BRFplus: The introduction of a new level of domain-specific programming, allowing a clearer separation of business concerns from "implementation details".

It would be possible to abstain from that new level, using only ABAP to express all parts of the solution. It is then in the responsibility of the developer to write his code in different levels of abstractions, the highest abstraction on top exposing a pure domain-oriented view, the lower levels containing more "implementation-oriented" aspects of his code. This is possible by applying what Robert C. Martin calls the "step-down rule" in [Clean Code]:

We want the code to read like a top-down narrative. We want every function to be followed by those at the next level of abstraction so that we can read the program, descending one level of abstraction at a time as we read down the list of functions. I call this the Step-down Rule.

Using a framework like BRFplus, one gets this separation out of the box. The rules themselves are not written in ABAP but are composites of various BRFplus expressions. Implementation details may still be written on the ABAP level (although it is basically possible to write any code in BRFplus, there is no clear benefit of it.).

Interface and Dictionary

The element which connects BRFplus into the hosting ABAP code is a BRFplus function. In our case, the function has the name "Rabatte berechnen" - "Compute rebates" and has the following interface:

All the items of the sales document are divided into two subsets: The rebate items, and the retail items, the latter being the real sales items the customer wants to buy. Before the function is called, these two subsets are filled into two internal tables, enriched by some additional properties derived from master data and sales action documents.

I found it convenient to use the tables as changing parameters, containing input and output fields in one structure. This way, when looping over the tables, the results can be filled during the rule processing. Here is an example: The line structure of the retail item table. The boxed part is the output part: The different kinds of reductions and rebate points ("Cumulus points") the item receives, and an internal table REDUKTION_COMPOSITION, documenting the contribution of the various rebate items to the total reduction of the retail item.

In BRFplus, the word "dictionary" gets more of its original meaning, it is thought as a glossary: The pool of data objects that are needed to describe the problem from the viewpoint of the business. In contrast, the ABAP dictionary is more a globally accessible type system - an essential counterpart of ABAP source code. Nowadays, nobody considers the ABAP dictionary as a "glossary of the business terms" in the first place: Although it was once intended for this purpose, "the DDIC" now firms as part of the "technical realm" - it is as development-specific as the source code itself.

Always when we have the freedom to invent names and texs for items in programming, we should choose them wisely. In his book "Clean Code", Robert C. Martin recommends to change the names of functions, parameters and variables again and again during development and during refactoring sessions, until the code that calls these functions is as expressive and readable as possible.

This holds for the BRFplus dictionary as well. After having invented the names and texts, we should look how the rule code reads with these texts: Is it comprehensible? An improper naming distracts from the essential point, the intention of the code / the rule.

In my project, I created the data structures in the ABAP dictionary and used the option to import them into BRFplus. It would also be possible to define all the necessary types and data objects freely in BRFplus, with no reference to the ABAP dictionary. But at least the data involved in the BRFplus function signatures should be known in ABAP as well. This means a duplicate definition of semantically identical types: a necessary "Don't Repeat Yourself" violation, which is handled best by using the ABAP dictionary binding mechanism (the alternative: to define the type in both worlds independent of each other, would be worse). When the structure is changed later in the ABAP dictionary, it can be actualized in BRFplus.   

I wrote that I use my interface parameters as changing parameters. Strictly speaking, this is not true. I found out that the parameter passing to the BRFplus function always is by value: The parameters are moved into the function context before the function call; and after the call, the results have to be pulled out from the context. This means, there are some copy processes of data necessary. The method RABATTE_BERECHNEN of the adapter class is defined with changing parameters:

methods rabatte_berechnen
     importing
       is_timestamp type zcrc_timestamp optional
     changing
       ct_retail_item type zcrc_retail_item_tab
       ct_promo_item type zcrc_promo_item_tab
     raising
       zcx_error .

This is the implementation of this method: the BRFplus call, which shows the necessary data copying from and into the method's changing parameters:

method rabatte_berechnen.

  data: lo_rabatte_berechnen type ref to if_fdt_function,
        lo_context type ref to if_fdt_context.

* A voucher always has a range of articles to which it refers 
  assert id zdev
    condition coupons_haben_artikelbezug( ct_promo_item ) eq abap_true.

* A voucher with multiplicity 1 always has a minimum turnover value specified
  assert id zdev
    condition mindestumsatz_gepflegt( ct_promo_item ) eq abap_true.

* Function processing only necessary if there are retail items and rebate items
  check :
    ct_retail_item is not initial,
    ct_promo_item is not initial.

* Get handle to BRFplus function
  lo_rabatte_berechnen = get_function_rabatte_berechnen( ).
  lo_context = lo_rabatte_berechnen->get_process_context( ).

* Pass parameters into function context
  lo_context->set_value( iv_name = 'RABATTPOSITIONEN' 
                         ia_value = ct_promo_item ).
  lo_context->set_value( iv_name = 'RETAIL_ITEMS'     
                         ia_value = ct_retail_item ).
  lo_context->set_value( iv_name = 'ZEITSTEMPEL'      
                         ia_value = is_timestamp ).

* Execute function
  process_function( io_function = lo_rabatte_berechnen
                    io_context  = lo_context ).

* Retrieve parameters from function context
  lo_context->get_value( exporting iv_name = 'RABATTPOSITIONEN' 
                         importing ea_value = ct_promo_item ).
  lo_context->get_value( exporting iv_name = 'RETAIL_ITEMS'     
                         importing ea_value = ct_retail_item ).

endmethod.

Expressions

I tried to keep the ingredients of the BRFplus function self-contained, avoiding interferences with the ABAP world. Here is the set of expressions that were necessary for the rebate voucher rules:

As you see, I used the following expression types:

• Boolean expressions,
• Cases,
• Formulae,
• Function Calls, and
• Loops.

In particular, I didn't use:

• Database accesses from within BRFplus. If database accesses were necessary, I did them before calling BRFplus and passed the relevant data using the function parameters.
• ABAP function and method calls from within BRFplus. ABAP function calls and method calls being necessary in an essential way, would question the use of BRFplus at all. Indeed, things like custom-defined, ABAP-implemented formulae should be the exception, not the rule when using BRFplus.

There might be cases in which these operations make sense. For example, ABAP method calls may be employed if there already exists a set of complex ABAP methods, and BRFplus is used only as a tool to combine (to "orchestrate") these methods in a flow, according to certain rules. Or, the database access may be used for techniques similar to the condition table access of classical pricing.

But keeping the BRFplus isolated and publishing all its dependencies in the function interfaces, brings a couple of advantages. One of them is the ability to do unit tests.

Unit Tests and Debugging

Designing a function such that the result depends only on the actual parameter values with which it is called, makes it easily testable, for example with unit tests. I have assured the basic rebate voucher functionality with 42 unit tests, organized in 12 classes.

In each test class, the BRFplus function is called precisely once, in the class setup. (Here, I use a macro set to fill internal tables, reducing the code to the essential parts: Which components should be filled with which values, whereas the boilerplate ABAP code to populate structures and tables is hidden in a subroutine pool zut_au_forms.)

method class_setup. 
     data: ls_promo_item type zcrc_promo_item.
 
     _insert_row_n_fields gt_retail_item
       'posnr;matnr;bossnummer;reduktion;preisbasis;waehrung;promofaehig' :
         '10;M1;220112548789;;1000;CHF;1'.
 
     _set_struc_n_fields ls_promo_item
        'posnr;matnr;typ;betrag;mindestumsatz;mehrfach' :
        '90010;RABATI;5000;10;;1'.
     _insert_row_n_fields ls_promo_item-sortiment : "insert the article range of this voucher
         'aktnr;pos_type;id;excluded' '12345;1;2201;0'.
     insert ls_promo_item into table gt_promo_item.
 
     clear go_testee.
     rabatte_berechnen( ).
 
   endmethod.                    "class_setup

The tests themselves only check that the function produced the expected results - like the following:

  method faktor.

    assert_equals( act = gs_promo_item-faktor
                   exp = `0.01`
                   msg = `Faktor has to be 0.01` ).

  endmethod.                    "faktor

  method composition.

    field-symbols: <ls_promo_comp>  type zcrc_bonus_composition.

    read table gs_retail_item-reduktion_composition
         assigning <ls_promo_comp> index 1.
    assert_subrc( act = sy-subrc
                  msg = 'Voucher must be part of the item's reductions' ).

    assert_equals( act = <ls_promo_comp>-promo_posnr
                   exp = '90010'
                   msg = 'Voucher item number needs to be passed into item composition table' ).

    assert_equals( act = <ls_promo_comp>-betrag
                   exp = 10
                   msg = 'This voucher must give a 10 CHF reduction' ).

  endmethod.                    "composition

The unit tests can be repeated frequently during development, since they don't consume much time. If one or more of them are broken at a certain point, it must be due to the last changes. A static analysis of these last changes usually helps understand the cause why they are broken. The time to fix a new bug is usually much shorter than with a trace or debugging session.

It should be mentioned that usually there is no necessity to debug the BRFplus logic, since there is a detailed trace which logs the result and all the details of each processed expression. I'll come back to that in a moment.

But even when you decide to debug, the module tests are helpful. By placing a break-point at the function call which produced a test failure, and hitting "Module test", the call can be repeated easily, again and again. The BRFplus rules are translated into ABAP code (code generation). But the good news is that the generated code is readable and the generation concept is readable and comprehensible - hence debuggable.

Understanding the Result

The backoffice workers - usually not the sales persons themselves - involved in the sales order management, sometimes want to know why a particular voucher is accepted or not accepted, and how it contributes to the order's total reductions. For these cases, an analysis screen is helpful. I designed such a screen and made it available with a button in the GUI status, using a new function code in the screen sequence control (transaction VFBS).

If the user hits the new button, the following screen is displayed, showing all the relevant data for the rebate voucher processing - including the results, which are computed again in simulation mode when the screen is called.

By double-clicking on a retail item, a popup appears listing the contributions of the different voucher items to the total reduction of this item.

For the daily business, the informations on this screen contain all the necessary information. But in support, sometimes a more detailled trace will be necessary. For this reason, I made the so-called technical trace of BRFplus available in the above screen. It can be used directly in the BRF+ Web Dynpro application, as described in a blog by Phillip Parkinson but then the interface data would have to be entered manually, which is a time-consuming and error-prone business for our function: Two internal tables would have to be populated field by field, row by row - with data that are available in the order anyway. In order to populate the interface automatically with the current sales order data, I decided to call the trace in ABAP code. This is the method performing the trace call:

method process_function.
 
   go_context = io_context.
 
   call method io_function->process
     exporting
       io_context    = go_context
       iv_trace_mode = if_fdt_constants=>gc_trace_mode_technical
     importing
       eo_trace      = go_trace
       eo_result     = go_result.
 
 endmethod.

The trace object eo_trace passed back from the function call, contains an XML representation of all the evaluations performed during the call. This trace is very detailed. The support employee, when analyzing a particular problem, can call it using the "XML" button in the detail screen shown above:

Due to its very detailed nature, I felt the desire to transform this XML into a more readable subset. There are certain building block elements of the XML structure like FUNCTION, EXPRESSION, RULESET, CONTEXT and CONTEXT_UPDATE which are combined in a hierarchical manner (reflecting the rules implementation, of course). I therefore designed an XSLT transformation ZCRC_TRACE which, applied to this XML file, produces HTML code in a more reduced manner, as the following screenshot shows. There are buttons for collapsing or expanding the subordinate informations on each level. Data objects can be inspected by clicking on the corresponding hyperlink, which shows them using the function module RS_COMPLEX_OBJECT_EDIT, which is also used for data maintenance and inspection in function module single test mode (SE37).

Summary

My experiences with this first BRFplus project are very positive. The implementation is stable and efficient. The vast majority of bugs and feature requests in the test phase referred not to BRFplus itself, but to the embedding of the rule processing into the SD sales order.

I consider BRFplus as a serious step towards the ideal of business-readable code. The introduction of a new level of programming, on top of ABAP as the host language, is a promising new route in development.

Also, I praise the co-operative philosophy of BRFplus: It doesn't want to lead, to seize the whole development floor, but can co-exist with other implementations which at the same time are following a more traditional approach. There is no top-down strategy necessary (by the way, it was this top-down philosophy which broke SOA the neck). In the words of blogger Meinte Boersma: BRFplus, like all the model-driven-inspired development techniques, needs a kind of guerilla technique. Don't make a big management issue about it - just employ it in all places where you find it makes sense. Every aspect of the system that gets implemented with BRFplus is your contribution to the better software world of tomorrow! :-)

References

• Thomas Albrecht and Carsten Ziegler: BRFplus - Business Rule Management for ABAP applications. SAPpress 2010.
• Phillip Parkinson: Technical Trace in BRFplus. Blog, 09/19/2011.
• Meinte Boersma: In the trenches: MDSD as guerilla warfare. Blog, 10/01/2012.
• Martin Fowler: Domain-specific languages. Addison-Wesley 2010.
• Robert C. Martin: Clean Code. A handbook of Agile Software Craftmanship. Prentice Hall, 2008.
• Jack W. Reeves: Code as design. Three essays, The C++ Journal, 1992f.

Hello,

BRFPlus has saved me so much time and development effort it is my new best friend.  However, I have a new requirement to update/delete specific rows in a decision table.

For the delete, if I know the row number, I can easily call the delete_rows method of IF_FDT_DECISION_TABLE, however, getting the specific row that I am interested has proven to be a challenge.  Shouldn't the function provide me with the reference to the row in the decision table.

For the update of a decision table row, my only solution right now is to read the entire table, manipulate it and then repost it. So I need to find a more elegant solution to access only the row I am interested in.

If anyone has experience with this type of activity I would really appreciate the help.  I have looked through the examples and the SAP-Press BRF book, a lot of excellent information that has help with other scenarios, but not this one. 

Thanks,

Andrew

This blog shows some best practices for the authoring of decision services in SAP NetWeaver Decision Service Management with BRFplus business rules. Where appropriate, I will contrast good with bad examples to illustrate my arguments. The idea of decision services based on business rules has the functional experts in its focus. These people need to be able to understand the business rules and take ownership of the logic that contributes to their success.

The screenshots were taken from a system with NetWeaver 7.3 Enhancement Package 1 (which is equal to NetWeaver 7.0 Enhancement Package 1) and SAP NetWeaver Decision Service Management 1.0.

Content

• Descriptive object texts
• Object documentation
• Expression result values
• Usage of technical expressions
• Rule catalogs
• Access control
• Decision service design and documentation

Descriptive object texts

I cannot emphasize enough the importance of good descriptive texts for BRFplus objects such as formulas, decision tables, table operations, and especially for the more technical expressions, such as database lookups and procedure calls. When people with a technical background start modeling business rules, they tend to apply the same patterns they use for programming to the authoring of business rules in BRFplus. This is especially true when it comes to defining object names. And often, things get even worse when we look at the object texts. Moreover, many IT people configure the BRFplus workbench so that the technical object names are shown in the user interface instead of the texts.

The following example shows a pricing ruleset. Although simple in its logic, it looks complex. Names with technical prefixes have been used. The names do not explain what the objects are used for. Also, the names include German abbreviations, maybe because the data objects are bound to the Data Dictionary where German abbreviations are still common in some modules.

How can we improve this? It all starts with making the right personalization settings. To open the personalization dialog, use the highlighted icon in the BRFplus workbench.

On the General tab of the Personalization dialog, make sure the Show Technical Names checkbox is deselected. By the way, if you want to learn more about the various personalization settings, choose Show Quick Help from the background context menu. Most of the available options have an explanation attached that helps you understand the effect of each setting.

Once the Show Technical Names option is deselected, the example from above looks like this:

Now, it is very clear what this ruleset is used for. It is easy to understand the meaning of each data object and expression. Even people without technical expertise are able to read and understand the business rules.

For each object in BRFplus, two text fields are offered:

• Short Text (up to 20 characters)
• Text (up to 80 characters)

When both are maintained, BRFplus uses the short text by default. If the short text is missing, BRFplus uses the text, which provides a lot of space to describe the object well. So, instead of entering a cryptic short text, just leave it empty and use the Text field only.

Texts have even more advantages over names. While names adhere to restrictions known from development and database objects, texts do not have any such restrictions. They can be translated into several languages which make the rules including all used objects not only form English sentences but also form sentences in other supported languages such as Portuguese, Spanish, Chinese, German, and so on.  Also, special characters such as the German Umlauts are supported. If you like, you can go to extremes and insert a text like the following - no problem:

In case you have bound a data object to a Data Dictionary data element, you can still overwrite the texts to customize the appearance according to the needs of the target group. And remember – a major part of the target group are business experts, not just developers. Needless to say, changing a text is automatically reflected in all the places where an object is used. 

Technical expressions such as a database lookup expression (selects data from a database table) or a procedure call expression (calls an ABAP function module, an ABAP method, or an SAP HANA procedure) can be nicely described with texts, too. A text such as “Retrieve business partner properties” is much better than “SELECT NAME AGE … FROM BUT000”.

The same is true for complex conditions that may be formulated as questions with the help of the text property. In the following example, a table operation expression is used to get the total for a month out of a table.

All these features in BRFplus contribute to a so-called Domain Specific Language (DSL), that is, business-readable instructions for the execution of the decision service. Rüdiger Plantiko has recently published a blog with a nice explanation of this principle using a real-life example.

At best, you start with a business vocabulary defined by the functional experts. Then, this vocabulary is translated into BRFplus objects and used throughout the rules. I have seen complex business rules that were understood and owned by business teams within a few days. A positive side effect of this approach is that feedback for improvements can be discussed between IT and business without any translation step.

Object Documentation

Each object in BRFplus can be documented. You can find the documentation input field in the general data section. Documentation can also be language-dependent.

As soon as documentation is available for an object, you will find a new icon in the top row. Just click on it to let the system take you directly to the documentation tab.

In addition, if documentation has been maintained for an object, this is also reflected in other places in the workbench, such as the help menu or the object menu, which will show you the object documentation in a popup.

Additionally, rule documentation can also be inserted directly when creating rules. This is part of the so-called rule header that can be made visible with the glasses icon, or with rule-specific menu. Good rule documentation can help a lot to introduce the decision service logic to new experts, thus making your projects more efficient.

Since each rule in a ruleset has exactly one documentation string, we recommend not making the rules too big. The following figure shows a bad example (rule #3), followed by a better one (rules #4 and #5):

Expression result values

Each expression in BRFplus has exactly one result data object. This can be an element, a structure (with components of type element, structure, or table), or a table (with an element of a structure as its line type). In a rule, a decision is made about which part of the result should be taken over into the context, and how this should be accomplished (either updating a data object or inserting it into a data object of type table). It is, for example, possible to use a decision table with 3 result columns but take only 2 result values over into the rule context. The example below shows a decision table with two result columns, Base Price and Explanation. BRFplus has automatically generated a result structure (“Result Structure Of Table with Product Prices incl. Discounts”) with these two components.

In the rule, it is possible to update the context data object Base Price only and ignore Explanation.

It is further possible to map the result of the decision table to another context data object. Although the table returns Base Price, I can set Price as the context data object to be updated by using the little highlighted menu.

Sometimes you may not want to return a result. This may be the case when your expressions only perform actions. If this is the case, make this clear in the rule by using the respective option.

For loop expressions and call procedure expressions, it is possible that no specific result is to be returned and mapped to a context field. Instead, the context is updated within the loop. Nevertheless it is good practice to use a result, ideally, the updated data object. This makes clear to the reader of the rule what is changed during rule execution.

Often, rules authors are not clear about all the options BRFplus provides. Instead, workarounds are applied that make the rules look more complex than necessary.

Rule catalogs

Rule catalogs are a very efficient means to organize business rules and related artifacts. One object can be used within many different catalogs. Structuring folders can be created, and even referencing between catalogs is possible.

Catalogs optimized for specific user groups can be preset in the personalization settings. It is further possible to limit the navigation pane to catalogs only. If you do so, the appearance of the BRFplus workbench can be simplified significantly.

Access control

Catalogs can be used to simplify the navigation in the BRFplus workbench. Business experts are enabled to find their content quickly. Nevertheless, they may not be allowed to change all those objects. Especially objects like functions or technical expressions may be changed by technical experts only. To this end, authorization checks are available in BRFplus. Should you feel that this is still not sufficient or flexible enough for your use case, exits, such as the authorization exit, can be used. A separate document has been provided to explain how to use exits.

Decision service design and documentation

Finally, a very important topic is the documentation of decision services and business rules. I recommend using so called decision maps. A decision map is a high-level process description with a focus on the decision services involved. No separate tool is required for the creation of a decision map. Microsoft PowerPoint and comparable tools will do the job.

Decision maps show non-technical people where decision services are invoked. They are decision-centric, leaving out many technical implementation details. A decision map does not replace an architectural diagram or a business process model. These are, however, intended for technical experts.

For each decision service a separate document should be created that documents the decision service interface and implementation. I have created a template document that you may download and use.

Other interesting blogs I recently read about BRFplus

• Samir Pipalia, GOPA IT Consultants, BRFplus: Business Rules Processing in SAP TM
• James Taylor, Decision Management Solutions, The ROI of BRFplus

Configuration of the BRFplus workbench is an important feature of BRFplus. Especially for business experts, a simplified BRFplus workbench and easy navigation are required. In this blog, I would like to show you a few ways in which you can change the visual appearance of the BRFplus workbench.

The screenshots were taken in a system with NetWeaver 7.3 Enhancement Package 1 (which is equal to NetWeaver 7.0 Enhancement Package 1) and SAP NetWeaver Decision Service Management 1.0. The descriptions given apply to this release. However, most of the functionality described has already been available in a very similar form in older releases.

Content

• Configuration
• Preset configuration
• Object filter
• Catalog
• Embedded BRFplus UI

Configuration

By default, the Personalization dialog is enabled and can be opened with the respective toolbar button (highlighted in the picture below). If you want to disable it, please see the Preset configuration section below.

With the Personalization settings, the user interface can be customized according to the user’s needs. It is possible to show or hide technical features that make the UI look more technical or more business-oriented. You can control the behavior of the navigation panel objects, pre-set catalogs, optimize the UI for your screen size, and so on.

Preset configuration

Whatever you find in the Personalization dialog can be preset. In addition, the Personalization dialog as a whole can be hidden from the user. We call this configuration. It is a common pattern for simplifying the workbench for business experts in a way that technical features are switched off and the catalog navigation is the only means of navigation provided with a few predefined catalogs for navigation.

You can achieve this in the following way:

• Create a class that inherits from CL_FDT_WD_UI_SIMPLE_MODE. BRFplus supports two UI modes: Simple and Expert. You can define your own mode, which is just a combination of configuration parameters.
• Redefine method IF_FDT_WD_UI_MODE~GET_CONFIGURATION to set some of the configuration parameters

All interfaces concerning UI configuration are nested in the interface IF_FDT_WD_CONFIGURATION. For example, you can also control the button properties with it:

• Create a report or method to call the UI with your new configuration

In case of problems, check SAP note 1800571.

Object filter

With an object filter, you can define a subset of object types that should be available in a BRFplus application at design time. This helps you to ensure that for business rules of all kinds in an application, only those object types that can pass through the filter can be used. Especially, you can remove expression and action types that will definitely not be used by specific users or within specific use cases. Defining object filters as well as assigning them to user profiles is a typical administrative activity.

You create an object of the type object filter directly under an application. You need to specify two dimensions for each filter:

• Applications: A filter can either be applicable for all applications in the system, or for an individual subset of applications that you specify.
• Object types: Here, you define the object types that are available in the BRFplus workbench at design time. By default, all object types are allowed. If you change the scope to user-defined, you can deselect all the object types that you want to hide from the users.

Once you are done with the object filter definition, one last step remains: You need to add the filter to the Personalization settings of a user so that the filter-specific restrictions can take effect. To accomplish this, proceed as follows:

1. Open the Personalization dialog.
2. Navigate to the Filters tab and choose Add Filter.
3. Select the filter that you want to make effective.

You can add multiple filters simultaneously. If you decide to do so, the available object types are calculated as the intersection of the object types that are defined as "allowed" in all the filters that you have added.

Catalog

Catalogs can be seen as an alternative organization method for the business rule artifacts. While the repository shows the complete overview of objects organized in applications and objects, the catalog allows you to define any structure suitable for the target group, such as functional experts. Nodes can be enriched by attributes, and all terminology expected by the target group can be applied in structure nodes as well as object nodes. By this, the appearance of the BRFplus workbench can be simplified. In combination with a preset configuration, it is possible to hide other navigation options and present some predefined catalogs.

Embedded BRFplus UI

Sometimes, it is necessary to embed an original BRFplus UI (such as the decision table) into an application UI. This can be done easily. For details, refer to the paper Embedding a BRFplus Object in an ABAP WebDynpro Application. Although specifically written for an older version of BRFplus, all of the principles described still apply. The paper gives step by step explanations of how to embed an object and modify its UI.

The BRFplus API even allows you to build custom UIs as a replacement or an alternative to the BRFplus workbench. For a description of the API, see the BRFplus book.