Transporting changes through the system landscape is mandatory as soon as you create Business Rule Framework application with the system or customising storage type. There are some strategic decisions you need to consider before you use BRF+.

First, identify that BRF+ is based on object oriented programming. That means that you identify objects and identify attributes and methods.

A car is the most common example used in literature to explain object related programming. Where the car is the object, its attributes are the colour, number of wheels and the type of engine. The obvious methods are accelerating, braking and turning.

Within the SAP system you have other types of objects, such as sales order, production order, purchase order, customer, vendor, material and plant. Ideally each SAP object has its own Business Rule Framework application (transaction BRF+), development class (transaction code SE24) and message class (transaction code SE91) to establish a one-to-one-to-one relationship. This increases transparency and benefits transporting changes through the system landscape.

It is good practice to place the entire BRF+ application into a transport when a change is needed in any of its objects. Even the most miniscule change should trigger the transport of the entire application, as that is the only assurance that changes are transported successfully between systems. Applying this rule has as disadvantage that the entire application is locked for any other changes. Obviously deploying changes within an application need to be done as quickly as possible to avoid locking issues. Luckily BRF+ has very powerful simulation capabilities, allowing you to test in the development environment with production data. So you can already assess the result of your changes in the production environment before you release the transport.

Ideally you also build a custom set of structures and table types and construct an API between the SAP database and BRF+ functions. That ensures that the BRF+ signature components for the function is always associated to the SAP data dictionary. When you need to add new fields to a structure, then you can easily refresh the binding. This will have as a consequence that any change in the API must be in the same transport as the applications using the updates structures and/or table types. If you do not control these BRF+ application and and development class changes in the same transport then you could trigger system dumps.

Also important to understand that an introduction of a new BRF+ function can be deployed in several transports, but then the timing is important.

Imagine you want to add a new BRF+ function to support sales order processing. Then you can split this into two transports.

The first transport contains the changes made to the BRF+ application, development class and/or message class. You can deploy this as soon as possible.

The second transport contains the change in the code that is calling the BRF+ function, by using a new method in the development class. You can deploy this days, weeks or even months after the first transport.

Applying this guideline, new BRF+ functions can be introduced in a production environment but remain dormant as long as there is no program calling this BRF+ function.

All these suggestions will ensure that the introduction of BRF+ in your organisation is gradual, easily to control and without any bumps along the way.