Automation, automation...
“I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.” (Bill Gates)
With respect to this statement from Bill Gates (and he is for sure not the only one with this opinion), let's see how we can move into this direction - towards to laziness, avoiding many repetitive, boring, time-consuming and annoying tasks.
Automation is one of the key factors to a well-running IT landscape and it accommodates both our need for laziness and safety in operations.
Although many things are possible in SAP, there are still some gaps that make life unnecessarily difficult, especially for administrators. So if you are an SAP administrator and/or interested in making your life easier during system copies or go-lives, here are ways to make some tasks easier.
Think about:
- Re-creating the system users after a system copy
- Setting passwords for them
- Dealing with the system-specific data before / after a system copy
Edit: With version 1.2.1 from the command line tool this article is a little bit outdated, especially regarding the work for a system refresh. Have a look at this blog article:
When using XML files you do not need variants anymore.
In the subfolder 'xml' you will also find example files for doing the pre work in front of a system refresh (identically to saving the system specific data) and for doing the post work (cleaning some tables and re-importing the saved data). The also supplied ABAP program (subfolder 'ABAPs', file 'ShowPCATables.txt') makes it so easy to generate XML files for the purpose of backing up system specific data as well as for automatism of pre- and post-processing in the context of a system refresh. Also user locking, unlocking and logging off, copying users and setting passwords can be automated.
Let's start with saving the system users before and re-creating them after the system copy.
We can use the "Copy user" function to store the system users in a file in front of the system copy and to re-create them out of the file after the system copy. To implement this in an automated process we can use the command line tool, which comes with our product.
First we have to specify the system users to be stored in the file. Some users are not necessary to store and re-create them (for instance the DDIC user and the one used for the TMS), but most of the system users are used exclusively on the system and would get lost if we do not save them. Beside the system users there could be some others to be kept, for instance an emergency user.
We save these values in a variant using the 
button at the upper right of the window:
button at the upper right of the window:
Now it is on creating another variant for re-creating the users (reading them out of the file and creating them in the system). If the file does not exist yet, we have to execute the copy process now - otherwise we could not create the variant for re-creating them because the function claims that the file does not exist.
Once we executed the "store" part we can create the variant for restoring the users out of the file. Switch the "From" and "To" data and store the settings in a second variant:
Now we have the variants for storing and restoring the system users. Let us move to the command line tool. It is located in the same folder and is named with "Sc4SAPCmd.exe".
Opening the console and executing it offers some information how to use it:
In a nutshell: 1st parameter is the function, 2nd parameter is the variant. Thus, for copying the users into the file it is this:
sc4sapcmd copyuser "QX1/100 syscopy store"
If I would have given a non-existing variant, the command line tool would claim about this. But I did it correctly, and so the copy user function was executed:
Similar to what we have seen using the GUI application. Ok, it worked.
Because I did not set the "Overwrite existing users?" flag, I can also test the 2nd step. I expect that it works in general, but no users are to be overwritten, so finally it does not cause any change in my system:
sc4sapcmd copyuser "QX1/100 syscopy restore"
...
After a system copy the situation will be different and missing users will be re-created.
There is one issue I have to take into account: the user used in the connection has to be valid even after the system copy! If there is one with the same login data that I can use, fine! If not, I have to ensure that the connection to the system used for the re-creation of the users also works after the system copy is done.
After the system users have been re-created, the passwords are to be set. I use the "Set password" function to do so, the fields for the users and the passwords can easily be filled via clipboard. Saving the data in a variant enables me to execute it via the command line tool.
Back again to the console, using the command line tool:
sc4sapcmd setpassword "QX1/100 systemuser"
...
For me as an admin using the command line tool is not easier than using the GUI application.
But, and this is the real benefit, it enables me to offer simple executable scripts to save and restore the users during a system copy process and set the correct passwords. In automation solutions such small one-liners can be integrated in existing automatisms to be executed at any time.
Now let's have a look at another task mentioned above: dealing with system-specific data before and after a system copy. There are lots of them, e.g. the RFC tables, the TMS configuration, the license key and many more. Maybe you have already some scripts or similar to ease your life for some of these, but usually there is still some gap where you have to prepare or finish the system copy by manual tasks.
I would like to draw your attention to the "Process data using R3trans" function, which can make life much easier regarding system copies. I prepared some variants to save system-specific tables in front of a system copy. As in the scope of a system copy only the database is copied and not the whole filesystem of the application server, I used the DIR_HOME directory to store all the data files.
Regarding the granularity I did it similar to the grouping of tables in the "PCA" tool (you can find some information in this blog article). However, you can also use fewer variants with more tables and group them as you like.
Some basic components of the PCA tool are available in all(?) SAP systems with an ABAP stack. You can execute the program SCTC_LIST_TABLES to show tables of a component. However, due to license issues (the use of the PCA tool requires some prerequesites) the program might deny your request. In that case you can try this program which is a modified copy of it, showing all components managed by the PCA tool and their related tables in one big list. And here is the output of the program taken from my local SAP system (NW AS ABAP 7.52).
Having all these variants prepared I made a small script file on OS level and stored it in a subdirectory "scripts":
Starting this file on OS level launches the command line tool with function "Process data using R3trans" with the given variants and saves the data of all the tables in files on the application server.
...
In AL11 we can see all the created files, containing the data that is to be kept and restored for the system copy.
Based on the export variants, the variants for importing the data again in the post-work phase can be created quite easily: just take the variants and for each of the variant just change the R3trans action from "Export" to "Import" and store it as "...import..." variant.
Between exporting and importing the data again some tables are preferrably to be emptied. In the PCA tool there is a differentiation between "Refresh" and "Truncate". Whereas the "Refresh" option belongs to the tables to be exported before the system copy and imported again after the system copy, the "Truncate" option belongs to tables that are to be emptied in front of the import. The list of tables is much smaller than by using the "Refresh" option. For example, the T000 table will not be removed - because if this table is emptied, no login into the system would be possible anymore. Also the RFC tables are not listed, due to similar reasons (without some basic RFC connections, e.g. SAPGUI_QUEUE, lots of shortdumps would occur and simple functions using the SAPGUI would abort).
So, let's choose all of the given tables and create variants for removing the contents of these tables.
Then combine all the "Remove / Clientremove" commands in a script as already done for the "Export" variants and do the same for the "Import" commands. In sum you should have 3 single command files, one for "Export", one for "Remove / Clientremove" and one for "Import" (the last 2 files can also be combined into one). With this you can do the pre-work and the post-work of a system copy via one-liners! And to go one step further, the availability of the functions on OS level even makes it possible to integrate the script files into automatic procedures that you might have already in use for system copies.
Isn't this much smarter as doing the same manual administrative stuff like TMS configuration, SAP Connect settings etc. again and again, consuming more time, possibly (rather old-fashioned) based on some screenshots you had to do before the system copy and with the possible error rate that inevitably accompanies manual work? It saves me manual (and thus error-prone) work at potentially inconvenient hours, and on top of that, the time savings are enormous! The command line tool also makes it possible to integrate these tasks into an automated process, thus avoiding the typical break between automated and manual operations at this point in the flow of a system copy. In this way, manpower and also processing time can be saved. And, to come back to the intention mentioned at the beginning of this article, I can be a little lazier again....
Es gibt noch keine Rezension.