Between releases 2.2 and 3.0, new archiving methods were developed in the R/3 Basis system. These allow, for example, for compressed storage of archived files as well as connection to optical archives. At the same time, a new architecture provides absolute data security, parallel processing and an identical user interface for archiving programs spanning all applications.
The archiving and reloading programs in FI were reworked to take advantage of this new functionality. The following text will go into more detail about these changes, particularly as to how they affect customizing, the user interface and functionality.
You can find non-application-dependent documentation for the architecture as well as for general customizing in the "BC Extended Function Library Applications" and "System Administration" documents.
Further documentation on this topic:
Release note
"Changes in Document Archiving"
Release note
"Archiving and Retrieval of Check Data"
Note: The following program names have only been added to provide more
detail. You would normally select the required function directly via the menu,
or by using the new transaction SARA:
Accounting->Financial accounting->General
ledger,
Periodic
processing->Archiving-><Object>
Under the previous archiving architecture, objects were sequentially read from the database, checked for suitability for archiving, saved to a file and then deleted from the directory. This "block" processing had the disadvantage that it could not perform these steps simultaneously. There was also the slight danger of data loss in the case of a system crash, if at that point in time the files were not completely saved in the file system (which is why SAP recommended that a database backup should be performed before archiving, a step which has been eliminated in the new FI archiving program).
The new architecture, however, which has already been in use in this form for document archiving, will separate the selection of dataset archiving from the deletion process. Therefore, an archiving program exists for each type of object, which reads the data to be archived from the database and writes it to a file. Finally, a deletion program for each archive file begins, which once again reads the data to be deleted from the file and deletes it from the database. Thus, with this architecture, the deletion and archiving programs can be executed in tandem. Moreover, in SAP's view, complete data security is guaranteed because each archived file is stored in the database before deletion.
In the following section, an overview of the archiving objects which have
been changed in FI, as well as the programs to which they belong, is provided
(second name is the old name prior to Release 2.2).
Two new objects were added to Archiving in version 3.0. Each of the new
objects also has a Release Note.
The archive administration has been reworked in the course of the latest
conversion, one effect of this is that the maintenance transaction F040 has
been eliminated. For each object, the new archive administration can be called
up by selecting
Accounting->Financial accounting->General
ledger,
Periodic processing->Archiving->
<Object>->Administration,
or directly accessed through the SARA transaction. The administration is
non-application-dependent and is documented in "BC Extended Function Library
Applications" and "System Administration" documents.
In the new version, you always begin archiving and reloading programs via variants. This guarantees that archive administration will be able to store the selection in question. You can start the process either by the menu path mentioned above or directly through the SARA transaction. It is recommended that you avoid calling up these programs via transaction SE38 except for test purposes, or else the selection parameters will not be saved and the deletion programs will not start automatically.
The formatting of archive files was converted in Release 3.0. However, compatibility with earlier versions has been maintained, so that any older archived files can still be read. A conversion program transfers old administration data to the new archive administration system.
All archiving programs in a production run should, as far as possible, be
run in the background on the database server. If the system is configured for
the automatic startup of deletion programs, these will always run in
background mode on the server with the capacity to run them at that time. You
should therefore use the following path:
Tools->Administration, Jobs->Job
overview and "Execute" to check if your deletion programs ended
normally. Terminated deletion programs can be manually restarted in restart
mode, in order to locate errors or to delete all objects in a file.
The new archive files are, as before, stored in a file system established under a logical path name. The filename, however, is based on the logical path name. Both can be configured (see below).
If the system's settings specify that archive files should automatically be transported to the optical archive, the files will be deleted after a short period of time (when they are stored in the optical archive).
You can control the transport between the file system and the optical archive centrally, from archive administration. You can find descriptions of the necessary customizing and operation functions in the "BC Extended Function Library Applications" and "System Administration" documents.
The authorization group with the value F_002 is always maintained in the archiving program attributes. This way you can protect the archiving program from being started. To do this, you need to maintain an authorization with value F_002 for the S_PROGRAM authorization object and include it in the user profiles. The SAP_ALL authorization must then be withdrawn from the users.
An authorization check is also carried out on the basis of the data to be archived for particular objects; this way the company code authorization, for example, is taken into consideration in the document archiving.
Central customizing takes place in two areas. On the one hand, it allows you to determine the archiving process.
For further information, see the "General Task Functions" Implementation Guide in the chapter "Define control parameters for archiving sessions".
You also have to define the file names of the archive. Either the path or the name can be assigned. You should, however, bear in mind that the optical archive (if connected) has access to the given path.
For further information refer to the Basis Implementation Guide, chapters "Additional client-dependent filename maintenance" and "Client-independent maintenance of filenames and paths".
A special object-related configuration within FI is exclusively necessary for document archiving. Modifications to this can be found in release note "Changes in Document Archiving" . Configurations for index management as well as for document type and account life have also been added. All other objects are configured through central archiving customizing (transaction SAR3).
An exact description of each field is provided in the program documentation. The following section deals with the more general subdivision.
Archiving Programs
In the first part of the selection screen, the dataset to be archived can be restricted. Datasets are normally restricted by key concepts such as company code or fiscal year. In some cases, a key date for an archiving run can be entered to which a minimum time period rule applies. In the second part, both known options, test run and detail log, can be selected.
Deletion Programs
The selection screen for deletion programs is identical for all FI objects. Before 3.0, the system would request an archive number, which designated the files whose contents would be removed from the database. This has been eliminated in 3.0 thanks to a new selection popup menu. A manually controlled deletion via transaction SARA must take place for background processing. Finally, there are the known options test run and detail log, as well as the Restart Mode for error situations. The "Hold FI index" field which is additionally offered in document archiving, will be described in release note "Changes in Document Archiving".
Reloading Programs
The first part of the reloading program restricts the dataset to be reloaded. Objects which should or cannot be reloaded are combined in a new remainder file, and the files which were selected are invalidated. The last part of the program consists of the known options test run and detail log.
The logs consist of a detailed list (when activated), a statistical log and a run summary. The old record-by-record logs for transaction figures and bank master data have been eliminated.