Old BRF(Business Rules Framework) Implementation Strategy Guidelines

[florin_niculescu]

BRF Implementation Strategy Guidelines

Executive Summary:

Reason for such a blog expands with the need of maintainability of previous functionality whilst building a comprehensive solution with a higher degree of flexibility in terms of amendments for future releases.

Such a document should be followed in order to implement new business requirements that are to be in-line with a customer's blueprint and standard sap guidelines.

Please note: this blog refers to the old Business Rule Framework tool.

Benefits:

     - Faster knowledge transfer

     - Organised and easy to access rules portfolio

     - Lower implementation costs

     - Helps to define a migration strategy for business rules

     - Lower maintenance costs

Contact:

Active Global Support:
Florin Niculescu (florin.niculescu@sap.com) – Insurance Safeguarding Portfolio

Thus, the procedure for tackling:

     1. Need for maintainability

1. Brf rules belonging to a similar functionality should be bundled under a certain rule set. There shall not be objects that are used across multiple lines of business – hence it is better to recreate / copy, based on the lob guidelines for creating new objects
2. Each object created under brf should have comprehensive description and in case of expressions, actions, these should be referenced to the right place in the blueprint.
3. Custom tasks(activity management) are not to be created by hardcoding, this will render us without any trace of brf customizing – worst case scenario is that these tasks are belonging to a certain line of business process – meaning they will be grouped under a rule set with possible custom events and corresponding customizing in place for expressions and actions.
4. Shall avoid creation of objects of complex logic within a brf expression
5. Shall not raise tasks from expressions, using anomalies, but from actions
6. If old functionality needs to be amended – copy the necessary objects amend them and create new customizing in the rule set – do not remove the old objects logic from the rule set customizing – but deactivate them – reference each brf object with the new blueprint reference, usually based on it`s blueprint id
7. Technical documentation for BRF rules is to be maintained separately under a global technical document template designed for brf rules. Reference to it is to be specified in the technical specification of built functionality (rfc) and functional specification with corresponding references (like it is now)
8. When describing a brf functionality within a functional analysis try to use a formula like :

Ex.:  Segmentation Rules Template

OR/ AND	CONDITION 1	CONDITION 2	CONDITION 3	CONDITION 4	CONDITION 5	ACTION
RULE 1	X	x				set complexity to 8
RULE 2		x	x	x	x	set complexity to 7
RULE 3	X		x		x	Create log entry “L_CNooo”
RULE 4	X	x	x	x	x	Trigger task “T_CN ooo”
RULE 5	X	x		x	x	set complexity to 9
RULE 6		x	x	x	x	set complexity to 8

You can replace “Rule 1” with blueprint reference and “condition 1” with something like “risk file checked?” or “complexity < 7?” – Based on this approach we can easily devise dependencies, redundancies and take a fast decision on which objects are better to use for implementing the requirements

     2. Need for Migration to BRF plus

1. Use function modules when creating brf expressions, as much as you can. If this activity consumes a lot of time from an effort perspective and the logic of it is simple then you can make use of customising abilities of the tool.