Sappress Archiving Data

Bonn � Boston

Helmut Stefani

Archiving Your SAP® Data

116.book Seite 3 Dienstag, 8. Mai 2007 10:58 10

Contents at a Glance

1 Basic Principles of Data Archiving .......................... 27

2 Data Archiving Processes ....................................... 59

3 Storing Archived Data ............................................. 87

4 Accessing Archived Data ......................................... 143

5 Technology and Administration .............................. 181

6 Data Archiving in Various SAP Applications and Components ............................................................ 239

7 Planning and Executing Archiving Projects ............ 305

A Example of an Object Description for the Blueprint ................................................................. 367

B Checklist for Archiving Projects .............................. 371

C Additional Information and Services ...................... 375

D Glossary .................................................................. 379

E List of Acronyms ..................................................... 385

F Bibliography ............................................................ 387

G The Authors ............................................................. 389


7

Contents

Preface to the Second Edition ............................................... 15Preface by DSAG ................................................................... 17Acknowledgements for the First Edition ................................ 19Introduction .......................................................................... 21

1 Basic Principles of Data Archiving ........................... 27

1.1 Information Lifecycle Management in an SAP Environment ........................................................ 27

1.2 Data Archiving as Part of Data Management ............... 311.2.1 Benefits of Data Archiving .............................. 321.2.1.1 System Availability ......................................... 331.2.1.2 Resource Usage .............................................. 331.2.1.3 Response Times ............................................. 331.2.1.4 Adherence to Legal Regulations ..................... 341.2.2 Scope of Functions ......................................... 351.2.3 Areas of Use ................................................... 361.2.4 The Archive Development Kit ........................ 381.2.5 The Archiving Object ..................................... 39

1.3 The Data Archiving Process ......................................... 411.3.1 Accessing Archived Data ................................ 431.3.2 Storing Archive Files ...................................... 47

1.4 Performance Aspects .................................................. 501.5 Archiving Projects ....................................................... 53

1.5.1 The Right Moment ......................................... 541.5.2 Data Management ......................................... 54

1.6 Taxation Requirements Placed on Archived Data ........ 561.6.1 Audit Information System .............................. 571.6.2 Data Retention Tool ....................................... 58

2 Data Archiving Processes ......................................... 59

2.1 Checking Archivability ................................................ 592.1.1 Linked Application Data ................................. 612.1.2 Performing the Archivability Check ................ 65

2.2 Main Data Archiving Processes ................................... 672.2.1 Writing Data from the Database to the

Archive .......................................................... 692.2.2 Deleting Data from the Database ................... 72


Contents

8

2.2.2.1 Deleting After Writing ................................... 732.2.2.2 Deleting During Writing ................................ 742.2.3 Storing Archive Files (Optional) ..................... 76

2.3 Other Processes and Tasks ......................................... 792.3.1 Accessing Archived Data ............................... 802.3.1.1 Evaluating Archive Files ................................. 802.3.1.2 Displaying Archived Single Objects ................ 812.3.2 Reloading Archived Data ............................... 822.3.3 Executing Preprocessing and Postprocessing

Programs ....................................................... 84

3 Storing Archived Data .............................................. 87

3.1 Criteria for Choosing a Storage Strategy ..................... 873.1.1 Security ......................................................... 893.1.1.1 How Secure is the Storage Path? ................... 893.1.1.2 How Secure is the Storage Itself? ................... 903.1.1.3 Which Security Options Does the Storage

System Provide? ............................................ 923.1.2 Costs ............................................................. 923.1.2.1 Purchase Costs .............................................. 933.1.2.2 Operating Costs ............................................ 933.1.3 Integration .................................................... 943.1.3.1 How Does the Storage System Fit into the

Existing IT Landscape? ................................... 943.1.3.2 Besides Data Archiving, How Does Storage

Add Value? ................................................... 943.1.4 Performance .................................................. 953.1.4.1 Parallel Job Processing ................................... 953.1.4.2 Block-by-Block Access ................................... 963.1.5 Long-Term Storage ........................................ 97

3.2 Storage in a Certified Storage System ......................... 993.2.1 Definitions: ArchiveLink, KPro, CMS .............. 993.2.2 What is ArchiveLink? ..................................... 1023.2.2.1 The Main Purpose of ArchiveLink .................. 1033.2.2.2 The Term Document ..................................... 1053.2.2.3 Document Search .......................................... 1073.2.3 Document Scenarios ...................................... 1143.2.3.1 Workflow-Based Document Scenarios ........... 1143.2.3.2 Barcode Scenario ........................................... 1173.2.3.3 Outgoing Documents .................................... 1183.2.3.4 Print Lists ...................................................... 120


Contents

9

3.2.4 Interface to External Systems ......................... 1213.2.4.1 Communication ............................................. 1223.2.4.2 Certifying Storage Systems ............................. 1253.2.4.3 Certified Systems and SAP Content Server ...... 1273.2.5 Storing Archive Files ...................................... 1283.2.5.1 Asynchronous Storage .................................... 1293.2.5.2 Synchronous Storage ...................................... 1303.2.6 Known Technical Problems When Storing

Archive Files .................................................. 1303.2.6.1 Synchronous Problem .................................... 1313.2.6.2 Security Gap .................................................. 1313.2.6.3 Performance Problem .................................... 1323.2.7 Accessing Archive Files .................................. 1323.2.8 Known Technical Problems Accessing Archive

Files via ArchiveLink ....................................... 1333.2.9 Advantages of Using ArchiveLink ................... 133

3.3 Storage via HSM Systems ............................................ 1343.3.1 What is HSM? ................................................ 1343.3.2 Storing Archive Files ...................................... 1373.3.3 Accessing Archive Files .................................. 1383.3.4 Typical Technical Problems ............................ 1393.3.5 Advantages of Using HSM Systems ................. 140

3.4 Manual Storage .......................................................... 1403.4.1 Direct Integration .......................................... 1403.4.2 Indirect Integration ........................................ 1413.4.3 Advantages and Disadvantages of Manual

Storage .......................................................... 1413.5 Summary .................................................................... 141

4 Accessing Archived Data .......................................... 143

4.1 Introduction ............................................................... 1434.2 Basic Principles ........................................................... 1464.3 Sequential Read Programs .......................................... 1474.4 Direct Access .............................................................. 1494.5 Archive Information System ........................................ 152

4.5.1 Creating an Infostructure ............................... 1544.5.2 Partitioning an Infostructure .......................... 1554.5.3 Activating an Infostructure ............................. 1564.5.4 Building an Infostructure ................................ 1574.5.5 Evaluating an Infostructure ............................ 1574.5.6 Deleting an Infostructure ............................... 159


Contents

10

4.5.7 Creating a Field Catalog ................................. 1604.5.7.1 Creating a Field Catalog with One Source

Table ............................................................. 1614.5.7.2 Creating a Field Catalog with Several Source

Tables ........................................................... 1624.5.7.3 Typical Pitfalls When Creating Field

Catalogs ........................................................ 1644.6 Archive Access Based on the Archive Information

System ....................................................................... 1654.7 Document Relationship Browser ................................ 168

4.7.1 Connected Object Types in Detail ................. 1704.7.1.1 Accounting Document .................................. 1724.7.1.2 Cost Accounting Document ........................... 1744.7.1.3 Sales Order .................................................... 1754.7.2 Configuring the Document Relationship

Browser ......................................................... 1774.7.2.1 Presetting the Entry Programs ....................... 1774.7.2.2 Selecting Entry List Fields .............................. 1784.7.2.3 Selecting Object Types to Be Displayed ......... 1794.7.2.4 Selecting Fields in DRB .................................. 180

5 Technology and Administration ............................... 181

5.1 Basic Technology of SAP Archiving Solutions .............. 1815.1.1 The Archive Development Kit: Classification

and Components ........................................... 1815.1.2 ADK as Runtime Environment ....................... 1825.1.3 ADK as Development Environment ............... 1845.1.3.1 Developing New Archiving Objects ............... 1855.1.3.2 Extending SAP Archiving Objects ................... 1865.1.4 Data Archiving and Unicode .......................... 1885.1.5 XML-Based Archiving .................................... 1915.1.5.1 Positioning of XML Archiving ........................ 1915.1.5.2 Common Features and Differences from

ADK from an Administrative Viewpoint ......... 1925.1.5.3 Availability and Documentation .................... 195

5.2 Tasks of the Data Archiving Administrator .................. 1955.2.1 The Data Archiving Administrator Role .......... 1965.2.2 Monitoring Archiving Sessions ....................... 1985.2.2.1 Archive Management .................................... 1995.2.2.2 Data Archiving Monitor ................................. 2035.2.3 Security versus Performance .......................... 205


Contents

11

5.2.3.1 Verification of Archive Files ............................ 2055.2.3.2 File Access Check for Archive Selection .......... 2065.2.3.3 Reverse Order: Storage before Deletion ......... 2075.2.4 Data Archiving Statistics ................................. 2085.2.5 Data Archiving Logs ....................................... 2105.2.5.1 The Application Log ....................................... 2125.2.5.2 The Standard Log ........................................... 2135.2.6 Reorganizing the Database after a Data

Archiving Session ........................................... 2155.2.7 Archive File Browser ...................................... 219

5.3 Archive Routing .......................................................... 2215.4 Automated Production Operation .............................. 223

5.4.1 Periodic Archiving .......................................... 2235.4.2 Scheduling Data Archiving Jobs ...................... 2245.4.2.1 Job Types ....................................................... 2245.4.2.2 Using Server Groups ....................................... 2265.4.3 Interrupting and Continuing Archiving Jobs .... 2275.4.4 Options for Automating Dependent

Processes ....................................................... 2285.4.5 Controlling Data Archiving Jobs Using

External Job Schedulers .................................. 2295.4.5.1 Scheduling Write Jobs .................................... 2295.4.5.2 Scheduling Delete Jobs .................................. 230

5.5 Application-Independent Errors and Their Resolution .................................................................. 2325.5.1 Abnormal Program Termination Behavior ....... 2325.5.1.1 Abnormal Program Termination During the

Write Phase ................................................... 2335.5.1.2 Abnormal Program Termination During the

Delete Phase .................................................. 2355.5.2 Typical Pitfalls ................................................ 2365.5.2.1 The File System Cannot be Accessed .............. 2365.5.2.2 Insufficient Storage Space in the File System .. 2375.5.2.3 Log File Overflow for Database Changes ........ 2375.5.2.4 Database Error ORA-1555—Snapshot too

Old (Only in Oracle Database System) ............ 2385.5.2.5 Database Lock Problems ................................ 238


Contents

12

6 Data Archiving in Various SAP Applications and Components ............................................................. 239

6.1 SAP ERP ..................................................................... 2396.1.1 Data Archiving in Financial Accounting ......... 2396.1.1.1 Data Management ........................................ 2406.1.1.2 Customizing .................................................. 2426.1.1.3 Data Archiving .............................................. 2456.1.1.4 Accessing Archived Data ............................... 2496.1.2 Data Archiving in Cost Accounting ................ 2506.1.2.1 Table COEP in Context .................................. 2516.1.2.2 Object Number and Object Type ................... 2526.1.2.3 Analyzing Overhead Cost Controlling Tables .. 2526.1.2.4 Data Management—Line Item Summarization .. 2546.1.2.5 Selecting Archiving Objects ........................... 2546.1.2.6 CO_ITEM: Central Archiving Object .............. 2576.1.3 Data Archiving in SAP ERP HCM ................... 2586.1.3.1 Data Archiving in Payroll ............................... 2596.1.3.2 Archiving Other HCM Application Data ......... 266

6.2 SAP CRM ................................................................... 2676.2.1 CRM Server in the SAP CRM Application ....... 2676.2.2 Special Features of Data Archiving in

SAP CRM ...................................................... 2696.2.3 Relationship Between Business Objects

and Archiving Objects ................................... 2716.2.4 The Three-Phase Model of Data Archiving ..... 2736.2.5 Cross-Archiving-Object Programs for

Continuous Data Archiving ............................ 2756.2.6 The CRM Business Transaction Data Model ... 2776.2.7 The Archiving Object CRM_ACT_ON ............. 2786.2.8 Summary and Outlook ................................... 282

6.3 SAP NetWeaver Business Intelligence ........................ 2836.3.1 Technical Basics ............................................. 2836.3.2 Considerations for Data Archiving ................. 2866.3.3 Data Archiving in SAP NetWeaver BI ............. 2896.3.4 Modeling Data Archiving Processes ............... 2916.3.5 The Data Archiving Process ........................... 2966.3.5.1 Writing Data to the Archive .......................... 2976.3.5.2 Deleting Data in the Database ....................... 2996.3.6 Reloading Archived Data ............................... 3026.3.7 Accessing Archived Data ............................... 3026.3.8 A Look Ahead ............................................... 303


Contents

13

7 Planning and Executing Archiving Projects ............. 305

7.1 Introduction ............................................................... 3057.1.1 Early Implementation of an Archiving

Project ........................................................... 3067.1.2 Late Implementation of an Archiving

Project ........................................................... 3077.1.3 Considerations Prior to Data Archiving ........... 307

7.2 Procedure After ASAP Implementation Phases ............ 3077.3 Project Phases ............................................................ 310

7.3.1 Project Preparation ........................................ 3107.3.1.1 Putting Together the Project Team ................. 3117.3.1.2 Database Analysis .......................................... 3147.3.1.3 Creating the Basic Concept ............................ 3267.3.2 Business Blueprint: Design and Conception .... 3297.3.2.1 Creating a Detailed Concept .......................... 3307.3.3 Realization ..................................................... 3377.3.3.1 Configuration and Customizing ...................... 3387.3.3.2 Integration Test ............................................. 3407.3.4 Final Preparation ............................................ 3417.3.4.1 Checking Settings and Notes .......................... 3417.3.4.2 Test Phase ...................................................... 3417.3.4.3 End-User Training .......................................... 3427.3.4.4 Release for the Production System ................. 3427.3.5 Go-Live and Support ...................................... 3427.3.5.1 Go-Live .......................................................... 3427.3.5.2 Creating a Long-Term Archiving Plan ............. 3447.3.5.3 Project-End Workshop ................................... 345

7.4 Quality Assurance for the Project ................................ 3457.5 Example: Executing an Archiving Project for

Sales-Related Data ...................................................... 3467.5.1 Introduction ................................................... 3467.5.2 Project Preparation ........................................ 3477.5.2.1 Putting Together the Project Team ................. 3477.5.2.2 Analysis ......................................................... 3487.5.2.3 Basic Concept ................................................ 3497.5.3 Business Blueprint .......................................... 3497.5.3.1 Detailed Concept ........................................... 3497.5.4 Realization ..................................................... 3537.5.5 Final Preparation ............................................ 3547.5.6 Go-Live and Support ...................................... 3547.5.7 Example: Archiving a Sales Document ............ 354


Contents

14

7.6 Critical Success Factors for an Archiving Project ......... 3597.7 Selecting the Right Residence Times .......................... 3597.8 Selecting the Right Archiving Sequence ...................... 362

Appendix......................................................................... 365

A Example of an Object Description for the Blueprint .............. 367B Checklist for Archiving Projects ............................................. 371C Additional Information and Services ..................................... 375

C.1 Information ................................................................ 375C.2 Services ...................................................................... 375C.3 Training ..................................................................... 376

D Glossary ............................................................................... 379E List of Acronyms ................................................................... 385F Bibliography ......................................................................... 387G The Authors ......................................................................... 389

Index ........................................................................................... 395


15

Preface to the Second Edition

Since this book was first published in 2002, the data archiving pro-cesses in the SAP environment have been developed further withregard to both functionality and quality. A large number of newfunctions and improvements made available by releases SAPNetWeaver 7.0 (2004s) and SAP ERP 6.0 (formely known as SAP ERP2005) facilitate the archiving of data and actually complete the dataarchiving processes in many respects.

With regard to the design and concept of data archiving as a whole,the integration of data archiving into the extended context of Infor-mation Lifecycle Management (ILM) is probably the most significantof those innovations. ILM represents a holistic method to activelymanage all information objects in a system across their entire lifecy-cle. It comprises technologies, processes, and concepts whose pri-mary goal is to provide users with the right information at the righttime in the right place and at the lowest cost possible.

New topics in this edition

Other new features that are covered in this second edition includeXML-based archiving that complements the “classical” ArchiveDevelopment Kit (ADK)-based archiving process in the Java and XMLenvironment, partitioning the Archive Information System (AS) toimprove the management of large tables, and Archive Routing,which enables the automatic separation of archived data, for exam-ple, in order to meet legal requirements more efficiently. Anothernew feature described in this book is the Archive File Browser (AFB)that supports the archive administrator in solving problems relatedto archive files. In addition, this book contains a new chapter onarchiving data in SAP ERP Human Capital Management (SAP ERPHCM).

The section on the reporting transaction TAANA (Chapter 7) wascompletely updated and enhanced (e.g., by the description of thefunctions for virtual field catalogs and of analysis procedures in massoperations). The process of archiving data in SAP NetWeaver BI hasalso changed considerably as compared to its predecessor, SAP BW,


16

Preface to the Second Edition

due to the newly developed nearline storage concept. This isreflected in Chapter 6, which deals with archiving data in SAPNetWeaver BI, a large part of which has been added and updated.Another focus in development at SAP was the standardization andimprovement of archiving logs that can now be accessed centrally viatransaction SARA (Chapter 5).

In addition, the entire contents of this book have been updated toreflect the latest SAP system releases. This includes modified termi-nology used in this book, as well as updates of graphics and screen-shots, wherever necessary.

Because of all the new and updated information available in this newedition, I am sure that this book will not only help those readers whoare just becoming familiar with the subject of data archiving, but alsothose users who are experienced in data archiving tasks. Gook luckto all of you!

AcknowledgementsFirst, I would like to express my sincere thanks to the new authorswho joined our team and contributed their expertise to the creationof this current edition of the book. On behalf of the entire team ofauthors, I would also like to thank the following colleagues for theircontributions and support: Olaf Schmidt for proofreading the chap-ter on the Document Relationship Browser; Tanja Kaufmann for hersupport with the terminology and her help in writing the chapter oninformation lifecycle management; Harold “Ken” Campbell, withoutwhom many of the new examples and screenshots would not havebeen possible; and last but not least, Dr. Ulrich Marquard, SeniorVice President at SAP, who, as an active sponsor of this project,deserves our special thanks.

Walldorf, March 2007Helmut Stefani, editor and co-author


17

Preface by DSAG

Archiving data in SAP systems is an ever-changing area whose signif-icance is continuously increasing for companies.

When maintaining SAP systems, the growing data volume and unsat-isfactory performance that occur soon after the going live of a pro-duction system raise such questions as which data should be retainedin the system and for how long, as well as which data must beretained and which data can be deleted. To avoid system operationproblems that cause these questions to arise, data archiving must beconsidered at the start of an SAP project. Regular archiving activitiescan slow down the overall growth of the quantity of data and there-fore establish an equilibrium within the system and ensure good sys-tem performance.

When considering data archiving, you need to take into account sev-eral requirements. There are legal requirements for retaining andevaluating company data, as well as user requirements for easyaccess to data from previous time periods. Also, there are technicalrequirements regarding system performance, backup and recoverytimes, as well as hardware and administration costs.

To take into account all of these data archiving aspects, experts fromvarious areas of the company have to work together: system techni-cians; Basis support; application support; key users from the depart-ments concerned; data center, auditing, and security departmentpersonnel; and external auditors.

These experts have to perform a number of tasks. The database needsto be analyzed and suitable archiving objects need to be chosen.Archiving processes need to be customized—which may eveninvolve programming—and tested, right up to the first archivingruns in the production environment and throughout routine opera-tion. These experts also need to evaluate the effects of these pro-cesses on the size and performance of the system. Finally, they needto consider dependencies between data archiving and documentstorage, including questions concerning authorizations, and storing


18

Preface by DSAG

and accessing archived data. The recent enhancements of the SAPdata archiving functions and tools provide sufficient support to carryout these different tasks.

With the introduction of SAP/R3 Enterprise, the area of dataarchiving became standardized, which made administrative workmuch easier and more straightforward. The ability to interruptarchiving runs, a statistics function, the complete control of back-ground jobs by external schedulers through the new XBP-2.0 inter-face, and the table analysis via transaction TAANA are but a few ofthose new developments.

In the context of SAP ERP 6.0/SAP NetWeaver 7.0, new functionssuch as Archive Routing, the partitioning of tables of the archiveinformation system, and XML-based archiving have been added.

The concept of information lifecycle management (ILM) poses newtasks and challenges to all those involved in data archiving in SAPsystems.

I hope that all readers of this book, Archiving Your SAP Data, can tapinto the new possibilities of data archiving and optimize theseoptions both in their daily work and in new projects and strategies.

Gütersloh, March 2007Dipl-Inf. Jutta GimpelMiele & Cie KGGTZ/IT BetriebSpokeswoman of DSAG-Arbeitsgruppe Datenarchivierung


19

Acknowledgements for the First Edition

In completing an extensive project such as this book, experienceshows that the final version is not just a product of the authors, butalso of a number of other “helpful souls” who are too numerous tomention here. The entire team of authors would like to extend theirthanks and appreciation to these people.

Special thanks goes to Dr. Peter Zencke and Dr. Ulrich Marquard,without whose support this book would not have been possible. Wewould also like to mention Wolfgang Röder, the “grandfather” ofSAP data archiving, who initiated its development and who hashelped to shape it over many years.

We also would like to thank Dr. Rolf Gersbacher, who helped withmany of the documents included in this book; Erik Meyers for hisgraphic design, documentation contributions, and terminologywork; and René Bacher for providing us with valuable linguistic feed-back on many chapters.

Finally, we would like to take this opportunity to thank everyoneelse who supported us in creating this book.

Walldorf, May 2007The Team of AuthorsHelmut Stefani, editor and co-author


21

Introduction

Never before has mankind created so much information—and data—as is being created today. According to a survey carried out by theSchool of Information Management and Systems at the University ofBerkeley, California, in 2003, we produced a total data quantity of 5exabytes1 in 2002, while in 1999, the total was 2 exabytes. The larg-est part of this data—92 %—was stored on magnetic media, mostoften on magnetic disks. Within this same timeframe, printed paperdocuments barely maintained a 0.01 % share [SIMS2003]. Eventhough the information on which this survey was based is now sev-eral years old, there's no reason to expect a significant change orslowdown of this trend.

These general observations, which take into account audio and videodata, also apply in the area of business software. Only a few yearsago, computer systems that could handle terabytes of data were arare exception. Today, many companies operate systems of this size.The volume of stored data, often distributed over a number of sys-tems, has also clearly risen. There are many reasons for this increase.For example, after successfully introducing business software to cer-tain business processes, a company will apply it to other businessprocesses, or will extend the existing processes to include otherdepartments or subsidiaries. As a result, additional data is created,which must be stored and managed within the company.

The flood of infor-mation continues to grow

The current, and more importantly, future rate of data growth is pri-marily the result of a revolutionary expansion in the global businessworld, fueled by the explosive proliferation of the Internet. Theworldwide networking of millions of computers enables the high-speed exchange of data between companies and across national bor-ders, forming the foundation for electronic trade and e-commerce.

1 1 exabyte corresponds to 1 billion gigabytes or 1018 bytes. For comparison:According to [SIMS2003], 1 gigabyte corresponds to a small delivery truck fullof books. 5 exabytes would be the equivalent of all words that have ever beenspoken by humans.


143

This chapter describes the options available for accessing archived data for display or evaluation purposes. It focuses on how to use and optimize the Archive Information System and Document Relationship Browser tools. This chapter is intended primarily for administrators who implement and use these tools.

4 Accessing Archived Databy Dr. Martin Fischer and Thorsten Pferdekämper

Even after the data has been archived and therefore removed fromthe database, the system can still access it.

If you were not able to display archived data, you would have toreload the data back into the database (see also Section 2.3.2), whichwould make the process of archiving data meaningless. The purposeof archiving data is ultimately to remove application data that is nolonger required in order to reduce the workload on the database, butalso to save this data in such a way that read access is still always pos-sible.

However, the archived data is then no longer controlled by the data-base. This means that (at least on a purely technical level) you mustuse different access concepts from those used for data that is stillavailable in the database (the SELECT statement cannot accessarchived data). Whether this situation will affect the end userdepends on how the archive is accessed in each specific case.

4.1 Introduction

Access optionsThere are many options available for accessing archived data. In prin-ciple, each archive file created in the same system and client can be


144

Accessing Archived Data4

read. The way in which access to an archive for a certain archivingobject is defined in terms of handling, logging, formatting of theresults, and so on, depends on the programs of the particular appli-cation. The range of options here is very broad. At the low end of thespectrum, there are applications that don’t offer any special pro-grams. In this case, you can only display the archived data in theArchive Information System. This type of display, however, is moretechnical in nature; similar to the way data from the database is dis-played in the Data Browser (transaction SE16). At the high end of thespectrum, archive access is integrated into the application so wellthat the end user cannot tell whether the displayed data originatesfrom the database or from the archive.

In this chapter, we describe the different access concepts usingarchiving objects from Accounting as examples. However, the sce-narios presented here don't necessarily apply to all situations,because hardly any one archiving object can provide every one of thedescribed access options. Nevertheless, almost all archiving objectshave at least one of the identified options.

What is not cov-ered in this chapter

The following terms and concepts are frequently used in the contextof access to archived data, but they only relate loosely to this topicand will therefore not be described in detail in this chapter. Never-theless, we will discuss these topics briefly to clearly distinguishthem from the context of archive access.

� Storing print listsIf, before you start archiving data, you already know preciselyhow you want the subsequent archive accesses to appear, you canperform this type of evaluation before you archive the data andstore the resulting print lists on suitable storage media. If youwant to access data at a later stage, you can find and display thecorresponding list. However, you would not actually be accessingthe archive in this case. For more information on print lists, referto Section 3.2.3.4.

� Storing documentsYou can use the document storage option, often also called opticalarchiving, to store scanned orginal documents or other files thatbelong to a business object (e.g., a financial accounting docu-


145

Introduction 4.1

ment). You can then link them to the corresponding object anddisplay them again later. However, access to these documents haslittle to do with data archiving.

� ReloadingYou could, in principle, restore the status of archived data prior toits archiving by reloading it into the database. You could then per-form the usual evaluations using this data. For different reasonsalready explained in Section 2.3.2, however, you should view thereloading of archived data as a means of correcting an incorrectarchiving process, and not as an alternative for evaluatingarchived data.

� DARTAlthough the Data Retention Tool (DART) was originally developedto comply with the requirements of the U.S. Internal Revenue Ser-vice for evaluating electronic data, it is now also gaining impor-tance in Europe. DART allows you to extract tax-relevant datafrom the system and to save this data in simple text files known asflat files. This tool also contains functions for finding and display-ing the saved data. When you view data that has been extractedand stored using DART, it does not matter if the source data wasarchived in the meantime. However, you can only use DART toaccess a narrowly defined range of tax-related data. For moreinformation on DART, see Section 1.6.2.

� Audit trails in Financial AccountingSimilar to the process used in DART, files are exported duringaudit trails in the financial accounting. These files represent a cer-tain view of the documents in the system. The documents in thiscase, however, are accounting documents only.

� Accessing stored archive filesIn this chapter, we assume that the Archive Development Kit(ADK) can access the archive files. This means that either the filesare located directly in the file system or the storage is configuredin such a way that ADK functions can access the storage medium.For more information on storing archive files, see Chapter 3.


146


4.2 Basic Principles

Basic steps Irrespective of the type of access, you need to implement the follow-ing basic steps to identify and display archived data. It is mainly inthe implementation of these steps that the various access options dif-fer.

Selection 1. Selecting the archive files and business objects to be read in anarchive fileTwo different techniques are used here: The first techniqueinvolves the user selecting the data manually. The user selects therequired archive files in a selection screen of the system, as shownin Figure 4.1.

The second technique involves the system determining thearchive files to be read without any further user interaction. To dothis, the system uses an archive index that it reads based on theselection criteria entered by the user. An archive index is a data-base table that, in addition to containing application-specific selec-tion fields such as a document number, for example, also containsthe key of the archive file where the corresponding data is located.

Figure 4.1 Selection Screen for Selecting Archive Files

Opening 2. Opening the archive files and reading the contentAgain, there are two options available here. The first option is toopen the archive file and read its contents sequentially. The sec-


147

Sequential Read Programs 4.3

ond option is to access the data directly: To do this, you place thefile pointer directly in the location in the archive file where thebusiness object that is to be read begins. This location is called theoffset.

Filtering3. Filtering the required dataThe selection with which the data is to be read from the archivedoes not generally correspond to the selection that was used tostart the archiving session. This means that, by selecting thearchive files, more than the required data range is read in thearchive. The program must therefore filter the data that is actuallyrequired by the user in an additional step, even if it has alreadyread only the relevant business objects.

Preparing data for display

4. Displaying the required dataThere are different ways in which you can format the display ofdata read from the archive. The range of options extends from apurely technical display that corresponds to the Data Browser(transaction SE16) to a typical business display for data from thedatabase. You can find the first option in the Archive InformationSystem, while the second option is available in applications thathave archive access fully integrated into their display functions.In this case, you can no longer tell whether the data originatesfrom the archive or from the database.

4.3 Sequential Read Programs

The Read pushbutton in Archive Administration (transaction SARA)is usually the first contact that users dealing with data archiving havewith the subject of archive access. This pushbutton links the user toprograms that are used to sequentially read the archive files selectedby the user. These programs were specifically written for evaluatingarchive files and typically only operate on archived data. In mostcases, the data is displayed in a format that meets the requirementsof the end user. These programs are particularly suitable for checkingarchived data.

ExampleOne example of such a sequential read program is the RKAARCS1 pro-gram, which is part of the CO_ORDER archiving object (internalorders), and which is also available when you select the aforemen-tioned Read pushbutton. After you enter your selection criteria, you


148


can execute the program. The dialog box shown in Figure 4.1 opensallowing you to select the archive files. In this case, however, notethat the selection criteria does not influence which archive files areoffered for selection. All accessible files are always offered for evalu-ation, irrespective of the selection criteria. You should thereforeensure that selection of archive files matches the chosen selection cri-teria. If you don’t select all the relevant files, not all the required datacan be displayed. Since the program reads all files sequentially, youshould not select too many archive files as this will lead to longerresponse times.

The read program now reads through the selected archive filessequentially and filters the data according to the specified selectioncriteria. The selection criteria has very little effect on the runtime ofthe program. The important factor here is the selection of the archivefiles. After you have selected an archive file, its content is usually dis-played as a list. In the previous example for internal orders, you cannavigate further from the generated list, although this is quiteunusual for this type of evaluation.

Scheduling in thebackground

In addition to executing the read archive program in dialog mode,you can also schedule it to run in the background. Scheduling basi-cally corresponds to scheduling a delete program manually. The dif-ference here is that the read program requires a variant for transfer-ring the selection criteria.

Programs withsubsequently

enhanced archiveread function

While the programs available in Archive Administration are usuallydedicated programs for reading archives, there are also programsthat were originally developed to read normal evaluations of datafrom the database, however these programs were then enhancedwith additional functions for accessing archives. One particular dis-advantage of these programs is that users must know whether thedata is located in the archive and, if so, in which archive file it hasbeen saved. The advantage here, however, is that the data is dis-played in a familiar format. An example of this type of data is thetotals reports (Report Writer reports) in Overhead Cost Controlling.

By clicking on the Data Source pushbutton on the selection screen ofthis type of program, you can specify that the data should be readfrom the archive (Read from archive option) rather than from thedatabase (see Figure 4.2). You can also select the archive files here.


149

Direct Access 4.4

Figure 4.2 Selecting the Data Source in Report Writer Reports

From a technical point of view, the data source selection (database orarchive), as well as the archive files to be read are part of the selec-tion screen, even though the corresponding information is not dis-played directly on this screen. When you save a selection variant,this means that the data source is also saved along with it. This ena-bles you to create a variant for evaluating specific archives in thebackground, for example. After you execute the program, you can nolonger distinguish from the list displayed whether the data originatesfrom the database or from the archive.

4.4 Direct Access

If you want a large part of the data to be read in the archive file andyou know which files contain this data, it is particularly useful forentire archive files to be read sequentially using the manual fileselection that you made previously. This can be the case, for exam-ple, if you want to check the contents of an archive file. For most endusers, however, those functions that require the least amount ofarchiving knowledge are more suitable. The best option here is auto-matic archive access. Although some configuration and administra-tion effort is required, the end user has very little to do.

ExampleAn example of this type of function is the display for accounting doc-uments (transaction FB03). This function also always accessesarchived FI documents automatically, so that the user may no longernotice that the displayed data was already archived. In particular, the


150


user doesn’t have to worry about whether the data could alreadyhave been archived before she executes the transaction.

Data source With some display transactions, such as KE5Z for evaluating actualline items (see Figure 4.3) or KE5Y for evaluating planned line itemsin the profit center, before you execute the transaction you can usethe Extras � Data Source… function to specify whether you want thedata to be read in the database, the archive, or in both sources. Whenselecting the archive, you can also determine whether you want thearchive to be accessed automatically from the Archive InformationSystem or manually by selecting the corresponding archive files.

Figure 4.3 Selecting the Data Source in Display Transactions

Archive index forlocating data

Information on whether the document you want to find has beenarchived and where you can locate it in the archive is usually saved inan archive information structure of the Archive Information System,or it may be saved in an application-specific archive index. Using theselection criteria of the corresponding program, the archive indexcan determine the location in the archive (i.e., the archive file andthe offset) where the data is contained. In the example shown here,the application-specific archive index is only supported for readaccesses but is no longer updated.1 The database table here is ARIX_BKPF. Table 4.1 below contains the relevant fields for this example.

1 This is the case as of SAP ERP 6.0. As of this release, only the Archive InformationSystem is still supported for indexing archived FI documents. However, if youhave created old application-specific indexes based on ARIX_BKPF, you will stillbe able to read these indexes. For more information, refer to SAP Notes 807726and 596865.


151

Direct Access 4.4

When the document display looks for a document in the archiveusing the application-specific archive index, it accesses this databasetable first. The document display uses the Company code, Documentnumber, and Fiscal year fields to determine the archive file and theoffset of the business object where the required document is located.The data in the archive is then read by direct access. The programtherefore does not read through the entire archive file sequentially,but places the pointer directly on the required offset when the file isopened and only reads the relevant business object. This type ofarchive access is much more efficient than the sequential reading ofarchived data if you only want one or a few business objects to beread.

Run a search only using fields contained in the archive index

However, this method is not appropriate for fast access to data usingfields other than those contained in the archive index. In our exam-ple, the archive can only be accessed through the application-specificarchive index if you know the company code, document number,and fiscal year. You cannot search for data using other fields from thedocument. For example, you cannot use the account field, since thisfield is not contained in the archive index. In this case, the archiveindexes of the Archive Information System are vastly superior to therigid concept of the application-specific archive index.

Building the archive index

The archive index is built automatically during the delete phase forarchiving objects that support this concept. You can also build anddelete this index information manually at a later stage. You can dothis using the Index pushbutton that appears in the initial screen ofArchive Administration for archiving objects that support this func-tion.

Field Description

BUKRS Company code

BELNR Document number

GJAHR Fiscal year

ARCHIV_KEY Key for archive file

OFFST Offset of business object

Table 4.1 Table ARIX_BKPF


152


The archive index is only built automatically during the delete phaseif the index build option was activated in the specific Customizingfor the archiving object by selecting the Build Index indicator. How-ever, this indicator is only available if the archiving object supportsthe index function. Setting this indicator means that the archiveindex will automatically be built for future deletion runs.

An archive index is not built for archive files that were processed bythe delete program before you set this indicator. This is evident fromthe information for the relevant archive file, which you can refer toin archive management. You can start the subsequent index build forthese types of archive files. This is primarily a sequential read pro-gram that does not display the read data, but simply creates anextract of this data and writes it, together with the archive file keyand the offset, into the database table of the archive index.

4.5 Archive Information System

Disadvantages ofconventional

access methods

Despite many advantages, the conventional access methodsdescribed so far have several disadvantages, mainly due to technicalrestrictions and the application dependency of the methods:

� For sequential access, the user must know the correct archive files.

� Sequential access takes too long if you only want individual docu-ments to be displayed from the archive.

� Direct access using application-specific archive indexes are notimplemented in all cases.

� Application-specific direct access only works using the fields pro-vided by the developer.

� The building and deletion of archive indexes is application-spe-cific. Although there is a general procedure for building and delet-ing archive indexes in Archive Administration, the programs thatactually build and delete the indexes are application-specific.

Advantages of theArchive Informa-

tion System

These disadvantages don’t apply when you use the Archive Informa-tion System (AS). This tool, developed specifically for accessingarchives, enables you to configure your own archive indexes, fillthem with data from the archive, and search for archived data. As isthe case with an application-specific archive index, the archive file


153

Archive Information System 4.5

and offset are also updated here, which allows you to access thearchived data directly. The Archive Information System also offers ageneric (rather than application-specific) display of all contents of abusiness object from the archive. This system works with all archiv-ing objects, including user-defined objects, and requires no applica-tion-specific programs or modifications.

Tool of choice for accessing archives

The Archive Information System is therefore the tool of choice foraccessing archived data quickly. However, you need to pay specialattention to the term tool here. Due to the generic nature of theArchive Information System, application-specific features cannot, orcan only partially, be considered. This is therefore more of a techni-cal tool, which cannot always meet the requirements of the end userin every respect.

Archive informa-tion structure

The key term in the environment of the Archive Information Systemis the archive information structure.2 This term effectively replaces theterm for archive index introduced above. Each archive access basedon the Archive Information System is performed via an infostruc-ture. Infostructures are created using the Archive Retrieval Configura-tor (transaction SARJ), which is the Customizing component of theArchive Information System. Similar to archive indexes, the data isfilled in the infostructure either directly during the delete phase orsubsequently by the user. As is also the case with an archive index,data for an infostructure is maintained in a database table. Anothercomponent of the Archive Information System, the Archive Explorer,supports data mining within an infostructure and allows you todirectly access and subsequently display archived data.

Field catalogEach infostructure not only belongs uniquely to an archiving object,it also refers exclusively to a specific field catalog. A field catalog isbasically a collection of fields suitable for indexing the archived filesof the archiving object in question. The fields of an infostructure arealways a selection of the fields of the corresponding field catalog.The field catalog also contains a number of technical properties thatare transferred to the infostructure. Due to the design of field cata-logs, you don’t need to know the technical details of the archivingobject in order to create an infostructure, since this information is

2 To improve readability, the short form of this term “infostructure” will be usedfrom now on.


154


already stored in the field catalog. To create an infostructure, yousimply have to select the fields.

In the following sections, we describe how to use the Archive Infor-mation System and provide some related background information.The individual steps are listed in the order in which they are nor-mally performed by the user or administrator if the Archive Informa-tionInformation System is used for an archiving object for the firsttime. You can access all the functions listed here through the centraladministration of the Archive Information System (transactionSARI). The help function of the application provides more detailedinformation detailed.

4.5.1 Creating an Infostructure

Do notchange standard

infostructures

Before you create your own infostructure, you should check whetheran infostructure already exists that you can use to evaluate thearchived data. If necessary, you can copy this infostructure andchange it to meet your own requirements; however, you should notchange any infostructures supplied by SAP. If you do make such achange, this modification may be undone with the next upgrade or ifSupport Packages are installed.

Transferring fields When you create an infostructure, you define which fields must betransferred from the archive into the infostructure. To do this, youselect the required fields from a field catalog and transfer them intothe infostructure (see Figure 4.4). The standard SAP delivery alreadycontains field catalogs for many archiving objects. If you cannot finda field catalog that meets your requirements, you can create yourown. For more information, see Section 4.5.7.

Key fields For technical reasons, some fields of the field catalog are transferredimmediately into the infostructure and cannot be removed. Thesefields are usually key fields. However, most fields of a field catalogbelong to the list of selectable fields that you can transfer into theinfostructure. You can use all the fields of the infostructure to runsubsequent searches for archived data. However, you should notethat infostructures are stored in the database, and therefore eachadditional field that is transferred into the infostructure requiresadditional space in the database.


155


Figure 4.4 Creating an Infostructure in the Archive Retrieval Configurator

4.5.2 Partitioning an Infostructure

Improved han-dling of tables for infostructures

To be able to handle very large amounts of data in the infostructures,you can partition the infostructures, that is, you can distribute thedata of the infostructure onto several database tables. Consequently,not all the data is written to one single table, but is instead distrib-uted to several tables. The partitioning criterion here is the creationdate of the archiving session. For example, the partitioning could beconfigured in such a way that the records of the infostructure for thesessions of each calendar year would be written into a differenttable. The basic concept here is so flexible that you don’t have todefine the partitioning at the start and you can change it at any time.

Defining your own table names

As part of the partitioning process, you could also set the table (ortables) by default for an infostructure. This means that you can freelyselect the table names and the required technical settings and trans-port the tables yourself. The advantage here is that the tables for aninfostructure in a system landscape have the same name and sameproperties overall and are easier to manage.


156


4.5.3 Activating an Infostructure

To be able to use an infostructure, you must activate it. An infostruc-ture can only be filled with data from the archive and evaluated onceit has been activated. But, you can no longer change an activatedinfostructure.

Database table forindex data

As is already the case with the concept of application-specific archiveindexes, the Archive Information System also requires a databasetable to save the index data. This table is not set by default, however;it is generated using the available information when the infostruc-ture is activated. This table contains the following fields:

� The client

� The fields of the infostructure

� The key of the archive file

� The offset of the business object in the archive file

For the above example, the generated database table looks like theone shown in Figure 4.5.

Reporting program A reporting program is also generated to evaluate this table and toaccess the archive to display the archived data. After the databasetable and the reporting program are generated, the system sets anactive indicator for the infostructure in question. This indicatormeans that the infostructure can now be used for evaluations and

Note

The configuration of the partititioning is part of the infostructure itself andis therefore transported and delivered with the infostructure. A partition-ing change to SAP infostructures would therefore constitute a modifica-tion, so you could practically use the partitioning for user-defined info-structures only.

If an SAP infostructure already contains a very large amount of data, youcan transfer this directly into a separate infostructure with suitable parti-tioning by selecting the Utilities � Copy Data menu option. In this case,you don’t have to delete the SAP infostructure and build your new info-structure.

It usually only takes a few seconds to execute this function. Make surethat your own infostructure is based on the same field catalog as the SAPinfostructure; otherwise, read access processes in the application couldbehave differently.


157


that it should be built automatically while the corresponding deleteprogram is running.

Figure 4.5 Database Table for the Infostructure

4.5.4 Building an Infostructure

During the delete phase of data archiving, all active infostructuresbelonging to an archiving object are automatically filled with datafrom the relevant archive file. Based on the defined infostructure,the Archive Information System filters the data from the data recordsin the archive and inserts it into the generated database tablestogether with the archive file key and the offset of the businessobject. These entries are then used as the basis of later searches.

Subsequent buildIn addition to being built automatically by the delete program, aninfostructure can also be built at a later stage for archives that alreadyexist. You can therefore build infostructures when required, forexample, to evaluate data that was already archived before theArchive Information System was introduced or to change the fieldsof an infostructure.

Build statusBesides the generated database table being filled with data from thearchive when you build an infostructure, a build status is alsorecorded. You can use this status in the status management area ofthe Archive Information System to identify for which archive filesthe relevant infostructures were built.

4.5.5 Evaluating an Infostructure

Evaluation pro-gram as a basis

The search for archived data in the Archive Explorer is always con-ducted using the evaluation program created when you activated theinfostructure. The selection screen of the evaluation program con-tains all the fields of the infostructure, except for the Client, ArchiveFile Key, and Offset fields. When you execute the program, you get alist of all the entries in the infostructure that match your selection


158


criteria. Up to this point in the evaluation process, the archive hasnot yet been accessed; the system has only read the index data savedin the infostructure. By double-clicking on a list entry, you can nowaccess the archive directly and drill down as far as the field level inthe data hierarchy.

Technical and busi-ness view

The way the data is displayed in the Archive Explorer is very technicaland therefore less suitable for end users. The Archive Information Sys-tem provides this type of technical display for each archiving object.To adapt the display to best meet the needs of the end user, SAP hasintroduced the concept of business views. This concept means that thearchived data is displayed in a format that the end user would expectto see, or that the end user is familiar with from the display of corre-sponding data in the database. The extent to which this type of displayis supported depends on the archiving object. Some archiving objectsdon’t have any business views in the Archive Information System,whereas some objects, such as CO_ORDER, for example, are actuallyprovided with several business views. When you double-click on aninfostructure entry, you are first prompted to select the view yourequire, as shown in Figure 4.6.

Figure 4.6 Selecting a View for Archived CO Orders

Ad-hoc evaluations An infostructure usually has to have been built already for the ArchiveExplorer in order to be able to evaluate it. This means that only fileswith the Deletion Completed status can be evaluated. This makessense, since all the other data is essentially still in the database andtherefore there is no reason to search for this data in the archive. How-ever, you may want to simply check the archived data before the startof the delete phase. You can use the Ad-hoc Evaluation function forthis purpose. In an ad-hoc evaluation, rather than accessing the gen-erated database table, the system instead performs a sequential read


159


access on the selected archive files. The volume of data that would oth-erwise accumulate when you build an infostructure is only savedinternally. The subsequent display of data and the navigation optionsthen correspond to those of a normal infostructure evaluation.

Database indexes for infostructures

4.5.6 Deleting an Infostructure

Like data in other database tables, the data saved in a generated data-base table needs disk space. For this reason, it generally makes senseto delete data for other archive files again after a certain time. Sincethe source data has already been archived, you no longer need toconsider archiving this data. However, you can generally deleteinfostructures again manually. This function gives you added flexibil-ity for building or deleting infostructures as required, for example, ifyou don’t need to access archives regularly.

Explicit deletionContrary to when you build infostructures, there is no integrationwith the Archiving Data Kit (ADK) for deleting infostructures. Thismeans that the deletion must always be activated explicitly. Youmust take this into account especially when reloading archives.When you reload archived data, you must explicitly delete activeinfostructures for the corresponding files and build the infostruc-tures for any archive files that may have been created during thereloading process.

Note

The evaluation of built infostructures with the Archive Explorer or othertypes of access to the Archive Information System is particularly fast (seeSection 4.6) if the system can access the required data using the primaryindex of the relevant database table.

Additional database indexes may be required to access data through fieldsother than those of the primary index. Because the tables of the ArchiveInformation System are generated in the live system, in most cases, it isnot feasible to create this type of index through the ABAP Dictionary.Moreover, if the database table is regenerated, this could result in theindex being deleted again.

In this case, the Archive Information System gives you the option of add-ing information on the required database indexes into the definition of aninfostructure. This option also allows you to create user-defined indexesfor standard SAP infostructures where you enter the index ID and the cor-responding fields into the AIND_STR8 table. For more information, seeSAP Note 164704.


160


4.5.7 Creating a Field Catalog

Do not changestandard field

catalogs

SAP provides standard field catalogs for many applications. You canidentify these standard field catalogs by their name, which beginswith “SAP_”. Therefore, before you create your own field catalogs,you should always check whether you cannot actually use a standardfield catalog instead. You should never modify a standard field cata-log, not even by adding new fields. Standard field catalogs may beoverwritten when you upgrade a release, or when you install Sup-port Packages. Furthermore, some programs assume that the fieldcatalogs look exactly the way they did when they were delivered.

Still, you can copy a standard field catalog into your own namespaceand make the changes you require to this copy. Nevertheless, youshould keep in mind that standard programs generally ignore info-structures that were created based on user-defined field catalogs. Youcan therefore usually only use these types of infostructures in theArchive Explorer and in your own programs.

Expertise required Creating a field catalog requires specific expertise; for example, youmust know which tables are archived with a particular archivingobject and which of these tables’ entries have been used in a businessobject. You should know this information before you create a newfield catalog for an archiving object. This is particularly important forestimating the expected volume of data and for field catalogs withseveral source tables.

Example for finan-cial accounting

documents

A typical procedure that you can apply in most cases is describedbelow. We make a distinction here between field catalogs with onesource table and those field catalogs with several source tables. Formore detailed information on how to proceed when creating a fieldcatalog and on the significance of relevant fields and indicators, youcan refer to the application help function as well as to the field helpfunction. In the procedure described below, we will thereforeassume that you know the significance of the individual fields andknow how to make entries.

For our example, we will use a field catalog for financial accountingdocuments that are archived using the FI_DOCUMNT archivingobject. A financial accounting document consists of, among otherthings, a document header and several items. The document headeris saved in the BKPF table and the items are located in the BSEG table.


161


4.5.7.1 Creating a Field Catalog with One Source Table

To create a field catalog with one source table, you proceed as fol-lows:

1. Selecting the source tableTo fill an infostructure, the Archive Information System can useeach table and structure saved in the corresponding archive files.Which of the tables of an archiving object is used depends onwhich fields you want to use to search for archived objects. How-ever, note that searching for archived objects using the fields of anitem table generally requires more space in the database thansearching in a header table. This is because an item table usuallyhas more entries than a header table. In addition, after you createthe infostructure, the generated database table usually containsjust as many entries as those in the main table of the field catalogin the archive files.

In our example, the BKPF table of the FI_DOCUMNT archivingobject was selected. You should be able to search for the Docu-ment number, Fiscal year, and Posting date.

2. Naming the field catalogThe name of a field catalog is subject to the same restrictions as thename of other systems objects, for example, database tables. Youshould only use letters, numbers, and the underscore symbol. Thename should begin with a letter, but not with the abbreviation“SAP.” We recommend that you use a name in your ownnamespace.

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

3. Header entry of the field catalogEnter the name, description, and archiving object of the new fieldcatalog. Enter “K” (key field) in the File in index column and “D”(data field) in the Offset in index column.

4. Key fields of the field catalogIn most cases, it makes sense to use all key fields of the referencetable (with the exception of the client) as key fields of the field cat-alog. We recommend that you choose the numbers 10, 20, 30, andso on as field numbers. Always ensure that the key field numbersare smaller than the data field numbers. As field names, we also


162


recommend that you use the same field names as those used in thereference table.

Make sure that the Obligatory key field and Optional field indica-tors are not set for key fields. You must set the Key indicator forthe key fields.

In the example here, all key fields (except the client) of the BKPFtable were added to the field catalog as key fields.

5. Data fields of the field catalogIn most cases, it is a advisable to make all the data fields of the ref-erence table data fields of the field catalog too. We also recom-mend that you use the numbers 100, 110, 120, and so on to num-ber the data fields. Make sure that the Key indicator and theObligatory key field indicator are not set for data fields. TheOptional field indicator should be activated for data fields.

With data fields, it usually makes sense to add as many fields ofthe reference table as possible to the field catalog. In contrast toadding a field to an infostructure, inserting an additional data fieldinto a field catalog does not require much storage place or runt-ime. Nevertheless, you should only add fields to the field catalogthat also work as the selection criteria of programs. You shouldtherefore not use any fields for the FLTP (floating point number)in particular. You should also avoid using the CURR and QUANdata types, since these are usually formatted incorrectly. For moreinformation on these data types, refer to SAP Note 309384.

4.5.7.2 Creating a Field Catalog with Several Source Tables

To create a field catalog with several source tables, you proceedaccording to the following example:

1. Selecting the source tablesThe procedure for selecting several source tables is the same as theone used to select one source table. However note that the sourcetables must fulfill certain dependency conditions in this case. Inaddition, unrelated tables cannot be used together in a field cata-log. You should generally select tables that belong to a combineddocument, such as the document header and document item, forexample, or tables that can at least be linked through commonfields.


163


Based on our example for the FI_DOCUMNT archiving object,these are the BKPF and BSEG tables.

2. Determining dependenciesThe Archive Information System can only use several source tablesif the tables are in a hierarchical dependency relationship. Keyfields with the same semantics determine which table depends onwhich table. These fields usually have the same name in the differ-ent tables. To define a field catalog, you must be able to arrange allsource tables so that each table that depends on another table alsohas the same key fields as that table.

In the example for the financial accounting documents, the BKPFand BSEG tables are linked by the Company code, Documentnumber, and Fiscal year fields. Entries from BKPF and BSEG thatare the same in these fields belong together. The BSEG tabledepends on the higher-level BKPF table and contains the key fieldsof this higher-level table as its key fields.

3. Determining the main tableAfter you determine any possible relationships between the tablesinvolved, you will notice that there is at least one table whosefields are the same as the key fields of the field catalog. There mayalso be several other tables with this feature. This is the case ifthere are at least two tables with the same number of key fields inthe field catalog. In such a case, you can select any of the tables inquestion as the main table.

However, if there is no table that has all the same key fields of thefield catalog, you cannot create the field catalog in this way. In thiscase, you must select other source tables or check the relationshipsbetween the tables. This is the BSEG table in our example.

4. Creating the field catalog for the main tableIgnore all tables except the main table for the time being. Createthe field catalog as described in Section 4.5.6.2. In the example, afield catalog is created for the BSEG source table first.

5. Enhancing the other table(s) progressivelyAt this point, all the key fields should already be in the field catalogfor all other tables. If this is not the case, either an error occurredwhen you determined the table dependencies, or you didn’t selectthe correct table in the last step.


164


Now select any of the remaining tables and enter their key fieldsas additional source fields for the corresponding key field of thefield catalog. For our example, this means that the BUKRS field ofthe BKPF table is entered as an additional source field for theBUKRS field; BKPF-BELNR is entered as an additional source fieldfor BELNR; and BKPF-GJAHR is entered as an additional sourcefield for GJAHR. (There is no corresponding field in the BKPFtable for the BUZEI field.)

Then enter each data field of the table into the field catalog as anew data field. Note that the same restrictions for fields of thefield catalog also apply for field catalogs with only one sourcetable.

Repeat this step for each table that still has to be added.

4.5.7.3 Typical Pitfalls When Creating Field Catalogs

If you create a field catalog following the steps described above,errors should not normally occur when you build the correspondinginfostructures. In some cases, however, problems that were not pre-viously discussed may occur. We will address these problems belowusing two typical error scenarios.

Error scenario 1: “Records not inserted in infostructure”During the delete phase or when you subsequently build an info-structure, the error message “Records not inserted in infostructure”(Q6330) may appear. In addition to the other causes for this errormentioned in the long text of this error message, an incorrect fieldcatalog may also be responsible for the error. This is due to the factthat the field catalog key was not defined completely, or did notmatch the structure of the archive file. The procedure describedabove is based on the assumption that the table entries defined bythe key specified in the field catalog are no longer found in anarchive file. If this is the case, however, the error described aboveoccurs when you try to insert the corresponding records into thegenerated database table.

Solution There are essentially two strategies to solve this problem: On the onehand, you can try to make the key of the field catalog unique by add-ing other key fields. On the other hand, you can make the businessobject itself (i.e., the offset in the archive file) the key field. You can


165

Archive Access Based on the Archive Information System 4.6

do this by entering “K” in the Offset in Index column in the headerentry of the field catalog. The offset then becomes the key field forthe generated database table.

Error scenario 2: “Infostructure is inconsistent”If the error message “Infostructure is inconsistent” (Q6234) appearsduring the delete phase or when you subsequently build an info-structure, this is usually caused by the definition of the field catalograther than by the infostructure itself. As already mentioned above,field catalogs with several source tables must satisfy certain consis-tency conditions.The source tables must therefore be sorted in sucha way that the key fields of each source table are a subset of the keyfields of the previous source table in the sorting sequence.

SolutionYou should therefore check whether the other source fields for allkey fields were entered correctly, and whether the field catalog wascreated following the procedure described above. You may have todelete a source table from the field catalog to ensure the consistencyof the field catalog.

4.6 Archive Access Based on the Archive Information System

In the section about accessing archives directly, an option wasdescribed where an end user can access archived data without havingto know anything about archiving or without having to knowwhether the data is in the archive or is still in the database. With thistype of access, the system automatically determines whether the datais in the archive and in which archive file it is saved. The system thenusually accesses the archives automatically without any interactionfrom the user. The advantage of this type of access is the consistentintegration of archived data into the familiar display transaction.However, an application-specific concept for indexing archived datais required for the solution mentioned above.

With the Archive Information System, the behavior is exactly thereverse. There is a uniform procedure for indexing archived data, butdata cannot be integrated sufficiently into the usual display transac-tions.


166


You can use the programming interface of the Archive InformationSystem to access the data of an infostructure from a program and touse this data as an application-specific archive index. This means thatarchived data can be integrated into the normal application transac-tion without the disadvantage of dealing with different solutions foran application-specific index.

Example The line item reports of Cost Accounting in SAP ERP are an exampleof this type of function. Figure 4.6 shows the line item report forinternal orders (transaction KOB1) with the line items of an archivedinternal order. It is no longer clear from this report whether the dataoriginates from the database or from the archive. To display the lineitems, the user does not need to know from where this data origi-nated.

Figure 4.7 Line Item Report for Orders

The line item reports of cost accounting do not automatically accessarchived data by default. The system must first be notified of thisrequirement for access through the ASACCESS01 table. In this table,you can specify whether the report should only be read from thedatabase, or whether the archived data should also be included auto-matically through the Archive Information System.


167

Archive Access Based on the Archive Information System 4.6

Corresponding infostructures must be created for the reports to beable to find archived data in the Archive Information System. Whatis important here is that an infostructure for a specific standard fieldcatalog provided by SAP was activated and built.

Using the stan-dard field catalog

In the example shown above, the line items were archived with theCO_ITEM archiving object. For this reason, an infostructure isrequired for one of the SAP_CO_ITEM_001 or SAP_CO_ITEM_002field catalogs. In our example, an infostructure was used for the SAP_CO_ITEM_001 field catalog. The important factor in this case is notthe use of an infostructure provided by SAP, but the use of a suitablefield catalog provided by SAP. Infostructures that were created withreference to user-defined field catalogs are ignored by the line itemreports. One reason for this is that the application (in this case, theline item report) requires that specific fields with a specific signifi-cance exist in the field catalog. When using user-defined field cata-logs, this requirement would not be given with sufficient certainty.However, in addition to the infostructure required for the line itemreports, you can use a different infostructure that refers to anotherfield catalog. This does not present a problem for the line itemreport, but it does consume additional storage space in the database.

This type of archive access primarily runs in the same way that anapplication-specific index is read. The difference here is that data isread for a suitable infostructure, rather than from the application-specific index table. Although the infostructure also includes a data-base table, the fields for this table are not set by default; they are onlyselected when you configure the infostructure.

Another difference between the line item report described aboveand direct access to data, for example, for displaying accounting doc-uments (transaction FB03), is the fact that, with the line item report,several business objects are frequently read from the archive andthen filtered again using the selection criteria. To a certain extent,this is an indexed sequential access method.


168


4.7 Document Relationship Browser

Data from thearchive and from

the database

The Document Relationship Browser (DRB) is used to display linkedbusiness objects. These are usually documents that were created dur-ing a shared business transaction or that belong to a common pro-cess. DRB in this case is not restricted to a specific application butinstead supplies linked documents from different application areas.DRB also enables the end user to integrate data easily outside theboundary of the system, for instance, when using different Applica-tion Link Enabling (ALE) scenario.

Although it is useful for displaying data that has not yet beenarchived, another advantage of DRB is that you can use it to displayarchived objects. In this chapter, we mainly want to discuss the capa-bilities of DRB in relation to archived data. For more information onDRB, see SAP Note 492938.

Archive Informa-tion Systemas the basis

The archive accesses made through DRB are always automaticaccesses that are almost always based on the Archive InformationSystem. You therefore do not need to know whether the data is inthe archive, although you can use DRB to determine whether it is.

DRB is a service DRB is not an independent application; it is simply a service that youcan call at any time for an entry object. The applications contain dif-ferent transactions and reports from where you can branch to DRBfor each entry object. Most of these functions are summarized in theDocument Relationship Browser role (SAP_DRB). In addition tosome simple lists for finding documents, these functions also includethe document display in financial accounting (transaction FB03) andthe line item reports for overhead cost controlling.

After you enter DRB using the business object of a particular type,such as a sales order, the program displays which business objectsare linked to the entry object (see Figure 4.7). The applications pro-vide the business objects that are directly linked to the entry objectsin each case. The relevant application determines what this actuallysignifies in detail. The links between the business objects do nothave any other significant features; therefore, you cannot discernwhether an object is the predecessor or successor of a differentobject. The display in DRB only indicates that there is a link betweenthe objects.


169

Document Relationship Browser 4.7

Multiply-linked objects are dis-played only once

To avoid a cyclical and therefore unnecessarily complicated displayof linked business objects, each object within the business process inquestion is only displayed once. This is also the case if an object islinked directly to several objects. Consequently, not all the directlinks are actually displayed. The display can also vary, depending onwhich entry object you have selected and in which sequence younavigate through the link tree. However, the total number of objectsdisplayed remains the same, irrespective of the sequence of individ-ual navigation steps. In the first step of the DRB display, only theobjects that are directly linked to the entry object are displayed. Ifother objects are linked to these objects, you can also display themby navigating into the displayed link tree. In Figure 4.7, sales order4972 was selected as the entry object. In the link tree, you can see allthe business objects that are linked to this sales order.

Figure 4.8 Business Objects Linked to a Sales Order

You can branch to the object display by double-clicking on an objectkey (this is usually the document number). The way this displayappears depends in particular on the application in question and onthe type of business object.

DRB componentsDRB is divided into a general Basis core and other application-specificcomponents, such as Sales and Distribution, Materials Management,and Accounting. The Basis core is responsible for displaying links asshown above and for forwarding the functions that depend on the


170


object type to the relevant application. The application componentsare responsible for determining the links and for displaying the indi-vidual business objects.

The specific functions that are performed by the application compo-nents require access to archives. Therefore, the corresponding appli-cation, rather than the Basis core of DRB, accesses the archived data.The way in which an archive is accessed and the prerequisitesrequired to do this therefore depend on the type of business object.

In order for DRB to access archived data, however, you must selectappropriate settings for all object types in the Archive InformationSystem. In most cases, this includes building infostructures for certainstandard field catalogs (“SAP_...”). A considerable part of the docu-mentation on DRB deals with the specific details of these settings.

Accessing DRBusing the

SAP_DRB role

As already mentioned, DRB cannot independently perform all thetasks for determining and displaying linked business objects. In fact,DRB requires support from the applications, for example, to find theentry object selected by the user. However, the functions from theDocument Relationship Browser role (SAP_DRB) mentioned earliercan deal with this task. All the functions contained in this role haveautomatic access to archives.

The way in which a certain business object is displayed in the DRBview is also application-specific. Whether an archived object is dis-played differently to a corresponding object from the database alsodepends on the application or the object type.

4.7.1 Connected Object Types in Detail

In this chapter, we want to focus on some important object typesconnected to DRB and explore these in more detail. We will addressthe prerequisites that must be fulfilled to ensure that DRB can findand display archived data for these object types. We will also discussthe links between these object types and how they are displayed inDRB. Information on other object types is available in the documen-tation for the Document Relationship Browser.

Overview Table 4.2 gives you an overview of which object types in SAP ERP areconnected to DRB.


171


Application Object types

SAP NetWeaver 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 items

� Profit and loss statement

� Special ledger documents

� Electronic account statements

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

� Handling units

� Shipments

� Inbound deliveries

� Rough goods receipt

� Shipment requirements

� Shipment orders

Materials Management � Document line invoice

� Incoming invoice

� Purchase requisition

� Purchase order

� Goods receipt

Table 4.2 Object Types Connected to DRB


172


Note that not all the object types listed here are connected to DRB inthe same way. For example, not every object type has a function inthe system for calling the relevant object as an entry object in DRB.

Object types not listed in the table above can also appear in DRB,because some functions for determining relationships are based ongeneric properties of the relationship in question. For example, thesystem always uses the same method to find the source document(see Section 4.7.1.1) for an accounting document, regardless of theobject type of the source document. Consequently, source docu-ments can be found, even if their object types are not explicitly con-nected to DRB and therefore don’t appear in the table. However,these types of objects cannot generally be displayed if they havealready been archived.

4.7.1.1 Accounting Document

Source document The principle of the source document applies in Accounting. Thismeans that each business transaction that you can display inAccounting has a document that activates the transaction—the sourcedocument—however, the document itself does not necessarily haveto be in Accounting. If you post a billing document in Sales and Dis-tribution, for example, an accounting document and cost accountingdocument are usually created (as well as other accounting docu-ments, if necessary). The source document for this business transac-tion is a billing document, although this billing document is not inAccounting. For the purpose of DRB, all accounting documents areconsidered linked to their source document and vice versa. In theabove example, the cost accounting document is therefore not

Plant Maintenance and Service � Maintenance order

� Maintenance order confirmation

� Maintenance notification

� Service notification

� Service order confirmation

Production Planning and Control

� Production order

� Production order completion confirmation

Application Object types

Table 4.2 Object Types Connected to DRB (cont.)


173


directly linked to the accounting document; rather, both are linkedto the billing document. Through this billing document, a two-tierrelationship can then be established between the cost accountingdocument and the accounting document.

Preprequisites for displaying data in DRB

We have already described above how you can branch from the doc-ument display to the Document Relationship Browser. No additionalprerequisites are required here, expect that you must be able to viewthe document to be displayed in the document display (transactionFB03). For archived documents, this means that either the applica-tion-specific archive index has been created for the FI_DOCUMNTarchiving object (table ARIX_BKPF), or that an active and establishedinfostructure exists for one of the SAP_FI_DOC_001 or SAP_FI_DOC_002 field catalogs. In transaction FB00, you can then set thedocument display in such a way that archived documents are alsofound and displayed in DRB.

In addition, the Document Relationship Browser role (SAP_DRB)contains a program that is also suitable for accessing DRB from anaccounting document. You can branch to DRB by double-clicking onthe required document in the output list of this program. Similar tothe line item reports for cost accounting mentioned earlier, you canselect whether you want the program to read from the archive or thedatabase. The method already described previously, which is control-led from table ASACCESS01, also works with this program. You onlyneed to make the corresponding entry for the RDRBFI00 program.

Connecting archived account-ing documents

You can connect archived accounting documents fully to the Docu-ment Relationship Browser as follows:

� If you want to use the RDRBFI00 program contained in the Docu-ment Relationship Browser role and you also want to make selec-tions using the Posting Period (BKPF-MONAT) and Reference(BKPF-XBLNR) fields, you should use an infostructure for either ofthe field catalogs SAP_FI_DOC_001 or SAP_FI_DOC_002 , whichalso contain fields for Posting period, Posting date, Documenttype, Reference (document number), Reference transaction, Ref-erence key and Logical system.

� If you don’t want to use this program, you don’t require automaticarchive access contained in this program. If you don’t want tomake a selection using the fields mentioned above, you can use


174


the application-specific archive index (ARIX_BKPF), which is nor-mally built anyway.

� Set the document display in transaction FB00 in such a way thatdata is read from the archive using the archive index.

4.7.1.2 Cost Accounting Document

Distribution toarchives

Dealing with archived cost accounting documents in DRB is morecomplicated than dealing with accounting documents, for example.This is due to the way in which the line items are distributed in thearchives. You can archive cost accounting documents with differentarchiving objects, such as CO_ITEM, PP_ORDER, or SD_VBAK, forexample. Another problem is that the cost accounting documents arenot archived document by document. With a posting that involves aproduction order and a cost center, part of the document is in a PP_ORDER archive, while the other part of this document is still in thedatabase. Therefore, you cannot clearly determine in which archivefile a cost accounting document is located, or whether it was alreadyarchived. This can only be determined for individual line items (sin-gle line items).

Multiple fieldcatalogs and

infostructures

Since a field catalog of the Archive Information System depends onthe archiving object, you may require multiple field catalogs andtherefore multiple infostructures. To access cost accounting docu-ments, field catalogs are provided for the different archiving objects.These field catalogs begin with the prefix “SAP_COBK_.” Therefore,to connect archived cost accounting documents to DRB, you need aninfostructure for the corresponding SAP_COBK field catalog for eacharchiving object that you want to use to archive cost accounting lineitems. To be able to determine the links, these infostructures mustcontain the REFBN field. SAP provides these types of infostructuresby default. Their names also start with “SAP_COBK_.” Activating andbuilding these infostructures is usually sufficient. You can improvethe runtime of the program by adding the REFBT, AWTYP, andAWORG fields into your infostructures; however, this means thatthe infostructures also need more storage space in the database,which you may have to compare with faster processing speeds.

Based on the way in which cost accounting documents are archived,the number of entries in the required infostructures correspondsapproximately to the number of line items. The important items


175


here, however, are the line items from archive files, for which thecorresponding infostructure was built. Since such an infostructurecan be very large, you should carefully consider whether you need todisplay archived cost accounting documents.

Only the corresponding source documents are linked to the costaccounting documents (as is also the case with other accounting doc-uments). The objects in which the costs are collected (e.g., orders andcost centers) are not considered to be linked to the cost accountingdocument. Otherwise, you could have a situation where several mil-lion documents would be connected to an object, which wouldexceed the capabilities of DRB.

4.7.1.3 Sales Order

In Sales and Distribution, a link between two documents corre-sponds to the relationship referred to in the document flow as thepredecessor or successor. However, because the semantics of therelationship is omitted in DRB, you can no longer discern which doc-ument is the predecessor and which is the successor. To connectarchived sales orders and other sales documents archived with theSD_VBAK archiving object to DRB, you simply need an active andfilled infostructure for one of the SAP_SD_VBAK_001 or SAP_SD_VBAK_002 field catalogs.

The Document Relationship Browser role contains a special programfor sales documents that enables access to DRB (see Figure 4.9).

Figure 4.9 Accessing DRB through Sales Documents


176


In addition to the document number in the Sales Documents field,you can also use other fields as selection criteria. We recommendadding these fields to the infostructure.

Search options Also note the three selection buttons on the selection screen. You canuse these buttons to control where the search for the sales docu-ments is run.

� Search in the databaseIf you select this option, the program only searches the databasefor sales documents. Archived sales documents are completelyignored.

� Search in the database and SAP ASIf you select this option, the program searches for sales documentsin the database and the infostructures of the Archive InformationSystem listed above. However, no archives are accessed. Conse-quently, not all the fields in the output list may be filled and notall the required records may be found, since the program viewsfields that are not contained in the infostructure as empty andtherefore does not continue searching for sales documents.

� Search DB, SAP AS, and archiveIf you select this option, the program searches for sales documentsin the database and in the Archive Information System. For docu-ments already found in the Archive Information System, any miss-ing data is read from the archive. Therefore, only documentslocated in a suitable infostructure are read in this case.

Known pitfalls This selection only controls what is displayed in the output list of theprogram, and not the linked documents that DRB will subsequentlyfind. Archived documents may therefore be displayed as linked objectsin DRB, despite the fact that you selected the Search in DB option. Inmany cases, you should only use the two options: Search in databaseand Search in DB, SAP AS, and archive. Although the Search in data-base and SAP AS option is often faster than the latter option men-tioned, it often presents the end user with confusing results because theend user doesn’t always know which fields are contained in the infos-tructures and what effect this has on the selection.

Displayingarchived logistics

documents

In contrast to accounting, archived logistics documents are not dis-played in DRB in the same way as documents that are still in the data-base. However, the display for archived documents is based on the


177


relevant display transaction for documents from the database. Thisalso ensures that the important fields are displayed. If the documentsare still in the database, the usual document display transactions,such as VA03, for example, are used.

All other object types for logistics are connected to DRB in the sameway as the sales orders. The only differences are with the field cata-logs used and the fields through which data can be selected, andwhich should be integrated into the infostructures. For more infor-mation, refer to the documentation for application-specific compo-nents of the Document Relationship Browser.

4.7.2 Configuring the Document Relationship Browser

The previous DRB discussion focused mainly on using the ArchiveInformation System and other data archiving functions to accessarchived data. In terms of configuration, we concentrated primarilyon how infostructures are defined. In addition to this main optionfor making selections, however, there are also other options availa-ble for optimizing access to archived data and for adapting functionsto suit the needs of the end user.

In this context, we will address the following configuration options:

� Presetting the entry programs

� Selecting entry list fields

� Selecting object types to be displayed

� Selecting fields in DRB

In principle, all settings can be user-specific. All settings, except theone for selecting object types to be displayed, are not actually spe-cific for the Document Relationship Browser, but originate from thetools used there. But, since these settings are extremely useful foradapting DRB better to data archiving, we would like to discuss themin more detail below, and to demonstrate how you can make accessto archived data even more convenient for the end user.

4.7.2.1 Presetting the Entry Programs

Although the Document Relationship Browser role in the standarddelivery contains some suitable programs for accessing DRB, these


178


programs are set up in such a way that they cannot access archives.For logistics programs, the Search in database search option is pre-set. For accounting programs, the automatic archive access is notactivated by default in the ASACCESS01 table. Below we describehow you can assign these programs to a role to activate an automaticarchive access.

Creating selectionvariants

First you must create a selection variant for each program that youwant to use. In the field properties of the selection variant, you canpreset and hide the Search in... fields. If the program is now startedwith this variant, the user no longer sees these fields on the selectionscreen and the required value is used automatically.

You can proceed in the same way for the entry lists for accountingdocuments and for the line item reports in cost accounting. How-ever, you cannot hide the fields for selecting the data source heresince these fields don’t appear on the selection screen in any case.Nevertheless, they are saved with the variant. You can, of course,also control the entry lists for accounting and cost accounting docu-ments in table ASACCESS01, as described above. In this case, theperformance changes for all users. If you really want to set up thesystem in such a way that the line item reports in cost centeraccounting are automatically read from the archive for all users, youshould implement the setting in table ASACCESS01.

Assigning a selec-tion variant

to a role

After you have created corresponding variants for all programs to beused, you can enter these programs into a role in transaction PFCG.If you call this type of program from the role to which it wasassigned, this program starts automatically with the default settingsfrom the variant. In this way, you can compile a role that contains allprograms that call DRB and that are configured to access the archiveautomatically. You can, of course, also use this method to presetselection criteria other than those mentioned here.

4.7.2.2 Selecting Entry List Fields

All programs contained in the Document Relationship Browser rolewere implemented using the SAP List Viewer. Therefore, wheneveryou display a list, you can change its layout, save this changed layout,and set it as the default setting. These settings can be made for spe-cific users or for all users.


179


4.7.2.3 Selecting Object Types to Be Displayed

Complex business transactions and processes are also usually dis-played in a relatively complicated format in the Document Relation-ship Browser. Furthermore, due to the large number of object typesthat support DRB in SAP ERP, runtime problems can occur whenlinks are being determined, because the program tries to resolve alllinks, even though the user does not generally require all objecttypes.

Personalized display

Let us assume, for example, that a user is interested in the supplychain of a business process, but not in the accounting details. In thiscase, it would make sense to simply hide the unwanted object typesin the display. The method you use to achieve a selective display iscalled personalization. Depending on whether you want the settingsto apply for individual users or for a role, you can implement thepersonalization in user maintenance (transaction SU01) or in rolemaintenance (transaction PFCG). Settings made for a role can auto-matically be made for all users assigned to this role. The selection ofobject types in the Document Relationship Browser role is set in sucha way that all objects are displayed.

Figure 4.10 Selecting the Object Types to Be Displayed in User Maintenance


180


When you hide object types, note that the documents in question arenot only removed from the display, they can also no longer be usedto determine additional relationships. This means that not only arethe explicitly hidden objects removed from the display, but they arealso the objects that depend on the hidden objects.

4.7.2.4 Selecting Fields in DRB

Only the type and description of an object are displayed by default inthe navigation tree of DRB. You can enhance this display by addingadditional relevant fields. Apart from the technical equivalence ofthe object key and object type, there are two fields of particularimportance here:

The Logical systemand Origin fields

� The Logical system: This field indicates from which system thedata originates. This is relevant if cross-system processes or busi-ness transactions are involved.

� The Origin field: In terms of data archiving, this field in particularis worth mentioning. This field indicates whether a displayedbusiness object is located in the database or in the archive. In thesame way as entry lists, you can also control the field selectionhere using layouts. You can also save and preset user-specific lay-outs.


395

Index

A

AcceleratedSAP (ASAP) 53, 308implementation phases 307

Access to archived datasequential reading 147

Access to external system archives 37Access Verification 201Accessing archive files 132

from an HSM system 138problems accessing via ArchiveLink 133

Accessing archived data 80, 132basic principles 146dearch strategies for financial accounting

documents 249direct access 149SAP NetWeaver BI 302types 43, 143using the Archive Information System

165Account type life 60

definition rules 244example 244

Adherence to legal regulations 34Ad-hoc

evaluation 158ADK → Archive Development Kit 38Administrative data 379AFB → Archive File Browser 219Aggregates 285, 300

definition 285AIND_STR8 159AIS → Audit Information System 57Application analysis 319Application data

dependencies 61Application interface

application-level 101document-level 101

Application-independent errors 232abnormal program termination 233,

235Archivability check 31, 59

financial accounting documents 246in a preprocessing program 65

in the write program 65performance 67performing 65

Archivability criteria 38, 59application-specific 61

Archive Development Kit (ADK) 38, 379API 184, 379as development environment 184as runtime environment 182components 181, 182conversions 183encapsulated functions 38file management 184internal data object services 183triggering events 228

Archive Explorer 153Archive File Browser 219, 379

user interface 220Archive files 379

compressing 70evaluating 80storing 47, 76verification 205with saved metadata 35

Archive index 379building 82, 151

Archive information structure 44, 379Archive Information System (AS) 152,

379, 380advantages 152display variants 44

Archive management 71, 199, 380access verification 201details on archiving session 200details on the archive file 201displaying selection criteria 202overview of archiving sessions 199overview of stored archive files 203

Archive Routing 221, 380availability 223definition 221routing rules 221routing rules using the example of

SD_VBAK 222storage location 222


396

Index

Archive selectionfile access check 206

Archive server 48Archived data

accessing 80deleting from the database 72reloading 82taxation requirements 56

ArchiveLink 99, 380administration 104certified versions 122definition 102definition of document 124interface to external systems 121storage methods 128

ArchiveLink interfacecurrent version 98

ArchiveLink systemtypical configuration 104

Archivingperiodic 223

Archiving class 380definition 41, 186

Archiving customizationdefinition of logical file name 197examples 197

Archiving documentationi pushbutton 26path names in the SAP Library 26SAP Notes for sources of information 26

Archiving groups 261creating 261using 262

Archiving logs 210accessing information 214application log 211, 212detailed log 212displaying 211job log 211job overview 211spool list 211standard log 213summary log 212

Archiving objects 39, 380archiving programs 39, 185Customizing settings 40definition 185description 39extending 186

extending with custom tables 187in cost accounting 250in financial accounting 240in sales and distribution 348in SAP CRM 282in SAP NetWeaver BI 290residence times 360

Archiving orderreversing 207

Archiving payroll datacreating archiving groups 261retroactive accounting 260

Archiving processresource requirements 54two-step process 68

Archiving program 380Archiving projects 53

ASAP implementation phases 307audit 346business analysis 325Business Blueprint 329characteristics of successful teams 311creating a long-term archiving plan 344creating the authorization concept 332creating the basic concept 326data archiving guide 310, 315defining residence times 329defining the archiving strategy 328early implementation 306example of sales and distribution 346final preparation 341Go-Live & Support 342integration test 340late implementation 307principle of dual control 345project management 312project preparation 310putting together the project team 311quality assurance 345review 345sizing phase 54technical analysis 315test phase 341the right moment 54

Archiving requests 297Archiving sequence 62

define 332example 362in sales and distribution 353


397

Index

Archiving session 380complete 42, 68monitoring 198suspending 72

Archiving-object-specific Customizingcheck and delete 277

ARIX_BKPF 82, 173, 174AS → Archive Information System 152AS_AFB 219ASAP → AcceleratedSAPASUG 22Asynchronous storage 129Audit Information System 57Automated live operation 219Automated production operation 223Automatic job interception 232Automating

downstream tasks 71, 75

B

Backup 92, 380BAdIs

ARC_MM_MATBEL_CHECK 370ARC_MM_MATBEL_WRITE 370FI_DOCUMNT_CHECK 246

Barcode scenario 117Basic concept

scope 326BC_ARCHIVE 192, 199, 200, 213, 233,

234BC_SBOOK_X 195BC_SFLIGHT 190BI accelerator 286Block-by-block access 140BR*Tools 318, 319Business Content 380Business object 31, 381

archivability criteria 59processing status 60relationship with archiving object 271

Business Object Repository 271, 381Business view 381

C

Case Management 110CBO → Cost Based OptimizerCCMS Alert Monitor 203

Certificationstorage systems 125WebDAV for XML archiving 126

CHANGEDOCU 220Check program 67Check/Delete 277Checking

archivability 31, 59before the write phase 229

CO analysis programsRARCOA1 253RARCOA2 253

CO objectobject number and object type 252structure 251

CO_CCMAST 253CO_COSTCTR 174, 253, 254, 256CO_ITEM 167, 174, 253, 254, 256, 257

runtime 257CO_MAST 254CO_ORDER 147, 158, 256, 257CO_TOTAL 253, 254Codepage 36, 80, 381

ASCII 36EBCDIC 36Unicode 36

COEP 257Collection 193Combined evaluation 81Comparing ArchiveLink

3.1 and 4.5 123Complete archiving session 68Compressing

archive files 70data 35rule of thumb 35

Computing Center Management System 381

Concurrent user model 93Content 124

unit 124Content Management Service 381Content server 48

interface 101Correction program SAPF048S 249Cost accounting

archiving objects 250Cost Based Optimizer (CBO) 217Costs


398

Index

storage system 92CRC-32 checksum 205Creating a field catalog

example for financial accounting docu-ments 160

typical pitfalls 164with one source table 161with several source tables 162

Creating selection variantsDocument Relationship Browser 178

Criteria for archivability 59CRM business transaction

data model 277inheritance hierarchy 272

CRM Middleware 268, 381CRM Server 267, 381CRM_ACT_ON 272, 278, 279, 282

delete program 281parallelization 280preprocessing program 278read program 281write program 280

CRM_COMP 283CRM_IBASE 283CRM_LEAD 282CRM_OPPT 282CRM_SACONT 283CRM_SALDOC 283CRM_SERORD 283CRMD_ORDERADM_H 279Customizing archiving

running write and delete jobs concur-rently 75

D

DART → Data Retention Tool 58Data aggregation 55Data archiving

application-independent errors 232areas of use 36as part of data management 31available logs 211benefits 32compression 35data security 71during live operation 68example of a sales document 354in cost accounting 250

in payroll 259in SAP CRM 267in SAP ERP HCM 258in SAP NetWeaver BI 289main processes 67performance aspects 50preparation and execution 354process 41review 34SAP ERP Financials 239scope of performance 35selection criteria 41statistical data 208structure of development and test systems

37two-step procedure 35, 68typical pitfalls 236Unicode 188when it is not helpful 37

Data archiving administratortasks 196user role 196

Data archiving guide 310Data archiving in financial accounting

239Data archiving in payroll 258

execution 265Data archiving in SAP CRM 267, 269

cross-archiving-object programs 275three-phase model 273

Data archiving in SAP NetWeaver BI 289accessing the archive 302ADK-based archiving 294archiving time slices 297creating a write variant 297data archiving process 296delete phase 299delete strategies 300nearline storage 295queries on archived data 302reloading 302structure of archive files 292summarizing archiving sessions 300time slices method 292write phase 297

Data archiving jobsautomatic job interception by third party

232interrupting and continuing 227


399

Index

job class A 225job types 224scheduling 224scheduling delete jobs 230scheduling outside SARA 229scheduling write jobs 229using server groups 226

Data archiving monitor 203functional scope 203sample scenario 204

Data archiving processesin SAP NetWeaver BI 289, 291modeling 291

Data cleansing 325Data destruction 36, 55Data management 54, 55

document summarization in financial accounting 241

guidelines 55in cost accounting 254in financial accounting 240summarization simulation in financial

accounting 241Data object 382Data Retention Tool 58, 145Data security 71

verification data 71Data source

in display transactions 150in report writer reports 149reading data 148

Data transfer processes 288usage when accessing the archive 302

Databaseerror ORA-1555 238fragmentation 216growth 33monitor 316reorganizing after archiving 215

Database-based archiving 181DataManager interface 291DataStore objects 284

definition 284Defective systems 91Definition

administration layer 100application interface 99ArchiveLink 102content server interface 99

document 105external content server 99storage system 99

Delete jobs 382direct scheduling 230indirect scheduling 230

Delete phase 382after storage phase 73process flow 73read verification 73

Delete program 382outside Archive Administration 72read behavior 207scheduling 72settings 208

Deletingafter writing 73during writing 74event-driven 228

Deletion flagremove manually 66setting 65

Deletion flag and indicatorcombined procedure 66setting 66

Deletion indicator 38, 61setting 65

Dependencies between data 61Detailed concept

business view 331scope 330technical view 334

Determining free space 69Direct access 43, 81, 382Display variants 44Displaying archived data

in the application transaction 43in the Archive Information System 44in the Document Relationship Browser

45Displaying single objects 81Document

categories 105compact journal 81definition 105Finder 110flow 61, 347incoming 106integration 94


400

Index

management 94outgoing 107, 119search 107storage 382summarization 241

Document management 94Document Relationship Browser (DRB)

45, 168components 169configuration 177connected object types 170connecting archived accounting docu-

ments 173creating selection variants 178displaying archived logistics documents

176known pitfalls 176logical system field 180origin field 180personalized display 179prerequisites for the display 173search options 176source document 172usage 168

Document scenarios 114barcode 117incoming documents 114outgoing documents 118storing for subsequent entry 115workflow-based 114

Document searchexample 112

Document type life 60definition rules 245example 245

Document type life in financial accoun-tingcontrol 243possible access restrictions 243

Documentationdata archiving 26

Downstream tasksautomating 71

DRB → Document Relationship Browser 45, 168

Durationwrite phase 71

E

Early archiving → Storing for subsequent entry 115

Electronic records 110Enterprise storage system 32Evaluation 43

combined 81of archive files 80

Event-drivendeleting 228scheduling the delete program 72

Extensions 277External content server 101External system archives

access 37

F

FI_ACCOUNT 240FI_ACCPAYB 240FI_ACCRECV 240FI_BANKS 240FI_DOCUMNT 69, 85, 160, 161, 163,

173, 200, 240, 333runtime Customizing 242structure definition 185technical Customizing 242

FI_ELBANK 240FI_MONTHLY 240FI_PAYRQ 240FI_SCHECK 240FI_TCJ_DOC 240Field catalog 153, 382

creating 160key fields 154

File access check for archive selection 206

Financial accountingarchiving objects 240

Financial accounting documentsaccessing archived data 249archivability checks 246carrying out evaluations 249correction program for secondary indexes

249deleting from the database 247


401

Index

deleting secondary indexes 248reloading archived data 249writing to the archive 245

G

General status management 60

H

Hierarchical Storage Management system (HSM) 48, 77, 382definition 134goals 135rule-based organization 134sample scenario 137typical technical problems 139

HSM → Hierarchical Storage Manage-ment system

HTTP Content Management Service 48HTTP Content Server Interface 4.5 126

I

I/O load 50ILM → Information Lifecycle Manage-

ment 27Incoming documents 106Indexes

building 82chronologically sorted 52non-chronologically sorted 52reorganization 216

Industry solutionsspecial feature with archiving objects 41

InfoCubes 284, 299definition 285

InfoProviders 286Information Lifecycle Management 27

four phases 30general definition 28

Information structures 44Infostructures

activating 156build 154build status 157creating 157database indexes 159deleting 159

evaluating 157explicit deletion 159partitioning 155subsequent build 157technical and business views 158

Initial data archiving 354Integration

and certification service 125storage system 94test 337, 340

Intercepted jobs 232Interrupting and continuing

archiving jobs 227

J

J2EE Engine 193Job Scheduler

external 72SAP 72

Jukebox 49, 76, 383

K

Knowledge Provider (KPro) 100, 383KPro → Knowledge Provider

L

Legally required storage periods 55Lifecycle of SAP data 28Lifecycle of storage media 91Line item reports for orders 166Linked application data 61

M

Magnetic disk-based storage systems 49Manual storage 78, 140

advantages and disadvantages 141direct integration 140indirect integration 141

Metadata 35, 80, 383Migration

automated 97to other storage systems 98

MM_EBAN 63MM_EKKO 63, 333MM_MATBEL 224, 367


402

Index

N

Named user model 93Nametabs 183Nearline objects 291Nearline storage

interface 287Network graphic 64Non-SAP documents 107Number format 36, 80

O

Offset 383Operating costs 93Optical archiving 383ORA-1555 238Outgoing documents 107Overhead cost controlling

analyzing the tables 252

P

PA_CALC 259, 261PA_LDOC 266PA_PDOC 266PA_PIDX 266PA_TIME 259, 261PA_TRAVEL 259, 261Parallel job processing 95Partitioning

configuration 156defining your own table names 155transferring data 156

Payrolldata archiving 259

Performancearchivability check 67chronologically sorted indexes 52data archiving 50influence of the data age 52non-chronologically sorted indexes 52storage system 95

Periodic archiving 223, 354prerequisites 224

Platform independence 80PM_ORDER 257Postprocessing program 383

executing 85

PP_ORDER 174, 257PR_ORDER 257Preceding and succeeding documents 62Prepared archive files

deleting 202Preprocessing program 383

executing 84Print lists 107, 383

archiving 47Processing status

completed 60of a business object 60

Q

Quickwins 328

R

R/2 383RAID systems 90RARCCOA5 254Read program 383Read verification 73Records Management 109Recovery 92Release independence 80Reload program 383Reloading 45, 68, 82

archived data 82limitations 83possible risks 45process flow 82to the live system 46to the test system 46

Reorganization 383database after archiving 215indexes 216, 219online 218tables 218tablespaces 218

Residence time 38, 41, 60, 384calculation 60examples 361making the right selection 359

Resource usage 33Response times 33Restore 384Resubmission interval 277


403

Index

Retrieved archive files 201Retroactive accounting

archiving payroll data 259RFBELJ00 81RFEPOJ00 81RM07MARCS 224Robot system 49Routing rules 221RSARCH_FLAG_SESSIONS 200RV_LIKP 348, 350, 351

S

Sales and distributionarchiving objects 348

SAP Content Server 127SAP CRM

deleting data without prior archiving 270

SAP ERP Financialsdata archiving 239

SAP Job Scheduler 72SAP Library

data archiving documentation 25SAP NetWeaver Application Server 384SAP NetWeaver BI → SAP NetWeaver

Business Intelligence 47SAP NetWeaver Business Intelligence (BI)

technical basics 283SAP RFC interface 122SAP Test Data Migration Server 37SAP_DRB 45, 168, 170, 173Scheduling

data archiving jobs 224School of Information Management and

Systems, Survey on quantity 21SD_COND 348SD_VBAK 60, 174, 175, 222, 323, 348,

351, 357SD_VBKA 348SD_VBRK 348, 351SD_VFKK 348SD_VTTK 348, 349Secondary indexes

deleting 85financial accounting documents 243

Securitystorage system 89

Selection criteria

data archiving 41Semantic groups 294Sequence

storing 79when archiving 62

Sequential read 80, 384Sequential read programs 147

example 147scheduling in the background 148subsequently enhanced archive read func-

tion 148Server groups 226Service provider 111Sets 277Simulating the summarization 241Single document access 43, 81Single document display 249Sizing phase 54Smart Forms 118Source document 172Standard field catalogs 160Standard log 213Star schema 285Statistical data

archiving 213collecting 208Cost Based Optimizer 217displaying 209information on storage space 209

Storage costs 32Storage criteria 88Storage media

CD 90hard disks 90lifecycle 91magnetic tapes 91MO and WORM 90

Storage phase 384process flow 78

Storage strategyselection criteria 87

Storage system 384block-by-block access 96certifying 125costs 92definition 99integration 94long-term storage 97parallel job processing 95


404

Index

performance 95security 89security options 92with file interface 48

Storing archive filesalternative storage 77asynchronous 129before delete phase 79in a magnetic disk-based storage system

49in a storage system 76, 99in an external storage system 48in an HSM system 48, 77, 134, 137known technical problems 130manually 78, 140sequence 79synchronous 130using ArchiveLink 48using WebDAV 48

Storing for subsequent entry 115Summarization simulation

RARCCOA5 254Synchronous storage 130System architecture

SAP CRM 268System availability 33

T

TAAN_PROCESS_MULTIPLE 322TAANA 266TAANA_AV 321TAANA_VF 321Table analysis 319Tables

AIND_STR8 159analysis with TAANA 319ARIX_BKPF 242ASACCESS01 166, 173AUFK 251BKPF 160, 163, 164, 246BSEG 160, 163, 246BSIS 242CDCLS 324CDHDR 324cluster 260COEP 251, 254COSP 252CRMD_LINK 278

CRMD_ORDERADM_H 277CRMD_ORDERADM_I 277PCL1 260, 265PCL2 260, 265, 266reorganization 218STXH 324STXL 324V_TVARA 351V_TVARL 350V_TVARR 351V_TVARS 349VBAK 251VBAP 251

Taxation requirementsarchived data 56

Technical view 384Test mode

starting the write job 70statistical information 70

Three-phase model 273check phase 274delete phase 275replication phase 274

TI_TF_GLC 240Time slices 292, 297Transaction

ACLA 182AOBJ 75, 182, 185, 227, 229, 230,

233, 237ARCHGUIDE 310, 315AS_AFB 219DA_CONTROL 276, 277DACONTROL 276DB02 316DB15 182, 199, 257, 318, 323FB00 173, 174FB03 149, 167, 168, 173, 249FB99 246FILE 338KE5Y 150KE5Z 150KOB1 166MB51 367MBAD 367MBAL 367MBAR 367MBAV 367OBCY 241OBR7 243


405

Index

OBR8 244PFCG 178, 179, 196PU22 261, 262, 265RSDAP 291RZ20 192, 205SAR_SHOW_MONITOR 205SARA 69, 182, 362, 369, 380SARI 154SARJ 153SE16 144, 147, 384SM36 72, 276SM61 226ST03 318ST14 319SU01 179TAANA 319TAANA_AV 321TAANA_VF 321VA03 177

Two-step process 68

U

Unicode 188ISO/IEC10646 189Unicode-based archiving 190UTF-16 transformation 189

User exit 247User model 93User role

data archiving administrator 196SAP_BC_CCM_DATA_ARCHIVING 196SAP_DRB 45, 170

V

V_TVARA 351V_TVARL 350V_TVARR 351V_TVARS 349VBAK 323Verification

of archive files 205verification data 71

Volume model 93

W

WebDAV 47, 191, 193WebDAV for XML archiving 126Workshop

project kick-off 310project-end 345

WORM disks 90Write and delete jobs

Customizing 74Write jobs 384

scheduling 229starting in test mode 70

Write phase 384duration 71process flow 70

Write program 384scheduling 69

Write-through 89, 139

X

XML archiving 191archive hierarchy 194availability 195available documentation 195collection 193comparison with ADK archiving 192PACK format 192positioning 191separation of data 193

XML DAS → XML Data Archiving ServiceXML DAS connectors 191XML DAS server 193XML Data Archiving Service (XML DAS)

191XML documents 192XML schema 192
