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: 

Custom Role Names

Former Member
0 Kudos

Good Morning All,

We have created our role names to reflect:

- Custom VS SAP template

- Type of role (Composite, Master..)

-System (ECC, BI < PI...)

-Module (FI, CO...)

I wanted to know what is most seen across industry, how companies name their security roles. Our company is going global so wanted to make standards which make sense to users and IT.

Your suggestions are much appreciated.

Thanks.

1 ACCEPTED SOLUTION

Former Member
0 Kudos

If your company is going global, it might have need for a CUA in one time or another (as you system landscape grows). This might reside on a SolMan (or not, does not matter), so you would have to consider additional parameters:

Which system does the original role reside in?

Which client in which system do you want to address?

In case of such a scenario you would want to have both, the SID and CLNT-field as a part of the role name.

Consider adding it now, because if you really go-CUA once, having to copy thousands of roles per SID/CLNT is one hell of a job - been there, done that (

23 REPLIES 23

Former Member
0 Kudos

If your company is going global, it might have need for a CUA in one time or another (as you system landscape grows). This might reside on a SolMan (or not, does not matter), so you would have to consider additional parameters:

Which system does the original role reside in?

Which client in which system do you want to address?

In case of such a scenario you would want to have both, the SID and CLNT-field as a part of the role name.

Consider adding it now, because if you really go-CUA once, having to copy thousands of roles per SID/CLNT is one hell of a job - been there, done that (

0 Kudos

I am not convinced of the benefits of having SID and MANDT in the role name convention.

In the F4 search on roles you also have the receiver system as a "prefix" already. If you want to use the same roles accross multiple system landscapes then maintaining them is easier when their names are all the same.

What is the "pain point" of not having the SID and MANDT?

What is IMO very usefull to include somewhere is:

PQD = for assignment in all systems.

XQD = QAS and DEV only.

XXD = DEV only.

Cheers,

Julius

0 Kudos

PQD? Ouch ... what about having multiple additional T?? (test, education, etc). What if you have a role in multiple clients in all of those systems? Where do you go with your F4-help? How do you go about having some roles in PQD, but hell's bell's they dare never show up in any T (or vice versa) ...

Edited by: Mylène Dorias on Apr 13, 2010 3:22 PM

ETA: what if you have several landscapes consisting of PQDTTT and they all share one role (like your average BASIC_Authorisations_Role) which could be the same for all and every NW-based system ...

0 Kudos

I think we are not on the same codepage here...

P = Production clients

Q = Any type of testing, verification, QA, etc system.

D = Development systems.

PQD = roles which can be assigned in any or all of them.

PDQ is not the SID.

Cheers,

Julius

0 Kudos

>

> I think we are not on the same codepage here...

>

> P = Production clients

> Q = Any type of testing, verification, QA, etc system.

> D = Development systems.

>

> PQD = roles which can be assigned in any or all of them.

>

> PDQ is not the SID.

>

> Cheers,

> Julius

you may be correct, we are talking different setups - here's mine:

Landscapes:

BI

WebAS

ERP1

ERP2

XI

Systems per landscape:

DEV

QAS

PRD

TST

EDU

productive clients per system: 2

One Basis-role for all of them in a CUA on a SolMan - HR attached. I cannot have the same role with the same name and different destinations in one CUA-master, so if I want one basis-role (which I distribute per transport over all DEV-systems and from all DEV-systems further on), how would you go about naming such a one on the CUA master?

0 Kudos

>

> What is IMO very usefull to include somewhere is:

>

> PQD = for assignment in all systems.

> XQD = QAS and DEV only.

> XXD = DEV only.

>

> Cheers,

> Julius

That's an interesting approach.

I have used:

Z - first character

D, S, Z, Y - second character (D for development and not assigned in PROD, S for standard role can be assigned on all systems, Z for composite role, Y for system roles assigned to service or system users)

_ - underscore

XX - fourth, fifth or sixth character is for module or area (FI, HR, SRM, ECC, BI, etc)

_ - underscore

XX - remaining are free text

Edited by: John Navarro on Apr 13, 2010 4:44 PM

0 Kudos

So this basis role is available in all clients in all systems and now you want to assign it to user MYLENE in all of them.

On the roles tab in SU01, enter Z_PQD_BC_04_BASIS_ALL

Z = Single role

PQD = can be assigned in PROD, QAS (hence TEST and EDU as well) and DEV.

BC = Main component.

04 = Super user "layer" in role classification.

BASIS_ALL = main role for all basis functions without any org. classification.

Then hit F4... <- here is the advantage!

If the roles all had different names, you would need to wildcard - the necessity of which I don't see. The receiver system prefix is telling you the client and the SID already.

Another advantage is in cross-client and system comparisons and reporting in general, to be able to make a unique match of the names which should be the same as far as content is concerned, or counting the number of roles to be maintained regardless of how distributed they are.

More Irish poetry for you:

SELECT SINGLE * FROM agr_define CLIENT SPECIFIED
           WHERE agr_name = SLIGHTLY LIKE my_agr_name

Imagine oneday there is a remote enabled SU25 available in SolMan...!

Cheers,

Julius

Edited by: Julius Bussche on Apr 13, 2010 5:03 PM

0 Kudos

I would also recommend an approach similar to that of Julius.

XXX:YY:Role_ name

XXX represents the company code, in case of consultants use any 3 letter word suitable.

YY is the component name

Role name

Ex: GLO:SD:Sales_order_maintain

Here Glo stands for global role, valid for all company codes and etc.

SD is the main component for sales and distribution.

As per me, end user roles doesn't need to be classigied based on the system level. However, for consultants / managers who need to have extra authorizaiton can have the DQP (as mentioned by Julius)

Regards,

Gowrinadh

0 Kudos

The company code is a 4 character number, and placing it at the beginning would only make sense if you have decentral role administration for user admins per company code.

Rather unlikely, but you never know...

I think Alex hit the nail on the head: It depends, and AJ is not telling us what the dependencies are, so...

Cheers,

Julius

0 Kudos

> Y for system roles assigned to service or system users)

I usually move these out right to the end of the alphabet, just incase they get sneaked into a range for access to the roles.

ZZ1 = Special roles ONLY for Customizing

ZZ2 = Special roles ONLY for Developers

ZZ3 = Special roles ONLY for Auditors

ZZ4 = Special roles ONLY for RFC users.

ZZ5 = Special roles ONLY for Service / Proxy users.

ZZ6 = Special roles ONLY for Batch users.

ZZ7 = Special roles ONLY for Basis.

ZZ8 = Special roles ONLY for Security Admins.

ZZ9 = Special roles ONLY for Emergencies.

I typically set up the user groups in SUGR with the same convention for the corresponding users themselves.

Cheers,

Julius

0 Kudos

Yes. We use 3 letter company code, hence I mentioned as such. It can be customized according to the client

Regards,

Gowrinadh

0 Kudos

Julius - Would you elaborate little bit on "4 Character CC placing at beginning if decentral role admin for user...'

Thanks.

0 Kudos

If you want that a local key user can assign / unassign all roles for their company code themselves, and you only build the roles for them... then you can use object S_USER_AGR to control their access for the AGR_NAME field in their authorizations in combination with ACTVT 03 and 22.

Now, if for example you have the company code 1201 as number at the beginning of the name range, then you can do this in the authorizations:

 1201*

... and it will work.

If you don't, then you can try to do:

 *1201*

... but it will not work, so you will need to list all of them individually.

Something you need to plan for in advance

Cheers,

Julius

0 Kudos

Thanks for clarifying Julius, appreciate it.

0 Kudos

I remember a thread from long ago, where a few folks requested that "place holders" via '?' should be possible.

For example:

 ??????1201*

But I never heard anything of it again. It would also impose a requirement for your role names which I have personally not been able to consistently enforce myself either (typos, etc) in the preceding length of the name.

Currently, once a '*' is found, the subsequent values are also wildcards and not evaluated.

I suspect the reason for it being that some authorization fields are truncated due to ancient constraints which for compatibility reasons need to be respected. If the placeholders exceeded the truncation length, then the ?'s would raise *'s...

It would for example be tempting to add the org. value to the end of the 32 character role name, regardless of it's own length. But SAP does not know how long the role name is on the customer side, nor how long program names might become for example, although the restriction is questionable. (search for the term "package concept").

Any authorization field value longer than 16 characters which is also used for control purposes is questionable. Defining them exactly is of course perfectly okay if you want to derive the values automatically and know exactly what they are and where they are coming from. It does give you granularity and upward compatibility...

Cheers,

Julius

0 Kudos

I think the role naming is a choice you make based on the client operations and the way they are structured, there is no internationally accepted standard as such. It is like taking an opinion on what colour car should i buy - well it depends,isnt it.

Anyway, coming to the discussion:

We have European operations controlled from the official headquarters and users are spread across 21 countries. My role naming has been based on the domians we work. for a start let me inform that we do not allow local role assignments. local administrators are empowered to maintain users locally (create/change/delete) but not assign/delete/restrcit role authorizations - it is managed centrally after due approvals are taken care of.

My master roles are defined as ZSMSLSX001, ZSMSLSX002 .......for sales, ZSMRDCX001, ZSMRDCX002.....for the local regional distribution centres owned by the local countries (these are the various plants in the loca countries), we have European distribution centres owned by the headquarters and the naming convention is ZSMELCX001........ZFMSXXX001, for Finance sales operations and ZFMMXXX001....for Finance manufacturing opearations

these master roles are derived to the local countries using the SALES ORGANIZATION for the sales roles (ex: ZSMSLSX001 is derived to ZSISDL1001, for Germany - ZSISFR2001 for France and so on, ZSMRDCX001 is derived as ZSIRDK1001 for the Danish plant, ZSICFR2001 is derived from ZFMMXXX001 for Finance manufacturing of France).........I dont know if it is an accepted appraoch in the forum, but it makes life easy at our end and i like it

bottom line: there is no right or wrong in the naming convention, trying to keep them as simple as you can and reflecting the operations and the domain they are created for, would make sense

With the approach you suggested of having the country "US" specifed in the role - can make life difficult if you want to create a role for India and Indonesia (or) Begium and Belarus , following ISO codes could be an option but then you would have to consider the Spanish feelings about using "HP" in the naming (atleast the set of users at our end hate having HP mentioned in the user Id (or) in the role name.........(i am told that it has a not so nice meaning when HP is expanded to its gloriest best).......many things to consider, isnt it?

I wish you luck for your search on the "IDEAL" naming convention

0 Kudos

Juluis - Its no more an requirement now.

To use resources effectively, its decicided that role administration would be centralized. So now we have no req. to restrict on admin level.

Per Sekhar's point I know there is no specific standard, management is more leaning towards Doing a Big Composite role which would be close match to HR Org model. Some thing like 'ZC_ECC: HR_CLERK_CORPORATE'. we will still do Master dervied role concept in underlying child role (Setting a naming standard for them is big task by itself, primary thing I want to cut is maintenance)

Still doing some R&D.

-AJ

0 Kudos

Then base you convention primarily on the type of the role, if it is the intention only ever to assign composites. Good luck with trying to stick to that...

If you have big composites aligned to the Org model, then why do you not consider building big single roles?

Cheers,

Julius

Former Member
0 Kudos

Hi AJ,

As you can see from the exchange between Mylene & Julius, there are many factors that you need to take into consideration. What will not make sense for one implementation (or proposed landscape) will potentially save lots of time on another.

What you need to do is identify how your implementation will end up looking, how it will be supported and how you want to structure your roles to support your business processes. With this information you can start to develop a naming convention that will take this into account. Factors such as method of provisioning (CUA, IdM, HR-ORG, CUP, good old SU01 etc) should be considered as they will have an influence on naming.

Typically I consider the following sorts of information (they are not in any order & not all always used):

System, tech classification, functional or process area, role type, sensitivity, org identifier.

You can also think about whether you want descriptions in the tech title (I prefer numbering but there are pro's and con's to both approaches), if you use descriptions you need to define a key to give consistency. E.g. R3DPRDISAPDISPLAY 'vs' R3DPRDISAACTPAYDISPLAY (not that I suggest that you use the convention I just made up).

Former Member
0 Kudos

This message was moderated.

Former Member
0 Kudos

Aj,

You might want to think about using some including some country identifier since you mentioned you will be going Global. This will help with assignments and speicifc country requirements for the role config to seperate.

Thanks.

Matt

Former Member
0 Kudos

Awesome Guys, thanks so much for sharing your thoughts was completely buried with a project so did not get chance to read/repond..sorry about that!

Mylene: I tried convincing for CUA but management dont see a needm my guess is they will only start think when it becomes necessity.

- We dont add Clnt info in role names however I suggested SID, as for now we added system name like (PI, BI, SCM..)

Julius : I like your idea, it will be helpful to role owners when they approve roles fo rusers. Issue is as role name can accomdate 30 characters, management dont like to use good chunk of space for identifier.

My role names is close to Mylene and John some what, here is it:

ZM_ECC_US_FI:Display_1030

Z : For Custom

M: M is Master..Reference..Composite..

ECC: System identifier, can be BI, PI, SCM...

US: For US location

FI: Module

Remaining is what make sense

Managers have concerns with 'US', my idea was role owners will know what location they are approving to.

Business Analyst want to know if they can do 'Company Code: like 4800, 4500,...

We have no automate tools for role request, so to make it easy on users I included system like 'ECC/BI/...' by this roles group by system on our intranet wesite from where users request.

It was great to hear your thoughts, I will much appreciate your thoughts will be helpful for a sensible standard.

Thanks Much.

Former Member
0 Kudos

Mylene - To answer your question 'What system does the original role reside in?"

We have Dev Security client, all the security roles start their journey here:

DEV Security -060->QAS-->PRD and then goes to SBX sandbox and all other Dev clients.

Thanks.