05-20-2008 9:42 AM
Hi,
We built some roles manually by drag and drop transaction through the menu tab. In some roles, we have duplicated authorization object
For example, in PM : Maintenance Plant (object I_SWREK), we have 2 profiles with SWERK=* and TCD = (list of transactions).
I'd like to generate a new role with only one profile which contains SWERK=* and a list of transactions in TCD
The pb is i don't know at first which authorization objects or profiles are concerned by this duplicated objects
Is there a program, trans code or function module i can run to get this information ?
Thanks
Guillaume
05-20-2008 4:59 PM
Ok, thanks for yours answers.
If we deal with performances during authorization checks (when executing transactions or reports), do you think it's better to store all the information in one profile?
For example :
one profile :
- SWERK=* and TCD = IE03, IL03, IP06, IQS1, IQS2, IQS3, IW3D
2 profiles
- SWERK=* and TCD = IE03, IL03, IP06
- SWERK=* and TCD = IQS1, IQS2, IQS3, IW3D
Which one is the better ?
Thanks.
Guillaume
05-20-2008 11:16 AM
The fact that you have the same object multiple times is not wrong. When the objects have the same values you can deactivate one of the objects. When they have different values the authorization will be based on the object that allows the most. So if you have an object with values 1,2 and 3 and that same object with only value 3, then the user will have the authorizations of the first object (11,2 and 3).
05-20-2008 11:29 AM
Just to add !!!
Example:
Duplicated block1 may have activity say 1,2,3 with Auth group field ABC
Duplicated block2 may have activity say 3 with Auth group field XYZ
So in this senario same Tcode will be able to create, change and display for Auth group ABC and Will act as only display for Auth group XYZ.
If activities are same then you can club the duplicated block into one and deactivate the other.
Take care of these things before deactivating.
Rakesh
05-20-2008 12:05 PM
....there is also a compression-function in pfcg....
menu->utilities->Merge authorizations.
But authorizations can only be merged depending on identical status and values....
b.rgds, Bernhard
05-20-2008 4:47 PM
We advise to never use merge :
The problem is that the link of the TRX to Object from USOBT_C can be lost when merging and next time you open the profile the same object is added again.
beter is to deactivate the objects one does not want.
Anyway they do not bite as they will be merged when the user logs on!!
How to find them: download AGR_1251 and do a query on duplicate Lines/values on that table
05-20-2008 4:59 PM
Ok, thanks for yours answers.
If we deal with performances during authorization checks (when executing transactions or reports), do you think it's better to store all the information in one profile?
For example :
one profile :
- SWERK=* and TCD = IE03, IL03, IP06, IQS1, IQS2, IQS3, IW3D
2 profiles
- SWERK=* and TCD = IE03, IL03, IP06
- SWERK=* and TCD = IQS1, IQS2, IQS3, IW3D
Which one is the better ?
Thanks.
Guillaume
05-21-2008 9:01 AM
Hi Guillaume,
I would say, that there will be not much difference.
The auth.-check scans one authorzation (not profile!!!) after the other for the requested values.
So for example:
check for TCD = IE03
first hit is successful for both scenarios, as both list IE03 at first place.
Scenario 1:
SWERK=* and TCD = IE03, IL03, IP06, IQS1, IQS2, IQS3, IW3D
Scenario2:
SWERK=* and TCD = IE03, IL03, IP06
SWERK=* and TCD = IQS1, IQS2, IQS3, IW3D
second example:
check for TCD=IW3D
Scenario 1: the first authorization is loaded and verified, last value gives success.
Scenario 2: no success for the first authorization, second auth. has to be loaded for analyzis and gives success with the last value.
So scenario 2 could even be less performant....
did you realize already some differencies???? Would be interesting...
thx, Bernhard
05-21-2008 9:51 AM
Hi
i agree with Bernhard, there is no performance change involved in how you create your roles:
The profile contents is stored without a link to a role, and all info from that table is being merged at the moment the user logs on.
Of course many big roles assigned to a single user can lead to performance problems and
one should be verry carefull which objects to restrict. Especailly Org levels. Do not just assign values as they can be assigned, but let the functional consultants tell you were they are needed. Were are the risks when leving them open. For instance, if you only have ONE company code in the system, performance wise it is than better to assign a * (STAR) value then the code itselve.
On the other hand talk to your basis people what they can do to optimise the system performance. I have never seen that security (Profiles) did so much harm to the system or user performance, as long as you obide the afromentioned rules.