Editing expressions in non-development systems.

[Former Member]

Our first use of BRF+ met a large success among our business key users and  they are requesting now the maintenance of some decision tables.

We therefore followed the guidelines of document "editing BRF+ component in non-development systems" and implemented interface IF_FDT_APPLICATION_SETTINGS.

All went fine on this part, but we hit major troubles with the authorization parts.

Due to the fact that our application was defined as 'customizing', we keep having message "System settings do not allow changes for customizing objects" and asks for authorization object S_TRANSPRT in production.

Having the application set to 'customizing' was not the best idea, as all objects created afterwards inherited automatically from this property.

Is there any way to force the status of specific expressions (not all at it would not make sense) from customizing to master data ?

[carsten_ziegler · Accepted solution]

As Christian explained you may split your use case in two applications.

I anyway recommend for bigger use cass to put function and (shared) data objects into a system application and rules into a customizing application. In scenarios where you frequently need to change rules you can also use a master data application, not only customizing.

However, we have seen several issues with customers changing rules in the productive system (be it master data or be it customizing with the application exit). The problems are

• missing checks for activation of changes (although customers could implement exist for any specific checks they want)
• conflicts with imports (again, customers could implement custom code in exits to prevent some of the issues)
• missing activation workflow (also here custom solutions may help)
• times where BRFplus may fall back into interpretation mode because of changes happening in parallel

As a consequence I generally do not recommend changing rules in productive systems directly. Instead my recommendation is NW Decision Service Management which provides you all the tools to perform your changes, test them, deploy (with or without release workflow) and use them (always generated code).

- Features of DSM

[Former Member · Accepted solution]

First of all, thanks to you both for those valuable hints.

This split of applications into several parts will certainly be the major lesson learned.

Taking into consideration Carsten's remarks, we are going to restrict the scope of maintenance in production to the key decision tables (we will create a dedicated catalog for that purpose) and the authorizations to a single key user and his backup.

As for DSM, we need that BRF+ benefits fully from current success and good (internal) press to get into this next step.

I believe that the remaining steps are on my side...

Best Regards,

[Jocelyn_Dart · Accepted solution]

Hi Jean Charles,

Re your "As for DSM" comment - that's fair enough as a starting position.

But please make sure you preview with your internal customers, that it's DSM that will give them true adaptability without being tied to the IT schedule, and let them do much more than simply enter data in decision tables.

Rgds,

Jocelyn

[Former Member · Accepted solution]

Hi, Jocelyn,

Fact is that you do not learn to drive on a Ferrari.

BRF+ has introduced major changes in the way key users perceived SAP systems. They currently start to perceive all the benefits from this new approach. It would not be a wise move at this stage to switch to a new tool, and ask them now to do more than the decision table updates. If we do not go through a stepwise approach, we may compromise the whole move...

Best Regards,

JCF

[former_member190447 · Accepted solution]

Be aware that DSM is not a new tool, but an add-on to BRFplus. So it offers a big number of new features and capabilities, while you can reuse existing rules as they are. You don't need to rebuild them, nor do you need to migrate anything. Using DSM is the exact same user experience as using BRFplus only. So I don't think the picture with the Ferrari is a good analogy.

[Former Member · Accepted solution]

Hello, Wofgang,

I am completely aware of what DSM is, and did not try to depreciate it in any way.

The key point here is that the decision to move to a new tool with additional (license) costs belong to our business users, who will ultimately bear this cost. As I mentioned, they start to see all the benefits introduced by BRF+ tools. Switching now to DSM will just kill the whole thing.

[christianlechne]

Hi,

as you write the storage type is defined on the level of the appplication and inherted to the BRF+ artefacts contained in that application. There is no way to mix that up in one application (at least not that I am aware of).

I would propose that you split your application into two, one customizing and one master data. Within the master data you define the objects you want to maintain in productive environment and you call those from the existing customizing application.

Best regards

Christian