Pre- and post work of an SAP System refresh

It is a recurring task for the SAP Basis: the data of the quality and test systems become outdated, are thus less and less useful and must therefore be periodically updated with data from the productive system. For the SAP Basis, this is a high effort, and also under time pressure. After all, the systems should be available again quickly. With "Shortcut for SAP systems", most of the pre- and post-processing can be automated.

If you do not have the required license, you will see in this article, how information from the PCA tool can be used and a lot of pre- and post work can be done using "Shortcut for SAP systems".

Let's see how we can achieve this. First, let's see what the PCA tool can do for us. Hmm... I already wrote that we need a licence for this, so what else can we expect here? With the PCA tool we can get the information of the tables to be backed up (and restored after the system refresh). Even if the license may not be there and the configuration of the PCA tool requires additional effort, we can use it for getting the information about the relevant tables.

Ok, there are some values to be given as input: a choice between "Refresh" and "Data Cleanup" and an obligatory "Component". Unfortunately there is no F4 list available for the "Component". However, to shorten this: the execution of this report causes some problems. We do not know the "Component" up to now, and even if we would (try "RFC" for example), we would be faced with an error message:

Despite the program is not running, we can still use it for getting the information. A look into the source code shows that the information about the relevant components is hard-coded in function module SCTC_GET_ALL_COMPONENTS and from there the information about the assigned tables is in Include SCTC_SC_INCL_COMPONENTS.

Let's try it. A popup appears:

We choose the "Sys.refresh-Export" option. As this article is about SAP system refresh, first we have to export data in front of the system refresh, therefore we follow the sequence.

Another popup appears:

Table NRIV contains the number ranges. This table is listed more than once and is therefore part of multiple components. Let's get back to the list and filter it for table NRIV:

For components OFFICE_ATT, SAP_OFFICE, SWU3 and SWU3_DATA only parts of the table would be considered. For components SNRO and NRIV all records of the NRIV table would be considered.

Our aim is to get recent data of the productive system via system refresh - including all the business documents, where lots of them have a document number, received from the number range method based on the NRIV table. If we save the whole NRIV table - the last given number for each number range object is part of it - and restore it after the system refresh, we will run into problems when it is about creating new documents. Assuming that on our Quality system currently there are less documents than on the Productive system, the last given number in the NRIV table is already occupied.

Next attempt for generating the XML file.

After clicking on the button "Sys.refresh-Export" the warning popup does not appear anymore. Now we are asked for some paths.

First path is for the destination of the files containing the exported data. I prefer to have a dedicated directory for the files from the system refresh, so I created a directory systemrefresh in DIR_HOME.

The second path is about a temp directory on your frontend. Tables where only a selective amount of data is to be processed (like NRIV, DOKIL and TADIR) can (currently) not processed with the "Process table data using R3trans" function, so for these functions the "Download / upload table data" function will be used. As it is about downloading data from the SAP system, the frontend is involved. However, finally all data will be stored in the directory on the SAP server, so this is only a temporary storage.

Ok, so my input for this popup is this:

Now we are asked for a directory and filename of the XML file:

After specifying folder and filename another information comes up:

Let's have a look into the file:

For each component we find a <Task> in the XML file, containing all the tables from the list to be exported into a file. In most cases R3trans is used, in some cases the "Download / upload table data" function is used. When the "Download / upload table data" is used for a table, a corresponding <UploadFile> task exists with the given SAP directory as target.

There is only one modification of the XML file needed.

As some data is to be downloaded, a connection using a user with dialog capabilities is necessary.

After specifying a suitable connection in the XML file, we call the command line tool for processing it.

During the execution of the tasks you can have a look into the specified target directory and see the files being created:

After few minutes (which is of course depending on the amount of data in your system) the execution finished.

Having again a look into AL11 we find for every R3trans file also a log file. Let's have a look into one of them:

Now let's make a jump to the time when the systems database is overwritten with the one from the source system. As you know some data has to be adjusted - this is all the stuff with the manual reconfiguration of lots of settings like SAP Connect, the server groups, CCMS configuration, TMS configuration, logical paths and files, the SAP license, logon groups, operation modes etc. etc. etc.

We are going to do this by restoring the saved data. All of the mentioned topics are covered in the tables we saved in front of the system refresh - so by restoring these data we will have the same status in the overwritten system as before.

As mentioned above, there is a "Data cleanup" task to be executed in front of the restore. Let's go back to our program and generate an XML file for this.

After clicking the "Execute" button we receive the list and again we use the "XML file" button and specify the system on the SAP server.

As it is about deletion of data no data files will be created. The directory on the SAP server is only for the log files.

After this we are asked again about directory and filename of the XML file.

After this the creation of the XML file is done in less than a second. Again a popup with some information about the content of the XML file comes up:

There is a hint: SRT_MONILOG_VIEW (is not a table)

That is correct, it is a view, using table SRT_MONILOG_DATA. This table is part of the "Refresh" set and also in the "Data cleanup" set, so it is exported, will be emptied and is to be imported again. By doing this with the table also the view will have the same data as before - it is not clear to me why the PCA tool lists this view here.

The created XML file looks similar to the one created for the Export. The R3trans command has changed from <Export> to <Remove> and instead of a <ServerFile> we now have a <ServerLogFile> (as it is about deletion of data, we do not have a data file).

After adjusting the connection (line 3) I start again the command line tool.

Ooops, return code 4. A warning. As we do this the first time, we should find the reason and see if something has gone wrong.

The command line tool updates the XML file after processing it. So instead of scrolling in the console it is more comfortable to search for details in the XML file.

The log file shows the reason of it:

Here a warning was given because all tables were already empty. R3trans had nothing to do, so it quitted with a warning.

There were some more return codes 4, and all of them had the same reason.

If you have a look into the SAP system, you will find some impacts of the data cleanup. This is STMS after deleting some TMS data:

Also some other areas look empty: batch input session (SM35), shortdumps (ST22), ...

The Data cleanup part took ~1 minute only on the system. As it is about deletion of data and the amount of tables is smaller than for the previously done 'Export' part, also the needed time is less.

Now let's do the last step (and the most exciting of all): importing the saved data again. Coming back to our XML file generation tool: let's use the "Refresh" option again and create an XML file. As we filtered out the components NRIV and SNRO for the export, we do the same now (if you forget it, you will be faced again with the warning popup).

We store the file near to the others and name it accordingly:

Again the generation of the XML file is done within a second and we see some information about the content of the XML file.

The generated XML file looks very similar to the one generated for the Export. Some task types changed the direction: <Export> has turned to <Import>, <DownloadTableData> to <UploadTableData> and <UploadFile> to <DownloadFile>. After specifying the connection in line 3 the XML file is ready for execution.

Now start the command line tool for processing the XML file. It takes more time than the Export.

Now we find 2 warnings in the logs:

The first warning "Selective import specified" is because of the SELECT statements for each table that is stored in the file, and the second warning is because R3trans notices that the file used for import has its origin on the same system. Yes, that is exactly what we did - export and import on the same system.

We can ignore these warnings, they are the same for every task.

The import tasks needed significantly more time than the export tasks: ~27 minutes on my small system. This is because updating the tables in general needs more time than just reading the data. Beside others indexes are to be considered, rollback segments are to be managed by the database etc.

The log files look a little bit different from the 'export' ones, pointing to the fact that it is here about update / insertion instead of simple reading:

 

Let's have a look into the system now. The TMS looks fine again, also the batch input sessions and the SAP Connect settings in transaction SCOT look like before the system refresh.