The "Copy user" function in "Shortcut for SAP systems" offers a lot of possibilities. It is very handy, quite fast und very flexible. Here are some use cases that can be covered with this function.
- Your test system will be refreshed via system copy from the productive system. With the system copy all users on your test system will be deleted resp. replaced with the users of the productive system. But... some test users will get lost, also the members of the project team, the system users will be the wrong ones, which would result in non-working interfaces, and last not least you will have also the much more restrictive authorizations on your test system. With that situation a continuation of the current test would not be possible and a lot of time and effort would be necessary to add the missing users and the extended authorizations.
Ok, of course it's not the first time this happens, and meanwhile you are dealing somehow with it. Possibly you have the PCA tool in use, which enables you to keep users and authorizations in front of a system copy and replace that data afterwards again.
Or you use a client copy to somewhere in front of the system copy (to another new client on another system) and do the same in the other direction afterwards. But it's all very elaborate, cumbersome and time-consuming, and you are under pressure because of the tight schedule of the project (as ever), unfortunately sacrificing another weekend :-(
Or, that's simply not what is needed. For example, the project team wants to test under circumstances that are as near to the productive environment as possible, so using the users and authorizations from the productive system is a good idea in general. But of course there are exceptions: special test users were created, and also the system users are different from those in the productive environment. So, there is still the need to adjust the users.
- For every new system or client you have to create the administrative users. Depending on your organization and the role of the client (000 or a client with business data) this could be more than only a small number of users. And, btw, creating them one by one in SU01 is boring.
Also this problem is not new. You can think of solving it via a client copy from another client that already keeps the administrative users. For this you have to create an RFC connection on the source system and perform a client copy. Also a CUA (central user administration) system would offer functions in this area - accompanied by the usual inconveniences and problems of a CUA... Or maybe you have an Identity Management System offering functions for this. However, it's always a lot of effort.
- You are faced with a roll-in project or merge of systems or clients, and users from multiple clients have to be migrated to a single target client.
Or, just the other way round, in a carve-out project users selectively are to be migrated to another system.
So let's have a look at the "Copy user" function. The most valuable features of it are in my opinion:
- you can specify the users you want to process. This is completely different from the SAP client copy, where no selection is possible.
- you can use a file as target as well as the source. This means that for saving the users you don't have to create a new client on another systems, including RFC connections. Just use a file as storage for the users, and use it again as a source when you want to copy the users into a client. It works even with a huge amount of users (we tested it successfully with an amount of ~150000 users).
It is so easy. For storing all users of a client just a few steps are necessary and the users are stored in a file. Specify source and target (in this case a file on your computer), press the "Execute" button, that's it. In this example we use a file on our computer for storing the users, therefore an SAP connection using a user with dialog capabilities is needed. In case you copy the users from an SAP client directly to another one or you use a file on the SAP system you can also use a connection with a system user.
In this example only a small amount of users are in the source client which of course results in a small data file. But also for clients with a huge amount of users the procedure works reliable. Data files will be splitted at a filesize of approx. 100MB, the filename will be extended by ".Partn" where n is incremented. Sc4SAP stores an ".info" file beside the data file on your computer. Keep data file(s) and ".info" file together in the same directory.
Now let us use the file to copy them into another client (here: 100). We select the file as the source and address the client 100 in the system as the target.
For creating the file we didn't restricted the amount of users and took all ("*"). Sc4SAP now offers all users for which is data in the selected file. Having a look at them there are some I don't want to copy because they already exist in client 100, therefore I leave the "Overwrite" flag empty and don't change the user ID's in the text field. But the possibility is there, and in case you want to reduce the amount of users to be copied you can do that!
Thus, let's start....
Connection established, starting to copy... but errors came up:
Ok, have a look into the messages for what the user copy process is claiming about. By using the most right button above the messages we see it all a little bit more comfortable than in the small message area. Obviously it is a general problem with the address data:
In every user master data record there is an address number belonging to the company address maintained in SUCOMP. This data is client-dependent and the company addresses in the target client are not the same as in the source client. Therefore the creation of the relation between the user master record and the company address fails. In case you have set up the target client as a copy from the source client this error should not occurr. But here we have a client with other company addresses.
For my purpose the company address is not important, so I decide to use the option to do the copy without the relation to the company address:
Now it looks better, the copy process is working and it's quite fast. After some seconds it is finished.
Now it looks fine. Already existing users were not copied, but the others were. If I had chosen to overwrite users the user used in the SAP connection should not be specified in the input field for the User ID's! During the copy process the authorizations temporarily get lost which would cause an abort of the copy process. Also overwriting of the own user should be well considered - in this case it's the same.
So finally 59 users were copied successfully to the target client. I did not have to struggle with a CUA or an Identity Management system, I did not need to maintain RFC connections or wait for others to maintain RFC connections. I can use the same data file to copy the users again, possibly into the same client after a system copy or another client on another system.
But there is still one issue: the passwords. Maybe you recognized that there is an input field in the copy function for the initial password which I filled with a value. In case you leave it empty a password will be generated (you will get the individual passwords in the messages). In case you missed this somehow: there is nothing that can not be done afterwards with the "Set password" function which gaves us the possibility to assign the same initial password or assign randomly generated passwords.
"Shortcut for SAP systems" uses the function modules from SAP which are intended to deal with the users. To name the most relevant here: BAPI_USER_GET_DETAIL (for reading the user from the source client) and BAPI_USER_CREATE (to create the user in the target client). The function modules don't offer the possibility to copy also the passwords.
If it's ok that the users will have either the same password (as given in the "Copy user" function) or a randomly generated password, then the job is finished here. The users exist in the target client and it took only few minutes. We can use the same data file for other clients, either on the same or another system. This procedure looks suitable e.g. to create a base stock of basis and system admins and some system users on every new client and can be carried out easily and fast.
If your aim is that the copied users will have the same passwords than in the source client we have to do an additional task: copy the USR02 entries for the copied users (the USR02 table is an essential table for the users on the system and contains the individual passwords, stored in hash values). This can be done with the "Download / Upload table data" function. For avoiding that the password will be changed for users that will not come with the data file we reduce the download to the specific amount of users by giving a "where" clause.
After pressing the "Execute" button an SAP screen comes up with a confirmation message. For continuing your work in Sc4SAP you have to press the "Back" button in the SAP window, otherwise Sc4SAP does not recognize that the SAP system has finished its task and still waits for the completion.
For copying the passwords of the users to the target client we now have to use an SAP connection to the target client and use the "Upload" option. After pressing the "OK" button in the appearing confirmation dialog the data are uploaded to the target client.
After 2 seconds an SAP screen appears:
Ah, ok. There are already USR02 records for the 59 users, and overwriting them is exactly what I wanted to do. I forgot to set this flag in the dialog:
After setting this flag and a new execution I received what I expected:
The users in the target client now have the same passwords as in the source client.
Consider that, due to the fact that we copied the USR02 records, also attributes like the lock status have been copied. Therefore there might be the need that you have to unlock users.
I don't want to finish this article without giving some warnings and hints:
- In the "Copy user" function you should take care that the user used in the SAP connection will not be overwritten. Otherwise the copy process might abort because during the copy operation the authorizations of the user gets lost (at least temporarily, but that would be enough to abort the task).
- The function for downloading/uploading and deleting table entries is very critical! Please, please be quite sure what you are doing with these functions.