In a previous article we described a method to save your system specific data of your SAP system - data, which can not be taken from another system as it is unique for your SAP system, for example RFC connections and a lot of configuration data belonging to ALE, SAP Office, SAP Connect, the Security Audit Log and many more. In case something goes wrong with this data, it could be a hard task or nearly impossible to restore / reconfigure these settings - there is no other system with the same data, so you do not have any possibility to have a look or create a transport request.
Recently I found this in the SAP community forum (https://answers.sap.com/questions/13551577/sicf-accidently-activated-the-entire-tree.html):
A simple wrong click (which might happen every day, no one is safe from this, it can happen to anyone), and now there is a big problem to get back to the previous settings!
The answer to the question - in a nutshell - is: no, there is no way. There are some tools available in the area of the service definition, like exporting the active services and a mass activation tool, but typically there is no export file, and consequently nothing on which you can start the recovery. And the mentioned tools are specific to the service definitions, so you have to know about them and use them, and in this case it would be necessary to do that manually (because the export feature can be used in a dialog session only - no way to schedule it so that it will be executed periodically and automatically).
But with "Shortcut for SAP systems" you can use a generic approach, fitting to the service definitions as well as to many other settings. As written above we described this in another blog article - focused on the dialog function "Process table data using R3trans", dealing with the tables for the RFC connection. If we want to backup all system specific data periodically, using the command line tool is the preferable solution.
So here is a description of how you can set up a daily backup of system-specific data for being able to restore corrupted settings within a few minutes if necessary.
Ok, but which tables contain the system-specific data? Difficult to figure out... fortunately the SAP system gives us this information! We can use the "PCA tool" (Post Copy Automation). This tool is part of the SAP Landscape Management, enterprise edition software and SAP Landscape Management Cloud software. To use the full scope of its functions, you must either own an SAP Landscape Management, enterprise edition license or an SAP Landscape Management Cloud subscription. If this does not fit to your situation, you can not use it and likely not all software parts of the PCA tool are available in your system. But the good news is, that in every case we can use it to determine the tables which are worth to consider them in a backup.
1st step: Use the program Z_SHOW_PCA_TABLES supplied with our product (folder ABAPs, file 'ShowPCATables.txt', or download it here) to get the complete list. Execute it by using the option "REFRESH" and you will get a list of components and their related tables in a single big list.
So this is the overall amount of components and tables that will be handled by the PCA tool (if you have the necessary license) in the context of a system refresh.
Above the table, you will find a button "XML file". With this button the ABAP program can generate an XML file that can be used by "Shortcut for SAP systems" - to be more precise, by the command line tool - for backing up the tables in files.
If you want, you can use the ALV filter and/or the selection mark in the 1st row to reduce the amount of components and/or tables. As this article is about backing up system specific data, we simply take all of the components and tables.
2nd step: Click on the "XML file" button
Now you will be asked for your intention. There are 3 options available: "Backup", "Sys.refresh-Export" and "Sys.refresh-Import".
Afterwards you will be asked for a directory for the created files on the SAP system as well as for a directory on your frontend for temporary files.
Personally, I prefer to not flood DIR_HOME with the files from the backup, so I recommend to create a dedicated directory (e.g. backup) below DIR_HOME for the backup files.
Some tables are to be backed up with reduced data - e.g. NRIV (number ranges), DOKIL (Login screen), TADIR (keeping the information about the system changeability). The "Process table data using R3trans" function can (currently) process the whole table data only, resp. all data in a client in case the table is client dependent. For backing up these tables the "Download / upload table data" is used, enabling us to select the data quite flexibly. As it is about download from the SAP system, the frontend is involved, and for this an existing directory on the frontend is necessary.
The next dialog window is about the location and the filename of the XML file.
After this the XML file is quickly generated. You will get some information about the content of the generated XML file.
Ok, let's have a look into the generated XML file.
For every component we will find a <Task> tag, addressing a function in "Shortcut for SAP systems" and keeping all necessary information to execute it. Most tasks addresses the "Process table data using R3trans" function in "Shortcut for SAP systems". Some tasks (related to tables NRIV, DOKIL, TADIR) addresses the "Download / upload table data" function, and we will find also some file uploads (via the "Download / upload server file" function). Finally all backup files will be stored in the SAP system in the specified directory.
Very less in the XML file is to be adjusted: in the 3rd line the connection is to be specified.
Here I enter the connection to my PX1 system. Nothing else is to be adjusted, so finally the XML file looks like this:
As written before the XML file is intended to be processed by the command line tool. So, let's execute it.
With this one-liner the content of all PCA components with their tables will be written into files in the SAP system:
It takes a few minutes. At the end you can see in the last message from the command line tool whether errors occurred or everything is fine.
You can also have a look into the XML file - the command line tool updates it after its execution and writes some information into it.
Having a look into the directory in the SAP system you can see lots of files. For each R3trans file you will also find a log file.
The log files were created by R3trans and contain some information about the tables and the amount of processed records.
More or less that's all! Using the command line tool and the XML file we can schedule a daily backup of this data. This can be done using a lean solution like the Windows Task Scheduler or a full-blown automation solution like UC4©.
In a nutshell, there is very little effort to set it up:
- create a backup directory on the SAP server
- create the XML file with the supplied ABAP program (this should be done individually for each system line on the development system, because the amount of tables depends on the SAP release and installed software components).
- schedule the one-liner (calling the command line tool with the XML file as argument) periodically.
In total: 5 minutes per SAP system? What little effort for such a huuuuge gain in security in your SAP operations.
If we get into the situation that by mistake the whole SICF tree was activated (like the unlucky guy mentioned above), we can easily restore the data in a minute. Just use the "Process table data using R3trans" function, use the file containing the data and enter the tables to be restored. All this information is also still available in the XML file.
After taking over the data from the XML file and clicking on the Execute button the data will be restored in few seconds.
There is a warning given. The reason for this is visible in the log file:
The first warning is because R3trans was executed with the 'SELECT * from...' statements. R3trans also allows an Import with giving only the data file, in that case all data from all tables in the data file will be processed. As here the tables are given, R3trans remarks this as 'Selective import specified' and gives a warning. This can be ignored.
The other warning comes up, because R3trans found that the data file was created on the same system. Yes, that's typical for a backup. Also this warning can be ignored.
Due to table buffering it may take few minutes after executing the import (you may have a look into the open synchronizations by using transaction AL12), but finally the SICF tree will be the same as at the time the backup was made!
So, this would be an easy way to get more security in the operability of your SAP systems. In my opinion this should be done for every productively used system. Even if there are doubts that a simple import of the stored data might not be the best approach to fix a recent problem with lost data, the data is there and could also be used to restore it on another system - as an intermediate system where the data can be verified and adjusted if necessary. Once the data is available and usable, the possibilities are correspondingly diverse. Is the user department missing an important variant for a report which can not be recreated easily? Ok, let's make a backup of the variants on a test system, then restore the variants data from the backup of our productive system on the test system, put the variant into a transport request, release the transport request and finally restore the variants on the test system. Likely you will be the hero of the day.
The alternative to this easily done backup of system specific data is a point-in-time recovery of the whole system - if you exactly know the point in time when the data got lost. In practice, this would be a disaster and the very last way out and likely would create more problems than solving it - I never noticed that this really has been done on a productive system. You could also think about a point-in-time recovery on another (test) system, but also this option has some hurdles: you need to have the hardware resources and it is quite time-consuming. Likely it would take days instead of some minutes. The above described backup method can be set up with less effort and provides a tremendous increase in the ability to quickly fix a problem in your SAP systems.
Es gibt noch keine Rezension.