Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

Periodic Update to Derived roles

nishad_showkath
Explorer
0 Kudos

Hi Gurus,

We have master derived roles security concept in place. Our master roles are changed in a separate system (Like Adding or Deleting tcode,object values etc) and then pushed across 5 R/3 development systems (each system for different region). In each development system, we have derived the roles for different countries. However there is monthly release of updated master roles coming in to each of the system and we have to update the derived roles.

The issue now is, we have some Non ORG values maintained in each of the derived roles and these gets over written by * values from parent role when we do copy data. We are looking for any automation we can do to have few of the non org fields (like AUART Sales Document Type, BSART Order Type, FKART Billing Type etc) with the values maintained in Derived roles and dont get over written by * value from parent role.

Since it is a monthly release happening and every month we need to update almost 180(parent roles) * 15 countries = 2700 derived roles its a very lengthy process... 

Please advice in case you have any solution to reduce the effort in this case.

With Regards,

Nishad Showkath

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hello,

As far as I know, the only solution in the SAP system itself is by promoting the non org object value to a org level.

Authorization object fields can be turned into Organizational Levels by using program PFCG_ORGFIELD_CREATE.

GOTO ABAP editor (SE38/SA38), then execute the report “PFCG_ORGFIELD_CREATE”.

But be careful doing this because it will affect all the roles and some authorizations fields are used by different kind of authorizations (Like BRGRU)

I use a third party tool for doing this complex authorization maintenance, CSI RBM (CSI Role Build and Manage). With this tool I can easily maintain roles and derive them for both org levels as non org levels.

Best regards,

Meta Hoetjes

18 REPLIES 18

Former Member
0 Kudos

Hello,

As far as I know, the only solution in the SAP system itself is by promoting the non org object value to a org level.

Authorization object fields can be turned into Organizational Levels by using program PFCG_ORGFIELD_CREATE.

GOTO ABAP editor (SE38/SA38), then execute the report “PFCG_ORGFIELD_CREATE”.

But be careful doing this because it will affect all the roles and some authorizations fields are used by different kind of authorizations (Like BRGRU)

I use a third party tool for doing this complex authorization maintenance, CSI RBM (CSI Role Build and Manage). With this tool I can easily maintain roles and derive them for both org levels as non org levels.

Best regards,

Meta Hoetjes

0 Kudos

Hi Meta,

we already had a discussion on converting these fields to org values which was decided not to be due to few reasons...

I want to know if there is any other solution for this.

With Regards,

Nishad Showkath

0 Kudos

Hi,

The only other workable solution is to remove the inheritance relationships for the derived roles & process them all manually.  From what you are saying I expect this will increase the effort.

The golden rule of using derived roles is that field values remain consistent.  If they don't then you have to rework your role concept or promote the fields to org levels as Meta has mentioned.  If you do the latter then I expect that there would be some additional rework (e.g. if you have different activity combinations for various permutation of variable field values) but in the long run it would be supporting the concept that you based your role design around. 

0 Kudos

Hi Nishad,

It is possible for all non org values objects . For which object you would like to do it?

Meta

0 Kudos

You must however be careful of solutions which "hobble" PFCG and perform direct updates to the AGR* tables. These will be blocked in future via the package interface concept and you cannot rollback to normal PFCG maintenance -> you have to start over without the tool.

As security tables are system critical and there are APIs for user and to some extent authorizations administration, the likelihood of SUSR and PRGN packages being switched sooner than others is very high and SAP did not give any warnings when they switched the first round of packages from developer log warnings to runtime errors.

I strongly recommend that if you want to use such tools, then you should acquire them via SAP services contracts for partner products and not external bespoke tools.

Cheers,

Julius

0 Kudos

Thanks Julius,

I got your point... I will consider it before deciding to go with any 3rd party vendor tools.

0 Kudos

You must however be careful of solutions which "hobble" PFCG and perform direct updates to the AGR* tables. These will be blocked in future via the package interface concept and you cannot rollback to normal PFCG maintenance -> you have to start over without the tool.

? This statement is really not correct Julius, PFCG is still being used, well at least it is for the CSI tooling, I can't tell about other parties. If companies want to decide to no longer use the tooling they can just stop using at and continue in SAP.

I strongly recommend that if you want to use such tools, then you should acquire them via SAP services contracts for partner products and not external bespoke tools. External besproke tools can be SAP partners as well Julius...

0 Kudos

I agree with you.

I am not familiar with CSI as no one I know uses it, but I am yet to see an attempt to tool derived role equivalents which do not directly update AGR_1252 etc themselves and then generate the profiles in batch.

So yes, one should generally be careful in this area and it is best to license the tools via SAP IMO. That gives you some degree of compatibility and sustainability comfort.

Cheers,

Julius

nishad_showkath
Explorer
0 Kudos

Hi Meta,

There are few field like BSART, LGORT, APPLIC, FKART, EDI_MES etc...

With Regards,

Nishad Showkath

0 Kudos

In an ideal world there would not be any org.levels...  😉

They are a small convenience to cascade value sets to multiple instances of multiple objects in one go, but the disadvantages outway that convenience significantly. This becomes even more painful when you use derived roles and add org.type flavours to fields which are not associable to anything in an organization. It will hurt you.

In the above cases you will certainly be forced into building more and more smaller and smaller roles so that you don't mix the values. Otherwise you will be forced to have the same order types for contracts, requisitions and orders. Displaying one archive cannot be mixed with generating archive documents in another. You will not be able to monitor some types of Idocs and selectively be able to correct only a subset of those you can display. Etc.

In moments of weakness I have also tried to think of derived roles as a possible solution to some large sets of roles needed, but I have always regretted it. Every time.

Rather use SU24 to pull values which can be associated to the application type or take it on the nose that you will have to maintain a few fields locally in the role data. It is not that bad.. and gives you much more freedom to build better roles of which you then have much less in number.

Cheers,

Julius

0 Kudos

Julius von dem Bussche wrote:

In an ideal world there would not be any org.levels...  😉

They are a small convenience to cascade value sets to multiple instances of multiple objects in one go, but the disadvantages outway that convenience significantly. This becomes even more painful when you use derived roles and add org.type flavours to fields which are not associable to anything in an organization. It will hurt you.

They have their uses, as does the derived concept but like the other tools at our disposal they need to be evaluated for their suitability for the purpose rather than used as the default answer 🙂

0 Kudos

I guess it depends on the risk appetite of the customer. I for one regretted it every time - big pain which luckily makes itself felt quite soon.

At least with derived roles you have the option to divorce them again from the parent role and then try to save them. Or do that intentionally to build them up to a certain level and then divorce them. Still, much too complicated...  🙂

Cheers,

Julius

0 Kudos

Hi Julius

Merry Christmas!

Referring to your comment:

"or take it on the nose that you will have to maintain a few fields locally in the role data."

Does this mean the org levels in derived roles should be maintained locally (i.e. within the field in the authorisation object)? If so, I know we can change the text for the yellow authorisation object description and add notes to the long text description but I feel that it still may cause some confusion and possibly be cancelled using the reset org level program should somebody see the dark maintained colour in the field or see actual values in AGR_1251.

If it's not this then I'm not quite following 😞

Best wishes

David

0 Kudos

Hi DB,

No. That is not what I meant.

If you don't use derived roles then you have the freedom to maintain a few non-org fields in the roles if you do want to make the decision in the role and dont want to be forced into making an org-level out of it.

eg. display all movement types but post only some and use MIGO for both.

Cheers,

Julius

0 Kudos

Hi Julius

I see.

"in an idea world there would not be any org levels"

Let's pretend HR position-based is not an option...

It would be interesting to see if the PIDs options were a possibility on the UMR to complete (what I can do) with (where I can do it).

Suspect a rat's nest but just putting it out there as an obsevation

Kind regards

David

0 Kudos

David Berry wrote:

It would be interesting to see if the PIDs options were a possibility on the UMR to complete (what I can do) with (where I can do it).

That is very much what personalization keys set out to do. Even up until what amount I can do it.

If you see that the security you want to implement in an application is potentially going to have a nasty affect on the number of roles, then org. levels and user based exits are the least best choice, PIDs can be influenced by users, but personalizations give you both Role and UMR as vector and lots of freedom to implement your own security which can still be (de)provisioned together with the role or the user ID.

Cheers,

Julius

0 Kudos

Ah, I think that I may possibly see your point? The personalisations tab has always been a mystery to me - looking at some of my own entries:

Highest value of shopping cart that can be approved  BBP_APPROVAL_LIMIT

Value above which approval is necessary                 BBP_SPENDING_LIMIT

So, are you saying that these entries could be set to interact with the role functionality?

Probably completely wrong idea on my side.

Kind regards

David

0 Kudos

You can assign the keys via roles or via the user (same tab in SU01). UMR keys take preference over roles if found.

Whether they work depends on whether the application supports the personalization.

They are widely used for webdynpro applications already, as these are often intended for larger sets of users than what SAPGui screens are (such as FB01).

It is the proliferation of series of roles which are the problem, not the number of roles themselves.

Generally for ERP type systems you should be able to get away with about 50 roles max, if you leverage things like SU24 and personalizations. If you have 200 company codes or 5000 cost centers then you can still efficiently make adjustments without the temptation of creating lots of little roles and trying to put humpty dumpty together again via role assignments to the users.

Cheers,

Julius