Get into a new client without struggling with SAP*

Direkt zum Seiteninhalt

Get into a new client without struggling with SAP*

Veröffentlicht von Shortcut IT in Sc4SAP · 24 September 2019
Tags: SAP*R3trans
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 can use the PCA tool for getting the information about the tables. We use the ABAP program that comes with "Shortcut for SAP systems" and take all tables of category 'USER':

PCA tables for category 'USER'

Though the number of 135 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. 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.
Exporting USER tables with R3trans

A look into the log file offers some details about the exported data:
Details about the exported data in the log file

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.
Switching from Export to Import and selecting the new 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. Here we are going to do the import into the same system, so it would not make a difference. However, it is not a big issue to consider the client-dependent tables only and 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".
Searching for client dependent tables
After pressing the button "Find All in Current Document" a 2nd window comes up with all hits:
Identified client dependent tables via log file
A right mouse-click, followed by "Select All" and the same for "Copy" copies all 124 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 124) 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:
Importing the USER tables into the new client using R3trans

Yes, we are sure, and pressing "OK" starts the action.

It takes noticeably longer than the export (the import of data into the database causes more effort than reading), but after approx. 2 minutes we see the feedback from the SAP system. Hmm, a warning...
Import done with warning

Thus, let's have a look into the log file for the warning(s). By pressing again 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:
Warnings in the log file

The first 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 the client dependent tables only, so the statement about the 'selective import' is true, but we can ignore the warning. The statement of the other warning also is 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:
Log in into the new created client - without downtime!

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.


Es gibt noch keine Rezension.
0
0
0
0
0
Shortcut IT GmbH
Försterstr. 11A
31275 Lehrte

Zurück zum Seiteninhalt