SAP BRF+: business rules out of custom code.

What is BRF+, in plain words?

BRF+ (Business Rule Framework plus) is SAP's own tool for business rules, built in ABAP and part of the ABAP platform underneath SAP ECC and S/4HANA. It lets you model a business decision, such as whether an order may proceed or which output a customer gets, as visible rules instead of burying it in custom code.

The people closest to the business can see the rule, simulate it, test it and change it, often without another development cycle. Developers still provide the engineering around it: getting the data in, and acting on the result. Use code to perform a technical task. Use BRF+ to make the business decision.

Why has nobody told me about BRF+?

Because custom development is the consensus, and BRF+ is a decision. Nobody needs courage to propose another piece of ABAP when that is how the organisation has always solved the problem. BRF+ needs someone to suggest it, understand it well enough to defend it, and explain why the familiar route may no longer be the best one.

There are the usual explanations as well: skills, architecture, performance, support, an implementation partner that never proposed it, management that does not want another technology. And "we've always done it in ABAP". SAP created BRF+ for SAP and uses it in its own S/4HANA functionality. It is there for you too. Nobody told you.

Can BRF+ help me keep a clean core?

It helps, but it is not a magic clean core button. The objective is not simply less code running in SAP. It is owning less bespoke code. There is a difference between carrying bespoke procedural code into S/4HANA and carrying business rules maintained in SAP's own rule framework.

You do not have to wait for the S/4HANA programme either. BRF+ is available in ECC, so suitable decisions buried in ECC custom code can move into BRF+ before the transformation. That improves ECC today and shrinks the pile of custom logic the transformation has to understand later. Don't wait for the S/4HANA transformation to discover which custom code you shouldn't be taking with you.

Can business users really change rules in Excel?

Yes, with control. BRF+ decision tables can be exported to Excel and filled by importing a spreadsheet again. That reverses an old SAP habit: data used to go from SAP into Excel; now rules go the other way, and BRF+ shows which rule SAP applied.

Two things to know. The import replaces the contents of the decision table rather than merging into it, so the spreadsheet must hold the complete table, not just the changes. With versioning switched on, the previous version is kept: nothing is lost, and you can see what changed and when. And it is not a licence for uncontrolled spreadsheets straight into production: authorisation, testing and release control still apply. Where the spreadsheet is the functional requirement, keeping one version of the rule beats keeping two that drift apart.

Is BRF+ included in the SAP licence?

BRF+ is part of the ABAP platform underneath ECC and S/4HANA, and it is generally understood to come with it, without a separate BRF+ licence. As with anything contractual, check your own SAP agreement if it matters.

SAP Decision Service Management (DSM) is different. DSM sits on top of BRF+ and adds central management and deployment of rules across systems, including productive ones. DSM is a separately licensed add-on.

When should I not use BRF+?

When the task is technical rather than a business decision. Solve any problem does not mean build everything in BRF+. BRF+ works well for complex decisions; anything else, custom code can do just fine. And sometimes a complicated BRF+ construction can be replaced by a single ABAP statement. Then let BRF+ call that bit of ABAP.

The useful question is not "how do we safely modify this old development?" but "which custom code is easy and stable, and which is not?" Stable technical code can stay. Decisions that keep changing, or that nobody can explain any more, deserve a better home.

Who does what: developers or functional consultants?

Developers handle the input and output. Consultants configure the rules. A common trap is to discover BRF+ and hand it to the developers, when functional consultants are the people already translating business requirements into SAP.

A better order: the consultant models the rule in BRF+, prototypes it with the business and gets it signed off before a line of code is written. Then the developers decide where to call BRF+ in the process and how to handle the outcome. The journey shrinks from business, consultant, specification, developer, code, test, deploy to business, consultant, business rule, test, deploy.

What is a business rule management system?

A business rule management system keeps business decisions outside the application code, where people can find, change and test them. It has three parts. The authoring environment is where rules are written and maintained, ideally with simulation, gap and conflict checks. The repository stores the rules, with versions, access control and change history. The rule engine runs the rules when an application asks, and it needs to be fast.

BRF+ is SAP’s business rule management system for ABAP. The workbench is the authoring environment: the user interface where rules are built, simulated and checked. Rules are grouped in BRF+ applications and stored in BRF+’s own repository, with versions and change history. When a program calls a BRF+ function, the rules run as generated ABAP code, which is why they are fast.

What is a decision service?

A decision with a clear interface: defined inputs go in, defined results come out. The application calls it, receives the answer and decides what to do next. In BRF+, the function is that interface. The pattern keeps the decision replaceable: you can improve the rules without touching the calling code, as long as the input and output remain unchanged.

The usual alternative is the decision buried in the application: custom code reading custom tables to decide what happens. It works, but the decision has no interface of its own. The logic is spread across programs, the tables only make sense to whoever built them, and changing a rule means a developer, a transport and a retest of the code around it. A decision service gives that decision a front door.

What is shadow mode?

Running BRF+ alongside the existing solution, on real transactions, without letting it decide anything. The custom code stays authoritative. BRF+ evaluates the same documents and records what it would have decided. It is an approach, not an SAP setting, and it comes in two forms.

In parallel: a separate program runs BRF+ and compares its results with the custom code. Business as usual is not touched, so start here.

In the process: once you trust the results, a developer calls BRF+ from the live process after the custom code has run, and logs every disagreement.

Each disagreement is a lead: incomplete rules, an incomplete requirement, or old code doing something nobody realised. Cut the custom code out only when shadowing shows BRF+ is accurate and complete for its full scope. Trust first. Deployment second. Savings third.

Inside the process, set the log action to persist messages, and keep Send Email, Start Workflow and Workflow Event out of shadow rules: they commit to the database, including whatever the calling program had pending.

How do I keep big decision tables fast and readable?

It is the obvious question a manager asks first, and a fair one. First ask how useful a table with hundreds of rows is for controlling a decision anyway. Split it by organisational unit, such as sales organisation or company code. Each unit has its own person maintaining the values, so give each its own table; that also makes clear who may change what.

Still more than about 100 rows? BRF+ reads a decision table sequentially, from top to bottom. So apply the 80/20 rule: put the most frequently matched rows near the top. Specific rows must still come before generic ones, because by default the first matching row wins. Keep each table small enough for its owner to read. BRF+ will read it faster too.

Decision tables are the visible concern, but rarely the biggest danger to performance. Watch these more closely:

• Interpretation instead of generated code, forced by a technical trace, a dynamic expression or a custom expression type that cannot generate code.
• Database lookups, above all inside loops. Read once beforehand, or let the calling program pass the data in.
• Remote calls, by RFC or web service, instead of local calls.
• Comparing amounts or quantities in different currencies or units, which triggers a conversion every time.
• Committing actions such as Send Email or Start Workflow in a high-volume path.

What are the building blocks of BRF+?

Everything lives in an application, the container for one set of rules. Inside it:

• A function is the interface your program calls. Its context is the input; its result data object is the output.
• Data objects describe the data: elements, structures and tables.
• Expressions do the deciding and calculating: decision tables, formulas, Boolean conditions, database lookups and more.
• Rulesets group rules. A rule is an If, Then and optional Else.
• Actions do something rather than return a value: log a message, send an email, start a workflow, call ABAP.
• Catalogs give business users a tidy view of the objects that matter to them.

Your ABAP program fills the context, calls the function and acts on the result. BRF+ does the deciding in between.

What is a BRF+ application?

The application is the container for all BRF+ objects that belong to one set of rules: functions, data objects, expressions, rulesets, actions and catalogs. The key choice is its storage type, because it decides how the rules reach production, and it cannot be changed afterwards.

Normally, BRF+ is treated as configuration: a customizing application, client-specific, moving through the landscape in a customizing request like any other configuration.

If you need global definitions that other applications reuse, such as a standard message structure, put them in a separate system application, which is client-independent and moves in a workbench request.

When decisions depend on codes that differ per system, such as material, customer or vendor numbers, use a master data application. It is never transported: you move it between systems by XML export and import.

What is a BRF+ function?

The function is the rule interface: the object your application code calls. Its signature has two parts. The context holds the input data objects. The result data object holds the output. The input can consist of a selection of elements, structures or tables. The output can either be a single element, structure or table.

As long as the input and output remain unchanged, whatever happens inside the function does not require a developer.

A function runs in one of three modes.

• Functional mode: the function processes the dedicated expression, for example a decision table, and returns its result.
• Event mode: the function processes rulesets in order of priority. Each ruleset can have multiple rules that also have an order.

What are data objects in BRF+?

Data objects describe the data BRF+ works with. There are three kinds: elements (a single value), structures (a group of elements) and tables (rows of a structure). An element has one of six types: text, number, Boolean, amount, quantity or timepoint.

Data objects can be bound to ABAP Dictionary types, such as data elements, structures and table types. That is usually the smart move: BRF+ reuses the definitions, value checks and descriptions your system already has, and the handover between your ABAP code and BRF+ stays simple.

What is an expression in BRF+?

The transformation of BRF+ input into a result is achieved by using expressions.

An expression is a reusable piece of logic that takes input and returns an output. Expressions can be nested, so one decision table can use a formula, which can use a table operation.

The standard expression types include:

• Constant, range and value range: fixed values and value checks.
• Boolean: combines conditions with AND, OR and NOT.
• Case: compares a value against test values, like an ABAP CASE.
• Decision table and decision tree: rows or branches of conditions leading to results.
• Formula: calculations, with built-in mathematical, character string, date and time, table, system and miscellaneous functions.
• DB lookup: reads database tables, including existence checks and aggregation.
• Table operation: counts, sorts, totals and similar operations on a table.
• Loop: repeats rules for each table line, a fixed number of times, until a condition holds, or while it holds.
• Function call and procedure call: call another BRF+ function, or ABAP function modules and public static methods.
• Search tree, random number, dynamic expression, XSL transformation and BRMS connector for special cases.

If the standard set is not enough, you can build your own expression types.

How does a decision table work?

A decision table has condition columns and result columns. Each row says: when the inputs match these conditions, return these results. BRF+ checks the rows from top to bottom, and an empty condition cell counts as "any value".

• By default, the first fully matching row wins. Specific rows must therefore come before generic ones, or the generic row will catch everything first.
• With the setting "Return all matches found", every matching row is returned. The result data object must then be a table.

BRF+ checks a table for overlapping rows and for gaps, combinations of inputs that match no row at all, when you maintain it. By default these checks give warnings; each can be made an error or switched off. Tables can be exported to Excel and imported again, as long as the cells hold direct values and ranges rather than references to other expressions. The import overwrites the table contents.

What is the difference between a decision table and a decision tree?

A decision table lists combinations as rows, checked from top to bottom: ideal when the same few inputs decide the outcome and the business wants to maintain the values, possibly in Excel.

A decision tree asks one condition at a time and branches to the next, with a result at each end: easier to read when the questions depend on earlier answers.

Which to choose depends on the shape of the decision, not on fashion. If the business thinks in a grid of values, use a table. If they think in a sequence of yes-or-no questions, a tree tells the story better.

What happens when no row in a decision table matches?

By default, a decision table that returns a single row raises a processing error when nothing matches, and the function call fails. The setting "Return an initial value if no match is found" avoids the error, but then your program must cope with an empty result. When you configure the table to return all matches, no match simply gives an empty table.

A cleaner habit is a last row with no conditions at all, which catches everything else and acts as the deliberate default. Remember that an empty condition cell means "any value", which is not the same as testing for an empty value. The gap check shows the combinations nobody covered.

How do I return several values from a BRF+ function?

A function has exactly one result data object, so make it a structure when you need several fields, or a table when you need several rows. A decision table with several result columns returns them as a structure. In event mode the caller can also read context values back after the call, because the rules can change them. Each data object can appear only once in the signature, so the same object cannot be both input and result.

How does BRF+ handle amounts and quantities?

An amount is always a number plus a currency, and a quantity is always a number plus a unit. Pass both together, ideally through a dictionary structure that holds the value and its reference field. Decimals follow the currency settings in the system.

Comparing amounts in different currencies, or quantities in different units, triggers a conversion first, which costs time. Currencies and units are client-dependent customisation, so a value defined in a client-independent system object may not be valid in every client. A quantity element can also be limited to one dimension, such as mass.

What can a DB lookup do, and what can it not do?

A DB lookup reads database tables from inside a rule. It can read one row or several, aggregate one column (minimum, maximum, average, sum or count), or simply check whether a matching row exists. Conditions on different columns are combined with AND, conditions on the same column with OR.

Its limits: no conditions on amount or quantity columns, no comparing one column with another, and fewer text operators than ABAP. Maintaining a lookup needs table authorisation. And mind performance: a lookup inside a loop reads the database again and again. Read once beforehand where you can, or let the calling program pass the data in.

Best practice is to avoid DB lookups as it can have a negative impact on system performance. Instead, provide the necessary potential information as a BRF+ function input table.

What is a ruleset, and what is a rule?

A ruleset is a container of rules, assigned to a function that runs in event mode (or functional and event mode), and it sees the function's context. A ruleset can have a precondition, so it only runs when that condition is true, and an on and off switch. Its priority sets the order between rulesets: 1 runs first and 99 last, while 0 means no priority and an arbitrary order. It can hold variables for intermediate results, which the calling program cannot see, with initialisation expressions to fill them. Between the rules you can place exit conditions that stop the ruleset early. Each rule entry can be switched on or off and given its own validity period.

A rule is the smallest piece of decision logic: If a condition holds, Then do something, Else optionally do something else. A rule without a condition always runs its Then branch. Then and Else hold an ordered list of steps: assign or initialise context values, process an expression, perform an action, or run another rule. A rule usually lives in a ruleset, but it is an object in its own right and can be reused.

How do I stop a ruleset early?

Place an exit condition between the rules. Rules run from top to bottom, and when an exit condition is true, the rest of the ruleset is skipped. A typical pattern: set a default, test a specific case, and exit when the answer is settled.

If the application allows deferred ruleset processing, an exit can also save the state, including the context values, so that the ruleset restarts later, either before or after that exit. That suits situations where data is still missing, or where the remaining work is better left to a background job.

What are actions in BRF+?

Actions do something rather than return a value. They can be chained to follow-up actions. The standard action types are:

• Log message: writes information, warnings or errors to the SAP application log (transaction SLG1), but only if the action is set to persist its messages. Otherwise they stay in memory.
• Send email.
• Start workflow, and raise a workflow event.
• Procedure call: calls ABAP, such as a public static method or function module.

Actions are triggered from the Then or Else branch of a rule, and also from a decision table's action column, from case expressions and decision or search trees with an action as result, and from loops. One caution: Send Email, Start Workflow and Workflow Event commit to the database. The log message action does not, which makes it the workhorse for shadow mode and audit: if you model it to, every decision leaves a readable trail of what BRF+ decided and why.

What is a catalog in BRF+?

A catalog gives business users their own entrance to BRF+. Instead of the technical workbench, they see only the objects that matter to them, usually decision tables, arranged and named in their own terms. From there they can maintain the rules themselves, including downloading a decision table to Excel and uploading it again, without going inside the workbench.

A catalog is a view, not a security boundary. What each user may display or change is controlled by BRF+ authorisations, which check the application, the object type and the activity. Set both up together: the catalog makes it easy, the authorisations make it safe.

Which transactions open BRF+?

Transactions BRF+, BRFPLUS and FDT_WORKBENCH all open the same BRF+ workbench, a Web Dynpro application in the browser. FDT_HELPERS opens a collection of utilities. The FDT prefix comes from BRF+'s origin as the Formula and Derivation Tool, which is why its classes start with CL_FDT and some of its transactions with FDT. To use the workbench, a user needs the right authorisations, and SAP delivers an administrator role, SAP_BC_FDT_ADMINISTRATOR.

Do not confuse it with transaction BRF, which opens the old Business Rule Framework. That predecessor is obsolete: in S/4HANA you cannot create new BRF application classes, and SAP's advice is to convert BRF applications to BRF+.

Does every BRF+ object need a name?

No. Applications, functions and data objects always need one. Rules, expressions and actions can stay unnamed, and then they can only be used where they were created and disappear with their parent. Naming an object makes it reusable, with a life of its own, and that cannot be undone.

Application names are unique across the system, so use Y, Z or your own namespace. Give every object a short text and, where it helps, a longer text and documentation. And think before renaming objects that code already calls. Naming conventions are cheap at the start and expensive to introduce later.

What does an object's access level do?

The access level decides which other objects may reuse a named BRF+ object. It ranges from the same application only, which is the default, through wider levels based on SAP's application component hierarchy, up to global. The rule of thumb: as narrow as possible, as wide as necessary.

Never narrow the access level of an object already used in production, because the objects that depend on it can become inconsistent. Storage type limits reuse as well: a transportable object cannot use a local one, for example.

How does an ABAP program call BRF+?

Usually through the static method PROCESS of class CL_FDT_FUNCTION_PROCESS, which is the fastest way. The program passes the function's ID (a GUID), optionally a timestamp, and the context values, and receives the result data object back. Without a timestamp, BRF+ uses the latest active versions. Errors are raised as exceptions of class CX_FDT, with subclasses that separate input, system and processing errors.

You do not have to write that call from scratch. In the workbench, switch the user mode from Simple to Expert, then on the function choose Create Code Template: BRF+ generates ready-made ABAP for that function. Use the same timestamp for all calls in one processing cycle. Other routes exist, an instance-based API, a generated RFC function module and a generated web service, but they are slower. All of them run the same generated code, so the calling program does not change when the rules do.

Can I call a BRF+ function as a web service, or from another system?

Yes. A tool in the workbench wraps a function in a generated RFC-enabled function module and, if you want, a web service on top, configured afterwards in SOAMANAGER. The function needs a flat signature, because remote calls cannot carry deeply nested structures, and the wrapper must be regenerated if you change the signature incompatibly.

Rules can even live in a separate system that business systems call remotely, which also suits non-ABAP callers. The price is network overhead and extra integration work for value checks and help. Most landscapes keep the rules local, transported with the process they serve: faster, and simpler.

Can BRF+ be extended without modifying SAP code?

Yes, at several depths. Procedure calls let rules use your own static methods and function modules. Application exits, an ABAP class assigned to an application, can tighten authorisation, add consistency checks, block activation, react to changes and open customising objects for change. You can add your own formula functions, and even build your own expression and action types.

Check that custom types support code generation. If they do not, they force the slower interpreted mode for everything that uses them.

Is BRF+ slow?

Not when it is used sensibly. BRF+ generates an ABAP class for each function and runs that generated code, which is many times faster than interpreting the rules. Generation happens automatically on the first call and again when a used object changes, manually from the function, or in bulk with report FDT_GENERATE_MANY_FUNCTIONS. After importing into production, regenerate, so the first business user is not the one who pays for it.

The real costs sit in a few places: anything that forces interpretation (a technical trace, a dynamic expression, a custom expression type that cannot generate code), database lookups, especially inside loops, remote calls instead of local ones, and comparisons of amounts or quantities that trigger currency or unit conversion. Design matters more than the engine. BRF+ does not make a badly designed rule fast, just as ABAP does not.

How do I test a BRF+ rule?

With the simulation tool, started from the function in the workbench. You enter context values, run the simulation and see the result and, if you ask for it, the intermediate steps behind it. Test cases can be uploaded from Excel and run in one go, with the results exported to Excel, as long as the context contains no tables. Only the latest active version of a function can be simulated, so activate first. Newer releases let you choose between interpretation and generation mode.

That is one of BRF+'s biggest practical advantages: a functional consultant can test a rule with the business before any ABAP calls it. Simulation does not replace testing in the real process, though. Shadow mode on real transactions shows the combinations that workshops never thought of.

How can I see afterwards which rule BRF+ applied?

Three tools help.

• The lean trace is designed for production audit. The calling program switches it on and must save it explicitly, otherwise nothing is stored. It records only what is decisive and rebuilds the rest from object versions, so it really needs versioning switched on. The default trace table is purged automatically after five days, so long-term audit needs its own trace table. Dynamic expressions cannot be lean traced, and access to traces has its own authorisation object, FDT_TRACE.
• The technical trace is for debugging during development and simulation. It forces interpretation and lives in memory only.
• Log message actions, set to persist, write your own readable messages to the SAP application log.

That is the answer to the auditor's question: which rule applied, what information was considered, and why a transaction passed or failed. Traceable, and quick, if you planned it.

How does versioning work in BRF+?

Versioning keeps earlier states of BRF+ objects, so you can see and use a rule as it was at an earlier point in time. It is set per object, with defaults at application level: off, on by default for the objects that affect processing, enforced for those objects, or triggered by transport.

For anything that matters in production, enforce versioning at application level. It answers the question "who changed what rule in this decision table?", and it keeps the lean trace meaningful.

Can BRF+ run a rule as it was on an earlier date?

Yes, if versioning is switched on. Each activation then creates a new version, valid from its activation time until the next one. When a function is processed with a timestamp, BRF+ uses the versions that were valid at that moment; without a timestamp it uses the latest ones. That supports audits, reprocessing old documents and explaining past decisions.

Rulesets and rules can also carry validity periods for planned changes. Switch versioning on for the referenced objects too, or a change to an unversioned part quietly alters the history.

Does BRF+ commit to the database?

BRF+ itself does not commit while it processes, but some actions do. Send Email, Start Workflow and Workflow Event commit, and with them anything else the calling program had pending. Log message does not commit, and a procedure call depends on the code it calls.

If your program may need to roll back, keep committing actions out of that path, or run them after your own commit. That is one reason why decisions that act on their own belong in the hands of someone who understands the transaction they run in.

How do BRF+ rules get to production?

That depends on the application's storage type.

• System: objects travel in workbench transport requests.
• Customizing: objects travel in customizing requests; whether changes are recorded depends on the client settings. They arrive in client 000 of the target system and may need copying to other clients.
• Master data: objects are not transported at all; they are maintained directly in each system and client.

A transport only releases when its objects are active, consistent, not locked, and complete with the objects they depend on; report FDT_TRANS_MASS_CHECK checks in bulk, and FDT_TRANS writes a complete application to a transport. After import BRF+ activates the objects itself, without downtime. There is also an XML export and import, which moves objects outside the transport system. Define a release route matched to risk: a low-impact rule does not need the same controls as one that can stop invoicing.

A BRF+ transport failed on import. What now?

Read the transport log first. Return code 12 points to a temporary problem, such as a lock, and BRF+ retries by itself. Return code 8 is a permanent error: the objects stay inactive and the import waits in a queue.

The usual cause is something missing in the target system, often not a BRF+ object at all: a dictionary type, an ABAP class, a table or an application log object. Transport the missing piece, then restart the import with the transport analysis tool or report FDT_TRANS_Q_RESTART.

Can rules be changed directly in production?

Not by default, and that is deliberate. There are several routes, each with consequences.

• Master data storage type: content is maintained per system rather than transported, which suits rules the business owns in production.
• A production-only ruleset with master data storage can be attached to a transported function. The transported rules hold the defaults; the production ruleset, with its priority and precondition, handles the exceptions.
• The changeability exit of an application can open selected customizing objects for change in production. Changes made there must be aligned back to development, or the next transport or client copy will overwrite them.
• SAP Decision Service Management (DSM) is SAP's managed route for changing and deploying rules in productive systems. It is licensed separately.

Whichever route you choose, versioning, authorisation and testing still apply. Changing a rule in production is still changing production.

Where does SAP itself use BRF+?

In more places than most people notice. The best-known example is S/4HANA output management: output parameter determination uses BRF+ decision tables to decide output type, recipient, channel, printer settings, email settings, email recipient, form template and output relevance. SAP Master Data Governance uses BRF+ for rule-based workflow and for checks and derivations. SAP Transportation Management uses it widely for conditions, and it is used heavily in Tax and Revenue Management.

A common misconception concerns the standard flexible workflow for purchase requisitions and purchase orders: as far as can be confirmed, its conditions are not BRF+. They use workflow pre-conditions and BAdIs.

How do I find where a BRF+ object is used?

For relationships between applications, use the application usage tool: it shows which applications an application borrows from, and which ones depend on it, for the latest version or as of a chosen moment. It also warns when something you use is marked for deletion. For single objects, the utilities show who uses an object and what it uses itself.

Check usage before changing or deleting anything that other applications are allowed to reuse. The surprise is always in the application nobody remembered.

How do I clean up unused BRF+ objects and old versions?

With the application administration tool. It finds named objects that nothing references and deletes them, removes objects that have been marked for deletion longer than a chosen period, and discards versions older than a chosen number of days. Deletion is logical first, and physical removal follows later.

Run it in test mode first, because physical removal cannot be undone, and keep the authorisation for this tool tight. Discarding old versions also discards your ability to explain old decisions, so align it with your audit requirements.

How do I start learning BRF+?

In a safe place: a sandbox or test system, with a local application that nobody needs to transport. Build a small function with one decision table, simulate it, then call it from a few lines of ABAP using the generated code template.

Make it a game. Pick something everyone understands regardless of SAP experience, such as the decisions in a penalty shoot-out. Build something that works, then deliberately change the rules and see how quickly you can follow. That is the point of BRF+: being ready when the target moves. Learning is the investment; the saving comes after.

Which SAP release do I need for BRF+?

BRF+ is part of the SAP_BASIS software component, so there is nothing to install. The first unrestricted release was SAP NetWeaver 7.0 enhancement package 2 (SAP_BASIS 702); earlier releases had a restricted or pilot version. Transactions BRF+ and BRFPLUS arrived with that release.

Any ECC 6.0 system on a reasonably current enhancement package, and every S/4HANA system, is well beyond that. Newer releases added features over the years, so a feature you read about may depend on your release. To check a system, look at the SAP_BASIS release under System, Status.

What lifecycle does a BRF+ object go through?

Every change starts as an inactive version. You can save it while it is still incomplete, but it never runs. Activation checks the object and makes it the version that is processed.

When an object should no longer be used for new work, mark it obsolete: existing uses keep working, new ones are blocked, and you can reverse it. Objects can also be marked for deletion and cleaned up later by an administrator. Deletion is logical first; the object disappears from view but stays in the database for a while before it is physically removed. Only active, consistent objects can be transported.

How is access to BRF+ controlled?

Through standard SAP authorisations. The authorisation object FDT_OBJECT checks the BRF+ application, the object type and the activity: display, change, create, activate or delete. Access to the workbench tools and to traces has its own authorisation objects, and SAP delivers an administrator role, SAP_BC_FDT_ADMINISTRATOR.

Changeability also depends on the storage type and the client settings, which can forbid changes or force transport recording. For finer control, an application exit can add your own checks. Catalogs simplify what users see, but they secure nothing on their own.