Handling in case of a system-copy

[Former Member]

Hello,

one of my periodically jobs is to copy a PROD-System to the QAS-system.

I installed the Personas-Addon in each system (DEV, QAS and the PROD-System).

The QAS-Datas will be overwritten after the data-copy.

Is there a Screen-Personas feature/process to save the QAS-data?

Currently, I save the persos-Table-entries in a transport (transport of copies).

Is there anybody who has some experience in this case?

Regards Matthias

[Former Member]

Personas data is no different from any other data in you QAS system. If you do a system copy, it all goes. And so, if you need to put any of it back you need to save it somewhere first.

I have to ask, though, what Personas data do you have in your QAS system that's unique to that system? Do you not develop flavours in DEV first and transport them to QAS? If so, everything you need will be DEV and already on a transport, so you can just re-import the original transports, or else generate new transports from DEV.

Steve.

[Former Member]

Hello Steve,

you are right. We are creating our flavors and personas groups in the DEV-system. Afterwards we transport these settings to the other systems of the landscape. But how can I handle the members of the personas-groups, because we have different user-states in the QAS and the PROD-System. The QAS-R3-users will be saved in the system-copy's preparation-steps (tcode SCC8).

... PROD-users are not in the QAS-System:

not critical, because this users are no longer displayed in the personas admin-tcode

... QAS-users are not in the PROD-System:

for this users I have to create a new entry in the personas-group after the system-copy, right?

Matthias

[Former Member]

Yes, doing the obvious thing you would need to re-create the group assignments after the system copy. You can transport groups, which I think takes the user assignments too, doesn't it? That doesn't make sense when transporting between systems as, as you say, the users are all different, but you could maybe use this to put things back after the copy - add your groups to a transport in QAS, release it, do the system copy, and add the transport back to the QAS queue and import it. Worth a try.

However, I think you'll still have issues with the access control - that will also be copied from PRD and as far as I know there's no standard way to export/import that. If there aren't too many users it shouldn't be too hard to rebuild this by hand. There are other manual activities you need after a system copy anyway.

I guess your "transport of copies" method will work, but I just get nervous about hand crafting transport requests to move/save table contents without being 100% sure of what's going on with the tables. I'd rather use the official mechanisms and do some manual work, generally. But if you've tried it and it works, you might as well stick with it.

This is different in Personas 3, where the group concept doesn't exist. Flavour assignments are done via PFCG roles. The user/role assignment will get properly reinstated after the system copy but the flavour/role assignment probably still won't. That is included on a transport though, and should have been be done in DEV and transport to QAS in any case, so you can restore it that way.

That said, I haven't done a system copy since installing Personas 3, so I'm not yet sure about this.

Steve.

[former_member195167]

I personally think that the QAS-data would not be overwritten, rather, dual copies would be created. Maybe, Personas 3.0 solves the issue all instances are referred using ID's instead of NAME.

Nevertheless, your problem could be easily solved by creating an ABAP batch program that periodically stores the data from persos-tables into custom tables and then deletes it all from the standard tables making way for the new data to come in.