A system copy is a frequent requirement of the business department or project. Test systems constantly have to be set up and productive data mirrored. A lot of work can be saved by backing up certain data from the target system beforehand. Here is how to do it.
Save users
The number of users in a system can sometimes reach obscene proportions. In large corporations, 5-6 digit user numbers (mostly in the central ERP systems) are not uncommon.
The task of re-creating and authorizing these users and their roles after mirroring the productive data into the test environment can only please someone who has fallen madly in love with SU01. In order not to overuse the – quite practical – detour via CATT, since actually only the old status is to be restored, one can make use of the client copy tools.
Here we make use of an interesting circumstance: The client copy profile SAP_USER does not contain the „Initialize“ parameter. This means that a client exported with SAP_USER does not overwrite any data in the target except for the user and role information (unlike other selective profiles such as SAP_CUST).
Therefore, before the system copy in the target system, we can put a SAP_USER client export in the file system, which we import back into the system after the copy using stms_import. The exact procedure is as follows:
- Check the file system space in TRANS_DIR (see SE38 / RSPARAM).
Depending on the number of users a few MB up to several hundred MB necessary.
- Check the SCC4 in the source client
The client must not be locked against client export in the T000, otherwise the SCC8 cannot be called. The following setting would be too restrictive:
- Preparing the client export
SCC8 – client copy profile SAP_USER – schedule in background. The job should not run very long for normal clients (<1h). The target of the transport is ideally a virtual system, so you can manually append the client transports to the import queue later.
Tip : For experienced admins with huge clients, the report RSCCEXPT (accessible in SCC8 via Edit / Expert Settings) is intended. Here you can configure parallel processes and maintain exclusion tables. For the house and yard use the standard settings should be sufficient in 90% of the cases however.
Either way, don’t click on anything you don’t know you need!
- Convert system copy
After the export job has run successfully (monitorable under SCC3 / Exports), you should first (if you haven’t already) write down the transport name – SCC3 -> Exports -> Source client -> Copy run -> bottom right starting with KT.
The next step of the blog assumes that the scheduled system copy has completed successfully.
- Import users and follow up
After system copy, append the previously exported transport (name from SCC3) to your import queue in stms_import via Extras -> More Requests -> Append and start import.
- Import postprocessing
After the import is complete, start transaction SCC7 in the target client to start the postprocessing. Again, you can track the status via SCC3. Once this is complete, you have successfully completed the user recovery.
Congratulations!
Rescuing RFC Destinations
Rescuing RFC destinations saves you the tedious task of creating connection data and descriptions. What it can’t save you (since the introduction of SECSTORE) is the re-entering of the passwords into the individual connection entries, or the migration of the secure storage afterwards.
The procedure described here involves a certain risk, because SAP standard procedures are left and changes are made directly in database tables. Only experienced administrators should perform these activities, secure themselves beforehand with backups and also test beforehand in non-critical environments. The procedure described here worked up to and including release 7.01. I have not yet been able to test 7.1 and 7.3, mind you there is no guarantee of functionality, as SAP can adjust the function and persistence of RFCDES at any time via notes or support packages (see also „The Mandatory“).
The data for the RFC connections is mainly hidden in the RFCDES table, but also scatters into other RFC tables with properties and links. Accordingly, the export command looks like this:
ora: exp / TABLES=RFCDES, RFCATTRIB, RFCCMC, RFCDOC, RFCSYSACL, RFCTRUST file=TABLES_RFC.dump log=TABLES_RFC.log compress=no
If the SAPR3.RFCDOC table does not exist, do not worry, the export will still work.
After the system copy is finished, the RFC tables are emptied and then the RFC destinations are imported:
truncate table SAPR3.RFCDES;
truncate table SAPR3.RFCATTRIB;
truncate table SAPR3.RFCCMC;
truncate table SAPR3.RFCSYSACL;
truncate table SAPR3.RFCTRUST;
truncate table SAPR3.RFCDOC;
ora : imp / TABLES=RFCDES, RFCATTRIB, RFCCMC, RFCDOC, RFCSYSACL, RFCTRUST file=TABLES_RFC.dump ignore=yes
You can then use Secure Storage Migration (SMP -> Keys and Orders -> Migration Keys -> Secure Storage Migration) to request and import a migration key, or simply reset the passwords in SM59.
The Mandatory
This documentation is a collection of empirical values, and has not been tested or approved in any form by the product manufacturers (SAP, Oracle, ..). No liability can be assumed for damages resulting from following this documentation (partially or completely).
Of course I am happy about questions, comments or additions.
