RSEC_MIGRATION

[Former Member]

I have read all the material on the migration tool; nevertheless, I still have some basic questions that I cannot find the exact answer to.

1. Selection of the reporting authorization objects to be migrated.

In the SAP material it shows certain authorization objects selected but not all. In his presentation on video, Marc Bernard from SAP stated to select all - does that include reporting objects S_RS_ICUBE and S_RS_ODSO that are no longer checked during query processing for BI-7? Or do you just select the custom authorization objects you have created?

2. Selection of Assignment Method

There are 3 methods available but no reference to a prefered method. In his video presentation, Marc stated to chose method #3 - Extend Existing profiles.

Has anyone used this method? Any examples of methods used at other implementations? Any reasons not to use Marc's preferred method?

3. IMG Switch - Old vs New

In one of the posts, Stan Snyder stated that the auth check can be left on the old 3.X convention and users will operate with those authorizations until the above work is complete.

Is he stating then that he did the migration with the old setting? (i.e. Obsolete concept with RSR Authorization objects).

I would assume that when you start the migration, you would want the setting to the default - i.e. current procedure with analysis authorizations (the new method).

Thanks very much,

Joe

[Former Member]

Hi Joe

Regarding your first question the general lingo that is used among SAP experts is to do it in one big bang. by that they mean select all users and all relevant RSR objects. I don't see a reason why one should be migrating SAP standard or business content when using this tool because think about it you will be simply updating the same thing with same thing. I am selecting only those RSR objects which are identified as the ones we need to migrate I am leaving _ICUBE and other standard objects.

About preferred method of assignment I am using the third method reason for that is that it basically keep thing parallel means your role and assignment method will stay the same and when you will open the role in pfcg it will have additional auth object S_RS_AUTH which will have analysis authorization corresponding to the set up previously in Obsolete RSR reporting authorizations.

IMG setting is simple if it is OLD then RSR auth will be checked and if it is new then S_RS_AUTH will be checked, I am flipping the switch after running the rsec_migration but if you do some testing like flip the settings before migration you will get NO AUTH msg.

Hope that helps.

[Former Member]

Hi there,

we found that the migration tool didnt work as expected. Because of that we are now looking at manually converting the auths. Do you know of any documentation that lists a step-by-step of doing this task manually? What are the transaction codes that one would need to execute to work in the appropriate screens?

[Former Member]

Hi Stephanie,

I know this is a late reply, but I'm not aware of any step-by-step documentation for this.

I've completed three of these migrations manually and each one presented its own challenges. It really depends on several factors, such as how many characteristics are authorization relevant, how many of them are actually used to restrict users, whether any key figure restrictions are in place and if authorizations do not have to be different dependent on the infocube.

If you have any specific questions about this, I'd be happy to answer them. (pls see business card for contact info)

Good luck.

Cheers,

Rob Valcich

[Former Member]

Hi Rob,

Thanks very much for your reply.

Yes, this aspect of BW migration is a challenging one to say the least.

I did manage to get through with the task. After running the tool there was some work to be done manually. A program was written to cover the bulk of the clean-up.

The main problem fell with the original BW 3.5 roles design. Some objects were not authorisation relevant that appeared in the roles.

SJ