Implement a functionality in the system that creates a decision table (including its вЂњsurroundingsвЂќ like application, function etc.) in background for each master policy and make it available for the UI.For this topic I want to refer to the corresponding document available here in SCN: Enhance the UI of the policy management application in order to allow the user to display and edit the data in the decision table.So a possible the solution for that scenario consists of two tasks: The user does not want to switch from the master policy management application to the BRF+ application in order to enter the data of the master policy.No Decision Service Management is available.The premium conditions are entered on the productive environment after the negotiation between the insurer and the insured company has been concluded.Even this simplified description leads us to the point that a decision table might be a very good choice to tackle the scenario. for a car with less than 1.5 tons and a performance of 80 kw you pay a premium of 250 в‚¬. Let us use the following very simplified example for such a table:Д®ach insured car finally gets one single policy issued with the premium corresponding to the properties of car and the agreement in the fleet master policy e. This basis depends on certain properties of the cars to be insured.

Usually the insured company pays a certain premium per car and the basis for the premium calculation is written down in the master policy. Within these master policies the insurer and the insured company agree on the insurance of the company cars. a decision table) into an existing application so that the user is not even aware of using the BRF+ but on the other hand still being able to use all the nice features of the artefact.Д«efore the story gets a little bit too theoretical I want to introduce a business scenario where this approach can be used.ДЄs my background is the field of insurance so is my scenario: Let us assume we have a SAP module (like SAP Policy Management) that allows you to manage master policies more specific the fleet master policies. This approach might also be of favor when you want to (deeply) integrate an artefact of the BRF+ (e.

So this might be right time to switch to a generative approach using the BRF+ API. Now you might say that a master data application might solve the issue but that one is not intended to be transported except for the XML export and import functionality which might not be the preferred way of your IT operations team. This can get quite tricky and is not the best way to go. There is a workaround by using an application exit but then you really have to take care on the synchronization process between the development and the productive system as those applications are still part of the regular transport process.

One example is the maintenance of the rules on the productive environment when DSM is not in place, In case you are using BRF+ applications of storage type S or C your system settings will usually prevent their maintenance on the productive system. The answer is: There are scenarios where the BRF+ workbench cannot be used for the maintenance. The first question that might arise up to now is: Why should I use an API if I have the comfort of the BRF+ workbench with its quite usable Webdynpro UI? A comprehensive description of the API can be found in the book BRFplus вЂ“ The Book of Carsten Ziegler and Thomas Albrecht. This blog shall introduce you into some basic usage scenarios of the API. But there is also another way to get these things done namely the BRF+ API.

Many questions and descriptions here in SCN focus on the usage of the BRF+ via the workbench as interface for the creation and maintenance of objects of the BRF+.

Api 613 latest edition of dsm