8/13/2019
Sap Press Archiving Sap Data
Helmut Stefani (Ed.)
Archiving Your
®
SAP Data
A comprehensive guide to plan and
execute archiving projects
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
1/40
8/13/2019
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
Sap Press Archiving Sap Data
2/40
8/13/2019
Sap Press Archiving Sap Data
6
2.3
2.3.1
2.3.2
2.3.3
Other Processes and Tasks 70
Accessing Archived Data 70
Reloading Archived Data 72
Executing Preprocessing and Postprocessing Programs 74
3
Storing Archived Data 77
3.1
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
Criteria for Choosing a Storage Strategy 77
Security 78
Costs 82
Integration 83
Performance 84
Long-Term Storage 85
3.2
3.2.1
Storage on a Certified Storage System 87
Definitions: ArchiveLink, KPro, CMS 87
3.2.2
3.2.3
3.2.4
3.2.5
3.2.6
3.2.7
3.2.8
3.2.9
What is ArchiveLink? 90
Document Scenarios 101
Interface to External Systems 108
Storing Archive Files 112
Known Technical Problems with Archive File Storage 114
Accessing Archive Files 116
Known Technical Problems Accessing Archive Files via ArchiveLink 117
Advantages of Using ArchiveLink 117
3.3
3.3.1
3.3.2
3.3.3
3.3.4
3.3.5
Storage via HSM Systems 118
What is HSM? 118
Storing Archive Files 120
Accessing Archive Files 121
Typical Technical Problems 122
Advantages of Using HSM Systems 123
3.4
3.4.1
3.4.2
3.4.3
Manual Storage 123
Direct Integration 123
Indirect Integration 124
Advantages and Disadvantages of Manual Storage
3.5
Summary
4
Accessing Archived Data 125
4.1
4.1.1
Introduction 125
What Is Not Covered in This Chapter 126
4.2
The Fundamentals
4.3
Sequential Read Programs
4.4
Direct Access
124
124
127
129
131
Content
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
3/40
8/13/2019
Sap Press Archiving Sap Data
4.5
4.5.1
4.5.2
4.5.3
4.5.4
Archive Information System 133
Creating an Infostructure 134
Activating an Infostructure 135
Building an Infostructure 136
Evaluating an Infostructure 137
4.5.5
4.5.6
Deleting aanField
Infostructure
139
Creating
Catalog 139
4.6
Archive Accesses Based on the Archive Information System 144
4.7
4.7.1
4.7.2
The Document Relationship Browser 146
Connected Object Types in Detail 149
Configuring the Document Relationship Browser 155
5
Technology and Administration 159
5.1
5.1.1
5.1.2
5.1.3
5.1.4
The Basis Technology for SAP Archiving Solutions: The Archive
Development Kit 159
ADK Classification and Components 159
ADK as a Runtime Environment 160
ADK as a Development Environment 162
Data Archiving and Unicode 165
5.2
5.2.1
5.2.2
5.2.3
Tasks of the Data Archiving Administrator 168
The “Data Archiving Administrator” Role 168
Monitoring Archiving Sessions 170
Security Versus Performance 177
5.2.4
5.2.5
Data Archiving
Statistics
Reorganizing
the
Database180
After Data Archiving 183
5.3
5.3.1
5.3.2
5.3.3
5.3.4
5.3.5
Automated Production Operation 186
Periodic Archiving 187
Scheduling Data Archiving Jobs 187
Interrupting and Continuing Archiving Jobs 190
Options for Automating Dependent Processes 191
Controlling Data Archiving Jobs Using External Job Schedulers 192
5.4
5.4.1
Application-Independent Errors and Their Resolution 194
Abnormal Program Termination Behavior 194
5.4.2
Typical Pitfalls 198
6
Data Archiving in Various Components of mySAP.com
6.1
6.1.1
6.1.2
SAP R/3 Enterprise 201
Archiving in Financial Accounting (FI) 201
Archiving in Cost Accounting (CO) 214
6.2
6.2.1
CRM Server 221
The CRM Server as Part of the mySAP CRM Solution 221
6.2.2
Special Features of Data Archiving with CRM Server 223
201
Content
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
7
4/40
8/13/2019
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
Sap Press Archiving Sap Data
5/40
8/13/2019
Sap Press Archiving Sap Data
A
An Example of a Detailed Object Description for the Blueprint
Phase 307
B
Checklist for Archiving Projects 311
C
Additional Information and Services 314
C.1
Information
C.2
Services
C.3
Training 314
D
Glossary 316
E
List of Acronyms 321
F
References 322
G
The Authors 323
314
314
Index 327
Content
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
9
6/40
8/13/2019
Sap Press Archiving Sap Data
4
Accessing Archived Data
Thorsten Pferdekämper
This chapter describes the options available for accessing
archived data for the purpose of display or evaluation. The
focus of the chapter is on the use and optimization of the
Archive Information System and Document Relationship
Browser tools. The chapter is intended for administrators who
set up and use these tools.
Even after data has been archived and relocated from the database, the
system can still access it. If it were not possible to display archived data,
the archived data would have to be reloaded into the database (see also
Section 2.3.2), and as a result, the process of archiving data would be
meaningless. After all, the purpose of data archiving is to decrease the
load on the database by relocating application data that is no longer
needed, but to store the archived data in such a way that read access is
still possible at any time.
However, the archived data is no longer controlled by the database,
which means that—at least on a purely technical level—different access
concepts must be used for archived data than for data that is still in the
database (the SELECT statement cannot access archived data). Whether
or not this ultimately affects the end user, however, depends on how the
archive is accessed in each particular case.
4.1
Introduction
There are different options for accessing archived data. In general, any
Access options
archive
file that
wasexactly
created
the same
system
on of
the
same client
can be read.
What
thisinaccess
looks
like inand
terms
handling,
log,
the format in which the results are displayed, and so forth depends on the
programs that each particular application offers. The range of possibilities
can be very broad: At the low end of the spectrum, there are applications
that do not offer any special programs. In this case, the archived data can
be displayed only with the help of the Archive Information System. The
disadvantage of this method is that it is rather technical, similar to the display of data from the database in the Data Browser (transaction SE16). At
the top end of the spectrum, archive access is integrated into the applica-
Accessing Archived Data
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
125
7/40
8/13/2019
Sap Press Archiving Sap Data
tion so well that the end user cannot tell whether the displayed data originates from the database or from the archive.
In this chapter we will describe the different access concepts, using examples of archiving objects from Financial Accounting. However, the scenarios presented are not representative of every possible situation, since
hardly any archiving object actually offers every single one of the
described access options. Nevertheless, almost all archiving objects offer
at least one of the options described.
4.1.1
What Is Not Covered in This Chapter
The following terms and concepts are frequently used in connection with
access to archived data, but are only distantly related to this topic. They
are therefore not described in detail in this chapter, and are mentioned
only briefly, to set them apart from the context of archive access clearly.
4.1.1.1 Print List Storage
If, before you begin archiving, you already have a precise idea of how the
archive will be accessed later, you can carry out this type of evaluation
before archiving the data and storing the resulting print lists on suitable
media. If you then need to access the archive later, you can find the corresponding list and display it. However, you should keep in mind that you
would not actually be accessing the archive in this case. For more information on print lists, refer to Section 3.2.3.4.
4.1.1.2 Document Storage
By means of the document storage, which is often called “optical archiving,” you can store scanned original documents or other files of a business
object, such as a financial accounting document. These files can then be
linked with the corresponding objects and displayed again later. But
again, access to these documents has little to do with data archiving.
4.1.1.3 Reloading
We could say that by reloading the archived data into the database it is
possible to essentially re-create its status prior to the archiving process,
and that afterward, regular evaluations could be executed for this data.
However, as we already explained in Section 2.3.2, reloading should be
regarded as correction of an erroneous archiving procedure and not as an
option for evaluating archived data.
126
Accessing Archived Data
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
8/40
8/13/2019
Sap Press Archiving Sap Data
4.1.1.4 DART
Although DART (Data Retention Tool) was originally developed to comply
with IRS requirements regarding the evaluation of electronic data, it is
now gaining importance in Europe as well. DART permits the extraction
of tax-related data from the system and the storage of this data in simple
text files, known as flat files. The tool also contains functions for searching
for and displaying the archived data. When viewing data that was
extracted and stored with DART, it is of no importance if the source data
has been archived in the meantime. The disadvantage of using DART is
that only a narrow range of tax-related data can be accessed with it. For
more information on DART, refer to Section 1.6.2.
4.1.1.5 Financial Bookkeeping Audit Trails
As is the case with DART, files are exported during audit trails in financial
accounting. These files present a certain view of the documents in the
system. In this case, however, the documents are exclusively accounting
documents.
4.1.1.6 Accessing Stored Archive Files
In this chapter we assume that it is possible for ADK to access the archive
files, i.e., either the files are located directly in the file system or the storage is configured in such a way that ADK functions can access the file
storage medium. Please refer to Chapter 3 for more information on storing archive files.
4.2
The Fundamentals
Regardless of the type of access, the following basic steps are necessary in
order to identify and display the archived data. It is mainly in the implementation of these steps that the various access options differ.
Basic steps
1. Selecting the archive files and the business objects to be read in an
archive file
The are two different techniques for doing this:
Selection

The first involves manual selection by the user. The desired archive
files are selected within a selection screen, which is displayed by the
system, as shown in Figure 4.1.

The second technique consists of having the system determine the
archive files to be read, with no further user interaction. The choice
of files is based on an archive index, which the system searches
The Fundamentals
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
127
9/40
8/13/2019
Sap Press Archiving Sap Data
according to selection criteria entered by the user. An archive index
is a database table that contains application-specific selection fields,
such as a document number, as well as the key of the archive file in
which the relevant data can be found.
Figure 4.1 Selection screen for selecting archive files
Opening
2. Opening the archive files and reading the content
Again there are two techniques for doing this. The first possibility is to
open the archive file and read its content sequentially. The second possibility is direct access: In this case, the file pointer is positioned directly
at the place in the archive file where the business object to be read
begins. This place is called the offset.
Filtering
3. Filtering the desired data
The selection with which data is to be read from the archive does not
normally correspond to the selection that was used to start the archiving session. This means that through the selection of the archive files,
more than the desired data scope is read in the archive. The program
must therefore filter the data actually requested by the user in an additional step—even if it has already read only the relevant business
objects.
128
Accessing Archived Data
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
10/40
8/13/2019
Sap Press Archiving Sap Data
4. Displaying the desired data
There are different formats in which the data read from the archive can
be displayed. The range of options extends from a purely technical display, which corresponds to the Data Browser (transaction SE16), to a
commonly-used business display for data from the database. The first
option can be found in the Archive Information System, while the second option is found in applications that have file access fully integrated
into their display functions. In this case, the user can no longer tell if
the data originates from the archive or the database.
4.3
Preparation for
display
Sequential Read Programs
For most users dealing with data archiving, the pushbutton Read in
Archive Administration (transaction SARA) is usually the first contact with
the subject of archive access. This button is linked to programs with
which archive files selected by the user are read sequentially. These programs were especially written for the evaluation of archive files and usually operate exclusively on archived data. In most cases the data is displayed in a way that meets the needs of the end user. These programs are
particularly suitable for checking the archived data.
One example of such a sequential read program is the program
RKAARCS1, which is part of the archiving object CO_ORDER (internal
Example
orders), which is also available via the pushbutton described above. After
entering the selection criteria, you can execute the program, and the dialog box shown above (Figure 4.1) will appear for you to select the archive
files. Please note, however, that the selection criteria do not determine
which archive files are offered for selection. Regardless of the selection
criteria, all accessible files are always offered for evaluation. You should
therefore ensure that the selection of the archive files matches the selection criteria chosen. If you do not select all the relevant files, not all
desired data may be displayed. Since the program reads all files sequentially, you should not select too many archive files either, as this leads to
longer response times.
The read program now reads the selected archive files sequentially and filters the data according to the selection criteria entered. The selection criteria have very little effect on the program runtime. The determining factor is the selection of the archive files. Once you have selected the files,
the content of the archive file is usually displayed as a list. In the above
example of internal orders, you can navigate further from the created list.
However, this is rather unusual for this type of evaluation.
Sequential Read Programs
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
129
11/40
8/13/2019
Sap Press Archiving Sap Data
Background
scheduling
In addition to executing the archive read program in dialog mode, you
can also schedule it to run in the background. Scheduling essentially corresponds to the manual scheduling of a delete program. The difference is
that the read program needs a variant to transfer the selection criteria.
Programs
with
subsequently
extended archive
read function
Whereas the programs available through Archive Administration are usually dedicated archive read programs, there are also programs that were
originally developed for the regular evaluation of database data and to
which archive access functions were added at a later stage. A disadvantage of these programs is that the user must know if the data is in the
archive, and, if so, which archive file it is stored in. However, the advantage is that the data is then presented in a format familiar to the user. An
example of this are the summary reports (Report Writer reports) in Overhead Cost Controlling.
Using the Data Source pushbutton in the selection screen of this type of
program, you can specify that the data is to be read from the archive
rather than from the database (see Figure 4.2). The archive files are also
selected here.
Figure 4.2 Selection of data source in Report Writer reports
From a technical point of view, the selection of the data source (database
or archive) and archive files to be read is part of the selection screen even
though the corresponding specifications are not displayed in this screen.
This means that when a selection variant is stored, the data source is also
stored with it. This permits, for example, the creation of a variant for the
evaluation of certain archives in the background. In the list, which is displayed after the program has been executed, the user can no longer tell if
the data originated from the database or the archive.
130
Accessing Archived Data
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
12/40
8/13/2019
Sap Press Archiving Sap Data
4.4
Direct Access
Sequential reading of entire archive files with previous manual file selection is particularly useful if a large part of the data is to be read from the
archive file and the user knows which files the data is located in. This can
be the case if the content of an archive file is to be checked. For most end
users, however, those functions that require as little knowledge about
archiving as possible are most suitable—automatic file access procedures
are the best solution. Even though this approach involves more configuration and management work, it means that the end user has to do very
little.
An example of such a function is the display of financial accounting documents (transaction FB03). Using transaction FB00, you can configure
Example
this display function so that it will access the archive directly and automatically if it cannot find a document in the database. Additionally, in this
example you can even configure whether a dialog box should appear
before the archive access, asking the user if the archive should be
searched or not. If this query option is not activated, the user may not
even notice that the displayed data was already archived. The advantage
is that the user does not have to worry about determining whether the
data has already been archived before executing the transaction.
The archive index contains information about whether the document to
be displayed is archived and where in the archive it is stored. Using the
selection criteria in the corresponding program, the archive index is used
to determine the location within the archive (i.e., the archive file and the
offset) where the data is stored. The archive index is stored in database
tables specific to each application. In the present example, the database
table is ARIX_BKPF. Table 4.1 below contains a list of the fields that apply
to this example.
Field
Description
BUKRS
Company code
BELNR
Document number
GJAHR
Fiscal year
ARCHIV_KEY
Key of the archive file
OFFST
Offset of the business object
Archive index for
locating data
Table 4.1 Table ARIX_BKPF
Direct Access
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
131
13/40
8/13/2019
Sap Press Archiving Sap Data
When the document display looks for a document in the archive, it
accesses this database table first. It uses the bukrs, belnr, and gjahr fields
to determine the archive file and the offset of the business object in
which the required document is located. Reading in the archive then
takes place via direct access. The program, therefore, does not read the
entire archive file sequentially, but positions the pointer directly to the
required offset when opening the file and reads only the applicable business object. This type of archive access is much more efficient than
sequential reading of archived data if only one or a few business objects
are to be read.
Search using fields
contained in the
file index only
This method is not suitable, however, for fast access on the basis of fields
other than those contained in the file index. In our example, the archive
can be accessed via the archive index only if the user knows the company
code, document number, and fiscal year. A search using other document
fields, such as the account, is not possible since this field is not contained
in the archive index.
Building the
archive index
The archive index is built automatically during the delete phase for archiving objects that support this concept. It is also possible to build and
delete this index information manually at a later stage. This can be done
using the Index pushbutton that appears in the start screen of Archive
Administration for archiving objects that support this function.
Automatic creation during the delete phase occurs only if index creation
was activated in archiving-object-specific Customizing. This can be done
by setting the Build index indicator. However, this indicator is available
only if the archiving object supports the index function. If the Build index
indicator is set, the archive index will be built automatically during future
delete runs.
No archive index will have been built for archive files that were processed
by the delete program before this indicator was set. This is evident from
the details of the respective archive file, which you can see in archive
management. For such archive files, you can start subsequent index creation. In general, a sequential read program does not display the data read,
but merely produces an extract of it and writes the extract, together with
the archive file key and the offset, to the database table of the archive
index.
132
Accessing Archived Data
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
14/40
8/13/2019
Sap Press Archiving Sap Data
4.5
Archive Information System
Despite many advantages, the conventional access methods described so
far also have several disadvantages, which are due mainly to technical
restrictions and the application dependency of the methods:

For sequential accesses, the user must know the correct archive files.

Sequential accesses take too long if only individual documents from
the archive are to be displayed.

Direct accesses with application-specific archive indexes are not implemented in all cases.

Application-specific direct accesses work only with the fields designated by the developer.

The creation and deletion of archive indexes is application-specific. It is
true that there is a general procedure for the creation and deletion of
archive indexes in Archive Administration, but the programs that actually execute the creation and deletion are application-specific.
Disadvantages of
conventional
access methods
These disadvantages are resolved if the Archive Information System (AS) is
implemented. This tool, developed specifically for archive accesses,
allows you to configure your own archive indexes, fill them with data
from the archive, and search for archived data. As is the case with an
application-specific archive index, the archive file key and offset are also
completed here, making it possible to access archived data directly. In
addition, the Archive Information System provides a generic (not application-specific) display of all contents of a business object from the archive.
It works with all archiving objects, including user-defined objects, and
requires no application-specific programs or modifications.
Advantages of the
Archive Information System
The Archive Information System is thus the tool of choice where fast
access to archived data is concerned. However, you should pay special
attention to the term “tool” here: Because of the generic setting of the
Tool of choice for
file access
Archive Information System, application-specific special features cannot,
or can only partly, be taken into account. It is therefore a rather technical
tool, which cannot meet the needs of the end user in every aspect.
The key term in connection with the Archive Information System is the
archive information structure.1 This term effectively replaces the term
“archive index” which was introduced above. Every file access through
the Archive Information System takes place via an infostructure. Infostructures are created with the help of the Archive Retrieval Configurator,
Archive information structure
1 For better readability, we will use the short term “infostructure” from now on.
Archive Information System
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
133
15/40
8/13/2019
Sap Press Archiving Sap Data
the customizing component of the Archive Information System. As with
the archive indexes, the infostructure is filled with data either directly
during the delete phase or later, when initiated by the user. As is the case
with an archive index, the data related to an infostructure is maintained in
a database table. Another component of the Archive Information System,
the Archive Explorer supports data mining within an infostructure and permits direct accesses to the archived data and, ultimately, their display.
Field catalog
Each infostructure not only belongs uniquely to an archiving object, it
also refers explicitly to a certain field catalog. A field catalog is a collection
of fields that are suitable for indexing the archive files of the archiving
object concerned. The fields of an infostructure are always a selection of
the fields of the corresponding field catalog. In addition, the field catalog
contains a set of technical properties that are also transferred to the infostructure. Thanks to the concept of field catalogs, it is not necessary to
know the technical details of the archiving object to create an infostructure, since the details are already stored in the field catalog. To create an
infostructure, you only have to select which fields it should include.
The use of the Archive Information System and some related background
information are explained below. The individual steps are listed in the
order in which the user or administrator would normally execute them if
the Archive Information System is to be used for an archiving object for
the first time. All functions listed here can be accessed through the central management of the Archive Information System (transaction SARI).
The application help function provides more detailed information on the
Archive Information System.
4.5.1
Do not change
standard infostructures
Creating an Infostructure
Before you create your own infostructure, you should check to see
whether there is already an infostructure available that you can use to
evaluate the archived data. You can copy this infostructure and adapt it to
your own needs. However, you should not modify any infostructures provided by SAP. Such a change would be a modification of the software,
which may be undone with the next upgrade or with the installation of
support packages.
Transferring fields
134
When creating an infostructure, you determine which fields from the
archive are transferred to the infostructure. To do so, you select the
desired fields from a field catalog and transfer them to the infostructure
(see Figure 4.3). For many archiving objects, field catalogs are already
contained in the standard system. If no field catalog exists that meets
Accessing Archived Data
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
16/40
8/13/2019
Sap Press Archiving Sap Data
your needs, you can create your own. For further information on this
topic, refer to Section 4.5.6.
Figure 4.3 Creating an infostructure in the Archive Retrieval Configurator
For technical reasons, some fields from the field catalog are immediately
transferred to the infostructure and cannot be removed. These are usually
the key fields. Most field catalog fields belong to the list of selectable
fields, however, and you can transfer them to the infostructure. You can
later search for archived data using all the fields of the infostructure.
Note, however, that infostructures are stored in the database, and therefore each additional field that is transferred to the infostructure requires
additional space in the database.
4.5.2
Key fields
Activating an Infostructure
In order to be able to use an infostructure, you must activate it. Only after
an infostructure has been activated can it be filled with data from the
archive and evaluated. However, activated infostructures can no longer
be modified.
As was the case with the application-specific archive indexes, the Archive
Information System also needs a database table to store the index data.
Archive Information System
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
Database table for
index data
135
17/40
8/13/2019
Sap Press Archiving Sap Data
The database table is not predetermined. Rather, it is generated on the
basis of the information available when the infostructure is activated. The
fields of this table consist of:

The client
The fields of the infostructure
 The archive file key


The offset of the business object in the archive file
For the above example, the generated database table would look like the
one shown in Figure 4.4.
Figure 4.4 Database table for the infostructure
Reporting
program
A reporting program is also generated for evaluating this table and for
accessing the archive to display the archived data. After the database
table and the reporting program have been created, the system sets an
active indicator for the infostructure in question. This indicator means
that the infostructure can now be used for evaluation and that it should
be created automatically when the respective delete program is run.
4.5.3
Building an Infostructure
During the delete phase of data archiving, all active infostructures
belonging to an archiving object are automatically filled with data from
the respective archive file. On the basis of the defined infostructure, the
Archive Information System filters the data from the data records in the
archive and inserts it into the generated database table together with the
archive file key and the offset of the business object. These entries will
serve as a basis for subsequent searches.
Subsequent
creation
In addition to being created automatically by the delete program, an
infostructure can also be built subsequently for existing archives. Therefore, you have the option of building infostructures when required, e.g.,
136
Accessing Archived Data
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
18/40
8/13/2019
Sap Press Archiving Sap Data
when evaluating data that was already archived before the introduction
of the Archive Information System or in order to modify the fields of an
infostructure.
When an infostructure is built, the database table is filled with data from
Build status
the archive and a build status is recorded in parallel. In the status administration of the Archive Information System, you can then see which
archive files the respective infostructures were created for.
4.5.4 Evaluating an Infostructure
The search for archived data in the Archive Explorer is always done on the
basis of the reporting program that was created during the activation of
the infostructure. The selection screen of the reporting program contains
all fields of the infostructure, except for the Mandt, Archivekey, and
Archiveofs fields (see Figure 4.4). When the program is executed, you
will receive a list of all entries in the infostructure that fit your selection
criteria. Up to this point in the evaluation process, no access to the
archive has taken place; the system has only read the index data stored in
the infostructure. By double-clicking on a list entry, you can now perform
a direct access to the archive and navigate all the way down to the field
level in the data hierarchy.
Reporting
program as a basis
The view of the data shown in the Archive Explorer is very technical and
therefore less suitable for end users. The Archive Information System
makes this type of technical view available for all archiving objects. In
order to adapt the display to the needs of the end users, SAP has introduced the concept of business views. This concept means that the
archived data is shown in a form that the end user would expect to see,
or one that is familiar from the display of the corresponding data in the
database. The extent to which this type of display is supported depends
on the archiving object. Many archiving objects have no business view at
Technical views
and business
views
all in the Archive Information System, while others, such as the archiving
object CO_ORDER, are supplied with several business views. When you
double-click on an infostructure entry, you are first prompted to select
the desired view, as shown in Figure 4.5.
Generally, an infostructure has to have already been created in order for
the Archive Explorer to carry out an evaluation of the infostructure. This
means that only files with the “delete completed” status can be evaluated. This makes sense since all other data still resides in the database.
There would be no reason to search for this data in the archive.
Archive Information System
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
Ad-hoc
evaluations
137
19/40
8/13/2019
Sap Press Archiving Sap Data
Figure 4.5 Selecting a view for archived CO orders
However, you may want to simply check the archived data before the
delete phase. For this purpose, you can use the Ad-hoc evaluation function. In an ad-hoc evaluation, the system does not access the generated
database table, but rather performs a sequential read access to the
archive files you have selected. The data volume that would otherwise be
created when building an infostructure is only stored internally. The following display of data and the navigation options correspond to those of
a normal infostructure evaluation.
The evaluation of built infostructures with the Archive Explorer or
other accesses to the Archive Information System (see Section 4.6) is
particularly fast if the system can perform the access using the primary
index of the corresponding database table.
For accesses via fields other than those of the primary index, additional
database indexes may be needed. Since the tables of the Archive Information System are generated in the production system, in most cases
it is not feasible to create this type of index using the ABAP Dictionary.
Also, if the database table is re-created, the index may be deleted
again.
Database indexes
for infostructures
138
In this case, the Archive Information System offers the option of adding information about the desired database indexes to an infostructure
definition. You can also create user-defined indexes for SAP standard
infostructures by entering the index ID and the corresponding fields
into the AIND_STR8 table. For more detailed information on this
topic, refer to SAP Note 164704.
Accessing Archived Data
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
20/40
8/13/2019
Sap Press Archiving Sap Data
4.5.5 Deleting an Infostructure
Just like data in other database tables, the data stored in a generated
database table needs disk space. Therefore, it is generally advisable to
delete data for older archive files after a certain time. Since the source
data has already been archived, archiving this data is no longer pertinent.
However, you generally have the option of manually deleting the contents of infostructures. This function gives you additional flexibility to
build and empty infostructures as needed—for example, if file access is
not needed all the time.
When infostructures are created, an integration with ADK takes place.
This is not the case when infostructures are emptied, which means that
the deletion of the content must always be explicitly triggered. This must
Explicit emptying
of infostructures
be
taken
into account
particularly
when empty
reloading
archives.
When you
reload
archived
data, you
must explicitly
active
infostructures
for
the corresponding files and explicitly build infostructures for any archive
files that may have been created during the reload process.
4.5.6 Creating a Field Catalog
SAP supplies standard field catalogs for many applications. You can recognize SAP’s standard field catalogs by their name, which begins with “SAP_”.
Before you create your own field catalogs, you should always check to see
whether you can use a standard field catalog. You should never modify a
standard field catalog, not even by adding new fields. When the release is
upgraded or when support packages are installed, standard field catalogs
may be overwritten. Furthermore, some programs assume that the field
catalogs look exactly the way they did when they were delivered.
Do not modify
standard field
catalogs
You can, however, copy a standard field catalog to your own namespace
and perform the desired modifications on the copy. However, you should
bear in mind that standard programs usually ignore infostructures created
on the basis of user-defined field catalogs. As a result, you can usually use
such infostructures only in the Archive Explorer and in your own programs.
The creation of a field catalog requires expert knowledge. You must therefore know, for example, which tables are archived together with a certain
archiving object and which of these table entries makes up a business
object. You should know this information before you create a new field
catalog for an archiving object. This is particularly important for estimating the expected volume of data and for field catalogs with several source
Expert knowledge required
tables.
Archive Information System
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
139
21/40
8/13/2019
Sap Press Archiving Sap Data
Example for financial accounting
documents
The following paragraphs describe a typical procedure that can be applied
in most cases. It is necessary to differentiate between field catalogs with
one source table and those with several source tables. For more detailed
information on how to create a field catalog and on the significance of the
various fields and indicators, use the Application Help function or the F1
Help function. In the following procedure description, we assume that
you know the significance of the individual fields and that you know how
to make entries.
As an example, we will use a field catalog for financial accounting documents, which are archived by means of the FI_DOCUMNT archiving
object. This type of document includes, among other things, a document
header and several items. The document header is stored in table BKPF;
the items are in table BSEG.
4.5.6.1 Creating a Field Catalog with One Source Table
1. Selecting the source table
To build an infostructure, the Archive Information System can use any
table and any structure stored in the respective archive files. Which one
of the tables of an archiving object is used depends on the fields you
would like to use to search for archived objects. Note, however, that a
search using the fields of an item table generally requires more space in
the database than a search in a header table. This is because an item
table generally has more entries than a header table. In addition, after
an infostructure has been built, the database table generated usually
contains as many entries as are contained in the leading table of the
field catalog in the archive files.
In our example, table BKPF of the archiving object FI_DOCUMNT was
selected. It should be possible to run a search for the Document
number, Fiscal year, and Posting date fields.
2. Naming the field catalog
The name of a field catalog is subject to the same limitations as the
names of other system objects, such as database tables. You should use
only letters, numbers, and the underscore. The name should begin with
a letter, but not with the abbreviation “SAP”. It is recommended that
you use a name contained in your internal namespace.
For our example, we selected “ZDEMO_BKPF” as the name.
3. Header entry of the field catalog
Enter the name, the identification, and the archiving object of the new
field catalog. In the File in index column, enter “K” (key field), and in
the Offset in index column, enter “D” (data field).
140
Accessing Archived Data
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
22/40
8/13/2019
Sap Press Archiving Sap Data
4. Key fields of the field catalog
In most cases it is a good idea to use all the key fields of the reference
table as key fields in the field catalog, with the exception of the client.
It is recommended that you use the numbers 10, 20, 30, and so on as
field numbers. In any case, you should make sure that the key field
numbers are smaller than the data field numbers. It is also recommended that when naming fields, you use the same field names as are
used in the reference table.
Make sure that the Obligatory key field and Valid key field indicators
are not set for key fields. The Key indicator must be set for key fields.
In the example, all key fields of the table BKPF (except the client) were
transferred to the field catalog as key fields.
5. Data fields of the field catalog
In most cases, it is advisable to make all data fields of the reference
table data fields of the field catalog too. For numbering data fields, it is
recommended that you use the numbers 100, 110, 120, etc. Make
sure that the Key and Obligatory key field indicators are not set for
data fields. The Valid key field indicator should be activated for data
fields.
For data fields, it usually makes sense to transfer as many reference
table fields as possible to the field catalog. Additional data fields in a
field catalog require neither considerable storage space nor considerable runtime. However, you should transfer only fields that also function as selection criteria for programs to the field catalog. In particular,
you should not use any fields of data type FLTP (floating-point
number). You should also omit fields of the data types CURR and
QUAN, since these are generally not formatted correctly. For more
information on these data types, see SAP Note 309384.
4.5.6.2 Creating a Field Catalog with Several Source Tables
1. Selecting the source tables
For the selection of several source tables, the same procedure applies
as for the selection of one source table. It should, however, be noted
that the source tables must satisfy certain dependency conditions.
Tables that are not related to each other in any way cannot be used
together in a field catalog. In general, you should select tables that all
belong to one document, such as document header and document
item, or that can at least be linked via common fields.
Archive Information System
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
141
23/40
8/13/2019
Sap Press Archiving Sap Data
In our example for the archiving object FI_DOCUMNT, these are the
tables BKPF and BSEG.
2. Determining dependencies
It is possible to use several source tables with the Archive Information
System
only ifis the
tables are
a hierarchical
relation
dependence.
Which table
dependent
oninwhich
is defined
by keyoffields
with the
same semantics. Usually these fields have the same names in the different tables. To define a field catalog, it must be possible to arrange all
source tables in such a way that each table that depends on another
also has the same key fields as that table.
In the example of the financial accounting documents, the tables BKPF
and BSEG are linked by the Company Code, Document Number, and
Fiscal Year fields. Entries from BKPF and BSEG that are the same in
these fields belong together. The table BSEG depends on the higherlevel table BKPF and contains the key fields of the latter table as key
fields.
3. Determining the leading table
After determining the possible relationships between the tables
involved, you will notice that there is usually at least one table whose
fields are the same as the key fields of the field catalog. There may even
be several tables with this property. This is the case if there are at least
two tables that have the same number of key fields in the field catalog.
In such a case, you can select any of the eligible tables as the leading
table.
If, on the other hand, there is no table that has all the key fields of the
field catalog, you cannot create the field catalog in this way. You must
select other source tables or check the relationships between the
tables. In our example, the leading table is table BSEG.
4. Creating the field catalog for the leading table
For the time being, ignore all tables except the leading table. Create the
field catalog as described in Section 4.5.6.2. In the example, a field catalog for the source table BSEG is created first.
5. Completing the other table(s)
For all other tables, all key fields should already be in the field catalog
at this point. If this is not the case, either you made an error in determining the table dependencies or you did not select the correct table
in the last step.
Now select any one of the remaining tables and enter its key fields as
further source fields in the corresponding key field of the field catalog.
142
Accessing Archived Data
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
24/40
8/13/2019
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
Sap Press Archiving Sap Data
25/40
8/13/2019
Sap Press Archiving Sap Data
the definition of the field catalog. As already stated above, field catalogs
with several source tables must satisfy certain conditions of consistency.
For example, the source tables must be sorted so that the key fields of
each source table are a subset of the key fields of the preceding source
table in the sort sequence.
Solution
You should check to see whether the additional source fields were
entered correctly for all key fields and whether the field catalog was created according to the procedure described above. You might have to
remove a source table from the field catalog in order to ensure the consistency of the field catalog.
4.6
Archive Accesses Based on the Archive
Information System
In the section on direct access, we described an option whereby an end
user could access archived data without having to know the archiving
details and without knowing whether the data is in the archive or still in
the database. For such accesses, the system automatically determines
whether the data is in the archive and in which archive file it is stored. The
archive access is then usually carried out automatically by the system,
without the interaction of the user. The advantage of this type of access is
the consistent integration of archived data into the familiar display transaction. In the solution described above, an application-specific model for
indexing the archived data is needed.
For the Archive Information System, exactly the opposite is the case:
Archived data is indexed via a uniform procedure, but during this procedure, data cannot be sufficiently integrated into common display transactions.
Using the programming interface of the Archive Information System, it is
possible to access the data of an infostructure from a program and to use
this data as an application-specific archive index. This permits the integration of archived data into the familiar application transaction while the
disadvantage of different application-specific index solutions is avoided.
Example
An example of this type of function is the line item reports of Cost
Accounting in SAP R/3 Enterprise. Figure 4.6 shows the line item report
for internal orders (KOB1) with the line items of an archived internal
order. In this report it is no longer evident if the data originated from the
database or from the archive. There is no need for the user to know
where the data came from to display the line items.
144
Accessing Archived Data
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
26/40
8/13/2019
Sap Press Archiving Sap Data
Figure 4.6 Line item report for orders
By default, the line item reports of cost accounting do not automatically
access archived data. The need to access archived data must first be indicated to the system in the table ASACCESS01. In this table, you can specify whether the report should read exclusively from the database or
whether it should also automatically read the archived data via the
Archive Information System.
In order for the reports to find archived data using the Archive Information System, the corresponding infostructures must be built. It is important in this case that an infostructure has been activated and built for a
standard field catalog supplied by SAP.
In the example shown above, the line items were archived with the
archiving object CO_ITEM. Based on this, an infostructure is needed for
one of the field catalogs SAP_CO_ITEM_001 or SAP_CO_ITEM_002. In
the example, an infostructure was used for the SAP_CO_ITEM_001 field
catalog. The important point in this case is not the use of an infostructure
supplied by SAP, but the use of a suitable field catalog supplied by SAP.
Infostructures that were created with reference to user-defined field catalogs are ignored by the line item reports. One reason for this is the fact
that the application—in this case the line item report—assumes that certain fields with a certain significance in the field catalog exist. If customerdefined field catalogs were used, this could not be ensured with sufficient
certainty. However, in addition to the infostructure needed for the line
item reports, it is possible to use a different infostructure which refers to
another field catalog. This is not a problem for the line item report, but it
uses up additional storage space in the database.
Archive Accesses Based on the Archive Information System
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
Using the standard field catalog
145
27/40
8/13/2019
Sap Press Archiving Sap Data
This type of file access is performed in essentially the same way as the
reading of an application-specific index, with the difference that instead
of the application-specific index table, an appropriate infostructure is
read. Even though the infostructure also has a database table hidden
behind it, the fields of the table are not predetermined, but are selected
when the infostructure is configured.
Another difference between the described line item report and a direct
access—to display accounting documents (transaction FB03), for
instance—is the fact that, with the line item report, several business
objects are often read from the archive and then filtered further against
the selection criteria. To a certain extent, this is therefore an indexed
sequential access.
4.7
Data from the
archive and from
the database
The Document Relationship Browser
The Document Relationship Browser (DRB) is used to display linked business objects. Usually these are documents that were created during a
common business transaction or that are part of a common process. DRB
is not limited to a special application, but rather displays linked documents from different application areas. In addition, with DRB it is easy for
the end user to integrate other programs outside the SAP system, such as
different ALE scenarios ( Application Link Enabling).
Another strength of DRB is that it can display archived objects, although
DRB is just as effective when displaying data that has not yet been
archived. In this chapter, we would like to discuss the capabilities of DRB
with regard to archived data in particular. See SAP Note 492938 to find
out where you can get further information on DRB.
Archive Information System as
base
The file accesses made through DRB are always automatic accesses,
almost always based on the Archive Information System. It is therefore
not necessary to know if the data is in the archive. However, you can use
DRB to find out if this is the case.
DRB is a service
DRB is not an independent application, but rather a service which is
called up for a single entry object. From the applications, you can connect
to DRB for a single entry object via different transactions and reports.
Most of these functions are summarized in the “Document Relationship
Browser” (SAP_DRB) role. In addition to some simple lists for finding documents, these functions also include the document display in financial
accounting (transaction FB03) and the line item reports of overhead cost
controlling.
146
Accessing Archived Data
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
28/40
8/13/2019
Sap Press Archiving Sap Data
After entering DRB via a business object of a certain type, such as a sales
order, as shown in Figure 4.7, you can see which business objects are
linked with the entry object. The applications provide the business
objects that are directly linked with the entry object in question. What
this means in detail has been determined within the respective applications. The links between the business objects have no further semantics;
it is therefore not possible to detect whether one object is the predecessor or successor of another object. The display in DRB shows only that
there is a link between the objects.
Figure 4.7 Business objects linked with a sales order
In order to avoid a cyclic, and thus an unnecessarily complicated, display
of the linked business objects, each object is displayed only once within
the respective business process. This is also the case if an object is directly
linked to several objects. The consequence is that not all direct links are
actually shown. The display can also vary depending on the entry object
you select and the order in which you navigate through the link tree.
However, the total number of displayed objects remains the same,
regardless of the order of the individual navigation steps. In the first step
of the DRB display, only those objects that are linked directly with the
entry object are displayed. If further objects are in turn linked with these
objects, you can display them as well by navigating through the displayed
The Document Relationship Browser
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
Objects linked
more than once
are displayed
only once
147
29/40
8/13/2019
Sap Press Archiving Sap Data
link tree. In Figure 4.7, the sales order 4972 was selected as the entry
object. In the link tree, you can see all of the business objects that are
linked with this sales order.
You can call up the object display by double-clicking on an object key—
usually the document number. What this display looks like in detail
depends on the respective application and the type of business object.
The components
of DRB
DRB is divided into a general Basis core and further application-specific
components, such as Sales, Materials Management, and Accounting. The
Basis core is responsible for the display of the links shown above and for
forwarding the functions to the respective application, depending on the
type of object. The application components are responsible for determining the links and for displaying the individual business objects, among
other things.
File accesses are necessary for precisely those functions that are executed
by the application components. Therefore, it is not the Basis core of DRB
that accesses the archived data, but the respective application. The way in
which the archive access is executed and the requirements that apply in
each case thus depend on the type of business object.
However, in order for DRB to be able to access archived data, you must
select the appropriate settings in the Archive Information System for all
object types. In most cases this includes the building of infostructures for
certain standard field catalogs (“SAP_...”). A considerable part of the documentation on DRB deals with the details of these settings.
Calling up DRB
from the SAP_
DRB role
As previously mentioned, DRB is not able to independently execute all
functions for finding and displaying the linked business objects. It needs
the support of applications—for finding the entry object selected by the
user, for example. This function can be performed with the functions of
the “Document Relationship Browser” (SAP_DRB) role, already mentioned above. All functions contained in this role provide automatic
archive access.
The way in which a certain business object is displayed in the DRB view is
also application-specific. Whether an archived object is displayed differently than a corresponding object from the database also depends on the
application and the business object type.
148
Accessing Archived Data
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
30/40
8/13/2019
Sap Press Archiving Sap Data
4.7.1
Connected Object Types in Detail
This section deals with some important business object types connected
to DRB, which will be examined more closely. We will look at the prerequisites that must be fulfilled so that DRB can find and display the archived
data of these object types. Furthermore, we will discuss the links
between these object types and how they are presented in DRB. You will
find details on additional object types in the Document Relationship
Browser documentation.
Table 4.2 provides you with an overview of which SAP R/3 Enterprise
business object types are connected to DRB.
Application
Business Object Types
SAP Web Application
Server
Intermediate document (IDoc)
Workflow work items
Accounting
Settlement document
Overview
Accounting document
Direct input accounting document
Cost accounting document
Profit center document
Account statement line item
Profit and loss statement
Special ledger documents
Sales and Distribution
Customer inquiry
Customer quotation
Sales order
Customer complaints order
Customer contract
Customer scheduling agreement
Customer outline agreement
Credit memo request
Group master contract
Returns
Subsequent delivery free of charge
Customer delivery
Sales support document
Individual customer billing document
Invoice list
Table 4.2 Object types connected to DRB
The Document Relationship Browser
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
149
31/40
8/13/2019
Sap Press Archiving Sap Data
Application
Business Object Types
Materials Management
Line item invoice
Incoming invoice
Purchase requisition
Purchase order
Goods receipt
Production Planning and
Control
Production order
Production order completion confirmation
Table 4.2 Object types connected to DRB (Cont.)
Please note that not all object types listed here are connected to DRB in
the same way. For example, in the system, not every object type has a
function that calls up the respective object as an entry object in DRB.
Also, object types may appear in DRB that are not listed in the table. This
is because some functions for determining relationships are based on
generic characteristics of the relationship in question. For example, the
system always finds the source document (see Section 4.7.1.1) of an
accounting document with the same mechanism, regardless of the object
type of the source document. In this way, it is possible to find source documents even if their object type is not explicitly connected to DRB and,
as a result, does not appear in the table. In general, however, these
objects cannot be displayed if they are already archived.
4.7.1.1 Accounting Document
Source document
In Accounting, the principle of the source document applies. This means
that each business transaction visible in accounting has a document that
triggered the action—the source document. This document does not have
to be located in Accounting. If, for example, a billing document is posted
in Sales and Distribution (SD), an accounting document and a cost
accounting document (as well as additional accounting documents, if
applicable) are usually also created. The source document of this business
transaction is the billing document, even though it is not actually located
in Accounting. For the purpose of DRB, all accounting documents are
now considered linked with their source document and vice versa. In the
above example, the cost accounting document is thus not linked directly
with the accounting document, but both are linked to the billing document. Via the billing document, a two-stage relationship can then be
established between the cost accounting document and the accounting
document.
150
Accessing Archived Data
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
32/40
8/13/2019
Sap Press Archiving Sap Data
The jump from the document display to the Document Relationship
Browser was described in greater detail above. No further prerequisites
are needed, except that it must be possible to display the document in
question in the document display (transaction FB03). For archived documents, this means either that the application-specific archive index for
the archiving object FI_DOCUMNT (table ARIX_BKPF) has been built or
that an active and established infostructure for one of the field catalogs
SAP_FI_DOC_001 or SAP_FI_DOC_002 exists. Using transaction FB00,
you can then set the document display so that archived documents are
also found and displayed in DRB.
Prerequisites for
display in DRB
The “Document Relationship Browser” role (SAP_DRB) also contains
another program that can be used to enter DRB from an accounting document. You can jump to DRB by double-clicking on the desired document in the output list of this program. As with the cost accounting line
item reports described above, you can select whether the program
should read from the archive or from the database. The mechanism we
described earlier, which is controlled via the table ASACCESS01, also
works with this program; you only need to make the corresponding entry
for the program RDRBFI00.
To carry out a complete connection of archived accounting documents to
the Document Relationship Browser, you should proceed as follows:

Suppose you would like to use the program RDRBFI00, contained in
the “Document Relationship Browser” role, and you would also like to
make selections via the Posting Period (BKPF-MONTH) and Reference
(BKPF-XBLNR) fields. For this, you should use an infostructure for one
of the field catalogs SAP_FI_DOC_001 or SAP_FI_DOC_002 that also
contains the Posting Period, Posting Date, Document Type, Reference Document Number, Reference Process, Reference Key, and Logical System fields.

If you do not want to use the program RDRBFI00, you do not require
automatic file access in the program, or you do not want to select via
the mentioned fields, it is sufficient that you use the application-specific archive index (ARIX_BKPF), which the program usually builds anyway.

Set the document display in transaction FB00 so that reading from the
archive is done with the help of the archive index.
The Document Relationship Browser
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
Connecting
archived accounting documents
151
33/40
8/13/2019
Sap Press Archiving Sap Data
4.7.1.2 Cost Accounting Document
Distribution to
archives
Dealing with archived cost accounting documents in DRB is more complicated than, dealing with, say, accounting documents. This is due to the
way in which the line items are distributed in the archives. Cost accounting documents can be archived with different archiving objects, such as
CO_ITEM, PP_ORDER, CO_COSTCTR, and SD_VBAK. Another problem
is that the cost accounting documents are not archived document-bydocument. In the case of a posting in which a production order and a cost
center are involved, part of the document can be stored in a PP_ORDER
archive while the other part is still in the database. Therefore, it is not
possible to determine exactly which archive file a cost accounting document is located in, nor can it be determined whether the cost accounting
document has already been archived or not. This can be determined only
for individual document line items.
Several field
catalogs and
infostructures
Because an Archive Information System field catalog depends on the
archiving object, several field catalogs, and thus infostructures, may be
needed. For access to cost accounting documents, field catalogs for the
different archiving objects are supplied. The names of these catalogs
begin with “SAP_COBK_”. Therefore, in order to connect archived cost
accounting documents to DRB, you need an infostructure for the corresponding SAP_COBK field catalog for each archiving object with which
you archive cost accounting line items. To determine the links, these
infostructures must contain the field REFBN. Infostructures of this kind
are part of the standard SAP system delivered to the customer. Their
names also start with “SAP_COBK_”. It is usually sufficient to activate and
build up these infostructures. However, if you add the REFBT, AWTYP,
and AWORG fields to your infostructures, the program runtime will be
improved. The downside is that the infostructures then require more
storage space in the database. This has to be weighed against the runtime
advantage.
Because of the way in which cost accounting documents are archived, the
number of entries in the necessary infostructures corresponds approximately to the number of line items. However, the important things here
are the line items from archive files for which the corresponding infostructure was built. Since this type of infostructure can be very large, you
should think carefully about whether the display of archived cost
accounting documents is necessary.
With
costrespective
accountingsource
documents
(as with
accounting
documents),
only the
documents
areother
linked.
The objects
in which
152
Accessing Archived Data
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
34/40
8/13/2019
Sap Press Archiving Sap Data
the costs are collected, such as orders and cost centers, are not considered to be linked to the cost accounting document. Otherwise, several
million documents could be linked with one object, exceeding the capabilities of DRB.
4.7.1.3 Sales Order
In Sales and Distribution, a link between two documents corresponds to
the relationship that, in the document flow, is referred to as predecessor
or successor. However, the semantics of the relationship disappears in
DRB and it is no longer evident which document is the predecessor and
which is the successor. To connect archived sales orders and other sales
documents that are archived with the archiving object SD_VBAK to DRB,
all you need is an active and filled infostructure for one of the field catalogs SAP_SD_VBAK_002 or SAP_SD_VBAK_002.
For sales documents, the “Document Relationship Browser” role has a
special program that can be used to enter DRB (see Figure 4.8).
Figure 4.8 Entering DRB via sales documents
Here, in addition to the document number in the Sales Document field,
you can also use other fields as selection criteria. It is a good idea to
include these fields in the infostructure.
The Document Relationship Browser
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
153
35/40
8/13/2019
Sap Press Archiving Sap Data
Search options
Also note the three selection buttons on the selection screen, which you
can use to control where the program searches for the sales documents.



Search DB
If this option is selected, only the database is searched for the sales
documents. Archived sales documents are ignored.
Search DB and SAP AS
If you select this option, the program searches for sales documents in
the database and in the infostructures of the Archive Information System specified above. However, the archive is not accessed. Consequently, not all fields in the results list may be filled and not all desired
records may be found, because the program views any fields that are
not contained in the infostructure as empty, and does not continue to
search for the missing data.
Search DB, SAP AS and Archive
When selecting this option, the program searches for sales documents
in both the database and the infostructures of the Archive Information
System. For documents found in the infostructures, any missing data is
read from the archive. Therefore, the only documents read are the
ones that are contained in a suitable infostructure.
Known pitfalls
This selection controls only what is displayed in the results list of the program, and not the linked documents that DRB will find later. Archived
documents may therefore be displayed as linked objects in DRB, even
though the option Search in DB was selected. In many cases, only the
two options Search in DB and Search in DB, SAP AS and Archive should
be used. The Search in DB and SAP AS option may often be faster than
the latter option, but it may give confusing results because the end user
usually does not know which fields are contained in the infostructures
and what effect this has on the selection.
Display of
Unlike in accounting, in logistics DRB does not display archived docu-
archived logistics
documents
ments in the same way as documents that are still in the database. However, the display transactions for archived documents were designed to
be similar to the corresponding display transactions for documents that
still reside in the database. In addition, all the important fields are displayed. If the documents are still in the database, the usual document display transactions, such as VA03, are used.
All further logistics object types are connected to DRB in a manner similar
to sales orders. The only differences are in the case of the field catalogs
used, and in the case of those fields that can be used to make selections
154
Accessing Archived Data
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
36/40
8/13/2019
Sap Press Archiving Sap Data
and that can be integrated into the infostructures. For more information,
refer to the documentation on the application-specific components of
the Document Relationship Browser.
4.7.2
Configuring the Document Relationship Browser
Up to now, discussion of DRB concentrated mainly on how the Archive
Information System and other data archiving functions use DRB to access
archived data. The main configuration topic was the definition of infostructures. However, in addition to this main option for making settings,
there are also other options available for optimizing access to archived
data and for adapting the functions to the needs of the end user.
In this context, the following configuration options should be addressed:

Presetting the entry programs

Choosing entry list fields

Choosing object types to be displayed

Choosing fields in DRB
All settings can be user-specific. All settings, except for the setting for
choosing which object types are to be displayed, are not actually specific
to the Document Relationship Browser, but originate from the tools used
in it. However, since these settings are extremely useful for adapting DRB
to data archiving, we will now discuss and demonstrate how you can
make the access to archived data even more convenient for the user.
4.7.2.1 Presetting the Entry Programs
By default, the “Document Relationship Browser” role contains some
programs that can be used to enter DRB. However, these programs are
set up in such a way that they cannot access files. For logistics programs,
the Search in DB search option is preset. For the accounting programs,
the automatic file access is, by default, not activated in table
ASACCESS01. Below you will see how to assign these programs to a role
in such a way that automatic file access is activated.
First you must create a selection variant for each program that you want
to use. In the field characteristics of the selection variant, you can, among
other things, preset the Search in... fields and hide them. If the program
is now started with this variant, the user will not see these fields on the
selection screen anymore and the desired value is used automatically.
The Document Relationship Browser
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
Creating a selection variant
155
37/40
8/13/2019
Sap Press Archiving Sap Data
For the entry lists for accounting documents and for the line item reports
in cost accounting, you can proceed in a similar manner. However, you
cannot hide the fields for the selection of the data source here, because
no matter what, these fields do not appear on the selection screen. Nevertheless, they are stored with the variant. Of course, you can also control
the entry lists for accounting and cost accounting documents via the
ASACCESS01 table, as described above. In this case, however, performance changes for all users. If you really want to set up the system so that
the line item reports within cost center accounting automatically read
from the archive for all users, it is preferable that you make the setting via
ASACCESS01.
Assigning
selection variant
After you have created corresponding variants for all programs to be
used, you can enter these programs into a role by means of transaction
to a role
PFCG. If one of the programs to be used is called from the role to which
it was assigned, it starts automatically with the variant settings. In this
way you can set up a role containing all programs that call DRB and that
are configured to automatically access the archive. Of course, you can
also use this mechanism to preset selection criteria other than those mentioned here.
4.7.2.2 Choosing Entry List Fields
All programs contained in the “Document Relationship Browser” role
were implemented with the help of the ABAP List Viewer. Therefore,
every time a list is displayed, you can modify its layout, save the modified
layout, and set it as the default. These adjustments can be user-specific or
can be implemented as a general setting for all users.
4.7.2.3 Choosing Object Types to Be Displayed
Complex business transactions and processes are usually displayed in the
Document
Browser
in a relatively
manner.
more, givenRelationship
the vast number
of object
types thatcomplex
DRB supports
in FurtherSAP R/3
Enterprise, DRB may have runtime problems when it tries to determine the
links of these object types. This is because the program tries to resolve all
links even though the user does not generally need all object types.
Personalized
display
156
Let us assume, for example, that a user is interested in the supply chain of
a business process, but not in the accounting details. In this case, it would
make sense to simply hide the unwanted object types in the display. The
means for achieving such a selective display is personalization. Depending
on whether the settings are to apply to individual users or to a role, you
Accessing Archived Data
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
38/40
8/13/2019
Sap Press Archiving Sap Data
implement personalization either in user maintenance (transaction SU01)
or in role maintenance (transaction PFCG). Settings implemented for a
role can be automatically transferred to all users assigned to this role. In
the “Document Relationship Browser” role, the selection of the object
types is set so that all objects are displayed.
Figure 4.9 Choosing the object types to be displayed in user maintenance
When you hide certain object types, you should keep in mind that the
documents concerned are not only removed from the display, they can
also no longer be used to determine additional relationships. This means
that not only the explicitly hidden objects are excluded from the display,
but also those objects that are dependent on the hidden objects.
4.7.2.4 Choosing Fields in DRB
In the DRB navigation tree, only the type and description of an object are
displayed by default. You can extend this display by including additional
relevant fields. Apart from the technical equivalents of the object key and
the object type, two fields are of particular importance:

The Logical System field indicates which logical system the data originates from. This is relevant if cross-system processes or business trans-
The logical system and origin
fields
actions are involved.
The Document Relationship Browser
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
157
39/40
8/13/2019
Sap Press Archiving Sap Data

Regarding data archiving, the Origin field in particular is worth mentioning. It indicates whether a displayed business object is in the database or in the archive. As with the entry lists, you can control the field
selection via layouts, and store and preset user-specific layouts.
http://slidepdf.com/reader/full/sap-press-archiving-sap-data
40/40