Skip to Content

Applies to:

SAP BW NW 7.X. For more information, visit the Business Intelligence home page for Data ware house management.

Author:          MP Reddy

Company:      NTT DATA Global Delivery Services Private Limited

Created On:   4th August 2015

Author Bio  

Pitchireddy Mettu is a Principal Consultant at NTT DATA Global Delivery Services Private Limited from the SAP Analytics Practice.

Summary

In one BI system, the volume of data increases constantly. Constant changes to business and legal requirements mean that this data must be available for Longer. Since keeping a large volume of data in the system affects performance and increases administration efforts, we recommend BI administrator to apply Data archiving task if needed.

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

By archiving request administration data we make sure that the request administration data does not impair the performance of our system.

This guide gives a step-by-step demo to show how to Achieving BW Requests using BWREQARCH and reloading Achieved requests when needed.

Prerequisites

In our case the settings are already maintained for the object that we are archiving on the SAP BW system.

The objects that are archived are:

  • BWREQARCH
  • IDOC
  • WORKITEM

The checklist of archiving new objects is as followed

Process Flow

Before using an archiving object for the first time

  • Check archiving object-specific Customizing settings:
  • Was the file name is correctly assigned?
  • Are the deletion program variants maintained? (Note that the variants are client-specific)
  • Is the maximum archive file size correctly set?
  • Is the deletion program to run automatically?

File locations

File locations must be set in order to write the archive files. Currently the files are located in /local/data/storage/<SYSEMID>/archiving.

The section below explains the setup of the files. Unless specified by the support lead DO NOT CHANGE ANY OF THE SETTINGS.

This can be accessed via AL11 .

image1.JPG

File Names

The file names are generated automatically by the archiving tool. The current setup is as followed:

For BWREQARCH the customizing shows that ARCHIVE_DATA_FILE is used.

image2.JPG

The ARCHIVE_DATA_FILE has the mask <PARAM_1>_<PARAM_3>_<DATE>_<TIME>_<PARAM_2>.ARCHIVE
and uses the logical path ARCHIVE_GLOBAL_PATH

PARAM_1 = Type of system

PARAM_2 = Sequence number

PARAM_3 = Archiving Object

Archiving
  Object

PARAM_1

PARAM_2

PARAM_3

BWREQARCH

BW

0

BWREQARCH

image3.JPG

The ARCHIVE_GLOBAL_PATH is set to /local/data/storage/<SYSID>/archiving.

image4.JPG

In AL11 you can view the files created.

image5.JPG

Archive BW Requests

When archiving requests there are two steps to perform.

  1. Write the archive files
  2. Delete the data from the tables

Write the archive files

Start transaction code SARA – Fill in BWREQARCH

image6.JPG

First we need to write the archive log files.
In order to this we need to create a variant of what needs to be archived.

When installing a regular job we need to make the timing relative to the date. By default we archive requests older than 4 months.

image7.JPG

For a test run you can put the processing option to Test Mode, for actual archiving you can put the processing option to Production Mode. Keep With DTP Requests turned on as we also archive the DTP request information. Min. Number Requests will stay on 1000. This means that only if there are more than 1000 requests to archive it will actually start archiving.

image8.JPG

Manual writing with SARA

When running the manual jobs make sure that the username is has the correct authorization to run archive jobs.

Create the archive file once all the settings (Spool Params& Date) have been maintained.

image11.JPG

When the write is executed you can find the jobs running/finished.

image12.JPG

There will be two jobs, one with SUB in the name that will schedule the various write job(s).
The other job will have WRI in the name.

image13.JPG

Delete the data from the tables

When the request are writing into the archive files. The data can be deleted from the tables.

The next chapters will provide details on how to delete the BW-Request data once the archive files have been written.

Manual deletion with SARA

  Return to SARA and select Delete.

image14.JPG

  Click on Archive selection to select the file for deleting the actual entries from the table

image15.JPG

image16.JPG

When file is selected enter the start data for deletion of the entries from the table. Periodic scheduling only makes sense when the write
job is dynamically deleting the requests. As we are deleting once a month on a 4 month basis we can schedule the delete also periodically.

Be aware that the delete should not run during the write job and that there is enough time between the two activities.

When all settings (Spool params.and scheduled date) are maintained you can run the deletion job.

image20.JPG

In the job overview you should see a deletion job running/finished.

image21.JPG

Reloading Archived Requests

When the requests are archived they are still accessible when needed if

There are three ways of reloading the requests

  1. Reload the individual request from the DTP monitoring screen or InfoPackage monitoring screen
  2. Reload a complete archiving job (T-Code SARA)
  3. Reload multiple requests (T-Code RSREQARCH)

For reloading complete archive jobs or multiple requests look further down in the documents. The following sections shows how individual
requests can be reloaded from the archive.

Reload the individual request

Before retrieving the request from the archive, question yourself if the detailed data is needed. The header information of the request is still visible, only detailed messages are archived.

InfoPackage Requests

When displaying the request in the monitoring screen a popup will inform the user that the request is archived with a question to retrieve
the details from the archiving. By default do not reload the details when looking at an archived request unless it is really necessary.

image22.JPG

  An archived requests looks like this:

image23.JPG

  When an request is reloaded the data becomes visible again

image24.JPG

DTP Requests

When displaying the request there will not be a popup compared to InfoPackage requests. On the DTP overview screen you will see that the DTP is archived.

image25.JPG

By default the details will not show the details.

image26.JPG

On the menu you can reload the request from the archive.

image27.JPG

When the data is reloaded the details become visible again.

image28.JPG

Reload a complete archiving job :

When you want to reload a complete archiving job you have to reload is within T-Code SARA.

Run SARA and put in the archiving object. In the menu the Reload function becomes available.

image29.JPG

  Select a variant. There will be only two necessary variants as the selection screen will only give you option Test or Production mode.

image30.JPG

Select an Archive file.

image32.JPG

Maintain the start data and spool parameters like in the previous sections and run the reload activity.

image33.JPG

The job log will show if the reload has finished.

A job with REL in the name will run.

image35.JPG

Related Content

http://scn.sap.com/docs/DOC-30539

http://scn.sap.com/thread/1944220

http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/70ef2f01-641a-2d10-c59e-cf6d9e673926?QuickLink=index&overridelayout=true&47197395624637

https://help.sap.com/saphelp_nw73/helpdata/en/49/9500f79c1d311fe10000000a421938/content.htm

For more information, visit the Business Intelligence home page for Data ware house management.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply