Introduction: We might come across data in Access Control and Process Control applications which are relatively old or obsolete in nature and need to be archived to avoid system performance issues when the data volume rises.

The archiving function provides the choice to store away unneeded historical data so that the different features/applications will be able to function more quickly with a reduced dataset. This information is kept in the system, but it can be brought up again by restoring it if required. In this blog, we will keep our focus in archiving data related to Access Requests.

Step-by-step Procedure:

Prior to archiving data, we must first identify or create the archiving object. Go to transaction AOBJ and under the node Archiving Object, filter for GR* and SPM* using the Position button to find standard archiving objects available for GRC applications.

In this case (GRFND_A/V8100/SP09), the following archiving objects are available. Since the aim is to archive data related to access requests, GRFNMSMP is the object used for this purpose.

When there is a requirement to archive a specific set of data, just for instance, not all tables configured under the archiving object GRFNMSMP are required to be archived, the following sequence of steps can be followed:

Execute transaction AOBJ and create a new object by clicking on New Entries. Enter information like the object name, text, application component information along with the programs for Write, Delete, Reload and/or Read functionalities.

Then go to the Structure Definition sub-dialog and define the structure (tables) that need to be archived. For example:

Go to the Customizing Settings sub-dialog and define the archive file ARCHIVE_DATA_FILE

Optionally, you can assign a read program to the archive object in the Read Program sub-dialog, if you want to read the archived data. For example:

Now, since we have already identified the archiving object GRFNMSMP, double click on the object to validate if the programs for Write, Delete and Reload are already tagged to the object.

Providing additional context, Write, Delete, Reload, Read are the steps involved in an archiving process. First, data is written with respect to an archiving object which is then stored based on the parameters defined in the logical filename under Customizing Settings in transaction AOBJ.

Second step is deletion, where the data is deleted from the respective tables included in the archiving object definition.

Reloading is the third step, for reloading the deleted data. However, it is not generally recommended as it might lead to inconsistencies in the system. Alternatively, the archived data can still be read using the program tagged to the object under Read Programs in transaction AOBJ as mentioned above, without the need to reload the deleted data.

Note: Write, Delete, Reload and/or Read activities can also be performed using the Archive Administration tool (transaction SARA) provided the archiving object is known already.

Write Data of Old Access Requests for Archiving: Go to transaction SA38 and enter the program GRFNMW_ARCHIVE_WRITE as shown above. Run the program in Test mode first to see the expected results. This step will however not result in data deletion and the archived data will still be visible in SAP tables and NWBC screens.

Output:

Delete Data of Old Access Requests for Archiving:

Go to transaction SA38 and enter the program GRFNMW_ARCHIVE_DELETE as shown above. Run the program in Test mode first to see the expected results. After executing this step, the archived data will no longer be visible in NWBC screens.

Select the sessions to be deleted:

Output:

Reload Data of Old Access Requests for Archiving:

Go to transaction SA38 and enter the program GRFNMW_ARCHIVE_RELOAD as shown above. Run the program in Test mode first to see the expected results.

Select the archived session to be reloaded and click on Continue:

Output:

Conclusion: Archiving can be an effective way to keep records securely maintained and accessible, with improved storage efficiency, improved security, and easier access to read-on-demand feature. However, to ensure data integrity and security, appropriate processes and policies need to be followed prior to executing any archiving activity in the system.