Sap Press Archiving Sap Data

Helmut Stefani (Ed.)

Archiving Your ® SAP Data A comprehensive guide to plan and execute archiving projects

Content Preface

11

Acknowledgements

Introduction

13

15

1

The Fundamentals of Data Archiving

21

1.1 1.1.1 1.1.2

The mySAP.com E-Business Platform The Components of mySAP.com 22 SAP Web Application Server 24

1.2 1.2.1 1.2.2 1.2.3 1.2.4 1.2.5

Data Archiving as a Part of mySAP Technology The Benefits of Data Archiving 28 Scope of Functions 30 Purpose of Data Archiving 31 The Archive Development Kit 32 The Archiving Object 33

1.3 1.3.1 1.3.2

The Data Archiving Process 35 Accessing Archived Data 36 Storing Archive Files 41

1.4

Performance Aspects

1.5 1.5.1 1.5.2

Archiving Projects 44 The Right Moment 45 Data Prevention 46

1.6 1.6.1 1.6.2

Taxation Requirements Placed on Archived Data Audit Information System 48 Data Retention Tool 49

2

Data Archiving Processes

2.1 2.1.1 2.1.2

Checking Archivability 51 Linked Application Data 53 Performing the Archivability Check

2.2 2.2.1 2.2.2 2.2.3

Main Data Archiving Processes 58 Writing Data from the Database to the Archive Deleting Data from the Database 63 Storing Archive Files (optional) 66

21

27

43

47

51

56 60

Content

5

6

2.3 2.3.1 2.3.2 2.3.3

Other Processes and Tasks 70 Accessing Archived Data 70 Reloading Archived Data 72 Executing Preprocessing and Postprocessing Programs

3

Storing Archived Data

3.1 3.1.1 3.1.2 3.1.3 3.1.4 3.1.5

Criteria for Choosing a Storage Strategy Security 78 Costs 82 Integration 83 Performance 84 Long-Term Storage 85

3.2 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6 3.2.7 3.2.8 3.2.9

Storage on a Certified Storage System 87 Definitions: ArchiveLink, KPro, CMS 87 What is ArchiveLink? 90 Document Scenarios 101 Interface to External Systems 108 Storing Archive Files 112 Known Technical Problems with Archive File Storage 114 Accessing Archive Files 116 Known Technical Problems Accessing Archive Files via ArchiveLink Advantages of Using ArchiveLink 117

3.3 3.3.1 3.3.2 3.3.3 3.3.4 3.3.5

Storage via HSM Systems 118 What is HSM? 118 Storing Archive Files 120 Accessing Archive Files 121 Typical Technical Problems 122 Advantages of Using HSM Systems

3.4 3.4.1 3.4.2 3.4.3

Manual Storage 123 Direct Integration 123 Indirect Integration 124 Advantages and Disadvantages of Manual Storage

3.5

Summary

4

Accessing Archived Data

4.1 4.1.1

Introduction 125 What Is Not Covered in This Chapter

4.2

The Fundamentals

4.3

Sequential Read Programs

4.4

Direct Access

Content

77

125

127 129

77

123

124

131

74

126

124

117

4.5 4.5.1 4.5.2 4.5.3 4.5.4 4.5.5 4.5.6

Archive Information System 133 Creating an Infostructure 134 Activating an Infostructure 135 Building an Infostructure 136 Evaluating an Infostructure 137 Deleting an Infostructure 139 Creating a Field Catalog 139

4.6

Archive Accesses Based on the Archive Information System

4.7 4.7.1 4.7.2

The Document Relationship Browser 146 Connected Object Types in Detail 149 Configuring the Document Relationship Browser

5

Technology and Administration

5.1 5.1.1 5.1.2 5.1.3 5.1.4

The Basis Technology for SAP Archiving Solutions: The Archive Development Kit 159 ADK Classification and Components 159 ADK as a Runtime Environment 160 ADK as a Development Environment 162 Data Archiving and Unicode 165

5.2 5.2.1 5.2.2 5.2.3 5.2.4 5.2.5

Tasks of the Data Archiving Administrator 168 The “Data Archiving Administrator” Role 168 Monitoring Archiving Sessions 170 Security Versus Performance 177 Data Archiving Statistics 180 Reorganizing the Database After Data Archiving 183

5.3 5.3.1 5.3.2 5.3.3 5.3.4 5.3.5

Automated Production Operation 186 Periodic Archiving 187 Scheduling Data Archiving Jobs 187 Interrupting and Continuing Archiving Jobs 190 Options for Automating Dependent Processes 191 Controlling Data Archiving Jobs Using External Job Schedulers

5.4 5.4.1 5.4.2

Application-Independent Errors and Their Resolution Abnormal Program Termination Behavior 194 Typical Pitfalls 198

6

Data Archiving in Various Components of mySAP.com

6.1 6.1.1 6.1.2

SAP R/3 Enterprise 201 Archiving in Financial Accounting (FI) 201 Archiving in Cost Accounting (CO) 214

6.2 6.2.1 6.2.2

CRM Server 221 The CRM Server as Part of the mySAP CRM Solution 221 Special Features of Data Archiving with CRM Server 223

144

155

159

192

194

201

Content

7

8

6.2.3 6.2.4 6.2.5 6.2.6 6.2.7 6.2.8

The Relationship Between Business Objects and Archiving Objects 225 The Three-Phase Model of Data Archiving 227 Cross-Archiving-Object Programs for Continuous Data Archiving 229 The CRM Business Transaction Data Model 230 The Archiving Object CRM_ACT_ON 231 Summary and Outlook 234

6.3 6.3.1 6.3.2 6.3.3 6.3.4 6.3.5 6.3.6 6.3.7

SAP Business Information Warehouse 235 SAP BW in mySAP.com 235 Data Archiving in SAP BW 240 Modeling Archiving Objects 242 The Data Archiving Process 244 Typical Errors and How to Eliminate Them 249 Accessing Archived Data 249 Outlook 250

7

Planning and Managing Archiving Projects

7.1 7.1.1 7.1.2 7.1.3

Introduction 253 Setting Up an Archiving Project Early 254 Setting Up an Archiving Project Later 254 Considerations Prior to Data Archiving 255

7.2

Procedures Based on ASAP Implementation Phases

7.3 7.3.1 7.3.2 7.3.3 7.3.4 7.3.5

Project Phases 258 Project Preparation 258 Business Blueprint: Design and Conception Realization 281 Final Preparation 284 Go Live & Support 286

7.4

Quality Assurance in the Project

7.5 7.5.1 7.5.2 7.5.3 7.5.4 7.5.5 7.5.6 7.5.7

Managing an Archiving Project Using SD as an Example Introduction 289 Project Preparation 290 Business Blueprint 292 Realization 296 Final Preparation 296 Go Live & Support 297 Example: Archiving a Sales Document 297

7.6

Critical Factors for a Successful Archiving Project

255

273

288

7.7

Choosing the Right Residence Times

7.8

Choosing the Right Archiving Sequence

Content

253

302 304

301

289

A

An Example of a Detailed Object Description for the Blueprint Phase 307

B

Checklist for Archiving Projects

C

Additional Information and Services

C.1

Information

C.2

Services

314

C.3

Training

314

D

Glossary

E

List of Acronyms

F

References

G

The Authors

Index

311

314

314

316

321

322

323

327

Content

9

4

Accessing Archived Data Thorsten Pferdekämper This chapter describes the options available for accessing archived data for the purpose of display or evaluation. The focus of the chapter is on the use and optimization of the Archive Information System and Document Relationship Browser tools. The chapter is intended for administrators who set up and use these tools.

Even after data has been archived and relocated from the database, the system can still access it. If it were not possible to display archived data, the archived data would have to be reloaded into the database (see also Section 2.3.2), and as a result, the process of archiving data would be meaningless. After all, the purpose of data archiving is to decrease the load on the database by relocating application data that is no longer needed, but to store the archived data in such a way that read access is still possible at any time. However, the archived data is no longer controlled by the database, which means that—at least on a purely technical level—different access concepts must be used for archived data than for data that is still in the database (the SELECT statement cannot access archived data). Whether or not this ultimately affects the end user, however, depends on how the archive is accessed in each particular case.

4.1

Introduction

There are different options for accessing archived data. In general, any archive file that was created in the same system and on the same client can be read. What exactly this access looks like in terms of handling, log, the format in which the results are displayed, and so forth depends on the programs that each particular application offers. The range of possibilities can be very broad: At the low end of the spectrum, there are applications that do not offer any special programs. In this case, the archived data can be displayed only with the help of the Archive Information System. The disadvantage of this method is that it is rather technical, similar to the display of data from the database in the Data Browser (transaction SE16). At the top end of the spectrum, archive access is integrated into the applica-

Accessing Archived Data

Access options

125

tion so well that the end user cannot tell whether the displayed data originates from the database or from the archive. In this chapter we will describe the different access concepts, using examples of archiving objects from Financial Accounting. However, the scenarios presented are not representative of every possible situation, since hardly any archiving object actually offers every single one of the described access options. Nevertheless, almost all archiving objects offer at least one of the options described.

4.1.1

What Is Not Covered in This Chapter

The following terms and concepts are frequently used in connection with access to archived data, but are only distantly related to this topic. They are therefore not described in detail in this chapter, and are mentioned only briefly, to set them apart from the context of archive access clearly. 4.1.1.1 Print List Storage If, before you begin archiving, you already have a precise idea of how the archive will be accessed later, you can carry out this type of evaluation before archiving the data and storing the resulting print lists on suitable media. If you then need to access the archive later, you can find the corresponding list and display it. However, you should keep in mind that you would not actually be accessing the archive in this case. For more information on print lists, refer to Section 3.2.3.4. 4.1.1.2 Document Storage By means of the document storage, which is often called “optical archiving,” you can store scanned original documents or other files of a business object, such as a financial accounting document. These files can then be linked with the corresponding objects and displayed again later. But again, access to these documents has little to do with data archiving. 4.1.1.3 Reloading We could say that by reloading the archived data into the database it is possible to essentially re-create its status prior to the archiving process, and that afterward, regular evaluations could be executed for this data. However, as we already explained in Section 2.3.2, reloading should be regarded as correction of an erroneous archiving procedure and not as an option for evaluating archived data.

126

Accessing Archived Data

4.1.1.4 DART Although DART (Data Retention Tool) was originally developed to comply with IRS requirements regarding the evaluation of electronic data, it is now gaining importance in Europe as well. DART permits the extraction of tax-related data from the system and the storage of this data in simple text files, known as flat files. The tool also contains functions for searching for and displaying the archived data. When viewing data that was extracted and stored with DART, it is of no importance if the source data has been archived in the meantime. The disadvantage of using DART is that only a narrow range of tax-related data can be accessed with it. For more information on DART, refer to Section 1.6.2. 4.1.1.5 Financial Bookkeeping Audit Trails As is the case with DART, files are exported during audit trails in financial accounting. These files present a certain view of the documents in the system. In this case, however, the documents are exclusively accounting documents. 4.1.1.6 Accessing Stored Archive Files In this chapter we assume that it is possible for ADK to access the archive files, i.e., either the files are located directly in the file system or the storage is configured in such a way that ADK functions can access the file storage medium. Please refer to Chapter 3 for more information on storing archive files.

4.2

The Fundamentals

Regardless of the type of access, the following basic steps are necessary in order to identify and display the archived data. It is mainly in the implementation of these steps that the various access options differ.

Basic steps

1. Selecting the archive files and the business objects to be read in an archive file The are two different techniques for doing this:

Selection

왘 The first involves manual selection by the user. The desired archive

files are selected within a selection screen, which is displayed by the system, as shown in Figure 4.1. 왘 The second technique consists of having the system determine the

archive files to be read, with no further user interaction. The choice of files is based on an archive index, which the system searches

The Fundamentals

127

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

Figure 4.1 Selection screen for selecting archive files Opening

2. Opening the archive files and reading the content Again there are two techniques for doing this. The first possibility is to open the archive file and read its content sequentially. The second possibility is direct access: In this case, the file pointer is positioned directly at the place in the archive file where the business object to be read begins. This place is called the offset.

Filtering

3. Filtering the desired data The selection with which data is to be read from the archive does not normally correspond to the selection that was used to start the archiving session. This means that through the selection of the archive files, more than the desired data scope is read in the archive. The program must therefore filter the data actually requested by the user in an additional step—even if it has already read only the relevant business objects.

128

Accessing Archived Data

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

4.3

Preparation for display

Sequential Read Programs

For most users dealing with data archiving, the pushbutton Read in Archive Administration (transaction SARA) is usually the first contact with the subject of archive access. This button is linked to programs with which archive files selected by the user are read sequentially. These programs were especially written for the evaluation of archive files and usually operate exclusively on archived data. In most cases the data is displayed in a way that meets the needs of the end user. These programs are particularly suitable for checking the archived data. One example of such a sequential read program is the program RKAARCS1, which is part of the archiving object CO_ORDER (internal orders), which is also available via the pushbutton described above. After entering the selection criteria, you can execute the program, and the dialog box shown above (Figure 4.1) will appear for you to select the archive files. Please note, however, that the selection criteria do not determine which archive files are offered for selection. Regardless of the selection criteria, all accessible files are always offered for evaluation. You should therefore ensure that the selection of the archive files matches the selection criteria chosen. If you do not select all the relevant files, not all desired data may be displayed. Since the program reads all files sequentially, you should not select too many archive files either, as this leads to longer response times.

Example

The read program now reads the selected archive files sequentially and filters the data according to the selection criteria entered. The selection criteria have very little effect on the program runtime. The determining factor is the selection of the archive files. Once you have selected the files, the content of the archive file is usually displayed as a list. In the above example of internal orders, you can navigate further from the created list. However, this is rather unusual for this type of evaluation.

Sequential Read Programs

129

Background scheduling

In addition to executing the archive read program in dialog mode, you can also schedule it to run in the background. Scheduling essentially corresponds to the manual scheduling of a delete program. The difference is that the read program needs a variant to transfer the selection criteria.

Programs with subsequently extended archive read function

Whereas the programs available through Archive Administration are usually dedicated archive read programs, there are also programs that were originally developed for the regular evaluation of database data and to which archive access functions were added at a later stage. A disadvantage of these programs is that the user must know if the data is in the archive, and, if so, which archive file it is stored in. However, the advantage is that the data is then presented in a format familiar to the user. An example of this are the summary reports (Report Writer reports) in Overhead Cost Controlling. Using the Data Source pushbutton in the selection screen of this type of program, you can specify that the data is to be read from the archive rather than from the database (see Figure 4.2). The archive files are also selected here.

Figure 4.2 Selection of data source in Report Writer reports

From a technical point of view, the selection of the data source (database or archive) and archive files to be read is part of the selection screen even though the corresponding specifications are not displayed in this screen. This means that when a selection variant is stored, the data source is also stored with it. This permits, for example, the creation of a variant for the evaluation of certain archives in the background. In the list, which is displayed after the program has been executed, the user can no longer tell if the data originated from the database or the archive.

130

Accessing Archived Data

4.4

Direct Access

Sequential reading of entire archive files with previous manual file selection is particularly useful if a large part of the data is to be read from the archive file and the user knows which files the data is located in. This can be the case if the content of an archive file is to be checked. For most end users, however, those functions that require as little knowledge about archiving as possible are most suitable—automatic file access procedures are the best solution. Even though this approach involves more configuration and management work, it means that the end user has to do very little. An example of such a function is the display of financial accounting documents (transaction FB03). Using transaction FB00, you can configure this display function so that it will access the archive directly and automatically if it cannot find a document in the database. Additionally, in this example you can even configure whether a dialog box should appear before the archive access, asking the user if the archive should be searched or not. If this query option is not activated, the user may not even notice that the displayed data was already archived. The advantage is that the user does not have to worry about determining whether the data has already been archived before executing the transaction.

Example

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.

Archive index for locating data

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

Direct Access

131

When the document display looks for a document in the archive, it accesses this database table first. It uses the bukrs, belnr, and gjahr fields to determine the archive file and the offset of the business object in which the required document is located. Reading in the archive then takes place via direct access. The program, therefore, does not read the entire archive file sequentially, but positions the pointer directly to the required offset when opening the file and reads only the applicable business object. This type of archive access is much more efficient than sequential reading of archived data if only one or a few business objects are to be read. Search using fields contained in the file index only

This method is not suitable, however, for fast access on the basis of fields other than those contained in the file index. In our example, the archive can be accessed via the archive index only if the user knows the company code, document number, and fiscal year. A search using other document fields, such as the account, is not possible since this field is not contained in the archive index.

Building the archive index

The archive index is built automatically during the delete phase for archiving objects that support this concept. It is also possible to build and delete this index information manually at a later stage. This can be done using the Index pushbutton that appears in the start screen of Archive Administration for archiving objects that support this function. Automatic creation during the delete phase occurs only if index creation was activated in archiving-object-specific Customizing. This can be done by setting the Build index indicator. However, this indicator is available only if the archiving object supports the index function. If the Build index indicator is set, the archive index will be built automatically during future delete runs. No archive index will have been built for archive files that were processed by the delete program before this indicator was set. This is evident from the details of the respective archive file, which you can see in archive management. For such archive files, you can start subsequent index creation. In general, a sequential read program does not display the data read, but merely produces an extract of it and writes the extract, together with the archive file key and the offset, to the database table of the archive index.

132

Accessing Archived Data

4.5

Archive Information System

Despite many advantages, the conventional access methods described so far also have several disadvantages, which are due mainly to technical restrictions and the application dependency of the methods:

Disadvantages of conventional access 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 actually execute the creation and deletion are application-specific. These disadvantages are resolved if the Archive Information System (AS) is implemented. This tool, developed specifically for archive accesses, allows you to configure your own archive indexes, fill them with data from the archive, and search for archived data. As is the case with an application-specific archive index, the archive file key and offset are also completed here, making it possible to access archived data directly. In addition, the Archive Information System provides a generic (not application-specific) display of all contents of a business object from the archive. It works with all archiving objects, including user-defined objects, and requires no application-specific programs or modifications.

Advantages of the Archive Information System

The Archive Information System is thus the tool of choice where fast access to archived data is concerned. However, you should pay special attention to the term “tool” here: Because of the generic setting of the 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.

Tool of choice for file access

The key term in connection with the Archive Information System is the archive information structure.1 This term effectively replaces the term “archive index” which was introduced above. Every file access through the Archive Information System takes place via an infostructure. Infostructures are created with the help of the Archive Retrieval Configurator,

Archive information structure

1 For better readability, we will use the short term “infostructure” from now on.

Archive Information System

133

the customizing component of the Archive Information System. As with the archive indexes, the infostructure is filled with data either directly during the delete phase or later, when initiated by the user. As is the case with an archive index, the data related to an infostructure is maintained in a database table. Another component of the Archive Information System, the Archive Explorer supports data mining within an infostructure and permits direct accesses to the archived data and, ultimately, their display. Field catalog

Each infostructure not only belongs uniquely to an archiving object, it also refers explicitly to a certain field catalog. A field catalog is a collection of fields that are suitable for indexing the archive files of the archiving object concerned. The fields of an infostructure are always a selection of the fields of the corresponding field catalog. In addition, the field catalog contains a set of technical properties that are also transferred to the infostructure. Thanks to the concept of field catalogs, it is not necessary to know the technical details of the archiving object to create an infostructure, since the details are already stored in the field catalog. To create an infostructure, you only have to select which fields it should include. The use of the Archive Information System and some related background information are explained below. The individual steps are listed in the order in which the user or administrator would normally execute them if the Archive Information System is to be used for an archiving object for the first time. All functions listed here can be accessed through the central management of the Archive Information System (transaction SARI). The application help function provides more detailed information on the Archive Information System.

4.5.1

Creating an Infostructure

Do not change standard infostructures

Before you create your own infostructure, you should check to see whether there is already an infostructure available that you can use to evaluate the archived data. You can copy this infostructure and adapt it to your own needs. However, you should not modify any infostructures provided by SAP. Such a change would be a modification of the software, which may be undone with the next upgrade or with the installation of support packages.

Transferring fields

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

134

Accessing Archived Data

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

Figure 4.3 Creating an infostructure in the Archive Retrieval Configurator

For technical reasons, some fields from the field catalog are immediately transferred to the infostructure and cannot be removed. These are usually the key fields. Most field catalog fields belong to the list of selectable fields, however, and you can transfer them to the infostructure. You can later search for archived data using all the fields of the infostructure. Note, however, that infostructures are stored in the database, and therefore each additional field that is transferred to the infostructure requires additional space in the database.

4.5.2

Key fields

Activating an Infostructure

In order to be able to use an infostructure, you must activate it. Only after an infostructure has been activated can it be filled with data from the archive and evaluated. However, activated infostructures can no longer be modified. As was the case with the application-specific archive indexes, the Archive Information System also needs a database table to store the index data.

Archive Information System

Database table for index data

135

The database table is not predetermined. Rather, it is generated on the basis of the information available when the infostructure is activated. The fields of this table consist of: 왘 The client 왘 The fields of the infostructure 왘 The archive file key 왘 The offset of the business object in the archive file

For the above example, the generated database table would look like the one shown in Figure 4.4.

Figure 4.4 Database table for the infostructure Reporting program

A reporting program is also generated for evaluating this table and for accessing the archive to display the archived data. After the database table and the reporting program have been created, the system sets an active indicator for the infostructure in question. This indicator means that the infostructure can now be used for evaluation and that it should be created automatically when the respective delete program is run.

4.5.3

Building an Infostructure

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

136

In addition to being created automatically by the delete program, an infostructure can also be built subsequently for existing archives. Therefore, you have the option of building infostructures when required, e.g.,

Accessing Archived Data

when evaluating data that was already archived before the introduction of the Archive Information System or in order to modify the fields of an infostructure. When an infostructure is built, the database table is filled with data from the archive and a build status is recorded in parallel. In the status administration of the Archive Information System, you can then see which archive files the respective infostructures were created for.

Build status

4.5.4 Evaluating an Infostructure The search for archived data in the Archive Explorer is always done on the basis of the reporting program that was created during the activation of the infostructure. The selection screen of the reporting program contains all fields of the infostructure, except for the Mandt, Archivekey, and Archiveofs fields (see Figure 4.4). When the program is executed, you will receive a list of all entries in the infostructure that fit your selection criteria. Up to this point in the evaluation process, no access to the archive has taken place; the system has only read the index data stored in the infostructure. By double-clicking on a list entry, you can now perform a direct access to the archive and navigate all the way down to the field level in the data hierarchy.

Reporting program as a basis

The view of the data shown in the Archive Explorer is very technical and therefore less suitable for end users. The Archive Information System makes this type of technical view available for all archiving objects. In order to adapt the display to the needs of the end users, SAP has introduced the concept of business views. This concept means that the archived data is shown in a form that the end user would expect to see, or one that is familiar from the display of the corresponding data in the database. The extent to which this type of display is supported depends on the archiving object. Many archiving objects have no business view at all in the Archive Information System, while others, such as the archiving object CO_ORDER, are supplied with several business views. When you double-click on an infostructure entry, you are first prompted to select the desired view, as shown in Figure 4.5.

Technical views and business views

Generally, an infostructure has to have already been created in order for the Archive Explorer to carry out an evaluation of the infostructure. This means that only files with the “delete completed” status can be evaluated. This makes sense since all other data still resides in the database. There would be no reason to search for this data in the archive.

Ad-hoc evaluations

Archive Information System

137

Figure 4.5 Selecting a view for archived CO orders

However, you may want to simply check the archived data before the delete phase. For this purpose, you can use the Ad-hoc evaluation function. In an ad-hoc evaluation, the system does not access the generated database table, but rather performs a sequential read access to the archive files you have selected. The data volume that would otherwise be created when building an infostructure is only stored internally. The following display of data and the navigation options correspond to those of a normal infostructure evaluation. The evaluation of built infostructures with the Archive Explorer or other accesses to the Archive Information System (see Section 4.6) is particularly fast if the system can perform the access using the primary index of the corresponding database table. For accesses via fields other than those of the primary index, additional database indexes may be needed. Since the tables of the Archive Information System are generated in the production system, in most cases it is not feasible to create this type of index using the ABAP Dictionary. Also, if the database table is re-created, the index may be deleted again. Database indexes for infostructures

138

In this case, the Archive Information System offers the option of adding information about the desired database indexes to an infostructure definition. You can also create user-defined indexes for SAP standard infostructures by entering the index ID and the corresponding fields into the AIND_STR8 table. For more detailed information on this topic, refer to SAP Note 164704.

Accessing Archived Data

4.5.5

Deleting an Infostructure

Just like data in other database tables, the data stored in a generated database table needs disk space. Therefore, it is generally advisable to delete data for older archive files after a certain time. Since the source data has already been archived, archiving this data is no longer pertinent. However, you generally have the option of manually deleting the contents of infostructures. This function gives you additional flexibility to build and empty infostructures as needed—for example, if file access is not needed all the time. When infostructures are created, an integration with ADK takes place. This is not the case when infostructures are emptied, which means that the deletion of the content must always be explicitly triggered. This must be taken into account particularly when reloading archives. When you reload archived data, you must explicitly empty active infostructures for the corresponding files and explicitly build infostructures for any archive files that may have been created during the reload process.

Explicit emptying of infostructures

4.5.6 Creating a Field Catalog SAP supplies standard field catalogs for many applications. You can recognize SAP’s standard field catalogs by their name, which begins with “SAP_”. Before you create your own field catalogs, you should always check to see whether you can use a standard field catalog. You should never modify a standard field catalog, not even by adding new fields. When the release is upgraded or when support packages are installed, standard field catalogs may be overwritten. Furthermore, some programs assume that the field catalogs look exactly the way they did when they were delivered.

Do not modify standard field catalogs

You can, however, copy a standard field catalog to your own namespace and perform the desired modifications on the copy. However, you should bear in mind that standard programs usually ignore infostructures created on the basis of user-defined field catalogs. As a result, you can usually use such infostructures only in the Archive Explorer and in your own programs. The creation of a field catalog requires expert knowledge. You must therefore know, for example, which tables are archived together with a certain archiving object and which of these table entries makes up a business object. You should know this information before you create a new field catalog for an archiving object. This is particularly important for estimating the expected volume of data and for field catalogs with several source tables.

Archive Information System

Expert knowledge required

139

Example for financial accounting documents

The following paragraphs describe a typical procedure that can be applied in most cases. It is necessary to differentiate between field catalogs with one source table and those with several source tables. For more detailed information on how to create a field catalog and on the significance of the various fields and indicators, use the Application Help function or the F1 Help function. In the following procedure description, we assume that you know the significance of the individual fields and that you know how to make entries. As an example, we will use a field catalog for financial accounting documents, which are archived by means of the FI_DOCUMNT archiving object. This type of document includes, among other things, a document header and several items. The document header is stored in table BKPF; the items are in table BSEG. 4.5.6.1 Creating a Field Catalog with One Source Table 1. Selecting the source table To build an infostructure, the Archive Information System can use any table and any structure stored in the respective archive files. Which one of the tables of an archiving object is used depends on the fields you would like to use to search for archived objects. Note, however, that a search using the fields of an item table generally requires more space in the database than a search in a header table. This is because an item table generally has more entries than a header table. In addition, after an infostructure has been built, the database table generated usually contains as many entries as are contained in the leading table of the field catalog in the archive files. In our example, table BKPF of the archiving object FI_DOCUMNT was selected. It should be possible to run a search for the Document number, Fiscal year, and Posting date fields. 2. Naming the field catalog The name of a field catalog is subject to the same limitations as the names of other system objects, such as database tables. You should use only letters, numbers, and the underscore. The name should begin with a letter, but not with the abbreviation “SAP”. It is recommended that you use a name contained in your internal namespace. For our example, we selected “ZDEMO_BKPF” as the name. 3. Header entry of the field catalog Enter the name, the identification, and the archiving object of the new field catalog. In the File in index column, enter “K” (key field), and in the Offset in index column, enter “D” (data field).

140

Accessing Archived Data

4. Key fields of the field catalog In most cases it is a good idea to use all the key fields of the reference table as key fields in the field catalog, with the exception of the client. It is recommended that you use the numbers 10, 20, 30, and so on as field numbers. In any case, you should make sure that the key field numbers are smaller than the data field numbers. It is also recommended that when naming fields, you use the same field names as are used in the reference table. Make sure that the Obligatory key field and Valid key field indicators are not set for key fields. The Key indicator must be set for key fields. In the example, all key fields of the table BKPF (except the client) were transferred to the field catalog as key fields. 5. Data fields of the field catalog In most cases, it is advisable to make all data fields of the reference table data fields of the field catalog too. For numbering data fields, it is recommended that you use the numbers 100, 110, 120, etc. Make sure that the Key and Obligatory key field indicators are not set for data fields. The Valid key field indicator should be activated for data fields. For data fields, it usually makes sense to transfer as many reference table fields as possible to the field catalog. Additional data fields in a field catalog require neither considerable storage space nor considerable runtime. However, you should transfer only fields that also function as selection criteria for programs to the field catalog. In particular, you should not use any fields of data type FLTP (floating-point number). You should also omit fields of the data types CURR and QUAN, since these are generally not formatted correctly. For more information on these data types, see SAP Note 309384. 4.5.6.2 Creating a Field Catalog with Several Source Tables 1. Selecting the source tables For the selection of several source tables, the same procedure applies as for the selection of one source table. It should, however, be noted that the source tables must satisfy certain dependency conditions. Tables that are not related to each other in any way cannot be used together in a field catalog. In general, you should select tables that all belong to one document, such as document header and document item, or that can at least be linked via common fields.

Archive Information System

141

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 different tables. To define a field catalog, it must be possible to arrange all source tables in such a way that each table that depends on another also has the same key fields as that table. In the example of the financial accounting documents, the tables BKPF and BSEG are linked by the Company Code, Document Number, and Fiscal Year fields. Entries from BKPF and BSEG that are the same in these fields belong together. The table BSEG depends on the higherlevel table BKPF and contains the key fields of the latter table as key fields. 3. Determining the leading table After determining the possible relationships between the tables involved, you will notice that there is usually at least one table whose fields are the same as the key fields of the field catalog. There may even be several tables with this property. This is the case if there are at least two tables that have the same number of key fields in the field catalog. In such a case, you can select any of the eligible tables as the leading table. If, on the other hand, there is no table that has all the key fields of the field catalog, you cannot create the field catalog in this way. You must select other source tables or check the relationships between the tables. In our example, the leading table is table BSEG. 4. Creating the field catalog for the leading table For the time being, ignore all tables except the leading table. Create the field catalog as described in Section 4.5.6.2. In the example, a field catalog for the source table BSEG is created first. 5. Completing the other table(s) For all other tables, all key fields should already be in the field catalog at this point. If this is not the case, either you made an error in determining the table dependencies or you did not select the correct table in the last step. Now select any one of the remaining tables and enter its key fields as further source fields in the corresponding key field of the field catalog.

142

Accessing Archived Data

For our example, this means that the BUKRS field from table BKPF is entered as an additional source field for the BUKRS field; BKPF-BUKRS is entered as an additional source field for BUKRS; and BKPF-GJAHR is entered as an additional source field for GJAHR. (There is no corresponding field in table BKPF for the field BUZEI.) Afterward, enter each of the table data fields as a new data field in the field catalog. When doing so, follow the same restrictions for fields in the field catalog as for field catalogs with only one source table. Repeat this step for each table that is to be included. 4.5.6.3 Typical Pitfalls When Creating Field Catalogs If you create a field catalog as described above, there should be no errors in the creation of the corresponding infostructures. Nevertheless, in some cases there may be problems which have not been discussed so far. We will address them now by describing two typical error scenarios: Error scenario 1: “Records not inserted in infostructure” During the delete phase or a subsequent deletion of an infostructure, the error message “Records not inserted in infostructure” (Q6330) may appear. In addition to the other causes mentioned in the full text of this message, a defective field catalog may also be responsible for the error. This is because the key table of the field catalog was not fully defined or did not match the structure of the archive files. The procedure described above is based on the assumption that the table entries which are defined by the key table given in the field catalog do not occur more than once in an archive file. Should this be the case, though, the error described will occur when you attempt to insert the corresponding records into the generated database table. There are two possible strategies for dealing with this problem: On one hand, you can try to make the key table of the field catalog unique by adding further key fields. On the other hand, you can designate the business object itself—the offset in the archive file—as the key field. To do this, enter “K” in the column Offset in index in the header entry of the field catalog. The offset then becomes the key field of the generated database table.

Solution

Error scenario 2: “Infostructure is inconsistent” If, however, the message “Infostructure is inconsistent” (Q6234) appears during the delete phase or during the subsequent creation of an infostructure, the error usually does not lie in the infostructure itself, but in

Archive Information System

143

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

You should check to see whether the additional source fields were entered correctly for all key fields and whether the field catalog was created according to the procedure described above. You might have to remove a source table from the field catalog in order to ensure the consistency of the field catalog.

4.6

Archive Accesses Based on the Archive Information System

In the section on direct access, we described an option whereby an end user could access archived data without having to know the archiving details and without knowing whether the data is in the archive or still in the database. For such accesses, the system automatically determines whether the data is in the archive and in which archive file it is stored. The archive access is then usually carried out automatically by the system, without the interaction of the user. The advantage of this type of access is the consistent integration of archived data into the familiar display transaction. In the solution described above, an application-specific model for indexing the archived data is needed. For the Archive Information System, exactly the opposite is the case: Archived data is indexed via a uniform procedure, but during this procedure, data cannot be sufficiently integrated into common display transactions. Using the programming interface of the Archive Information System, it is possible to access the data of an infostructure from a program and to use this data as an application-specific archive index. This permits the integration of archived data into the familiar application transaction while the disadvantage of different application-specific index solutions is avoided. Example

144

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.

Accessing Archived Data

Figure 4.6 Line item report for orders

By default, the line item reports of cost accounting do not automatically access archived data. The need to access archived data must first be indicated to the system in the table ASACCESS01. In this table, you can specify whether the report should read exclusively from the database or whether it should also automatically read the archived data via the Archive Information System. In order for the reports to find archived data using the Archive Information System, the corresponding infostructures must be built. It is important in this case that an infostructure has been activated and built for a standard field catalog supplied by SAP. In the example shown above, the line items were archived with the archiving object CO_ITEM. Based on this, an infostructure is needed for one of the field catalogs SAP_CO_ITEM_001 or SAP_CO_ITEM_002. In the example, an infostructure was used for the SAP_CO_ITEM_001 field catalog. The important point in this case is not the use of an infostructure supplied by SAP, but the use of a suitable field catalog supplied by SAP. Infostructures that were created with reference to user-defined field catalogs are ignored by the line item reports. One reason for this is the fact that the application—in this case the line item report—assumes that certain fields with a certain significance in the field catalog exist. If customerdefined field catalogs were used, this could not be ensured with sufficient certainty. However, in addition to the infostructure needed for the line item reports, it is possible to use a different infostructure which refers to another field catalog. This is not a problem for the line item report, but it uses up additional storage space in the database.

Archive Accesses Based on the Archive Information System

Using the standard field catalog

145

This type of file access is performed in essentially the same way as the reading of an application-specific index, with the difference that instead of the application-specific index table, an appropriate infostructure is read. Even though the infostructure also has a database table hidden behind it, the fields of the table are not predetermined, but are selected when the infostructure is configured. Another difference between the described line item report and a direct access—to display accounting documents (transaction FB03), for instance—is the fact that, with the line item report, several business objects are often read from the archive and then filtered further against the selection criteria. To a certain extent, this is therefore an indexed sequential access.

4.7 Data from the archive and from the database

The Document Relationship Browser

The Document Relationship Browser (DRB) is used to display linked business objects. Usually these are documents that were created during a common business transaction or that are part of a common process. DRB is not limited to a special application, but rather displays linked documents from different application areas. In addition, with DRB it is easy for the end user to integrate other programs outside the SAP system, such as different ALE scenarios (Application Link Enabling). Another strength of DRB is that it can display archived objects, although DRB is just as effective when displaying data that has not yet been archived. In this chapter, we would like to discuss the capabilities of DRB with regard to archived data in particular. See SAP Note 492938 to find out where you can get further information on DRB.

Archive Information System as base

The file accesses made through DRB are always automatic accesses, almost always based on the Archive Information System. It is therefore not necessary to know if the data is in the archive. However, you can use DRB to find out if this is the case.

DRB is a service

DRB is not an independent application, but rather a service which is called up for a single entry object. From the applications, you can connect to DRB for a single entry object via different transactions and reports. Most of these functions are summarized in the “Document Relationship Browser” (SAP_DRB) role. In addition to some simple lists for finding documents, these functions also include the document display in financial accounting (transaction FB03) and the line item reports of overhead cost controlling.

146

Accessing Archived Data

After entering DRB via a business object of a certain type, such as a sales order, as shown in Figure 4.7, you can see which business objects are linked with the entry object. The applications provide the business objects that are directly linked with the entry object in question. What this means in detail has been determined within the respective applications. The links between the business objects have no further semantics; it is therefore not possible to detect whether one object is the predecessor or successor of another object. The display in DRB shows only that there is a link between the objects.

Figure 4.7 Business objects linked with a sales order

In order to avoid a cyclic, and thus an unnecessarily complicated, display of the linked business objects, each object is displayed only once within the respective business process. This is also the case if an object is directly linked to several objects. The consequence is that not all direct links are actually shown. The display can also vary depending on the entry object you select and the order in which you navigate through the link tree. However, the total number of displayed objects remains the same, regardless of the order of the individual navigation steps. In the first step of the DRB display, only those objects that are linked directly with the entry object are displayed. If further objects are in turn linked with these objects, you can display them as well by navigating through the displayed

The Document Relationship Browser

Objects linked more than once are displayed only once

147

link tree. In Figure 4.7, the sales order 4972 was selected as the entry object. In the link tree, you can see all of the business objects that are linked with this sales order. You can call up the object display by double-clicking on an object key— usually the document number. What this display looks like in detail depends on the respective application and the type of business object. The components of DRB

DRB is divided into a general Basis core and further application-specific components, such as Sales, Materials Management, and Accounting. The Basis core is responsible for the display of the links shown above and for forwarding the functions to the respective application, depending on the type of object. The application components are responsible for determining the links and for displaying the individual business objects, among other things. File accesses are necessary for precisely those functions that are executed by the application components. Therefore, it is not the Basis core of DRB that accesses the archived data, but the respective application. The way in which the archive access is executed and the requirements that apply in each case thus depend on the type of business object. However, in order for DRB to be able to access archived data, you must select the appropriate settings in the Archive Information System for all object types. In most cases this includes the building of infostructures for certain standard field catalogs (“SAP_...”). A considerable part of the documentation on DRB deals with the details of these settings.

Calling up DRB from the SAP_ DRB role

As previously mentioned, DRB is not able to independently execute all functions for finding and displaying the linked business objects. It needs the support of applications—for finding the entry object selected by the user, for example. This function can be performed with the functions of the “Document Relationship Browser” (SAP_DRB) role, already mentioned above. All functions contained in this role provide automatic archive access. The way in which a certain business object is displayed in the DRB view is also application-specific. Whether an archived object is displayed differently than a corresponding object from the database also depends on the application and the business object type.

148

Accessing Archived Data

4.7.1

Connected Object Types in Detail

This section deals with some important business object types connected to DRB, which will be examined more closely. We will look at the prerequisites that must be fulfilled so that DRB can find and display the archived data of these object types. Furthermore, we will discuss the links between these object types and how they are presented in DRB. You will find details on additional object types in the Document Relationship Browser documentation. Table 4.2 provides you with an overview of which SAP R/3 Enterprise business object types are connected to DRB. Application

Business Object Types

SAP Web Application Server

Intermediate document (IDoc)

Accounting

Settlement document

Overview

Workflow work items

Accounting document Direct input accounting document Cost accounting document Profit center document Account statement line item Profit and loss statement Special ledger documents Sales and Distribution

Customer inquiry Customer quotation Sales order Customer complaints order Customer contract Customer scheduling agreement Customer outline agreement Credit memo request Group master contract Returns Subsequent delivery free of charge Customer delivery Sales support document Individual customer billing document Invoice list

Table 4.2 Object types connected to DRB

The Document Relationship Browser

149

Application

Business Object Types

Materials Management

Line item invoice Incoming invoice Purchase requisition Purchase order Goods receipt

Production Planning and Control

Production order Production order completion confirmation

Table 4.2 Object types connected to DRB (Cont.)

Please note that not all object types listed here are connected to DRB in the same way. For example, in the system, not every object type has a function that calls up the respective object as an entry object in DRB. Also, object types may appear in DRB that are not listed in the table. This is because some functions for determining relationships are based on generic characteristics of the relationship in question. For example, the system always finds the source document (see Section 4.7.1.1) of an accounting document with the same mechanism, regardless of the object type of the source document. In this way, it is possible to find source documents even if their object type is not explicitly connected to DRB and, as a result, does not appear in the table. In general, however, these objects cannot be displayed if they are already archived. 4.7.1.1 Accounting Document Source document

150

In Accounting, the principle of the source document applies. This means that each business transaction visible in accounting has a document that triggered the action—the source document. This document does not have to be located in Accounting. If, for example, a billing document is posted in Sales and Distribution (SD), an accounting document and a cost accounting document (as well as additional accounting documents, if applicable) are usually also created. The source document of this business transaction is the billing document, even though it is not actually located in Accounting. For the purpose of DRB, all accounting documents are now considered linked with their source document and vice versa. In the above example, the cost accounting document is thus not linked directly with the accounting document, but both are linked to the billing document. Via the billing document, a two-stage relationship can then be established between the cost accounting document and the accounting document.

Accessing Archived Data

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

Prerequisites for display in DRB

The “Document Relationship Browser” role (SAP_DRB) also contains another program that can be used to enter DRB from an accounting document. You can jump to DRB by double-clicking on the desired document in the output list of this program. As with the cost accounting line item reports described above, you can select whether the program should read from the archive or from the database. The mechanism we described earlier, which is controlled via the table ASACCESS01, also works with this program; you only need to make the corresponding entry for the program RDRBFI00. To carry out a complete connection of archived accounting documents to the Document Relationship Browser, you should proceed as follows:

Connecting archived accounting documents

왘 Suppose you would like to use the program

RDRBFI00, contained in the “Document Relationship Browser” role, and you would also like to make selections via the Posting Period (BKPF-MONTH) and Reference (BKPF-XBLNR) fields. For this, you should use an infostructure for one of the field catalogs SAP_FI_DOC_001 or SAP_FI_DOC_002 that also contains the Posting Period, Posting Date, Document Type, Reference Document Number, Reference Process, Reference Key, and Logical System fields.

왘 If you do not want to use the program

RDRBFI00, you do not require automatic file access in the program, or you do not want to select via the mentioned fields, it is sufficient that you use the application-specific archive index (ARIX_BKPF), which the program usually builds anyway.

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

archive is done with the help of the archive index.

The Document Relationship Browser

151

4.7.1.2 Cost Accounting Document Distribution to archives

Dealing with archived cost accounting documents in DRB is more complicated than, dealing with, say, accounting documents. This is due to the way in which the line items are distributed in the archives. Cost accounting documents can be archived with different archiving objects, such as CO_ITEM, PP_ORDER, CO_COSTCTR, and SD_VBAK. Another problem is that the cost accounting documents are not archived document-bydocument. In the case of a posting in which a production order and a cost center are involved, part of the document can be stored in a PP_ORDER archive while the other part is still in the database. Therefore, it is not possible to determine exactly which archive file a cost accounting document is located in, nor can it be determined whether the cost accounting document has already been archived or not. This can be determined only for individual document line items.

Several field catalogs and infostructures

Because an Archive Information System field catalog depends on the archiving object, several field catalogs, and thus infostructures, may be needed. For access to cost accounting documents, field catalogs for the different archiving objects are supplied. The names of these catalogs begin with “SAP_COBK_”. Therefore, in order to connect archived cost accounting documents to DRB, you need an infostructure for the corresponding SAP_COBK field catalog for each archiving object with which you archive cost accounting line items. To determine the links, these infostructures must contain the field REFBN. Infostructures of this kind are part of the standard SAP system delivered to the customer. Their names also start with “SAP_COBK_”. It is usually sufficient to activate and build up these infostructures. However, if you add the REFBT, AWTYP, and AWORG fields to your infostructures, the program runtime will be improved. The downside is that the infostructures then require more storage space in the database. This has to be weighed against the runtime advantage. Because of the way in which cost accounting documents are archived, the number of entries in the necessary infostructures corresponds approximately to the number of line items. However, the important things here are the line items from archive files for which the corresponding infostructure was built. Since this type of infostructure can be very large, you should think carefully about whether the display of archived cost accounting documents is necessary. With cost accounting documents (as with other accounting documents), only the respective source documents are linked. The objects in which

152

Accessing Archived Data

the costs are collected, such as orders and cost centers, are not considered to be linked to the cost accounting document. Otherwise, several million documents could be linked with one object, exceeding the capabilities of DRB. 4.7.1.3 Sales Order In Sales and Distribution, a link between two documents corresponds to the relationship that, in the document flow, is referred to as predecessor or successor. However, the semantics of the relationship disappears in DRB and it is no longer evident which document is the predecessor and which is the successor. To connect archived sales orders and other sales documents that are archived with the archiving object SD_VBAK to DRB, all you need is an active and filled infostructure for one of the field catalogs SAP_SD_VBAK_002 or SAP_SD_VBAK_002. For sales documents, the “Document Relationship Browser” role has a special program that can be used to enter DRB (see Figure 4.8).

Figure 4.8 Entering DRB via sales documents

Here, in addition to the document number in the Sales Document field, you can also use other fields as selection criteria. It is a good idea to include these fields in the infostructure.

The Document Relationship Browser

153

Search options

Also note the three selection buttons on the selection screen, which you can use to control where the program searches for the sales documents. 왘 Search DB

If this option is selected, only the database is searched for the sales documents. Archived sales documents are ignored. 왘 Search DB and SAP AS

If you select this option, the program searches for sales documents in the database and in the infostructures of the Archive Information System specified above. However, the archive is not accessed. Consequently, not all fields in the results list may be filled and not all desired records may be found, because the program views any fields that are not contained in the infostructure as empty, and does not continue to search for the missing data. 왘 Search DB, SAP AS and Archive

When selecting this option, the program searches for sales documents in both the database and the infostructures of the Archive Information System. For documents found in the infostructures, any missing data is read from the archive. Therefore, the only documents read are the ones that are contained in a suitable infostructure. Known pitfalls

This selection controls only what is displayed in the results list of the program, and not the linked documents that DRB will find later. Archived documents may therefore be displayed as linked objects in DRB, even though the option Search in DB was selected. In many cases, only the two options Search in DB and Search in DB, SAP AS and Archive should be used. The Search in DB and SAP AS option may often be faster than the latter option, but it may give confusing results because the end user usually does not know which fields are contained in the infostructures and what effect this has on the selection.

Display of archived logistics documents

Unlike in accounting, in logistics DRB does not display archived documents in the same way as documents that are still in the database. However, the display transactions for archived documents were designed to be similar to the corresponding display transactions for documents that still reside in the database. In addition, all the important fields are displayed. If the documents are still in the database, the usual document display transactions, such as VA03, are used. All further logistics object types are connected to DRB in a manner similar to sales orders. The only differences are in the case of the field catalogs used, and in the case of those fields that can be used to make selections

154

Accessing Archived Data

and that can be integrated into the infostructures. For more information, refer to the documentation on the application-specific components of the Document Relationship Browser.

4.7.2

Configuring the Document Relationship Browser

Up to now, discussion of DRB concentrated mainly on how the Archive Information System and other data archiving functions use DRB to access archived data. The main configuration topic was the definition of infostructures. However, in addition to this main option for making settings, there are also other options available for optimizing access to archived data and for adapting the functions to the needs of the end user. In this context, the following configuration options should be addressed: 왘 Presetting the entry programs 왘 Choosing entry list fields 왘 Choosing object types to be displayed 왘 Choosing fields in DRB

All settings can be user-specific. All settings, except for the setting for choosing which object types are to be displayed, are not actually specific to the Document Relationship Browser, but originate from the tools used in it. However, since these settings are extremely useful for adapting DRB to data archiving, we will now discuss and demonstrate how you can make the access to archived data even more convenient for the user. 4.7.2.1 Presetting the Entry Programs By default, the “Document Relationship Browser” role contains some programs that can be used to enter DRB. However, these programs are set up in such a way that they cannot access files. For logistics programs, the Search in DB search option is preset. For the accounting programs, the automatic file access is, by default, not activated in table ASACCESS01. Below you will see how to assign these programs to a role in such a way that automatic file access is activated. First you must create a selection variant for each program that you want to use. In the field characteristics of the selection variant, you can, among other things, preset the Search in... fields and hide them. If the program is now started with this variant, the user will not see these fields on the selection screen anymore and the desired value is used automatically.

The Document Relationship Browser

Creating a selection variant

155

For the entry lists for accounting documents and for the line item reports in cost accounting, you can proceed in a similar manner. However, you cannot hide the fields for the selection of the data source here, because no matter what, these fields do not appear on the selection screen. Nevertheless, they are stored with the variant. Of course, you can also control the entry lists for accounting and cost accounting documents via the ASACCESS01 table, as described above. In this case, however, performance changes for all users. If you really want to set up the system so that the line item reports within cost center accounting automatically read from the archive for all users, it is preferable that you make the setting via ASACCESS01. Assigning selection variant to a role

After you have created corresponding variants for all programs to be used, you can enter these programs into a role by means of transaction PFCG. If one of the programs to be used is called from the role to which it was assigned, it starts automatically with the variant settings. In this way you can set up a role containing all programs that call DRB and that are configured to automatically access the archive. Of course, you can also use this mechanism to preset selection criteria other than those mentioned here. 4.7.2.2 Choosing Entry List Fields All programs contained in the “Document Relationship Browser” role were implemented with the help of the ABAP List Viewer. Therefore, every time a list is displayed, you can modify its layout, save the modified layout, and set it as the default. These adjustments can be user-specific or can be implemented as a general setting for all users. 4.7.2.3 Choosing Object Types to Be Displayed Complex business transactions and processes are usually displayed in the Document Relationship Browser in a relatively complex manner. Furthermore, 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.

Personalized display

156

Let us assume, for example, that a user is interested in the supply chain of a business process, but not in the accounting details. In this case, it would make sense to simply hide the unwanted object types in the display. The means for achieving such a selective display is personalization. Depending on whether the settings are to apply to individual users or to a role, you

Accessing Archived Data

implement personalization either in user maintenance (transaction SU01) or in role maintenance (transaction PFCG). Settings implemented for a role can be automatically transferred to all users assigned to this role. In the “Document Relationship Browser” role, the selection of the object types is set so that all objects are displayed.

Figure 4.9 Choosing the object types to be displayed in user maintenance

When you hide certain object types, you should keep in mind that the documents concerned are not only removed from the display, they can also no longer be used to determine additional relationships. This means that not only the explicitly hidden objects are excluded from the display, but also those objects that are dependent on the hidden objects. 4.7.2.4 Choosing Fields in DRB In the DRB navigation tree, only the type and description of an object are displayed by default. You can extend this display by including additional relevant fields. Apart from the technical equivalents of the object key and the object type, two fields are of particular importance: 왘 The Logical System field indicates which logical system the data origi-

nates from. This is relevant if cross-system processes or business transactions are involved.

The Document Relationship Browser

The logical system and origin fields

157

왘 Regarding data archiving, the Origin field in particular is worth men-

tioning. It indicates whether a displayed business object is in the database or in the archive. As with the entry lists, you can control the field selection via layouts, and store and preset user-specific layouts.

158

Accessing Archived Data