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: 

Naming convention for roles - your opinion

Former Member
0 Kudos

Our practice has been to start all of our roles with a "z". We have a different naming convention for single roles versus composite roles also.

I am aware that SAP says not to start roles with an "s", because their roles start with an "s".

Is there any downside to using other letters or naming conventions?

6 REPLIES 6

Former Member
0 Kudos

I am not aware of any disadvantage here nor anywhere else from having a naming convention and keeping to it.

On the contrary, it is probably the first-most important step towards orderly and secure system management.

There are a number of threads here about security related naming conventions and specifically for roles and profiles as well. I am sure that "convention" OR "naming" as term will return some of them easily.

Cheers,

Julius

0 Kudos

Julius is right we discussed this a number of times already.

small recap:

1 there is no GOLDEN rule for names, just a number of best practice advises.

2 be sure to chose a naming convention that is fit for purpose, so you do not have to redo it again!

3 it is good to clearly discriminate between singles and composite roles:

for example: single roles Z:....... composite roles C:................. or whatever you chose (except S)

4 be sure to have a GOOD naming mask, whenever you have to chose a large number of roles the right mask is helping, so have the same kind of chracter on the same position: example: Z:FI010_PGMM.

Explanation: Z= single role, FI= Finance, 010= specific role in the FI group. PGMM= Company code as in used the BUKRS field.

The above is just an example that you can use to build your own naming convention on, when using derived roles concept make sure that FI010 is on exactly the same position in all deriveds and the Company code also. By choosing Z:_PGMM One can select all roles for that company and by choosing Z:FI one can chose all Finance roles etc. this can be handy when looking into tables, or when doing checks in CRG or when transporting.

Hope this helps

0 Kudos

>

> for example: single roles Z:....... composite roles C:................. or whatever you chose (except S)

Even S is not sacred......it has been claimed by a number of SAP employed consultants that it is safe to use.

0 Kudos

Many people use S; to signal that it is a copy of a SAP standard testing role delivered with the system.

Probably because the Authorizations Made Easy book suggested it...

Cheers,

Julius

0 Kudos

....feel free to use any name you like.

Roles are customizing objects, therefore there is no regulation regarding names. Of course it is advisable, not to use existing names starting with 'SAP' (=the existing SAP roles) or other names starting with 'SAP' as a SAP-role with the same name you have used already might be delivered once.... SAP note 20643 is also valid for roles except the question for namespaces.

It is also possible to use namespaces for role names. The check for a valid namespace is performed in TR_CHECK_NAMESPACE ( LPRGN_TREEF0F (Form CHECK_NAMESPACE_FOR_AGR)). (pls refer to the comments in the function for prerequisites (unfortunately those are in german)).

b.rgds,

Bernhard

Former Member
0 Kudos

In addition to the naming 'mask' as Auke pointed out, also consider whether it would help if the naming convention were to include an identifier for the system in which the role is relevant.

Often times, you may have similarly named roles (for example, 'Basis Administrator' or 'Security Admin') in different systems. But depending on the system they are in, their authorizations will differ. If the security team is not diligent , this can lead to a lot of confusion. Yes, we are all guilty of downloading a role from one system and uploading it in another as a quick fix and then 'forgetting' to fine-tune the role to system/application specific needs.

Also consider what function CUA or SolMan plays in your landscape. Also think about the personnel that support 'security' function. Not everyone involved have the same level of security acumen. So it helps a great deal if you keep the name simple enough to be understood by all.