12-28-2010 3:28 PM
Hello
I'm trying to create an SoD report in R3 4.6C where I've created around 400 user groups based on HR employee information, the users are now assigned to their new (but still to be verified) user groups in DEV and QAS and I'm now at the stage of trying to link these to a custom table of paired conflicting transactions which have been provided by the business.
I'm using SQVI in QAS instead of SQ01 due to authorisation and time constraints as I just need to see if the report would actually work without bringing the system to its knees. I'm hoping this isn't the case...
I can insert tables and link USOBT to AGR_1251 then to AGR_USERS and then to USGRP_USER but the custom table with tcode A to tcode B isn't available to insert. The aim is to define a single user group as a starting point to run and analyse and gradually increase the number of user groups in the program in background mode to build up a picture of the number of conflicts based on users' object activities. (A poor man's RAR I suppose)
Without ABAP assistance, as there isn't any for several months, is there a way a custom table be made visible to SQVI please?
As always, no points are given regardless but a warm thank you is always given for any comments or assistance whether or not actually stated.
Cheers
David
12-28-2010 3:56 PM
Hello David,
You can only join a Sap standard table with any other Sap standard or custom table via SQVI when both of them have at least one table key in common.
Also, pool/cluster tables cannot be used in SQVI. It always has to be transparent table if you want to insert it in SQVI.
Can you please check this and revert with your finding.
Thanks
Sandipan
Edited by: Sandipan Choudhury on Dec 28, 2010 9:34 PM
12-28-2010 5:20 PM
Hi Sandipan
Also, pool/cluster tables cannot be used in SQVI. It always has to be transparent table if you want to insert it in SQVI.
Thanks Sandipan, it does look like this custom table isn't going to work based on this insight.
Hi Julius
Thanks for that one - a report in SUIM I have never used before!
We don't yet have the RSUSR008_009_NEW report in this version but the transparent table USKRIA from RSUSR009 can be inserted but doesn't result in anything unfortunately - however - running the report from SUIM, it appears to be a list of either SAP delivered or customer defined critical objects which I'm still a bit confused about (as you probably expected) as it is a list of 'ID's - 71 in QAS.
This really does look similar to the client's custom table that has already been generated with 1400+ entries where it might be possible to add the transactions to the 'ID' field with their SU24 values, this would then, hopefully, let me do a join to exclude users who don't have the object, field name and 'from' values in the AGR_1251 entries.
The next step from that (in the original SQVI) was to do a join to find users with both transactionA and transactionB but, maybe, this isn't possible in R3. I'm trying to avoid using Microsoft Access to manipulate tables out of SAP as it's an extra offline process that will only add confusion and probably end up in the Recycle bin once I've left.
12-28-2010 5:47 PM
Yes, in older releases the report is still split between RSUSR008 (critical auths) and RSUSR009 (critical combinations).
There are maintenance views where you can create your own auth ID's and define whatever you want as values in them.
It is a labour-of-love but works out-of-the-box and is customizable. I think you will enjoy it, but it is not everyone's cup of tea because it is hard work in the beginning.
Tip: Rather avoid wildcards such as * or #* etc in lower releases, as it works differently than expected. Important to note as well is that whenever a check group changes (you can freely define them) the operand is always 'AND' and within a group the operand must always be the same, but is regardless of whether it is 'OR' or 'AND'.
Cheers,
Julius
12-29-2010 8:44 AM
Hi Julius,
Rather avoid wildcards such as * or #*
May I know what #* is used for? I've tried using this, but didn't find an answer on using this? Please explain.
Rgds,
Raghu
12-29-2010 9:05 AM
12-29-2010 9:09 AM
Thanks Arpan,
So can I use #* to check all the S_TABU_DIS with * values directly?
I remember some thread which was replied by Julius that says # can't be used. I was not able to find it now. May be Julius can recollect it to provide more info.
Regards,
Raghu
12-29-2010 9:21 AM
Hi David,
In earlier versions (as in 4.5 and above and pre ECC6.0 days) the report was available in two parts RSUSR008 and RSUSR009, have a look around them, it is quite a nice report in ECC6 but as Julius rightly mentioned it needs quite some dedicated effort to configure it and a few trials for sure.
I had earlier had a discussion on the report , just search for RSUSR008_009_NEW in the forums and i am sure you should be able to find the post
Cheers,
12-29-2010 9:26 AM
The information, release dependencies and restraints are explained in [SAP Notes 1259329|https://service.sap.com/sap/support/notes/1259329] and [1267608|https://service.sap.com/sap/support/notes/1267608] (Harmonizing the search patterns).
One cannot say that generally it does not work and I see now that the harmonization was backported to 46C, so probably it will work for:
a) Well built roles without a crow's nest of auths in them.
b) Fields using domains and check tables for search helps.
c) 4.6C system on reasonably recent support pack levels.
So... it depends.
Cheers,
Julius
12-29-2010 6:16 PM
Hi
I see these two reports in SUIM now and they are the same as the ones that the business have provided so either this was a fluke or they decided to go for a custom version, can't tell until the new year but it a good starting point. The 008 (S_BCE_68001401) seems to have been tested at some time as it contains only a few basic SoD combinations such as ME21N - MIGO - MIRO but, if it's a standard report and not a custom jobbie then I'm all for it.
Thanks for all the contributions - I'll close this thread now as there are other ways of working.
Cheers
David
12-29-2010 10:51 PM
Probably a copy&paste job (to use the UST* tables) in 46C,
Which SP is system now on?
Cheers,
Julius
12-30-2010 11:45 AM
Hi Julius
SAPKB46C59 13.03.2010 Basis Support Package 59 for 4.6C
Regards
David
12-30-2010 9:38 PM
Then you should be fine, but it is generally worthwhile to keep an eye out for program errors in SUIM reports...
In Z-reports which are copies of ancient SAP reports it is almost guaranteed that they will be ridden with all sorts of bugs and obsolete stuff...
Cheers,
Julius
01-04-2011 6:17 PM
Hi
We've done a bit of testing and table USKRIA is looking very promising but, still trying to use the combined RSUSR009 and RSUSR008 reports is proving a little tiresome.
We have RSUSR008_009_NEW in BW but it doesn't look like you can run it for users with both options selected - only either/or?
Trying to join the USKRIA table in SQVI to AGR_1251 and then AGR_USERS to provide a little cockpit works well so far but table SUKRI or SUKRIT for transaction combinations is baffling me as it won't 'join' using any of the TCD1-5 fields.
Is there a way of joining AGR_1251 or USKRIA to SUKRI(T) please?
Cheers
David
01-04-2011 6:38 PM
There is a trick you can use...
The field "group" in the critical auths always uses an AND argument in the reports. Within the same authorization ID you can use AND or OR but they must be consistent within the same group....
So... if you give up the S_TCODE layer of supposed control... and substitute it with meaningfull groups to represent a function (at the surface = a set of transaction codes and reports...) then you can also perform "combination" checks as a "critical" one.
The "transaction code" field of the auth ID is optional as an entry point level of control. If something is really critical then you should not care whether or not the user can navigate into the coding context which performs the critical task as you will never find them all... you should care about whether they can complete the task!
Works for me, and I swear by it!
Cheers,
Julius
01-05-2011 10:18 AM
Hi Julius
It took me a while to work it out but I think I understand what you mean now!
Cheers
David
01-05-2011 3:36 PM
Here is a little example of 1 critical auth ID which checks for the combination of any user admin (OR2) with changing roles / profiles AND assigning them (OR1) as a conflict (to make it critical...)
"Auth ID Group Object Field Value Operator
Z_BC_USAU OR1 S_USER_AGR ACTVT 02 AND
Z_BC_USAU OR1 S_USER_AGR ACTVT 22 AND
Z_BC_USAU OR1 S_USER_PRO ACTVT 02 AND
Z_BC_USAU OR1 S_USER_PRO ACTVT 22 AND
Z_BC_USAU OR2 S_USER_GRP ACTVT 01 OR
Z_BC_USAU OR2 S_USER_GRP ACTVT 02 OR
Z_BC_USAU OR2 S_USER_GRP ACTVT 06 OR
Cheers,
Julius
01-27-2011 2:55 PM
Not quite resolved going down the SQ / SQVI route as we could use AGR_TCODES connected to a new table which has the field types but th programmer was concerned about the efficiency of table joins so we're looking a a proper ABAP custom program to carry out the number crunching.
Thanks for the assistance.
David
12-28-2010 4:08 PM
There is a much easier way of doing this than joins and queries of your own, although I would not say that it is particularly intuitive... --> report RSUSR008_009_NEW.
You can use the user groups in the select options or define different variants from the same authorizations for different user groups.
I have a central monitoring cockpit from which I launch the variants in a sequence and it records the results. In my case, I am actually excluding sets of user groups to see whether the report returns any data at all in the critical auths checks.
You can also exclude certain roles for the critical combinations checks.
You can also run it from SolMan with system specific variants.
Cheers,
Julius