Decision table in BRFplus to be updated without Transport Request in Production

[rohan_somji]

Hello,

We are currently using BRFplus application for SAP Management of Change (MOC) to maintain business partners for Partner determination of activity. The Business partners have internally generated numbers in Dev / QA and Prod. Now we need to make changes in the decision tables i.e. to add or change business partner in production. But we cannot do it directly in production as it is asking for transport request because the storage type is customizing. The other option is to open client and make the changes which is also not a recommended approach. if I create a transport request then the business partners in Dev and QA will be changed and this will then impact our testing environment as the business partner numbers will be different.

1. So now how can I make changes in the decision table directly without transport request or opening client. Is there any way of doing it.

2. Can I change the storage type from customization to master data for a standard application? If yes then where do I need to go to change this setting.

The idea is to give access of this decision table to business in future so that they can modify the business partner whenever it is needed as it will be an ongoing activity.

Kindly help me with a feasible solution. Thanks.

Regards,

Rohan

[former_member674140]

I have a very similar issue and was wondering if you found a resolution.

[rohan_somji]

Hello Kathy,

Yes we have implemented this solution.

Regards,

Rohan

[former_member674140]

Rohan, thanks so much for the quick response but I am not sure it is clear to me which of the options you implemented?

[michaelf_ · Accepted solution]

Hi Rohan,

indeed this is a problem if you generate the Business Partners separately in DEV, QA, and PROD.

Generally, there are two approaches for this issue:

1. Create the Business Partners in PROD (or an HR System) and move them to DEV and QA using ALE

2. Use the SAP System User name. In the decision tables for the partner determination for change requests and activities, there's the column for "Position". The trick is to use this column and adapt the BAdI /IAM/BADI_POSITION_TO_BUPA so that it does not map a PPOME or BPHR position to a business partner but a user name. Usually, the user names are equal in DEV, QA, and PROD.

3. (not recommended) open the PROD system for customizing (t-code: SCC4).

Changing the storage category would only be applicable for your own custom BRF+ application which you could create and customize to work with your change request type.

With kind regards,

Michael

[rohan_somji · Accepted solution]

Hello Michael,

Thank you for the reply. To comment on your suggestions.

1. Using ALE.

In Prod we have around 3000 IDs. In Dev we hardly have 50 IDs and all of these are test IDs.

2. Use the SAP System User name

We cannot do this as we do not have prod user IDs in Dev and QA unfortunately. We only have test IDs created in Dev and QA.

3. Open the PROD system for customizing:

This request is rejected in our case as we wont be doing any open client activity. The decision table is more of a business table which will be continuously updated as and when we have updates coming in from business like new member to be added or current member to be removed or replaced. So we cannot keep opening client every now and then.

Couple of queries if you can kindly answer.

1. The decision table we have is standard and the storage type is customizing i.e. transportable. Is there a way to change this to type master data so that we can then make changes in production directly. I see the field is grayed out and was wondering if this can be changed. If yes then where can I make the necessary settings. I'm attaching screenshot for reference.

2. Is it possible that this table which is customizing in Dev and QA which requires transport but in Production this table will not ask for transport and rather let me save the data directly. I have read some post have said at times this type of situation is possible but I'm not sure if this how SAP provides certain standard decision tables which can be directly changed in Production despite Storage Type as Customizing. If I do get this option then is it ok to make changes directly in production. This then acts like how storage type master Data will act.

Refer the below post. It is an old one though.

https://answers.sap.com/questions/7937048/client-not-modifiable-message-while-executing-t-co.html

It would be great if you can throw light some light on my queries. Thanks.

Regards,

Rohan

[rpscg]

I have been back and forth on this topic and I have yet to see a definitive answer that actually makes any sense. The official help pages are seriously lacking in some areas which is creating confusion for many.

1/ What is the point of a master data application? I can see a use case for it, where the elements in the rules are actually master data that could change on the fly. At its simplest case, the rule could be a switch for an enhancement that isn't supported by the switch framework.

Except...

It can only be created locally, therefore it would mean a master data application for PRD has to be created in PRD. This has several drawbacks.

Getting permission - even in the most laid back of environments, not easy. Working on a high-sec system, don't even ask!

How would it be consumed? I need to incorporate a method call to access a BRF+ function which requires development in the same system.

How would it be tested (without disrupting BAU)? There is simulation but ideally it stills need integration with a consumer.

How would it move from "test" to "live"? Versioning?

The only scenario I can envisage where this works is if the master data application is on a service hub and is accessed remotely, similar to a Gateway Hub, etc. All of the building and data population happens there and doesn't get transported. In this scenario, versioning makes more sense as well (I have seen recommendations to avoid versioning if possible). Is this where frameworks like DSM kick in? Great if you have it and understand it, not so great if you don't and have no influence over the decision to implement it.

Ideally (without a hub) this would be treated like any application that needs to work on master data. The 'code' portion is transportable and immutable (until a new version is produced). On arrival at its destination, the application is given its data. This could be the same data used to test it, via the upload facility.

2/ Backdoor exits (hacks?)

The provision of an exit channel to enable change mode just feels like a hack to me, because I cannot see the rationale behind the basic master data design. It looks like it was realised that there was a use case for transportable master data applications but by then it was too late.

If this exit had been made so this it only worked in master data applications it would not have been so bad, but it can be used on customising types. Which leads to the situation already mentioned in this thread, where it now possibly conflicts with the alternative transport option. Well thought out or a hack?

3/ Roles and authorisations. As far as I have been able to determine, there are no specific roles for various BRF+ uses, just one superuser role. So if there is possibility to ring-fence off some functions, it's really not clear how to build a suitable role based on the super role. Was it really too hard to provide some sensible roles for this?

And where is that missing tranche of BRF+ content that is pointed to in various posts? Very mysterious.

[michaelf_]

Hi Rohan,

in general, changes should not be made in production because then you will not be able to test the changes in a safe environment.

Michael

[michaelf_]

Hi Rohan,

regarding your questions:

1. The storage type can't be changed once an application is created. However, when copying an application, the storage type can be adapted for the copied application (deep copy!).
2. This is most likely a use case for Decision Service Management (DSM) which offers a lot of functionality for changing and transporting BRF+ outside of the "normal" transport mechanisms.

Regarding the usage of user names or business partners in DEV, QA: There is no check or validation on the existence of those, so you can enter the productive user names and set up the DEV and QA test users in SM34:

• Persons involved for activities: /MOC/VC_ACTPTY_MD
• Persons involved for change request:/MOC/VC_IS_PTY_MD

Best regards,

Michael

[rohan_somji]

Hello Michael,

Thanks for the reply. So now for me point 1 is very clear that I cannot change storage type.

About point 2 the reason I asked is because in my case when I add any entry directly in Dev or QA for the decision table I mentioned above I'm always asked for a transport request. But when I made the same changes in the same decision table in prod I was not asked for any transport and this was very surprising for me as the client is definitely closed for prod and we do not have Decision Service Management (DSM) implemented. Then how is this scenario possible? Now with this option in hand I'm not sure if I should make the changes in production directly then as it is lot easier but I need to know that if this is recommended.

Regards,

Rohan