SAP Data Archiving Strategy

SAP Data Archiving Strategy &
Approach
Moving data out of the SAP online database via an archive file to a
storage medium
SAP Data Archiving Strategy
Document Control Information
Document Information
Document Identification SAP Data Archiving Strategy
Document Name SAP Data Archiving Strategy
Document Author Abhishek Sawant
Document Version 1.0
Document Status Final
Date Released 23-Dec-2015
Document Edit History

Version Date Additions/Modifications Prepared/Revised by
Document Review/Approval History

Date Name Organization/Title Comments
Initial Document Reviewer
Distribution of Final Document

The following people are designated recipients of the final version of this document:
Name Organization/Title
Page 2 SAP Data Archiving Strategy and

18-Nov-21 Approach
Table of Contents
1. Introduction.........................................................................................................................................4
1.1 Preface of Data Archiving............................................................................................................4
1.2 When to use Data Archiving........................................................................................................4
1.3 Benefits of Data Archiving...........................................................................................................5
2. Archiving Overview..............................................................................................................................6
2.1 Data Archiving..............................................................................................................................7
2.2 Data Purge...................................................................................................................................8
2.3 Data Retrieval..............................................................................................................................9
2.4 Document Imaging.....................................................................................................................11
3. Storing Archived Files........................................................................................................................12
4. Archiving Phases................................................................................................................................13
4.1 Analysis and Development.........................................................................................................13
4.2 Archiving Scheduling and Execution..........................................................................................14
4.3 Archiving Maintenance..............................................................................................................14
5. Milestones and Deliverables..............................................................................................................14
6. Project Resource Requirements........................................................................................................16
7. Archiving Procedure..........................................................................................................................18
7.1 Objective....................................................................................................................................18
7.2 Archiving Objects.......................................................................................................................18
7.3 Create Archive Files...................................................................................................................19
7.4 Delete the archived data from database...................................................................................22
7.5 Access Archived Data.................................................................................................................23
7.6 Retrieve archived data from Standard reports:.........................................................................24
7.7 Other useful transactions..........................................................................................................26
8. Custom Program................................................................................................................................29
9. Data Archiving for HANA...................................................................................................................33

18-Nov-21 Approach
1. Introduction
1.1 Preface of Data Archiving

Today a large number of enterprises use SAP R/3 as a platform for integration of business processes.
Continuous usage of SAP results in huge amount of enterprise data, which is stored in SAP R/3. With
passage of time, the new and updated data is entered into the system while the old data still resides
in the SAP enterprise system.
Since some of the old data is critical, it cannot be deleted. The difficulty is to keep the required data
and delete the unwanted data. Hence, SAP database keeps on expanding rapidly and enterprise
systems, which have limited data retention abilities for a few years, suffer from problems such as
data overflow, longer transaction processing times and performance degradation.
The solution to this problem has led to the concept of Data Archiving in SAP. Data Archiving removes
out-of-date data from the SAP database that the R/3 system does not need online, but can be
retrieved on a later date, if required. This data is known as archived data and is stored at an offline
location. Data Archiving not only consistently removes data from the database but also ensures data
availability for future business requirements.
1.2 When to use Data Archiving

Implementing data archiving should be a question of when not why. Typically, a client will start
looking for an archiving solution when archiving becomes necessary. However, the turnaround time
to implement a data archiving solution can take up to 6 months or longer. If the client implemented
data archiving solution as part of a SAP development project (before Go-Live), then the client can
leverage the data archiving process and technologies that are already implemented to quickly
correct a data archiving related issue. For example, adding a high data growth business object to
the archive object list or a new legal requirement mandated by the government.

18-Nov-21 Approach
1.3 Benefits of Data Archiving

Data archiving offers benefits in performance improvement and legal requirements. The sooner
archiving is in place, the sooner the benefits can be realized.
Performance Improvements:
o Reduced database growth rates
o Improved system performance
o Improve storage and capacity
o Reduced back-up and recovery times
o Reduced data management costs
Legal Requirements:
o Many countries require companies to adhere to paperless tax audits
o Auditors may require direct access to a system to analyze all relevant system data
o Data archiving flexibility enables custom programs to meet the legal requirements of various
countries and industries
o Compliance with Records Managements retention requirements

18-Nov-21 Approach
2. Archiving Overview
Moving data out of the SAP online database via an archive file to a storage medium (either an SAP
file system or an external storage system), where that data remains accessible to users
Archiving within the context of a SAP system refers to the removal of data that is no longer required
on the production database. Yet, in order to fulfill business and legal retention requirements, some
form of retrieval will be necessary.
Correct archiving procedures ensure that:
o Disk space and performance problems caused by the growth in the volume of transaction data
do not become critical.
o Statutory data retention rules are observed.
o Archiving processes do not interrupt business flow.
o System maintenance is very efficient
To meet the needs of the SAP system, three forms of archiving are possible: data archiving, data
purge, and document imaging.
R/3 system
DB
DB Interface
L Archiving
D ABAP/4 program class
B
Conversion of:
ADK: Codepage, record structures,
number formats
ArchiveLink Archive
file
Archive system with

tertiary storage media
Information from SAP AG

18-Nov-21 Approach
The Archive Development Kit (ADK) can be accessed through transaction SARA. The ADK provides
the following options for archiving objects (varies per object):
o Preparation
o Archive
o Delete
o Post-processing
o Reload
o Analyze
o Management
o Index
The ADK also contains the selection variants, start time and date settings, spool parameters, object
dependencies, and object customization fields necessary to build the archiving solution.
The benefits of using the ADK are compression (optimally five times), ability to archive while the
system is active, dependency graphics, and access to individual data objects in the archive. It also
provides the means to Reload, Analyze, or Read data that has been removed from the database.
2.1 Data Archiving

Large quantities of data flow through a fully operational SAP system on a day-to-day basis. Despite
significant improvements in system architecture and hardware capabilities, it is inevitable that
certain tables within SAP will eventually grow to an unacceptably large size, which may have a direct
impact on system performance. In order to maintain acceptable performance levels, there may be a
need to remove data from the system at some point in time.
Data archiving involves the physical removal of data from the SAP system’s database tables. This
type of archiving allows information to be moved to a non-production environment and held on a
separate storage device or medium (i.e. Optical Disk, etc.). In some cases, it is likely that once
removed from the database, this data will not be needed in the future. However, for business and
legal reasons, it is likely that the majority of extracted data must remain accessible.
Figure 2 below shows the process of internal document archiving within SAP.

18-Nov-21 Approach
During an archiving session, internal SAP documents residing on the R/3 database are extracted by
means of Archiving Objects. Objects, containing a series of pre-coded ABAP programs, exist for all
standard SAP data that can be archived, and are grouped by functional area. These pre-coded
programs control the archive and delete functions of the archiving process. Some objects also
contain programs for the analysis of archived data. In addition, a number of archiving objects contain
programs for the reloading of data. The reload programs are designed to be used in emergency cases
only and should not be considered as forming any part of the standard data archiving workflow. As
such, it should not be possible to use the reload programs to subsequently gain access to archive files
at Client X. The risks inherent to this process are too great.
It should be noted that if a business need exists to archive data from custom tables, it would be
necessary to build archiving objects specifically for that purpose. In such a case, custom ABAP
programs would be designed for the archive and delete functions.
The archiving program creates an archive file at the operating system level. The data to be archived is
read from the database tables and written to that file. Data is archived according to a number of
business related criteria, some of which are user configurable. Purchasing documents, for example,
can only be archived if the deletion flag is set; this flag can only be set if the document is complete
and closed.
The process of writing to the file continues either until the job has completed or until the maximum
file size or number of documents - as specified by the user - has been reached. If the file has reached
its maximum size or maximum number of documents, a new archive file is created, and the archive
process continues.
The delete program may be configured to start automatically during the execution of the archive
program, or as a separate job which the user executes after the entire archive run has been
completed. If configured to run automatically, the delete program begins executing after the first
archive file is closed. This program reads the archived data from the file, and deletes the
corresponding records from the R/3 database. This procedure guarantees that only data that has
been correctly saved to the archive file is deleted.
2.2 Data Purge

The difference between data archiving and data purge is very simple, but important. Data purge
refers to the process of removing data from the R/3 system permanently.
The data purge process is exactly the same as data archiving: internal SAP documents residing on
the R/3 database are extracted by means of the Archiving Objects. The archive program will create
an archive file at the operating system level - but at a different file path from the archive files
created from data archiving objects. After the SAP delete program has verified the archived data
from the file, it will delete the corresponding data from the R/3 database. Once this is complete, the
data purge archive file will be permanently purged from the system.

18-Nov-21 Approach
2.3 Data Retrieval

As stated above, one of the reasons for Data Archiving is to retain the archive file (archived data) for
future retrieval. There are four retrieval methods available to users:
2.3.1 Reload
The Reload program provided in the ADK reads the archive file and repopulates the SAP online
database with the archived data. This method of retrieval is not recommended by SAP and may
cause data integrity problems. Therefore, while this option may be available for some archiving
objects, it should not be implemented as a retrieval solution.
2.3.2 ADK Read (Analyze) Programs

SAP provides a standard retrieval program (the analyze option in the ADK) for the viewing of data in
archive files. The user is unable to run reports or analysis tools against this data. The Analyze
program only provides a view of this data.
2.3.3 Single Document Access

Single Document Access (SDA) combines the best attributes of the prior two retrieval methods,
Reload and Analyze. SDA allows the user to display archived data through normal display
transactions without repopulating the SAP tables. When the delete program of an archiving object
with SDA capabilities is executed, SAP updates an archiving table with indexing information for this
archived data. Therefore, when the user attempts to view this data using normal business
transactions, SAP knows where to find this data, and the user will be queried whether they want to
retrieve this data.

18-Nov-21 Approach
By answering yes, a temporary structure for the data is created, and the user can display the data in
the same display screens as online data. As the name states, it is only possible to use this method of
retrieval on one document at a time. Furthermore, this feature is available for only a few objects
e.g. FI_DOCUMNT.
2.3.4 Archive Information System

The R/3 Archive Information System (SAP AS) is an archiving tool for enhancing search capability in
the R/3 data archives. The search for and display of the data follows the rules set in the Archive
Information Structures, which may be defined and populated with data from the archives.
In response to customer needs to create more flexible retrieval programs, SAP developed the
Archive Information System (SAP AS). Although SAP AS is completely customizable by the user, it
does not provide the transparent retrieval of SDA (Single Document Access).
SAP AS includes the following components:
1. Archive Retrieval Configurator (ARC) allows creation of archive information structures to be
populated with data from archives by using field catalogs. It provides an index for searching.
2. Archive Explorer allows fast searches of archived data. It does this by accessing the archive
information structures created and stored in transparent database tables using the ARC.
The user creates two objects for AS: 1) the Information Structure where some archived data will be
stored, and 2) the Field Catalog that will help define which data is stored in the Information
Structure.
First, the user creates the field catalog. The field catalog lists the SAP table fields that can be used as
key indexing fields and search criteria for the archived data. After the field catalog is created, the
user defines the info structure. The info structure will become a SAP table that contains data for
the fields specified by the associated field catalog.
As data is being archived (deleted) from SAP, the info structure (table) is being populated with the
archived data that corresponds to the fields listed in the field catalog. This data will act as an index
to retrieve archived data.
After the archiving job is complete, the user may use the info structure’s contents as search criteria
to retrieve archived data. The user can then drills down into a particular line item in the info
structure and view all archived data associated with the key fields. Currently SAP provides two
views – technical and business views of the data. Technical views break the data down into tables
and fields (as shown above). Business views list the data in a formatted display. It is only possible to
18-Nov-21 Approach
view a single document at a time.
2.4 Document Imaging

When archiving, removing historic and orphaned transactional data from the R/3 system is of
primary importance, yet because of statutory policies it will be necessary to retain some data or
information that would be deleted. For this purpose, SAP created the analyze programs that are
associated with some objects in the ADK. It is important to acknowledge though that not all objects
have analyze programs and not all analyze programs are satisfactory. Therefore, it is sometimes
necessary to look to document imaging as a means of retaining the information needed to fulfill
retention requirements. Document imaging allows purging of unneeded SAP data while retaining
business and legal information in the form of an image in a 3rd party storage device.
Document imaging captures an image of an outgoing SAP document -- i.e. sales order, purchase
order, etc. – and stores this image in an optical jukebox or on CD-ROM. The image that is captured
is identical to the printout of the outgoing document.
Figure 5 below shows the process of document imaging:
At the time of printing, the outgoing document is sent to the print spool. From here the
document’s information will be sent in two directions. First, the document will be printed. If there
is no printing error, the document is sent through the SAP Archive Link where it is processed and
made available to the third-party document-imaging tool. The third-party tool stores and manages
the image.
When the document is processed in the Archive Link, information pertaining to the document is
indexed. Therefore, the user is able to retrieve the image through the SAP client.

18-Nov-21 Approach
3. Storing Archived Files
In general, it is not enough simply to write the data to be archived to archive files and delete it from
the database.
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:
There are several methods for storing and administering archive files:
1. 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 Archive Link is not necessary.
2. Storage system using SAP Archive Link: If an external storage system is connected using SAP
Archive Link, this storage system is instructed to store processed archive files at the end of a
successful deletion run.
3. 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.

18-Nov-21 Approach
4. Archiving Phases
Typical archiving phases / cycles are -
4.1 Analysis and Development

In this phase, objects for archiving will be identified and finalized. Objects which are not required in
future are purged instead of archiving.
Roles and Responsibilities –

1. Archiving Architect –
Analysis – Identify objects to be archived (standard as well as custom), purged (deleted from system
– for example IDOCs)
Identify the risk – Complexity and Impact
Finalize the strategy – Data Retention, Archival and retrieval strategy
2. Process Team Member(s) –

Process team member is responsible for Configuration, Prototyping and Testing.
Make sure archiving processes do not interrupt business flow
3. Technical Developer(s)
This is an optional role required in case of archival strategy is required on custom objects

18-Nov-21 Approach
4.2 Archiving Scheduling and Execution
In this phase/cycle, Archiving Schedule is finalized and executed. This schedule is based on every
object. Based on volume daily / weekly or monthly strategy is applied.

1. Archiving Architect
Finalize the schedule for archiving considering archiving objects and volume
2. Archiving Administrator
Scheduling and executing archiving jobs
3. Storage Administrator (optional)

Monitoring storage system during and after archiving jobs
4.3 Archiving Maintenance
This is an ongoing phase where online storage and performance is monitored and modifications are
made to existing archiving objects if necessary.

1. Archiving Architect
Monitor the system performance and storage requirement.
Review and modify existing archiving objects.
2. Storage Administrator
Review backup and recovery procedures
Review storage allocation, hardware assessment, and directory structures
5. Milestones and Deliverables

Below list is a deliverables for milestones of Archiving project
Milestone Deliverable(s)
1 Create Prioritized Archive Object List  Completed list of objects to be archived

together with specific properties regarding
retention, schedule, size, etc. from each
functional / application area.

18-Nov-21 Approach
2 Select Archiving System Vendor  Decision matrix with vendor selection

criteria establishing selected vendor
3 Archiving System Technical Design  Storage requirements for archive objects to

allow infrastructure / basis team to capture
requirements for the design phase of the
archiving solution
 Livelink ECM - Suite for SAP Solutions
infrastructure validation including s/w
versions compatibility, licensing,
backup/storage requirement, availability
and sizing
 Infrastructure design including H/W, O/S,
Livelink ECM - Suite for SAP Solutions, SAP
integration, networking requirements,
availability and backup.
4 Purchase Solution  Signed CAR documentation for project

 Completed purchasing documents for
required components
5 Archiving Design for Standards & Templates  Archiving object requirements specification
template
 Archiving process design documentation
 Performance metrics requirements
6 Install Archiving System  Operable Dev/QA archiving system in

Location 3 City
 Operable Prod archiving system in Location
4
7 Develop Archiving Objects  Completed requirements documents per

archive object
 Completed unit test plans per archive object
 Completed configuration, OSS Note
application, variant definition per archive
object
8 Quality Assurance Testing  Completed QA test plan strategy

 Completed QA test per object

18-Nov-21 Approach
9 Develop Archiving Processes and Procedures  Diagram of archive object sequence/process

flow for objects in each functional /
application area
 Documented processes for: archiving,
purge, retrieval and max retention disposal
10 Volume & Performance Testing  Completed VPT test templates per object
 Completed VPT test case per object
11 Final Preparation  Completion of all transports to prod

environment
 Archive job scheduling
 Archive operations procedures
12 Go-Live & Support  Archiving verification report

 Archiving results report
13 Future Scope  Periodic system evaluation report

 Legal requirement mandates
6. Project Resource Requirements

Primary Roles
Given the timeframe to deploy an archiving solution for the Client X Project A, a number of key roles
would be required to drive the archiving solution from a technical infrastructure and SAP basis view
point. The roles listed below summarize the responsibility of each role.
Archiving Architect:
Responsible for the overall technical orchestration of the effort in support of the Client X project
leader. The specific value this role brings to the project is the depth of experience in orchestrating
the involvement of all the disparate technical and process teams associated with the archiving
project.
Infrastructure Team Lead:

18-Nov-21 Approach
Responsible for understanding the interdependencies between operating systems, storage and
RDBMS in the context SAP archiving requirements and delivery. This role will help outline the
requirements for designing the technical infrastructure requirements for archiving.
Basis Team Lead:
Responsible for understanding the archiving interdependencies between the functional aspects and
SAP basis requirements to support the archiving processes. This role will help outline the
requirements for designing the SAP Basis requirements for archiving.
Other Team Involvement

Technology Team:
o Review the Data Archiving Technical Architecture plan

o Provide operations standards during the Requirements phase
o Perform migrations, DB reorgs and other basis support activities
Business Resources:
o Work with Business to identify resources to participate in requirements gathering/validation

o Business resources who have extensive knowledge of the business and various SAP modules to
help determine and or validate data to be archived and/or purged. Also will determine/validate
data retention.
o Involvement is by interviews lasting 1-2 hours with follow-ups for further clarification
Run Support:
o Apps Management may need to provide research information regarding existing application
environment
o Basis may need to provide research information regarding existing database environment
SAP Configuration Team:
Current SAP configuration knowledge may be required to provide insight on object configuration
and data structures.
Post Go-Live Resource Needs

Archiving Team Lead:
o Responsible for understanding the archiving interdependencies between the functional aspects
and SAP basis requirements to support the archiving process.
o Experience of SAP archiving

18-Nov-21 Approach
Archiving Administrator:
o Responsible for primarily archiving targeted functional / application areas, second responsibility
for supporting another administrator. At this stage the workload for archiving has not been
clearly defined, however, initially a target of one administrator per application is recommended.
o Archive Management (write, delete, post-processing, read, index management)
Archive Monitoring (Incorrect and incomplete sessions, completed sessions and sessions to be
archived)
7. Archiving Procedure
7.1 Objective
In this exercise we will archive two FI Documents and will retrieve them from standard reports.
7.2 Archiving Objects
Archiving objects instruct the SAP archiving system to get the right tables when archiving specific
R/3 business objects. They are defined using transaction AOBJ.
The archiving objects are defined for different modules of a SAP system. For example, financial
accounting documents are archived via the archiving object FI_DOCUMNT, which comprises the
document header, company-code-dependent postings, change documents, SAP script texts and
other elements. Some archiving objects with their basic functionality are listed in the table below.
Archiving Object Type of Archiving Object Details
Only the cleared FI documents

FI_DOCUMNT Finance
will be archived
Special Purpose Line Item records in Special

FI_SL_DATA
Ledger purpose Ledger will be archived
IDOC IDOC’s Expired IDOC’s will be archived
PS_PROJECT Project Systems Closed Projects will be archived

Profit Center line items will be
EC_PCA_ITM Profit Center
archived
Profit Profit Center totals records will
EC_PCA_SUM
Center be archived
Older Work items with status of
WORKITEM Work Flow completed or cancelled status
will be archived

18-Nov-21 Approach
7.3 Create Archive Files
The archive files can be created using the write program for each Archiving object.
Use Transaction AOBJ to find out the Write, Delete, reload and other program for a particular
archiving object.
The archive files for FI_DOCUMNT can be created using the write program SAPF048. Create a variant
with an appropriate data for program SAPF048.
Note that FI Documents which are cleared can only be archived.
Consider the below documents that are to be archived:
Create Variant for program SAPF048:

18-Nov-21 Approach
Once the variant is created, run the write program from transaction SARA
Choose the ‘Write’ option which will take you to below screen:

18-Nov-21 Approach
Use the variant created in SAPF048 program. Ensure to maintain the start date and Spool
Parameters for the background job to be triggered.
From the below spool list which is the output of the write program scheduled in background, you
can find the Archive File key, File session number, number of documents archived etc. parameters:
7.4 Delete the archived data from database

18-Nov-21 Approach
Once the data is archived, it needs to be deleted from the database.
The delete program for FI_DOCUMNT is ‘SAPF048D’.
Create a variant with appropriate selections for the program SAPF048D.
In transaction SARA, choose option ‘Delete’ and press ‘Archive Selection’ option:
Check the required archive file to be processed by the delete program.
Check ‘000159’ in this case.
Also mention the ‘Start Date’ and ‘Spool Parameters’ to schedule the program in background. Once
the program is scheduled in background it will delete the same records from the related FI tables.
Check the spool of the scheduled background job, you can find the number of deleted document as
‘2’.
Now check the documents in BKPF table and you can find the entries do not exists as they were
archived.
18-Nov-21 Approach
7.5 Access Archived Data
Use transaction ‘SARI’ to view the archived data:
Choose option ‘Archive Explorer’:
The name of the Archive info Structure might change as per the configuration settings.

18-Nov-21 Approach
Enter the required data and execute to see the archived data.
7.6 Retrieve archived data from Standard reports:
Using TCODE FB03 to view the archived FI documents:

18-Nov-21 Approach
Use other transaction such as FBL3N, FBL5N to fetch the cleared Archived documents:

18-Nov-21 Approach
In FBL#N transactions, to fetch the archived data choose the DATASOURCE option as 'Archive’.
7.7 Other useful transactions

Dynamic Menu
A list of transaction codes along-with the short description required for SAP Archiving can be found
in the dynamic menu. Go to transaction SDMO and enter search for the text as ‘Archive’.

18-Nov-21 Approach
Identifying the Archive Objects
Transaction DB02 is used to identify tables with high growth in data volumes and to compare
the table size after archiving and thus to monitor growth of the database tables.
Transaction TAANA which is used to identify the appropriate archiving object when a table

has more than one archiving object

18-Nov-21 Approach
Transaction DB15 is used to identify the Archive Objects, if you know the Database tables or if
you know the Archiving Object it displays the list of associated database tables for that
particular Archiving Object as Shown in the below figure.

18-Nov-21 Approach
8. Custom Program
* ---------------------------------------------------------*
* Purpose: This is a test program to demonstrate*
* the retrieval of archived data *
*----------------------------------------------------------*
REPORT ztest_arch NO STANDARD PAGE HEADING.
*----------------------------------------------------------*
* TYPE POOLS *
*----------------------------------------------------------*
TYPE-POOLS: rsds.
*----------------------------------------------------------*
* TYPE DECLARATION *
*----------------------------------------------------------*
TYPES: BEGIN OF ty_final,
archkey TYPE aind_arkey-archivekey, "Archive Key
bukrs TYPE bukrs, "Company code
belnr TYPE belnr_d, "Document Number
gjahr TYPE gjahr, "Fiscal Yr
END OF ty_final.
*----------------------------------------------------------*
* INTERNAL TABLE DECLARATION *
*----------------------------------------------------------*
DATA: t_final TYPE TABLE OF ty_final,
t_bkpf TYPE TABLE OF bkpf,
t_archptr TYPE TABLE OF aind_arkey,
t_frange TYPE rsds_frange_t.
*----------------------------------------------------------*
* WORKAREA DECLARATION *
*----------------------------------------------------------*
DATA: wa_final TYPE ty_final,
wa_bkpf TYPE bkpf,
wa_archptr TYPE aind_arkey,
wa_frange TYPE rsds_frange,
wa_rsdsselopt LIKE rsdsselopt.
*----------------------------------------------------------*
* WORK VARAIBLES *
*----------------------------------------------------------*
DATA: v_handle TYPE sy-tabix.
*----------------------------------------------------------*
* SELECTION SCREEN *
*----------------------------------------------------------*
SELECT-OPTIONS: s_bukrs FOR wa_bkpf-bukrs,
s_belnr FOR wa_bkpf-belnr,
s_gjahr FOR wa_bkpf-gjahr.

18-Nov-21 Approach
*----------------------------------------------------------*
* START-OF-SELECTION *
*----------------------------------------------------------*
START-OF-SELECTION.
* Populate the Company code details

IF s_bukrs[] IS NOT INITIAL.
wa_frange-fieldname = 'BUKRS'.
LOOP AT s_bukrs.
MOVE-CORRESPONDING s_bukrs TO wa_rsdsselopt.
APPEND wa_rsdsselopt TO wa_frange-selopt_t.
ENDLOOP.
APPEND wa_frange TO t_frange.
CLEAR wa_frange.
ENDIF.
* Populate the document number details

IF s_belnr[] IS NOT INITIAL.
wa_frange-fieldname = 'BELNR'.
LOOP AT s_belnr.
MOVE-CORRESPONDING s_belnr TO wa_rsdsselopt.
ENDLOOP.
CLEAR wa_frange.
ENDIF.
* Populate the fiscal year details

IF s_gjahr[] IS NOT INITIAL.
wa_frange-fieldname = 'GJAHR'.
LOOP AT s_gjahr.
MOVE-CORRESPONDING s_gjahr TO wa_rsdsselopt.
ENDLOOP.
CLEAR wa_frange.
ENDIF.
* Function Module to fetch the archive pointers

* with respect to the data in t_frange
CALL FUNCTION 'AS_API_READ'
EXPORTING
i_fieldcat = 'SAP_FI_DOC_002'
i_selections = t_frange
IMPORTING
e_result = t_archptr[]
EXCEPTIONS
no_infostruc_found = 0.
* Pull the data from archive using the fetched pointers

LOOP AT t_archptr INTO wa_archptr.

18-Nov-21 Approach
* Read the archive data using archive object & get the
* handler
CALL FUNCTION 'ARCHIVE_READ_OBJECT'
EXPORTING
object = 'FI_DOCUMNT'
archivkey = wa_archptr-archivekey
offset = wa_archptr-archiveofs
IMPORTING
archive_handle = v_handle
EXCEPTIONS
OTHERS = 42.
IF NOT sy-subrc IS INITIAL.
CONTINUE.
ENDIF.
* Get the archived BKPF data using the handler

CALL FUNCTION 'ARCHIVE_GET_TABLE'
EXPORTING
archive_handle = v_handle
record_structure = 'BKPF'
all_records_of_object = 'X'
TABLES
table = t_bkpf.
* Close the file using handler

CALL FUNCTION 'ARCHIVE_CLOSE_FILE'
EXPORTING
archive_handle = v_handle.
LOOP AT t_bkpf INTO wa_bkpf.

wa_final-archkey = wa_archptr-archivekey.
wa_final-bukrs = wa_bkpf-bukrs.
wa_final-belnr = wa_bkpf-belnr.
wa_final-gjahr = wa_bkpf-gjahr.
APPEND wa_final TO t_final.
CLEAR wa_final.
ENDLOOP.
REFRESH t_bkpf[].
ENDLOOP.
SORT t_final.
DELETE ADJACENT DUPLICATES FROM t_final.
*----------------------------------------------------------*
* END-OF-SELECTION *
*----------------------------------------------------------*
END-OF-SELECTION.
LOOP AT t_final INTO wa_final.
WRITE:/5 wa_final-archkey,
30 wa_final-bukrs,
38 wa_final-belnr,

18-Nov-21 Approach
53 wa_final-gjahr.
ENDLOOP.
*----------------------------------------------------------*
* TOP-OF-PAGE *
*----------------------------------------------------------*
TOP-OF-PAGE.
WRITE:/5 'Archive Key' COLOR 5,30 'C.Code' COLOR 5,38
'Document No.' COLOR 5,53 'F.Year' COLOR 5.
WRITE:/5 sy-uline(55).
Selection Screen:
Use the data which was archived in exercise:
Output:

18-Nov-21 Approach
9. Data Archiving for HANA
SAP HANA is a relational database management system that stores data in memory rather than on
traditional hard disks. It is used in conjunction with "big data" for accelerating business processes,
data processing, and analytics.
Volume is not just few gigabytes of data; we're talking about terabytes and petabytes in some cases.
When stored traditionally, gleaning insights from the massive amounts of data stored on hard disks
takes time - and it can lead to bandwidth issues. With SAP HANA, a business's data - even multiple
terabytes of it - is stored on in a memory where it can be accessed instantly. The ability to gather
information in real time is one of SAP HANA's biggest selling points. However, storing big data on
memory rather than on low-cost, high capacity hard disks is costly. Data archiving from HANA is a
technique used to lower the overall cost of SAP HANA. After all, if you no longer need data, why pay
to store it on one of the most expensive forms of storage. While controlling costs is certainly an
important factor when considering data archiving from HANA, it's not the only one. Data archiving
can improve business information and help ensure that your most critical information is readily
available.
Archiving from HANA improves business information by categorizing and indexing it. Whether you
need to look up a sales order from ten years ago or want to view the latest real time sales
information, integrating a data archive with SAP HANA is a winning combination. You'll be able to
quickly find old data (without having to pay a premium to store it in memory) and you'll have more
in-memory space available for current information. In addition, moving non-essential data from
HANA can improve the performance of other applications that may not be as capable as HANA is at
sorting through terabytes of data.

18-Nov-21 Approach

SAP Data Archiving Strategy

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SAP Data Archiving Strategy

Uploaded by

Copyright:

Available Formats

SAP Data Archiving Strategy &

Document Identification SAP Data Archiving Strategy

Document Name SAP Data Archiving Strategy

Document Author Abhishek Sawant

Document Version 1.0

Document Status Final

Date Released 23-Dec-2015

Document Edit History

Document Review/Approval History

Distribution of Final Document

Page 2 SAP Data Archiving Strategy and

Page 3 SAP Data Archiving Strategy and

1.1 Preface of Data Archiving

1.2 When to use Data Archiving

Page 4 SAP Data Archiving Strategy and

1.3 Benefits of Data Archiving

Page 5 SAP Data Archiving Strategy and

Archive system with

Information from SAP AG

Page 6 SAP Data Archiving Strategy and

2.1 Data Archiving

Page 7 SAP Data Archiving Strategy and

2.2 Data Purge

Page 8 SAP Data Archiving Strategy and

2.3 Data Retrieval

2.3.2 ADK Read (Analyze) Programs

2.3.3 Single Document Access

Page 9 SAP Data Archiving Strategy and

2.3.4 Archive Information System

2.4 Document Imaging

Page 11 SAP Data Archiving Strategy and

Page 12 SAP Data Archiving Strategy and

4.1 Analysis and Development

Roles and Responsibilities –

2. Process Team Member(s) –

Page 13 SAP Data Archiving Strategy and

4.2 Archiving Scheduling and Execution

Roles and Responsibilities –

3. Storage Administrator (optional)

4.3 Archiving Maintenance

Roles and Responsibilities –

5. Milestones and Deliverables

1 Create Prioritized Archive Object List  Completed list of objects to be archived

Page 14 SAP Data Archiving Strategy and

2 Select Archiving System Vendor  Decision matrix with vendor selection

3 Archiving System Technical Design  Storage requirements for archive objects to

4 Purchase Solution  Signed CAR documentation for project

6 Install Archiving System  Operable Dev/QA archiving system in

7 Develop Archiving Objects  Completed requirements documents per

8 Quality Assurance Testing  Completed QA test plan strategy

Page 15 SAP Data Archiving Strategy and

9 Develop Archiving Processes and Procedures  Diagram of archive object sequence/process

11 Final Preparation  Completion of all transports to prod

12 Go-Live & Support  Archiving verification report

13 Future Scope  Periodic system evaluation report

6. Project Resource Requirements

Infrastructure Team Lead:

Page 16 SAP Data Archiving Strategy and

Basis Team Lead:

Other Team Involvement

o Review the Data Archiving Technical Architecture plan

o Work with Business to identify resources to participate in requirements gathering/validation

SAP Configuration Team: