This article is related especially to the requirement for a new client on a test system. On productive systems it's about mostly one client only, and on a development system the requirement for new clients is seldom. But for test system the request comes up quite often.
Ok, so what is the problem...
Creating a new client in SCC4 is done quite easily and quickly. But then... how to get into the newly created client? The client is empty, there is no data and of course also no users. In this case, SAP plans to use the hard-coded SAP* user, which can also be used to log on, even though it does not actually exist.
But in general the possibility of using the SAP* user should be avoided, it's a kind of an open door to the system. Therefore for avoiding the access to the SAP* user there is a profile parameter login/no_automatic_user_sapstar which is by default set to 1 which means: no login using the (non existing) user SAP* is possible. Of course you can change this profile parameter to 0 but this profile parameter is not dynamically switchable and a restart of the system is necessary for taking effect of the changed value. Afterwards you could use the SAP* user, but of course the profile parameter should be switched back to its original value and another restart is necessary.
Often you will find this situation regarding the SAP* user (which is a good method, I support this):
- profile parameter login/no_automatic_user_sapstar set to 1 which disables the login with a (non-existing) user SAP*
- user SAP* created in the clients, but locked by admin and without any authorizations.
And this points us into the direction that we need to change the profile parameter in the profile editor and restart the system. Hmm, cumbersome... in case the system is currently in use you have to deal with the stakeholders about a downtime (or more precise: 2 downtimes) and of course there will be the usual side-effects raised from a system restart like failed jobs, failed update tasks etc. Maybe the project leaders raise the idea to do this at the weekend. Congrats!
Another possible method would be to do a client export of an already existing client of your system (transaction SCC8, profile SAP_USER). This would create 3 transport requests which could be used for import into the new client. However, the import has to be done differently from the usual procedure because umode 18 is necessary which can't be set via STMS. Thus, you have to use tp via OS command.
Ok, we see it's of course not impossible, but there should be an easier and shorter way to deal with the access to the new client. Let's see whether we can shortcut this...
Yes, of course we can, otherwise I wouldn't have written this blog ;-)
Here is a step-by-step guide.
Let us have a look again at the "Process table data using R3trans" function and the tables related to users. Same as in the blog about saving system specific tables we have a look into the function module of the PCA tool for the tables.:
The list of tables is quite long. In sum there are (in my system here) 136 tables related to users named in the function module. Copy the source code lines of the function module to a text editor and use the text editor to reduce the text to the table names - using the replace function this can be done in a minute (replace all occurrences of "APPEND '" and " to l_tab_tablist." with nothing). Or use the program SCTC_LIST_TABLES or this modified copy of it to get the tables into the clipboard a little bit easier.
Though the number of 136 tables seems to be a big amount: as we use client 000 in this example the amount of data is not so big, and exporting the data needed less than 10 seconds. Notice that in this example we defined that the data file is to be stored on the frontend, our computer. This requires an SAP connection that uses a user with dialog capabilities. A convenient side-effect is that we will see an SAP screen with some information about the done job. 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.
Of course you can also use the server as the location of the data (and log) file, in that case you can use a system user. In this example I use the frontend and a connection with a dialog user.
So, now we have a file with R3trans data containing users. And, as there were also the AGR_... tables given we also have the roles in it.
Now do the import of this data in our new client (here: 100). There are only 2 input fields to be changed: switch from "Export" to "Import" and use the target client, now. We do not need a connection to the target client (which is not possible of course, because there is no user up to now - that's what we want to change here). We can still use the same SAP connection we used for the export. Only the "Client" field has to be changed to the target client.
Pressing on "Execute" Sc4SAP comes up with a confirmation dialog, containing also an information that might be of interest:
Okay... that is a point we did not consider when we did the export. There is the possibility that importing also the client-independent data could have some effects to the other clients...
Sc4SAP gives the information of client-dependency for every table entered in the input field and did this also when we entered the tables for the export. I think it might be better to consider the client-dependent tables only for avoiding any side-effects to other clients in the system.
Ok, it's still not too late to do so. So let's stop here for the moment, cancel the confirmation dialog and reduce the tables in the input field to those which are client-dependent. We can use a text editor for this (here: Notepad++, free available and useful for lots of things). Copy the messages of Sc4SAP regarding the client-dependency into a new window and select the lines with "client dependent".
After pressing the button "Find All in Current Document" a 2nd window comes up with all hits:
A right mouse-click, followed by "Select All" and the same for "Copy" copies all 125 tables into the clipboard. In a new editor window we can paste the lines and reduce the data leaving the table names only (simply use the "Replace" function to replace all texts "Table " and " is client dependent." with nothing). Then switch to Sc4SAP and replace the content in the "Tables" input field with the reduced amount of (now 125) tables (maybe it sounds a little bit cumbersome, but it is a task of a minute only). And let us do the export again. It would be also possible to reduce the amount of data to the client-dependent tables for the import. The other tables would not be processed. But I would like to have this tidy for later requests of new clients for the system, and doing the export is a task of few seconds only. Spending these few seconds for repeating the export will preserve me in future of dealing with the separation of client-dependent and client-independent tables when I have to use the same data file later again (for other clients). Thus, switch the R3trans operation back to "Export" and client "000" again and repeat the export. See the screenshot above in this article.
After having created the data file with client-dependent data only we use "Import" and the target client to create user and authorization data in the target client. We will be asked for confirmation again, but now without the warning about client-independent data:
Yes, we are sure, and pressing "OK" starts the action.
It takes noticably longer than the export (the import of data into the database causes more effort than reading), but after approx. a minute we see the feedback from the SAP system. Hmm, a warning...
Thus, let's have a look into the log file for the warning(s). Press the "Back" button in the SAP window to enable the GUI in Sc4SAP again. By pressing the button with the glasses the log file will be shown in a separate window.
The warnings in the log file of R3trans have a "W" in the 2nd column (the first column is a log level that is used in the SAP system for expanding and collapsing a log). There are 2 warnings in it:
This warning tells us that we specified the tables to be imported. R3trans allows also to leave the naming of the tables blank, in that case R3trans take the whole content of the data file. We specified all the tables, so this did not make a difference and we can ignore the warning.
This is the other warning, later in the log file:
That's true, we used the same system to transfer users and authorizations from client 000 to client 100.
Ok, finally we are at the end. Now check if we can log into our new client. We copied all the user tables from client 000 into client 100, therefore we expect to have the same users and the same passwords:
Tataaa.... we logged in.
Looking a little bit around in our new client offers no big surprises. We find the same users and the same roles in our freshly created new client. We did not have to deal with profile parameters and restarts of the system. And although this article got quite long and extensive, the time necessary for doing it was quite short and the tasks can be done in a few minutes. And: the data file can be used again for getting into another new client on the system or a new client on another system. This could be done now in a few minutes, without the need for profile parameter changes and restarting the system!
In a 2nd try I reduced the tables. As I chose client 000 as source, containing users (also mine) with profile SAP_ALL, it is not necessary to copy all the roles. It should be enough to copy the USR* tables (containing the users) and the UST* tables (containing the authorizations, e.g. the SAP_ALL profile), so I decreased the amount of tables to these:
USGRP; USGRP_USER; USGRPT; USR_CUST; USR01; USR02; USR04; USR05; USR06; USR06SYS; USR08; USR10; USR11; USR12; USR13; USR14; USR22; USRACL; USRACLEXT; USRATTR; USREFUS; USREXTID; USREXTID_IDM; USREXTIDH; USRSTAMP; UST04; UST10C; UST10S; UST12
The result was the same: I could log into the new client with my user credentials from the source client.
So, until now we shortcut the login into the new client, but - except some tables for user and roles - all the important tables are still empty (addresses, number intervals, country settings etc.etc.etc.... in short: the whole customizing). Without this data not much more than a login into the client is possible - which was the target we wanted to achieve, and we did it.
Therefore, after now having the access to the new client you can (and have to) continue like you would do as usual, e.g. with performing a client copy in SCCL using profile SAP_CUST (Customizing). Means: enable now the SAP* user (mostly it is created in the systems with respect to the security gap related to this user, otherwise you can create the user now), assign SAP_ALL and use the SAP* user to perform a client copy with the new created client as the target.