Application Development and Automation Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 
Read only

After Migration issues

Former Member
0 Likes
1,556

Hello,

1)Once after running the migration in DEV How can i transport to the quality and producation... OR i have to run migration in quality and production again.?

2) When iam try to see the authorization obj in rsecadmin> maintance>when iam giveing the old authorization obj and click on display system shows "obj not created"...what it mean. old obj are not shown in new system..? if we can see the old obj ..where we can...?

3)If user want to create a new authorization obj ..i will create the auth obj in rsec admin ...after then i have to migrate that one also?...or no need of the migration...?

4)How can i test the migrated authorizations.

B.K

1 ACCEPTED SOLUTION
Read only

Former Member
0 Likes
1,383

Hello B.K.

1)Once after running the migration in DEV How can i transport to the quality and producation... OR i have to run migration in quality and production again.?

You should do that in DEV system and then TRANSPORT IT TO QUALITY AND PRODUCTION (don't agree with you Dimitri). Of course you can run the migration program in all systems, but i don't believe that's the right approach. Here's what i believe is the better approach:

First: be sure that in RSSM you have the same authorizations objects in DEV, quality and production. Also be sure that in RSSM all the InfoProviders that you previously marked to check for those objects are equal to quality and production. Do the same for the definition of hierarchies. Normally when you're doing an upgrade and want also to do the migration of authorizations you do a copy of production to development, so you end up with a development system equal to production. In that case you can do all your changes in development with an equal system to production and then you can transport all your changes to production system without any problems.

Now after that, be sure you have the same roles defined in pfcg in production system equal to development system. If you're not sure you can mass download your developed roles (starts with Z or Y) in transaction pfcg in production system and then upload that file in development system in transaction pfcg (this is just like transporting all the roles from production to development). Again if you've already a copy of the system, or you're sure that all the roles that exist in production are the same and with the same definition in development system, no need to do this step!

Now the RSEC_MIGRATION program is built based on users. So the program searches for the roles assigned to the users. So if you have a role created in production system, this roles is assigned to several users, but in development system this role is not assigned to anyone (since is development and sometimes you don't need to assign to anyone, you only had created and transport it), the program is gonna skip that role, and therefore might skip the migration of some objects! To prevent this you MUST GUARANTEE THAT ALL ROLES THAT YOU WANT TO MIGRATE (starts with Z OR Y) ARE ASSIGNED TO AT LEAST ONE USER (You could create a Dummy user and assign all roles that aren't assigned to anyone for this particular purpose)

After this steps, and after running the migration program, you have to transport your changes to quality and production system. You can do this with two steps:

A). Go to rsecadmin transaction and click on button "Transp.". IT will be showed a list of objects. Mark all these objects and choose a transport request.

B). Go to transaction pfcg and choose mass transportation. Insert the list of all your Z or Y roles and create a request transport.

transport both the requests to quality and production system and there you go! The same migration of your authorization is in all the systems with transport. Now you can maintain your authorizations in DEV system and transport it to quality and production every time you want!

2) When iam try to see the authorization obj in rsecadmin> maintance>when iam giveing the old authorization obj and click on display system shows "obj not created"...what it mean. old obj are not shown in new system..? if we can see the old obj ..where we can...?

In transaction RSECADMIN you can only mantain the new authorizations objects (that were created during migration program and exist in table RSECVAL). Forget the old authorization objects that existed in RSSM. If you're using the new authorization concept Analysis Authorization, you'll no longer need those objects, and RSSM is gonna do nothing to your authorizations.

3)If user want to create a new authorization obj ..i will create the auth obj in rsec admin ...after then i have to migrate that one also?...or no need of the migration...?

No! If you choose in your RSEC_MIGRATION program the option of "enhance existing profiles", you should create your new authorization object in rsecadmin and assigned it to a role (could be a role that already exist for that particular authorization values or a new created one for a new group of authorization), and then assign that role to the user. You should not migrate any more after the migration is complete. You should maintain you new authorizations (create/change/delete)

4)How can i test the migrated authorizations.

To test your authorizations you can execute the queries with test users and see if whatever he/she is to be authorized for that InfoProvider (what existed in RSSM) is what he/she can see

<removed_by_moderator>

Diogo.

Edited by: Julius Bussche on Jul 10, 2008 9:53 AM

8 REPLIES 8
Read only

Former Member
0 Likes
1,383

As far as I deduce, your issues stem from not transporting your authorization objects. The reason why you can't see them clearly shows they haven't been transported to the new system...

Read only

former_member74904
Contributor
0 Likes
1,383

hi B.K.,

1) the migration of old BW3.x objects to 7.x analysis should be executed in all systems and not be transported.

2) only analysis objects can be maintained/viewed with RSECADMIN.

3) when you create a new analysis object you don't have to migrate it anymore. migration is typically something you only do once within a system landscape.

4) testing analysis auth. could normally be tested by running queries in the new environment and compare it to the old productive results.

good luck!

Read only

0 Likes
1,383

Hello Diogo.

I found the new analysis obj in RSECVAL Table.There New analysis obj maintain as (my reporting auth obj tech name ZPRFCTR) ZPRFCTR03(With some numerics)

Total i have around 30 obj . but in that table i found only 10 obj converted as analysis obj.

Iam not able to understand that table correctly.. For my above auth obj haveing only obj zprfctr and 1kyfnm .But in migrated obj haveing the special char's (0tca*) ,zfacility,zregion etc(actually these obj are not included ..no probs about the special chars).

All my auth obj are assigned to roles, and all roles are assigned to at least one user.

Can any one explain.

B.K

edit by b.k

Read only

0 Likes
1,383

Then where we can see the reporting authorization obj? If i want change the values of the obj ,where i have to change..in roles. ? So we are not able to maintain the reporting auth obj like analysis obj ,even after it is migrated...?

the objects you have migrated have been made using Business Explorer -- Authorizations -- Reporting Authorization Objects.. these objects in turn had to be added into a role (also for the new concept).

some more info can be found [here|http://help.sap.com/erp2005_ehp_03/helpdata/EN/ad/8f7842fdb70f53e10000000a155106/frameset.htm|SAPhelp]

According to the new concept we have to maintain 0TCAACTVT

0TCAIPROV, 0TCAVALID,0TCAKYFNM .these four obj automatically assigned t othe each reporting obj.

there's a button in RSECADMIN which automatically adds these four characteristics which are always authorization-relevant into you analysis object.

It mean we can directly create the analysis obj andassign to the uaser directly .after then we can use normally.

yes.

take care,

dimitri.

Read only

0 Likes
1,383

Sorry dimitri. Iam edited the message...Because with the Diogo posting iam understand some what... ok .. no probs any way its usefull.

BK

Read only

0 Likes
1,383

Hello B.K.,

Not sure if I understood your question.

But here it is:

RSECVAL contains all objects of the new concept.

If previously you had in RSSM an object named ZPRFCTR (I believe profit center), you could have let's say for example 6 roles created for values of that object like this:

zrole1 with ZPRFCTR=1;

zrole2 with ZPRFCTR=2;

zrole3 with ZPRFCTR=3;

zrole4 with ZPRFCTR=4;

zrole5 with ZPRFCTR=5;

zrole6 with ZPRFCTR=6;

Now the program picks up the name of your authorization object in this case ZPRFCTR and starts to create the new objects with two more digits in the end to represent the different values,in this case it would be something like this:

zrole1 with ZPRFCTR01;

zrole2 with ZPRFCTR02;

zrole3 with ZPRFCTR03;

zrole4 with ZPRFCTR04;

zrole5 with ZPRFCTR05;

zrole6 with ZPRFCTR06;

If you looked in this case ZPRFCTR01 in RSECADMIN you would find the object 0PROFIT_CTR with the values 1 inside.

Also the program also creates for the same authorization the special characteristics 0tca* representing InfoProvider, validity, key-figure and activity.

I believe that was your question right?

Diogo.

Read only

0 Likes
1,383

Hello Diogo,

My question is another one ..any way.i got what i want..and also your answer will be the help full.

My problem is solved ...Thank you Diogo and Dimiatri. Points are assigned

B.K

Edited by: B.K on Jul 10, 2008 5:15 PM

Read only

Former Member
0 Likes
1,384

Hello B.K.

1)Once after running the migration in DEV How can i transport to the quality and producation... OR i have to run migration in quality and production again.?

You should do that in DEV system and then TRANSPORT IT TO QUALITY AND PRODUCTION (don't agree with you Dimitri). Of course you can run the migration program in all systems, but i don't believe that's the right approach. Here's what i believe is the better approach:

First: be sure that in RSSM you have the same authorizations objects in DEV, quality and production. Also be sure that in RSSM all the InfoProviders that you previously marked to check for those objects are equal to quality and production. Do the same for the definition of hierarchies. Normally when you're doing an upgrade and want also to do the migration of authorizations you do a copy of production to development, so you end up with a development system equal to production. In that case you can do all your changes in development with an equal system to production and then you can transport all your changes to production system without any problems.

Now after that, be sure you have the same roles defined in pfcg in production system equal to development system. If you're not sure you can mass download your developed roles (starts with Z or Y) in transaction pfcg in production system and then upload that file in development system in transaction pfcg (this is just like transporting all the roles from production to development). Again if you've already a copy of the system, or you're sure that all the roles that exist in production are the same and with the same definition in development system, no need to do this step!

Now the RSEC_MIGRATION program is built based on users. So the program searches for the roles assigned to the users. So if you have a role created in production system, this roles is assigned to several users, but in development system this role is not assigned to anyone (since is development and sometimes you don't need to assign to anyone, you only had created and transport it), the program is gonna skip that role, and therefore might skip the migration of some objects! To prevent this you MUST GUARANTEE THAT ALL ROLES THAT YOU WANT TO MIGRATE (starts with Z OR Y) ARE ASSIGNED TO AT LEAST ONE USER (You could create a Dummy user and assign all roles that aren't assigned to anyone for this particular purpose)

After this steps, and after running the migration program, you have to transport your changes to quality and production system. You can do this with two steps:

A). Go to rsecadmin transaction and click on button "Transp.". IT will be showed a list of objects. Mark all these objects and choose a transport request.

B). Go to transaction pfcg and choose mass transportation. Insert the list of all your Z or Y roles and create a request transport.

transport both the requests to quality and production system and there you go! The same migration of your authorization is in all the systems with transport. Now you can maintain your authorizations in DEV system and transport it to quality and production every time you want!

2) When iam try to see the authorization obj in rsecadmin> maintance>when iam giveing the old authorization obj and click on display system shows "obj not created"...what it mean. old obj are not shown in new system..? if we can see the old obj ..where we can...?

In transaction RSECADMIN you can only mantain the new authorizations objects (that were created during migration program and exist in table RSECVAL). Forget the old authorization objects that existed in RSSM. If you're using the new authorization concept Analysis Authorization, you'll no longer need those objects, and RSSM is gonna do nothing to your authorizations.

3)If user want to create a new authorization obj ..i will create the auth obj in rsec admin ...after then i have to migrate that one also?...or no need of the migration...?

No! If you choose in your RSEC_MIGRATION program the option of "enhance existing profiles", you should create your new authorization object in rsecadmin and assigned it to a role (could be a role that already exist for that particular authorization values or a new created one for a new group of authorization), and then assign that role to the user. You should not migrate any more after the migration is complete. You should maintain you new authorizations (create/change/delete)

4)How can i test the migrated authorizations.

To test your authorizations you can execute the queries with test users and see if whatever he/she is to be authorized for that InfoProvider (what existed in RSSM) is what he/she can see

<removed_by_moderator>

Diogo.

Edited by: Julius Bussche on Jul 10, 2008 9:53 AM