T-code not in any role but shown in the SUIM report

[Former Member]

Hi friends

I have a t-code which is not any role, but when i run the SUIM reports for Where used list>Authorization Values>In Roles by entering the S-tcode in the Object1 field and t-code in the entry value field the report brings out a role where this t-code is used. I have been into that role and checked if that t-code is in the menu tab, but i could not find it. I also ran the SUIM for Roles By Complex Selection Criteria but i could not find a role where this t-code is in. But how come when i run the report for Where Used list it brings this t-code

Any quick thoughts on this are highly appreciated as this is a High priortiy.

Thanks in advance

KV

[jurjen_heeck]

Instead of the menu tab in PFCG, go to the authorizations tab and look -in the profile- into the values of S_TCODE. This behaviour looks like a manually added S_TCODE authorization or range.

HTH

Jurjen

[Former Member]

Hi,

User tcode PFCG-> Authorisation ->Click on Display Authorisation Data-> Ctrl + F and put S_Tcode and click on find object ... Over there it will show you the Tcode .. may it will in range

Regards,

Rakesh

[Former Member]

Heeck

I did that but i could not find the t-code under S_TCODE auth obj in Auth tab?

[jurjen_heeck]

Is there any tcode value in the S_TCODE object where both the ''from' and 'to' fields are filled?? Or any fields containing a star (*) at any point?

[Former Member]

Hi KV,

Check objects P_TCODE, Q_TCODE etc or look directly in the authorization for field 'TCD' having the tcode value.

>

> ... when i run the SUIM reports for Where used list>Authorization Values>In Roles by entering the S-tcode in the Object1 field and t-code in the entry value field the report brings out a role where this t-code is used.

The "tcode" is most likely available and used ("where-use-list") by the field of an object which is not S_TCODE.

Cheers,

Julius

[Former Member]

Hi,

Keep in mind that suim gives sometimes information about profiles. Maybe it has been added to a profile in the past. Try to find out in which profile it is and with su02 you can look into the profile. The profile if it is generated has a special sign. If this is so look in table agr_prof to find out which role it belongs to. If it is not a generated profile you have to deal with it in su02.

Have fun

Jan van Roest

[Former Member]

Hi Jan,

SUIM reports typically use the profile data in the UST tables which can get out of sync with the USR tables containing the real access.

Running function module SUSR_SYNC_USER_TABLES with TABLETYPE=X can usually improve this, though if you have a slow system with lots of roles (20000+) then it may time out.

[Former Member]

>

> Running function module SUSR_SYNC_USER_TABLES with TABLETYPE=X can usually improve this, though if you have a slow system with lots of roles (20000+) then it may time out.

Hi Alex,

Thanks for this useful info.

Just had a question too on the above Function module.

What does tabletype signify here ? I see tabletype 'U' coming in as default.

Also, how often is this sync required?

Will appreciate your guidance

Thank you

Abhishek

[Former Member]

Hi Abhishek,

I looked into it a while back but I have to admit I forgot what the table types signify (and don't have access at the moment to check). What I do remember is that table type had to be set to X for it to work.

I usually run it every month or so on a smaller implementation just to make sure SUIM is reasonably accurate. It definitely has fixed a few anomalies over the last few years

[Former Member]

If I remember correctly, you can look inside the function module to see what that parameter does. It was something like:

U = USR tables clean up based on UST tables

T = UST tables clean up based on USR tables

X = clean up of the UST tables, after considering possible clean up for the USR tables (or the other way around).

There were also some corrections, which might be mentioned in the function module. They would be more authoritative on the difference than my memory.

Cheers,

Julius

[Former Member]

Thanks for this this info Alex and Julius

I ran this function module in a sandbox....and guess what...i saw some changes :

I ran with parameter 'X':

(Picked 3 UST* tables, number of entries)

Table Before After

UST04 67,651 67,340

UST10C 10,972 10,968

UST10S 198,915 198,902

But now I have some concerns........ain't PFCG_TIME_DEPENDENCY updates and synchronizes UST04?

1. Standard Profiles assigned manually do not have end dates, hence PFUD is not applicable here.

2. Manual deletion of such profile reflects immediately in UST04.

3. The remaining entries are a result of assignment of roles which may have end dates. PFCG_TIME_DEPENDENCY cleans and reconciles the UMR's, updating UST04 in turn whenever run.

How did UST04 change with this function module??

-Abhishek

Edited by: Abhishek Belokar on Feb 20, 2008 11:22 PM

[Former Member]

Hello Abhishek,

As Alex indicated, you can use this FM (function module) to correct inconsistencies, primarily on the UST* tables which are used by SUIM. If you have been doing a lot of manual changes to authorizations and using ranges, then this can happen (particularly so if you are changing authorizations in production...). As far as I know, in the latest SAP releases (from 6.40 onwards) this should not normally occur that easily...

I looked into this FM a bit, as I have not used it in quite some time now (see above comments).

Right upfront, the function group name which it belongs to (SUSI) has a "(FOR INTERNAL USE ONLY!)" comment in it...

Perhaps you also read that comment (which is activity '03')...

I was however not able to generate a test environment and execute it, because I am not authorized for SUSI... (see SAP note 587410 to distinguish between them).

I did find reports which call this, so you might be lucky there (and not need S_DEVELOP authorizations to do this... but without the table_type = 'X')

However, I did try to make a bit more sense of it, without actually running it... (some corrections to my above post - but still not authoritative on the topic)

table_type 'U' = (which is default) synchronizes USR04 from UST04, however UST04 might still have phantom entries in it.

table_type 'P' = synchronizes UST10* from UST04, though how that is meant to work I really dont know.

table_type 'A' = synchronizes UST12 from UST10*, see above and also includes "BIS" values.

table_type 'X' = syncrhonize UST04 from USR04, then table_type 'U', 'P' and 'A'.

Running it "just for fun" is okay in a sandbox...

Running it in a production system.... is also okay to fix a mess once you are there... but you could seriously disrupt the business processes (see above comment about manual changes, also in production).

>

> I ran this function module in a sandbox....and guess what...i saw some changes :

> I ran with parameter 'X':

>

> (Picked 3 UST* tables, number of entries)

> Table Before After

> UST04 67,651 67,340

> UST10C 10,972 10,968

> UST10S 198,915 198,902

Consider yourself blessed (unless the developers run this regularly in the sandbox...

Kind regards,

Julius

[Former Member]

Hi Julius,

Thanks for the response

I did check the SAP note you mentioned. It was indeed good info for me.

The intent for me was to avoid any potential inconsistencies that we could have overseen, and what better system to check than a sandbox? We are still on 6.20, maybe thats why I thought we could eliminate possible inconsistencies. We still need to dig this further to check if this report would be helpful for us. Maybe download the entire ust* table before and after the FM run and analyze what entires are getting wiped out(is it consistent after the run?), before actually proposing this in the live landscape.

Thank you for all the info, is indeed very helpful to further analyze this .. Really appreciate it

-Abhishek