Archiving Your SAP Data - SAP PRESS

Helmut Stefani (Ed.)

Archiving Your SAP® DataA comprehensive guide to plan and

execute archiving projects

Content 5

Content

Preface 11

Acknowledgements 13

Introduction 15

1 The Fundamentals of Data Archiving 21

1.1 The mySAP.com E-Business Platform 211.1.1 The Components of mySAP.com 221.1.2 SAP Web Application Server 24

1.2 Data Archiving as a Part of mySAP Technology 271.2.1 The Benefits of Data Archiving 281.2.2 Scope of Functions 301.2.3 Purpose of Data Archiving 311.2.4 The Archive Development Kit 321.2.5 The Archiving Object 33

1.3 The Data Archiving Process 351.3.1 Accessing Archived Data 361.3.2 Storing Archive Files 41

1.4 Performance Aspects 43

1.5 Archiving Projects 441.5.1 The Right Moment 451.5.2 Data Prevention 46

1.6 Taxation Requirements Placed on Archived Data 471.6.1 Audit Information System 481.6.2 Data Retention Tool 49

2 Data Archiving Processes 51

2.1 Checking Archivability 512.1.1 Linked Application Data 532.1.2 Performing the Archivability Check 56

2.2 Main Data Archiving Processes 582.2.1 Writing Data from the Database to the Archive 602.2.2 Deleting Data from the Database 632.2.3 Storing Archive Files (optional) 66

6 Content

2.3 Other Processes and Tasks 702.3.1 Accessing Archived Data 702.3.2 Reloading Archived Data 722.3.3 Executing Preprocessing and Postprocessing Programs 74

3 Storing Archived Data 77

3.1 Criteria for Choosing a Storage Strategy 773.1.1 Security 783.1.2 Costs 823.1.3 Integration 833.1.4 Performance 843.1.5 Long-Term Storage 85

3.2 Storage on a Certified Storage System 873.2.1 Definitions: ArchiveLink, KPro, CMS 873.2.2 What is ArchiveLink? 903.2.3 Document Scenarios 1013.2.4 Interface to External Systems 1083.2.5 Storing Archive Files 1123.2.6 Known Technical Problems with Archive File Storage 1143.2.7 Accessing Archive Files 1163.2.8 Known Technical Problems Accessing Archive Files via ArchiveLink 1173.2.9 Advantages of Using ArchiveLink 117

3.3 Storage via HSM Systems 1183.3.1 What is HSM? 1183.3.2 Storing Archive Files 1203.3.3 Accessing Archive Files 1213.3.4 Typical Technical Problems 1223.3.5 Advantages of Using HSM Systems 123

3.4 Manual Storage 1233.4.1 Direct Integration 1233.4.2 Indirect Integration 1243.4.3 Advantages and Disadvantages of Manual Storage 124

3.5 Summary 124

4 Accessing Archived Data 125

4.1 Introduction 1254.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 1334.5.1 Creating an Infostructure 1344.5.2 Activating an Infostructure 1354.5.3 Building an Infostructure 1364.5.4 Evaluating an Infostructure 1374.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 1464.7.1 Connected Object Types in Detail 1494.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 1595.1.2 ADK as a Runtime Environment 1605.1.3 ADK as a Development Environment 1625.1.4 Data Archiving and Unicode 165

5.2 Tasks of the Data Archiving Administrator 1685.2.1 The “Data Archiving Administrator” Role 1685.2.2 Monitoring Archiving Sessions 1705.2.3 Security Versus Performance 1775.2.4 Data Archiving Statistics 1805.2.5 Reorganizing the Database After Data Archiving 183

5.3 Automated Production Operation 1865.3.1 Periodic Archiving 1875.3.2 Scheduling Data Archiving Jobs 1875.3.3 Interrupting and Continuing Archiving Jobs 1905.3.4 Options for Automating Dependent Processes 1915.3.5 Controlling Data Archiving Jobs Using External Job Schedulers 192

5.4 Application-Independent Errors and Their Resolution 1945.4.1 Abnormal Program Termination Behavior 1945.4.2 Typical Pitfalls 198

6 Data Archiving in Various Components of mySAP.com 201

6.1 SAP R/3 Enterprise 2016.1.1 Archiving in Financial Accounting (FI) 2016.1.2 Archiving in Cost Accounting (CO) 214

6.2 CRM Server 2216.2.1 The CRM Server as Part of the mySAP CRM Solution 2216.2.2 Special Features of Data Archiving with CRM Server 223

8 Content

6.2.3 The Relationship Between Business Objects and Archiving Objects 2256.2.4 The Three-Phase Model of Data Archiving 2276.2.5 Cross-Archiving-Object Programs for Continuous Data Archiving 2296.2.6 The CRM Business Transaction Data Model 2306.2.7 The Archiving Object CRM_ACT_ON 2316.2.8 Summary and Outlook 234

6.3 SAP Business Information Warehouse 2356.3.1 SAP BW in mySAP.com 2356.3.2 Data Archiving in SAP BW 2406.3.3 Modeling Archiving Objects 2426.3.4 The Data Archiving Process 2446.3.5 Typical Errors and How to Eliminate Them 2496.3.6 Accessing Archived Data 2496.3.7 Outlook 250

7 Planning and Managing Archiving Projects 253

7.1 Introduction 2537.1.1 Setting Up an Archiving Project Early 2547.1.2 Setting Up an Archiving Project Later 2547.1.3 Considerations Prior to Data Archiving 255

7.2 Procedures Based on ASAP Implementation Phases 255

7.3 Project Phases 2587.3.1 Project Preparation 2587.3.2 Business Blueprint: Design and Conception 2737.3.3 Realization 2817.3.4 Final Preparation 2847.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 2897.5.1 Introduction 2897.5.2 Project Preparation 2907.5.3 Business Blueprint 2927.5.4 Realization 2967.5.5 Final Preparation 2967.5.6 Go Live & Support 2977.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, thesystem 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 alsoSection 2.3.2), and as a result, the process of archiving data would bemeaningless. After all, the purpose of data archiving is to decrease theload on the database by relocating application data that is no longerneeded, but to store the archived data in such a way that read access isstill 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 thedatabase (the SELECT statement cannot access archived data). Whetheror not this ultimately affects the end user, however, depends on how thearchive is accessed in each particular case.

4.1 IntroductionAccess 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 theprograms that each particular application offers. The range of possibilitiescan be very broad: At the low end of the spectrum, there are applicationsthat do not offer any special programs. In this case, the archived data canbe displayed only with the help of the Archive Information System. Thedisadvantage 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). Atthe 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 thedescribed access options. Nevertheless, almost all archiving objects offerat 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 withaccess to archived data, but are only distantly related to this topic. Theyare 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 thearchive will be accessed later, you can carry out this type of evaluationbefore archiving the data and storing the resulting print lists on suitablemedia. 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 youwould 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 businessobject, such as a financial accounting document. These files can then belinked with the corresponding objects and displayed again later. Butagain, 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 ispossible 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 beregarded as correction of an erroneous archiving procedure and not as anoption for evaluating archived data.

The Fundamentals 127

4.1.1.4 DART

Although DART (Data Retention Tool) was originally developed to complywith IRS requirements regarding the evaluation of electronic data, it isnow gaining importance in Europe as well. DART permits the extractionof 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 searchingfor and displaying the archived data. When viewing data that wasextracted and stored with DART, it is of no importance if the source datahas been archived in the meantime. The disadvantage of using DART isthat only a narrow range of tax-related data can be accessed with it. Formore 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 financialaccounting. These files present a certain view of the documents in thesystem. In this case, however, the documents are exclusively accountingdocuments.

4.1.1.6 Accessing Stored Archive Files

In this chapter we assume that it is possible for ADK to access the archivefiles, 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 filestorage medium. Please refer to Chapter 3 for more information on stor-ing archive files.

4.2 The FundamentalsBasic 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 anarchive file The are two different techniques for doing this:

� The first involves manual selection by the user. The desired archivefiles are selected within a selection screen, which is displayed by thesystem, as shown in Figure 4.1.

� The second technique consists of having the system determine thearchive files to be read, with no further user interaction. The choiceof files is based on an archive index, which the system searches


according to selection criteria entered by the user. An archive indexis a database table that contains application-specific selection fields,such as a document number, as well as the key of the archive file inwhich the relevant data can be found.

Opening 2. Opening the archive files and reading the contentAgain there are two techniques for doing this. The first possibility is toopen the archive file and read its content sequentially. The second pos-sibility is direct access: In this case, the file pointer is positioned directlyat the place in the archive file where the business object to be readbegins. 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 notnormally 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 programmust therefore filter the data actually requested by the user in an addi-tional step—even if it has already read only the relevant businessobjects.

Figure 4.1 Selection screen for selecting archive files

Sequential Read Programs 129

Preparation for display

4. Displaying the desired data There are different formats in which the data read from the archive canbe displayed. The range of options extends from a purely technical dis-play, which corresponds to the Data Browser (transaction SE16), to acommonly-used business display for data from the database. The firstoption can be found in the Archive Information System, while the sec-ond option is found in applications that have file access fully integratedinto their display functions. In this case, the user can no longer tell ifthe data originates from the archive or the database.

4.3 Sequential Read Programs

For most users dealing with data archiving, the pushbutton Read inArchive Administration (transaction SARA) is usually the first contact withthe subject of archive access. This button is linked to programs withwhich 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 areparticularly suitable for checking the archived data.

ExampleOne example of such a sequential read program is the programRKAARCS1, which is part of the archiving object CO_ORDER (internalorders), 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 archivefiles. Please note, however, that the selection criteria do not determinewhich archive files are offered for selection. Regardless of the selectioncriteria, all accessible files are always offered for evaluation. You shouldtherefore ensure that the selection of the archive files matches the selec-tion criteria chosen. If you do not select all the relevant files, not alldesired data may be displayed. Since the program reads all files sequen-tially, you should not select too many archive files either, as this leads tolonger 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 aboveexample 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, youcan also schedule it to run in the background. Scheduling essentially cor-responds to the manual scheduling of a delete program. The difference isthat the read program needs a variant to transfer the selection criteria.

Programs withsubsequently

extended archiveread function

Whereas the programs available through Archive Administration are usu-ally dedicated archive read programs, there are also programs that wereoriginally developed for the regular evaluation of database data and towhich 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 thearchive, 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. Anexample 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 ofprogram, you can specify that the data is to be read from the archiverather than from the database (see Figure 4.2). The archive files are alsoselected here.

From a technical point of view, the selection of the data source (databaseor archive) and archive files to be read is part of the selection screen eventhough the corresponding specifications are not displayed in this screen.This means that when a selection variant is stored, the data source is alsostored with it. This permits, for example, the creation of a variant for theevaluation 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 ifthe 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 thearchive file and the user knows which files the data is located in. This canbe the case if the content of an archive file is to be checked. For most endusers, however, those functions that require as little knowledge aboutarchiving as possible are most suitable—automatic file access proceduresare the best solution. Even though this approach involves more configu-ration and management work, it means that the end user has to do verylittle.

ExampleAn example of such a function is the display of financial accounting doc-uments (transaction FB03). Using transaction FB00, you can configurethis display function so that it will access the archive directly and auto-matically if it cannot find a document in the database. Additionally, in thisexample you can even configure whether a dialog box should appearbefore the archive access, asking the user if the archive should besearched or not. If this query option is not activated, the user may noteven notice that the displayed data was already archived. The advantageis that the user does not have to worry about determining whether thedata has already been archived before executing the transaction.

Archive index for locating data

The archive index contains information about whether the document tobe displayed is archived and where in the archive it is stored. Using theselection criteria in the corresponding program, the archive index is usedto determine the location within the archive (i.e., the archive file and theoffset) where the data is stored. The archive index is stored in databasetables specific to each application. In the present example, the databasetable is ARIX_BKPF. Table 4.1 below contains a list of the fields that applyto 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, itaccesses this database table first. It uses the bukrs, belnr, and gjahr fieldsto determine the archive file and the offset of the business object inwhich the required document is located. Reading in the archive thentakes place via direct access. The program, therefore, does not read theentire archive file sequentially, but positions the pointer directly to therequired offset when opening the file and reads only the applicable busi-ness object. This type of archive access is much more efficient thansequential reading of archived data if only one or a few business objectsare to be read.

Search using fieldscontained in the

file index only

This method is not suitable, however, for fast access on the basis of fieldsother than those contained in the file index. In our example, the archivecan be accessed via the archive index only if the user knows the companycode, document number, and fiscal year. A search using other documentfields, such as the account, is not possible since this field is not containedin 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 anddelete this index information manually at a later stage. This can be doneusing the Index pushbutton that appears in the start screen of ArchiveAdministration for archiving objects that support this function.

Automatic creation during the delete phase occurs only if index creationwas activated in archiving-object-specific Customizing. This can be doneby setting the Build index indicator. However, this indicator is availableonly if the archiving object supports the index function. If the Build indexindicator is set, the archive index will be built automatically during futuredelete runs.

No archive index will have been built for archive files that were processedby the delete program before this indicator was set. This is evident fromthe details of the respective archive file, which you can see in archivemanagement. 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 withthe archive file key and the offset, to the database table of the archiveindex.

Archive Information System 133

4.5 Archive Information SystemDisadvantages of conventional access methods

Despite many advantages, the conventional access methods described sofar also have several disadvantages, which are due mainly to technicalrestrictions 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 fromthe 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 istrue that there is a general procedure for the creation and deletion ofarchive 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) isimplemented. This tool, developed specifically for archive accesses,allows you to configure your own archive indexes, fill them with datafrom the archive, and search for archived data. As is the case with anapplication-specific archive index, the archive file key and offset are alsocompleted here, making it possible to access archived data directly. Inaddition, 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, andrequires no application-specific programs or modifications.

Tool of choice for file access

The Archive Information System is thus the tool of choice where fastaccess to archived data is concerned. However, you should pay specialattention to the term “tool” here: Because of the generic setting of theArchive Information System, application-specific special features cannot,or can only partly, be taken into account. It is therefore a rather technicaltool, 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 thearchive information structure.1 This term effectively replaces the term“archive index” which was introduced above. Every file access throughthe 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 withthe archive indexes, the infostructure is filled with data either directlyduring the delete phase or later, when initiated by the user. As is the casewith an archive index, the data related to an infostructure is maintained ina 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, italso refers explicitly to a certain field catalog. A field catalog is a collectionof fields that are suitable for indexing the archive files of the archivingobject concerned. The fields of an infostructure are always a selection ofthe fields of the corresponding field catalog. In addition, the field catalogcontains 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 aninfostructure, you only have to select which fields it should include.

The use of the Archive Information System and some related backgroundinformation are explained below. The individual steps are listed in theorder in which the user or administrator would normally execute them ifthe Archive Information System is to be used for an archiving object forthe 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 theArchive Information System.

4.5.1 Creating an Infostructure

Do not changestandard infos-

tructures

Before you create your own infostructure, you should check to seewhether there is already an infostructure available that you can use toevaluate 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 ofsupport packages.

Transferring fields When creating an infostructure, you determine which fields from thearchive are transferred to the infostructure. To do so, you select thedesired fields from a field catalog and transfer them to the infostructure(see Figure 4.3). For many archiving objects, field catalogs are alreadycontained in the standard system. If no field catalog exists that meets


your needs, you can create your own. For further information on thistopic, refer to Section 4.5.6.

Key fieldsFor technical reasons, some fields from the field catalog are immediatelytransferred to the infostructure and cannot be removed. These are usuallythe key fields. Most field catalog fields belong to the list of selectablefields, however, and you can transfer them to the infostructure. You canlater 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 requiresadditional space in the database.

4.5.2 Activating an Infostructure

In order to be able to use an infostructure, you must activate it. Only afteran infostructure has been activated can it be filled with data from thearchive and evaluated. However, activated infostructures can no longerbe modified.

Database table for index data

As was the case with the application-specific archive indexes, the ArchiveInformation 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 thebasis of the information available when the infostructure is activated. Thefields 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 theone shown in Figure 4.4.

Reportingprogram

A reporting program is also generated for evaluating this table and foraccessing the archive to display the archived data. After the databasetable and the reporting program have been created, the system sets anactive indicator for the infostructure in question. This indicator meansthat the infostructure can now be used for evaluation and that it shouldbe created automatically when the respective delete program is run.

4.5.3 Building an Infostructure

During the delete phase of data archiving, all active infostructuresbelonging to an archiving object are automatically filled with data fromthe respective archive file. On the basis of the defined infostructure, theArchive Information System filters the data from the data records in thearchive and inserts it into the generated database table together with thearchive file key and the offset of the business object. These entries willserve as a basis for subsequent searches.

Subsequentcreation

In addition to being created automatically by the delete program, aninfostructure 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 introductionof the Archive Information System or in order to modify the fields of aninfostructure.

Build statusWhen an infostructure is built, the database table is filled with data fromthe archive and a build status is recorded in parallel. In the status admin-istration of the Archive Information System, you can then see whicharchive files the respective infostructures were created for.

4.5.4 Evaluating an Infostructure

Reporting program as a basis

The search for archived data in the Archive Explorer is always done on thebasis of the reporting program that was created during the activation ofthe infostructure. The selection screen of the reporting program containsall fields of the infostructure, except for the Mandt, Archivekey, andArchiveofs fields (see Figure 4.4). When the program is executed, youwill receive a list of all entries in the infostructure that fit your selectioncriteria. Up to this point in the evaluation process, no access to thearchive has taken place; the system has only read the index data stored inthe infostructure. By double-clicking on a list entry, you can now performa direct access to the archive and navigate all the way down to the fieldlevel in the data hierarchy.

Technical views and business views

The view of the data shown in the Archive Explorer is very technical andtherefore less suitable for end users. The Archive Information Systemmakes this type of technical view available for all archiving objects. Inorder to adapt the display to the needs of the end users, SAP has intro-duced the concept of business views. This concept means that thearchived 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 thedatabase. The extent to which this type of display is supported dependson the archiving object. Many archiving objects have no business view atall in the Archive Information System, while others, such as the archivingobject CO_ORDER, are supplied with several business views. When youdouble-click on an infostructure entry, you are first prompted to selectthe desired view, as shown in Figure 4.5.

Ad-hoc evaluations

Generally, an infostructure has to have already been created in order forthe Archive Explorer to carry out an evaluation of the infostructure. Thismeans 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 thedelete phase. For this purpose, you can use the Ad-hoc evaluation func-tion. In an ad-hoc evaluation, the system does not access the generateddatabase table, but rather performs a sequential read access to thearchive files you have selected. The data volume that would otherwise becreated when building an infostructure is only stored internally. The fol-lowing display of data and the navigation options correspond to those ofa 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 orother accesses to the Archive Information System (see Section 4.6) isparticularly fast if the system can perform the access using the primaryindex of the corresponding database table.

For accesses via fields other than those of the primary index, additionaldatabase indexes may be needed. Since the tables of the Archive Infor-mation System are generated in the production system, in most casesit 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 deletedagain.

In this case, the Archive Information System offers the option of add-ing information about the desired database indexes to an infostructuredefinition. You can also create user-defined indexes for SAP standardinfostructures by entering the index ID and the corresponding fieldsinto the AIND_STR8 table. For more detailed information on thistopic, refer to SAP Note 164704.


4.5.5 Deleting an Infostructure

Just like data in other database tables, the data stored in a generateddatabase table needs disk space. Therefore, it is generally advisable todelete data for older archive files after a certain time. Since the sourcedata 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 tobuild and empty infostructures as needed—for example, if file access isnot 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 thatthe deletion of the content must always be explicitly triggered. This mustbe taken into account particularly when reloading archives. When youreload archived data, you must explicitly empty active infostructures forthe corresponding files and explicitly build infostructures for any archivefiles that may have been created during the reload process.

4.5.6 Creating a Field Catalog

Do not modify standard field catalogs

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 seewhether you can use a standard field catalog. You should never modify astandard field catalog, not even by adding new fields. When the release isupgraded or when support packages are installed, standard field catalogsmay be overwritten. Furthermore, some programs assume that the fieldcatalogs look exactly the way they did when they were delivered.

You can, however, copy a standard field catalog to your own namespaceand perform the desired modifications on the copy. However, you shouldbear in mind that standard programs usually ignore infostructures createdon the basis of user-defined field catalogs. As a result, you can usually usesuch 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 certainarchiving object and which of these table entries makes up a businessobject. You should know this information before you create a new fieldcatalog for an archiving object. This is particularly important for estimat-ing the expected volume of data and for field catalogs with several sourcetables.


Example for finan-cial accounting

documents

The following paragraphs describe a typical procedure that can be appliedin most cases. It is necessary to differentiate between field catalogs withone source table and those with several source tables. For more detailedinformation on how to create a field catalog and on the significance of thevarious fields and indicators, use the Application Help function or the F1Help function. In the following procedure description, we assume thatyou know the significance of the individual fields and that you know howto 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 archivingobject. This type of document includes, among other things, a documentheader 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 tableTo build an infostructure, the Archive Information System can use anytable and any structure stored in the respective archive files. Which oneof the tables of an archiving object is used depends on the fields youwould like to use to search for archived objects. Note, however, that asearch using the fields of an item table generally requires more space inthe database than a search in a header table. This is because an itemtable generally has more entries than a header table. In addition, afteran infostructure has been built, the database table generated usuallycontains as many entries as are contained in the leading table of thefield catalog in the archive files.

In our example, table BKPF of the archiving object FI_DOCUMNT wasselected. It should be possible to run a search for the Documentnumber, Fiscal year, and Posting date fields.

2. Naming the field catalogThe name of a field catalog is subject to the same limitations as thenames of other system objects, such as database tables. You should useonly letters, numbers, and the underscore. The name should begin witha letter, but not with the abbreviation “SAP”. It is recommended thatyou use a name contained in your internal namespace.

For our example, we selected “ZDEMO_BKPF” as the name.

3. Header entry of the field catalogEnter the name, the identification, and the archiving object of the newfield 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 catalogIn most cases it is a good idea to use all the key fields of the referencetable 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 asfield numbers. In any case, you should make sure that the key fieldnumbers are smaller than the data field numbers. It is also recom-mended that when naming fields, you use the same field names as areused in the reference table.

Make sure that the Obligatory key field and Valid key field indicatorsare 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) weretransferred to the field catalog as key fields.

5. Data fields of the field catalogIn most cases, it is advisable to make all data fields of the referencetable data fields of the field catalog too. For numbering data fields, it isrecommended that you use the numbers 100, 110, 120, etc. Makesure that the Key and Obligatory key field indicators are not set fordata fields. The Valid key field indicator should be activated for datafields.

For data fields, it usually makes sense to transfer as many referencetable fields as possible to the field catalog. Additional data fields in afield 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-pointnumber). You should also omit fields of the data types CURR andQUAN, since these are generally not formatted correctly. For moreinformation on these data types, see SAP Note 309384.

4.5.6.2 Creating a Field Catalog with Several Source Tables

1. Selecting the source tablesFor the selection of several source tables, the same procedure appliesas for the selection of one source table. It should, however, be notedthat the source tables must satisfy certain dependency conditions.Tables that are not related to each other in any way cannot be usedtogether in a field catalog. In general, you should select tables that allbelong to one document, such as document header and documentitem, or that can at least be linked via common fields.


In our example for the archiving object FI_DOCUMNT, these are thetables BKPF and BSEG.

2. Determining dependenciesIt is possible to use several source tables with the Archive InformationSystem only if the tables are in a hierarchical relation of dependence.Which table is dependent on which is defined by key fields with thesame semantics. Usually these fields have the same names in the dif-ferent tables. To define a field catalog, it must be possible to arrange allsource tables in such a way that each table that depends on anotheralso has the same key fields as that table.

In the example of the financial accounting documents, the tables BKPFand BSEG are linked by the Company Code, Document Number, andFiscal Year fields. Entries from BKPF and BSEG that are the same inthese fields belong together. The table BSEG depends on the higher-level table BKPF and contains the key fields of the latter table as keyfields.

3. Determining the leading tableAfter determining the possible relationships between the tablesinvolved, you will notice that there is usually at least one table whosefields are the same as the key fields of the field catalog. There may evenbe several tables with this property. This is the case if there are at leasttwo 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 leadingtable.

If, on the other hand, there is no table that has all the key fields of thefield catalog, you cannot create the field catalog in this way. You mustselect other source tables or check the relationships between thetables. In our example, the leading table is table BSEG.

4. Creating the field catalog for the leading tableFor the time being, ignore all tables except the leading table. Create thefield 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 catalogat 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 tablein the last step.

Now select any one of the remaining tables and enter its key fields asfurther source fields in the corresponding key field of the field catalog.


For our example, this means that the BUKRS field from table BKPF isentered as an additional source field for the BUKRS field; BKPF-BUKRSis entered as an additional source field for BUKRS; and BKPF-GJAHR isentered 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 thefield catalog. When doing so, follow the same restrictions for fields inthe field catalog as for field catalogs with only one source table.

Repeat this step for each table that is to be included.

4.5.6.3 Typical Pitfalls When Creating Field Catalogs

If you create a field catalog as described above, there should be no errorsin the creation of the corresponding infostructures. Nevertheless, in somecases there may be problems which have not been discussed so far. Wewill 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, theerror message “Records not inserted in infostructure” (Q6330) mayappear. In addition to the other causes mentioned in the full text of thismessage, 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 ordid not match the structure of the archive files. The procedure describedabove is based on the assumption that the table entries which are definedby the key table given in the field catalog do not occur more than once inan archive file. Should this be the case, though, the error described willoccur when you attempt to insert the corresponding records into thegenerated database table.

SolutionThere are two possible strategies for dealing with this problem: On onehand, you can try to make the key table of the field catalog unique byadding 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 dothis, enter “K” in the column Offset in index in the header entry of thefield 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) appearsduring the delete phase or during the subsequent creation of an info-structure, the error usually does not lie in the infostructure itself, but in


the definition of the field catalog. As already stated above, field catalogswith several source tables must satisfy certain conditions of consistency.For example, the source tables must be sorted so that the key fields ofeach source table are a subset of the key fields of the preceding sourcetable in the sort sequence.

Solution You should check to see whether the additional source fields wereentered correctly for all key fields and whether the field catalog was cre-ated according to the procedure described above. You might have toremove 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 enduser could access archived data without having to know the archivingdetails and without knowing whether the data is in the archive or still inthe database. For such accesses, the system automatically determineswhether the data is in the archive and in which archive file it is stored. Thearchive access is then usually carried out automatically by the system,without the interaction of the user. The advantage of this type of access isthe 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 ispossible to access the data of an infostructure from a program and to usethis data as an application-specific archive index. This permits the integra-tion of archived data into the familiar application transaction while thedisadvantage of different application-specific index solutions is avoided.

Example An example of this type of function is the line item reports of CostAccounting in SAP R/3 Enterprise. Figure 4.6 shows the line item reportfor internal orders (KOB1) with the line items of an archived internalorder. In this report it is no longer evident if the data originated from thedatabase or from the archive. There is no need for the user to knowwhere 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 automaticallyaccess 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 orwhether it should also automatically read the archived data via theArchive 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 astandard field catalog supplied by SAP.

Using the stan-dard field catalog

In the example shown above, the line items were archived with thearchiving object CO_ITEM. Based on this, an infostructure is needed forone of the field catalogs SAP_CO_ITEM_001 or SAP_CO_ITEM_002. Inthe example, an infostructure was used for the SAP_CO_ITEM_001 fieldcatalog. The important point in this case is not the use of an infostructuresupplied 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 factthat 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 sufficientcertainty. However, in addition to the infostructure needed for the lineitem reports, it is possible to use a different infostructure which refers toanother field catalog. This is not a problem for the line item report, but ituses 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 thereading of an application-specific index, with the difference that insteadof the application-specific index table, an appropriate infostructure isread. Even though the infostructure also has a database table hiddenbehind it, the fields of the table are not predetermined, but are selectedwhen the infostructure is configured.

Another difference between the described line item report and a directaccess—to display accounting documents (transaction FB03), forinstance—is the fact that, with the line item report, several businessobjects are often read from the archive and then filtered further againstthe selection criteria. To a certain extent, this is therefore an indexedsequential access.

4.7 The Document Relationship BrowserData from the

archive and fromthe database

The Document Relationship Browser (DRB) is used to display linked busi-ness objects. Usually these are documents that were created during acommon business transaction or that are part of a common process. DRBis not limited to a special application, but rather displays linked docu-ments from different application areas. In addition, with DRB it is easy forthe end user to integrate other programs outside the SAP system, such asdifferent ALE scenarios (Application Link Enabling).

Another strength of DRB is that it can display archived objects, althoughDRB is just as effective when displaying data that has not yet beenarchived. In this chapter, we would like to discuss the capabilities of DRBwith regard to archived data in particular. See SAP Note 492938 to findout 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 thereforenot necessary to know if the data is in the archive. However, you can useDRB to find out if this is the case.

DRB is a service DRB is not an independent application, but rather a service which iscalled up for a single entry object. From the applications, you can connectto DRB for a single entry object via different transactions and reports.Most of these functions are summarized in the “Document RelationshipBrowser” (SAP_DRB) role. In addition to some simple lists for finding doc-uments, these functions also include the document display in financialaccounting (transaction FB03) and the line item reports of overhead costcontrolling.

The Document Relationship Browser 147

After entering DRB via a business object of a certain type, such as a salesorder, as shown in Figure 4.7, you can see which business objects arelinked with the entry object. The applications provide the businessobjects that are directly linked with the entry object in question. Whatthis 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 thatthere 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, displayof the linked business objects, each object is displayed only once withinthe respective business process. This is also the case if an object is directlylinked to several objects. The consequence is that not all direct links areactually shown. The display can also vary depending on the entry objectyou 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 stepof the DRB display, only those objects that are linked directly with theentry object are displayed. If further objects are in turn linked with theseobjects, 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 entryobject. In the link tree, you can see all of the business objects that arelinked 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-specificcomponents, such as Sales, Materials Management, and Accounting. TheBasis core is responsible for the display of the links shown above and forforwarding the functions to the respective application, depending on thetype of object. The application components are responsible for determin-ing the links and for displaying the individual business objects, amongother things.

File accesses are necessary for precisely those functions that are executedby the application components. Therefore, it is not the Basis core of DRBthat accesses the archived data, but the respective application. The way inwhich the archive access is executed and the requirements that apply ineach case thus depend on the type of business object.

However, in order for DRB to be able to access archived data, you mustselect the appropriate settings in the Archive Information System for allobject 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 allfunctions for finding and displaying the linked business objects. It needsthe support of applications—for finding the entry object selected by theuser, for example. This function can be performed with the functions ofthe “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 isalso application-specific. Whether an archived object is displayed differ-ently than a corresponding object from the database also depends on theapplication and the business object type.


4.7.1 Connected Object Types in Detail

This section deals with some important business object types connectedto 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 archiveddata of these object types. Furthermore, we will discuss the linksbetween these object types and how they are presented in DRB. You willfind details on additional object types in the Document RelationshipBrowser documentation.

OverviewTable 4.2 provides you with an overview of which SAP R/3 Enterprisebusiness object types are connected to DRB.

Application Business Object Types

SAP Web Application Server

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

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 inthe same way. For example, in the system, not every object type has afunction 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. Thisis because some functions for determining relationships are based ongeneric characteristics of the relationship in question. For example, thesystem always finds the source document (see Section 4.7.1.1) of anaccounting document with the same mechanism, regardless of the objecttype 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 meansthat each business transaction visible in accounting has a document thattriggered the action—the source document. This document does not haveto be located in Accounting. If, for example, a billing document is postedin Sales and Distribution (SD), an accounting document and a costaccounting document (as well as additional accounting documents, ifapplicable) are usually also created. The source document of this businesstransaction is the billing document, even though it is not actually locatedin Accounting. For the purpose of DRB, all accounting documents arenow considered linked with their source document and vice versa. In theabove example, the cost accounting document is thus not linked directlywith the accounting document, but both are linked to the billing docu-ment. Via the billing document, a two-stage relationship can then beestablished between the cost accounting document and the accountingdocument.

Materials Management Line item invoice

Incoming invoice

Purchase requisition

Purchase order

Goods receipt

Production Planning and Control

Production order

Production order completion confirmation

Application Business Object Types

Table 4.2 Object types connected to DRB (Cont.)


Prerequisites for display in DRB

The jump from the document display to the Document RelationshipBrowser was described in greater detail above. No further prerequisitesare needed, except that it must be possible to display the document inquestion in the document display (transaction FB03). For archived docu-ments, this means either that the application-specific archive index forthe archiving object FI_DOCUMNT (table ARIX_BKPF) has been built orthat an active and established infostructure for one of the field catalogsSAP_FI_DOC_001 or SAP_FI_DOC_002 exists. Using transaction FB00,you can then set the document display so that archived documents arealso found and displayed in DRB.

The “Document Relationship Browser” role (SAP_DRB) also containsanother 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 programshould read from the archive or from the database. The mechanism wedescribed earlier, which is controlled via the table ASACCESS01, alsoworks with this program; you only need to make the corresponding entryfor the program RDRBFI00.

Connecting archived account-ing documents

To carry out a complete connection of archived accounting documents tothe Document Relationship Browser, you should proceed as follows:

� Suppose you would like to use the program RDRBFI00, contained inthe “Document Relationship Browser” role, and you would also like tomake selections via the Posting Period (BKPF-MONTH) and Reference(BKPF-XBLNR) fields. For this, you should use an infostructure for oneof the field catalogs SAP_FI_DOC_001 or SAP_FI_DOC_002 that alsocontains 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 viathe 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 thearchive 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 theway 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 problemis that the cost accounting documents are not archived document-by-document. In the case of a posting in which a production order and a costcenter are involved, part of the document can be stored in a PP_ORDERarchive while the other part is still in the database. Therefore, it is notpossible to determine exactly which archive file a cost accounting docu-ment is located in, nor can it be determined whether the cost accountingdocument has already been archived or not. This can be determined onlyfor individual document line items.

Several fieldcatalogs and

infostructures

Because an Archive Information System field catalog depends on thearchiving object, several field catalogs, and thus infostructures, may beneeded. For access to cost accounting documents, field catalogs for thedifferent archiving objects are supplied. The names of these catalogsbegin with “SAP_COBK_”. Therefore, in order to connect archived costaccounting documents to DRB, you need an infostructure for the corre-sponding SAP_COBK field catalog for each archiving object with whichyou archive cost accounting line items. To determine the links, theseinfostructures must contain the field REFBN. Infostructures of this kindare part of the standard SAP system delivered to the customer. Theirnames also start with “SAP_COBK_”. It is usually sufficient to activate andbuild up these infostructures. However, if you add the REFBT, AWTYP,and AWORG fields to your infostructures, the program runtime will beimproved. The downside is that the infostructures then require morestorage space in the database. This has to be weighed against the runtimeadvantage.

Because of the way in which cost accounting documents are archived, thenumber of entries in the necessary infostructures corresponds approxi-mately to the number of line items. However, the important things hereare the line items from archive files for which the corresponding info-structure was built. Since this type of infostructure can be very large, youshould think carefully about whether the display of archived costaccounting 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, severalmillion 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 tothe relationship that, in the document flow, is referred to as predecessoror successor. However, the semantics of the relationship disappears inDRB and it is no longer evident which document is the predecessor andwhich is the successor. To connect archived sales orders and other salesdocuments 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 aspecial 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 toinclude 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 youcan use to control where the program searches for the sales documents.

� Search DBIf this option is selected, only the database is searched for the salesdocuments. Archived sales documents are ignored.

� Search DB and SAP ASIf you select this option, the program searches for sales documents inthe 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 desiredrecords may be found, because the program views any fields that arenot contained in the infostructure as empty, and does not continue tosearch for the missing data.

� Search DB, SAP AS and ArchiveWhen selecting this option, the program searches for sales documentsin both the database and the infostructures of the Archive InformationSystem. For documents found in the infostructures, any missing data isread from the archive. Therefore, the only documents read are theones 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. Archiveddocuments may therefore be displayed as linked objects in DRB, eventhough the option Search in DB was selected. In many cases, only thetwo options Search in DB and Search in DB, SAP AS and Archive shouldbe used. The Search in DB and SAP AS option may often be faster thanthe latter option, but it may give confusing results because the end userusually does not know which fields are contained in the infostructuresand what effect this has on the selection.

Display ofarchived logistics

documents

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 tobe similar to the corresponding display transactions for documents thatstill 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 similarto sales orders. The only differences are in the case of the field catalogsused, 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 ofthe Document Relationship Browser.

4.7.2 Configuring the Document Relationship Browser

Up to now, discussion of DRB concentrated mainly on how the ArchiveInformation System and other data archiving functions use DRB to accessarchived 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 archiveddata 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 forchoosing which object types are to be displayed, are not actually specificto the Document Relationship Browser, but originate from the tools usedin it. However, since these settings are extremely useful for adapting DRBto data archiving, we will now discuss and demonstrate how you canmake 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 someprograms that can be used to enter DRB. However, these programs areset 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 tableASACCESS01. Below you will see how to assign these programs to a rolein 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 wantto use. In the field characteristics of the selection variant, you can, amongother things, preset the Search in... fields and hide them. If the programis now started with this variant, the user will not see these fields on theselection screen anymore and the desired value is used automatically.


For the entry lists for accounting documents and for the line item reportsin cost accounting, you can proceed in a similar manner. However, youcannot hide the fields for the selection of the data source here, becauseno matter what, these fields do not appear on the selection screen. Nev-ertheless, they are stored with the variant. Of course, you can also controlthe entry lists for accounting and cost accounting documents via theASACCESS01 table, as described above. In this case, however, perfor-mance changes for all users. If you really want to set up the system so thatthe line item reports within cost center accounting automatically readfrom the archive for all users, it is preferable that you make the setting viaASACCESS01.

Assigningselection variant

to a role

After you have created corresponding variants for all programs to beused, you can enter these programs into a role by means of transactionPFCG. 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 thisway you can set up a role containing all programs that call DRB and thatare configured to automatically access the archive. Of course, you canalso 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 modifiedlayout, and set it as the default. These adjustments can be user-specific orcan 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 theDocument Relationship Browser in a relatively complex manner. Further-more, given the vast number of object types that DRB supports in SAP R/3Enterprise, DRB may have runtime problems when it tries to determine thelinks of these object types. This is because the program tries to resolve alllinks 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 ofa business process, but not in the accounting details. In this case, it wouldmake sense to simply hide the unwanted object types in the display. Themeans for achieving such a selective display is personalization. Dependingon 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 arole can be automatically transferred to all users assigned to this role. Inthe “Document Relationship Browser” role, the selection of the objecttypes is set so that all objects are displayed.

When you hide certain object types, you should keep in mind that thedocuments concerned are not only removed from the display, they canalso no longer be used to determine additional relationships. This meansthat 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 aredisplayed by default. You can extend this display by including additionalrelevant fields. Apart from the technical equivalents of the object key andthe object type, two fields are of particular importance:

The logical sys-tem and origin fields

� 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 fieldselection via layouts, and store and preset user-specific layouts.

Archiving Your SAP Data - SAP PRESS

Documents

Transcript of Archiving Your SAP Data - SAP PRESS