Extracting or Backing Up AGR_1251

[Former Member]

About 2 - 3 times a year we make an updated to a role which causes us issues only after being moved to production. The standard testing only focuses on the current change and sometimes does not capture waterfall effects. I would like to be able to extract or back up AGR_1251 as once our change is moved to production we have no record as to the objects and values associated with a role previous to the change. I often refer back to the change documents (PFCG) within our development environment but this does not appear to capture all data changed.

My problem is that there are 2.3m records and trying to run (SE16 -> AGR_1251) in the backgroud wide open and then extracting the spool is a nightmare. Am I going about this the wrong way? Is there a simpler method to extraction? I would like to be able to do this about once a quarter.

Thanks,

Chris

[Former Member]

If you do not have too many roles, then you could try a mass download. That will also be more complete than a AGR_1251.

If needed, then load them into a "clean" client somewhere (e.g. sandbox) to take a look at the older version.

Cheers,

Julius

[Former Member]

Thanks Julius.

I am currently dealing wiith 7,000 composite roles and 25,000 single roles. Our sandbox has not been maintained over the years and I had requested in the past to copy all roles into our sandbox but there were sp level issues and custom objects that where not in this environment. It was going to turn out to be a lot of work.

[Former Member]

I am currently dealing wiith 7,000 composite roles and 25,000 single roles.

OMG!! Run away!!

On the bright side, if about 500 of them are irreperably broken, then you still have about 98% of your roles intact to choose from...

Sorry, cannot help you.

Cheers,

Julius

[Former Member]

Running away.....hmmmm wish it was that simple.

[Former Member]

I dont know whether you got yourself into this or a redesign is possible, so should not have commented about running away.

The availability and therefore use of the option "edit old status" is probably a legacy cause of these surprises...

Good luck!

Julius

Edited by: Julius Bussche on Oct 19, 2011 10:59 PM

[Former Member]

> OMG!! Run away!!

I have seen an implementation where number of single roles was some 6-digit figure. Didn't even dare to count the number of composite roles. Every transaction had own role and every HR infotype had own role for display and change in different personnel area and employee subgroup (not derived). I ran away... It would've been nice long project to redesign the security there but I wasn't game enough for it due to the location... (trying to explain being coward)

@Chris: I can't offer any advice for your current problem but I would recommend redesign of the roles. From my experience I know it can be difficult to get approval for redesign project since it requires lot of testing and resources and redesigning business processes in some cases. So I would start planting the seed of redesign project to management mind already now.

[Former Member]

Julius, no problem. I did inherit this but things are really not that bad.

We are a company with 35 physical plants globally and ~ 35,000 employess keeping things SOx compliant has been a challenge but definitely achievable. At the org level we have ~120 different plants and keeping roles segregate has been fun to say the least.

An upgrade from 4.6c is also a possibility in the near future so any huge changes would be rejected.

From a role design standpoint I do like the way it was originally setup.

Template roles to cover base business functionality but segregated into four categories.

1) Std SAP Tcodes Display Only

2) Std SAP Tcodes Maintanence Capability

3) Custom SAP Tcodes Display Only

4) Custom SAP Tcodes Maintanence Capability

There are then single roles derived from the template adding in the org level values.

And finally the Composite role for the Business Area, doing all these and keeping in mind SOD issues (recently upgraded from Compliance Calibrator 4.0 (Virsa) to GRC 5.3 (RAR and CUP installed to this point))

Sorry, maybe a little too much background info

[Former Member]

SaQ, From a maintenance standpoint as well as ensuring each single role is SOD free, the current setup is not that bad. There are some obsolete role that I would like to have reversed out of the system, but this may only account for about 5-10%.

There are some ideas I have been keeping awaiting for an upgrade someday and hopefully that upgrade will come sooner than later just to drive some of these changes.

I've worked with other regions where they almost create a single role for each person and that is chaotic and the team there was essentially just creating new roles cause they had no idea what role did what. I can pretty much tell what each template role now for us does just from memory and instead of having to update 100 roles to add a simple tcode to a business area, I can add to just one template role and voila, done.

One thing that is really interesting now that we have GRC, RAR considers the entire landscape for SOD's compared to when we were running virsa in each system independently. We now have a wider scope to cover for our SOD analysis across all systems (XI, APO, IPC etc) and that has been interesting

[mvoros]

Shameless plug. [This report|http://wiki.sdn.sap.com/wiki/display/Security/QAMetricsforRoleDesign] might be useful for identifying how bad the roles are. There is a long way in front of you. Good luck.

Cheers

[arpan_paik]

  I often refer back to the change documents (PFCG) within our development environment but this does not appear to capture all data changed 

Why it is so? What happen when you select change history for authorization data option?

Or profile change history (provides a better view I guess).

Regards,

Arpan Paik

[Former Member]

Hi Chris,

There are many freeware data translator which extracts data from SAP Tables and stores them in MS Access.

You can search for some of them and install it on your system. These tools will basically call for RFC connection to the system you wish to extract data from. Whatever Tables you specify in the configuration of the tool it will download all the tables in your local hard drive in form of Tables in MS access format.

Advantages are :

1. These tools can work in the background while you can carry on your work in the system.

2. Entire table ( No matter how big) gets downloaded with exactly the same data format as present in SAP.

3. Extraction can be repeated and there is option to overwrite existing table or backup in a new location.

I use CSI Data Translator. You can search if there is anything better.

Thanks,

Deb

Edited by: Debmalya Majumdar on Oct 20, 2011 1:36 PM

[Former Member]

Plan C: A partial client export would achieve the same. Import into Test system "dummy" client if ever required.

Cheers,

Julius