of 40

Sap Press Archiving Sap Data

Published on May 2016 | Categories: Documents | Downloads: 25 | Comments: 0



Helmut Stefani (Ed.)
Archiving Your
A comprehensive guide to plan and
execute archiving projects
Content 5
Preface 11
Acknowledgements 13
Introduction 15
1 The Fundamentals of Data Archiving 21
1.1 The mySAP.com E-Business Platform 21
1.1.1 The Components of mySAP.com 22
1.1.2 SAP Web Application Server 24
1.2 Data Archiving as a Part of mySAP Technology 27
1.2.1 The Benefits of Data Archiving 28
1.2.2 Scope of Functions 30
1.2.3 Purpose of Data Archiving 31
1.2.4 The Archive Development Kit 32
1.2.5 The Archiving Object 33
1.3 The Data Archiving Process 35
1.3.1 Accessing Archived Data 36
1.3.2 Storing Archive Files 41
1.4 Performance Aspects 43
1.5 Archiving Projects 44
1.5.1 The Right Moment 45
1.5.2 Data Prevention 46
1.6 Taxation Requirements Placed on Archived Data 47
1.6.1 Audit Information System 48
1.6.2 Data Retention Tool 49
2 Data Archiving Processes 51
2.1 Checking Archivability 51
2.1.1 Linked Application Data 53
2.1.2 Performing the Archivability Check 56
2.2 Main Data Archiving Processes 58
2.2.1 Writing Data from the Database to the Archive 60
2.2.2 Deleting Data from the Database 63
2.2.3 Storing Archive Files (optional) 66
6 Content
2.3 Other Processes and Tasks 70
2.3.1 Accessing Archived Data 70
2.3.2 Reloading Archived Data 72
2.3.3 Executing Preprocessing and Postprocessing Programs 74
3 Storing Archived Data 77
3.1 Criteria for Choosing a Storage Strategy 77
3.1.1 Security 78
3.1.2 Costs 82
3.1.3 Integration 83
3.1.4 Performance 84
3.1.5 Long-Term Storage 85
3.2 Storage on a Certified Storage System 87
3.2.1 Definitions: ArchiveLink, KPro, CMS 87
3.2.2 What is ArchiveLink? 90
3.2.3 Document Scenarios 101
3.2.4 Interface to External Systems 108
3.2.5 Storing Archive Files 112
3.2.6 Known Technical Problems with Archive File Storage 114
3.2.7 Accessing Archive Files 116
3.2.8 Known Technical Problems Accessing Archive Files via ArchiveLink 117
3.2.9 Advantages of Using ArchiveLink 117
3.3 Storage via HSM Systems 118
3.3.1 What is HSM? 118
3.3.2 Storing Archive Files 120
3.3.3 Accessing Archive Files 121
3.3.4 Typical Technical Problems 122
3.3.5 Advantages of Using HSM Systems 123
3.4 Manual Storage 123
3.4.1 Direct Integration 123
3.4.2 Indirect Integration 124
3.4.3 Advantages and Disadvantages of Manual Storage 124
3.5 Summary 124
4 Accessing Archived Data 125
4.1 Introduction 125
4.1.1 What Is Not Covered in This Chapter 126
4.2 The Fundamentals 127
4.3 Sequential Read Programs 129
4.4 Direct Access 131
Content 7
4.5 Archive Information System 133
4.5.1 Creating an Infostructure 134
4.5.2 Activating an Infostructure 135
4.5.3 Building an Infostructure 136
4.5.4 Evaluating an Infostructure 137
4.5.5 Deleting an Infostructure 139
4.5.6 Creating a Field Catalog 139
4.6 Archive Accesses Based on the Archive Information System 144
4.7 The Document Relationship Browser 146
4.7.1 Connected Object Types in Detail 149
4.7.2 Configuring the Document Relationship Browser 155
5 Technology and Administration 159
5.1 The Basis Technology for SAP Archiving Solutions: The Archive
Development Kit 159
5.1.1 ADK Classification and Components 159
5.1.2 ADK as a Runtime Environment 160
5.1.3 ADK as a Development Environment 162
5.1.4 Data Archiving and Unicode 165
5.2 Tasks of the Data Archiving Administrator 168
5.2.1 The “Data Archiving Administrator” Role 168
5.2.2 Monitoring Archiving Sessions 170
5.2.3 Security Versus Performance 177
5.2.4 Data Archiving Statistics 180
5.2.5 Reorganizing the Database After Data Archiving 183
5.3 Automated Production Operation 186
5.3.1 Periodic Archiving 187
5.3.2 Scheduling Data Archiving Jobs 187
5.3.3 Interrupting and Continuing Archiving Jobs 190
5.3.4 Options for Automating Dependent Processes 191
5.3.5 Controlling Data Archiving Jobs Using External Job Schedulers 192
5.4 Application-Independent Errors and Their Resolution 194
5.4.1 Abnormal Program Termination Behavior 194
5.4.2 Typical Pitfalls 198
6 Data Archiving in Various Components of mySAP.com 201
6.1 SAP R/3 Enterprise 201
6.1.1 Archiving in Financial Accounting (FI) 201
6.1.2 Archiving in Cost Accounting (CO) 214
6.2 CRM Server 221
6.2.1 The CRM Server as Part of the mySAP CRM Solution 221
6.2.2 Special Features of Data Archiving with CRM Server 223
8 Content
6.2.3 The Relationship Between Business Objects and Archiving Objects 225
6.2.4 The Three-Phase Model of Data Archiving 227
6.2.5 Cross-Archiving-Object Programs for Continuous Data Archiving 229
6.2.6 The CRM Business Transaction Data Model 230
6.2.7 The Archiving Object CRM_ACT_ON 231
6.2.8 Summary and Outlook 234
6.3 SAP Business Information Warehouse 235
6.3.1 SAP BW in mySAP.com 235
6.3.2 Data Archiving in SAP BW 240
6.3.3 Modeling Archiving Objects 242
6.3.4 The Data Archiving Process 244
6.3.5 Typical Errors and How to Eliminate Them 249
6.3.6 Accessing Archived Data 249
6.3.7 Outlook 250
7 Planning and Managing Archiving Projects 253
7.1 Introduction 253
7.1.1 Setting Up an Archiving Project Early 254
7.1.2 Setting Up an Archiving Project Later 254
7.1.3 Considerations Prior to Data Archiving 255
7.2 Procedures Based on ASAP Implementation Phases 255
7.3 Project Phases 258
7.3.1 Project Preparation 258
7.3.2 Business Blueprint: Design and Conception 273
7.3.3 Realization 281
7.3.4 Final Preparation 284
7.3.5 Go Live & Support 286
7.4 Quality Assurance in the Project 288
7.5 Managing an Archiving Project Using SD as an Example 289
7.5.1 Introduction 289
7.5.2 Project Preparation 290
7.5.3 Business Blueprint 292
7.5.4 Realization 296
7.5.5 Final Preparation 296
7.5.6 Go Live & Support 297
7.5.7 Example: Archiving a Sales Document 297
7.6 Critical Factors for a Successful Archiving Project 301
7.7 Choosing the Right Residence Times 302
7.8 Choosing the Right Archiving Sequence 304
Content 9
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 314
C.2 Services 314
C.3 Training 314
D Glossary 316
E List of Acronyms 321
F References 322
G The Authors 323
Index 327
Accessing Archived Data 125
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
Access options There are different options for accessing archived data. In general, any
archive file that was created in the same system and on the same client
can be read. What exactly this access looks like in terms of 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 dis-
play 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-
126 Accessing Archived Data
tion so well that the end user cannot tell whether the displayed data orig-
inates from the database or from the archive.
In this chapter we will describe the different access concepts, using exam-
ples of archiving objects from Financial Accounting. However, the scenar-
ios 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. 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 cor-
responding list and display it. However, you should keep in mind that you
would not actually be accessing the archive in this case. For more infor-
mation on print lists, refer to Section Document Storage
By means of the document storage, which is often called “optical archiv-
ing,” 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. 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.
The Fundamentals 127 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. 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. 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 stor-
age is configured in such a way that ADK functions can access the file
storage medium. Please refer to Chapter 3 for more information on stor-
ing archive files.
4.2 The Fundamentals
Basic steps 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 imple-
mentation of these steps that the various access options differ.
Selection 1. Selecting the archive files and the business objects to be read in an
archive file
The are two different techniques for doing this:
̈ 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
128 Accessing Archived 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.
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 pos-
sibility 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 archiv-
ing 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 addi-
tional step—even if it has already read only the relevant business
Figure 4.1 Selection screen for selecting archive files
Sequential Read Programs 129
Preparation for
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 dis-
play, 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 sec-
ond 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 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 pro-
grams were especially written for the evaluation of archive files and usu-
ally operate exclusively on archived data. In most cases the data is dis-
played in a way that meets the needs of the end user. These programs are
particularly suitable for checking the archived data.
Example One example of such a sequential read program is the program
RKAARCS1, which is part of the archiving object CO_ORDER (internal
orders), which is also available via the pushbutton described above. After
entering the selection criteria, you can execute the program, and the dia-
log 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 selec-
tion criteria chosen. If you do not select all the relevant files, not all
desired data may be displayed. Since the program reads all files sequen-
tially, 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 fil-
ters the data according to the selection criteria entered. The selection cri-
teria have very little effect on the program runtime. The determining fac-
tor 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.
130 Accessing Archived Data
In addition to executing the archive read program in dialog mode, you
can also schedule it to run in the background. Scheduling essentially cor-
responds 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
extended archive
read function
Whereas the programs available through Archive Administration are usu-
ally 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 disadvan-
tage 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 advan-
tage 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 Over-
head 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.
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 dis-
played after the program has been executed, the user can no longer tell if
the data originated from the database or the archive.
Figure 4.2 Selection of data source in Report Writer reports
Direct Access 131
4.4 Direct Access
Sequential reading of entire archive files with previous manual file selec-
tion 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 configu-
ration and management work, it means that the end user has to do very
Example An example of such a function is the display of financial accounting doc-
uments (transaction FB03). Using transaction FB00, you can configure
this display function so that it will access the archive directly and auto-
matically 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.
Archive index for
locating data
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
Table 4.1 Table ARIX_BKPF
132 Accessing Archived 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 busi-
ness 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 archiv-
ing 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 crea-
tion. 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
Archive Information System 133
4.5 Archive Information System
Disadvantages of
access methods
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 imple-
mented in all cases.
̈ Application-specific direct accesses work only with the fields desig-
nated 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 actu-
ally execute the creation and deletion are application-specific.
Advantages of the
Archive Informa-
tion System
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 applica-
tion-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.
Tool of choice for
file access
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
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.
Archive informa-
tion structure
The key term in connection with the Archive Information System is the
archive information structure.
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. Info-
structures are created with the help of the Archive Retrieval Configurator,
1 For better readability, we will use the short term “infostructure” from now on.
134 Accessing Archived 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 per-
mits 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 info-
structure. Thanks to the concept of field catalogs, it is not necessary to
know the technical details of the archiving object to create an infostruc-
ture, 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 cen-
tral management of the Archive Information System (transaction SARI).
The application help function provides more detailed information on the
Archive Information System.
4.5.1 Creating an Infostructure
Do not change
standard infos-
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 pro-
vided 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 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
Archive Information System 135
your needs, you can create your own. For further information on this
topic, refer to Section 4.5.6.
Key fields 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 there-
fore each additional field that is transferred to the infostructure requires
additional space in the database.
4.5.2 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.
Database table for
index data
As was the case with the application-specific archive indexes, the Archive
Information System also needs a database table to store the index data.
Figure 4.3 Creating an infostructure in the Archive Retrieval Configurator
136 Accessing Archived 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.
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.
In addition to being created automatically by the delete program, an
infostructure can also be built subsequently for existing archives. There-
fore, you have the option of building infostructures when required, e. g.,
Figure 4.4 Database table for the infostructure
Archive Information System 137
when evaluating data that was already archived before the introduction
of the Archive Information System or in order to modify the fields of an
Build status When an infostructure is built, the database table is filled with data from
the archive and a build status is recorded in parallel. In the status admin-
istration of the Archive Information System, you can then see which
archive files the respective infostructures were created for.
4.5.4 Evaluating an Infostructure
program as a basis
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.
Technical views
and business
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 intro-
duced 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
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 evalu-
ated. 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.
138 Accessing Archived Data
However, you may want to simply check the archived data before the
delete phase. For this purpose, you can use the Ad-hoc evaluation func-
tion. 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 fol-
lowing display of data and the navigation options correspond to those of
a normal infostructure evaluation.
Database indexes
for infostructures
Figure 4.5 Selecting a view for archived CO orders
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 Infor-
mation 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
In this case, the Archive Information System offers the option of add-
ing 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.
Archive Information System 139
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 con-
tents 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.
Explicit emptying
of infostructures
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
be taken into account particularly when reloading archives. When you
reload archived data, you must explicitly empty 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
Do not modify
standard field
SAP supplies standard field catalogs for many applications. You can recog-
nize 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.
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.
Expert knowl-
edge required
The creation of a field catalog requires expert knowledge. You must there-
fore 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 estimat-
ing the expected volume of data and for field catalogs with several source
140 Accessing Archived Data
Example for finan-
cial accounting
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 docu-
ments, 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. 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).
Archive Information System 141
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 recom-
mended 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
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 consider-
able runtime. However, you should transfer only fields that also func-
tion 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. 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.
142 Accessing Archived 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 if the tables are in a hierarchical relation of dependence.
Which table is dependent on which is defined by key fields with the
same semantics. Usually these fields have the same names in the dif-
ferent 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 higher-
level table BKPF and contains the key fields of the latter table as key
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
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 In the example, a field cat-
alog 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 deter-
mining 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.
Archive Information System 143
For our example, this means that the BUKRS field from table BKPF is
entered as an additional source field for the BUKRS field; BKPF-BUKRS
is entered as an additional source field for BUKRS; and BKPF-GJAHR is
entered as an additional source field for GJAHR. (There is no corre-
sponding field in table BKPF for the field BUZEI.)
Afterward, enter each of the table data fields as a new data field in the
field catalog. When doing so, follow the same restrictions for fields in
the field catalog as for field catalogs with only one source table.
Repeat this step for each table that is to be included. Typical Pitfalls When Creating Field Catalogs
If you create a field catalog as described above, there should be no errors
in the creation of the corresponding infostructures. Nevertheless, in some
cases there may be problems which have not been discussed so far. We
will address them now by describing two typical error scenarios:
Error scenario 1: “Records not inserted in infostructure”
During the delete phase or a subsequent deletion of an infostructure, the
error message “Records not inserted in infostructure” (Q6330) may
appear. In addition to the other causes mentioned in the full text of this
message, a defective field catalog may also be responsible for the error.
This is because the key table of the field catalog was not fully defined or
did not match the structure of the archive files. The procedure described
above is based on the assumption that the table entries which are defined
by the key table given in the field catalog do not occur more than once in
an archive file. Should this be the case, though, the error described will
occur when you attempt to insert the corresponding records into the
generated database table.
Solution There are two possible strategies for dealing with this problem: On one
hand, you can try to make the key table of the field catalog unique by
adding further key fields. On the other hand, you can designate the busi-
ness object itself—the offset in the archive file—as the key field. To do
this, enter “K” in the column Offset in index in the header entry of the
field catalog. The offset then becomes the key field of the generated data-
base table.
Error scenario 2: “Infostructure is inconsistent”
If, however, the message “Infostructure is inconsistent” (Q6234) appears
during the delete phase or during the subsequent creation of an info-
structure, the error usually does not lie in the infostructure itself, but in
144 Accessing Archived 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 cre-
ated according to the procedure described above. You might have to
remove a source table from the field catalog in order to ensure the con-
sistency 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 trans-
action. 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 proce-
dure, data cannot be sufficiently integrated into common display transac-
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 integra-
tion 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.
Archive Accesses Based on the Archive Information System 145
By default, the line item reports of cost accounting do not automatically
access archived data. The need to access archived data must first be indi-
cated to the system in the table ASACCESS01. In this table, you can spec-
ify 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 Informa-
tion System, the corresponding infostructures must be built. It is impor-
tant in this case that an infostructure has been activated and built for a
standard field catalog supplied by SAP.
Using the stan-
dard field catalog
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 cat-
alogs 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 cer-
tain fields with a certain significance in the field catalog exist. If customer-
defined 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.
Figure 4.6 Line item report for orders
146 Accessing Archived 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 The Document Relationship Browser
Data from the
archive and from
the database
The Document Relationship Browser (DRB) is used to display linked busi-
ness 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 docu-
ments 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 Informa-
tion System as
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 doc-
uments, these functions also include the document display in financial
accounting (transaction FB03) and the line item reports of overhead cost
The Document Relationship Browser 147
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 applica-
tions. The links between the business objects have no further semantics;
it is therefore not possible to detect whether one object is the predeces-
sor or successor of another object. The display in DRB shows only that
there is a link between the objects.
Objects linked
more than once
are displayed
only once
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
Figure 4.7 Business objects linked with a sales order
148 Accessing Archived 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 determin-
ing 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 doc-
umentation 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 men-
tioned 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 differ-
ently than a corresponding object from the database also depends on the
application and the business object type.
The Document Relationship Browser 149
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 prereq-
uisites 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.
Overview 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
Intermediate document (IDoc)
Workflow work items
Accounting Settlement document
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
Subsequent delivery free of charge
Customer delivery
Sales support document
Individual customer billing document
Invoice list
Table 4.2 Object types connected to DRB
150 Accessing Archived Data
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 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 doc-
uments 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. 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 docu-
ment. Via the billing document, a two-stage relationship can then be
established between the cost accounting document and the accounting
Materials Management Line item invoice
Incoming invoice
Purchase requisition
Purchase order
Goods receipt
Production Planning and
Production order
Production order completion confirmation
Application Business Object Types
Table 4.2 Object types connected to DRB (Cont.)
The Document Relationship Browser 151
Prerequisites for
display in DRB
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 docu-
ments, 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.
The “Document Relationship Browser” role (SAP_DRB) also contains
another program that can be used to enter DRB from an accounting doc-
ument. You can jump to DRB by double-clicking on the desired docu-
ment 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.
archived account-
ing documents
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, Refer-
ence Document Number, Reference Process, Reference Key, and Log-
ical 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-spe-
cific archive index (ARIX_BKPF), which the program usually builds any-
̈ Set the document display in transaction FB00 so that reading from the
archive is done with the help of the archive index.
152 Accessing Archived Data Cost Accounting Document
Distribution to
Dealing with archived cost accounting documents in DRB is more compli-
cated than, dealing with, say, accounting documents. This is due to the
way in which the line items are distributed in the archives. Cost account-
ing 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-by-
document. 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 docu-
ment 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
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 corre-
sponding 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
Because of the way in which cost accounting documents are archived, the
number of entries in the necessary infostructures corresponds approxi-
mately to the number of line items. However, the important things here
are the line items from archive files for which the corresponding info-
structure 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 cost accounting documents (as with other accounting documents),
only the respective source documents are linked. The objects in which
The Document Relationship Browser 153
the costs are collected, such as orders and cost centers, are not consid-
ered to be linked to the cost accounting document. Otherwise, several
million documents could be linked with one object, exceeding the capa-
bilities of DRB. 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 cata-
logs 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).
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.
Figure 4.8 Entering DRB via sales documents
154 Accessing Archived 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 Sys-
tem specified above. However, the archive is not accessed. Conse-
quently, 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 pro-
gram, 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
archived logistics
Unlike in accounting, in logistics DRB does not display archived docu-
ments in the same way as documents that are still in the database. How-
ever, 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 dis-
played. If the documents are still in the database, the usual document dis-
play 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
The Document Relationship Browser 155
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 info-
structures. 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. 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.
Creating a selec-
tion variant
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.
156 Accessing Archived 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. Nev-
ertheless, 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, perfor-
mance 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
selection variant
to a role
After you have created corresponding variants for all programs to be
used, you can enter these programs into a role by means of transaction
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 men-
tioned here. 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. Choosing Object Types to Be Displayed
Complex business transactions and processes are usually displayed in the
Document Relationship Browser in a relatively complex manner. Further-
more, given the vast number of object types that DRB supports in SAP 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.
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
The Document Relationship Browser 157
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.
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. 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 sys-
tem and origin
̈ The Logical System field indicates which logical system the data origi-
nates from. This is relevant if cross-system processes or business trans-
actions are involved.
Figure 4.9 Choosing the object types to be displayed in user maintenance
158 Accessing Archived Data
̈ Regarding data archiving, the Origin field in particular is worth men-
tioning. It indicates whether a displayed business object is in the data-
base or in the archive. As with the entry lists, you can control the field
selection via layouts, and store and preset user-specific layouts.

Sponsor Documents


No recommend documents

Or use your account on DocShare.tips


Forgot your password?

Or register your new account on DocShare.tips


Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in