BRFPlus Transports - Ability to maintain Decision table entries in PRD

[Former Member]

Hi BRFPlus gurus,

We are using BRFplus rules in place of customizing tables to maintain some of our business rules.

The way I want to see this working is.

1) Define Application, Function, Expression (decision table), Data objects in Dev - maintain some test entries in decision table in dev to test.

2) Transport all the objects created in step 1 except decision table entries to QA and evntually to PRD.

The problem that I am facing is.

1) When I create an application I get to choose Storage Type: System, Customizing or Master Data.

I choose Customizing and that way the application and all the underneath objects get included in the customizing transport and is transportable. What I am not sure is how to exclude decision table entries from the customizing transport.

2) In Target systems (QA/PRD) we are not able to maintain any object, including decision table entries. We want users to be able to maintain decision table entris in target systems.

How can this be achieved? Is this even possible?

Also I will appreciate if someone can help me understand storage types (System, Customizing or Master Data) with examples. I see that if 'Master Data' type is used objects cann't be transported. If 'System' type is used, BRFPlus GUI screen exits while trying to enter transport number and Save. Customizing type is the only type I was able to use for my scneario, but I was not able to exclude decision table entries from the customizing request.

I will appreciate any ideas.

Thanks,

Saurabh

[Former Member]

Hi Carsten,

As always, thanks for your help.

Can I please ask you why the steps below will not work with EHP1? Is that because in target systemsBRFPLus it would not let me change the decision table?

1) Create an expression (decision table) and corresponding objects (application, data objects, etc.) as a Master Data Object in DEV.

2) When Completed, Add these objects to a 'Transport' and move it to target systems.

3) In Target systems (QA, PROD), create constant expressions for decision table cell values, and add those expression in decision table cells.

Thanks,

Saurabh

[fred_verheul]

Hi Saurabh,

I don't know if you're still interested (may be anyone else?), but I think I've kinda solved this problem for 7.01.

As Carsten already said, you can define the 'static' objects as customizing (or system), and the objects that need to be changed by the business as local objects.

In order to do so you have to start with 2 applications: one customizing/system application, and a master data application.

In the cust.application you create the functions and data objects.

Important considerations:

1. Don't forget to set the access level of all these objects to global.

2. All functions need to be in event mode (to loosely couple the function and the rulesets).

3. The data object that you normally would set as a result object of the function needs to be added to the context.

In the master data application you create the rulesets, rules, actions and expressions like (in my case) a decision table.

Make sure you subscribe the rulesets to the right functions (which is possible since the functions have a global access level).

You can then transport the cust.application and underlying objects to PRD like you would do normally, and you can export from DEV and import to PRD the master data application + underlying objects.

Result: the business users can change the decision table entries (even the structure, but if you don't tell them, they won't ).

Best regards, Fred

[marioaerts]

Hi,

I have a cust. application which contains the data objects and function and are transportable. In a masterdata application I have  a ruleset linked to the function so business users can edit them directly in production.

If I try to XML Export/Import this masterdata application there is a problem when I try to import this application into my acceptance and prod system. There is a message error indicating that the package in which the master data object is residing is not editable (although it is a local development package) and the import fails.

How can you get these masterdata applications in acceptance and prod systems? How did you guys resolve this issue?

Kind regards,

Mario

[carsten_ziegler]

This must be a quite old release. At some point in time this check has been relaxed. Maybe check for notes. Or create an OSS message. You may comment into the OSS message my comment. This could help the colleagues.

[Former Member]

Thank you for this great step by step explanation. I intend to deliver many applications to customers in this method. This is essential instruction for anyone using a master data application to be called from ABAP application enhancements. The code in the enhancement needs to call a system application whose interface must be consistent in all environments, while the user maintained data and rules need to be application level to give them the freedom to change their rules.

I found another alternative that might make the development and transport easier. In the application exit class, you can define a customizing application as changeable and not recorded. IF_FDT_APPLICATION_SETTINGS~GET_CHANGEABILITY enables you to setup the rules and expressions as customizing in development system and transport them easily to ensure they are transported as tested. The XML download/upload works well too, but this is just another option that might be better in some cases.

[paul_pendleton]

Fred,

I know this post was a while back for you but I have a question for you.  How did you get your local BRF+ application to the production system?  You stated in your post that you created your functions and rules etc in a customizing/system application set to global access.  Then you said you have your decision table in another application as local.  I'm just wondering how you are getting the local app to prod.

Does that require certain access to get it there?  I know this is coming out of the blue but this is a big issue in our BRF+ design.  They have user exits you can use to allow certain objects to be changed on different systems however that is EPH 7 enhancement pack 2 and we are not there yet.  Not sure I really like that option anyway but I will wait if that is better.  Do you have any input you can share with me on this?

[former_member190447]

In the "old days" when Fred posted his comment you had to use SAP transportation management to transport all BRFplus objects from your DEV system to QAS or PROD. Now with SAP NetWeaver Decision Service Management you can just perform a hot deployment from DSM system (central designtime system) to all other systems in your system landscape. This deployment can be handled by any business user, it is being executed within seconds, and it does not involve waiting for the next transport cycle or system downtimes.

[hardyp180]

I just want to clear up what seems to be a common misconception.

In a lot of the articles about BRF+ it is claimed that moving a customising or ABAP transport from QA to production involves "system downtime" i.e. you have to switch your production system off to get a transport into it.

That is simply not the case. We do transports into production with the live system still going, at a time of low activity of course.

In fact, can you do a transport into a system that is down? Or are people talking about forcibly logging out all the users first?

The other common misconception is that companies want to pay money for an extra system with extra hardware and what have you, when they already have BRF+ in their system for free.

I currently can set up a Z table to be directly maintainable in production. I wanted to use BRF+ because it was better, but it can't do it. The only reason I got permission to use BRF+ in the first place was because it was free. I couldn't go back and say "oh in fact we have to shell out a load of money on a new system".

Cheersy Cheers

Paul

P.S. I am a big fan of BRF+ by the way, for situations where the rules don't change during the day, it's the bees knees.

[carsten_ziegler]

Hi Paul,

You do not need another system but you can reuse other systems (eg another client). So no Dollars need to be spent on Hardware.

Concerning transports: Technically,you do not need a downtime. However, transports are usually imported when users are not working productively. This is a safety mechanism as it is not clear how processes/applications behave on changed customizing (memory, DB). Also, I often could observed lengthy and political discussion between teams when one team wants changes to be transported and the other team resposnible for the system wants to limit the number of changes and disruptions by transports. That is finally what made us invest heavily into DSM.

Regards,

Carsten

[paul_pendleton]

Thanks guys.  I have not heard of DSM but will look into it.  Paul I agree with you about BRF+ it has a lot of functionality in it.  It would be way more useful if we could for instance create our decision tables so that they can be maintained on any system  Just like we do z-tables and tvarv today.  We are trying to replace the z-tables and tvarv with BRF+. However, without being able to design a BRF+ application that will allow the super user to change values on any system for specific objects we still have what we have today.

I know in enhancement EPH 7 enhancement pack 2 we do have a user exit we can use to allow this to be done.  Though I will take what I can get so this is an option but we are not on EP 2 yet!! I really think this defeats the purpose of BRF+(at least what I thought it was to be).  We are on enhancement pack 1 by they way.

I'm still learning BRF+.  Fred Verheul had mentioned that he created a local application on the dev system and was able to use that with a customizing/system application on prod.  This allowed them to maintain it on prod.  So I was hoping to find out how he got the local app to prod.  Maybe the DSM is the answer.  But I'm still skeptical if the local app will work with the customizing app.  What I have read says this will not work.

We are trying to get some kind of standard setup so we can use BRF+ exclusively for business rules.  Just have to get around this limitation of having to always transport changes that might change on a daily basis.

Thanks again everyone.

[carsten_ziegler]

Paul,

I like to offer you a call/webex to discuss.

Regards,

Carsten

[Former Member]

I know it's been a couple of years since this post, but were you able to accomplish getting the local app to work with the customizing app? DSM is not an option per this customer. We are on NW7.4 so I'm guessing the enhancement issue is no longer relevant. I'm new to BRF+. . Thanks in advance for any help/suggestions anyone can give me.

Terri

[hardyp180]

http://scn.sap.com/community/brm/blog/2015/03/23/brfplus-application-exits-ability-to-maintain-entri...

As can be seen above no doubt the official SAP position is that you are not supposed to use BRF+ to maintain the rules directly in production, you are supposed to give a lot of money to SAP to buy a separate system.

Naturally that is going to be the official position, if I was a salesman and my commission depended on convincing you to buy a separate licence that would be my position as well.

Guess what we have done at my company? That's right - we built our own system in ABAP as a top layer. A business type user makes a proposed change, and that is not committed but stored in an interim place, the proposed change gets work flowed to an approver, who can run a simulation to see what it is going to affect, and then can approve or reject the change and control exactly when the change takes effect from.

Now, it could be argued we have just built large chunks of something very like DSM ourselves, and probably what we have is not as good and cost as just as much in development time (time = money) as a new licence...... but that is just the way we are. We have written our own variant configuration system as well.

[Jocelyn_Dart]

HI Folks

Please don't resurrect old threads.  A lot changes in 6 years. 

Create a new discussion and add a hyperlink to the old one.

Terri - create a new discussion but first have a look at Christian Lechners blogs on the BRFplus API - some customers have used the API to do their own minimalist version of DSM so that may also be an option if DSM is off the table.

I'll close this thread.

Jocelyn

[Former Member]

Hi Carsten,

I think I failed to completely explain my scenario earlier.

A lil comparison with SAP ABAP Workbench world: SAP allows us to create Application/master Data type of tables in DEV, we transport this table object to QA and PROD, and we maintain entries for this table directly in PROD.

If I were to replace such table with BRFPlus decision table, how can we make this happen? Is this how it will work?

1) Create an expression (decision table) and corresponding objects (application, data objects, etc.) as a Master Data Object in DEV.

2) When Completed, Add these objects to a 'Customizing Transport' (this does not seem to accept Modifiable Transport like SAP tables do) using 'Transport' button and transport it to target systems.

3) In Target systems (QA, PROD), create constant expressions for decision table cell values, and add those expression in decision table cells.

If the answer is yes, the only problem I see is - If I created any consstant expressions and maintained them as decision table cell values in DEV for Unit Testing, I will have to make sure that I exclude them from the transport so that they don't make it to QA and PROD, which I think is managable with some development discipline.

Thanks,

Saurabh

[carsten_ziegler]

Hi Saurabh,

what you want to achieve needs NW 7.0 EHP2. we did not manage to get this into 7.0 EHP1 because of time.

In NW 7.0 EHP2 you can create a function incl. data objects as system objects. Then you may create a ruleset as a customizing object and have decision tables etc in that rule set.

It is possible to have more than one ruleset being assigned to one function.

So you may have a rule set being transported into the productive system. And another one being maintained in the productive system directly. With priorities you can define which ruleset is processed first.

E.G. you may have a default behavior coming into the productuve system by transport and exception behavior being maintained directly in the productive system. In NW 7.0 EHp2 we still do not allow to mix content inside of one decision table. Instead you need to work with two decision tables. You may use a precondition to decide if the second decision table or rule set should be evaluated at all.

BR,

Carsten

[Former Member]

Hi Carsten,

Thanks for responding, I really appreciate your help.

Correct me if I am wrong - Does not this limitation partly defeat the purpose of extracting business rules from the application coding and maintaining it centrally?

E.g. currently we have several rules that are maintained in customizing tables. For visibility and other purposes, we wanted to use BRFPlus.

In our current world, we create custom tables

Delivery Class = 'C' customizing

Data browser/Table view maint = 'Display/Maintenance allowed'

These custom tables and associated maintainence views are transported from Dev to PRD and users maintain these entries directly in PROD. How can we achieve this using BRFPLus? Is there a table maintenance type of mechanism for maintaining BRFPlus decision table entries if it can't be changed in PROD?

With the project we are working on, we wanted to use BRFPlus for similar business rules maintenance. and Decision table is the most suitable option here. If we can't maintain decision table directly in PRD and if we have to move transport everytime from DEV, it takes away the flexibility of changing rules faster and in a way partly defeates the purpose.

"1. Create application, function, data objects, maybe also some rules as system/customizing object. This can be done in a dev system. Transport to other systems.

2. Create application ruleset, rules, expressions, ... as customizing/local object." - Just to make sure I inderstood this correct, In EHP2 is I create an expression as local, I wont be able to transport it and If I create it as a customizing it won't allow me to change entries of decision table in PROD, so how would it work?

Thanks once again..

Saurabh

[carsten_ziegler]

Hi Saurabh,

"Correct me if I am wrong - Does not this limitation partly defeat the purpose of extracting business rules from the application coding and maintaining it centrally?"

No it does not. You can maintain rules in the PROD system, too. But when you take input from various sources (transport and/or local) and qualitites (customizing, application data) you need a mechanism to make sure it does not brake into pieces but works together. Also, you need to make sure that well-known concepts from the SAP world (client concept, system and client settings) are not violated.

"In our current world, we create custom tables

Delivery Class = 'C' customizing

Data browser/Table view maint = 'Display/Maintenance allowed'

These custom tables and associated maintainence views are transported from Dev to PRD and users maintain these entries directly in PROD."

This approach is very dangerous. Transports from DEV to PROD may overwrite data created in PROD. You need a concept of originality.

"How can we achieve this using BRFPLus?"

With 7.0 EHP1 there are only bad alternatives. So you either maintain all in PROD or all in DEV or have some code in PROD that creates artifacts in background and final maintenance happens in PROD.

With 7.0 EHP2 you can split into Rulesets. Means Ruleset 1 belongs to DEV and RUleset 2 belongs to PROD and Ruleset 2 may overrule or complete results from Ruleset 1 or vice versa depending on the use case.

Also you may maintain the rules in a separate system and feed them into DEV and PROD e.g. with XML exchange (quicker than transport).

I do not yet have a paper to describe this in all detalis. I hope we can provide one in the next 2-3 months.

BR,

Carsten

[hardyp180]

I think what is actually being talked about here is not a table normally defined as "C" in the ABAP workbench but one defined as "A" for "master and transaction data".

Traditionally this is used for when the rules change often, maybe several times a week, maybe even during the day. that is 100% the case for the scenario I have chosen the rules change every night, which i thought made it a perfect match for BRF+.

In such cases having to enter the new rules and then go through a complicated transport procedure with many people signing off is not viable.

Thus you transport the table defintion - but not the data - to production, and the business users maintain the rules directly in production. This keeps the concept of originality as discussed above.

BRF Plus was, I thought, intended for situations where the rules change often, and you want the users to maintain these rules, thus abstracting them from the ABAP program.

So the requirement here - a very common requirement I would have thought - is to be able to set up the framework of the rules in DEV, transport that framework into PROD and have the master data portion e.g. decision table entries maintained directly in production.

It appears from the answers here that this is not as easy in BRF+ as I had hoped. I am on 7.0 EHP2 and I cannot see how to create the ruleset as a master data object without creating a new application which is a master data application. By the way, if you try and copy a ruleset, it asks you what application to put the new ruleset in,  and then if you press cancel you get a short dump.

I am going to try and persevere with this, even though it looks like a big workaround is needed.

Cheersy Cheers

Paul

[carsten_ziegler]

Hi Saurabh,

This is not possible in NW 7.0 EHP1.

With NW 7.0 EHP2 you can do the following:

1. Create application, function, data objects, maybe also some rules as system/customizing object. This can be done in a dev system. Transport to other systems.

2. Create application ruleset, rules, expressions, ... as customizing/local object.

This comes close to what you need.

Today, all objects are part of one application. Means all behave same. Means you cannot create customizing objects, transport and change in the productive system. Usually the productive system does not let you do changes in customizing. If this would be possible, each update (transport from dev to prod system) would overwrite your data in the productive system. You need to have clear responsibilities and originals.

For explanation go to SE11 and check the table types:

- S (system) - like code, cross client

- C (Customizing) - like customizing, client dependent

When your screen exits on input of a workbench transport, pls check for notes and/or create a message for SAP.

BR,

Carsten

Edited by: Carsten Ziegler on Feb 11, 2010 6:06 PM

[jayesh_vorani1]

Hello Carsten,

Thanks for a clear and concise update. I have a similar requirement where I need create application ruleset, rules, expressions as local objects, but the rest of the application as transportable.

Your reply seems to suggest this functionality should be available in NW 702, but I can't find it in BRF+. I can confirm we are on NW 7 EHP2. The setting for whether something is transportable or local is still at the application level and not at individual object level.

I have also read through some documentation on EHP3 for NW 7 and it doesn’t mention anything about this functionality being delivered as part of EHP3.

Would you be able to provide more insight in to when can we expect this functionality to be made available?

Kind Regards,

Jay