Sap Press Archiving Sap Data

8/13/2019 Sap Press Archiving Sap Data

http://slidepdf.com/reader/full/sap-press-archiving-sap-data 1/40

Helmut Stefani (Ed.)

Archiving YourSAP

®Data

A comprehensive guide to plan andexecute archiving projects



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? 903.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 1394.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 1805.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



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 accessingarchived 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 accessconcepts 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 optionsThere are different options for accessing archived data. In general, any

archive file that was created in the same system and on the same clientcan 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-




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, sincehardly 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 mentionedonly 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 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 3.2.3.4.

4.1.1.2 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.

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.



The Fundamentals 127

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 simpletext 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 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 stepsRegardless 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.

Selection1. 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




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

objects.

Figure 4.1 Selection screen for selecting archive files



Sequential Read Programs 129

Preparation fordisplay

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.

ExampleOne 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. Afterentering 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.




Backgroundscheduling

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 withsubsequentlyextended 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 endusers, 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

little.

ExampleAn 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




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 fieldscontained 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 documentfields, such as the account, is not possible since this field is not contained

in the archive index.

Building thearchive 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

index.



Archive Information System 133

4.5 Archive Information System

Disadvantages ofconventionalaccess 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 theArchive 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 forfile 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.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. 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.




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 toknow 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 changestandard infos-

tructures

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 toyour 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




your needs, you can create your own. For further information on this

topic, refer to Section 4.5.6.

Key fieldsFor 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 forindex 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




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.

Reportingprogram

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.

Subsequentcreation

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




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.

Build statusWhen 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

Reportingprogram 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 businessviews

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 archivingobject 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.

Ad-hocevaluations

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.




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 indexesfor 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) isparticularly 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

again.

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.




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 emptyingof 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 youreload 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 modifystandard fieldcatalogs

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

tables.




Example for finan-cial 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 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.

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 itemtable 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 inthe Offset in index column, enter “D” (data field).




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

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 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.

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.




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

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 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.




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 ArchiveInformation 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 forindexing 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-

tions.

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




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 thearchive 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

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 doc-

uments, these functions also include the document display in financial

accounting (transaction FB03) and the line item reports of overhead cost

controlling.



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 linkedmore than onceare displayedonly 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 directlylinked 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




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 detaildepends on the respective application and the type of business object.

The componentsof 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 forcertain standard field catalogs (“SAP_...”). A considerable part of the doc-

umentation on DRB deals with the details of these settings.

Calling up DRBfrom 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 automaticarchive 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.




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 linksbetween these object types and how they are presented in DRB. You will

find details on additional object types in the Document Relationship

Browser documentation.

OverviewTable 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 ApplicationServer

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 requestGroup 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




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 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, theseobjects 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 docu-

ment. Via the billing document, a two-stage relationship can then be

established between the cost accounting document and the accountingdocument.

Materials Management Line item invoice

Incoming invoice

Purchase requisition

Purchase orderGoods receipt

Production Planning andControl

Production order

Production order completion confirmation

Application Business Object Types

Table 4.2 Object types connected to DRB (Cont.)




Prerequisites fordisplay 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 lineitem 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.

Connectingarchived 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 requireautomatic 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-

way.

Set the document display in transaction FB00 so that reading from the

archive is done with the help of the archive index.




4.7.1.2 Cost Accounting Document

Distribution toarchives

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 asCO_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 fieldcatalogs 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 corre-

sponding SAP_COBK field catalog for each archiving object with which

you archive cost accounting line items. To determine the links, theseinfostructures 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 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 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.

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 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




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 logisticsdocuments

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




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 DRBto 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.

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.




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

ASACCESS01.

Assigningselection 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 whichit 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.

4.7.2.2 Choosing Entry List Fields

All programs contained in the “Document Relationship Browser” rolewere 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 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.

Personalizeddisplay

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




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.

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 sys-tem and originfields

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



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.

Sap Press Archiving Sap Data

Documents

Transcript of Sap Press Archiving Sap Data