Archiving 

Purpose

This process is used to activate data from implemented archiving objects in which the structure and composition of the data awaiting archiving is determined. In doing so, the data is replicated outside of the SAP systems after the archive files have been checked. Then the archived data test is read and, if it has been successful, removed from the operational database. Data must be archived for the following reasons:

·        To reduce the system load on the servers

·        To minimize the total amount of data

·        To minimize the index trees

·        To minimize data selection in case of queries

·        To optimize buffer utilization

·        To restrict the number of hits

·        To avoid displacement mechanisms

·        To minimize network load

In SEM Banking, data archiving has been implemented for the following archiving objects:

Archiving Objects in SEM Banking

Technical Name	Archiving Object	Parallel Processing
JB_COLL	SEM Banking: Global Collateral	X
JB_FCTY	SEM Banking: Facilities	X
JB_FOBJ	SEM Banking: Financial Object	X
JB_FOCF	SEM Banking: Financial Object – Cash Flows	X
JB_GETR	SEM Banking: Generic Transaction	X
JB_GPAN	SEM Banking: Gap Analysis	X
JB_GPTP	SEM Banking: Opportunity Interest Rates from Gap Analysis	X
JB_GTVS	SEM Banking: Generic Transaction - Versions	X
JB_LOAN	SEM Banking: Loans Data Pool	X
JB_VTBA	SEM Banking: Variable Transaction - Balances	X
JB_VTMD	SEM Banking: Variable Transaction – Master Data	X
JB_VTTO	SEM Banking: Variable Transaction - Turnover	X
COPA1_*	Costing-Based CO-PA, Operating concern*
RDBRA_REC	SEM Banking+TRM: RDB Risk Analyzer Individual Records
RM_SVSTATE	SEM Banking+TRM: Risk Management – Data Pool Statuses
RM_BDS	SEM Banking+TRM: RM – Report Data Memory
TRTM_LM	SEM Banking+TRM: TR Limit Management - Limits, Utilizations

 

 

Prerequisites

You have made the necessary settings in the Implementation Guide (IMG) for SEM Banking by choosing SAP Banking  ® SEM Banking  ® Data Pool  ® Tools ® Archiving and Parallel Processing:

·        Archiving ® Maintain File Names and File Paths Across all Clients:
You must have maintained the path and the convention for forming archive file names for each archiving object using the FILE basic settings (logical file path and file names).

·        Archiving ® Edit Basic Settings for Archiving Objects:
You must have maintained the archiving objects fully in the AOBJ basic settings.

·        Archiving ® Archiving with Parallel Processing ® Create Number Range for Activity Log.

·        Archiving ®Archiving with Parallel Processing ® Use Global Archiving Control.

·        Archiving ® Archiving with Parallel Processing ® Edit Global Archiving Control:
You have maintained the global control of archiving and the check table for the global control for all implemented archiving objects.

·        Archiving ® Archiving with Parallel Processing ® Define Residence Time for....:
You have maintained the residence periods for the archiving objects in the object-specific Customizing settings.

·        Parallel Processing ® Maintain Job Distribution:
You have maintained the job distribution for parallel processing for the application types assigned to the archiving objects.

You are authorized to perform the archiving process. The system checks authorization object S_ARCHIVE for all activities.

Process Flow

Note that the following process applies only to archiving objects with parallel processing.

 

The archiving process is scheduled via the normal SAP job control. This can be executed using transaction SM36 or archive administration SARA. The archiving process is designed in such a way that it can run in parallel with the productive operations. The archiving process basically consists of three subprocesses: analysis, write, and delete. These are linked together in the standard set-up. Both the analysis and write subprocesses are processed in parallel using the parallel processing tool. This is done by forming suitable data packages that are then processed in parallel by different package administrators (jobs).

All subprocesses flag their activities in the archiving activity log, which can be displayed using the monitoring program. The monitoring program is the central tool for monitoring and logging archiving runs

1. Analysis

The analysis subprocess examines the data of an archiving object and determines the archiving status and resubmission date, if applicable. Two checks are always made for this:

·        Has the data completed the retention periods defined in the Customizing settings (minimum storage period for data in the operational database)?

·        Have all the business-related requirements been met in order for the data to be archived? This test is implemented using a check module of the application.

If both checks are successful, the archiving status is set to “Can Be Archived”. If not, the status is set to “Cannot Be Archived” and the resubmission date to “Today’s Date + Resubmission Period”. The resubmission period specifies the time periods for resubmission after the retention period has been completed and is defined in the global Customizing settings for each archiving object. This ensures that the data is not analyzed again until after the resubmission period, thereby reducing the amount of data that has to be processed and saving time in the analysis.

To increase efficiency, the data is divided into separate packages that are analyzed by package administrators (mutually independent jobs). Packages contain a partial amount of the data to be processed; this amount is precisely defined by key limits.

The following figure depicts parallel processing. When parallel processing starts, the parallel processing tool takes control. This calls up callback routines to execute the individual substeps of the process. Archiving provides these routines for each application type (cross-product of archiving object and subprocess to be executed in parallel [in other words, analysis and write]). You make settings in Customizing for parallel processing to determine the number of package administrators that you want to be used for each application type. Package administrators process different subpackages that they take from a worklist shared with all the other package administrators.

The time sequence for the process status is depicted on the left-hand side of the figure. The activity log always shows the most up-to-date status of a process. There are two possible final statuses indicating a successfully completed process, depending on the Customizing settings: “31” indicates that a WRITE subprocess has started automatically and “30” indicates that the analysis subprocess has ended and no WRITE process has started.

2. Write

In the standard set-up, the write program is started automatically by the analysis program and duplicates the data flagged previously by the analysis subprocess (status: “Can Be Archived”) from the operational database to new archive files. The actual data archiving is therefore executed in this step.

Data is written, as in the analysis process, in parallel in mutually independent jobs (package administrators – see figure). All package administrators process different subpackages that they take from the joint worklist. There is always just one archive package created per package administrator in parallel processing; this may consist of one or more archive files.

3. Delete

Once the data has been duplicated to the archive files, it is removed from the operational database using the delete subprocess. To do this, the archived data is read from the archive files and only deleted from the database if it is read successfully from the archive. This procedure ensures that data is only removed from the database if it has been archived successfully.

If the write process has closed an individual archive file successfully, a separate delete process is started automatically in the standard set-up. There are therefore only ever as many delete processes created per package in the write program parallel processing as the number of archive files this package created.

If the test reading of an archive file fails, the data remains in the operational system with the status “Can Be Archived” and is processed again during the write process in the next archiving run. The archive files that have already been created can be deleted manually or simply left in the archive. The latter option is safe, as no reference is made to the files from the operational system. This is because archive information structures are only created after the successful conclusion of a delete process.

 

Result

Successful Conclusion

Once archiving has been completed according to rule, the data that can be archived, from a business-related and technical perspective, is moved from the operational database into archive files. You can use the sequential read programs and the archiving information system (transaction SARI) to display the archiving files.

Reloading the Data

You have the option of recovering archived data using reload programs. During this process, data is read from the archive files and inserted into the operational database. This is, however, only permitted as an emergency strategy (incorrect Customizing settings, technical problems). To prevent this function from being misused and inconsistencies from occurring owing to old data being imported into the operational system, data may only be reloaded within a period of five days after successful archiving. The archive information structures are not updated during the reload process and can be restructured explicitly by the user via transaction SARI. The “Archive Status” attribute of the reloaded data records is set to “Cannot Be Archived” and the resubmission date is not adjusted. Note: The reloaded data records are written to the archive again in the next archiving run. (If you do not want this to occur, you must alter the Customizing setting for the retention periods accordingly).

Storing the Archive Files

It is generally not sufficient just to write the data that is to be archived to archive files and remove it from the database. The archive files themselves must be stored safely and managed to permit any access required at a later time. There are several different options for this:

·        HSM systems (hierarchical storage management)

An unlimited file system is simulated for an HSM system. The file system into which the data is archived is integrated into the memory hierarchy of the HSM system. It is sufficient to maintain the file path accordingly in the archiving Customizing settings. No communication via the SAP ArchiveLink is required.

·        Storage system via SAP ArchiveLink

If a storage system of a third-party administrator is connected via the SAP ArchiveLink, this storage system is ordered to store the processed archive file at the end of a successfully completed delete program.

·        Manual management

If you do not want the files to be stored in a storage system, the IT department can manage the archive files independently instead.

 

Example

The Variable Transaction archiving object is used in this example.

Additional Information

For more information, see the program documentation for the archiving objects.

The names of the programs are constructed as follows:

·        Analysis              RJBD_*_ARCH_ANALYZE

·        Write       RJBD_*_ARCH_WRITE

·        Delete                  RJBD_*_ARCH_DELETE

·        Reload           RJBD_*_ARCH_RELOAD

Replace * with the technical name of the archiving object (see table at the start of this document) without the “JB_”.

Example:

·        The program names of archiving object JB_VTMD (variable transaction master data) are as follows:

·        Analysis              RJBD_VTMD_ARCH_ANALYZE

·        Write       RJBD_VTMD_ARCH_WRITE

·        Delete                  RJBD_VTMD_ARCH_DELETE

·        Reload           RJBD_VTMD_ARCH_RELOAD

Note that in the case of archiving object GAP opportunity interest rates (JB_GPTP), the program names start with RJBR, for example RJBR_GPTP_ARCH_WRITE for the write program.

For the other archiving objects (see table) the program names are as follows:

RDBRA_REC (RDB Risk Analyzer individual records) 

·        Write program:           RDBRA_REC_ARC

·        Delete program:                RDBRA_REC_DEL

 

TRTM_LM (TR Limit Management: Limits, Utilizations)

·        Write program:           RFTBARC1

·        Delete program:                RFTBARC2

·        Reload program:         RFTBARC3

COPA1_* (Costing-Based CO-PA, Operating Concern *): See the online documentation under Accounting ® Controlling ® Profitability Analysis (CO-PA) ® Tools ®Archiving.