BASIS_Week6 by irays

VIEWS: 727 PAGES: 125

									SAP Archiving Solutions

Rolf Gersbacher
Helmut Keul




                          Managing SAP Archiving Projects
                          Best Practices Model

                          Version 2.0

                          April 2000
Copyright
© Copyright 2000 SAP AG. All rights reserved.
No part of this documentation may be reproduced or transmitted in any form or for any purpose without the
express permission of SAP AG.
SAP AG further does not warrant the accuracy or completeness of the information, text, graphics, links or
other items contained within these materials. SAP AG shall not be liable for any special, indirect, incidental,
or consequential damages, including without limitation, lost revenues or lost profits, which may result from
the use of these materials. The information in this documentation is subject to change without notice and
does not represent a commitment on the part of SAP AG in the future.
Some software products marketed by SAP AG and its distributors contain proprietary software components
of other software vendors.
Microsoft®, WINDOWS®, NT® and EXCEL® and SQL-Server® are registered trademarks of Microsoft
Corporation.
IBM®, OS/2®, DB2/6000®, AIX®, OS/400® and AS/400® are a registered trademark of IBM Corporation.
OSF/Motif® is a registered trademark of Open Software Foundation.
ORACLE® is a registered trademark of ORACLE Corporation, California, USA.
INFORMIX®-OnLine for SAP is a registered trademark of Informix Software Incorporated.
UNIX® and X/Open® are registered trademarks of SCO Santa Cruz Operation.
ADABAS® is a registered trademark of Software AG.
SAP, the SAP logo, mySAP.com, R/2®, R/3®, RIVA®, ABAP/4®, SAPoffice®, SAPmail®, SAPaccess®,
SAP-EDI®, SAP ArchiveLink®, SAP EarlyWatch®, SAP Business Workflow®, R/3 Retail® are trademarks or
registered trademarks of SAP AG in Germany and in several other countries all over the world.
SAP AG assumes no responsibility for errors or omissions in these materials.
All rights reserved.
Symbols used
   Symbol                      Meaning
                               Caution

                               Example

                               Note
Version 2.0                                                                                                                          Managing SAP Archiving Projects




Contents
1      INTRODUCTION.....................................................................................................................................................6
    1.1        DOCUMENT OBJECTIVES AND CONTENTS ............................................................................................................6
    1.2        REQUIREMENTS OF DATA ARCHIVING .................................................................................................................7
2      DATA ARCHIVING IN THE R/3 SYSTEM .........................................................................................................8
    2.1     R/3 SYSTEM ARCHITECTURE ...............................................................................................................................8
    2.2     REASONS FOR ARCHIVING ...................................................................................................................................9
       2.2.1     IT Department ...........................................................................................................................................10
         2.2.1.1 Ensuring system availability .................................................................................................................11
         2.2.1.2 Maintaining performance ......................................................................................................................11
       2.2.2     User Departments .....................................................................................................................................11
    2.3     DATA OBJECTS IN THE R/3 SYSTEM ...................................................................................................................12
    2.4     IMPORTANT ARCHIVING TERMINOLOGY ............................................................................................................13
    2.5     APPLICATION-SPECIFIC ARCHIVING ..................................................................................................................13
    2.6     POSITIONING OF DATA ARCHIVING ....................................................................................................................14
    2.7     DATA PREVENTION ............................................................................................................................................17
       2.7.1     How do I identify unnecessary data? ........................................................................................................18
       2.7.2     Why is some data created automatically?.................................................................................................18
       2.7.3     How can the automatic creation of data be prevented?............................................................................18
3      DATA ARCHIVING AND INFORMATION RETENTION..............................................................................20
    3.1     INFORMATION RETENTION REQUIREMENTS .......................................................................................................20
       3.1.1    Legal Requirements...................................................................................................................................20
       3.1.2    Business Requirements..............................................................................................................................21
       3.1.3    Technical Requirements ............................................................................................................................22
    3.2     PRINT LISTS .......................................................................................................................................................22
    3.3     AUDIT INFORMATION SYSTEM ...........................................................................................................................23
    3.4     DATA RETENTION TOOL ....................................................................................................................................23
4      SAP R/3 DATA ARCHIVING CONCEPT...........................................................................................................26
    4.1     PROCESS FLOW ..................................................................................................................................................26
       4.1.1    Create Archive Files .................................................................................................................................26
       4.1.2    Execute Deletion Program........................................................................................................................27
       4.1.3    Store Archive Files....................................................................................................................................29
    4.2     DATA ARCHIVING FEATURES.............................................................................................................................29
       4.2.1    Archivability Checks .................................................................................................................................29
       4.2.2    Data Security During Archiving ...............................................................................................................30
       4.2.3    Archiving in Parallel with Live Operations ..............................................................................................30
       4.2.4    Data Compression and Conversion ..........................................................................................................30
       4.2.5    Connecting to External Storage Systems...................................................................................................31
       4.2.6    Access to Archived Data ...........................................................................................................................31
       4.2.7    Reloading Archived Data..........................................................................................................................31
    4.3     DATA ARCHIVING AND CURRENCY CONVERSION (EURO) .................................................................................32
5      TECHNICAL BACKGROUND ............................................................................................................................33
    5.1     INTRODUCTION ..................................................................................................................................................33
    5.2     BASIC TERMINOLOGY EXPLAINED .....................................................................................................................33
    5.3     ARCHIVE DEVELOPMENT KIT (ADK) ................................................................................................................34
    5.4     SAP ARCHIVELINK ...........................................................................................................................................35
    5.5     ARCHIVING ADMINISTRATION ...........................................................................................................................38
       5.5.1    Customizing...............................................................................................................................................38
       5.5.2    Archiving Session ......................................................................................................................................39
       5.5.3    Management of Archive Files ...................................................................................................................41
    5.6     RESTARTING ARCHIVING AFTER A PROGRAM TERMINATION ............................................................................43
       5.6.1    Termination Occurs During Write Program.............................................................................................43
         5.6.1.1 General scenario....................................................................................................................................43
         5.6.1.2 Special scenario.....................................................................................................................................44



© SAP AG                                                                                                                                                               Page 3
Managing SAP Archiving Projects                                                                                                                                   Version 2.0



       5.6.2    Termination Occurs During Deletion Program ........................................................................................45
         5.6.2.1 Archive files are accessible ...................................................................................................................45
         5.6.2.2 Archive files are not accessible .............................................................................................................46
       5.6.3    The most common causes ..........................................................................................................................47
    5.7     REORGANIZATION OF THE DATABASE................................................................................................................48
6      ACCESS TO ARCHIVED DATA .........................................................................................................................49
    6.1     SEQUENTIAL ACCESS .........................................................................................................................................49
    6.2     DIRECT ACCESS .................................................................................................................................................49
    6.3     SAP ARCHIVE INFORMATION SYSTEM ..............................................................................................................50
       6.3.1    Concept and Use .......................................................................................................................................50
       6.3.2    Components...............................................................................................................................................50
         6.3.2.1 Archive Retrieval Configurator.............................................................................................................51
         6.3.2.2 Archive Explorer...................................................................................................................................53
         6.3.2.3 Status management................................................................................................................................54
       6.3.3    Enhanced Display Options: Examples from SD........................................................................................54
         6.3.3.1 Setting up a business view ....................................................................................................................54
         6.3.3.2 Enhancing the SAP AS interface...........................................................................................................54
         6.3.3.3 Process-oriented retrieval......................................................................................................................56
7      SPECIAL APPLICATION-SPECIFIC ASPECTS OF DATA ARCHIVING ..................................................57
    7.1     CONTROLLING (CO) ..........................................................................................................................................57
       7.1.1   Table analysis using RARCCOA1 and RARCCOA2 .................................................................................58
       7.1.2   Determining Archiving Objects.................................................................................................................59
       7.1.3   Further Consideration of CO_ITEM.........................................................................................................59
    7.2     ARCHIVING IN THE EDI ENVIRONMENT .............................................................................................................60
       7.2.1   Archiving IDocs ........................................................................................................................................60
       7.2.2   Archiving Work Items................................................................................................................................61
    7.3     ARCHIVING IN A DISTRIBUTED SYSTEM ENVIRONMENT ....................................................................................62
       7.3.1   Example: A Distribution Scenario Within an Application ........................................................................64
8      PLANNING AND IMPLEMENTING AN ARCHIVING PROJECT ...............................................................66
    8.1     INTRODUCTION ..................................................................................................................................................66
    8.2     BUILDING THE PROJECT TEAM ...........................................................................................................................67
    8.3     ANALYSIS ..........................................................................................................................................................68
       8.3.1    Database and Performance Analysis ........................................................................................................68
       8.3.2    Identifying the Archiving Objects..............................................................................................................69
       8.3.3    Requirements of Archived Data ................................................................................................................71
         8.3.3.1 Business requirements...........................................................................................................................72
         8.3.3.2 IT requirements .....................................................................................................................................73
         8.3.3.3 Auditing requirements...........................................................................................................................74
    8.4     DESIGN AND CONCEPTION .................................................................................................................................74
       8.4.1    Creating an Archiving Concept.................................................................................................................75
         8.4.1.1 Business concept ...................................................................................................................................75
         8.4.1.2 Technical concept..................................................................................................................................76
       8.4.2    Setting Up an Implementation Plan ..........................................................................................................76
       8.4.3    Setting Up a Long-Term Archiving Plan...................................................................................................77
    8.5     IMPLEMENTATION AND GOING LIVE ..................................................................................................................77
       8.5.1    Configuration and Customizing ................................................................................................................78
       8.5.2    Testing.......................................................................................................................................................78
       8.5.3    Going Live.................................................................................................................................................79
    8.6     PERFORMANCE AND ARCHIVING........................................................................................................................79
    8.7     IMPLEMENTING AN ARCHIVING PROJECT: AN EXAMPLE FROM SD....................................................................81
       8.7.1    Analysis .....................................................................................................................................................82
         8.7.1.1 Building the project team ......................................................................................................................82
         8.7.1.2 Analyzing the technical and business environment...............................................................................82
       8.7.2    Design and Conception .............................................................................................................................85
         8.7.2.1 Establishing the archiving sequence......................................................................................................85
         8.7.2.2 Establishing a periodic archiving plan ..................................................................................................85
       8.7.3    Implementation and Going Live................................................................................................................86



Page 4                                                                                                                                                             © SAP AG
Version 2.0                                                                                                                          Managing SAP Archiving Projects



         8.7.3.1 Preparation and execution of archiving.................................................................................................86
       8.7.4    Sample Archiving Process Flow (Sales Document) ..................................................................................87
    8.8     CONCLUSION: ARCHIVING CHECKLIST ..............................................................................................................93
9        TERTIARY STORAGE MEDIA FOR DATA ARCHIVING ............................................................................95
    9.1       STORAGE USING SAP ARCHIVELINK ................................................................................................................95
    9.2       STORAGE IN AN HSM SYSTEM ..........................................................................................................................97
    9.3       STORAGE IN A LOCAL FILE SYSTEM...................................................................................................................98
    9.4       EVALUATION OF PROCEDURES AND TECHNOLOGIES .........................................................................................99
APPENDIX....................................................................................................................................................................101
    A.     TABLES WITH RAPID GROWTH RATES .................................................................................................................101
    B.     INFORMATION ON SELECTED ARCHIVING OBJECTS .............................................................................................104
    C.     GLOSSARY ...........................................................................................................................................................123
    D.     FREQUENTLY ASKED QUESTIONS ........................................................................................................................123
    E.     FURTHER INFORMATION AND SERVICES ..............................................................................................................125




© SAP AG                                                                                                                                                                Page 5
Managing SAP Archiving Projects                                                                         Version 2.0
Introduction




1 Introduction
The large volumes of data stored in modern databases can often lead to performance bottlenecks, which in
turn lead to poor application performance and increased demand on resources. Therefore, data that is no
longer needed in the database should be removed to maximize space and performance. However, simply
deleting the data is often not an option, as read-access to some data may still be required. Consequently,
the data must be removed from the database and stored in external storage media so that direct read-
access is still possible.
The logical objects to be archived are usually distributed physically over several database tables. The
corresponding database structures uniquely identifying a logical object and the relevant archiving program
form an archiving object (see Section 5.2).
SAP Data Archiving is the only method supported by SAP for consistently removing data from the database
(and subsequently maintaining the availability or read-access). Consistency is achieved by the integrity
requirements of SAP archiving programs. Pure database-integrated archiving is not possible because the
grouping concepts of the underlying database implemented in the R/3 data model are not always known.
Using SAP Data Archiving, important business objects such as accounting documents and material master
records can be selectively removed from the database in such a way that the user does not have to worry
about the underlying physical table design.
Data for archiving is stored first in the file system. From here, it can be transferred to other storage media.
For security reasons, archived data is only deleted from the database if the previously created archive files
were read successfully.

1.1 Document Objectives and Contents
The aim of this document is to provide SAP Data Archiving project teams with important information about
data archiving and to introduce a step by step guide to support the implementation of archiving projects. The
documentation is structured as follows:
• Chapter 2 explains why application data should be archived, outlines SAP’s official position on data
  archiving, and discusses the value of data prevention in this context.
• Chapter 3 examines the legal, technical and business requirements for data archiving and discusses
  auditing requirements.
• Chapter 4 outlines the concept and scope of SAP Data Archiving in the R/3 System.
• Chapter 5 describes the technical implementation of data archiving. Archiving administration and its
  embedding in the R/3 System are explained in detail.
• Chapter 6 discusses the various procedures for accessing archived data, and focuses, in particular, on
  the SAP Archiving Information System (SAP AS).
• Chapter 7 deals with application-specific aspects of Data Archiving, for example, for the areas Controlling
  (CO), EDI or ALE.
• Chapter 8 provides a detailed step-by-step guide that can be used to plan and implement data archiving
  projects. A checklist identifies the key points for you to observe when archiving data.
• Chapter 9 explains the storage and administration of archive files and discusses the procedures and
  technology available.
• The Appendix contains a list of the database tables that are known to be subject to excessive growth and
  provides further useful information on the subject of data archiving.



      The archiving functions and screen shots in this document are based on Releases 4.0 and 4.5.
      Functions that are made available with subsequent releases will be outlined in the corresponding
      release information.




Page 6                                                                                                   © SAP AG
Version 2.0                                                                       Managing SAP Archiving Projects
                                                                                                      Introduction


1.2 Requirements of Data Archiving
The main purpose of data archiving is to remove from the database application data that is no longer needed
in day-to-day business, with the aim of using resources more efficiently. The following requirements must be
taken into account when archiving data:
• Legal requirements: Some kinds of data must be archived so that they can be analyzed at any time in
  the future, for example data required by the tax authorities. These requirements are subject to the laws of
  the relevant country. SAP has developed the Data Retention Tool (DART) to enable the US Internal
  Revenue Service to analyze archived data. The tool includes functions for creating transparent files from
  archived data and to display this data. For further information on DART see Section 8.3.3.3.
• Technical requirements: From a technical point of view, the question is whether data can still be read
  long after it has been archived, independent of the hardware used at the time of archiving and the
  software release status. To guarantee this, SAP Data Archiving stores, together with the actual
  application data, additional information about the hardware that was used to write the data to the archive
  and what type of data structure was applied.
• Business requirements: From the business point of view, only those data objects that are no longer
  required in day-to-day operations may be removed from the database. Therefore, a logic check must be
  performed to ensure that only data objects belonging to completed business processes can be archived.
  The high level of integration between R/3 System applications means that the data objects are closely
  linked. Consequently, it is essential, during archiving, to check whether the removal of a specific data
  object from the database requires other objects to be archived at the same time.
These points serve merely as indicators for the possible requirements of data archiving. For detailed
information, see Chapter 3.




© SAP AG                                                                                                  Page 7
Managing SAP Archiving Projects                                                                        Version 2.0
Data Archiving in the R/3 System




2 Data Archiving in the R/3 System
The use of SAP systems by many users - thousands in some cases, leads to the creation of enormous
volumes, sometimes terabytes, of data. The electronic display of standard business processes and the
automatic generation and transfer of data from previous systems also leads to increased volumes of data.
Sales documents and delivery notes, for example, are created electronically in the SAP System and
transferred to business partners using Electronic Data Interchange (EDI).
Many live installations have shown that over time, the growth in data volume is exponential rather than
linear. In parallel, system administration demands also grow - not just for the database concerned, but for
the whole IT infrastructure. Nowadays, mass data memory is readily available and reasonably affordable,
however, the hardware used, such as database and application servers, can only be upgraded to a
predefined limit. In many cases, there are scaling limits that restrict the data volume that can be administered
by the database.
A majority of the data objects that are held in the R/3 database belong to obsolete business processes and
are no longer required in the day-to-day business of the enterprise. Furthermore, the online database in the
live system is not the most appropriate storage location for data that is no longer, or only seldom used. Data
of this kind adds considerably to the volume of data that is to be processed by the Database Management
System (DBMS).
This problem can only be resolved by removing data objects from the database that are only seldom used.
This ensures the long-term manageability of the database. In many cases, deleting data objects is not
possible, since there may be subsequent business and legal considerations. Read-access to data objects
may be required at a later date - for example, within the context of service and product support, or, in the
case of a government tax audit, you may have to display certain accounting documents.
SAP Data Archiving systematically removes data objects from the database and enables subsequent read-
access to the data using R/3. This ensures the long-term manageability of the database. This is a crucial
element in concepts relating to data backup, data accessibility, database administration, and, in some cases
has implications for the response times in the R/3 System.
SAP Data Archiving ensures that only data from obsolete processes is removed. A process becomes
obsolete on the conclusion of the last business transaction within the process chain. In principle, it is
possible to archive, and thereby remove from the system all data (master data and transaction data)
belonging to a business process. Within the R/3 System, various checks are carried out to ensure that a data
object can only be archived once certain criteria have been fulfilled. For example, the data must have been
in the database for a predefined period.
Section 2.3 describes in how a data object is defined in R/3. For a better understanding of the data archiving
process, it is first necessary to outline the R/3 system architecture.

2.1 R/3 System Architecture
R/3 is a client-server system that is composed of at least three service levels:
1. The database: This contains and maintains data and provides services for the application programs.
2. The application level: This is where R/3’s business logic is implemented, and where the business
   transactions are interpreted and processed from the database.
3. The presentation level: This level interacts with the user and prepares the data for display.
The following graphic gives an overview of the R/3 system architecture:




Page 8                                                                                                 © SAP AG
Version 2.0                                                                         Managing SAP Archiving Projects
                                                                                    Data Archiving in the R/3 System




              Presentation




               Application



                             ...                                  ...



              Database




      ã SAP AG 2000


Figure 2-1: R/3 System architecture

The term “R/3 System” incorporates all software components that are assigned to the same database.
The architecture described above enables trouble-free scaling and componentization of data retention,
application logistics and presentation. An “instance” describes a group of services that run on the application
level and that ensure the correct processing of the application programs. These services deal with the
following tasks:
• Processing user requirements
• Distributing the transaction load to individual processes
• Administering buffer areas in the main memory
• Connecting to the presentation level
• Communicating with the database processes

2.2 Reasons for Archiving
Data from closed business processes is only very rarely processed in change mode. Investigations have
shown that in the FI component, for example, the system accesses documents belonging to closed posting
periods only in exceptional circumstances.
The following case study illustrates the need to archive data. Figure 2-2 shows the growth in database
volume over a period of time. The graphic is based on the following typical data:
• Annual data growth of 80 gigabytes (GB)
• Residence time of six months - after this time, data is no longer required online and can be archived
• Data is backed up 200 times annually
The unhatched area shows the volume of data that is actually required by the operational transactions. The
hatched area shows the volume of data that is no longer accessed. The volume of data required by the
regular daily business clearly remains constant at approximately 50 GB.




© SAP AG                                                                                                    Page 9
Managing SAP Archiving Projects                                                                           Version 2.0
Data Archiving in the R/3 System




                  After five years …
                  l Data not needed : 350 GB
                  l Backup volume without archiving : 200 GB
                  l Backup volume with archiving : ca. 50 GB
          400
                      not needed online
          350
                      needed online
          300

          250

          200

          150                                         Data growth:
                                                     80 GB annually
          100

           50

             0
             1996            1997         1998      1999         2000     2001
      ã SAP AG 2000


Figure 2-2: Case study showing the growth of data volume

This example is typical of many R/3 installations. Data from closed business transactions is retained in the
database although it is not required by the day-to-day business and will only be accessed in exceptional
circumstances.
There are several ways to avoid the bottlenecks caused by large volumes of data in the database:
• Increase System Resources
   This usually means a hardware upgrade, such as increased disk space or a more powerful CPU.
   However, you will soon find that the effectiveness of this approach is compromised by technical
   constraints and it is only a matter of time before performance problems occur again. Therefore data
   archiving should be prioritized, especially where data growth is particularly rapid, as it can offer a better
   cost/benefit ratio than hardware upgrades.
• Delete Data
   Business requirements can mean that the system needs to access individual data objects again.
   Moreover, there can be legal requirements that the objects must be accessible for auditing purposes.
   Therefore certain data cannot simply be deleted. Data archiving offers a solution.
• Archive Data
   Only SAP Data Archiving guarantees that the size of the database is kept under control in the long term
   and that read-access is also maintained.
• Data Prevention
   Excessive growth in the size of the database can, in many cases, be slowed by preventing data that is
   only required in the short term or not at all from being created. Examples include log files, spool requests,
   and batch input sessions. Preventing the creation of this kind of data is preferable to creating the data,
   then having to archive it. For more information, see Section 2.7.
The following highlights the necessity of data archiving with reference to the IT and application areas.

2.2.1 IT Department

The IT department is responsible for ensuring the smooth operation of the R/3 System, including
performance, R/3 Database, network, operating system and hardware issues. The following lists several




Page 10                                                                                                    © SAP AG
Version 2.0                                                                             Managing SAP Archiving Projects
                                                                                        Data Archiving in the R/3 System

aspects of system availability and performance that must be taken into account when handling large
volumes of data.
2.2.1.1 Ensuring system availability
Increased system availability means minimal downtime. However, it is not possible to avoid downtime
completely. The following activities require special attention if there is a large volume of data in the
database:
• Hardware administration
• Software upgrades
• Database reorganization
• Data backup
• Recovery
Even the high-availability concepts offered by hardware suppliers, by replicating data, for example, require
increased investment in disk space and CPU performance.
2.2.1.2 Maintaining performance
Large volumes of data place increased demands on the database and application servers. Consequently,
irrespective of the application, transactions and - especially reports - have to make selections from large
volumes of data in the application tables. This necessitaties further pressure on the memory and CPU
performance on the server. To maintain satisfactory performance levels where there is a large volume of
data, it is often necessary to increase hardware resources. On the other hand, scaling, of the database
buffers, for example, is not the ideal solution because of restrictions on database architecture.
In summary, increased investment in hardware (including network hardware) is required to ensure system
availability and acceptable performance levels. The administrative burden also increases accordingly.
However, due to the limits on system expansion and because hardware is not infinitely scalable, further data
volume growth can still create problems.

2.2.2 User Departments

The term “user departments” refers to both the departments in which the applications are used and to the
end users who are working with the R/3 System in a live environment. It is essential for the end users to be
able to exploit fully all R/3 functions online and to be able to rely on system availability during live operations.
From the point of view of the user department there are two important reasons for archiving application data:
• Improved response times
• Reduced data selection
For large data volumes, these targets can only be met through increased hardware expenditure. Queries
that can be carried out online for small data volumes might, for large data volumes, have to be run as
background jobs. Archiving is, in principle, only carried out for data that is no longer required by the day-to-
day business because it belongs to closed business processes. For indexed accesses, which is usually the
case, this means that the system has to search through larger index trees. The processing time is
proportional to the volume of data that the system has to search.
If the database uses a cost-based optimizer (CBO), this data may be analyzed in the statistics, which means
that information on old data objects is taken into account that is not actually of any interest to the end user.
During long transactions spread over a number of screens, this can result in runtimes that are unacceptable
for the user. This can also possibly lead to delays in the follow-up processes, if the steps are linked in large
cross-departmental process chains.
The end user will also be offered more data because the volume of data selected increases when data
volumes are larger. This has a particularly negative effect on the clarity of the available data. The data will
possibly have to be limited in the selection screen, with the result that additional user input is required.
In summary, archiving data which is no longer required by the day-to-day business can reduce end user
workloads significantly.




© SAP AG                                                                                                       Page 11
Managing SAP Archiving Projects                                                                         Version 2.0
Data Archiving in the R/3 System


2.3 Data Objects in the R/3 System
SAP Data Archiving is centered on data objects that have been defined in the R/3 System, and that have a
business significance. In general, data objects can be split into two categories:
• Master data, which is used over a long period in business operations
• Transaction data, which is of shorter-term significance
Examples of master data include material and vendor master records, bills of material and work schedules.
Transaction data includes, for example, accounting documents, production orders, sales orders, invoices
and deliveries.
A typical data object is composed of:
• A header, in which general information can be stored for the identification of the data object
• Individual items, which forms the main part of the data object
In addition, there are descriptive texts and change documents in which changes can be documented.
Further original documents, which are stored on a document server, can be assigned to a data object.
The data object is the smallest unit of business information that is identified in all SAP systems using a
unique key. Data objects are stored in the underlying database and the data that each data object contains
is stored in relational tables. This means that the data in the database in not stored according to object, but
distributed amongst several database tables. Which tables are concerned and how they interact is defined
by the underlying data model for the application. As a rule, this data model is not known to the database,
since not all tables, which give a data object its character, are linked to each other by foreign key
dependencies. Data objects in the R/3 application are accessed by means of SQL statements. Here,
communication with the underlying database takes place over the database interface (see Figure 2-3).
The following defines more precisely the term Data Archiving:
“Data Archiving is the consistent removal of data objects from the database. This involves writing all table
entries that define a data object in archive files outside the database. Consistency of business data is
ensured by the SAP archiving programs, which remove all the relevant table entries.”




                                   R/3 Application



                                       DB I/F


                                   SQL Statements




                                       DBMS


                                     Database




      ã SAP AG 2000


Figure 2-3: Interaction between R/3 and the database




Page 12                                                                                                  © SAP AG
Version 2.0                                                                            Managing SAP Archiving Projects
                                                                                       Data Archiving in the R/3 System


2.4 Important Archiving Terminology
Since, in the IT context, the term “Archiving” is used very loosely, this section aims to clarify terms relating
specifically to “Data Archiving”. Clear definitions of the following terms are indispensable for a thorough
understanding of the SAP archiving concept.
Reorganization
This term has a double meaning in the SAP context. Firstly, it refers to the physical deletion of application
data from the database. Secondly, - the true meaning - refers to the reorganization of the database.
In the database, individual table lines containing datasets are stored in database blocks. Deleting, changing
and creating datasets creates gaps in the blocks. These gaps can no longer be used. Fragmentation of the
database can, in some circumstances, increase the time needed by the system to search for table contents.
Removing the effects of this fragmentation by closing the gaps and thereby enabling more efficient use of
the available memory space is what is meant by the term (database) reorganization. This process entails the
physical relocation of data from a logical database segment to a contextually-related area in the memory.
Optical archiving
Optical archiving refers generally to the electronic storage and management of documents in storage
systems beyond the R/3 System. In most cases, data is stored in optical media such as CDs or WORMs;
hence the designation “optical archiving”. The term is, however, confusing, and it would be preferable to
refer to “imaging” or “electronic data storage” since the term “optical archiving” only describes the physical
storage. In principle, all media - and not just optical storage media - can be used that are supported by the
storage system that is connected to the SAP System.
Documents that can be stored in this way include:
• Scanned original documents such as suppliers’ invoices
• Outgoing documents, such as invoices that are created electronically in R/3 and then forwarded
• Print lists created in R/3
In these cases, the documents created are not stored in the R/3 database, but are transferred to document
storage systems. The SAP System only maintains links to the externally stored document, thereby enabling
access. Documents that are stored (not archived) in this way can be displayed in R/3, but cannot be
reloaded into the database. This is due to the different formats in which documents and applications are
saved. Whilst application data is stored in the database in a structured format (CI, coded information),
scanned documents are stored in NCI format (non-coded information), which cannot be interpreted by the
applications.
SAP ArchiveLink
SAP ArchiveLink is an interface that is integrated into the SAP Basis component. It controls communication
with storage systems. This standard interface enables access to documents created in SAP applications and
stored in a storage system. The storage system must be correctly configured and connected to the R/3
System.
Backup and Restore
Backup refers to the (saved) copy of the database contents that serves as a precaution against data loss.
This enables the reinstatement of the database as it was before the system failure. Restore refers to the
rewriting of the contents of the backup copy in an emergency.

2.5 Application-Specific Archiving
At the core of Data Archiving are business-relevant data objects that are wholly removed from the database
and are written as a unit to an external storage medium. The database objects, which identify a business-
relevant data object, are not usually known by the underlying database. Consequently, it is not sufficient to
rely wholly on the archiving functionality of the database software, since not all tables for one data object are
linked to each other by means of a foreign key dependency. The systematic removal of data objects must
therefore be transferred to the application programs that recognize the data model for the corresponding
data object.




© SAP AG                                                                                                      Page 13
Managing SAP Archiving Projects                                                                      Version 2.0
Data Archiving in the R/3 System

Before the data objects can be archived, certain business criteria - which are implemented by the archiving
programs in the application - must be fulfilled. For example, the data objects must have the status
“Completed”. A data object cannot be archived and deleted from the database until the check criteria have
been applied successfully. The resulting archive files are no longer managed by the underlying DBMS and
must be administered using a separate operation concept. In particular, there must be a specific backup
concept for the archived dataset.
It is no longer possible to access data objects in archive files using SQL statements. Instead, the SAP
System offers an integral archive administration system. The data objects in the archive files can then be
read using separate display programs. The archive files form a separate dataset from the data in the online
database, and can usually only be accessed on a read-only basis. This access does not offer the same
reporting and navigational logic that is available in the online database. Opening, reading and closing
archive files is carried out by the integral SAP Archive Administration System. The Archive Administration
System also conducts the administration of the archive files within the SAP System. Standard function
modules are used to read archive files.
The following graphic shows the environment for application-specific data archiving.




                                                 Access with ABAP Commands
                        R/3 Application


                            DB I/F                 Archive Administration



                          SQL
                                          Data
                      Statements

               R/3-Anwendung
                        DBMS


                         Database




                      Physical DB Files                Archive Files

      ã SAP AG 2000


Figure 2-4: Application-specific archiving


2.6 Positioning of Data Archiving
The following seeks to address a number of important frequently asked questions relating to SAP’s
positioning of data archiving, and to outline the ensuing aims and scope of implementation. It also seeks to
indicate the areas that lie beyond the scope of Data Archiving.
1. What are the aims of Data Archiving?
Archiving application data from the database is an important part of the administration of rapidly growing
datasets. Unlike backup and recovery, the process of data archiving is closely related to the application and
therefore has an immediate impact on an enterprise’s business processes.
Applications such as the R/3 System are designed in such a way that data can be stored on the database
and, if necessary, accessed again. When archived, this data is no longer available online, but is accessed
via the database. Read-only access is still possible, though in some cases, to a lesser extent than online
data. This applies to both the display of individual objects and evaluation using reports. Enabling similar
functionality for archived data would place excessive demands on the system, since archived data would
have to be modified in accordance with changes in the current system, for example, by conversion. A



Page 14                                                                                               © SAP AG
Version 2.0                                                                          Managing SAP Archiving Projects
                                                                                     Data Archiving in the R/3 System

function that could display archived data in a similar way to online would not justify the resources required,
since access to archived datasets is only rarely required. For this reason, SAP provides alternative means of
access, such as the SAP Archive Information System.
Data Archiving seeks to ease the administration of the R/3 System rather than simply relocating problems
that result from the processing of mass data.
2. What data should be archived?
This question is most easily answered by identifying data that should not be archived. Storing application
data in archives is not a simple alternative to leaving data in the database. The applications are designed to
make access to the database easy and for that reason, all data that is required for application operations
should remain in the database. For example, if, in order to make a bonus payment, you need to process all
the billing documents from the fiscal year, the relevant data cannot be archived until the bonus has been
processed.
3. When should application data be archived?
Application data should not be archived until:
• It is no longer required for processing
• It requires no further changes
• You are unlikely to need to display it
This also means that before archiving application data, you must ensure that all the required documentation
has been created for subsequent auditing.
4. Does Data Archiving fulfil auditing requirements?
Data Archiving is not intended as an auditing tool. It does, however, support audit requirements in that it
retains data and makes it available over a long period. You should only carry out data archiving once you
have defined a long-term auditing policy. Applications such as the Audit Information System (AIS) and DART
(specifically adapted to the requirements of the American market) are designed for auditing purposes. If you
intend to use DART, you are advised - for performance reasons - to implement this before carrying out data
archiving.
If, for auditing purposes, you do require detailed information that is not contained in the audit documentation,
it is possible to access archived data. Whilst there is no obligation to retain archive files, you must, at any
time, be able to document the breakdown of business figures. Archived data should only be included in the
auditing process if auditing requirements have to be fulfilled retroactively. To simplify the auditing process,
you are advised to meet all your auditing requirements whilst the data is still in the database.
5. When is it advisable to carry out data archiving?
The archiving of application data should be carried out before database maintenance costs become
prohibitive, or, conversely, when storage and administration of archived data can be carried out at a
reasonable price.
If costs for access to archived data exceed the costs for storage and administration of the data in the
database, the data should remain available in the database. If cost is a primary consideration that
determines when data archiving is to be carried out - for example, to avoid the purchase of a more efficient
database server, you should also consider the expenses that will be incurred as a result of accessing
archived data.
6. What is the status of archived data?
Archived data cannot be changed and is withdrawn from processing in business operations. If you need
detailed information on historical data, you can you can access archived data on a read-only basis. It should
be noted, however, that since the data has not been updated (for example, to reflect reorganization in your
enterprise), the content and structure of the data may not be valid for the current context. Furthermore, some
archiving objects only enable restricted access to archived data. This is the case, notably, with the display of
single documents or reports.
7. Can archived data be reloaded into the database?
Technically, it is possible to reload archived data into the database. However, since archived data has been
excluded from changes made in the database, inconsistencies may arise from reloading. It is therefore never



© SAP AG                                                                                                    Page 15
Managing SAP Archiving Projects                                                                           Version 2.0
Data Archiving in the R/3 System

advisable to reload data, unless it is carried out immediately after archiving. This should be seen solely as an
emergency function following an unsuccessful archiving job, due, for example, to incorrect Customizing
settings that led to the archiving of the wrong data.
8. When should I start archiving?
You should start archiving application data before all other alternative means of improving system
performance have been exhausted. This includes considerations relating to the required system size in
relation to the anticipated data volume (sizing) and the required residence times, that is, the period in which
the data is required online. You should ensure that you have fulfilled all foreseeable auditing requirements
before carrying out data archiving.
You should bear in mind that archiving data, slows, but does not halt the growth of the database. Nor does
archiving data reduce the volume in the database. Data archiving can only be used to maintain the
manageability of the system, and not to return the system to its original state.
9. How can I access archived data?
It is not possible to give a general answer for the R/3 System, since this depends on the application in
question and the archiving object used. The following options are available:
• Ideally, the user displays archived data directly from his usual transaction. To do this, index information
   on archived data must be maintained in the database, for example, using the SAP Archiving Information
   System (SAP AS). The applications must have been modified especially for this. This is not possible for
   all archiving objects.
• The SAP Archiving Information System offers generic access to data in the archive. This access can be
   enhanced using specially developed intelligent display programs. SAP has already included such
   enhancements in some archiving objects.
• Reporting on archived data is also possible. This also depends on the application, how detailed the result
   is, or whether archived data can be processed together with data from the database, that is, whether
   mixed reporting is possible. In the case of a list-oriented display, the system does not notify the user that
   the data selection may be incomplete, as some data objects have already been archived.
• By using the tools available in the standard system, the Archive Development Kit (ADK) and the SAP
   Archive Information System (SAP AS), it is possible to modify access to archived data in line with
   specific customer requirements. The use of these tools is explained on the course BC670 and in the
   relevant documentation.
10. Is print list archiving a substitute for data archiving?
No. print list archiving is not a substitute for data archiving. Print list archiving and data archiving are only
complementary. Print lists are created provided the data is still available in the database. Print lists can
subsequently be archived by transferring them to an integrated storage system using SAP Archive Link. Print
lists are mainly created and archived for subsequent audits. If you later discover that information is required
for an audit, you can access the archived data at any time.
A print list offers a snapshot of the system at the time of its creation. This means that the information that it
contains is only valid at the time of its creation. It is therefore pointless to create new print lists for an
upcoming audit, since they cannot provide a historical picture of the period for which the audit is to be
performed.
If you regularly have to search for specific data records, a print list is not the most appropriate method, since
the print list has to be determined manually before the data can be located automatically.
11. Can archived documents be reprinted?
Reprinting archived documents such as SD invoices is not possible without substantial programming for the
conversion of the print programs.
In releases up to and including 4.5, it is necessary to modify the print views. The modification applies to both
the print programs themselves and to the retrieval of the data that is to be printed. Data from internal tables
cannot be printed as the print programs always read the data from the online database.
From release 4.5, it is possible to use Smartforms for printing. Setting up a Smartform and implementing it in
the relevant print program (for example, RVADIN01 Print Program for Invoices) can, however, involve a
considerable amount of work. You can implement data retrieval relatively quickly with an index-supported
search in the archive (using the SAP Archiving Information System).


Page 16                                                                                                    © SAP AG
Version 2.0                                                                           Managing SAP Archiving Projects
                                                                                       Data Archiving in the R/3 System




      If an archived document is to be printed, you should bear in mind that there is no guarantee that the
      content and structure of this version is the same as the original.

Problems arising from printing archived data can best be avoided by using a storage system in which
outgoing documents are stored. If necessary, these can be printed again at a later date without a problem.

2.7 Data Prevention
This section is aimed at systems administrators concerned with the long-term manageability of the database.
Data prevention is a highly effective way of keeping growth of the database in check. This means that
unnecessary data is not created and therefore does not contribute to the growth of the data volume.
You are advised to prioritize the reduction of data volume as follows:
1. Data prevention
   If the system generates data that is subsequently not required, you should, if technically possible, prevent
   this data from being updated.
2. Data summary
   In some cases, it is possible to summarize information at a higher level, for example by calculating totals.
   If this can be done without the loss of necessary data, this is an excellent way of reducing data volume.
3. Data archiving
   Data that has to be kept for business or legal reasons, and can therefore not simply be deleted, should be
   archived.



      A lot of data, that - from a business point of view - is no longer required, can be removed from the
      system shortly after its creation (such as spool data, run time statistics or batch input administration
      data). The applications contain the necessary reorganization programs to carry this out.

The following flow chart depicts decision-making in relation to Data Archiving and other methods for data
reduction.




                        Do you              Switch off the
                                    N
                         need                 creation
                      this data?             of this data
  Step 1



                                     Can you
                           Y                          Y      Summarize
                                   summarize
                                                              this data
                                    this data?
                       Step 2



                                                      Can you
                                           N                         Y    Use Data
                                                      archive
                                                     this data?           Archiving
                                        Step 3
                                                             N


                                                    Retain Data
                                                    in Database
      ã SAP AG 2000


Figure 2-5: Data Archiving: The decision-making process



© SAP AG                                                                                                      Page 17
Managing SAP Archiving Projects                                                                            Version 2.0
Data Archiving in the R/3 System

As shown here, data archiving is not the only means for reducing data volume. Before archiving application
data, you should check whether alternatives are more appropriate. For example, make sure you know
whether data will be required later. How do you identify data that is no longer required, and how can its
creation be prevented? These and further questions are addressed below. It should be noted, however, that
only the most important aspects are described in detail. A thorough account of all relevant factors is beyond
the scope of this document.

2.7.1 How do I identify unnecessary data?

Database tables are not easily assigned to individual application functions, since table contents generally
originate from an assortment of functions. To identify unnecessary data, a thorough knowledge of the
business processes involved is called for. If this is not available, you are advised, at the very least, to identify
and document the processes used. With this information, an expert can analyze the growth of the database
table and assign it to specific functions. In such matters, you can refer to SAP Consulting or a competent
consulting partner of your choice. Appendix A gives examples of tables that are subject to rapid growth and
offers links to useful SAP Notes.

2.7.2 Why is some data created automatically?

Basically, there are three reasons for the automatic creation of data of unnecessary data. These reasons are
outlined below.
Functions are activated by default
Usually, when an SAP System is supplied, all system functions are activated. This means that the system
can be set up swiftly and enables the user to use the live system as soon as possible.
However, the swift introduction of the live system means that superfluous data is sometimes created in the
background. For optimal system performance, all required functions should be activated, and those that are
not required should be deactivated. You should, however, only deactivate individual functions after careful
consideration and after consulting an expert, since this can also lead to the loss of important data.
In some applications, only the logical part of the R/3 System is used, but 80% of the resulting data expansion
occurs in Accounting. Although this is not a common phenomenon, data originating in Logistics and created
in Accounting exemplifies one area that necessitates data prevention. In such areas, much data can be
prevented or summarized.
Functions are used for purposes other than those for which they were originally designed
For example, some users create certain Financial Accounting data merely to enable them to use an interface
enabling access to an Accounting system. As this case shows, some functions are being used for purposes
for which they were not originally designed. Consequently, the user must either live with this inordinate level
of data growth or develop programs that address these needs.
Experience shows that the growth of data resulting from the misuse of functions can go unnoticed for a long
time after the system has been live. Before your system goes live, you should run mass tests to determine
the potential data growth on the basis of the current system settings.
Regular reorganization programs are not run
Although some tables have special reorganization programs, these tables continue to grow simply because
these programs are not run. A typical example is the reorganization of temporary sequential files (TemSen),
spool requests and batch input sessions. Problems of this kind can easily be avoided or resolved.

2.7.3 How can the automatic creation of data be prevented?

There is no central R/3 Customizing where it is possible to activate or deactivate all functions. Individual
functions are deactivated in Customizing for the relevant application. In some cases, it is necessary to
modify individual programs.
However, simply deactivating a function is not enough. Above all, you must ensure that by deactivating a
function, you are not compromising the business process. It is essential that you remember to consider
programs that are run regularly, such as those that make bonus payments. For this reason, you should
deactivate functions and check the effect this has on business processes before your system goes live. If



Page 18                                                                                                     © SAP AG
Version 2.0                                                                       Managing SAP Archiving Projects
                                                                                   Data Archiving in the R/3 System

you think you cannot operate without a particular function, you should check whether other data, in
summarized form, or in a form that can be summarized, offers a substitute for the function.
For more information on the prevention of application data, such as CO and retail objects, Idocs, work items,
and so on, refer to the document “Data Prevention Checklist” in the SAP Service Marketplace at
http://service.sap.com/data-archiving , then choose: Media Center à Literature. You are also advised to
consult the most recent SAP Notes on this subject.




© SAP AG                                                                                                  Page 19
Managing SAP Archiving Projects                                                                        Version 2.0
Data Archiving and Information Retention




3 Data Archiving and Information Retention
SAP Data Archiving removes mass data that is no longer required from the database thereby enabling more
efficient utilization of the database resources. However, data archiving should not be regarded solely within
the context of improved administration and maximizing resources. It should also be regarded within the
context of information retention and auditing requirements.
The primary aim of information retention is to ensure read-access at a later stage. In addition to data
archiving, it is also possible to access stored information using print lists. In practice, both methods are
frequently combined. Furthermore, in addition to SAP systems, other components such as SAP Business
Information Warehouse (SAP BW) or other upstream or downstream systems are supplied with data using
standard interfaces.
This chapter introduces the most important concepts and discusses their context within data archiving.
Section 3.1 discusses possible information retention requirements. Section 3.2 describes print lists as an
alternative means of retention. Section 3.3 focuses on the Audit Information System (AIS), which is mainly
used within the European context. Section 3.4 focuses on the Data Retention Tool (DART), which is primarily
used in the USA to fulfil various statutory auditing requirements.

3.1 Information Retention Requirements
Information retention requirements can be divided into the following categories:
• Legal requirements: These cover the basic accounting requirements and specific requirements imposed
  by the tax authorities.
• Internal business requirements: For example, requirements imposed by service departments,
  controlling or internal auditing.
Technical requirements: For example, access times, durability of data media, long-term readability of the
information.

3.1.1 Legal Requirements


      Legal requirements vary enormously from country to country. It is important, therefore, to ensure that
      the auditing requirements of the relevant country are taken into account when considering
      information retention. Consequently, it is difficult to make general statements about the type and
      scope of information retention.

The following outlines the German legal requirements and explains how they can be fulfilled. The legal
requirements are based on the “Generally Accepted Accounting Principles” (GOB):
• Correctness refers to the observation of and adherence to legal regulations, such as the retention
  periods and types of retention.
• Completeness fulfills the requirement that the data in a data object be removed in its entirety to external
  archive files. In real terms, this means that the archiving process may not leave out any information that
  was previously stored in the database.
• Accuracy means that the information in data objects is not changed by the archiving process.
• Availability for inspection means that the archived data objects must be readable, and that they must
  be capable of being reproduced.
These criteria must form an integral part of any documentation describing auditing requirements.
Within the context of product liability, the manufacturer of a product is liable for damages resulting from a
product defect. Regulations relating to burden of proof therefore require that product information is retained
over a long period, for example, so that any production or construction defects can subsequently be traced.




Page 20                                                                                                © SAP AG
Version 2.0                                                                             Managing SAP Archiving Projects
                                                                                 Data Archiving and Information Retention

Similarly, a manufacturer is often required to observe a warranty obligation that requires the manufacturer
to take responsibility for apparent or hidden defects in a product sold. Due to legal requirements, it may be
necessary to retain information on a product’s entire life cycle. Individual questions that should be answered
in this respect are: To what extent is the manufacturer responsible for the product and what documentation-
relevant requirements apply within the context of product liability and warranty obligation. Agreements
relating to international product liability should be observed in addition to national requirements. In some
cases, each step in the production process must be documented, including purchasing, goods receipt,
development, manufacture and quality control. For this reason, you should always check the liability risks
and document the relevant steps as a precaution.
Furthermore, every country has accounting obligations. Every company is legally required to document
specific business transactions. Accounts books, inventories, year-end closing reports, reviews of operations,
operational method sheets, and so on, must be retained for inspection. Capital movements, monetary
transactions, assets, and so on, must all be clearly available from these documents. Different countries have
different rules regarding periods of retention, retention procedures and reporting.
For the purposes of external auditing, by tax authorities, for example, data objects must be made available
to external auditors. The information retained must be complete and accurate. In this context, it is advisable
to agree on an information retention strategy with your accountants or economic advisers so that you know
what data is relevant for external audit. It may be advisable to save this information separately in print lists.
In summary, there are no standard guidelines that apply to all countries regarding information retention
obligations. National rules apply regarding retention periods for single documents, reporting and the use of
appropriate tools. Legal requirements must always be dealt with at the country level.

3.1.2 Business Requirements

In addition to legal requirements, there are also business considerations that militate against deleting data
from the database.
Regardless of the life cycle of a product, product data must, in many cases, be kept for a period of several
decades. Specific product information must be made available to the company’s customer service
department for the entirety of the product’s life cycle. This includes construction-relevant CAD drawings,
bills of material (with period of validity), in-built components, production aids and work schedules. From this
list, it can be seen that the end-product is defined by various data objects. In some cases, it may be
necessary to reconstruct the whole process in which the product was involved. The information required by
this specialist department can therefore be very different from the requirements of other users, such as
external auditors.
In many cases, responsibility for the product does not end with its use, but can also include recycling.
Continued growth of data in a live SAP System means that it is necessary to remove data from the database
regularly. For the reasons outlined above, individual, specialist departments must have read-access to the
data objects. Consequently, deletion is not usually an option.
Internal audits often require access to archived data objects, for example, to monitor planning data and
supply the bases for decisions. Typically, their main task is to carry out the monitoring functions associated
with management. This consists mainly of ensuring correctness, security and economy of the archiving
solution. Internal audits can be extended to include any area of a company’s activity. There should, however,
be agreement within the company on what data is relevant for retention in addition to the data that is legally
required.
Statistical analyses, which aggregate important information on production, sales and markets, serve to
shape the decision-making process. Some programs even offer the possibility of evaluating, weighting and
formatting archived data objects. However, this feature is not available in all statistical reports. If you require
comprehensive statistical analysis that includes historical data, you should use a Data Warehouse.
The archived dataset also constitutes a central knowledge base of product data that may be required, for
example, for new or extended product development. In such cases, the reuse of information is crucial,
because former material requirements and production processes are often relevant for new products.




© SAP AG                                                                                                        Page 21
Managing SAP Archiving Projects                                                                              Version 2.0
Data Archiving and Information Retention

3.1.3 Technical Requirements

The purpose of data archiving is the return of information that is to be retained within defined retention
periods and access times. The access times play an important role in the live operation. Therefore, before
archiving, you should specify the access times required by end users in a requirements catalog. Of course,
the access time affects the physical storage medium and the type of access (data access or sequential
access, see Chapter 6).
• Correct transformation: The technical removal must fulfil the requirement that the relevant information
  is correctly transferred from the database to the appropriate storage medium. The correct transfer of data
  must also be ensured if the storage medium is changed. However, technical errors cannot be ruled out
  when transferring data, and such transformation procedures always carry a certain risk. Legislation may
  therefore require automated and/or manual certification that the information in the archive files is identical
  to the information in the database. For more information on backup in data archiving, see Section 4.2.2.
• Storage: The selected tertiary storage medium must ensure that the contents of the data objects will
  remain intact for the period of retention. During storage (not retention), physical and chemical processes
  can endanger the process of storing the data to the storage medium. A storage medium must therefore
  be capable of displaying the archived data for the period of storage. If, according to the manufacturer’s
  specifications, the storage medium is subject to (natural) disintegration, you should schedule a timely re-
  archiving of the affected data.
• Correct reproduction: The archiving solution must ensure that the required data objects can be read
  and interpreted, and that the contents can be correctly reproduced. In this context, readable means that a
  competent third party can display the information using the required read programs.

3.2 Print Lists
Print lists are the results of R/3 reports. The standard system contains numerous predefined reports, such as
accumulated balance audit trail, inventory levels, balance sheet valuations, journal. Print lists can either be
printed on paper and/or stored in a storage system using SAP ArchiveLink. Electronic storage has the
advantage of being more compact than paper and offers fast central availability with index or free-text search
functions and centralized administration of reports that are commonly used for auditing purposes. Print lists
can be created as long as the data remains in the database. A stored or printed print list shows the
relationship between different types of business data as it was recorded in the R/3 database at the time of
storage or the time of printing.
Since print lists or reports can be created individually at any time, you should distinguish between those that
are based on live (current) data and those that are based on data that has already been archived. From
Release 3.1, it is possible to access archived data by means of hyperlinks in live data. If, for example,
document number “4711” is a part of the print list information, a hyperlink here can link to the original
document, invoice “R816”, which was previously scanned or stored. Depending on the type of print list, the
relationship between data in the R/3 System can change and the information contained in a new print list will
be different from the previous one. It is also possible that the data in the archived original document no
longer matches the data in the R/3 document. Particular attention should be paid to this when dealing with
audit-relevant print lists.
Print lists are not intended to simplify data retrieval. Instead, they facilitate the retrieval of an extract of the
dataset at a particular point in time and in a business context. Since Release 3.1, it is possible to conduct
index searches in the print list according to freely-definable indexes. Free searches in currently read list
areas were previously possible. SAP AS offers a range of functions to search within historical (archived)
datasets. SAP Archive Link makes it possible to use the control record to search for print lists according to
object type, document type and the report name of the print list. Furthermore, the document management
system enables you to access print lists by using any individually defined search criteria.




Page 22                                                                                                       © SAP AG
Version 2.0                                                                                                 Managing SAP Archiving Projects
                                                                                                     Data Archiving and Information Retention




     R/3 System
                                                               SAP ArchiveLink List Management / DVS

                              Queue
                             archiving
                                                                         6
      Spool                                                                      Create administration
                      2                      Asynchronous requests                entry for archived
                                                                                       print list
                                  3
                                                                RFC Server SAP ArchiveLink

                           Batch archiving
                                                                                    RFC message:
                                                                                “Archiving successful...”
         1                                                                  5
                                           RFC Request:
                 List and
                                            “Store files       3
                                         asynchronously ...”
              description file
                                                                    Storage server     Storage system
                                                                     RFC server
                                                  4
                                                                        4
                                    Store file in
                                  storage system


      ã SAP AG 2000


Figure 3-1: The technical process for the storage of print lists (RFC)

The spool process creates a print list and description file. Asynchronously, requests to store the files are
sent from the Archiving queue the storage system. The storage system transfers the files to the storage
medium and then ensures that the document number of the print list is returned to the R/3 System and the
print list control record is written.

3.3 Audit Information System
According to the legal regulations in many countries, a company’s accounting must be constituted in such a
way that a competent third party is able to obtain an overview within a reasonable length of time. The Audit
Information System (AIS) offers the auditor appropriate methods for carrying out business checks and
internal audits, thereby enhancing the quality of the audit. The audit can be carried out in real-time, that is,
directly at the screen in the live environment.
AIS contains an auditing reporting tree and represents a collection of structured and predefined SAP
standard programs. Drilldown functions enable the user to move from highly summarized data to single
documents. It is a requirement that all the relevant data for the period covered by the audit is available in the
database. In some cases, AIS is also able to evaluate archived datasets. This is not an intended function of
AIS, and depends on the report used. You should therefore check this in each case.
From Release 3.1l and 4.6A, AIS is included in the standard system. For earlier releases, it is also possible
to install the current version of the AIS. For more information, refer to SAP Note 77503.

3.4 Data Retention Tool
Usually, for an external audit, all data objects that belong to an accounting transaction must be displayed.
Often, data is required from various applications, typically because they belong to the same invoice-relevant
process.
The data objects that are removed from the database using SAP Data Archiving are stored in external
archive files in compressed form, and then deleted from the database. The data objects for archiving are
stored in a SAP-specific format, and can therefore only be reevaluated in the SAP System. There are often
additional country-specific legal requirements regarding the retention and evaluation of data. Thus, in
addition to Financial Accounting documents, vendor master data that was used for the posting of Financial
Accounting documents may also be required. Since tables, in which transaction data was stored, generally
grow much faster, it is possible that the required Financial Accounting document was already archived and



© SAP AG                                                                                                                            Page 23
Managing SAP Archiving Projects                                                                     Version 2.0
Data Archiving and Information Retention

deleted from the database. This problem is addressed by the Data Retention Tool (DART), in that it stores
invoice-relevant data in contextual form, thereby enabling subsequent contextual reporting.
DART was especially developed for the retention and reporting requirements of the US tax authorities (IRS),
and is primarily used in the North and South American markets. This program is a part of the standard
system from Release 4.5. DART enables the extraction of invoice-relevant data from the R/3 System and its
subsequent storage in an external file. The data is stored sequentially in uncompressed ASCII format and
can be evaluated using external tools. This data extract can also be displayed again in R/3.
DART can process both data from the online database and, using SAP Data Archiving, archived data (see
Figure 3-2). Data objects are first read and the relevant field contents are filtered out. Then data is
temporarily placed in temporary database tables, which are not, however, identical to those tables that
describe the physical data model of a data object.
The following graphic shows the data extraction process in DART:




                                            Data extract
                                             browser
                                       Data
                                                       Extract
                                      extract
                         R/3                     Transaction data
                      Database
                                                 Transaction data



                          Archive                   Master data
                          retrieval
                                                    Master data


                Archive



      ã SAP AG 2000


Figure 3-2: Data extraction using DART

A data extract, composed of the current online data and data from the temporary tables, is then created. The
data that has been transferred to from archive files to temporary files can then be deleted again (see Figure
3-3). For more information, refer to the documentation on DART in the SAP Library.


      To prevent the archived data in the temporary files from being reloaded, we recommend that you
      create a data extract using DART before archiving the data objects. This procedure reduces
      pressure on system resources.

The graphic below illustrates the temporary storage of archived data during extraction:




Page 24                                                                                              © SAP AG
Version 2.0                                                                           Managing SAP Archiving Projects
                                                                               Data Archiving and Information Retention




                                                  R/3 Database

                                               Temporar
                                                          y      Standard
                                                retrieval                e
                                                                 databas
                                                 tables            tables




                             Archive
                             retrieval
         Archive



      ã SAP AG 2000


Figure 3-3: Temporary storage of archived data

The following offers an overview of the fundamental concepts behind DART and SAP Data Archiving (ADK)
and highlights their different aims and uses.

DART                                                          ADK
Objective: Fulfillment of US tax authority’s                  Objective: Ensure the manageability and maintenance
requirements regarding the retention and evaluation of        of the R/3 database.
invoice-relevant data
Processes data from various applications                      Only data objects from one archiving object type are
                                                              stored in an archive file.
Processing of archived data and online data possible          Combined evaluation of archived data and online data
                                                              is possible for some archiving objects
No changes are made to the database (data is not              Data objects are deleted from the database
deleted)
Data is stored in ASCII format                                Data objects are compressed in a SAP-specific format
External display using external tools; display within R/3     Display only possible using R/3
using ABAP programs
Various views can be defined (in Customizing)                 Various views are programmable using SAP Archiving
                                                              Information System
Table 1: Uses of DART and Data Archiving




© SAP AG                                                                                                      Page 25
Managing SAP Archiving Projects                                                                               Version 2.0
SAP R/3 Data Archiving Concept




4 SAP R/3 Data Archiving Concept

4.1 Process Flow
Data archiving removes data objects from the R/3 database using archiving objects in which the structure
and composition of the data to be archived is defined and written to archive files for subsequent analysis.
The archive files can be moved from the file system to tertiary storage media, for example WORMs, CD-
ROMs or magnetic tapes. The following graphic gives an overview of the process:




                                             Analyze



       Online             R/3 DB

                      Application data          Archiving
                                                 object




                                                              Archive
                                                              files

                                         Archiving




      ã SAP AG 2000


Figure 4-1: The R/3 Data Archiving process

The R/3 Data Archiving process is divided into the following three steps:
• Create archive files: Using an archiving object, the data to be archived is written sequentially to newly
  created archive files.
• Execute deletion program: After the data to be archived has been written to archive files, it is removed
  from the database by the deletion program. For data security reasons, the deletion run is only started
  after the previously created archive files have been read successfully.
• Store archive files: The archive files created during the archiving session can be moved to external
  mass storage systems or to tertiary storage media.

4.1.1 Create Archive Files
The write program first creates one or more archive files into which it copies the data to be archived from the
database. This process continues until one of the following events occurs:
4. The archiving is finished.
5. The archive file reaches the maximum size allowed, as defined in Customizing.
6. The archive file reaches the maximum number of data objects allowed as defined in Customizing.
   If in cases 2 and 3 there is still data to be archived, then an additional archive file will be created.
The following graphic shows the write process during data archiving:



Page 26                                                                                                       © SAP AG
Version 2.0                                                                         Managing SAP Archiving Projects
                                                                                     SAP R/3 Data Archiving Concept




                 R/3                                            Write
              database                                         program




                                                               Archive
                                                                 file




      ã SAP AG 2000


Figure 4-2: Creating the (first) archive file


4.1.2 Execute Deletion Program
After the data objects have been written to archive files the next step is to remove them from the database.
There is a choice of two step-by-step procedures that can be set in Customizing:
• Sequential execution of write and deletion jobs
• Parallel execution of deletion jobs
Sequential execution of write and deletion jobs
The deletion run is scheduled separately after all of the archive files have been written. The write run is
finished when all data objects have been written to archive files, and the last created archive file has been
successfully closed. The deletion program is then started in a second program run. During the deletion
program run, the previously created archive files are read and the relevant data objects are removed from
the database. This is illustrated by the following graphic:




© SAP AG                                                                                                  Page 27
Managing SAP Archiving Projects                                                                        Version 2.0
SAP R/3 Data Archiving Concept




                                   Write                                          Deletion
           R/3                    program                                        programs
          Data-
          base



                            Archive
                              file

                                      Archive
                                        file
                                                Archive
                                                  file
                                                          Archive
                                                            file




                                                 Write phase                Deletion phase
                                                                                                 t

      ã SAP AG 2000


Figure 4-3: Archiving session with separate execution of write and deletion jobs

Parallel execution of deletion jobs
After the system has created the first archive file and while the next archive file is being created, the system
reads the data objects from the previously created file and, if this is successful, deletes them from the data-
base. The ADK runtime system schedules the relevant read and deletion programs automatically. Data dele-
tion takes longer than writing the individual archive files, therefore there are usually several active deletion
programs working on the previously created archive files. This effectively raises the throughput of data
objects and shortens the archiving run time. The following graphic shows that a deletion job is started as
soon as the corresponding archive file has been closed, which results in the parallel execution of processes:




            R/3                Write
           Data-              program
           base




                                            Archive
                                              file
                                                      Archive
                                                        file
                                                                  Archive
                                         Deletion
                                                                    file      Archive
                                         program                                file

                                                    Deletion
                                                    program

                                                                Deletion
                                                                program

                                                                                             t
      ã SAP AG 2000


Figure 4-4: Archiving session with parallel write and deletion jobs



Page 28                                                                                                 © SAP AG
Version 2.0                                                                           Managing SAP Archiving Projects
                                                                                       SAP R/3 Data Archiving Concept

During the deletion run, the system first reads the archived data from the archive file and then deletes the
data from the database. This procedure guarantees that only data that has been correctly written to a
readable archive file is deleted from the database.

4.1.3 Store Archive Files
In general, it is not enough simply to write the data to be archived to archive files and delete it from the data-
base. The archive files themselves must be securely stored and managed so that they can be accessed at a
later date if necessary. The following graphic shows the procedure for file storage:




               R/3
                                              Storage system
              Data-
              base




                                                             Archive
                                                               file

                                   Deletion
                                                                       Archive
                                  programs
                                                                         file




      ã SAP AG 2000


Figure 4-5: Store archive files

There are several methods for storing and administering archive files:
• Hierarchical Storage Management (HSM) systems: An HSM system simulates an infinitely large file
  system. The archive file system created by the archiving process is included in the HSM system. It is
  sufficient to maintain the relevant file path in archiving Customizing. Communication using ArchiveLink is
  not necessary.
• Storage system using SAP ArchiveLink: If an external storage system is connected using SAP
  ArchiveLink, this storage system is instructed to store processed archive files at the end of a successful
  deletion run.
• Manual management: If you do not want to store the archive files in an external storage system, the files
  can be managed independently by the IT department.
For more information on the storage and management of archive files, see Chapter 9.

4.2 Data Archiving Features

4.2.1 Archivability Checks
It is important that data that is still required by the day-to-day business is not archived and thereby removed
from the database, therefore only data from closed business processes may be archived. Therefore, before
archiving data, the system checks whether the data to be archived meets the archiving object-specific
archivability criteria.
There are two basic types of archivability checks:


© SAP AG                                                                                                    Page 29
Managing SAP Archiving Projects                                                                        Version 2.0
SAP R/3 Data Archiving Concept

• General checks
• Special checks
General archivability checks
Archiving objects can be divided into the two following broad categories:
• Archiving objects that archive master data
• Archiving objects that archive transaction data
The archiving of master data is generally controlled by deletion indicators, while the archiving of master data
uses the residence time as the archivability criteria. The residence time is set in application-specific
Customizing and it refers to the period of time after which data can be archived on the basis of logical
checks. During archiving, the system checks whether the residence time for the data object to be archived
has been exceeded. Only then can the data object, such as a sales document, be archived.
Special archivability checks
Depending on the archiving object, additional application-specific checks can be implemented which can be
activated or deactivated before starting an archiving session. To improve the performance of the archiving
programs, only those checks that are absolutely essential from the business point of view should be carried
out.

4.2.2 Data Security During Archiving
To ensure that no data is lost due to errors during the archiving run, a two-step procedure is implemented for
data archiving. The first step is to write the data to archive files. The second step is to remove the data from
the database. The second step only proceeds if the archive file has been completed and can be read
successfully. This means that errors, such as data transmission errors between the database and the
archive file, are tracked before any data is deleted. If an error occurs, you can always start a new archiving
session, as the data is either still in the database or in an archive file.

4.2.3 Archiving in Parallel with Live Operations
The archiving session, which consists of write and deletion jobs, can be run at the same time as normal
operations, that is, users can continue to work normally with the system. However, performance bottlenecks
can occur, especially during large archiving sessions, when tables in which data records are being deleted
are accessed for standard operations. For this reason, we recommend that you archive data at times when
user activity is reduced. A suitable start time for an archiving session can easily be scheduled in archive
administration.

4.2.4 Data Compression and Conversion
During archiving, data is automatically compressed by up to a factor of 5. If the data to be archived is stored
in cluster tables no additional compression takes place. Metadata is stored in the archive file alongside the
actual application data so that the archive file can still be read at a much later date and after release
upgrades. The metadata includes:
• Database table schema (new and deleted columns)
• Column data type
• Column length
• Code page (ASCII, EBCDIC)
• Number format (for example, integer on various hardware platforms)
Using this information, the ADK is able to take into account changes in the database structures automatically
(field types, field lengths, new fields). This automatic adjustment is only temporary, that is, it only occurs
during the read access of the archive file. No permanent changes are made to the data in the archive file.
Because of this approach, you do not have to convert the archive when a hardware or software change is
implemented.




Page 30                                                                                                 © SAP AG
Version 2.0                                                                        Managing SAP Archiving Projects
                                                                                    SAP R/3 Data Archiving Concept

If the database structures in an application are changed to such an extent that the ADK cannot cope, for
example, where table fields are moved between tables or where a table is divided into several tables, then a
program to convert the existing archive files permanently will be provided by the application. Some
applications, such as FI, also support the temporary conversion of archive files for read access.

4.2.5 Connecting to External Storage Systems
After the system has created archive files, they can also be stored in an external archive. There are two
options:
1. Transfer to an HSM system
   The local file system is integrated into the storage hierarchy of the HSM system at operating system level.
   No action needs to be taken by the R/3 System. Due to the technical design of HSM systems, the user
   can always access the files as if they were stored on the user's local drive. As there is no procedure for
   the certification of HSM systems to be used with R/3, any HSM system that is available on the market can
   be used for data archiving. For performance reasons, however, the HSM system ought to support block
   access to archive files (see SAP Note 71935).
2. Transfer to an external storage system using SAP ArchiveLink
   External storage systems manage the archive files on tertiary storage media: These are generally
   jukeboxes with optical storage media. All storage systems presently on the market that are certified for
   the R/3 environment can be used for data archiving. In order that data objects in the storage system can
   be accessed from R/3, the storage system must support the ArchiveLink interface and be certified by
   SAP. Communication between the archiving programs and the storage system is controlled by the
   ArchiveLink interface, which the user can communicate with using the ADK.
   The majority of SAP-certified storage systems presently on the market are actually document
   management systems that can, however, also be used to store archive files in accordance with the data
   archiving framework.
Chapter 9 lists the criteria for deciding when to use external mass storage systems. Data security and
access times are important considerations when it comes to choosing a storage type and a storage media.
The decision should therefore be made carefully.

4.2.6 Access to Archived Data
Application data is moved out of the database by archive management so that it can be accessed later if
necessary.
There are two ways to access archived data:
1. Access individual data objects (for example accounting documents)
   Some archiving objects support single document access to enable the user departments to access single
   documents. This requires an index which can be filled either during or after archiving.
   Access to individual data objects in the archive can be improved using the SAP Archive Information
   System (SAP AS). It provides a convenient way to search for and to display archived data.
2. Analyze the archive file (sequential read)
   Archived data can also be used for reporting purposes. The archived data is read sequentially and basic
   information is displayed, such as item number, ordering party, purchase order date. A report can be
   spread over one or more archiving sessions.

4.2.7 Reloading Archived Data
SAP Data Archiving allows data to be read years after it has been archived, and across release upgrades.
However, the data must be correctly presented by the external storage system. Reloading archived data is
therefore not generally necessary. For this reason, reload programs are not available for all archiving
objects. SAP is not planning to support reload functions for all archiving objects.
There are two possible scenarios for the reloading of archived data:
• Reloading directly after archiving



© SAP AG                                                                                                 Page 31
Managing SAP Archiving Projects                                                                        Version 2.0
SAP R/3 Data Archiving Concept

   Typically, this occurs if you realize that you have archived too much data because incorrect selection
   criteria were set. The reload programs are specifically designed for this situation. Reloading should
   therefore usually not cause any problems.
• Reloading some time after archiving
   The reloading of archived data long after the archiving is problematic from a business point of view, since
   it can lead to database inconsistencies. For instance, a number range may, in the meantime, have
   become outdated and then been reissued. If you reload old documents, more recent documents with
   identical numbers are overwritten. Consequently, before reloading, you should always discuss this with
   your SAP consultant.

4.3 Data Archiving and Currency Conversion (Euro)
European monetary union (EMU) and the common currency, the euro, came into effect on 01.01.1999. Due
to its multi-currency functions, the SAP R/3 System is ideally prepared for the dual currency phase and for
the later conversion to a single currency. Additional functions are provided by SAP to enable the conversion
from local currency to the euro.
The introduction of the euro also increases the importance of an archiving concept. The conversion of the
local currency on a key date requires the system to be locked for a time, during which fields in the database
tables must be converted. During this time, the system will not be available for live operations. The length of
time will be in proportion to the size of the tables to be converted. In order to keep this period to a minimum,
SAP recommends that as much data as possible that is no longer required for day-to-day business
operations should be archived before the conversion date. Data objects in archive files will not be affected by
the conversion. SAP cannot, however, make a general recommendation as to when data archiving should be
performed with regard to local currency changeover. In order to be prepared for the conversion, you are
recommended to incorporate data archiving into your plans at an early stage. For more information, refer to
our guide “Data Archiving and the Euro” (see below).
After the conversion from the local currency, there may be some restrictions on operations involving data
objects that were archived before the conversion. Therefore, after conversion it will not be possible to reload
an FI document that was archived before the conversion and whose local currency has been converted.
Archiving objects that do not contain amounts, currency keys or exchange rates are not affected by the
conversion. For every access to archive files, the system checks to see whether the relevant archiving object
contains currency-related data: Critical activities are then stopped automatically.
Up-to-date information on archiving and currency conversion is contained in the SAP Notes 93697 and
99059 and in our guide “Data Archiving and the Euro”, which is available in the SAP Service Marketplace
(see Appendix E).




Page 32                                                                                                 © SAP AG
Version 2.0                                                                        Managing SAP Archiving Projects
                                                                                             Technical Background




5 Technical Background

5.1 Introduction
As illustrated in Chapter 2, data archiving in the R/3 System is characterized by a universal model. The
technical implementation is distinguished by the following features:
• Central archive administration
• Central archive Customizing
• Integration with development environment using the ADK enables you to write your own archiving
  programs for your own tables
• Central definition of archiving objects
To expand on the points listed above, section 5.2 explains basic data archiving terminology. Section 5.3
presents the Archive Development Kit (ADK), section 5.4 presents SAP ArchiveLink, and section 3.5 goes
into more detail on archiving administration. Section 5.6 provides recommendations on reorganization after
an archiving session.

5.2 Basic Terminology Explained
The archiving object is a central element in SAP Data Archiving. It defines the smallest unit that can be
archived and deleted from the database. Archiving objects specify the application object(s) to be archived.
The archiving object describes which data objects must be accessed and how to access them in order to
archive a business object fully.
An archiving object comprises three main components:
1. Data declaration: This describes all of the relevant data objects which make up an application object.
2. Archiving programs: These include:
   -    Write program: Writes data objects sequentially to the archive files.
   -    Deletion program: Deletes from the database data objects that have been successfully written to an
        archive file.
   -    Preprocessing program (optional): Prepares the data objects for the archiving session. Identifies the
        objects to be archived (sets a deletion indicator).
   -    Display program (optional): Allows archived data objects to be read.
   -    Postprocessing program (optional): Performs postprocessing after archiving, such as updating
        statistical data.
   -    Reload program (optional): Loads data objects back into the database.
3. Customizing settings: Sets archiving object-specific parameters for an archiving session.
As well as the archiving object, there are archiving classes. These are objects that have no independent
business meaning and that must be archived together with application objects. Examples of archiving
classes include SAPscript texts, change documents and classification data.
Archive administration is automatically supplied with information by the Archive Development Kit (ADK),
which provides archiving functions and subsequent access to archived data. In this context, it is important to
differentiate clearly between the archiving of application objects and the ADK:
The ADK represents a development environment for the development of archiving objects. It supports the
archiving of application objects by providing:
• Programming tools for the archiving programs
• A uniform administration screen for the control and supervision of archiving sessions.



© SAP AG                                                                                                 Page 33
Managing SAP Archiving Projects                                                                       Version 2.0
Technical Background

A connection to SAP ArchiveLink interface is also implemented using the ADK to allow the archived data to
be moved to external storage systems. To do this, the ADK sends a store command to ArchiveLink, which
controls communication with the storage system and allows archive files to be collected. There is more
detailed information on the ADK in the following section.

5.3 Archive Development Kit (ADK)
The ADK is the central component for controlling an archiving session. It contains functions for the analysis
of individual archiving objects and for the administration of archiving sessions. The ADK includes the
following transactions:
• Transaction SARA for archive administration
• Transaction AOBJ for the definition of archiving objects
• Transaction ACLA for the definition of archiving classes
• Transaction DB15 for monitoring the storage in the database
The following graphic shows how the ADK is embedded in the system environment:




              R/3 System

                                          Database




                L                                                          Archiving
                D                      ABAP/4 Program                      class
                B


                      ADK:   Adjust codepage, number format, structure changes;
                             random access, compression, batch handling, index ...



              ArchiveLink                Archive file       manual

                                        HSM

                         Storage system with
                        tertiary storage media

      ã SAP AG 2000


Figure 5-1: Archive Development Kit (ADK)

The ADK provides programming interfaces for the application programs that implement the following
functions:
• Writing archive files
• Reading archive files
• Including archiving classes
The ADK processes the archive files, that is, it creates, opens, describes, reads, and then closes them.
The following functions are also included in the ADK:
• Control and parameterization of the archiving session
• Central repository in which definitions of the archiving objects are stored
• Management of archive files




Page 34                                                                                                © SAP AG
Version 2.0                                                                           Managing SAP Archiving Projects
                                                                                                Technical Background

• Guarantee of interpretability: This includes the readability of bit sequences and the conversion of the
  code page, in case there are differences. Furthermore, the ADK carries out automatic structure
  conversions where changes have occurred in the database objects.
To guarantee this function, the ADK writes additional metadata to the archive file so that the archiving
programs do not have to do this. The relevant metadata is read automatically by the ADK from the archiving
repository.
The ADK is integrated with the archiving programs by means of ADK function modules. The application
programs get the logical data objects for themselves from the database by using SQL commands to fetch
the data over the database interface. The ADK stores selected data objects in a uniform format in the
archive file. The archiving programs do not have to deal with the physical transfer and storage of the data,
since this function is performed by the ADK.
The user specifies which data objects should be archived. The archiving programs check whether the data is
allowed to be archived. To do this, the relevant archivability criteria are applied, such as residence times,
deletion indicators or integration with the business environment. The application programs implement their
own complete check logic.
Access to archive files is controlled centrally by the ADK. At the same time, the ADK writes administration
information to the database, which is later used to read the archived data from the R/3 System. The
archiving of archiving classes results from inclusion in the archiving objects.
Storage can start after the archive files have been created. The archive files can either be moved using SAP
ArchiveLink to other storage media or transferred to an HSM system. Where an HSM system is used, the
system instructs the ADK to store the archive files in the file system of the HSM system. From the point of
view of the application programs, the archive files are transparent because access and management are
controlled automatically by the HSM system.
If data archiving is linked to an external storage system using SAP ArchiveLink, a message is sent by the
ADK by means of the SAP ArchiveLink interface to the storage system to initiate archive file storage.


5.4 SAP ArchiveLink
SAP ArchiveLink is a cross-application tool that serves as a communication interface between R/3
application components and storage system components (usually certified optical storage systems).
SAP ArchiveLink provides interfaces and basic storage, search and display functions for business
documents (for example, scanned invoices, offers, orders) to the R/3 applications. Data Archiving is one of
these applications used for the storage of archive files. With its document functions, SAP ArchiveLink
supports incoming documents (such as scanned originals), outgoing documents (SAPscript) and print lists
(print lists).
Storage and display of incoming documents
SAP ArchiveLink supports various scenarios relating to incoming documents:
• The scenario “Storing for subsequent entry” contains, for example, the central scanning of incoming sales
   documents and the automatic transfer of the documents to the person responsible for the subsequent
   decentralized creation of SAP documents within R/3. The individual creation of a scenario for incoming
   documents is further simplified by the Workflow-Wizard.
• The scenario “Late storage”, that is, linking an existing SAP document with a document to be scanned, is
   possible by manual assignment (since Release 4.5, also possible with workflow support) or automatically
   by using a barcode.
Storage and display of outgoing documents
When printing (from Release 4.6A, this is also possible using FAX or email) SAPscript documents, these can
also be stored and assigned to a business object at the same time. They can be displayed directly from an
SAP application document or from SAP ArchiveLink administration.
Storage and display of print lists
Print lists (mostly, R/3 reports) that contain data that is required later for auditing purposes, for example, can
be stored at the same time as printing. New reports can also be written for the creation of print lists that can



© SAP AG                                                                                                    Page 35
Managing SAP Archiving Projects                                                                                      Version 2.0
Technical Background

also contain hyperlinks for access to single documents. Print lists can be displayed using SAPGUI
(recommended from Release 4.5) or using the SAP ArchiveLink viewer.
Storage system
You can use the same storage system for the storage of archiving objects and business documents. This
enables worldwide access to a centrally managed, (but also possibly decentralized) store.
SAP ArchiveLink contains the following interfaces:
• To R/3 applications
• To components of the storage system based on OLE/RFC, and, since Release 4.5B, also
   HTTP/OLE/BAPI.
The following graphic shows the component view of SAP ArchiveLink solutions. SAP ArchiveLink interfaces
are indicated by a two-way arrow.




                                                  SAPconnect
                                                  SAPconnect                 SAPoffice
                                                                             SAPoffice

                   FI

                                                                R/3 Basis                                       MM
                   SD                                                                                     DMS
                                                                                                          DMS   PP
                                                                    SAP
                        Direct integration




                                                                    SAP
                   MM                                         Business Workflow
                                                              Business Workflow
     Applicatoin




                                                                                                                SD
                                                                                                          MC
                                                                                                          MC
                                                               Object services
                                                               Object services                                  MM
                   QM

                                                                    SAP
                                                                    SAP                                         FI
                   PM                                            ArchiveLink                              ADK
                                                                                                          ADK
                                                                 ArchiveLink                                    SD


                   PP                                                                                           MM



                   HR                        Storage system      Entry programs       Display programs

                                                                                  ArchiveLink Viewer
                                                                                  (before 4.5)
                                                                                  Business Document
                                                                                  Navigator (as of 4.6)



          ã SAP AG 2000


Figure 5-2: Component Overview SAP ArchiveLink

The following graphic shows the role of SAP ArchiveLink in the archiving process:




Page 36                                                                                                              © SAP AG
Version 2.0                                                                          Managing SAP Archiving Projects
                                                                                               Technical Background




       Application                         ADK


                       Archive                        Link between archiving
                        data                          session and archiving object
                                            Request


                                                  ArchiveLink


                              Create                                 Confirmation
                           archive files
                                                           Request

                                                                       Storage
                                                                       system


                                                      Store files



      ã SAP AG 2000


Figure 5-3: Data storage using SAP ArchiveLink

Transferring files using SAP ArchiveLink
In Customizing, you can specify whether the archive files created during an archiving session should be
transferred to an external storage system.
There are several steps to creating and transferring archive files using SAP ArchiveLink:
1. ADK writes the data sequentially to an archive file which is closed as soon as either the maximum file
   size or the maximum number of data objects is reached.
2. The archive files are opened in read mode and the data objects that can be successfully read from the
   archive files are deleted from the database.
3. The ADK informs the storage system by means of SAP ArchiveLink that data storage can proceed.
4. The storage system copies the archive files from the archive directory to the archive medium.
5. The storage system sends the status back to SAP ArchiveLink. This in turn informs the ADK whether the
   archive files were copied successfully to the storage system. If it was successfully copied, then the ADK
   deletes the archive files from the file system.
Access to files using ArchiveLink
During the read process, the display program requests a data packet from the storage system by using the
ADK. The ADK then gives the path and the name of the archive file to the ArchiveLink interface. For direct
access, an additional offset specification is also given to position the file pointer.
There are different procedures depending on the release:
Releases before 3.1I
The complete archive file from which the data objects are to be read is then copied back into the archiving
directory, then the file is opened in read mode.
Release 3.1I and above
The relevant data blocks are passed directly to the ADK layer using a byte-stream interface without
physically copying the archive file back into the local file system. The data is decompressed by the ADK
layer and passed on to the read program which then undertakes the actual formatting of the data objects.




© SAP AG                                                                                                   Page 37
Managing SAP Archiving Projects                                                                             Version 2.0
Technical Background


5.5 Archiving Administration
The actual archiving session is scheduled and processed as a background job. As explained above, the data
objects are first written sequentially to an archive file. If a specific pre-defined file size is reached, or if the
maximum number of data objects is reached, the system will close the archive file and open a new one.
There are two possible scenarios for deleting data from the database:
• Separation of delete and write jobs
   The deletion run is scheduled separately, that is, after all archive files have been written. See Chapter 2
   for more information.
• Parallel execution of deletion and write jobs
   If deletion and write jobs are scheduled to run in parallel, several data objects can be processed
   simultaneously. For more information, see also Chapter 2.
You can specify one of the above scenarios in Customizing.
Archiving process flow
The technical process flow of archiving generally includes the following phases:
1. Customizing
    -     General Customizing
    -     Object-specific Customizing
2. Archiving session
    -     Archive
    -     Delete
3. Archiving management

5.5.1 Customizing
General Customizing
Only points that are relevant for archiving are listed here:
• Application-specific Customizing
   The individual applications partly provide the criteria for the archivability or deletability of application data.
   These settings are made in Customizing for the relevant application. An example of this is the setting of
   the residence time.
• Customizing for SAP ArchiveLink
   Some Customizing is required if the archive files are to be transferred to a storage system over the
   ArchiveLink interface.
• Platform-independent filenames
   The archive files are stored in different directories depending on the operating system. The path and
   filenames therefore have a different syntax. Consequently, platform-independent “logical” filenames are
   used so that the archiving programs do not have to handle the technical details of allocating physical
   names. In the ADK runtime system, the logical filename is used to generate a corresponding physical
   filename.
You can find detailed information on Customizing for Data Archiving in the R/3 online documentation.
Archiving object-specific-Customizing
The following parameters must be set in archiving object-specific Customizing:
• Logical filename
   Select a logical filename for use by the archiving object. At runtime, the ADK generates a physical
   filename from the logical filename.



Page 38                                                                                                      © SAP AG
Version 2.0                                                                        Managing SAP Archiving Projects
                                                                                             Technical Background

• Archive file size
   Enter the maximum size that an archive file is permitted to reach before it is closed. You can establish the
   size in MB and/or the maximum number of data objects which can be written to an archive file. Both
   values are queried by an OR operation.
   As soon as either the maximum file size or the maximum number of data objects is reached, the system
   will close the archive file and create a new file.
• Deletion program settings
   You can specify whether the system should execute the deletion program automatically after an archive
   file has been created.
   Using the Commit Counter parameter the number of data objects required in the deletion program before
   a DB commit is triggered.
For example, the archiving object-specific Customizing screen for the object SD_VBAK looks like this:




Figure 5-4: Archiving object-specific Customizing


5.5.2 Archiving Session
• Archiving
   The archiving session selects the data objects from the database. The system observes the relevant
   integrity conditions which characterize a data object. It then checks each archiving object to see whether
   it is allowed to be archived. If this is the case, the data object is written to the archive file. If, in
   Customizing, you have set the deletion program to run automatically, the accompanying deletion run
   starts automatically.




© SAP AG                                                                                                 Page 39
Managing SAP Archiving Projects                                                                       Version 2.0
Technical Background

• Deletion
   The deletion run must be scheduled separately if it was not executed automatically at the archiving stage.
   A selection of archive files must be made from which data objects in the current deletion run have been
   read and subsequently deleted from the database.
   The following shows a file selection screen for sales documents:




Figure 5-5: Selection of files to be deleted

   Only archiving sessions that the deletion program has not yet processed are listed in the file selection
   screen. Every archiving session is identified by an archiving session number and a date. An additional
   description text can also be displayed if it has been entered in archive administration.
   You can select a complete archiving session, including all of the archive files belonging to that session,
   by choosing the archiving session checkbox. To select individual archive files from a session, expand the
   session and choose the relevant files. The small rectangle next to the checkbox can display the following
   statuses:
   •      Fully shaded: Complete session selected (including all archive files)
   •      Half shaded: Individual archive files selected
   •      Not shaded: No archive files selected
For some archiving objects, there are special preprocessing and postprocessing programs that are used for
the preparation and cleanup of an archiving session. For example, there are postprocessing programs to
update statistical data after a successful archiving session.




Page 40                                                                                                © SAP AG
Version 2.0                                                                           Managing SAP Archiving Projects
                                                                                                Technical Background

5.5.3 Management of Archive Files
The system has to do more than just write data to archive files. In order to access the files at a later date,
R/3 stores management data on the archive files that can be displayed for any archiving session. This
includes:
• Information on all archive files belonging to the archiving session
• Name, date, time and status of the archiving session




Figure 5-6: Overview of archiving sessions

The above screenshot shows the overview of archiving sessions for sales documents.
The red traffic light shows that the first archiving session was not completed successfully. The yellow traffic
light shows that the archiving session is incomplete, that is, the deletion program has not yet been run. The
third archiving session is “complete” (green light).
Additional detailed information can be displayed for each archive file, such as:
• Number of data objects
• Size in MB
• Archiving status
• Logical file path



© SAP AG                                                                                                    Page 41
Managing SAP Archiving Projects                                                                         Version 2.0
Technical Background

• Physical filename
The following screenshot shows detailed information on an archiving session for sales documents:




Figure 5-7: Archive file details

After a certain period of time, archived data may no longer be needed. This is the case when that the data
no longer needs to be kept for legal or business reasons, or if the data has been transported to another
format where it remains accessible (such as print lists, microfiche or statistics systems). The decision
whether to delete archived data is dependent on several factors.
Several actions are required to delete a complete archiving session:
• Deletion of archive files at operating system level
• Deletion of management information in the R/3 System
Double-click on the archiving session. A dialog window appears in which the deletion flag (“Archiv. notes”)
must be set. Direct deletion of the management entries is only possible in the corresponding archiving
session. To do this, the system first writes the entries to an external file and then deletes them. The relevant
archiving object is called BC_ARCHIVE. This starts an archiving session during which all management data
marked by the relevant deletion flag for the session is deleted. The management data is now in an archive
file and can be reloaded if necessary.
The following screenshot shows the setting of the deletion flag for management records for an archiving
session (sales documents):




Page 42                                                                                                 © SAP AG
Version 2.0                                                                        Managing SAP Archiving Projects
                                                                                             Technical Background




Figure 5-8: Setting the deletion flag for an archiving session


5.6 Restarting Archiving After a Program Termination
The procedure for restarting archiving after a program termination during an archiving session depends on
several factors:
• The archived object being used
• The time of the termination (during write or deletion program)
• The cause of the termination

5.6.1 Termination Occurs During Write Program
Depending on the frequency with which the termination occurs, there are two possible error scenarios:
• General scenario
• Special scenario
5.6.1.1 General scenario
In this case, it is immaterial whether the deletion programs for previously closed archive files were
successfully run or not. When creating a new archive file, the system generates a corresponding
management entry for subsequent access and sets the internal status to “created”. The status “active” is not
set in archive management until the archive file has been closed correctly. Only then is the ADK able to
present this archive file for processing by a read or deletion program or present it to the SAP Archive
information system.
In a write run, the archive files are created sequentially, which means that data cannot be written to several
archive files at the same time. Consequently, all archive files that were created prior to the termination
remain error-free, with the exception of the one that was being processed at the time of the termination. The
deletion program first reads the archive file that was created and then deletes the corresponding data from
the database. The ADK thereby ensures that deletion programs are only scheduled for archive files that
were correctly created. In the case of errors, the ADK marks the archive file that was processed last (and
that was not closed correctly) as invalid.
The following graphic shows an overview of the error scenario (the incorrect archive file is marked with a
lightening symbol):




© SAP AG                                                                                                 Page 43
Managing SAP Archiving Projects                                                                         Version 2.0
Technical Background




     Customizing setting: Deletion programs are scheduled after completion of
     one archive file (flag Start at end not set), or manually after completion of all
     archive files



                                                                     Write
              R/3
              R/3                                                   program
           Database




                             Deletion                                   Archive
                                                          Archive
                             program                                     file 3
                                                           file 1




                             Deletion
                                                                    Archive
                             program
                                                                     file 2


      ã SAP AG 2000


Figure 5-9: Termination during write program (general scenario)

Procedure
1. Schedule the deletion runs for the archive files that closed successfully.
2. Delete the defective archive files on the file system level.
3. Wait until the scheduled deletion jobs have been processed.
4. Run archiving again using the same selection criteria as you used for the write program that terminated.
   Only the data that was not processed in the first run is selected, since the processed data has already
   been deleted from the database.
5.6.1.2 Special scenario
This error scenario occurs relatively rarely - hence the designation “special scenario”
In this case, a snapshot of the database is archived, for example, for the evaluation of the investment values
of an enterprise at a particular time. If the write program terminates, this snapshot is incomplete since not all
data could be written to the archive files. In this situation, you must not schedule the deletion program.
Before restarting the archiving session, refer to the online documentation for the archiving object being used.
When the write program terminates, the archive file that was processed last and that could not be closed, is
marked by the ADK as invalid. Since the write program terminated, the deletion program is not automatically
started, which means that all the selection data continues to exist in the database.
The following graphic shows an overview of the error scenario (the incorrect file data is marked with a
lightening symbol)




Page 44                                                                                                  © SAP AG
Version 2.0                                                                           Managing SAP Archiving Projects
                                                                                                Technical Background




    Customizing setting: Deletion programs are scheduled after completion of
    all archive files (flag Start at end set)




                                                               Write
                 R/3
                 R/3                                          program
              Database




                                                    Archive         Archiv-
                                                                    Archive
                                                     file 1          file
                                                                    datei33




                                                          Archive
                                                           file 2



      ã SAP AG 2000


Figure 5-10: Write program termination (Special scenario)

Procedure
1. In the file system, delete all archive files that were created in the terminated archiving session - including
   those that were correctly created.
2. For the correctly created archive files, mark the deletion indicator in archiving management.
   This prevents the archive files from being offered for selection in reports.
3. Run archiving again using the same selection criteria as you used in the terminated write run.
   As an option, you can then use archiving object BC_ARCHIVE to delete the management data for the
   deleted archive files.

5.6.2 Termination Occurs During Deletion Program
A deletion program can terminate for various reasons. If this occurs, you are advised to read the
documentation for the relevant archiving object. There may be occasions, even in heterogeneous system
environments, when deletion programs cannot open the archive files because no access is possible to the
directory in the file system. Analyze the problem and try to remove the error. You can also search for SAP
Notes to help you to analyze the problem.
Deletion program terminations can be divided into the following scenarios:
• Archive files are accessible
• Archive files are not accessible
5.6.2.1 Archive files are accessible
The following graphic shows the initial situation for this error scenario (the terminated program is marked
with a lightening symbol):




© SAP AG                                                                                                    Page 45
Managing SAP Archiving Projects                                                                         Version 2.0
Technical Background




    Diagnosis: Program terminates during deletion, access to archive files possible




                         R/3
                         R/3
                      Database




                                  Deletion                       Archive
                                  program                         File 1


                                                                     Archive
                                                                      file 2




      ã SAP AG 2000


Figure 5-11: Write program termination (Access to data possible)

Procedure
1. Try to determine the cause of the error - check the system and job logs.
2. Remove the problem that led to the deletion program termination.
3. Run the deletion program for the affected archive files again. You can set any start time.
5.6.2.2 Archive files are not accessible
As the deletion program may have already deleted data from the database, it is necessary to try to
reconstruct the archive files using the repair program. This should be carried out by your consultant or SAP
support.
The repair program tries, as far as possible, to read the archive files and to write the read data to new files.
The new files must then be entered in file management as substitutes for the defective files. Subsequently,
the deletion program is run for these files. The data that could not be read remains in the database and can
be deleted in a later archiving run.
The following graphic shows the initial situation for this error scenario (program termination and incorrect
archive file are marked with a lightening symbol):




Page 46                                                                                                  © SAP AG
Version 2.0                                                                                 Managing SAP Archiving Projects
                                                                                                      Technical Background




    Diagnosis: Program terminates during deletion, access to archive file(s) not possilbe




                         R/3
                        R/3
                      Database




                                  Deletion                        Archive
                                  program                          file 1


                                                                     Archive
                                                                      file 2




      ã SAP AG 2000


Figure 5-12: Deletion program termination (Access not possible)


5.6.3 The most common causes
The following discusses the causes for the errors that most commonly result in program termination in data
archiving.
Insufficient memory space
This is mostly the case if the memory space in the file system has been fully used with the result that no
further archive files can be created. To estimate the amount of memory space required, the size of an
archive file that is to be created can be determined in test mode. From Release 4.5, the amount of memory
space available can be determined exactly using the archive-directory function in the current object-specific
archive directory.
Access to file system not possible
Up to and including Release 4.0B, write runs can be scheduled on all application servers that have been
configured for background operations. Write and deletion runs are given priority scheduling on the database
server in cases where an instance is running with free background work processes.
To prevent a termination of the write or deletion programs, the file system in which the archive files are
created should be accessible to all application servers that are configured for background processes.
Otherwise, it is recommended that you configure a dedicated batch server with exclusive access to the file
system in which the archive files are to be created. Ensure that write and deletion programs are scheduled
on various application servers if free background processes are configured.
From Release 4.5, you can specify an application server to run write and deletion programs. You make this
setting in Customizing for the transaction SARA. You must ensure that the corresponding batch processes
can access the file system.
Database: Overflow in log files for change documents
This error occurs if the area on the working memory is too small to store data record changes temporarily
until the database commit is processed, or, conversely, if the quantity of data is too large.
• Reduce the value specified for the commit counter
• Reduce the size of the archive file
• Increase the size of the roll back segment



© SAP AG                                                                                                          Page 47
Managing SAP Archiving Projects                                                                        Version 2.0
Technical Background

Database: 1555 – Snapshot too old (only Oracle)
This error occurs if very large quantities of data are transferred to the database for processing, for example,
if the user makes selection settings that involve large amounts of data. The database is no longer able to
handle such quantities correctly and the archiving program terminates the program with the SQL error “ORA-
1555”.
The problem is avoided by reducing the data selection when archiving, or by increasing the relevant
database parameters. In some cases, it is sufficient to restart the archiving run again later using the same
parameters when there is less pressure on the system.
Problems with database locks
Since some database systems switch dynamically from individual record locks to generic locks, this may
lead to a termination in the case of parallel deletion runs. In this case, the deletion runs should be scheduled
manually in sequence.
Internal memory for the write/deletion program is too small
In this case, you should raise the value of the rdisp/pg_maxfs parameter.
At runtime, parts of internal tables and extract datasets are used or temporarily stored in the paging area.
How quickly the paging area overflows depends on the number and size of the memory areas that are
created for the various work processes. The size of these areas is controlled by the above parameter.

5.7 Reorganization of the Database
Database reorganization involves a redistribution of physically fragmented data in order to move the data to
contextually related memory areas.
The removal of data from the database using an archiving object’s deletion program can, in combination with
the usual table maintenance, reduce system performance. Database reorganization should therefore be a
regular system administration task. To determine how often reorganization if required, you should determine
how often data objects are removed from the database and establish the degree of fragmentation that this
creates in tables and indices.
For further criteria on carrying out reorganization after data archiving, refer to SAP Note 53062.
For more information on reorganizing ORACLE and Informix database systems, refer to the following
TechNet articles: R/3 Storage Reorganization in an Oracle Database (Technet à DB Admin. Oracle à
Knowledge Base) and Reorganizing an Informix Database (Technet à DB Admin. Informix à Knowledge Base).




Page 48                                                                                                 © SAP AG
Version 2.0                                                                            Managing SAP Archiving Projects
                                                                                               Access to Archived Data




6 Access to Archived Data
The most important precondition for archiving application data is that the business transaction to which the
data belongs has been completed, and that the periods to which the data refers are in the past. This ensures
that the data is no longer required for current business processes. Data should only be archived if access
will only rarely be required, for example in the case of a complaint, or for reporting purposes, or if there is an
internal or external audit. ADK stores data in such a way that enables read-access at any time. To read the
data, you must have the relevant read programs which the relevant archiving object makes available. These
read programs retrieve the archived data according to the selection criteria and to display it in a form that is
appropriate for the user. Usually, two forms of access and display are used:
• Sequential access
• Direct access

6.1 Sequential Access
Sequential (read) access is the simplest form of access to archived data. Here, the read program first opens
sequentially the archive data in an archive session, reads the contents of all data objects and prepares a list
of all the data that matches the selection criteria.
Using this method, all data objects, - for a specific period or a specific document number range, for example
- are displayed. Further selection criteria can also be specified, for example, all material documents for a
specific factory; all material numbers belonging to a particular batch; all document numbers for a specific
controlling area. The type and number of selection criteria depends on the application. How the data is
displayed depends on the display function that was used for the archiving object. The display is not the same
for all data objects. Sequential read-access is mainly used for the evaluation of archived datasets and is a
standard function of most archiving objects.
An authorization strategy ensures that archived data that is later read by a Data Archiving read program is
protected in much the same way as access to application data. Various authorization tests take place in the
sequential read program itself as well as when the user enters the archive administration transaction
(SARA). The central authorization object for archiving activities S_ARCHIVE is also used for sequential
access.
The performance of a sequential read program depends mainly on the range of data for display. If you do not
make any entries in the selection screen (which means that all data objects are to be displayed), the read
program must read all the data in the selected archiving sessions before the data objects can be displayed.
This leads to a serious diminution in the performance of the read program. For faster access to archived
data objects, you are advised to use the direct access function (see Section 6.2).

6.2 Direct Access
Direct access (also known as single document access) to archived data objects, such as an order or invoice,
can only be carried out with the aid of an index table. The data object to be displayed is first restricted to
search criteria within the index table. If this is successful, the archive file containing the relevant data object
is located using the index and opened. The read program is now able to access the data object and display
it. Direct access of this kind requires extensive programming, and is therefore only available for a few
archiving objects, such as FI_DOCUMNT.
SAP Archive Information System offers a considerably more comprehensive, and easier to use function for
swift direct access to data objects. This function is discussed in more detail in the next section.
In addition to reading and displaying archived data objects, most read programs are also able to include in
the display independent data that are not part of an archiving objects. This is the case, for example, for
scanned original documents, CAD drawings, work items, Idocs, and e-mails. These documents are usually
necessary to reconstruct the original process context in which the data objects came about. This includes
links to independent data objects, such as the preceding or subsequent document within a process chain.
The scope of the function available in this context depends on the archiving object. With the aid of the SAP
Archive Information System, this is largely possible for SD (see Section 6.3.3.3).



© SAP AG                                                                                                     Page 49
Managing SAP Archiving Projects                                                                           Version 2.0
Access to Archived Data

For more information and examples on developing your own solutions for accessing archived data, you are
advised to take SAP‘s training course BC670 “Data Archiving - Retrieval Programming“ (See Appendix E)

6.3 SAP Archive Information System
From Release 4.5A, the SAP Archive Information System (SAP AS) is a part of R/3’s standard functions and
can be installed on previous releases down to and including 3.0D. For more information, refer to SAP Note
99388.

6.3.1 Concept and Use
The SAP Archive Information System is a retrieval tool that is fully integrated into the archiving environment,
and assists the user with information retrieval in R/3 data archives. It also offers functions for the display of
data.
Data retrieval takes place using archive information structures. These are transparent database tables
that contain data from the archive. As with other R/3 information systems, such as the Logistics Information
Structures (LIS) or the Sales Information System (VIS), these tables are referred to as information structures.
These are composed of the structure itself, the relevant transparent database table and an evaluation
program. When a new information structure is created, only the structure is created in the first instance. The
database table and the evaluation program are only generated when the information structure is activated.
An archive information structure is always assigned to an individual archiving object. For more information on
archive information structures, see below.
The Archive Information System is a generic tool, that is, the available functions can be used for all existing
archiving objects. To retrieve archived data for an archiving object, there must be at least one archive
information structure. The information structure should contain all the fields that are required for the retrieval.
The user can, if necessary, change the contents of the information structure by removing or adding fields
from an existing SAP field catalog (see below).
When displaying archived data, the user can usually choose between several views for displaying data
objects. For example, there is technical view and a business view. A technical view is available for all
archiving objects. The availability of application-views depends on the implementation settings for the
relevant archiving object.
For more information on the SAP Archiving Information System, refer to the SAP Library under CA - Cross-
Application Components → CA - Application Data Archiving → Introduction → Archive Information System (SAP AS).

6.3.2 Components
The SAP Archive Information System can be called from Archive Administration (transaction SARA) or
directly using transaction SARI (from Release 4.5A). It is composed of the following components:
1. Archive Retrieval Configurator
2. Archive Explorer
3. Status Administration
The following graphic shows the interaction between the two main components, the Archive Retrieval
Configurator and the Archive Explorer, when creating and evaluating an information structure:




Page 50                                                                                                    © SAP AG
Version 2.0                                                                           Managing SAP Archiving Projects
                                                                                              Access to Archived Data




                                SAP Archive Information System


                         Archive Retrieval
                                                    Archive Explorer
                           Configurator



                      creates         Archive information        reads
                                           structure




                                        Archive files

      ã SAP AG 2000


Figure 6-1: Overview of the SAP Archive Information System

6.3.2.1 Archive Retrieval Configurator
Using the Archive Retrieval Configurator (ARC), archive information structures can be created based on a
field catalog and filled with data from archive files. Furthermore, it enables the user to create his or her own
field catalogs.
Archive Information Structure
An information structure fulfils the same functions as an index. In addition to the search fields, it contains
further information that is required for access to an archived data object. This includes the name of the
archive file in which the data object is located (field ARCHIVEKEY) and the address for the data object (field
OFFSET). This facilitates access to specific business documents.
Furthermore, the information structure can contain more information on the content of the data object, such
as the company code, document number, fiscal year of a financial accounting document. This provides a
minidocument or extract, the contents of which are often sufficient for the user to form a picture of the data
object. It is often not necessary to display further data relating to the business context of the data object
(refer to the section Archive Explorer, below). This is significant with reference to the size of the information
structure and of the transparent database table that is stored in the R/3 database. If this table contains
numerous fields with the corresponding information, this may have a counterproductive effect on the memory
space that was gained by archiving. In this situation, it is necessary to find a balance between the user’s
needs, the possibility of seeing all the data in the database, and the IT department’s cost restrictions.
The information structure is constructed from the fields that are specified in the underlying field catalog. The
user selects the data fields that he or she requires for data retrieval in the archive. This also determines
which source fields are transferred to which fields in the information structure. This is determined in
application-specific field catalogs that are available within the functions of the SAP Archive Information
Structure (see below).
Before an information structure can be constructed, that is, filled with data from the archive, it must first be
activated. This means that the system generates a transparent database table and the evaluation program in
the background. There are two methods for filling an active information structure with archive contents:
• Automatically, when running the deletion program
• Manually by the user
When the deletion program is started for an archiving object, all the active information structures that belong
to this archiving object are filled. The Archive Development Kit (ADK) transfers all the datasets that it finds in


© SAP AG                                                                                                    Page 51
Managing SAP Archiving Projects                                                                         Version 2.0
Access to Archived Data

the archive to the SAP AG interface. Based on the defined information structure, the SAP AG interface filters
the data from the transferred data records and inserts them, together with an access key, in a transparent
database table. This table serves as the basis for subsequent retrieval.
In addition to this automatic option, the user also has the option of constructing information structures using
a special structure construction program. This is primarily required if evaluating existing archives, or if a new
structure has to be created due changes in the field selection.
The following graphic gives an overview of both these options.




              R/3 Database


            Data
           objects                           Deletion
                                             program

             Info
          structures
                                                                   Archive files




      ã SAP AG 2000


Figure 6-2: Automatic construction of an information structure




              R/3 Database
                                        Structure creation
                                            program


               Info
            structure                                               Archive files




      ã SAP AG 2000


Figure 6-3: Construction of an information structure by the user




Page 52                                                                                                  © SAP AG
Version 2.0                                                                          Managing SAP Archiving Projects
                                                                                             Access to Archived Data

Field Catalog
A field catalog is the basis for the construction of an archive information structure. It contains the names of
all fields whose contents are to be archived by the relevant archiving object and with which the search for
specific data objects is possible. The selected fields can originate from one or several source tables.
The field catalogs that are supplied with SAP AS in the standard system contain all the fields from the main
table that is normally required for the relevant business context. Usually, these are all the fields in an
archiving object’s main tables, such as header tables and position tables (VBUK and VBUP) for an SD order.
The user does not usually need to create individual field catalogs.
In order to create a customer field catalog, knowledge of the data structure and of the archiving object is
indispensable. To assist the user in this process, SAP has supplied standard field catalogs that can be used
as a guide or a template. Field catalogs are created and edited using transaction SARJ or by choosing
Environment à Field from the main menu in SAP AS.
At present, the SAP Archive Information System only offers field catalogs for several important archive
objects. In future, there will be appropriate field catalogs for all archiving objects.
6.3.2.2 Archive Explorer
A further component of the SAP Archive Information System is the Archive Explorer, which is based on the
functions of the ABAP List Viewer (ALV). The Archive Explorer makes it possible to display archived data
objects. The order in which the fields are displayed is determined by the information structure.
In the selection screen, it is possible to specify which data objects are to be read by the Archive Explorer
evaluation program. Based on this selection, an object list is displayed for the selected information structure.
From this list, it is possible to access individual data objects in the archive.




                             Analysis
                             program
     Archive
       info
    structure




      ã SAP AG 2000


Figure 6-4: Evaluating an archive information structure in the Archive Explorer

The archive information structure already contains the most important elementary data for a data object such
as the document number or the creation date.
For viewing the data objects, there is at least a technical view available. Depending on the archiving object,
there may also be application-specific views that offer a better business orientation. The design of the view is
based on the original view in the application. The user should therefore find a familiar environment, and
should experience no difficulties in identifying the required information.
In addition to this evaluation method, there is also the option of an ad hoc evaluation, which is particularly
suitable for test purposes. This function also requires an archive information structure, although in this case,



© SAP AG                                                                                                   Page 53
Managing SAP Archiving Projects                                                                          Version 2.0
Access to Archived Data

the structure does not need to be filled. This type of analysis accesses the archive file directly without going
through the database table. This process can, however, be time-consuming, and it is advisable to use only
small selection quantities or restrict use to test purposes. One advantage of this method is that it relieves
pressure on the database, since it does not require the construction and storage of a database table for the
fields that are to be displayed.
6.3.2.3 Status management
The status management function supplies information on whether an information structure was successfully
constructed or deconstructed. Status management can also trigger construction and deconstruction of
activated infrastructures. When constructing, the relevant tables in the database are filled with information
from the archive files. This process occurs in the background.
The information can be displayed in two views:
• Status per archive
   This view provides a list of all archive sessions that have taken place for a selected archiving object as
   well as all the information structures that are assigned to the sessions. The list shows the archiving
   sessions for which the active structures were constructed and whether there were problems.
• Status per infostructure
   This view provides information on the status of all active information structures that exist for a specific
   archiving object and on the status of the processed archive files. It is possible to see whether an archive
   file for an information structure was evaluated completely, partly or not at all.
Further management status functions include checking indexing and displaying file residence. In the former,
the system searches for archive files for which data was transferred from the source fields to the information
structure. Such archive files are then marked accordingly. The second function checks whether individual
archive files are being accessed by the Archive Development Kit (ADK). If this is the case, this file can be
taken into consideration when constructing an information structure. Direct access to the data object using
the Archive Explorer is only possible if the ADK can access the archive file.

6.3.3 Enhanced Display Options: Examples from SD
6.3.3.1 Setting up a business view
For some retrieval jobs, the information contained in the technical view is insufficient. Consequently, for
many archiving objects, it is possible to display further information on the business context of the data object
by using an application-specific or business view. For archiving objects that do not offer this option, you can
program your own application-specific formatting of the data. The following uses the example of SD to
outline how a view of this kind can be set up. This example can, however, only give an overview of the
concept. For more information, refer to the online documentation for SAP AS or attend the SAP training
course BC670, which addresses this topic specifically.
6.3.3.2 Enhancing the SAP AS interface
To set up a business view in addition to the technical view, you need to have the following in the R/3
System:
• A function module
• An entry in table AIND_STR5
The function module carries out the following tasks:
1. Opens the archive
2. Reads the required data
3. Closes the archive
4. Formats the data
The name of the function module is entered in table AIND_STR5 using the Data Browser (transaction SE16).
This creates a link between the archiving object - in this example, SD_VBAK - and the new function module.
It is also possible to enter a descriptive text, for example, “Customer order“.




Page 54                                                                                                  © SAP AG
Version 2.0                                                                                      Managing SAP Archiving Projects
                                                                                                         Access to Archived Data

The function module that is to be set up is called from the function KASH_ARCHIVE_DATA_FILE_SHOW.
This program forms the core in SAP Archive Information System process program. Its task is to make
available an evaluation of archive files for any archiving object. The following diagram illustrates how this
function module is called in relation to the entries in the table AIND_STR5:



                                        Function module
                                KASH_ARCHIVE_DATA_OBJECT_SHOW


                                    Determine archiving object



                                                Are there
                                           any entries in table
                                             AIND_STR5 ?
                                Y                                               N
              More than one?


                            Y

                                          Display dialog box


                        N               Determine function module for
                                        selected entry from AIND_STR5



                                            Is the name of
                                         the function module
                                                stored?
                                    Y                          N
         Run function module                                            Display technical view



      ã SAP AG 2000


Figure 6-5: Selection of views in SAP AS

The following values are transferred to the function value for the business display of archiving object
SD_VBAK:
• Name of the archive file (ARCHIVEKEY)
6.3.3.2.1 Displaying the data
The data can be displayed in the following two ways:
• As a screen
• In list form
The screen-oriented display is primarily of interest for archiving objects in the CO area since standard
screens can be accessed without difficulty. The corresponding authorization checks and further functions are
implemented in the standard screen and can be used without a great deal of further programming.
For programming reasons, the screen-oriented display of archived data cannot be used in the Logistics area,
including SD orders and SD invoices. This is due to the fact that data would have to be determined from the
database even if the data objects are only to be displayed. Since subsequent programming of standard
screens to enable the display of archived SD data would involve an unjustifiable amount of resources, a list-
oriented display remains the standard.
When creating a list-oriented business view, you should bear the following in mind:
• Authorization checks
   When using SAP Archiving Information System or when opening archive files, cross-application
   authorizations for ADK are checked. The authorization object is S_ARCHIVE.
• Links to other objects
   Archived documents may also have links to other objects for display, such as scanned documents, work
   items, or Idocs. Being able to access scanned original documents, in particular SD invoices or purchasing
   documents, has proved to be particularly advantageous.
• Mixed display of archived data and online data


© SAP AG                                                                                                               Page 55
Managing SAP Archiving Projects                                                                                     Version 2.0
Access to Archived Data

   When displaying archiving data using the SAP Archive Information System, you may also want to display
   data from the online system. This is usually the case if, in addition to transaction data, you also want to
   display or master data such as customer or material data. The relevant view function module for the
   application calls this data, which is then processed at the business view’s runtime.
6.3.3.3 Process-oriented retrieval
Once you have retrieved an archived document using the SAP Archive Information System, you may realize
that you require further documents that are either also in the archive, or in the online database. To display all
the single documents relevant to the document flow, you require the corresponding document flow data or
business process data. Normally, to access this information, the user would have to obtain the document
information using an explicit search using the SAP Archive Information System.
This procedure is possible in Logistics (MM, SD, PP) on account of its marked object-dependency. although
it requires considerable resources. Therefore, when creating a business view, you should check whether it is
possible to display all data belonging to a document flow in its original business context or whether
navigation between single documents is possible. This is known as process-oriented retrieval. From the
initial document accessed, information, insofar as it is available, is displayed on the preceding and
subsequent documents. Once this information has been determined, it is possible to display these
documents directly. The user does not then have to search the system again using the SAP AS.
Process-oriented retrieval for SD documents (customer orders, delivery documents and invoices; Archiving
objects: SD_VBAK, RV_LIKP, SD_VBRK) has already been developed and can be used as a template.
From Release 4.5A, the SAP Archive Information System has various function models for process-oriented
retrieval. For more information, refer to the SAP Library. This function can be achieved in other ways for
earlier releases. For example, business views for objects SD_VBAK, RV_LIKP and SD_VBRK can be made
available for releases down to and including 3.0D. For more information, refer to SAP Note 140652.
The following graphic illustrates the process-oriented retrieval function in SD:




                         Start document - SAP AS
                         business view sales document


   List of SAP AS
     information                                        SAP AS determines
      structures                                         correct archive for
                                                          object RV_LIKP                                  Cont’d
    (SD_VBAK)
                                                                                                          invoice
                                                                    Access to                             ...
        Double-click
                                                                    archived        Business view
        to access
        data in                                                     data            SD delivery
        archive
                                                                  Archive
                        Double-click on successor                 file
                        “delivery” (RV_LIKP)
      Archive
      file


  Document flow
  in SD                                                                                   Goods
                           Inquiry        Quotation       Order          Delivery                   Invoice
                                                                                          issue

  archived / online




        ã SAP AG 2000


Figure 6-6: Schematic depiction of process-oriented retrieval




Page 56                                                                                                             © SAP AG
Version 2.0                                                                                             Managing SAP Archiving Projects
                                                                                    Special Application-Specific Aspects of Data Archiving




7 Special Application-Specific Aspects of Data Archiving

7.1 Controlling (CO)
COEP is a central CO table. The following describes the significance of this table for CO processes and
outlines the measures that can be taken if it becomes too big, or grows too rapidly. In particular, this section
discusses line items (see below) that can be archived using archiving object CO_ITEM.
The term “CO objects” is often used within the context of controlling and refers to any object that contains
controlling data such as cost centers, internal orders, sales document item (items from customer orders),
cost objects, and production orders.




                                       Master Record (AUFK)                Settlement Rule
            Change
           Documents




                                                                                      Settlement
                                              Long Texts                              Documents

      Status Object

                                                                      Overal
                                                                     Planning

                      Totals Records (e.g. COSP, COSS)
                                                                     Unit Costing




                                                      Unit Costing




              Line Items (COBK and e.g. COEP, CEOJ)




      ã SAP AG 2000


Figure 7-1: Structure of an internal order

The following explanations of the key terms “master record”, “totals records” and “line items” seek to facilitate
a better understanding of data archiving in the CO application.
The master record is stored in various tables, depending on the application. In the case of internal orders,
the relevant master record is stored in the table AUFK; in the case of sales document items, it is stored in the
tables VBAP and VBAK. The information contained in the master data includes, for example, a short text on
the object, organizational data such as controlling area, company code and plant. The object currency is also
commonly stored in the master record, or is derived from information in the master record.
Unlike the master data, the CO totals records and line items are stored in the same tables for all
applications. The totals for primary costs, for example, are always in the table COSP irrespective of whether
they belong to a cost center or a customer order.
Orders, sales document items and cost centers have the attribute “object type”. An object is linked to its CO
data using the general object number (field OBJNR in the CO tables, for example, COEP-OBJNR). From this
field, you can find out information about the object type, and if required, the object key (such as the order
number).
The following list offers an overview of how the size of the table COEP can be reduced. A more detailed
account of each of the steps follows.
• Table analysis using RARCCOA1 and RARCCOA2



© SAP AG                                                                                                                         Page 57
Managing SAP Archiving Projects                                                                             Version 2.0
Special Application-Specific Aspects of Data Archiving

• Data prevention
   -      Line item summary
   -      Deactivate reconciliation objects
• Determine archiving objects
   -      What archiving objects are already used and which archiving objects are scheduled?
   -      What can be archived using CO_ITEM ?
   -      What can be archived using CO_ALLO_ST?
• Closer consideration of CO_ITEM
   -      Obtain optimum program version
   -      Customizing
   -      Performance considerations

7.1.1 Table analysis using RARCCOA1 and RARCCOA2
The programs RARCCOA1 and RARCCOA2 analyze which archiving objects should be used to remove CO
data. The programs count the entries in the CO tables (COEP, COSP, and so on) and assign them to one
specific archiving object. The reports also indicate how much data exists for each object type, controlling
area, and fiscal year.
Proceed as follows:
1. Use transaction SE38 to check whether RARCCOA1 and RARCCOA2 are available in your system. If
   not, import these programs (see SAP Note 13688)
2. Run the report RARCCOA1. Mark at least “COEP” on the selection screen.
   Since this report can take a long time, you are advised to schedule it as a background job. The report
   creates an extract of the data. It does not issue a list. It is difficult to estimate the runtime for the program,
   though experience shows that five hours are required for 80 million COEP entries.
   If you have a test system that is an exact replica of the live system, you should run the report here first.
   Data does not have to be current, although, if possible, it should not be older than two months. It is not
   possible to predict the exact runtime for the live system.
   Note for ORACLE: Run this report when there is minimum posting activity to prevent error ORA-1555.
   Should this error occur, schedule the report again. It usually runs successfully the second time.
3. Evaluate the data using program RARCCOA2 by running the report online. The report reads only the
   dataset created by RARCCOA1 and formats it for display. The runtime is a few seconds.
   You obtain a list in which the (mainly CO) archiving objects are compared with the number of entries in
   these tables. The listed archiving objects represent specific object types (or application).
   This list does not, however, give information about which entries can or should be archived. The system
   is unable to decide, for example, how long data will be required in the system. The following sections in
   this chapter give further indications of how to proceed with the data produced in this step.
   Note on the list
   The list is created using the ABAP List Viewer (ALV). The data in the lines is a summarized form of the
   analysis data created by the report RARCCOA1. By clicking on the totals lines, you can display further
   information. You can also set a filter to restrict the data that is to be analyzed (for example, to select only
   the data that belongs to one archiving object). You can also sort data (for example by fiscal year) or
   change the way in which data is cumulated.
   Which functions are available depends on the release you are using. You can, however, use any release
   to examine the analysis lines more closely. To do this, choose Expand totals.




Page 58                                                                                                     © SAP AG
Version 2.0                                                                              Managing SAP Archiving Projects
                                                                     Special Application-Specific Aspects of Data Archiving

7.1.2 Determining Archiving Objects
The table analysis provides information on which archiving objects can be used to archive COEP entries.
Proceed as follows:
1. Only consider archiving objects that cover the majority of the data. Usually two or three archiving objects
   can deal with 90 percent of the data.
2. It is possible that of the objects now under consideration, one is already (regularly) used. If this is the
   case, you should proceed as follows:
    a. Repeat the table analysis after archiving with this object. Run report RARCCOA1 again.
       Considerably less data should now appear in the RARCCOA2 list for this object.
    b. If the list RARCCOA2 still contains a lot of data for this object, you should try to extend archiving for
       this object by reducing residence times or by extending the selection criteria. You should only do this
       with the agreement of your specialist department.
    c.    If this is not successful, and you not longer require the CO line items for the relevant object type, you
          should indicate the object type for archiving using CO_ITEM.
3. It is possible that you are planning an archiving session for one of the objects that are described in this
   section. If so, should give greater priority to these archiving objects with respect to the dataset in the table
   COEP, since it may be more resource-intensive to use CO_ITEM in addition.
4. If the list also contains an entry for the archiving object CO_COSTCTR, you should also use the archiving
   object CO_ALLO_ST. Proceed as follows:
    a. Run the report RARCCOAA. If possible, run the report in the background, and a time when there is
       minimal posting activity.
    b. The report creates a list of all table entries in COEP and COEJ that belong to completely reversed
       allocation documents. If a significant number of entries are displayed, you should use the archiving
       object CO_ALLO_ST.
       You can use CO_ALLO_ST at any time since the archived documents are, in any case reversed
       controlling documents and therefore can have no further effect.
5. If a significant number of entries still remains in the list for RARCCOA2, or you have marked object types
   for archiving with CO_ITEM (see above), you should use archiving object CO_ITEM.
   Create a list of object types that are to be archived with CO_ITEM. You can base this on the RARCCOA2
   list, and omit all entries that have been dealt with by other archiving objects.

7.1.3 Further Consideration of CO_ITEM
The information in this section is only of interest if you do not already use the archiving object CO_ITEM
regularly.
7.1.3.1 Using the optimum program version
The archiving object CO_ITEM is a standard feature from 4.0. Many parts of this archiving solution have,
however, been available since 3.0D. Further corrections and improvements have also been made that are
useful for releases since 4.0. Depending on the release being used, various transports and Notes must be
installed. The following list was inclusive at the time of this document’s creation. However, you are advised to
check for Notes on CO_ITEM in the SAP Notes system.
Releases 3.0D, 3.0F, 3.1H and 3.1I
1. Install the archiving object CO_ITEM as described in Note 73152. If you have already imported this Note,
   check whether there is a more recent version of the transport. Import the latest version. Read the Note
   completely. It contains the documentation on the archiving object CO_ITEM.
2. Import Note 148273. Essentially, this installs the connection to the new write programs as described in
   the PDF documentation (for more information, see Note 148273).
Release 4.0B, 4.5A and 4.5B
1. Import Note 148273. Essentially, this installs the connection to the new write programs as described in
   the PDF documentation (for more information, see Note 148273).



© SAP AG                                                                                                          Page 59
Managing SAP Archiving Projects                                                                       Version 2.0
Special Application-Specific Aspects of Data Archiving

2. Import Note 158481. The Note can be found in the following Hot Packages: 21 (for 4.0B); 04 (for 4.5B).
3. Import Note 176063. The Note can be found in the following Hot Packages: 29 (for 4.0B) and 10 (for
   4.5B).
4. Apply Note 171965 if there are a large number of entries in table COEPB.
Release 4.6A
1. Import Note 158481.
2. Import Note 176063.
Release 4.6B
At the time of this document’s creation, the latest program versions are standard in 4.6B.
7.1.3.2 Customizing
Before you can begin archiving with CO_ITEM, you must make the relevant settings in Customizing.
Proceed as follows:
1. Contrary to the documentation (for 4.0 and 4.5), you do not need to change the “block sizes for deletion
   program” (ARCU_COIT2). The deletion program now ignores these settings.
2. For the settings on residence times, refer to the documentation on the archiving object CO_ITEM and
   Note 73152. From Release 4.0B, to find the settings in the Implementation Guide (IMG), choose:
   Controlling à General Controlling à Archiving à Prepare Archiving of Controlling Line Items
     a. You may have marked one or several object types for archiving with CO_ITEM (See “Determining
        archiving objects”). Use RARCCOA2 to determine which controlling areas and fiscal years contain a
        significant quantity of data for these object types.
     b. In co-operation with the relevant departments, decide on optimum residence times.
7.1.3.3 Performance considerations
Observe the following to ensure optimum performance of the write program:
• Always run the archiving program for specific object types only. Enter the object type on the selection
  screen.
• If possible, run the archiving program for specific controlling areas.
• Archive as many periods as possible in one session. We recommend that you do not make an entry in
  the To period or To fiscal year fields, so that residence times only are considered. There is no point in
  running several archiving sessions for various “to periods” or similar. The runtime for the write program is
  only minimally affected by restricting periods or the fiscal year.
• Do not run parallel archiving sessions using CO_ITEM. Do not run any CO_ITEM in parallel with other
  archiving objects that occur in the RARCCOA2 list.
7.1.3.4 Splitting the runtime using “Group or set”
If the runtime for the archiving program is too long (for example, because you only have a limited period of
time available), you can use the “Group or set” parameter to make a further restriction. Depending on the
release you are using, you can refer to the following for more information:
• F1 help for the “Group or set” field on the selection screen of the write program
• Documentation on the archiving object CO_ITEM in the SAP Library
• PDF documentation (See Note 148273)
You should have an understanding of the business significance of the various groups (or sets) for each
object type. You are therefore advised to discuss this with the relevant specialist department.

7.2 Archiving in the EDI Environment

7.2.1 Archiving IDocs
The IDoc interface has a standard SAP format for electronic data interchange between systems.


Page 60                                                                                               © SAP AG
Version 2.0                                                                             Managing SAP Archiving Projects
                                                                    Special Application-Specific Aspects of Data Archiving

Different message types (such as delivery documents and orders) usually have various special formats
known as IDoc types. Various content-related message types can be assigned to one IDoc type. For
example, the IDoc type ORDERS01 transfers the “logical” message types ORDERS (orders) and ORDRSP
(order confirmations).
IDocs are used, for example, in the following scenarios.
• ALE: Communication between logical system. Logical systems include R/3, R/2 or an external system.
  ALE distribution models are based on BAPIs and/or message types. The message types refer to the IDoc
  types. When using BAPIs for asynchronous communication, BAPI-ALE interfaces must be generated in
  the form of message types, IDocs and function modules.
• EDI: Communication between R/3 or R/2 or an external system (EDI subsystem).
IDocs are archived using the archiving object IDOC. The archiving program reads IDocs form the database
and writes then to an archive. It offers a range of selection parameters, such as message type and creation
date or last change. It is also possible to assign the status “archived” to an IDoc, although this lowers system
performance. It is also possible to create a log that lists archived IDocs.
To be suitable for archiving, IDocs require a relevant current status. The statuses that are suitable for
archiving are defined in the standard system. This ensures that IDocs with a status requiring further
processing are not archived. If you want to change the archivability of a status, you can use the status
maintenance function in the IDoc interface (transaction WEDI, menu: Control à Status maintenance).
Only the deletion program can delete archived IDocs from the database.
You should ensure that no IDocs are archived that may still be required by the application. This is usually the
case for IDocs with the status 53 - the application document was then successfully posted. IDocs in the
outbox should usually have at least status 03 - this means that they were successfully transferred to the
external system. You can use the IDoc display function (Transaction WE02) to establish the status of an
IDoc.
In the document view, you can determine whether a document originates from an IDoc or not. To do so,
choose System à Services for object à Links. The links themselves are table entries that cannot be
archived. This means that once they are deleted, they cannot be recalled. For more information on deleting
IDoc links, refer to the SAP Library under Basis à Basis Services à The IDoc Interface à Archiving IDocs.

7.2.2 Archiving Work Items
Work items are objects that represent a task or an action in the workflow system at runtime. They are divided
into various work item types according to which the internal processes are controlled. The work item type
determines the permitted status and status transfer. Depending on the work item type, some of these work
items are displayed in the user’s workflow inbox. Other work items, on the other hand, are only used and
processed internally within the system.
Work items are linked to R/3 data objects using the Business Object Repository (BOR).
In releases lower than 4.6, work items that were linked with the data objects were not written to the archive
files and were not deleted from the database. From Release 4.6, linked workflow histories are to be written
to the archive file with the data objects. In Release 4.6C, this will only apply to the archiving object
QM_QMEL (Quality notifications).
The archiving class WORKITEM (archiving object WORKITEM and interface) must be used for the
connection between work item archiving and the archiving of data objects. Unlike archiving objects, certain
restrictions apply to archiving classes (see below).
Work items can be archived and deleted using the archiving object WORKITEM. The system archives all
data that belongs to a work item and that is not strictly runtime data. In particular, the system archives log
data, the data from the Workflow Manager and other work items that are related to the work item, such as
those belonging to a work flow, a subflow, or worklist lines.
The objects in the workflow container are only archived as links. The same applies to items that are attached
to work items. The attachments themselves are not archived because they could be objects that exist
outside the R/3 System, such as Microsoft Word files, and may not be intended for archiving. If archived
work items are subsequently deleted, attachments are also automatically deleted, even those that are not
archived. Archived work items cannot be reloaded into the live system.



© SAP AG                                                                                                         Page 61
Managing SAP Archiving Projects                                                                        Version 2.0
Special Application-Specific Aspects of Data Archiving

Criteria for archiving permissibility (Check logic)
You can only archive work items with the following statuses:
• Completed: The work item was carried out.
• Cancelled: Carrying out the work item is no longer required.
Only work items that are not dependent on top level work items can be archived. This ensures that work
items that are still being processed are not archived. This only applies to the archiving object WORKITEM.
This check logic is not implemented in the archiving class WORKITEM and must be incorporated at the
application level.
Archiving work items
To archive work items, only the general archiving authorizations are required.
Work items are archived using the following reports:
• RSWWARCA
   The following selection criteria are used to select work items for archiving:
   -      Work item ID
   -      Task ID
   -      Actual agent
   -      Creation date
   -      End date
   Selection is only possible using the archiving object. If you use the archiving class, the selection must be
   made in the application.
• RSWWARCD
   This report deletes archived work items from the database. Historical data is also deleted. If you want,
   you can specify that after archiving, the deletion program is to be run in test mode. In Customizing for
   Archiving, you can specify whether the deletion program is to be run at all.
   Further deletion reports
   You can use the report to delete work items directory from the database. The report deletes all the work
   items from the database according to the selection criteria, and irrespective of their status.
   For performance reasons, you should use the report RSWWCIDE for “type C” work items.
   The report RSWWHIDE deletes only historical data.
Display archived work items
You can display archived work items using the following reports:
• RSWWARCR
   This report is to be used only as a template for customer developments.
• RSWWARCP
   This report reads work items from the archive that are based on an object or a task. It can, for example,
   display all work items relating to a specific notification of absence.
There has been a connection to the SAP Archive Information System since Release 4.6A.

7.3 Archiving in a Distributed System Environment
A range of specific considerations need to be addressed when carrying out archiving projects in an
environment with a distributed system. You should not implement such projects before carrying out a
detailed analysis of the planned scenario. In some cases, you may have to change the program logic for the
archiving programs or for the distribution scenarios. In your analysis, you should therefore consider whether




Page 62                                                                                                 © SAP AG
Version 2.0                                                                             Managing SAP Archiving Projects
                                                                    Special Application-Specific Aspects of Data Archiving

it is appropriate to use the archiving programs that you have used previously in the distributed system, or
whether new solutions are required.
When archiving in a distributed system, completeness and consistency must be guaranteed for all archiving
objects. The following outlines a suggested method for ensuring this. Since the networking of live R/3
Systems can vary greatly from case to case, the number of possible distribution scenarios is also enormous.
Consequently, neither the solution presented here nor the ALE examples can cover every eventuality.
Instead, it is intended that they illustrate the range of options available and highlight the factors that should
be considered at the implementation stage. When planning and implementing an archiving solution for your
own distribution scenario, you are advised to seek professional assistance.
A following is a possible solution:
The first step consists of analyzing and presenting the underlying process. Then, all the archiving objects for
the system landscape have to be determined (see Section 8.3.2). These archiving objects must then be
closely examined. The questions listed below can then enable you to determine whether changes are
necessary to the distribution scenario, the archiving object or both.
Your analysis should take the following aspects into consideration:
• What checks are applied to individual archiving objects?
• Can the checks be performed in your system, or must they be carried out in another system within the
  distributed scenario?
• If the checks are to be carried out in another system: Can this be avoided by making a change to the
  check in the archiving object or in the distributed landscape? For performance reasons, it is not advisable
  to carry out an archivability check for data records across system boundaries.
• Does the status determination function, which also determines the archivability of data sets, work
  properly?
• Does the sequence concept for the archiving objects involved (see network graphic in transaction SARA
  also apply without restriction to the distribution scenario?
• Have you ensured that there is a clear and unambiguous assignment in the distribution system? Which
  datasets have the attribute “original”, and which ones “replica”?
• Do datasets that have been stored as replicas still have to kept, or can the archive files be deleted?
• Can the datasets be archived according to object, or do individual segments have to be archived in
  different systems (see graphic).
• Are further distribution-specific tables to be included in the relevant archiving object? Do standard
  archiving objects have to be extended to take account of these tables?
• Are all table contents that are archived by one archiving object in a central system also archived in a
  distributed system?
The following graphic illustrates various possibilities for the distribution of a data object (in this case,
customer master) in a scenario for distributed systems. In variant I, the customer master for archiving exists
twice - once as original, and once as replica. Original and replica are maintained in different systems. In
variant II, the customer master is distributed in segments across both systems. Only the original segments B
(Accounting) and V (Sales) exist. For this reason, archiving must be carried out in segments.




© SAP AG                                                                                                         Page 63
Managing SAP Archiving Projects                                                                       Version 2.0
Special Application-Specific Aspects of Data Archiving




                       System A                                  System B
                                              Communication

                         Customer                                   Customer
    Variant I:             master                                     master
                         (original)                                (replicated)


                                              Customer master
                           Segment A                            Segment A
    Variant II:            (original)                           (replicated)
                           Segment B
                           (original)                           Segment V
                                                                (original)




       ã SAP AG 2000


Figure 7-2: Example showing the distribution of the customer master


7.3.1 Example: A Distribution Scenario Within an Application
The following discusses the ALE standard scenario “Decentralized Warehouse Management System
(WMS)”, which is located entirely within the application SD, as an example of further possible distribution
scenarios.
This scenario is used for setting up a decentralized warehouse management system. In its simplest form, the
scenario uses two R/3 Systems with differing tasks.
• ERP (Enterprise Resource Planning): Deals with tasks other than warehouse management, such as
  processing orders and invoices for sales.
• WMS (Warehouse Management System): Deals with all tasks within warehouse management. This
  includes managing stock and transport, the movement of goods, goods receipt and goods issue.
Both systems exchange data using BAPIs (Business APIs). Business processes usually proceed as follows:
An order is created in the ERP system. This is processed and the data is transferred to a delivery document.
Next, the document is replicated and transferred to the WMS system using a BAPI. The WMS system
processes the delivery including the goods issue posting. Goods issue posting triggers the replication of the
delivery document which is transferred as confirmation using another BAPI back to the ERP system. In the
ERP system. Further processing of the delivery document, such as the creation of an invoice, is then carried
out in the ERP.
The following graphic shows how the these sub-processes are handled by the two systems:




Page 64                                                                                                © SAP AG
Version 2.0                                                                               Managing SAP Archiving Projects
                                                                      Special Application-Specific Aspects of Data Archiving




               System I                           System II

                      Sales order

                                      BAPI
                                                      Inbound /
                       Delivery
                                                  outbound delivery
                                    replication



                                                   Transport order



                                                     Confirm TO
                                      BAPI
                  Goods issue
                                    feedback
                                                     Post goods
               Outgoing invoice                       movement



      ã SAP AG 2000


Figure 7-3: Processes in the ALE-Scenario WMS

Based on the above scenario, you must now check, whether the various SD archiving processes work in this
environment. You should pay particular attention to the following questions?
• Are all relevant table entries belonging to the archiving object also archived in this, new scenario, or must
  the archiving object be enhanced?
• Can all the checks belonging to each archiving object be performed in this scenario also?
• Can the same archiving sequence be maintained in this scenario? If not, how does the sequence have to
  be modified?
In this way, every archiving object is checked for its compatibility with a distributed system. A possible
procedure for the analysis is discussed above.




© SAP AG                                                                                                           Page 65
Managing SAP Archiving Projects                                                                        Version 2.0
Planning and Implementing an Archiving Project




8 Planning and Implementing an Archiving Project

8.1 Introduction
The removal of unnecessary data from the R/3 System is an important administrative task that ensures the
long-term availability of live systems. Large amounts of data accumulate in live R/3 Systems, therefore it is
only a question of time before this data has to be removed. Sooner or later, every employee responsible for
R/3 System administration faces the question of archiving. Consequently, to avoid potential problems,
archiving must be scheduled as soon as possible.
Data archiving should not be seen as the last resort to prevent system collapse after all possible hardware
upgrades have been implemented. Instead, data archiving should be part of the regular maintenance
procedures, such as backup or database reorganization. Even before a system or a process is live, the
cumulative data quantities should be estimated for the future. Conversely, unnecessary problems and costs
arise if archiving is only carried out to resolve performance and administrative bottlenecks.
Two scenarios can be identified:
• Early implementation of the archiving project
• Late implementation of the archiving project
Early implementation of the archiving project
The aim is to keep database volumes to a minimum, at an early stage, by removing unnecessary data from
the database.
In this scenario, the need to archive data is addressed at the “going live” stage of a system or process. The
employee responsible for the application or process knows the business processes and is familiar with the
data objects that are linked with those processes in R/3. In almost all cases, it is possible to estimate the
number of documents and quantity of accompanying data. Together with knowledge of the existing system,
the decision to implement data archiving can therefore be made at an early stage and the necessary steps
implemented, such as setting up a plan for regular archiving.
Late implementation of the archiving project
In this scenario, the aim is to stabilize and reduce database volumes. This situation occurs when
performance or administration problems arise due to large data volumes. If you are already experiencing
system bottlenecks, you will experience the following additional problems when archiving data:
• Longer runtimes for the archiving programs
• Additional system load caused by archiving
Data archiving requires more than just the physical removal of data from the database. Since change access
to business data is removed from the user departments, it is necessary to involve all of the groups involved
in carrying out a joint analysis and creating a requirements catalog.
This chapter presents a 3-phase procedure:
• Analysis
   In the first instance, this involves gathering information on the size and growth rate of database tables. A
   second step involves identifying the archiving objects that are assigned to these tables. Next, the data
   objects are then checked for archivability and to determine what requirements are to be placed on the
   archived data.
• Design
   This involves incorporating the requirements that have been identified during the analysis phase in a
   uniform archiving concept and setting up a concrete archiving plan.
• Implementation and going live
   During this phase, the data objects that are no longer required are removed from the database according
   to the previously created implementation plan.



Page 66                                                                                                 © SAP AG
Version 2.0                                                                           Managing SAP Archiving Projects
                                                                         Planning and Implementing an Archiving Project

   Before the analysis phase can begin, it is important to include the involved groups in a project team and
   to identify their tasks. The following section explains this in more detail.

8.2 Building the Project Team
During data archiving, it is not sufficient just to remove the relevant data objects from the database. It is
much more important to take into account the business environment in which the data objects are embedded
in order to understand the consequences of archiving. As some application objects are used in cross-
application process chains, the persons responsible for individual applications should be involved in the
archiving project.
The following groups are possible participants in archiving projects. (The exact composition of these groups
will vary according to the size and the internal organization of the enterprise and so may differ from what is
listed below.)
• IT department: Database administration, R/3 System administration
• User departments: Controlling, auditing department
• External: External auditing, external service providers, such as consultancies and SAP Remote Archiving
  Service
• Persons responsible for the application (and those from linked components)
The groups responsible for the archiving objects also have various tasks, depending on their role and field of
activity:
Project management
The main task of the project management is to coordinate, monitor, and adhere to the implementation plan.
It is essential to have a clear understanding of the R/3 Data Archiving concept. Further tasks include the
inclusion of archiving in broader archiving concepts, such as optical archiving, and ensuring a uniform and
homogenous archiving solution. For larger enterprises the overall IT-strategy of the enterprise should be
taken into account in order to avoid creating “stand alone” solutions.
IT department
R/3 System administration is usually responsible for database analysis, SAP ArchiveLink Customizing, the
construction and linking of archives, general archiving Customizing as well as configuring the R/3 System
(such as the batch server). A high level of understanding of the R/3 System and of database administration
is required in order to manage these varied tasks.
User departments
From the point of view of the relevant user department, the following questions must be addressed:
• Which data should be archived?
• When should this data be archived (for example, not before a year-end closing)?
• Should this data be accessible later?
• If yes, how often and in what format?
• How should the data be prepared?
• What is an acceptable access time and can it be implemented?
• Is the data still being used by other parts of the organization?
Auditing / Controlling department
The task of the auditing or controlling department is to identify the legal requirements of the archived data
from the legal point of view. Country-specific considerations must also be taken into account.
In this context, this department must also identify any additional requirements for external audits.
Persons responsible for the application
The persons responsible for the application (and from other components) must have a good understanding
of the components and processes. They must also be able to categorize the data to be archived in the



© SAP AG                                                                                                      Page 67
Managing SAP Archiving Projects                                                                         Version 2.0
Planning and Implementing an Archiving Project

context of the whole business. Moreover, they must identify possible dependencies between data objects
(for example, invoice documents cannot be archived until bonuses have been processed). They must also
estimate the quantity structure for archiving and carry out application-specific Customizing.
External service providers (when required)
To play an active or consultative role in an archiving project, an external service provider must have a good
understanding of archiving in R/3. This includes an understanding of:
• The archiving object and its structure
• How the archiving object fits into the overall context of R/3
• Storage systems that are available on the market and how they can be linked to R/3
• Other available archiving objects
Project team
Depending on the size of the organization, the project team should, if possible, include representatives from
all of the departments involved. It is the responsibility of the project team to determine archiving
requirements by assessing:
• Administrative problems
• Performance problems
• Rapid table growth, which can potentially lead to problems
Furthermore, the project team produces a requirements catalog for archived data, provides input on the
archiving concept, and carries out the archiving.
The individual steps of an archiving project are discussed in the following section.

8.3 Analysis
The analysis phase is the most important part of an archiving project. Database size, table growth, and
performance must be analyzed from a technical point of view. Next, it is necessary to identify the archiving
objects that process the relevant tables. Before carrying out this step, you should check whether the data
can be handled more effectively with data prevention methods, such as by deleting unnecessary data (see
Section 2.7). The user department can best identify data that is not required and that is therefore suitable for
archiving.

8.3.1 Database and Performance Analysis
Large data volumes place increased demands on physical storage capacity and on the execution of data
backups. In addition to this, many high availability concepts replicate or mirror data. This requires increased
investment in the hardware environment, and, more importantly, has serious consequences on data backup
concepts since the time required for a backup increases in proportion to the volume of data.
Performance problems may arise during reporting and online activities if, for instance, a full table scan is
executed. With large database tables, indexed accesses must go through large index trees, which can also
impair performance. Data archiving therefore benefits both system administrators and end users.
We cannot provide definitive statements on the ideal time for removing data from the system. Consequently,
the system administrators must identify the criteria enabling them to make a recommendation regarding a
data archiving schedule. Routine tasks include monitoring the database and maintaining the performance of
day-to-day operations. Various powerful monitoring tools are available to the IT department. It is beyond the
scope of this model to provide comprehensive information on issues relating to performance and database
analysis. It is therefore essential that the system administration is familiar with the relevant monitoring tools
and the interpretation of critical statistics. The following provides an overview of the most important tools.
Table sizes can be determined and their previous growth rate displayed by using the database monitor
(transaction DB02). This transaction supplies important database indicators. For the Oracle database
system, this includes the number of available table spaces, and size and growth of individual tables and
indexes. As an example, the following screenshot shows table sizes that have been determined by the
transaction DB02 in a live R/3 installation. The tables are displayed in order of size.



Page 68                                                                                                  © SAP AG
Version 2.0                                                                         Managing SAP Archiving Projects
                                                                       Planning and Implementing an Archiving Project




Figure 8-1: Determining table sizes with DB02

The previous table growth rate can be displayed using the pushbutton History.
In addition to the transaction DB02, you can use the SAPDBA tool and transaction ST03 (performance
monitor), to obtain more information on data archiving.
Archiving data is recommended if the following points apply (assuming that the database and database
server are optimally configured):
•   There are problems with the database administration resulting from excess data.
•   The response time is also critical when access is via an optimal index.
•   The database response time represents the largest part of the response time.
•   The tables are very large.
For more information, refer to the database administration training courses and to the documentation on
SAPDBA.

8.3.2 Identifying the Archiving Objects
After the critical tables have been identified, you must determine which archiving objects are assigned to
these tables. From Release 3.1, a tool is available in the transaction SARA that determines all of the
archiving objects that use a specific table.
The step-by-step procedures and the tools used are different for Releases 3.0, 3.1 and 4.0:
Release 3.0
There is no direct display for Release 3.0. However, you can use the general program for displaying table
contents (transaction SE16). To define the archiving objects, proceed as follows:
1. Enter the table name ARCH_DEF and confirm the entry.




© SAP AG                                                                                                    Page 69
Managing SAP Archiving Projects                                                                         Version 2.0
Planning and Implementing an Archiving Project

2. In the SON field, enter the relevant table. Choose Execute.
   If no table entries are found you can also use the STRUCTURE field, as SON may only be an alias.
   The system displays all the archiving objects that access this table.
Appendix B provides an overview of the tables used by the most important archiving objects.
Release 3.1
From Release 3.1, the table display function is integrated directly into the archiving administration
(transaction SARA) and is available using the pushbutton DB Tables.
To determine the archiving objects for a table proceed as follows:
1. Enter the name of an archiving object and choose ENTER.
2. Choose DB Tables.
   The system opens another window in which the database tables for the archiving object are listed.
3. Choose Find objects.
4. In the dialog box, enter the name of the required table and confirm the selection.
   The system lists the archiving objects that access the relevant tables.


      When you enter the table VBAK (Sales document header data table), the system lists all of the
      archiving objects that use this table.

After you have placed the cursor on a table, you can navigate through the structure using Additional objects
to display additional archiving objects for this table.


      Usually, a single archiving object is assigned to a table. However, in a few cases, for example for
      change documents, CO data or SAPscript texts, the contents of a table are archived by several
      archiving objects.

The following overview shows that the VBAK table is only used by the SD_VBAK archiving object:




Figure 8-2: Displaying database table archiving objects

Release 4.0
From Release 4.0, the DB15 transaction can also be used as an alternative to the DB Tables function. This
function is part of the Computer Center Management System (CCMS) and offers the following features:
• Identifies the archiving objects for a table


Page 70                                                                                                 © SAP AG
Version 2.0                                                                           Managing SAP Archiving Projects
                                                                         Planning and Implementing an Archiving Project

• Displays the tables for an archiving object
• Displays database-specific memory space information, such as
   -    Number of records
   -    Space for the table (in KB)
   -    Additional table details from SAP and database statistics
The following figure shows an example for the VBAK table:




Figure 8-3: Displaying tables and archiving objects in DB15


8.3.3 Requirements of Archived Data
The aim of this phase of the project is to gather the legal, business and technical requirements of the
archived data. Based on these requirements, the data objects that can be archived are then defined in the
design phase.
The primary purpose of data archiving is to reduce database volumes in accordance with business criteria.
Only data from completed business processes, for which only display access is required, should be archived.
Data that is subject to further operational processing must remain in the database, and is not suitable for
archiving. A central question for data archiving is: “How often will access be required to the data that is to be
archived?” If the answer is that the data is going to be accessed often and there are no performance or
administration problems, then you should try to allocate more space to the relevant tables.



© SAP AG                                                                                                      Page 71
Managing SAP Archiving Projects                                                                        Version 2.0
Planning and Implementing an Archiving Project

The requirements of archived data are best recorded in a requirements definition document. There are three
identifiable requirement areas:
• Business requirements: The user departments decide what data can to be archived and what
  access/display options should be implemented, based on the requirements of the business.
• IT technical requirements: This involves converting the contents of the requirements document into a
  usable archiving concept and technical specifications, for example, for implementing acceptable access
  times.
• Auditing requirements: This involves implementing legal requirements such as residence times and
  analysis options.
The following section provides more detail on these areas and gives examples of requirements that must be
applied based on defined criteria.
8.3.3.1 Business requirements
Data objects can generally be archived independently of one another. However, it is important to fit the
individual objects into the business environment and to take into consideration the currently used
components and their processes. The individual steps are explained in more detail in the following section.
Identification of archivable data
From a business point of view, it is essential to clarify which data is to be archived when. Only data objects
belonging to closed business processes can be archived. Therefore, you also have to establish when a
business process is considered closed. The criteria for this depend on the application. In certain
circumstances, certain unique aspects of an organization must be considered, such as different runtimes for
a data object depending on the organizational unit. In this situation, because of the different runtimes, if you
are performing cross-application reporting, you need to know which data has been archived and which data
is still in the system.
Integration of data objects in the business process flow
Due to the high level of integration of the R/3 System and the possible integration of data objects in cross-
component process chains, you should also examine the possible consequences for subsequent processes.
You specifically need to clarify whether there are subsequent processes that access the data objects to be
archived, and whether there are data objects that refer to the data objects to be archived. In certain
circumstances, the archived data can no longer be accessed from other transactions after archiving.
Therefore, the persons responsible for the application should be involved in identifying interaction between
data objects. The dependencies for the most important data objects are shown in the Appendix B.
Defining the retention period
All user departments involved must establish how long the data objects are to be retained in the system. The
retention period depends on the specific nature of the business and on the relevant business process. When
establishing the retention period, you should also pay attention to possible links to other data objects.
Displaying archived data
Read access to archived data is always available. There are two options:
• Read access to individual data objects (direct access). This type of access is possible for each archiving
  object using the SAP Archive Information System (SAP AS).
• Reading the archive file sequentially
However, the display function for archived data is not the same for all archiving objects. A technical display
function exists for all archiving objects and presents the field names and field contents in list form. Some
archiving objects (for example, FI_DOCUMNT) can also present archived data in the original display
transaction. SAP plans to extend this function in future releases, that is, to implement read access in the
original display transaction for the most important archiving objects.
Within the analysis phase, you should clarify with the user departments which data is required in which
display format. These requirements may well exceed the standard display functions. In this case, you can
use the standard display program as a template in order to add your additional requirements. The display
function should therefore also be evaluated in a test archiving session. The following considerations should
be used as a guide:
• Which data should be displayed?


Page 72                                                                                                 © SAP AG
Version 2.0                                                                           Managing SAP Archiving Projects
                                                                         Planning and Implementing an Archiving Project

   You must clarify whether only certain fields are useful or whether all fields belonging to the data object
   must be accessed.
• In which format should the data be displayed?
• Is it necessary to show the process context?
   This may be of interest where several archiving objects are assigned to a common business process.
Access to archived data
Usually there is no need to access archived data from an application because the data is derived from
completed business processes. However, before archiving, you should use a list of the data objects to be
archived to clarify whether and how often individual data objects will need to be accessed. For example, in
the case of a customer complaint or warranty claim, it may be necessary to access certain information in
individual data objects. You should also pay attention to the following points:
• Access times
   Because the data objects are stored in an external media you should expect longer access times than in
   an online operation. Exact times should be established in discussion with the relevant user department.
   The IT department can then decide on the storage media and the storage system according to the
   results.
• Authorization concept
   You should establish who is allowed to access archived data: Is access allowed for every employee who
   worked with these data objects in online operations, or are there restrictions? You should also identify the
   persons responsible for scheduling background jobs.
• Data retrieval
   You should establish whether the available search capability is sufficient or whether specialized retrieval
   tools need to be developed.
8.3.3.2 IT requirements
In addition to business requirements, there are requirements that result from integrating archiving with the
technical environment. We cannot provide general recommendations in this area due to the broad range of
possible technical solutions. However, several criteria are discussed here which may be of use when
reaching decisions on the storage and management of archive files:
• Choice of storage system
   If you plan to implement a storage system, refer also to Chapter 9.
   The choice of storage system depends on the use and the requirements of the archived data, such as the
   access times or the administration time. Furthermore, you should determine whether several R/3
   Systems are in operation and whether the archive files are to be stored and managed centrally.
   Regarding the integration of and access to the archive files in the system landscape, you should check
   whether the data objects are to be accessed by several R/3 Systems.
   If optical archiving is to be implemented as well as data archiving, - to store print lists or scanned
   documents, for example - you should consider a common storage system in order to ensure a consistent
   archiving solution.
• Access times
   The IT department must take the necessary technical steps to ensure the access times required by the
   user department. This includes the choice of storage media as well as the storage system. To implement
   the required access times, it is important to know whether access to the archive files is via a LAN or
   WAN, how often access is required, and the average number of data objects queried.
• Backup concept
   In case the file server fails, there should be a suitable backup concept in place in order to recover
   (restore) the archive files. This should also take into account whether the archive files are copied or
   moved. You are also advised to carry out a backup test on removed backup files in order to check
   whether they can be recovered in an emergency.




© SAP AG                                                                                                      Page 73
Managing SAP Archiving Projects                                                                       Version 2.0
Planning and Implementing an Archiving Project

• Durability of data medium
   As some archive files must be retained for upwards of 20 years, a change of media may be required in
   certain circumstances.
• Internal company rules
   Internal company rules may also have to be taken into account. For example, these may specify which
   data should be stored in centralized or department-specific storage media, or which archiving media is to
   be used for specific purposes.
Chapter 9 provides an overview of storage systems and gives additional background information.
8.3.3.3 Auditing requirements
There are legal requirements regarding the storage of archived data that you should take into account when
designing an archiving concept. These are supposed to ensure that the archived data can still be analyzed,
for example for external auditing or tax auditing.
Due to the country-specific nature of the legal requirements for archived data, only general questions relating
to the design and implementation of an archiving project are addressed here. In order to ensure that the
proper data archiving and retrieval procedures are available, the following considerations should be
addressed in the archiving concept:
• What is the minimum legal retention period for the data to be archived?
• Within what period of notice must the auditing department be able to read the data objects?
• Does the whole data object have to be displayed or only the fields that are relevant to the auditing
  department?
• Are there tools available in the system that are suitable for electronic searches of the archived data?
• Can legible reproductions be created on demand?
• Should it be possible to reconstruct the business process, that is, must the data be clearly applicable to
  the tendering of accounts?
• What access authorizations to archived data are set up?
• Is the archived data protected from manipulation?
Furthermore, the following rules apply for the display of archived data:
• There should be written instructions on the procedure governing the display of archived data.
• The written instructions for the display should include the procedure for checking the completeness and
  correctness of the displayed data.
Data Retention Tool (DART)
The Data Retention Tool (DART) is an add-on component that can also be installed for Releases 3.0D to
3.1I. From Release 4.5A, DART is a standard R/3 function. For information on how to install DART, see SAP
Note 99914.
DART allows you to extract and store data periodically from active R/3 applications, and from archive files
created using the Archive Development Kit (ADK). DART extracts the data into a sequential file that can be
viewed by numerous external tools, such as text editors or spreadsheet programs. DART also provides tools
for viewing the retained data in different ways.
DART was especially developed to meet the auditing requirements of the US tax authorities, but can also be
used for other audits. DART affords the auditor read access to data that must be retained in accordance with
statutory regulations.
For more information on DART, refer to Section 3.4 and the SAP Library.

8.4 Design and Conception
The aim of the design phase is to develop a concrete archiving concept for the removal of data objects from
the database.




Page 74                                                                                                  © SAP AG
Version 2.0                                                                           Managing SAP Archiving Projects
                                                                         Planning and Implementing an Archiving Project

From a data processing point of view, as many documents as possible - such as sales documents, deliveries
and billing documents in SD - should be removed from the database to increase performance and reduce
the administration workload. On the other hand, it is in the interests of the user departments to keep as many
documents as possible available online, to be able to carry out reports, document searches, generation of
lists, and so on. Therefore, the design phase is about finding a compromise between these two positions, or
between the demands of good performance and the online availability of documents. The long-term aim is to
keep the data volume as constant as possible and to archive data proactively.
There are three steps to the design phase:
• Creating an archiving concept
   This step identifies the data objects to be archived. This includes creating a concept that specifies how
   long individual data objects are to be retained in the system. The business, technical and legal
   requirements from the analysis phase need to be appraised and balanced against one another. An
   implementation plan can be initiated after the data objects to be archived have been identified.
• Setting up an implementation plan
   The aim is to set up a project plan for the archiving of data. This includes the setting up of a firm timetable
   and the definition of an activity list.
• Setting up a long-term archiving plan
   A plan should be prepared to archive data objects proactively over an extended period of time with the
   aim of keeping the database under control in the long term. Based on business criteria, a quantity
   structure must be produced that accurately reflects the future development of the expected data volumes.

8.4.1 Creating an Archiving Concept
In this step, you define the length of time that specific data objects are to be retained in the system and how
data archiving can be integrated into a consistent technical and business archiving concept. The
requirements must be harmonized within the scope of a business and technical archiving concept that is
independent of the two scenarios - proactive or reactive archiving.
8.4.1.1 Business concept
Before you can start work on the business data archiving concept, the dependencies and effects of archiving
on other components and processes must be established and documented. A concrete example of possible
dependencies that can arise during archiving in the SD component is presented in detail in section 8.7.
To implement the requirements from the analysis phase, you also have to decide whether you need the
support of external consultants or SAP Remote Archiving Services. SAP Remote Archiving Services
undertakes all activities within the scope of an archiving project such as analysis, Customizing and
implementation of the archiving. These activities are carried out over a remote data link.
The following points should be taken into account when creating an archiving concept:
Enterprise-specific criteria
To identify the relevant data objects, you must first determine which archiving objects are to be used. The
resulting concept should define the retention periods for the individual data objects in the system. This
should take into account the needs of the user departments as well as the requirements of the individual
processes. In certain circumstances, data objects that are assigned to a common business process can
have different residence times, for example, if they belong to different organizational units. Finally, you
create a project charter that specifies which data may be archived.
The next step is to present the logical dependencies between the archiving objects, taking into account the
requirements from the requirements definition document. The dependencies of the most important archiving
objects are documented in Appendix A.
As archived data is not included in the calculation of statistical data, you should also check to see what
effects archiving has on the statistics in the R/3 Information Systems, such as Logistics Information System
(LIS) and Marketing Information System (MKIS).




© SAP AG                                                                                                      Page 75
Managing SAP Archiving Projects                                                                         Version 2.0
Planning and Implementing an Archiving Project

Establishing the archiving sequence
This is important if several archiving objects are assigned to a common business process. An example of
this is the SD component, where, during the archiving of sales documents the following sequence must be
adhered to: Deliveries, billing documents, sales documents. For more information, see Section 8.7.
Accessing archived data
You are advised to create a procedure description for the access of archived data objects, which can be
used by the user departments and also in case of an external audit.
To control access, you should develop an authorization concept. This should define exactly which
employees are allowed to access which data. If you also want to archive print lists, you should ensure that
the relevant authorization object allows all print lists to be displayed.
For the most important archiving objects, suitable read programs are available that offer a user-friendly way
to search by using specific selection parameters. The functions of these tools should be adjusted to meet the
requirements of the end user and should be tested in practice. You can add additional search and display
functions by writing your own programs.
Display programs
To ensure displays for retrieval or reporting that suit the user, you should clearly understand the
requirements of the user departments and the auditing department. The following questions may be of help:
• Is it necessary to support different views?
• Are the standard display functions sufficient or do they have to be extended?
• Is a display of the process context required or is the display of the actual archiving object sufficient?
• What information or attributes from the archived data objects are usually required?
• How is the information flow displayed?
Reloading archived data
Reloading archived data should only be carried out if data has been archived accidentally. However,
reloading should, if possible, take place immediately after archiving to avoid possible database integrity
problems. There are no plans to support reloading in general.
Archiving is not recommended when it is known in advance that the data to be archived will have to be
processed in edit mode again.
8.4.1.2 Technical concept
Work can only start on the technical realization of data archiving when the business concept has been firmly
established. The following points should be considered:
• Implementation of the required access times
   The choice of storage media depends on the access times (see Section 4.2.6).
• Evaluation of the storage system (if one is going to be implemented)
• Integration of other archiving projects, for example optical archiving
• Creation of a technical operating concept including backup, restore and archive management

8.4.2 Setting Up an Implementation Plan
After the archiving concept has been created, you can begin to develop a definite implementation plan. This
includes defining activities and providing a timetable.
The following list contains activities required for setting up an implementation plan. The length of time
required for each activity depends on individual archiving projects. Consequently, no guidelines can be given
in this respect. Similarly, you must decide, for each project, which project team member is going to carry out
which activities.
• Integration and configuration of the storage media
• If the use of a storage system is planned:



Page 76                                                                                                  © SAP AG
Version 2.0                                                                             Managing SAP Archiving Projects
                                                                         Planning and Implementing an Archiving Project

   -    Evaluation of the storage system
   -    Selection of storage media to suit access times and frequency of access
   -    Integration into the system landscape, for instance, using optical archiving.
   For further criteria on the selection of storage systems, see Chapter 9.
• Developing your own programs, such as display programs and search functions, if the standard programs
  are not sufficient
• Testing in the consolidation system and acceptance by the user department
   It should already be clear from the results of test archiving in the analysis phase whether the standard
   functions are insufficient. The authorization concept and the access times should also have been tested.
• Training the project team
• Writing a procedure description for accessing data objects
• Customizing, scheduling transports
• Archiving in the live system
• Carrying out any postprocessing that may be required, such as releasing memory space, updating
  statistics by means of cost-based optimization or database reorganization.

8.4.3 Setting Up a Long-Term Archiving Plan
The archiving of business data is not a one-off activity, but must be executed at regular intervals to keep the
database under long-term control.
A long-term archiving plan establishes exactly which data objects should be archived and when. This
includes scheduling recurring archiving jobs. Before setting up such a plan, you should first estimate the
volume of data in the database. Then you can estimate the future data volume by means of an analysis of
the organization-specific business processes and of the table growth in the database.
The aim of proactive archiving is to implement a long-term archiving plan that keeps data volumes as small
as possible, while taking into account the object-specific residence times. You should therefore also consider
the need for data archiving when new processes or components go live.
Additional points that should be incorporated into a long-term archiving plan:
• Concept for archiving all data objects that have exceeded a defined residence time
• Integration of archiving into the R/3 System landscape
• Concept for the management of archive files
• Concept for the removal of older archive files to tertiary storage media (only where there is a large
  volume of old archive files)
All of the requirements defined in this section should be gathered in a requirements catalog and should be
incorporated into an archiving concept.
In addition to a long term archiving plan, you should record in writing procedures for handling exceptional
cases and problems.

8.5 Implementation and Going Live
The exact procedure for a complete archiving session depends on the archiving object that is being
processed. Here, it is only possible to describe the most common steps. For detailed information, refer to the
SAP Library.
Implementation and going live mainly involves the mapping of the archiving concept in the system. This is
done in the following steps: Implementing archiving based on the scope of activities defined in the concept
phase, making the required technical settings, and starting the system processes. The application
Customizing can either be carried out by the person responsible for the application or by the system
administrator. Before the first archiving of an archiving object, refer to the relevant documentation in
Application help, program documentation, and hints.


© SAP AG                                                                                                      Page 77
Managing SAP Archiving Projects                                                                         Version 2.0
Planning and Implementing an Archiving Project

8.5.1 Configuration and Customizing
If an external storage system is being implemented, it must be configured and integrated into the system
landscape. If a storage system is not being used, the file server must be configured accordingly. You should
ensure that the write, deletion and read programs running on different application servers can access the
archive files.
The configuration also includes executing the transports to the live system, setting up the database server
for archiving (see Section 8.6), and maintaining the variants. Note that the variants are client-specific.
As archiving jobs are scheduled with the lowest priority (“C”), you should make sure that the work processes
being carried out in the background can actually process priority “C” jobs (see SAP Note 62612).
Customizing for Data Archiving can be divided into four areas:
• General Customizing
• Archiving object-specific Customizing
• Application-specific Customizing
• SAP ArchiveLink Customizing
General Customizing
In General Customizing, the (platform-independent) logical filename is defined. Based on this, the physical
file path and file name are generated at runtime. To clarify the assignment of the individual archive files to an
archiving object, you are advised to use “meaningful” filenames - for example, by incorporating the name of
the archiving object into the filename. This is done by defining a parameter in the transaction FILE and is
documented in the SAP Library, in the section on General Customizing.
Archiving Object-Specific Customizing
In archiving object-specific Customizing, the logical filename, the size of the archive file, and the connection
with the storage system are established, and Customizing of the deletion and postprocessing programs (if
using) is carried out. For detailed information, refer to the section on archiving object-specific Customizing in
the SAP Library.
Application-Specific Customizing
In application-specific Customizing, you set the residence time (where possible) in accordance with the
requirements set in the concept phase. For detailed information, refer to the section on application-specific
Customizing in the SAP Library.
SAP ArchiveLink Customizing
ArchiveLink Customizing is only necessary if an external storage system is implemented. It should be carried
out by an experienced system administrator. The storage system vendor can also help with the connection.
The allocation of business object, document type and document class is carried out in ArchiveLink
Customizing. The technical format of a document type, for example, an incoming invoice, is established via
document class, for example FAX, PDF, ALF, DOC. Furthermore, the communication between the server
and the storage system is set up and the programs selected for entering the documents to be stored. For
detailed information, refer to the section on SAP ArchivingLink Customizing options in the SAP Library.

8.5.2 Testing
To test archiving under realistic conditions, you are advised to use as large a volume of data as possible in a
test system. This provides a rough idea of how long archiving will take and which data objects cannot be
archived. Testing can include the following activities:
• Analyzing the system log
• Testing the access times
• Checking the display functions (with the end users)
If the test runs satisfactorily and there is no more Customizing to be done, you can start to transport the
programs, Customizing settings, and so on, into the live system.



Page 78                                                                                                  © SAP AG
Version 2.0                                                                           Managing SAP Archiving Projects
                                                                         Planning and Implementing an Archiving Project

8.5.3 Going Live
Going live consists of three phases:
1. Preparation
2. Execution
3. Postprocessing (if required)
Preparation
Before the first archiving you should check the following parameters and correct them if necessary:
• General Customizing: Logical filename, size of archive file, SAP ArchiveLink
• Application Customizing: Residence times
• Deletion program settings
• Volume of data selected (if necessary, store as variants)
Subsequently, the data objects are activated. This includes the preprocessing program settings, or setting
deletion indicators.


       A preprocessing program is not assigned to every archiving object. Also, a deletion indicator is only
       intended for specific archiving objects.

In a further step, the available memory space can be checked and, if necessary, increased. Finally, the
project team members should be told which data objects are to be archived.
Execution
When archiving, you should adhere to the archiving sequence established in the concept phase. You should
carry out the following activities:
• Scheduling the archiving programs
• Setting the deletion program. There are two options:
   -     Automatically, parallel to the write program
   -     After the write run is finished
• Monitoring the job
• Reading system logs
• Testing read access (once)
After archiving has been completed and you have checked the logs, you can inform the user departments. It
may be beneficial to store notes on the individual archive files. These can be displayed later in archiving
management and provide important information on the stored data objects.
Postprocessing
The postprocessing can include the following activities:
• Reorganizing the database, if required (see Section 5.7)
• Updating the database statistics using a cost-based optimizer (CBO)
• Backing up the archive files
• Checking data objects, that could not be archived
• Scheduling the postprocessing programs (if required)

8.6 Performance and Archiving
You should always schedule archiving jobs to run when user activity is at a minimum. Archiving jobs process
large amounts of data, thereby increasing the load on available resources.


© SAP AG                                                                                                      Page 79
Managing SAP Archiving Projects                                                                          Version 2.0
Planning and Implementing an Archiving Project




      You are advised to install an allocated server with an R/3 instance, that is, configured only for
      background processing. The archive files should be written to a file system that is mounted locally
      on the server, so that data transfer to the archive files does not use the network. The advantage of
      this configuration is that it unburdens the database server as the central resource. A disadvantage is
      that the data to be archived has to be moved from the database server to the application server
      using the network.

If the database server has enough free resources, an R/3 instance with background job processing can be
configured on it. This reduces the network load during the archiving session, however, it increases the load
on the database server.
Before Release 3.0, the write job, which writes the data objects to the archive files, is scheduled
automatically on the database server, if background job processes are configured there. The deletion runs
are scheduled by the background runtime system to run on any available server that is configured for
background job processes.
From Release 4.0, the archiving session can be run on any available R/3 instance that is intended for
background processing.
Usually, two critical factors influence the runtime of an archiving session:
•   Application parameters of the selection program
•   Parameterization of the deletion run
Application parameters of the selection program
Many archiving programs offer optional checks that you can activate in the selection screen of the archiving
session. Each additional check increases the runtime of the write program and therefore also increases the
total runtime of the archiving session. Before executing an archiving session, you should always check
whether the additional checks are necessary.


      Before archiving sales documents in SD, you can activate the optional check Check accounting
      document. The system then checks whether the invoice has been cleared in Accounting (for
      example, by payment).

Parameterization of the deletion run
The performance of deletion programs depends on several factors. In archiving object-specific Customizing,
there are two fields that affect the performance of deletion programs: The field for setting the archive file size
and the field for specifying the commit counter.
In the commit counter, you specify the number of data objects that must be collected before a commit is
triggered in the database. Deletion programs collect the table entries to be deleted and delete these in
blocks, after the number of data objects defined in the commit counter has been reached. This procedure
significantly increases the performance of the deletion programs. However, there is also the hidden risk of a
program termination, if, before the commit, more deletion instructions are sent to the database than the
database can handle in its rollback segments.
Test runs have shown that a 10-line array deletion is approximately three times faster than ten single
deletions. However, the performance gain is only a few percent if larger array deletions are being processed.
The commit counter should therefore not exceed the value of 10.
The performance of an archiving session can be further increased by running deletion runs in parallel
(checkbox “Automatic Start” in Customizing). The parallel execution of the deletion runs can be
parameterized indirectly by the size of the archive files, as a deletion is always scheduled when an archive
file has been closed by the write program.
A deletion program that processes a large archive file requires significantly more time than several deletion
programs that divide up the data to be archived. However, there is a limit to this scalability effect: If too many
deletion programs access the database, the extra load on the database can cancel out any performance
gain.




Page 80                                                                                                   © SAP AG
Version 2.0                                                                           Managing SAP Archiving Projects
                                                                         Planning and Implementing an Archiving Project




      A file size of approximately 100 MB has been shown to be appropriate.

A further time saving can be made by the parallel scheduling of several archiving sessions. However, the
database server should have enough free resources available to support this procedure.
The disk space freed by the deletion of data is not immediately available. For example, in the ORACLE
database system, database blocks, whose maximum level exceeds a specified threshold value, are not
immediately usable for new data records.

8.7 Implementing an Archiving Project: An Example from SD
The primary aim of archiving SD documents is to improve database performance and to reduce the size of
the database. To do this, a compromise must be reached between the IT department and the user
departments.
From the point of view of the IT department, as many documents as possible should be removed from the
database - in this case sales documents, deliveries and billing documents - in order to improve performance
and maintenance (backup, monitoring, and so on). On the other hand, the user departments would like to
have as many documents as possible online, to carry out analyses, document searches, and so on. A
balance has to be struck in the live system between the demands for good performance, user requirements
and document availability.
The figure below shows the main elements in the SD business flow:




              Sales document   Delivery document      Billing document




      ã SAP AG 2000


Figure 8-4: SD business process flow

This flow represents a typical business process in SD. From a sales document, a shipping document is
created. On the basis of the shipping document, a billing document is then created and the flow in SD is
completed. The arrows show the relationships between the single document types. Such a relationship is
called a document flow, from which the following is produced:
• Preceding document
• Subsequent document




© SAP AG                                                                                                      Page 81
Managing SAP Archiving Projects                                                                     Version 2.0
Planning and Implementing an Archiving Project

8.7.1 Analysis
8.7.1.1 Building the project team
The project team responsible for implementing an SD archiving project should include:
• Representatives of the user departments involved - including cross-application components
   These are usually people from sales, shipping, invoicing and accounting. In the course of the project,
   representatives from stock-keeping, purchasing, production, controlling and sales support may become
   involved, as well as people from departments that produce reports and statistics.
• Representatives of the IT department who are responsible for system maintenance and availability, and
  database operations
8.7.1.2 Analyzing the technical and business environment
There are two clearly-definable aspects to preparing such a project: A technical aspect and a business
aspect. The following addresses the most important questions and presents possible solutions.
8.7.1.2.1 Technical aspect
Before you start SD archiving, you should make sure that the technical environment for the archiving objects
used is up-to-date. This includes using the current archiving programs as well as carrying out archiving
object-specific Customizing.
8.7.1.2.2 Business aspect
The main issue here is how long the SD documents (sales documents, shipping documents, billing
documents) should remain in the system after they have been created. This involves choosing the correct
residence time. Residence time refers to the time that a document, once created, is to remain in the system
starting from its creation date before it can be archived.


      A document was created on 01.01.1998. The set residence time is 20 days. The document can
      therefore be archived - if it is complete - from 21.01.1998.

SD_VBAK (Sales documents)
The table V_TVARA is the Customizing table for the archiving object SD_VBAK. As it is possible to make a
distinction between the residence times according to sales organization and/or document type in the
maintenance of the table V_TVARA, some additional fine tuning is required here alongside the optional
checks (Check residence time document flow, Check accounting document, Check purchase order) when
executing SD-sales order archiving. The following questions need to be answered here:
• Are there differences in residence times between sales organizations?
   This may be the case if the sales organizations have different business areas and processes that call for
   different residence times.
• Are there differences in the residence times between document types?
   This may be the case if, for example, rush orders (document type SO) are to spend less time in the
   system than standard orders (document type TA).
• Which optional checks must normally be carried out? Which checks relating to different document types
  must be carried out?
   When setting the residence times, indirect dependencies to other non-SD documents must also be
   checked.



      For make-to-order production, an order is created in the SD component, which then, in the course of
      the business process, creates a production order in PP and is subject to further processing in that
      component. If the SD order is archived (archiving object SD_VBAK), while the production order
      remains in the system, the information cannot be completely displayed because part of the
      information belonging to the SD order has already been deleted from the database.




Page 82                                                                                              © SAP AG
Version 2.0                                                                          Managing SAP Archiving Projects
                                                                        Planning and Implementing an Archiving Project

      Because of this situation, cross-component business processes must be checked to see whether
      information belonging to the SD sales document is required in other components. If this is the case,
      then the SD documents can only be archived after the non-SD documents have been archived. In
      the example presented above, the production order would have to be archived first (archiving object
      PP_ORDER) before the underlying SD order could be archived.

RV_LIKP (Deliveries)
The table V_TVARL is the Customizing table for the archiving object RV_LIKP. A distinction is also possible
here between the residence times according to sales organization and/or document type, so that as well as
activating the optional checks, such as Check residence time document flow or Check accounting
documents, additional settings are also possible. The following questions should be answered here:
• Are there differences in residence times between sales organizations?
   This may be the case if the sales organizations have different business areas and processes that call for
   different residence times.
• Are there differences in the residence times between document types?
   This may be the case if, for example, deliveries without a reference (document type LO) are to be
   retained in the system for a shorter period than normal deliveries (document type LF).
   When setting the residence times, indirect dependencies to other non-SD documents (and non-shipping
   documents) must also be checked.



      Deliveries can only be archived using archiving object RV_LIKP once the accompanying transport
      requests (archiving object SD_VTTK) have already been archived. Therefore, if deliveries with
      corresponding transport requests are to be archived, the residence times for the transports should
      be set as shorter than for the deliveries.

SD_VBRK (Billing documents)
The table V_TVARR is the Customizing table for the archiving object SD_VBRK. Due to the possible
difference in residence times according to sales organization and/or document type, additional settings can
also be made here. The following questions should be addressed:
• Are there differences in residence times between sales organizations?
   This may be the case if the sales organizations have different business areas and processes that call for
   different residence times.
• Are there differences in the residence times between document types?
   This may be the case if, for example, pro forma invoices for sales documents (document type F5) are to
   be retained in the system for a shorter period than normal invoices (document type F2). When setting the
   residence times, you should also check the indirect dependencies to non-SD documents.



      Within the accounting documents, there are links to the corresponding billing documents. In certain
      circumstances, it is necessary for the accounting department to retain billing documents in the
      system for a longer period than the SD business process demands. In extreme cases, billing using
      archiving object SD_VBRK) can only be archived if the accompanying financial accounting
      documents have already been archived using the archiving object FI_DOCUMNT.

In a further step, you need to clarify how long the different documents must be retained in the system. From
the point of view of the user departments, it may be worthwhile removing deliveries from the system after a
relatively short residence time, while for the accounting department, it is essential that the billing documents
remain in the system for as long as possible. As the document residence time is customer-specific and
dependent on many factors, an overview should be prepared that shows what types of business process
there are, and the average time it takes for a business process to be completed. The following is an example
of how such a list might appear :




© SAP AG                                                                                                     Page 83
Managing SAP Archiving Projects                                                                            Version 2.0
Planning and Implementing an Archiving Project


Business            Part of process         Average time    Affected archiving   Affected user
transaction         chain                   before closed   objects              departments


Standard            Order, delivery,        20 days         SD_VBAK, RV_LIKP,    Sales, shipping,
order               transport, billing                      SD_VTTK,             transport, invoice
                    document                                MM_MATBEL,           verification, financial
                                                            SD_VBRK              accounting
Third party         Purchase                30 days         MM_EKKO,             Purchasing, sales,
order               requisition,                            SD_VBAK,             invoice verification,
                    delivery, billing                       SD_VBRK              financial accounting
                    document
Production          Order, production       200 days        SD_VBAK,             Sales, production,
order               order, delivery,                        PP_ORDER,            stockkeeping, invoice
                    billing document                        RV_LIKP,             verification, financial
                                                            MM_MATBEL,           accounting
                                                            SD_VBRK
Transactions        All business            300 days        SD_VBAK, RV_LIKP, Sales, shipping,
in the sales        processes                               SD_VBRK and linked stockkeeping, invoice
organization                                                archiving objects  verification, financial
                                                                               accounting
Business            All business            300 days        SD_VBAK, RV_LIKP, Sales, shipping,
transactions        processes                               SD_VBRK and linked stockkeeping, invoice
with specific       specified by the                        archiving objects  verification, financial
customers           customers                                                  accounting
Table 2: Overview of business transactions

Having prepared such a list, you should have an overview of all business transactions to be processed. You
can then display portions of overall business, including the frequency of archiving. Such a list can show
notes on the possible residence times within application-specific Customizing. The list can also serve as an
extension for the creation of user-exits. On the basis of this list, you can also gather specific requirements
from the user departments, which can provide information on which optional archiving checks need to be
implemented, both in general or in specific circumstances. By analyzing this list, settings can be made in the
application Customizing tables V_TVARA, V_TVARL and V_TVARR.
In a third step, these settings should be monitored in the test system. This is best done by implementing the
relevant preprocessing program for the objects SD_VBAK, RV_LIKP and SD_VBRK. With the results, you
can identify to what extent archiving will reduce the load on the system. You can also see how many
documents must be processed, so that these can be archived. You can run further analyses of the system
load using transaction DB15. This function is available from Release 4.0B.
When the residence times have been established on the basis of the tables listed above and the information
from the user departments, the following questions need to be addressed:
• How can archived data be accessed?
   There are special read programs in SD for the objects SD_VBAK, RV_LIKP and SD_VBRK that can read
   archive files sequentially and present them in list form. Because the individual lists each only contain an
   extract of the archived documents, the read programs must, in certain circumstances, be extended in
   case specific information that is important for the user is not displayed, although the information was
   included in the archiving. Such an extension or conversion should be cleared with the user departments.
   Another way to analyze and present archived data is using the SAP Archive Information System. Note
   that a business view of these documents has to be programmed.
• How often is access to archived data required?
   As a rule, access to archived data should rarely be required. However, if archive access is very frequent,
   you should check whether the residence times have been set correctly.
• Are there legal or technical requirements for the access to archived data and its presentation?



Page 84                                                                                                    © SAP AG
Version 2.0                                                                          Managing SAP Archiving Projects
                                                                        Planning and Implementing an Archiving Project

   There are no direct legal requirements for the SD documents discussed here. However, there may be
   indirect requirements, for example from financial accounting (FI). You should therefore establish whether
   such requirements exist and how they can be fulfilled.
   The user department usually wants as much information as possible to be available. However, you
   should decide which document data is important and which is less important. You should establish
   directly with the user department which data must be displayed and for which data a reduced display is
   sufficient. In this case, a compromise must also be found between the IT department and the user
   department.
• Are there circumstances in which data must be made available in the system again?
   In general, archived data from SD documents should not be reloaded into the system. There are reload
   programs for several archiving objects, however these should only be used in emergencies, for example,
   where too much data has accidentally been archived and deleted from the database. For this reason, it is
   necessary to clarify in advance the reasons for which the user departments need these documents. At
   the same time, solutions should be developed to allow the user departments to access the information
   they need without having to reload the documents.
• Should a specific sequence of archiving objects be taken into account during archiving?
   There may be technical and business dependencies between the various archiving objects, so that a
   specific sequence may have to be adhered to.

8.7.2 Design and Conception
This phase involves integrating the requirements established in the analysis phase within a technical and
business concept. When setting up a technical concept, you should take into account the access times as
well as the integration with other projects, such as optical archiving. Further requirements, such as the
implementation of additional search parameters or organization-specific display functions, can be met by
developing your own programs and testing them with the end users.
8.7.2.1 Establishing the archiving sequence
After the individual SD objects have been examined, you should think about the processing order of the
various archiving objects that are linked, directly or indirectly, to the SD archiving objects. There may be
technical and business dependencies between the various archiving objects, so that a specific sequence
may have to be adhered to. This is illustrated by the following example:


      Third-party orders should be archived with the accompanying billing and relevant financial
      accounting documents. The technical aspect only requires that the accompanying purchase
      requisitions and purchase orders are archived using the archiving object MM_EKKO, before the
      accompanying SD sales documents can be archived.
      The business aspect goes further: Financial accounting needs the sales documents as well as the
      billing documents to be in the system to be able to control possible credit or debit memos better. As
      a possible solution, FI documents are archived using the archiving object FI_DOKUMNT first, then
      the billing documents using SD_VBRK. Only then can the purchase requisitions and purchase
      orders be archived using MM_EKKO. Finally, the third-party orders can be archived using the
      SD_VBAK archiving object.
      For technical and business reasons, such archiving chains can become very long. In an extreme
      case, the archiving chain from the point of view of the sales documents could resemble the following
      example:
      SD_VTTK (Shipments) à RV_LIKP (Deliveries) à FI-Documents (FI_DOCUMNT) à Billing
      Documents (SD_VBRK) à PP_ORDER (Production Orders) à SD_VBAK (Orders)
      As these archiving and process chains are highly customer-specific, you must define, at this stage, a
      sequence concept that reflects your requirements.

8.7.2.2 Establishing a periodic archiving plan
You should specify the archiving frequency in accordance with document growth in day-to-day operations.
From the customer point of view, it may be sufficient to archive SD documents monthly or quarterly.


© SAP AG                                                                                                     Page 85
Managing SAP Archiving Projects                                                                          Version 2.0
Planning and Implementing an Archiving Project

However, if you establish that document growth is very high, it may be necessary to archive every week or
even every day. In this case, you should first monitor the checks and residence times and possibly reset
these to accommodate the situation.
At the start of periodic data archiving, you should regularly check whether the residence times, optional
checks and user-exits are satisfactory for the IT department and the user departments. Correct the settings if
necessary. This may be required, for example, if, despite improved system performance, user departments
find they have to access archived data during every search. You should also correct the settings if, after
archiving successfully, there is no significant performance improvement in document-intensive activities.

8.7.3 Implementation and Going Live
SD documents are archived in accordance with the above solutions. Archiving takes place in two phases:
1. Execution of an initial archiving session
   If no previous archiving of SD documents has yet taken place, you should first execute an “initial”
   archiving session. For more information, see below.
2. Periodic execution of archiving sessions
   This includes the regular archiving of SD documents in business operations. For further information, see
   8.7.2.2.
Before archiving is carried out, you should clarify the following points:
• Has application-specific Customizing been correctly maintained?
• Have the variants (for the affected archiving objects) been set and tested?
• Have the required user-exits been programmed and tested?
• Has the future document growth been estimated and a long-term archiving concept been developed
  accordingly?
• Has a “sequence concept” been agreed on, that establishes the sequence in which the documents from
  SD and the associated components are to be archived?



      If all documents are still in the system and SD documents have never been archived, you should run
      an initial archiving session before proceeding with periodic archiving (see Section 8.7.3.1).

8.7.3.1 Preparation and execution of archiving
The first step of an “initial” archiving is to clarify whether the documents to be archived satisfy archiving
requirements. To do this, the preprocessing program with the detail view for the archiving objects SD_VBAK,
RV_LIKP and SD_VBRK must be run to determine what preparation is still needed.
The following discusses three examples of potential problems and possible solutions:


      Problem: Although no optional checks have been activated, sales documents whose retention time
      has been exceeded are indicated as “not archivable”. The reason “The document is open” is
      displayed in the overview and detail screens. If you look at the document flow, there is no apparent
      reason why this document should not be processed. The log of incomplete items does not give any
      reasons either.
      Solution: First, check the document flow for these documents: The document must have the status
      “completed”. Also, check the status management at header and item levels. If this is also
      unsuccessful, you can run the report SDVBUK00 in test mode. (At present, this report is only
      available for sales documents). Read the SAP Note 67742. This report removes inconsistencies
      between the status management in the database and the dynamic status management, and resets
      the status in the database.
      Note: Sometimes, a mass update of status management for sales documents can lead to
      subsequent problems with message determination, price determination and various order lists. You
      should therefore contact SAP Support before running this report.



Page 86                                                                                                  © SAP AG
Version 2.0                                                                           Managing SAP Archiving Projects
                                                                         Planning and Implementing an Archiving Project




      Problem: Although no optional checks have been activated, sales documents whose residence time
      has been exceeded are indicated as “not archivable”. The reason “Costs are still present in this
      document” appears in the overview and detail screens.
      Solution: No cost distribution was made in CO for these documents: This may be the case if CO
      has never before been used for this type of sales document. You have two options for removing the
      cause of non-archivability:
              • You distribute the costs within CO.
              • You deactivate the checking in CO (useful if you are dealing with a large number of
                 documents).



      Problem: Although no optional checks have been activated, sales documents whose residence time
      has been exceeded are indicated as “not archivable”. Due to the archiving sequence, the deliveries
      and billing documents have already been archived. If you look at the document flow of the checked
      sales document, you see that the order still has the status “open”, although the corresponding
      delivery and billing document already have the status “archived” (see SAP Note 82849). In the
      status management, at header and item levels, the status is correct.
      Solution: Check whether the VBAP-KZTLF field is set to “D” (= possible subsequent delivery) in the
      relevant sales document (view: Item shipping). If this is the case, this sales document can never
      have the status “completed”, as it is used as a pseudo order for the delivery to this special sold-to
      party. Proceed as follows:
              1. Remove the indicator from the sales document (View: Overview/shipping, field VBAP-KZTLF).
              2. Remove the indicator from the customer master (View: Overview/shipping, field partial
                 delivery/position KNVV-KZTLF).
When all of the documents to be archived are archivable, you can begin to schedule the archiving. When
doing this, it is important to check when and how the archiving of SD documents should be executed in the
first phase. You should address the following questions:
• When is time available for the initial archiving?
• Which archiving objects should be scheduled in which order?
• Can the deletion job be executed directly after the write job, or must these actions be kept separate?
• Should the deletion jobs be run in parallel?
These and other questions depend on the technical environment. Consequently, no general answers can be
provided.
If the first phase - the initial archiving - is successful, the next phase is to develop a long-term archiving
concept that is able to keep the database contents at a level that is acceptable to the IT department, while at
the same time supporting the user departments in their day-to-day work.

8.7.4 Sample Archiving Process Flow (Sales Document)
This section uses the example of archiving a sales document (third-party order) to show the process flow. It
also points out possible dependencies between documents. The procedure is as follows:
1. Check the document to be archived using the preprocessing program:




© SAP AG                                                                                                      Page 87
Managing SAP Archiving Projects                                                                     Version 2.0
Planning and Implementing an Archiving Project




Figure 8-5: Archivability check result

2. Using this result, next check the document flow of the sales document to decide which objects must be
   archived first. The flow presentation for the sales document and the accompanying objects is as follows:




Page 88                                                                                             © SAP AG
Version 2.0                                                                        Managing SAP Archiving Projects
                                                                      Planning and Implementing an Archiving Project




Figure 8-6: Display document flow

   Based on these connections, the documents must be archived in the following sequence (archiving object
   in brackets):
   1. Billing documents (SD_VBRK)
   2. Purchase orders (MM_EKKO)
   3. Sales documents (SD_VBAK)
   Pay attention to the following points when archiving sales documents:
   •    Has the Customizing table V_TVARA been correctly maintained?
   •    What is the result of the preprocessing program?
   After running the preprocessing program the result should appear as follows:




© SAP AG                                                                                                   Page 89
Managing SAP Archiving Projects                                                                Version 2.0
Planning and Implementing an Archiving Project




Figure 8-7: Archivability check result

3. You can now archive the sales document using the same settings. The selection screen appears as
   follows:




Page 90                                                                                         © SAP AG
Version 2.0                                                                         Managing SAP Archiving Projects
                                                                       Planning and Implementing an Archiving Project




Figure 8-8: Archive request screen

After running the write program you obtain the following overview. It contains the tables from which the data
is written to the archive during archiving:




© SAP AG                                                                                                    Page 91
Managing SAP Archiving Projects                           Version 2.0
Planning and Implementing an Archiving Project




Figure 8-9: Display tables used for archiving (extract)




Page 92                                                   © SAP AG
Version 2.0                                                                         Managing SAP Archiving Projects
                                                                       Planning and Implementing an Archiving Project

4. Before starting the deletion program, you can check, using the read program, for the archiving object
   SD_VBAK, whether the archive file was written correctly and is readable. The read program lists the
   archived documents as follows:




Figure 8-10: Result of the read program

5. Remove the sales document 451 from the database using the deletion program based on the archiving
   session 2100, by scheduling the deletion run for the object SD_VBAK in the archiving session.

8.8 Conclusion: Archiving Checklist
The following checklist contains an overview of activities that usually have to be carried out during the
planning and implementing of an archiving project. You can use the checklist to see which project steps still
need to be done. The checklist is divided into three project phases: Analysis, design and conception,
implementation and going live.
Analysis
r Building the project team
r Defining the archiving objects
r Identifying dependencies
r Defining the residence time
r Identifying the archivable data objects
r Specifying the display function, including access times and retrieval requirements
r Specifying the authorization concept
r Analyzing database and tables
r Estimating the expected data volumes
Design and conception
r Specifying the archiving sequence
r Evaluating storage media
r Customer-specific development: Programming, testing


© SAP AG                                                                                                    Page 93
Managing SAP Archiving Projects                                                                         Version 2.0
Planning and Implementing an Archiving Project

r Creating an operational concept for archive file management
Implementation and going live
r Customizing
   -      Logical filename and path (transaction FILE)
   -      SAP ArchiveLink Customizing (if a storage system is implemented using the ArchiveLink interface)
   -      Application-specific Customizing, such as setting the residence time (not necessary for all archiving
          objects)
   -      Archiving object-specific Customizing (transaction SARA)
r If implementing a storage system: Implementation, configuration, administration
r Pilot phase: Testing under realistic conditions
r Creating a procedure description for
   -      Accessing archived data objects
   -      Implementing reporting
   -      Searching for / analysis of archived data
r Training end-users
r Executing archiving (job control)
r Postprocessing after each archiving session (check to see whether reorganization is necessary, update
  statistics, backup archive files)




Page 94                                                                                                  © SAP AG
Version 2.0                                                                                                     Managing SAP Archiving Projects
                                                                                                         Tertiary Storage Media for Data Archiving




9 Tertiary Storage Media for Data Archiving
This chapter deals with the storage of data objects at the technical level, which – with the exception of the
ArchiveLink interface – is always implemented by other software and hardware vendors. The following is
intended to enable the persons responsible for IT to decide on the optimum technical storage solution.
The storage and management of archive files is independent of the archiving functions contained in the R/3
System, that is, the end-user can choose any storage medium currently on sale. There are only SAP-certi-
fied providers for systems that use the SAP ArchiveLink interface. There are three main storage concepts:
• SAP ArchiveLink interface (certified) plus storage system
• File system plus HSM (Hierarchical Storage Management System)
• File system plus standard backup tools
The individual solutions are explained in more detail in the following sections.

9.1 Storage Using SAP ArchiveLink
Since Release 3.0, Data Archiving (ADK) supports the SAP ArchiveLink interface (see following graphic), so
that archive files can be transferred from the file system to a storage system from which the files can also be
retrieved. For detailed information on the features of this interface, refer to Chapters 4 and 5.
SAP ArchiveLink is an optional storage for archive files created by SAP Data Archiving. By implementing
SAP ArchiveLink and ADK, it is possible to monitor the progress and storage of archive files on external
storage media. Since Release 4.0, there has been a direct, sequential read function for archive files. This
means that data can be displayed without being returned to the file system.
When storing archive files using SAP ArchiveLink, you must back up the archive files in the file system. This
means that it should be technically impossible to delete the archive files from the file system until they have
been stored in the storage system. Alternatively, once archive files have been created in the file system, they
can be stored manually. You can then schedule the deletion run on the basis of the stored archive files.
From Release 4.6C, you can make these settings in Customizing directly. The following graphic shows the
archiving process using SAP ArchiveLink:




     R/3 System                                                                SAP ArchiveLink RFC-Server
      Application
        tables                                            6
                                                   “Archiving sucessful”
              Delete table                                                              RFC message:
     2          entries                                                                 “Archiving ...
                                                                                 6       successful”
      ADK                      Create an open request
                       3                                                                          5
                                                           Asynchronous requests
                                 RFC request:
                                “Store files ...
         1                     asynchronously”

              Write archive files

                                                                      Storage server      Storage system
                                                                        RFC server
                                                      4
                                                                           4
                             Store archive file in storage system



      ã SAP AG 2000


Figure 9-1: Data storage using SAP ArchiveLink



© SAP AG                                                                                                                                 Page 95
Managing SAP Archiving Projects                                                                         Version 2.0
Tertiary Storage Media for Data Archiving

When archiving using SAP ArchiveLink, the ADK first writes the archive files to a file system. This file system
must be mounted on all application servers on which the write and deletion programs are running in the
background. Where SAP ArchiveLink is being used, the mount directory must, at the same time, act as the
exchange directory for the storage system.
In order to avoid increasing the network load, the archiving program is carried out with priority on the
database server. The archive files can only be stored and deleted by the external software if the ADK has
successfully read the archive file and deleted it from the database. At present, it is not possible to reschedule
the database deletion phase to run after the storage of the archive files by the external software. An
enhancement of the SAP ArchiveLink interface is planned for this purpose.
During archiving, the SAP ArchiveLink interface (here archive files are a special document class) ensures
the transfer of the metadata between the ADK and the storage system. The actual data is found in the
archive files that are read directly from the storage system. The actual storage of the archive files by the
external software takes place in a tertiary storage medium. The choice of storage medium depends mainly
on future data access requirements, and also on legal requirements regarding length of storage time and the
durability of the medium. The following table provides an overview of the characteristics of the various
media:

Storage medium                  Read rate Search/positioning       Durability
Magneto-optical (MO)            +           –                      ++
Hard disk                       ++          +                      –
Magnetic tape                   +           ––                     +
Table 3: Characteristics of tertiary storage media

Tape is only suitable for large amounts of data and is not suitable for single document access due to the
medium’s poor search facilities.
Individual storage system solutions manage the archive files in a separate database (such as ORACLE, MS
SQL-Server). This database is not stored in the archive - it must be integrated in the overall backup concept,
in the same way as the SAP Software backup or the SAP Database backup. In the case of a total loss of the
management database, some providers offer a facility to reconstruct the management data (such as an
index) by importing the current data. This procedure is very slow for large data volumes and therefore
(according to some of the storage system vendors themselves) not acceptable.
A storage system solution, in which the management data is backed up by the archive solution itself, would
be advantageous, but we do not know of any such solutions yet available. In comparison, the SAP Backup
programs for the R/3 Database (such as BRBACKUP, BRARCHIVE), back up their metadata together with
the actual data content.
In addition to pure storage system providers, there are also providers that support the connection of their
own storage systems using the SAP ArchiveLink interface to R/3 as well as the interfaces to database
backup products (Oracle SBT, Informix XBSA, SAP Oracle BACKINT to BRBACKUP, BRARCHIVE).
From Release 4.5A, it is possible to access individual data objects directly using the Byte Stream interface,
without having to copy the archive file back to the local file system.
Advantages:
• Scalable system
• Worldwide access to centrally stored archive files and business documents
• Support for the data carrier management
• Universal usability
• Automatic transfer of archive files to the storage system and monitoring by the ADK
Disadvantages:
• Administration of storage system
• Longer access times compared with a hard disk




Page 96                                                                                                 © SAP AG
Version 2.0                                                                            Managing SAP Archiving Projects
                                                                                Tertiary Storage Media for Data Archiving

There are various producers who offer archiving software and who have also implemented a connection to
the R/3 System using the ArchiveLink interface. A list of official SAP-certified solutions is available in the
Service Marketplace under http://service.sap.com/csp. There, follow the link „CSP Directory“, then choose
Search Options à by Software Category, and enter the search term “Archiving, Imaging Software”.

9.2 Storage in an HSM System
An HSM system is a file system implementation which, according to different strategies, moves files
automatically from fast but expensive storage media (such as hard disks) to slower, cheaper storage media
(for example tapes), and reverses this process where necessary. In the HSM context, this process is called
file migration. HSM stands for Hierarchical Storage Management, because usually a hierarchy of storage
levels is used (hard disks à magneto-optical movable disks in jukeboxes à tapes in tape libraries). The
HSM solution is a purely technical solution (see Chapters 2 and 5), which from the application point of view
represents a transparent “infinitely” large file system. Tertiary storage media are also used here as final
storage, although this layer is transparently decoupled.
The greatest advantage of such systems for the user, is that the files can still be addressed by the same
name after they have been stored in such a file system. Although the file may have been stored on tape long
ago, (for example, because it has not been accessed for a long time), the file retains its name so that access
is possible at any time (the delay caused by the reloading from tape is, in such cases, negligible).
Consequently, from the user's point of view, the data is stored transparently in an HSM system, which
means that you cannot see which data carrier contains the data. Only the delay in access shows that the file
is being fetched from a slower data carrier.
An additional, important aspect of implementing such a system is that data backup is no longer required.
Because of the very large data volumes that HSM systems can manage (more than 1 TB), conventional data
backup procedures cannot be used anyway. However, there is still the problem of backing up the metadata.
For this, the various HSM systems offer their own solutions, or implement conventional data backup
procedures.
As in standard archiving, the archiving session writes the archive files to a file system, only with the
difference that here, the file system is an HSM system. A physical disk represents an infinite buffer, that
prepares the “new” files for online-access as well as preparing the catalog for external access. The following
figure shows an overview of the processes:




                         Adjust codepage, number format, and structure
                  ADK:   changes; compression, file handling, batch I/F ...

                      Appl. REPORT: Runs on SAP batch server

                                                                          HSM


                                     Archive files




                      Disk Cache
                                                Store &
                                                retrieve




      ã SAP AG 2000


Figure 9-1: Storing archive files in an HSM system




© SAP AG                                                                                                        Page 97
Managing SAP Archiving Projects                                                                          Version 2.0
Tertiary Storage Media for Data Archiving

Requirements of an HSM system and factors influencing the choice of storage system
In the interests of protecting your investment, your HSM hardware (robotic system) should offer the following:
• Integration of different data carriers
• Use of different types of drive (media) in the same robotic system
• System extendibility to allow for additional drives and data carriers
• Fast access to the data carrier
• Exchange of data carriers using a separate storage system
Your HSM software should offer the following:
• Supported by different hardware (drives, robotic system)
• Available for different system platforms
• Integration of present file system with file servers in migration procedure
• Separate memory management system with local cache and several interfaces (particularly NFS or UFS)
• Automatic and user driven migration (if possible with GUI)
Because the final storage medium is also a tertiary storage medium (MO, tape), the storage policy of the
HSM system should be correctly configured in order to avoid long access times when accessing the tertiary
storage medium. The HSM system index must also be backed up separately.
• Support of volume groups to assign special data carriers to a directory
• Integrated database backup
Further points that should be addressed when selecting an external storage system:
• The removal of files from the buffer follows certain rules. These should be checked on each removal. For
  memories containing a lot of small files this can lead to long waiting times.
• The memory capacity on the hard disk is finite, as the amount of management sizes is limited in a similar
  way to the INODE limits in a UNIX file system.
• Possible side effects due to the attached terminals (for example MO library, tape library)
• Unit size that is used in the file system cache when reloading from tapes/CD's (blocks or whole files).
• Read-ahead mechanisms
An HSM system solution offers the following advantages and disadvantages:
Advantages:
• Access time under 30 seconds for block access
• Fast analysis (reporting) for block access
• Scalable file system
• Support for archive file management and data carrier management
Disadvantages:
• High purchase costs
• No connection as yet possible using the ArchiveLink interface

9.3 Storage in a Local File System
The storage of archive files in a local file system offers the following advantages and disadvantages:
Advantages:
• Access time for direct access to an archive file is less than 5 seconds
• Fast reporting




Page 98                                                                                                  © SAP AG
Version 2.0                                                                                 Managing SAP Archiving Projects
                                                                                     Tertiary Storage Media for Data Archiving

Disadvantages
• High maintenance and management workload for the data carrier
• Data backup concept required
• Migration strategy for archive files required
• High manual management workload (mirroring of archive files, data backup, in some cases removal and
  reimporting)
For the reasons listed above, the storage of archive files in a local file system is only recommended if the
data objects are going to be accessed relatively frequently and if access time is critical (ideally less than 5
seconds).

9.4 Evaluation of Procedures and Technologies
Hard disk technology is changing rapidly. By using redundant architectures and procedures (such as
Integrated Disc Cached Array from EMC), you further reduce the risk of losing data. If you also consider that
the cost of hard disk storage is falling constantly, an HSM solution represents a good choice.
Pure storage system vendors use the classic MO media, which have good physical characteristics and do
not need to buffer the data on hard disks. This purely technical view is however not enough to draw
comparisons.
In order to evaluate the procedures better, the following evaluates various solutions and their access
statistics.
Even before Release 4.0, archive files could be stored using the SAP ArchiveLink interface, although there
was no direct sequential read capability, so that the data had to be reloaded first – whilst still in the file –
back into the file system. For reading archives, this was a distinct disadvantage over an HSM system. The
access times were significantly worse due to this procedure (see the following graphic).




              600
                                                                   Hard disk
              540
              480
              420                                                  HSM with "random
                                                                   access"
              360
      Time in
              300
      seconds                                                      Jukebox via
              240                                                  SAP ArchiveLink
              180
              120                                                  HSM w/o "random
               60                                                  access"

                0
                        10 MB         50 MB            100 MB
                                Size of archive file



      ã SAP AG 2000


Figure 9-2: Access times for various stored single documents

With several HSM systems, it is possible to reload individual blocks from the tertiary storage into the file
system cache and simultaneously carry out read access on them (using Read-Ahead), before the file or a
larger number of blocks has been read. This solution is almost as fast as access to a local hard disk.




© SAP AG                                                                                                             Page 99
Managing SAP Archiving Projects                                                                          Version 2.0
Tertiary Storage Media for Data Archiving

All storage systems allow you to reload individual blocks requested (by Offset and Length) by ADK.
(ArchiveLink random access = Single document display). This solution is as fast as an HSM solution in which
the whole file is recalled into the file system cache. It is available from Release 3.1G.
Up to Release 3.1, during a data access using SAP ArchiveLink the whole archive file is reloaded into the file
system. The time required depends on the file size. Therefore, it is important to set the correct file sizes in
ADK Customizing.
From Release 4.0, it is also possible to read data sequentially over the SAP ArchiveLink interface (see
Chapter 2), without reloading the archive file back into the file system. This solves the problem described
above when reloading whole files. The above figure does not consider the differences, if the data is really
removed to the end medium, but rather it shows here the solution as combination of buffer (Cache) and end
medium.
In the case of read access to single documents, it takes longer to find the correct place in the archive file that
it does to reload the archive file back into the system. For large jukeboxes, as used by HSM systems, the
system index must be up-to-data to ensure reasonable access times.
When you are assessing an archiving solution from the technical point of view, consider the following:
• On which media should the data be archived (taking into account lifetime and accessibility)?
• When, how (single document access or sequential access) and how fast should the data be accessed
  again?
• Is a removal strategy (possibly multi-tier) necessary?
• Is the software support from the storage system vendor sufficient?
• How good are the index accesses and the monitoring of the storage system?
These questions should be clarified in cooperation with the relevant user departments, as the best removal
and access strategy is highly dependent on business factors. Chapters 2 and 5 explain these aspects in
more detail.
The following settings for archive files, amongst others, can be made in the technical and application-specific
Customizing for the ADK:
• Establishing and monitoring file size
• Establishing the storage location (directory)
These sizes should be defined according to the storage system configuration and take the application
requirements (such as frequency of access, type of access) into account.
In summary, optimum archiving is dependent on a large number of application factors. Since the range of
storage systems available on the market is changing constantly, the choice must be left to users themselves.




Page 100                                                                                                 © SAP AG
Version 2.0                                                                             Managing SAP Archiving Projects
                                                                                                              Appendix




Appendix

A. Tables with Rapid Growth Rates
The following lists tables that are prone to excessive growth. Where relevant, the archiving objects that
archive the contents of these tables are also shown. This list may not be exhaustive, since your SAP
Systems may contain further tables that are prone to rapid growth. Before archiving, you should check which
tables are affected. To determine the relevant tables, you can use the appropriate tools. See section 8.3.
The SAP Notes mentioned for some tables offer information on data prevention, data summarization, data
archiving and reorganization. These Notes reflect the current status at the time of this document’s
publication. You should always check the latest SAP Notes.
Several database tables are not archived directly using an archiving object, but use instead an archiving
class or subclass that is, in turn, linked to specific archiving object. For details of this assignment, refer to
tables Table 5 and Table 6.

 Table           Archiving Object           Description                                      Remarks
                 MM_ACCTIT                  MM- Accounting interface posting data
 ACCTIT,                                                                                     SAP Notes: 178476,
 ACCTHD,                                                                                     48009
 ACCTCR
 AUSP            CO_ORDER                   Orders with transaction data
                 FI_ACCPAYB                 Vendor master data
                 FI_ACCRECV                 Customer master data
                 MM_ASMD                    Service master
                 MM_MATNR                   LO: Material master records
                 MM_SPSTOCK                 LO: Batches and special stock
                 PI_PLAN                    Master recipes
                 PM_EQUI                    Equipment master data
                 PM_IFLOT                   Functional location master data
                 PM_ORDER                   PM/SM orders
                 PM_PLAN                    PM routings
                 PM_QMEL                    PM messages
                 PP_ORDER                   Production orders
                 PP_PLAN                    Work plans
                 PP_WKC                     Work centers
                 PR_ORDER                   Process orders
                 PS_PLAN                    Standard networks
                 PS_PROJECT                 Project system: Operative structures
                 QM_PLAN                    Inspection plans
                 QM_QMEL                    Quality notifications
                 SD_VBAK                    Sales documents
                 SM_QMEL                    Service notifications
                 WS_ACSITE                  Retail: Site master records
 BALHDR,                                    Application log: (log header / message)          SAP Notes: 91519,
 BALM                                                                                        117191
                                                                                             Reorganization
                                                                                             program:
                                                                                             SBAL_DELETE




© SAP AG                                                                                                     Page 101
Managing SAP Archiving Projects                                                          Version 2.0
Appendix

 CDCLS,           CHANGEDOCU      Change documents (cluster structure /     Archiving is performed
 CDHDR,                           header / items)                           by archiving class
 CDPOS                                                                      CHANGEDOCU. As of
                                                                            Release 4.5, there is
                                                                            also the archiving
                                                                            object CHANGEDOCU
                                                                            available for this task.
                                                                            SAP Notes: 140255,
                                                                            141243
 DBTABPRT                         Table of log records for table tupel      SAP Note: 129028
                                  changes
 EBAN             MM_EBAN         Purchase requisitions
                  PM_ORDER        PM/SM orders
                  PP_ORDER        Production orders
                  PR_ORDER        Process orders
                  PS_PROJECT      Project system: Operative structures
 EKBE             MM_EKKO         Purchasing documents
 EKBZ             MM_EKKO         Purchasing documents
 EKKO             MM_EKKO         Purchasing documents
 EKPO             MM_EKKO         Purchasing documents
 JCDS,            CO_ORDER        Orders with transactions
 JSTO,            CO_PROCESS      Business process, including transaction
 JEST                             data
                  PM_EQUI         Equipment master data
                  PM_IFLOT        Functional location master data
                  PM_MPLAN        PM maintenance plans
                  PM_ORDER        PM/SM orders
                  PM_QMEL         PM messages
                  PP_ORDER        Production orders
                  PR_ORDER        Process orders
                  PS_PROJECT      Project system: Operative structures
                  QM_CONTROL      Q check transaction data
                  QM_QMEL         Quality notifications
                  RE_BUILDNG      IS-RE Real estate: Buildings
                  RE_BUSN_EN      IS-RE Real estate: Economic units
                  RE_MGT_CNT      IS-RE Real estate: Management contracts
                  RE_PROPRTY      IS-RE Real estate: Land
                  RE_RNTL_AG      IS-RE Real estate: Rental contracts
                  RE_RNTL_UN      IS-RE Real estate: Rental units
                  RE_STLM_UN      IS-RE Real estate: Billing units
                  SD_VBAK         Sales documents
                  SM_QMEL         Service notifications
 LIPS             RV_LIKP         Deliveries
 MSEG             MM_MATBEL       Materials Management: Material
                                  documents
                  PP_BKFLUSH      Document log
 NAST             MM_EKKO         Purchasing documents
                  MM_MATBEL       Materials Management: Material
                                  documents
                  MM_REBEL        Materials Management: Billing documents
                  RV_LIKP         Deliveries
                  SD_VBAK         Sales documents
                  SD_VBKA         Sales activities
                  SD_VBRK         Billing documents
                  SD_VTTK         SD transports
 RESB             MM_EBAN         Purchase requisitions
                  MM_EKKO         Purchasing documents



Page 102                                                                                  © SAP AG
Version 2.0                                                                  Managing SAP Archiving Projects
                                                                                                   Appendix

               PP_ORDER               Productions orders
 RFBLG         FI_DOCUMNT             Financial accounting documents
 STXH,                                STXD SAPscript Text File (header / lines)   Archiving is performed
 STXL                                                                             by archiving class
                                                                                  TEXT.
 S***          MC_SELVS               LIS: Stored selection versions              Objects and programs
                                                                                  are generated at
                                                                                  runtime (transaction
                                                                                  MCSX).
 VAPMA         RV_LIKP                Deliveries
               SD_VBAK                Sales documents
               SD_VBRK                Billing documents
 VBAP          SD_VBAK                Sales documents
 VBEP          SD_VBAK                Sales documents
 VBFCL         RV_LIKP                Deliveries
               SD_VBAK                Sales documents
               SD_VBKA                Sales activities
               SD_VBRK                Billing documents
 VBKD          SD_VBAK                Sales documents
 VBPA          RV_LIKP                Deliveries
               SD_VBAK                Sales documents
               SD_VBKA                Sales activities
               SD_VBRK                Billing documents
 VBRP          SD_VBRK                Billing documents
 VBUK          RV_LIKP                Deliveries
               SD_VBAK                Sales documents
               SD_VBKA                Sales activities
               SD_VBRK                Billing documents
 VBUP          RV_LIKP                Deliveries
               SD_VBAK                Sales documents
 VEPO          RV_LIKP                Deliveries
               SD_VTTK                SD transports
 VRKPA         RV_LIKP                Deliveries
               SD_VBAK                Sales documents
               SD_VBRK                Billing documents
 VRPMA         RV_LIKP                Deliveries
               SD_VBAK                Sales documents
               SD_VBRK                Billing documents
Table 4: Tables with rapid growth rates and their archiving objects
 Archiving class   Assigned archiving
                   classes
 K_TOTAL           K_COER
                   K_COSTS
                   K_FIDAT
                   K_INTRATE
                   K_KABP
                   K_KABR
                   K_PRICES
                   K_QUANT
                   K_RATIOS
                   K_RPSCO
                   K_SRULE
                   K_VARI
                   STATUS
Table 5: Archiving classes assigned to K_TOTAL



© SAP AG                                                                                          Page 103
Managing SAP Archiving Projects                                                                       Version 2.0
Appendix

 Tables                  Archiving object
 BPBK                    RE_MGT_CNT
 BPEG                    RE_PROPRTY
 BPEJ                    CO_PROCESS
 BPEP                    RE_BUILDNG
 BPEG                    RE_BUSN_EN
 BPJA                    RE_RNTL_AG
 BPTR                    RE_RNTL_UN
 CKHS                    RE_STLM_UN
 CKIS                    SD_VBAK
 CKIT                    COPA2_C001
 CMFK                    COPA2_LEI1
 CMFP                    COPA2_LEI2
 COBRB                   COPA2_LEI3
 COEJL                   COPA2_S001
 COEJR                   COPA2_S_02
 COEJT                   COPA2_T001
 COEP                    COPA2_X001
 COEPL                   CO_KABR
 COKA                    CO_KSTRG
 COKL                    CO_ORDER
 COKP                    PM_EQUI
 COKS                    PM_IFLOT
 COOI                    PM_MPLAN
 COSB                    PM_QMEL
 COSL                    QM_CONTROL
 COSP                    QM_QMEL
 COSR                    RE_BUILDNG
 COST                    RE_BUSN_EN
 KEKO                    RE_MGT_CNT
 KEPH                    RE_PROPRTY
 KSSK                    RE_RNTL_AG
                         RE_RNTL_UN
                         RE_STLM_UN
                         SM_QMEL
Table 6: Tables assigned using archiving class K_TOTAL
         or its subclasses

The tables on the left are archived by means of the archiving objects on the right.
It is not possible to depict the exact assignment of tables to archiving objects, since these tables are also
archived using archiving class K_TOTAL and its subclasses. If required, an note of precise assignments can
be obtained directly from SAP by creating an Online Service System message.

B. Information on Selected Archiving Objects
The following contains additional detailed information on the archiving objects with the greatest table growth.
The archiving objects are listed according to application components.

        Archiving object          Description                          R/3 component
 1.     CO_ITEM                   CO Line Items                        CO
 2.     COPA1_*                   COPA Accrued                         CO
 3.     FI_DOCUMNT                FI Accounting Documents              FI
 4.     FI_GLF_IT                 Flexible general ledger line items   FI
 5.     FI_SL_DATA                Summary line items FI-SL             FI




Page 104                                                                                               © SAP AG
Version 2.0                                                                           Managing SAP Archiving Projects
                                                                                                            Appendix


 6.       MM_ACCTIT                 Document data FI/CO Interface        FI
 7.       MC_SELVS/                 LIS Selection Versions               LO
          MC_Snnn
 8.       MM_EBAN                   Purchase Requisitions                MM
 9.       MM_EKKO                   Purchasing Documents                 MM
 10.      MM_MATBEL                 Material Documents                   MM
 11.      MM_REBEL                  MM Invoice Documents                 MM
 12.      PCA_OBJECT                Totals/Items EC-PCA                  EC
 13.      PP_ORDER                  Production Orders                    PP
 14.      RV_LIKP                   Deliveries                           SD
 15.      SD_VBAK                   Sales Documents                      SD
 16.      SD_VBRK                   Billing Documents                    SD
Table 7: Overview of the most important archiving objects


Controlling (CO)

CO_ITEM
1. Which programs are available?
      Write program: RKCOITWR
      Deletion program: RKCOITDL
2. How are the display functions implemented?
      A preliminary transport is available for sequential reading, see SAP Note 73152. The following read
      programs are available:
      -   RKCOITS4
      -   RKCOITS1
      -   RKCOITS2
      In Release 4.0, and higher, it is possible to run line item reports based on archived CO data.
3. Which Customizing functions are available?
      Customizing for residence time: Transaction SM30, table ARCU_COIT1
      Customizing for block size: Transaction SM30, table ARCU_COIT2
      Note that it is not mandatory to maintain table ARCU_COIT2. You can still archive data using CO_ITEM
      without maintaining this table.
      In Release 4.0 and higher, you can also customize CO archiving in the IMG:
      Controlling à Controlling General à Archiving à Archiving in CO
4. Are there dependencies or established sequences for archiving?
      Using CO_ITEM you can also archive CO data that was updated from sales orders. This could lead to a
      sequence problem, since the archiving object CO_ITEM also archives entries that archiving object
      SD_VBAK is actually responsible for. This overlap between archiving objects SD_VBAK and CO_ITEM
      only applies for the object type “VBP” (sales document items).
5. How is the reload function implemented?
      No reload functions are available.
6. Which optional checks are available?



© SAP AG                                                                                                   Page 105
Managing SAP Archiving Projects                                                                        Version 2.0
Appendix

   No optional checks are available.
7. Are there recommendations on the input parameters on the selection screen?
   You should only archive one controlling area and one object type at a time.
8. Are additional information or SAP Notes available?
   SAP Note 73152: Preliminary transport for Release 3.0D
9. Are User Exits available?
   No

COPA1_*

In Profitability Analysis (CO-PA), the system creates archiving object COPA1_xxxx for costing-based CO-PA
when you generate your operating concern (xxxx = name of operating concern). It also generates the
corresponding write, deletion, and reload programs.
1. Which programs are available?
   Write program:          RK4A****
   Deletion program:       RK4B****
   Reload program:         RK4C****
   (“****” stands for the 4-character name of the operating concern.)
2. How are the display functions implemented?
   The CO-PA information system can read the archived data sequentially.
3. Which Customizing functions are available?
   No special Customizing available for archiving.
4. Are there dependencies or established sequences for archiving?
   When you delete, it is recommended that you select the “Delete presummarized data” field. Otherwise,
   you may obtain incorrect data in the information system when a report selects both archived data and a
   summarization level, or in planning when you plan a version that has already been archived. If you do
   select this option, you need to rebuild the summarization data and frozen report data after deleting or
   reloading.
5. How is the reload function implemented?
   All data archived with this archiving object can be reloaded. After reloading, you may need to rebuild
   summarization levels, summarization data, and frozen report data.
6. Which optional checks are available?
   No optional checks are available.
7. Are there recommendations on the input parameters on the selection screen?
   To avoid long runtimes in the case of large data volumes, you should not archive entire fiscal years at
   once. It is recommended that you restrict the data selection further, such as by periods.
8. Are additional information or SAP Notes available?
   SAP Note 92485: Performance in Release 3.0/3.1
9. Are User Exits available?
   No

Financial Accounting (FI)

FI_DOCUMNT

The financial accounting documents form the largest and most important of the databases involved in the
local currency changeover. If you are planning such a changeover, (particularly if archiving is to take place in



Page 106                                                                                                © SAP AG
Version 2.0                                                                              Managing SAP Archiving Projects
                                                                                                               Appendix

the fiscal year before the changeover), read the instructions for local currency changeover in the relevant
Implementation Guide (IMG). Note also that you may need to install relevant Hot Packages (see SAP Note
99059).
1. Which programs are available?
    Write program:                   SAPF048
    Deletion program:                SAPF048D
    Index reduction program:         SAPF048I
    Index construction program: SAPF048S
    (From Release 4.0A, the creation of object indexes also takes place at object line level.)
    Reload program:                  SAPF049
    Read programs:
    -      SAPF048A (technical archive analysis)
    -      SAPF048S (archive browser)
    -      SAPF048X (creation program for archive descriptions; condensed archive index)
    -      Logical database BRF/ all programs which use this logical database, for example:
                -   RFBELJ00 (document journal)
    -      RFEPOJ00 (line item journal)
    -      RFKKET00 (accumulated balance audit trail)
           If you choose selection variant 901 (program attribute), you can set each report that uses the logical
           database so that it takes archive files into account.
    -      Read routines/transactions (single document access for archive files):
    -      FB03 (document display)
    -      FBL1, FBL3, FBL5 (account display for customers, G/L accounts, vendors)
    -      Document environment (from Release 4.5A: All applications that post FI documents using the FI/CO
           interface and have the following menu option in their transactions: Environment à FI documents.)
    -      RFKORD*, SAPF140 (correspondence/print program)
2. How are the display functions implemented?
•       Sequential reading
•       Single document access
    There are corresponding (encapsulated) function modules for single document access and sequential
    access to the archive:
•       FI_DOCUMENT_ARCH_READ_NEXT (only for the archive)
•       FI_DOCUMENT_READ_SINGLE (for the database and archive)
    From Release 4.5A, all read accesses to the archive can be set in such a way that, for display purposes,
    they can carry out a currency conversion in accordance with the local currency changeover (see personal
    Customizing in FB00).
    Whether a single document access is possible depends on the legibility of the archive, as well as on the
    existence of appropriate indexes/the use of suitable (freely definable), personal search strategies (see
    index construction SAPF048S and personal Customizing FB00).
3. Which Customizing functions are available?
    For FI_DOCUMNT there are basically two types of Customizing:
•       Customizing of archiving history (object lives in the database) and index deletion history (index lives in
        the database)



© SAP AG                                                                                                      Page 107
Managing SAP Archiving Projects                                                                           Version 2.0
Appendix

•       Personal Customizing of archive access (search strategies, restricted/unrestricted access, translation
        during reading)
    Customizing the Lives
    -      Tables:          T070, T071
    -      Views:           V_T070, V_T071
    -      Transactions:    OBR7, OBR8
    The IMG path (in the SAP Reference IMG) is: Financial Accounting à Financial Accounting Global Settings
    à Document à Accounting Document Archiving.
    In both of the tables and views, you set the availability of a financial accounting document, its secondary
    indexes, and (from 4.0A) its archive indexes to be archived, based on the length of the desired residence
    time. Table T070 defines the minimum residence time of a document. This period can be managed
    separately according to document types and company codes. Generic entries can be set for both of these
    criteria (entry = *), so that for any one inquiry during archiving, the value that is more specific is used.
    T071 defines the runtime at a line level (account assignment). You can also manage the period
    separately here according to company code, account type and account interval (for company code and
    account type, generic entries (entry = *) are permitted; for account intervals, partial intervals and single
    values can be used from 4.5A). The more specific value also applies here; if this cannot be determined
    (interval overlap for masked values), the maximum is set).
    A document can therefore only be archived if it can be archived for all of its lines according to T070 and
    T071. If no entry is found for a document in T070 and/or T071, the life is automatically set to 9999 days.
    The same applies for the secondary and archive indexes during the index construction or postprocessing
    program.
    Customizing the Access
    User-specific parameters can be set within transaction FB00. The following search strategies exist (from
    4.0A): Without archive and with archive (using index, table of contents). The translation of amounts during
    reading takes place according to local currency conversion (from 4.5A).
4. Are there dependencies or established sequences for archiving?
    FI_DOCUMNT is not dependent on any other archiving object. There are, however, other archiving
    objects that are dependent on FI_DOCUMNT: FI_MONTHLY (FI transaction figures), as well as
    FI_ACCOUNT, FI_ACCPAYB and FI_ACCRECV (FI master data).
    Furthermore, secondary indexes can only be deleted when the corresponding documents/preceding
    documents have been archived (from 4.5A; see SAP Note 81489).
5. How is the reload function implemented?
    With the reload program, all data records that were archived with this archiving object can be reloaded in
    the database.
6. Which optional checks are available?
    To safeguard your local currency changeover, from Release 4.5A (or following the installation of the
    corresponding hot-package), there is an appropriate switch (displayed when making the corresponding
    fiscal year accrual) to safeguard the current fiscal year.
    There are no other further optional checks. There are merely selection options on the archiving planning
    selection screen, everything else is dealt with in Customizing or fixed rules (document can only be
    archived if it has been completely cleared, and so on).
7. Are there recommendations on the input parameters on the selection screen?
    Where there is a large volume of document data (from approximately. 500,000 archivable documents per
    R/3-client), splitting the archiving into several archiving runs is recommended. You must take into account
    that only one run should be carried out up to the end of the deletion run at any one time. To carry out
    parallel archiving runs, you should ensure that the document numbers on which the archiving runs
    operate are not connected. When carrying out such a split, selection by company codes and/or fiscal
    years is recommended.
8. Are additional information or SAP Notes available?



Page 108                                                                                                  © SAP AG
Version 2.0                                                                           Managing SAP Archiving Projects
                                                                                                            Appendix

    SAP Notes 81489 and 78138
9. Are User Exits available?
    Up to Release 4.5A, the User-Exit FARC0001 in the deletion program enables you to save information
    from the database or delete further (own) data when you are deleting the document.
    From 4.5A, Business Transaction Event user exits can be maintained that contain your own additional
    checks and/or additional functions for archiving, deleting, reloading, and reading.

FI_GLC_IT
1. Which programs are available?
    Write program:        RGUARCGL
    Deletion program:     RGUDELGL
    Read program:         RGUGLFLEXA (reading actual line items)
                          RGUGLFLEXP (reading planned line items)
    Reload program:       RGURELGL
2. How are the display functions implemented?
•   Sequential reading
•   Single document access
    The additional read programs listed above enable sequential read access.
    In the standard system, actual line item and planned line item reports (ABAPs) are sent to tables
    GLFLEXA and GLFLEXP. These tables can read data from the archive as well as from the databank.
    Furthermore, it is possible to branch automatically from the totals on the relevant line items to the next
    activity on the original document (irrespective of whether this is located in the database or the archive).
    From Release 4.0 the Report Writer/Report Painter for all archiving objects is linked to the archive.
    For archiving sorted by accounts/documents (see the information for FI-GLFLEX-archiving), a read
    access is possible using the SAP Archive Information System (Transaction SARI). (If archiving has been
    “sorted according to document”, the access is a “single document access”).
3. Which Customizing functions are available?
    You can call up the Customizing settings for archiving using transaction AOBJ. Using the Customizing
    transaction GLAREP you can assign all Report Writer-/Report Painter report groups for the above-
    mentioned tables that are relevant for archiving to the corresponding archiving object and start them
    directly.
4. Are there dependencies or established sequences for archiving?
    At runtime, a consistency check with the header data table BKPF (archiving object FI_DOCUMNT) is
    carried out for the ledgers that are linked to the split processor. Also, the corresponding totals of the
    flexible general ledger (archiving object FI_GLF_SUM) can only be archived after the line items have
    been archived.
5. How is the reload function implemented?
    Reloading is an emergency solution – no consistency checks are undertaken (except for EURO-relevant
    checks) and no new archive is written.
    Reloading of archived data is generally not advised, as there are sufficient read programs that enable
    access to the archived data. If however, you still want to use the reload function, you should first contact
    your SAP consultancy service.
6. Which optional checks are available?
    No optional checks are available.
7. Are there recommendations on the input parameters on the selection screen?
    The setting of parameters in the selection screen of the write program is dependent on the process
    control you have chosen (by account or document or unsorted archiving). However, what you should take




© SAP AG                                                                                                   Page 109
Managing SAP Archiving Projects                                                                        Version 2.0
Appendix

    into account and what advantages and disadvantages there are, is documented in the F1 help for each
    process control.
    You should also take into account that adding the combination list to the archiving report can impair the
    program runtime.
8. Are additional information or SAP Notes available?
    No.
9. Are User Exits available?
    No.

FI_SL_DATA
1. Which programs are available?
    Write program:         RGUARCSL
    Deletion program:      RGUDELSL
    Reload program:        RGURELSL
    Read program:
    For Releases 3.0D to 3.1I:
                           RGURDASL (reading actual line items)
                           RGURDPSL (reading planned line items)
                           RGURDTSL (reading summary records)
    From Release 4.0:
    Generation of Read ABAPs (in tables for planned and line items as well as summary tables) using
    transaction GAR9 (also possible using transaction SARA as well as IMG). These ABAPs are linked to
    one another, enabling a drilldown of the totals on the line item reports.
    The example report groups 0M11 and 0M12 that have been delivered (more are possible using
    transaction GAR8 or transaction SARA as well as the IMG) are entered.



     For Release 4.5A, these programs were changed in a revision of the archiving object FI_SL_DATA.
     For earlier releases, (up to and including 3.0D) the new programs can be imported from the
     SAPSERVx server (see SAP Note 84766).
2. How are the display functions implemented?
    The read programs listed above enable sequential read access.
    In the standard system, an actual line item, planned line item, and summary record report (ABAPs) for
    tables GLT1, GLS1, GLP1, GLFUNCT, GLFUNCA, GLFUNCP, FILCT, FILCA, and FILCP are issued
    (compare section for transaction GAR8). From Release 4.0, these tables can read data from the archive
    as well as from the database (up to Release 3.1I they could only read from the archive). Furthermore,
    from Release 4.0 (up to 3.1I this is not possible, can however be subsequently developed if necessary),
    you can branch from the totals to the corresponding line items and then to the original document in the
    next step (irrespective of whether this is located in the database or the archive).
    From Release 4.0, the Report Writer/Report Painter for all archiving objects is linked to data archiving.
    For archiving sorted by account/document (see advice for FI-SL archiving), read access using the SAP
    Archive Information System is planned (transaction SARI). (This can be problematic, because in FI-SL,
    tables can be generated by clients).
3. Which Customizing functions are available?
    Customizing can be done using the following transactions:
•   GAR8
•   GAR9



Page 110                                                                                                © SAP AG
Version 2.0                                                                        Managing SAP Archiving Projects
                                                                                                         Appendix

•   GCAG
    These transactions can also be carried out using the IMG:
    Financial Accounting à Special Purpose Ledger à Periodic Processing à Archiving
4. Are there dependencies or established sequences for archiving?
    At runtime a consistency check against header data table BKPF is carried out for ledgers that are linked
    to the split processor. Totals can only be archived after the corresponding line items have been archived.
5. How is the reload function implemented?
    No consistency checks are carried when reloading archived data (except for EURO-relevant ones).
    Before you use this function, you should contact the relevant SAP consultancy service.
6. Which optional checks are available?
    No optional checks are available.
7. Are there recommendations on the input parameters on the selection screen?
    The setting of parameters in the selection screen of the write program is dependent on the process
    control you have selected (by account, by document, or unsorted archiving). What you should take into
    consideration each time and what advantages and disadvantages there are, is documented in the F1 help
    for each process control.
8. Are additional information or SAP Notes available?
    SAP Note 84766
9. Are User Exits available?
    No

MM_ACCTIT
1. Which programs are available?
    Write program:       RGUARCMM
    Deletion program:    RGUDELMM
    Reload program:      RGURELMM (in work)
    Read program:        Reading using the SAP Archive Information System (see SAP Note 99388)
2. How are the display functions implemented?
    Single document access can be implemented using the SAP Archive Information System.
3. Which Customizing functions are available?
    Customizing takes place using transaction SARA.
4. Are there dependencies or established sequences for archiving?
    Under certain circumstances, there is a dependency to object MM_MATBEL (not yet stored in the
    network graphic, as it is not currently possible to reload or carry out post-archiving posting).
5. How is the reload function implemented?
    No reload function exists.
6. Which optional checks are available?
    No optional checks are available.
7. Are there recommendations on the input parameters on the selection screen?
    See Information and F1 help for MM_ACCTIT in transaction SARA.
8. Are additional information or SAP Notes available?
    SAP Note 48009
9. Are User Exits available?
    No



© SAP AG                                                                                                Page 111
Managing SAP Archiving Projects                                                    Version 2.0
Appendix

Logistics (LO)

MC_SELVS/MC_Snnn
1. Which programs are available?


                   MC_SELVS              MC_Snnn
                   (Transaction          (Transaction
                   MCSW)                 MCSX)
    Write          RMCSAR01              RMCANNN1
    Deletion       RMCSAR02              RMCANNN2
    Reload         RMCSAR03              RMCANNN3
Table 8: Programs available for Logistics (LO)



     The reload function can be used because all archived data will be reloaded.
1. How are the display functions implemented?
   No display functionality available.
2. Which Customizing functions are available?
   Transactions MCSX and MCSW; additional settings not required.
3. Are there dependencies or established sequences for archiving?
   No
4. How is the reload function implemented?
   All data is reloaded.
5. Which optional checks are available?
   No optional checks available
6. Are there recommendations on the input parameters on the selection screen?
   No
7. Are additional information or SAP Notes available?
   SAP Notes under the headings MCSX, MCSW and MC_SELVS.
8. Are User Exits available?
   No

Materials Management (MM)

MM_EBAN
1. Which programs are available?
   Write program:          RM06BW30
   Deletion program:       RM06BD30
2. How are the display functions implemented?
   Sequential read
3. Which Customizing functions are available?
   Transaction OMEX




Page 112                                                                           © SAP AG
Version 2.0                                                                        Managing SAP Archiving Projects
                                                                                                         Appendix

4. Are there dependencies or established sequences for archiving?
   No
5. How is the reload function implemented?
   No reload functions available
6. Which optional checks are available?
   No optional checks are available
7. Are there recommendations on the input parameters on the selection screen?
   No
8. Are additional information or SAP Notes available?
   No
9. Are User Exits available?
   No

MM_EKKO
1. Which programs are available?
   Write program:       RM06EW30
   Deletion program:    RM06ED30
2. How are the display functions implemented?
   Sequential read
3. Which Customizing functions are available?
   Transactions OMEY, OMEZ, OMEN
4. Are there dependencies or established sequences for archiving?
   No
5. How is the reload function implemented?
   No reload functions available
6. Which optional checks are available?
   Indicator in selection screen for the archiving program: “Key Date Quotation”
7. Are there recommendations on the input parameters on the selection screen?
   You are recommended to limit the selection to document types.
8. Are additional information or SAP Notes available?
   No
9. Are User Exits available?
   No

MM_MATBEL
1. Which programs are available?
   Write program:       RM07MARC (Transaction MBAR)
   Deletion program:    RM07MADE (Transaction MBAR)
   Management:          Transaction MBAV
   Read programs:       RM07MAAU (sequential access, transaction MBAL)
                        RM07MAAT (direct access, transaction MBAL/MB51)




© SAP AG                                                                                                Page 113
Managing SAP Archiving Projects                                                                        Version 2.0
Appendix

2. How are the display functions implemented?
•   Sequential read
•   Single document access
    The report RM07MAAU allows material documents to be read sequentially. From Release 4.0B the
    results can be filtered by the material number.
    From Release 4.0A selective reading (single document access) of the archived documents is possible
    using a short document. The documents are selected using the short documents and read from the
    archive by means of an index. Alternatively, the short document can also be displayed. The short
    document includes any selection of material document fields: It can be selected by these fields.
3. Which Customizing functions are available?
    Customizing can be carried out either in the transaction SARA or directly in the transactions MBAR,
    MBAD, MBAV.
4. Are there dependencies or established sequences for archiving?
    No
5. How is the reload function implemented?
    No reload functions available
6. Which optional checks are available?
    None
7. Are there recommendations on the input parameters on the selection screen?
    No
8. Are additional information or SAP Notes available?
    Refer to the program documentation for the archiving and deletion programs. It contains notes on
    Customizing and improving performance for archiving.
9. Are User Exits available?
    No

MM_REBEL
1. Which programs are available?
    Write program:         RM08RARC
    Deletion program:      RM8RADE
    Read program:          RM08RAAU
2. How are the display functions implemented?
•   sequential read
    There is a read program that reads the archive files sequentially and presents them in list form. Within a
    read run, you can search using the following selection criteria:
•   Invoice document number
•   Fiscal year
•   Posting date
•   Company code
•   Creditor
•   Reference
    If you want to display additional fields, you must modify the program RM08RAAU.
    You can select and display an invoice from the list. The document is transferred internally to transaction
    MR3M (display document), which can use the complete range of functions.




Page 114                                                                                                © SAP AG
Version 2.0                                                                         Managing SAP Archiving Projects
                                                                                                          Appendix

3. Which Customizing functions are available?
    In addition to Customizing using transaction AOBJ, there are also the following Customizing options:
•   Transaction ORMZ
•   IMG: Materials Management à Invoice Verification à Establish Document Life
    In this step, the minimum term for the invoice documents belonging to Logistics Invoice Verification is
    established per company code. When the minimum term for a document is reached, the document can
    be archived. In the SAP standard delivery, the minimum term for invoice documents is 200 days.
4. Are there dependencies or established sequences for archiving?
    In the purchase order history, the invoice document itself can no longer be displayed.
5. How is the reload function implemented?
    No reload function available.
6. Which optional checks are available?
    None
7. Are there recommendations on the input parameters on the selection screen?
    No
8. Are additional information or SAP Notes available?
    No
9. Are User Exits available?
    No

Enterprise Controlling (EC)

PCA_OBJECT
1. Which programs are available?
    Write program:       RGUARCPC
    Deletion program:    RGUDELPC
    Reload program:      RGURELPC
    Read programs:
    For Releases 3.0D to 3.1I:
                         RGUGLPCA (Reading of actual line items)
                         RGUGLPCP (Reading of plan line items)
                         RGUGLPCT (Reading of totals records)
    For Releases from 4.0A:
                         RGURDAPC (Reading of actual line items)
                         RGURDPPC (Reading of plan line items)
                         RGURDTPC (Reading of totals records)



      For Release 4.5A, these programs were changed within the scope of a revision of the archiving
      object PCA_OBJECT. For earlier releases (up to and including 3.0D), the new programs can be
      imported from the server SAPSERVx (see SAP Note 91615).
2. How are the display functions implemented?
•   Sequential read
•   Single document access



© SAP AG                                                                                                 Page 115
Managing SAP Archiving Projects                                                                      Version 2.0
Appendix

   The read programs listed above allow for sequential access. The selected archive files are read
   completely, however the data is displayed according to the selection conditions.
   In the standard version, an actual line item, a plan line item and a totals record (ABAPs) are sent to the
   tables GLPCA, GLPCP, GLPCT. These can (from Release 4.0) read the data from the archive as well as
   from the database (Release 3.1I only from the archive). Furthermore, from Release 4.0 (back to 3.1I not
   yet possible, can however be developed if necessary), it is possible to branch from the totals to the
   corresponding line items and in the next step to the original document (independent of whether this
   occurs in the database or in the archive).
   From Release 4.0, the Reportwriter/Reportpainter for all archiving objects is connected to data archiving.
   Furthermore, for archiving sorted by “account2 or “document”, faster single document access is possible
   using the SAP Archive Information System (Transaction SARI) (see Hints in EC-PCA-Archiving). Also in
   this context, refer to SAP Note 91615.
3. Which Customizing functions are available?
   The Customizing settings for archiving are accessible in the transaction AOBJ. Using the Customizing
   transaction KE87, all archiving-relevant Reportwriter-/Reportpainter report groups for the EC-PCA-tables
   can be allocated to the archiving object PCA_OBJECT and started directly.
4. Are there dependencies or established sequences for archiving?
   For the archiving object PCA_OBJECT there is no established sequence for archiving using archiving
   objects.
   However, there is the prerequisite for the archiving of totals records that the corresponding line items
   have already been archived. Therefore, archiving with the archiving type “only archive line items” must be
   executed before the archiving type “only archive totals records” can be selected. Furthermore, the totals
   records can only be archived for the last fiscal year at the earliest. This dependency is due to a fixed
   check that is implemented in the program flow.
5. How is the reload function implemented?
   With regard to possible dependencies, the reloading of PCA_OBJECT data presents no problems,
   because there are no dependent objects. Nevertheless, you are advised not to reload the data. There are
   enough read programs available that allow access to the archived data.
   Note that a complete consistency check is not possible. To avoid errors or data duplication, you should
   contact your SAP consultant before reloading.
6. Which optional checks are available?
   None
7. Are there recommendations for the input parameters on the selection screen?
   Setting parameters in the selection screen of the write program depends on the process flow control
   (archiving by account, document or unsorted), that you have chosen. To see what you should take into
   account, and which advantages and disadvantages there are, refer to the detailed information on the
   relevant process flow controls in the F1 help documentation.
   You should also note that adding combination lists to the archiving log can increase the program runtime.
8. Are additional information or SAP Notes available?
   Detailed online documentation on the write, reload and deletion programs is contained in the relevant
   hints (transaction SARA).
   SAP Note 91615
9. Are User Exits available?
   No




Page 116                                                                                              © SAP AG
Version 2.0                                                                            Managing SAP Archiving Projects
                                                                                                             Appendix

Production Planning (PP)

PP_ORDER
1. Which programs are available?
    Preprocessing program: PPARCHP1 (to set the deletion flag or the deletion indicator)
    Write program:            PPARCHA1
    Deletion program:         PPARCHD1
    Read program:             PPARCHR1
    For production orders there are two different delete statuses: Deletion flagged and deletion indicated.
    The status “deletion flagged” is reversible. Orders with this status can still be displayed. The status
    “deletion indicated” is not reversible. Orders with this status are still in the database but they cannot be
    displayed. For more information, see the documentation on “Archiving of Production Orders”.
2. How are the display functions implemented?
    The archive files are read sequentially and the individual field values are presented in list form. Direct
    accesses are not supported yet.
3. Which Customizing functions are available?
    The residence times can be maintained using the transaction OPJH (see online documentation for the
    archiving object PP_ORDER).
4. Are there dependencies or established sequences for archiving?
    When you set the deletion flag the system checks for dependencies (see online documentation for the
    archiving object PP_ORDER). The procedure for cases in which the production order is assigned to a
    sales order is described in the SAP Note no. 87561.
5. How is the reload function implemented?
    No reload function available
6. Which optional checks are available?
    None
7. Are there recommendations on the input parameters on the selection screen?
    No
8. Are additional information or SAP Notes available?
    Most of the SAP Notes are only valid up to Release 3.0F and are included in the relevant Hot Packages.
9. Are User Exits available?
    The following enhancement is available for production orders:
•   PPCO0002
    This enhancement allows you to set the delete flag or the deletion indicator (transaction SMOD).
    Additional checks can be built in that should run when setting the deletion flag or the deletion indicator.
    The enhancement PPCO0002 contains the following function module exits:
•   EXIT_SAPLCORE_001 (Set deletion flag)
•   EXIT_SAPLCORE_002 (Set deletion indicator)

Sales and Distribution (SD)

SD_VBAK
1. Which programs are available?
    Preprocessing program: S3VBAKPT




© SAP AG                                                                                                    Page 117
Managing SAP Archiving Projects                                                                          Version 2.0
Appendix

    Write program:                S3VBAKWR
    Deletion program:             S3VBAKDL
    Read program:                 S3VBAKAU
    Reload program:               S3VBAKRL



         The reload program is supplied, but is not available in transaction SARA (not maintained in
         transaction AOBJ). Archived sales documents should only be reloaded in exceptional cases,
         because dependent sub-objects cannot be reloaded.
    These programs have been changed due to a revision of archiving object SD_VBAK. The new programs
    are supplied as standard as of Release 3.1I and 4.0B, and can be transferred from server SAPSERVx for
    releases up to and including 3.0D (see SAP Note 88895).
2. How are the display functions implemented?
•   Read program:          S3VBAKAU
    The program reads the archive files sequentially and displays a list of the values in individual fields. This
    is a default list. If you want to display additional fields, you must modify program S3VBAKAU.
    Access for import is not supported. Instead, the SAP Archive Information System provides a “technical”
    view of single documents. A “business” view for selected archiving objects is at the planning stage.
3. Which Customizing functions are available?
    In addition to transaction AOBJ, you need to define the following Customizing settings:
•   Table TVARA (V_TVARA, transaction VORA)
•   IMG: Sales and Distribution à Data Transfer and Archiving à Archiving Controlà Archiving Sales Documents
    à Archiving Control for Sales Documents
    This is where you define whether sales documents are to be archived according to sales organization and
    sales document type. For this combination of entries, you enter a residence time after which a document
    can be archived. The residence time is always calculated from the date when the document is created.
    The following values apply:
•   Standard value:        30 days (if no residence time is entered)
•   Lowest value:          1 day
    You can also enter user exits that make customer-specific checks before archiving.


      You can enter generic values (*).
4. Are there dependencies or established sequences for archiving?
    When archiving sales documents, deliveries, and billing documents, there are 3 basic types of
    dependencies:
•   Which documents can be archived
    Purchase orders and purchase requisitions (MM_EKKO) must be archived before you can archive related
    orders (SD_VBAK). This is an optional check that you can switch off if required.
    Shipments (SD_VTTK) must be archived before you can archive related deliveries (RV_LIKP). This check
    is hard-coded in the program flow.
•   Display of other objects remaining in the system (documents, lists, and functions)
    If orders (SD_VBAK) that contain configurable materials have been archived, the order BOMs assigned
    to production can no longer be displayed. For this reason, archive order BOMs (CS_BOM) before you
    archive the related orders (SD_VBAK).
•   Display of details of other objects remaining in the system (documents, lists, and functions)
    If orders (SD_VBAK) have been archived, and want to display related deliveries in the system,
    sometimes details that were removed from the system when the orders (SD_VBAK) were archived can



Page 118                                                                                                  © SAP AG
Version 2.0                                                                           Managing SAP Archiving Projects
                                                                                                            Appendix

    no longer be displayed. For this reason, archive deliveries (RV_LIKP) before you archive the related
    orders (SD_VBAK).
5. How is the reload function implemented?
    Sales documents can be reloaded, but some related CO objects are not reloaded
    with them. For this reason, only reload this archiving object in exceptional cases.
6. Which optional checks are available?
•   Check purchase orders
    This checks whether purchase requisitions or purchase orders are still in the system or whether they
    have already been archived. The document cannot be archived until any purchase requisitions or
    purchase orders are archived.
    Only activate this check if you want to archive third-party orders (orders that automatically generate a
    purchase requisition when you create them). This check is not necessary for other sales document types,
    and by switching off this check you can improve system performance when archiving orders.
•   Check accounting document
    This checks whether the related accounting document has already been cleared. If it has, the order can
    be archived.
    Only activate this check if you need to ensure that orders are only archived if their accounting documents
    have been cleared. Do not use this check if your business transactions are not relevant to accounting, or
    if you do not need this check.
    This improves system performance and increases the scope of documents to be archived, because more
    documents can be archived.
•   Check residence flow document
    This calculation checks the creation date of the last business transaction, not the creation date of the
    document being checked.
    Use this check in particular for make-to-order sales documents. It ensures that sales documents with a
    long life cycle – as opposed to standard orders – cannot be archived until a later point in time. If you do
    not use this check, you can improve system performance and increase the scope of documents to be
    archived.
•   Alternative database access
    Due to administrative and locking problems within the database (keyword:
    Ora –1555 Snapshot too old), this switch uses a different type of data selection that avoids such
    problems.
    Only set this switch with an ORACLE database, and only for parallel processing of deletion runs or when
    archiving in parallel to online processing. It is not possible to make a general statement on system
    performance, because it depends on the customer's situation.
7. Are there recommendations on the input parameters on the selection screen?
    Each optional check slows down system performance for the archiving programs. For this reason,
    consider restricting the range of documents and which optional checks are really necessary. For
    recommendations on when to use the optional checks for archiving object SD_VBAK, see above.
8. Are additional information or SAP Notes available?
    SAP Note 88895: Archiving: New functions SD_VBAK
9. Are User Exits available?
    Archiving object SD_VBAK supports user exits for customer-specific checks. However, only use these
    checks for fields or tables that are available in the environment. Avoid customer-specific select
    statements in your check, because these can lower system performance. For more information, see SAP
    Note 114340.




© SAP AG                                                                                                   Page 119
Managing SAP Archiving Projects                                                                          Version 2.0
Appendix

RV_LIKP
1. Which programs are available?
    Preprocessing program: S3LIKPPT
    Write program:         S3LIKPWR
    Deletion program:      S3LIKPDL
    Read program:          S3LIKPAU
    Reload program:        S3LIKPRL



         The reload program is supplied, but is not available in transaction SARA (not maintained in
         transaction AOBJ). Archived deliveries should only be reloaded in exceptional cases.
    These programs have been changed due to a revision of archiving object RV_LIKP. The new programs
    are supplied as standard as of Release 3.1I and 4.0B, and can be transferred from server SAPSERVx for
    releases up to and including 3.0D (see SAP Note 92989).
2. How are the display functions implemented?
•   Read program:          S3LIKPAU
    The program reads the archive files sequentially and displays a list of the values in individual fields. This
    is a default list. If you want to display additional fields, you must modify program S3LIKPAU.
    Single document access is not supported by the application. However, “technical” and “business” views
    are available for single documents to be displayed for an archived delivery. For information on single
    document access, see SAP Note 14065.
3. Which Customizing functions are available?
    In addition to transaction AOBJ, you need to define the following Customizing settings:
•   Table TVARL (V_TVARL, transaction VORL)
•   IMG: Sales and Distribution à Data Transfer and Archiving à Archiving Data à Archiving Control for Sales
    Documents à Archiving Control for Deliveries
    This is where you define whether delivery documents can be archived according to sales organization
    and delivery type. For this combination of entries, you enter a residence time after which a document can
    be archived. The residence time is always calculated from the date when the document is created. The
    following values apply:
•   Standard value:        30 days (if no residence time is entered)
•   Lowest value:          1 day
    You can also enter user exits that make customer-specific checks before archiving.



      You can enter generic values (*).
4. Are there dependencies or established sequences for archiving?
    See sales documents (archiving object SD_VBAK)
5. How is the reload function implemented?
    Delivery documents can be reloaded, but this should only happen in exceptional cases. Sometimes not
    all information can be displayed in the delivery document, because information in the related order is
    required, and this order may no longer be in the system.
6. Which optional checks are available?
•   Check accounting document
    This checks whether the related accounting document has already been cleared. If it has, the delivery
    can be archived.




Page 120                                                                                                  © SAP AG
Version 2.0                                                                            Managing SAP Archiving Projects
                                                                                                             Appendix

    Only activate this check if you need to ensure that deliveries are only archived if their accounting
    documents have been cleared. Do not use this check if your business transactions are not relevant to
    accounting, or if you do not need this check. This improves system performance and increases the scope
    of documents to be archived, because more documents can be archived.
•   Check residence flow document
    This calculation checks the creation date of the last business transaction, not the creation date of the
    document being checked.
    Use this check for deliveries with a long life cycle. It ensures that deliveries with a long life cycle cannot
    be archived until a later point in time. If you do not use this check, you can improve system performance
    and increase the scope of deliveries to be archived.
•   Alternative database access
    Due to administrative and locking problems within the database (keyword:
    Ora –1555 Snapshot too old), this switch uses a different type of data selection that avoids such
    problems.
    Only set this switch with an ORACLE database, and only for parallel processing of deletion runs or when
    archiving in parallel to online processing. It is not possible to make a general statement on system
    performance, because it depends on the customer's situation.
7. Are there recommendations on the input parameters on the selection screen?
    Each optional check slows down system performance for the archiving programs. For this reason,
    consider restricting the range of documents and which optional checks are really necessary. For
    recommendations on when to use the optional checks for archiving object RV_LIKP, see above.
8. Are additional information or SAP Notes available?
    SAP Note 92989: Archiving: New functions RV_LIKP
9. Are User Exits available?
    Archiving object RV_LIKP supports user exits for customer-specific checks. However, only use these
    checks for fields or tables that are available in the environment. Avoid customer-specific select
    statements in your check, because these can slow down system performance. For more information, see
    SAP Note 114340.

SD_VBRK
1. Which programs are available?
    Preprocessing program: S3VBRKPT
    Write program:        S3VBRKWR
    Deletion program:     S3VBRKDL
    Read program:         S3VBRKAU
    Reload program:       S3VBRKRL



         The reload program is supplied, but is not available in transaction SARA (not maintained in
         transaction AOBJ). Archived billing documents should only be reloaded in exceptional cases.
    These programs have been changed due to a revision of archiving object SD_VBRK. The new programs
    are supplied as standard as of Release 3.1I and 4.0B, and can be transferred from server SAPSERVx for
    releases up to and including 3.0D (see SAP Note 93715).
2. How are the display functions implemented?
•   Read program:         S3VBRKAU
    The program reads the archive files sequentially and displays a list of the values in individual fields. This
    is a default list. If you want to display additional fields, you must modify program S3VBRKAU.
    Single document access is not supported by the application. However, the “technical” and “business”
    views are available for single documents using the SAP Archive Information System. This enables



© SAP AG                                                                                                    Page 121
Managing SAP Archiving Projects                                                                       Version 2.0
Appendix

    original documents to be displayed. The original documents relating to an archived sales document can
    also be displayed. For more information on single document access using SAP AS, refer to SAP Note
    140652.
3. Which Customizing functions are available?
    In addition to transaction AOBJ, you need to define the following Customizing settings:
•   Table TVARR (V_TVARR, transaction VORR)
•   IMG: Sales and Distribution à Data Transfer and Archiving à Archiving Data à Archiving Control for Sales
    Documents à Archiving Control for Billing Documents
    This is where you define whether billing documents can be archived, according to sales organization and
    billing type. For this combination of entries, you enter a residence time after which a document can be
    archived. The residence time is always calculated from the date when the document is created. The
    following values apply:
•   Standard value:        30 days (if no residence time is entered)
•   Lowest value:          1 day
    At the same time, the “Check accounting” check is activated, which checks whether the related
    accounting documents has been cleared. The billing document can only be archived if the accounting
    document is cleared.
    You can also enter user exits that make customer-specific checks before archiving.



     You can enter generic values (*).
4. Are there dependencies or established sequences for archiving?
    See sales documents (archiving object SD_VBAK)
5. How is the reload function implemented?
    Billing documents can be reloaded, but this should only happen in exceptional cases. Sometimes not all
    information can be displayed in the billing document, because information in the related order is required,
    and this order may no longer be in the system.
6. Which optional checks are available?
•   Alternative database access
    Due to administrative and locking problems within the database (keyword: Ora –1555 Snapshot too old),
    this switch uses a different type of data selection that avoids such problems.
    Only set this switch with an ORACLE database, and only for parallel processing of deletion runs or when
    archiving in parallel to online processing. It is not possible to make a general statement on system
    performance, because it depends on the customer's situation.
7. Are there recommendations on the input parameters on the selection screen?
    Each optional check slows system performance for the archiving programs. For this reason, consider
    restricting the range of documents and which optional checks are really necessary. For recommendations
    on when to use the optional checks for archiving object SD_VBRK, see above.
8. Are additional information or SAP Notes available?
    SAP Note 93715: Archiving: new functions SD_VBRK
9. Are User Exits available?
Archiving object SD_VBRK supports user exits for customer-specific checks. However, only use these
checks for fields or tables that are available in the environment. Avoid customer-specific select statements in
your check, because these can slow down system performance. For more information, see SAP Note
114340.




Page 122                                                                                               © SAP AG
Version 2.0                                                                            Managing SAP Archiving Projects
                                                                                                             Appendix


C. Glossary
In this section, the most important terms relating to SAP Data Archiving are explained.
ADK
Stands for Archive Development Kit and describes the development environment for archiving programs.
The ADK also offers all functions necessary for archiving and subsequent access to archived data.
Archiving class
Describes data that is linked through its business context and that is periodically extracted from the live
system according to individually-selected criteria and archived.
Archiving object
Set of interdependent business data that is periodically extracted from the current system and archived
according to individual criteria.
Optical archiving
Electronic storage and management of documents such as original documents, outgoing documents, print
lists in an external storage system that is usually based on optical media (CDs, WORMS, and so on).
Print list
Results of an R/3 report in the form of a list. The print list can be printed or stored in a storage system using
SAP ArchiveLink. Used primarily for auditing purposes.
Reorganization
In the R/2 environment, described the physical deletion of application data during a restructuring of the
database tables. Now, this applies generally to the restructuring of database tables with the aim of using
memory space efficiently.
Residence period
Period that must elapse before application data can be archived. The residence period can be based on
various application-specific data, such as creation data, posting period, goods issue date. The period can be
specified in days, weeks, months or years.
Restore
Rewriting the backup copy to the database to recreate the original sate of the database after a system
termination.
Retention period
Total period of time that data is held in the database until the point of archiving.
SAP ArchiveLink
Data interface that is embedded in the Basis component and that controls communication with an external
storage system. Enables access to stored documents from the SAP application.

D. Frequently Asked Questions

      Can archived data be reloaded to the database at any time?
There is only one situation in which data should be reloaded into the database: If, immediately after archiving
data, you realize that, as the result of a selection error, too much data was archived, you can reload this data
back into the database. Reloading historical data into the live system’s database always carries certain risks.
You should ask the following questions:
• Can the data be completely reconstructed?
• Does the data still comply with the current Customizing?
• Has the data in the database been changed in the intervening period (for example, as a result of currency
   conversion)?



© SAP AG                                                                                                    Page 123
Managing SAP Archiving Projects                                                                            Version 2.0
Appendix

• Has there been a release upgrade since the data was archived?
In addition to these questions, there is the more general question of the practicability of archiving in practice.
Usually, data is archived to make space for new data in the database. The greater the growth of data, the
more frequently archiving has to be carried out. The more frequently data is archived, the more likely it
becomes that access is required to archived data. It is also more likely that there will be sufficient space in
the database to accommodate the required data.

         Are customer-specific fields in SAP tables taken into consideration?
There is no general answer to this question. Usually, all archiving objects and archiving classes that archive
the contents of a particular table must be examined. However, it is possible to differentiate between the
following cases:
• The archiving object or archiving class writes the table contents to the archive.
    -      Customer-specific fields that were added using APPEND are automatically written to the archive.
    -      Customer-specific fields are automatically considered when reading old archives.
•       The archiving object or archiving class does not write the table record to the archive, but deletes the
        record from the database.
    -      The data in the customer-specific fields are lost (modification required).
•       The archiving object or the archiving class uses a view to write the data to the archive.
    -      The table is included in the view by means of an INCLUDE.

•       The system behaves as if the table is written to the archive.
    -      The view fields were added selectively.

•       The system behaves as if the table was not written to the archive.
To take the right measures, you should first examine which of the above cases applies to the database fields
that you created.

         What can I do to optimize data archiving whilst observing the needs of my application?
The following activities are advisable for optimum data archiving performance:
• EarlyWatch session to analyze performance and database growth.
• Monitor table growth regularly (daily or weekly)

    Within the context of an archiving project, what analyses can be carried out by the systems
administrator or application user?
• Identification of the largest tables and their rate of growth - using transaction DB02, or SAPDBA for
  Oracle/Informix
• Determining the relevant archiving objects using transaction DB015 (available from Release 4.0B).
• Identification of the objects that are used in live operations.
• Identification of objects that are being processed or have been completed for a specific period.

         What is the difference between optical archiving and data archiving?
Optical archiving is an integration component for document and archive data storage. Optical archiving uses
the SAP ArchiveLink interface, which can be used for both the storage of documents and the storage of
archive files.

         Can information structures be archived?
The archiving of information structures is a standard function. If there are no existing archiving functions, this
automatically creates programs for the creation, deletion, reloading, and management of archive files.



Page 124                                                                                                    © SAP AG
Version 2.0                                                                             Managing SAP Archiving Projects
                                                                                                              Appendix

Initially, it is not possible to call an information structure using transaction SARA since, at this stage, there is
no archiving object for the information structure (MC_Sxxx). For this reason, an information structure’s initial
archiving is carried out using the menu path Environment → Archiving → Statistics or using the transaction
MCSX. After initial access to the selected information structure, an archiving object is generated.

      Are append structures for tables archived with the object?
Most archiving objects support the archiving of customer-specific append structures for tables that are
located in the archiving objects table pool. If in doubt, check whether this is the case for the archiving object
you are using, or consult SAP support.

      Can archived data be reloaded into the system again later?
Basically, archived data can be reloaded as long as the reload function is offered for the relevant archiving
object. Note that archived data can only be reloaded within the same client. Generally, reloading should be
avoided, since archived data objects are closed business objects.

E. Further Information and Services

Information
Current information on data archiving in the R/3 environment and comprehensive documentation are
available at our website in the SAP Service Marketplace at the following address:
         http://service.sap.com/data-archiving
You can register for the SAP Service Marketplace using your online service system account.

Services
When implementing an archiving project, you may wish to consult external consulting services. In this area,
SAP has two well-experienced and competent teams - Remote Archiving Services and Remote Consulting.
SAP Remote Archiving Services assumes responsibility for all your archiving activities such as analysis,
Customizing, and archiving sessions from a remote site. SAP Remote Consulting provides telephone
support for problems relating to SAP Data Archiving. For more information, contact this department.
A further department, Remote Euro Services, can answer your questions and provide help regarding the
conversion of your R/3 system for the introduction of the euro.

Customer Training
BC660
In addition to a comprehensive introduction to the concept and functions of SAP Data Archiving, this
completely new 3-day course offers a range of real-life examples from the most important R/3 components
and has been designed to meet the specific requirements of customers.
BC670
This 2-day course focuses on the evaluation of archived data. It enables participants to write customer-
specific reports (read programs) and explains how to adjust existing programs to meet their needs.
Participants are required to have knowledge of ABAP4 and to have attended the training course BC660.
If you have further questions on the contents of the courses, or if you would like to register to attend a
course, contact the secretariat of our International Training Center (ITC) in Walldorf or call your international
subsidiary.




© SAP AG                                                                                                     Page 125

								
To top