Data Archiving and Deletion in Account
Management (FS-AM) 
Purpose
You can use these processes to archive the data from the archiving and deletion objects implemented in which the structure and composition of the data to be archived or deleted is defined, or to delete this data from the database without archiving.
· The archiving process involves the data being copied to archive files outside the SAP System after various checks, then test-read and removed from the operational database if successfully archived.
· Deletion involves the data being removed from the operational database immediately.
Both data archiving and data deletion enable you to:
· Reduce the system load on the server
· Minimize the overall volume of data
· Minimize the index trees
· Minimize the selection variants for queries
· Optimize the buffer utilization
· Minimize the number of hits
· Avoid replacement operations
· Minimize the network load
You can find information about all archiving and deletion objects in Account Management (FS-AM) in Customizing for Account Management in the IMG activity Technical Documentation in Account Management. When you start the IMG activity, a structure appears. In the Concepts and Guidelines ® Archiving section, you can find an overview from which you can navigate to all the documents on the individual archiving and deletion objects. Note that the Archiving Engine and the Archiving Factory can or must be used for some archiving objects.
Prerequisites
· You have made the settings required in Customizing for Account Management under Archiving:
¡ Cross-Archiving Object Customizing
¡ Create Logical File Path
¡ Archiving Object-Specific Customizing
¡ Maintain Global Archiving Control
¡ Maintain Global Control with the Archiving Engine
· You have executed the relevant IMG activity for each archiving object in Customizing for Account Management by choosing Archiving ® Archiving Objects.
· You have executed the IMG activity Maintain Job Distribution in Customizing for Account Management under Tools ® Parallel Processing.
· You are authorized to execute the archiving process. The S_ARCHIVE authorization object is checked for all activities.
Process Flow
The archiving process is scheduled using the normal SAP job control. This can be executed by transaction SM36 or the SARA archive administration. The archiving process is structured so it can run in parallel to the live operations. The archiving process basically consists of three subprocesses; analysis, write, and delete. These are linked together in the standard system. The analysis and write subprocesses can be processed in parallel if you use the parallel processing tool. This is achieved by forming suitable data packages that are processed in parallel by different package administrators (jobs).
The pre-step is an optional subprocess used to form package profiles and must run before the archiving process.
All subprocesses record their activities in the archiving activity log, which can be displayed by the monitor program. The monitor program is the central tool for monitoring and logging archiving runs.
1. Pre-step
The pre-step subprocess firstly examines the dataset of the archiving object, and then generates corresponding profiles that specify the package limits for parallel processing. The profiles are stored persistently in the database and then used later by the analysis andwrite subprocesses, if set in the global Customizing for the archiving object.
The aim of the profile generation is to run the parallel package administrators equally, in terms of capacity, in the analysis andwrite subprocesses in order to minimize the overall runtime of the archiving process. To this end, the dataset must be divided into separate packages of an equal size, as far as possible. Since the distribution of data can change over time, the pre-step must be repeated at regular intervals to ensure suitable profiles exist.
The pre-step is an optional subprocess and is not implemented for all archiving objects.
2. Analysis
The analysis subprocess examines the archiving object data, then determines the archiving status and resubmission date. Two checks run during the process:
· Has the data reached the residence times defined in Customizing (minimum retention period for data in the operational database)?
· Have all the business-related prerequisites for archiving data been met? This test is made by a check module in the application that, in turn, enables user-defined checks to be made with BAdIs.
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.
A = base date for archiving + residence time + 1 day
B = system date + resubmission period
The longest period of the two is used (A or B).
The resubmission period determines the time periods for the resubmission after the residence time expires and is defined for each archiving object in the global Customizing. This ensures that the data is not analyzed again until the resubmission period has elapsed. This can reduce the amount of data to be processed, thereby saving time in the analysis process.
To increase efficiency, the data is divided into separate packages that are analyzed by mutually independent jobs. Each package contains a subset of data to be processed, precisely defined by key limits.
The graphic below shows the process of parallel processing. When parallel processing starts, the parallel processing tool takes control. This calls up callback routines to execute the individual process steps. These routines are provided by archiving for each application type. There are two application types for each archiving object; one for the analysis subprocess and one for the write subprocess. You make settings in Customizing for parallel processing to determine the number of jobs that you want to use for each application type. Each job processes different subpackages, taken sequentially from a worklist shared by all jobs.
The left-hand side of the graphic shows the time sequence for the process status. The activity log always shows the most up-to-date status of a process. There are two possible final statuses indicating a successful process, depending on the Customizing setting: 31 means a write subprocess was started automatically and 30 means the analysis subprocess ended and no write process was started.
3. Write
In the standard set-up, the write program is started automatically by the analysis program. It copies the data flagged by the analysis subprocess (status Can Be Archived) from the operational database to new archive files. It is therefore in this step that the data is actually archived.
The data is written in parallel, mutually-independent jobs, as in the analysis process (see graphic). Each job processes different subpackages taken from the joint worklist. There is only ever one archiving run, consisting of one or more archive files, for each job in parallel processing.
The left-hand side of the graphic shows the time sequence for the process status. The activity log always shows the most up-to-date status of a process. There are two possible final statuses indicating a successful process, depending on the Customizing setting: 32 means a delete subprocess was started automatically and 30 means the analysis subprocess ended and no delete process was started.
4. Delete
Once the data has been duplicated to the archive files, it is removed from the operational database using the delete subprocess. To this end, 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 system (see the graphic for the write subprocess). Therefore, for each package in parallel processing of the write program, there are the same number of delete processes as the number of archive files created by this package.
If the test reading of an archive file fails, the data remains in the operational system with the status Can Be Archived and is then processed again by the write process in the next archiving run. You can either manually delete the archive files that have already been created or leave them in the archive. The latter option is harmless since the files are not referred to from the operational system: Archive information structures are only created if a delete process is completed successfully.
Result
Successful Conclusion
Once the archiving process has run correctly, the data that is archivable from a business and technical viewpoint is moved from the operational database into archive files. It can be displayed on the screen using either the sequential read programs implemented, the archive information system (transaction SARI), or the related business view(s). For some archiving objects, such as account and card, the archived data is displayed using the normal display transactions.
Data Reload
You have the option of recovering archived data using reload programs. These read the data from the archive files and insert it into the operational database. However, this is only permitted in an emergency (incorrect Customizing settings or technical problems). To prevent this function from being misused and possible inconsistencies from occurring through bringing old data back into the operational system, data can only be reloaded within a period of five days after successful archiving. The archive information structures are not updated by the reload process and can be reconstructed explicitly by users with the SARI transaction. The archiving 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 happen, you must adjust the Customizing setting for the residence times accordingly).
Archive File Storage
It is generally not sufficient simply to write the data to be archived to archive files and then remove it from the database. The archive files themselves must be stored securely and managed to permit later access if required. There are several different options for this:
· HSM systems (Hierarchical Storage Management)
HSM systems simulate infinitely large file systems. This means that the file system in which the files are archived is included in the memory hierarchy of the HSM system. It is sufficient to maintain the file path in the archiving Customizing. You do not need to communicate via the SAP ArchiveLink.
· Storage system through SAP ArchiveLink
If a third-party provider’s storage system is connected using the SAP ArchiveLink, this storage system stores the processed archive file when a delete program is successfully completed.
· Manual management
If the data does not have to be stored in a storage system, the archive files can also be managed independently by the IT department.