Show TOC

Archiving Request Administration DataLocate this document in the navigation structure


By archiving request administration data, you make sure that the request administration data does not impair the performance of your system.

Using the archive administration for the archiving object BWREQARCH you execute a write program. This program writes the administration data for selected requests in an archive file. After archiving, you execute a deletion program that deletes the administration data from the database.

You can set up the initial, as well as ongoing, archiving in one step if you schedule the archiving periodically with suitable selections.


You should be in the archive administration (transaction SARA).

  1. On the initial screen, choose the archiving object BWREQARCH.

  2. In the archiving object specific customizing, set up when after an archiving session the deletion program, which deletes the request administration data, should be run.

    1. Choose Customizing.

    2. On the following screen, choose Technical Settings.

    3. Choose Start Automatically in the Settings for Delete Program under Delete Jobs and save your entries. If necessary, enter a transport request.

      With this setting you make sure that the delete program RSREQARCH_DELETE starts automatically after the archiving session.


      If you want to manually control the archiving and the subsequent deletion of the archived data, choose Not Scheduled. You can then execute the delete program at any point after successful archiving. Note that the delete program cannot run in parallel to an archiving run; it has to be started after the archiving run. More than one delete program cannot run in parallel.

      We recommend that you execute the deletion program shortly after the write program. A request that is written by the write program to the new archive, but that is not deleted from the database by the deletion program, is inconsistent. Access to this type of request results in a dump in function module RSSM_RSSELDONE_READ.

    4. Go back and confirm the following dialog box.

      You are returned to the initial screen of the archive administration.

  3. Choose Write.

    The screen on which you schedule a background job for the write program appears.

  4. Select a variant.

  5. When you create a new variant, specify a variant name and choose Maintain.

    You are taken to the variant maintenance for the write program RSREQARCH_WRITE. Using different specifications in the variant, you limit which data should be archived and also make other setting that are independent of the archiving object.

    The request administration data to be archived is specified using various specifications.

    1. First, select a time period within which the requests with administration data to be archived should lie using Selection Date of Request.

      The requests that were loaded within the specified period are taken into account.

    2. Next, select how old the requests with administration data to be archived must be using Requests Older Than (Months).

      The months specified here are calculated as having 31 days.


      Choose the number of months so that the administration data of those requests that you do not expect to need is archived. In this way, you can avoid unnecessary reloading of the administration data.

      We recommend archiving the administration data of requests that are older than 3 months.

    3. Next, choose which "type" of requests should be archived:

      • Only Archive New Requests

        Only requests that have never been archived are taken into account.

      • Only Archive Reloaded Requests

        Only requests that were archived and have been reloaded are taken into account.

      • Archive All Requests

        All requests that are not currently archived are taken into account, new requests and requests that have been reloaded.


        We recommend you use Only Archive New Requests when you archive for the first time. In this way, you can check whether the archived request administration data had to be reloaded after a certain length of time and, if necessary, adjust the month specification.

    4. To archive the request administration data from data transfer process requests, choose With DTP Requests.

    5. Using Exclude DataSources, you can select DataSources from source systems for which the request administration data should be excluded from archiving.

    6. With Minimum Number of Requests, choose how many requests the write program must find that satisfy the selection conditions before the program creates an archive file.

      This specification is to avoid archives that are too small, and as a consequence of this too many archives being created.


      We recommend selecting at least 1,000 requests as the minimum. If your system will create a lot of requests, you can raise this setting to 9,999.

  6. Make any additional archiving object independent settings for the variants.

  7. Maintain the variant attributes and save them.

  8. Save the variant and go back to the previous screen.

  9. Maintain the start date and spool parameters.


    We recommend that you define the parameter for the start date so that the write program is executed periodically, that is, daily or on weekends.

    Note: Only one archiving session can run at any one specific time. You cannot start the write program RSREQARCH_WRITE in parallel to other archiving sessions.

  10. Choose Execute.


The system generates an archiving session at a specified start date for object BWREQARCH. The write program report RSREQARCH_WRITE is executed and the system writes the request administration data that meets the specified selection criteria and that is located in the tables RSREQDONE and RSSELDONE to an archive file.


When you archive the administration data of a request, a lock is set for the request. For this reason, the archiving run may affect performance when executing actions on requests (for example, calling the monitor). The administration data of a maximum of 10,000 requests is thus archived in one archiving session.

The deletion program RSREQARCH_DELETE starts after the archiving session. It verifies the archive files that the system has written and then deletes the entries for the archived requests from database tables. The system can only access the requests again once the archived request administration data has also been deleted from the database. This is necessary, for example, when reconstructing from the PSA.

During an initial archiving, the administration data of at most 10,000 requests that meet the selection criteria are archived per archiving session, and then deleted from the database. If archiving is periodically scheduled, archiving is executed for 10,000 requests each time until the administration data of all the old requests is archived. After this, an archive file is only created when a specified minimum number of requests has been reached.

More information :

Creating Archive Files

Maintenance of Variants for Archiving Jobs

Deleting Archived Data from the Database