mit SAP - bücher.de

Liebe Leserin, lieber Leser,

vielen Dank, dass Sie sich für ein Buch von SAP PRESS entschieden haben.

SAP PRESS ist eine gemeinschaftliche Initiative von SAP und Galileo Press. Ziel ist es, den Anwendern qualifiziertes SAP-Wissen zur Verfügung zu stel-len. SAP PRESS vereint das fachliche Know-how der SAP und die verlegeri-sche Kompetenz von Galileo Press. Die Bücher bieten Expertenwissen zu technischen wie auch zu betriebswirtschaftlichen SAP-Themen

Die technischen Bücher von SAP PRESS sind von Mitarbeitern der SAP oder qualifizierter Beratungsunternehmen konzipiert, verfasst und geprüft. Nie-mand wäre berufener als diese Experten, Sie bei Ihren anspruchsvollen Ad-ministrations- und Beratungsaufgaben zu unterstützen.

Jedes unserer Bücher will Sie überzeugen. Damit uns das immer wieder neu gelingt, sind wir auf Ihre Rückmeldung angewiesen. Bitte teilen Sie uns Ihre Meinung zu diesem Buch mit. Ihre kritischen und freundlichen Anregungen, Ihre Wünsche und Ideen werden uns weiterhelfen.

Wir freuen uns auf den Dialog mit Ihnen.

Ihr Florian ZimniakLektorat SAP PRESS

Galileo PressGartenstraße 2453229 Bonn

[email protected]

SAP PRESS wird herausgegeben vonBernhard Hochlehnert, SAP AG

Paul ReadSAP-Datenbankadministration mit Microsoft SQL Server 20002002, ca. 300 Seiten, geb.ISBN 3-934358-87-X

Liane WillSAP APO-SystemadministrationBasiswissen für ein effektives Systemmanagement2002, ca. 230 Seiten, geb.ISBN 3-89842-248-8

Thomas SchneiderSAP R/3-PerformanceoptimierungAnalyse und Tuning von SAP-Systemen2., aktualiserte u. erweiterte Auflage2002, 504 Seiten, geb.ISBN 3-89842-192-9

SAP LabsSAP Guide SystemadministrationSchritt-für-Schritt-Anleitungen für die tägliche Praxis2002, 792 Seiten, geb.ISBN 3-89842-208-9

Horst Keller, Sascha KrügerABAP ObjectsEinführung in die SAP-Programmierung2. Auflage 2001, 665 Seiten, geb., 2 CDsISBN 3-89842-147-3

Aktuelle Angaben zum gesamten SAP PRESS-Programm finden Sie unter: www.sap-press.de.

Helmut Stefani (Hrsg.)

Datenarchivierung mit SAP

Die Deutsche Bibliothek – CIP-Einheitsaufnahme

Ein Titeldatensatz für diese Publikation

ist bei der Deutschen Bibliothek erhältlich

ISBN 3-89842-212-7

© Galileo Press GmbH, Bonn 2002 1. Auflage 2002

Der Name Galileo Press geht auf den italieni-

schen Mathematiker und Philosophen Galileo

Galilei (1564–1642) zurück. Er gilt als Grün-

dungsfigur der neuzeitlichen Wissenschaft

und wurde berühmt als Verfechter des moder-

nen, heliozentrischen Weltbilds. Legendär ist

sein Ausspruch Eppur se muove (Und sie be-

wegt sich doch). Das Emblem von Galileo

Press ist der Jupiter, umkreist von den vier

Galileischen Monden. Galilei entdeckte die

nach ihm benannten Monde 1610.

Lektorat Florian Zimniak Korrektorat Alexan-

dra Müller, Oer-Erkenschwick Einbandgestal-

tung department, Köln Herstellung Iris War-

kus Satz reemers publishing services gmbh,

Krefeld Druck und Bindung Bercker Graphi-

scher Betrieb, Kevelaer

Das vorliegende Werk ist in all seinen Teilen

urheberrechtlich geschützt. Alle Rechte vor-

behalten, insbesondere das Recht der Über-

setzung, des Vortrags, der Reproduktion, der

Vervielfältigung auf fotomechanischen oder

anderen Wegen und der Speicherung in

elektronischen Medien.

Ungeachtet der Sorgfalt, die auf die Erstellung

von Text, Abbildungen und Programmen ver-

wendet wurde, können weder Verlag noch

Autor, Herausgeber oder Übersetzer für mög-

liche Fehler und deren Folgen eine juristische

Verantwortung oder irgendeine Haftung über-

nehmen.

Die in diesem Werk wiedergegebenen

Gebrauchsnamen, Handelsnamen, Warenbe-

zeichnungen usw. können auch ohne be-

sondere Kennzeichnung Marken sein und als

solche den gesetzlichen Bestimmungen unter-

liegen.

Sämtliche in diesem Werk abgedruckten

Abbildungen und Bildschirmabzüge unter-

liegen dem Urheberrecht © der SAP AG,

Neurottstraße 16, D-69190 Walldorf.

SAP, das SAP-Logo, mySAP.com, R/3, R/2,

SAPtronic, ABAP, ABAP/4, SAPscript, SAP

Business Navigator, SAP Business Framework,

AcceleratedSAP, InterSAP, SAPoffice, SAPfind,

SAPfile, SAPtime, SAPmail, SAPaccess, SAP-

EDI, SAP ArchiveLink, SAP Early Watch, R/3

Retail, RIVA, SAP GUI, TeamSAP, SAP APO,

SAP Business Workflow, SAP Business Engi-

neer, SAP Business Information Warehouse,

BW Explorer, ALE/WEB und SAP PRESS sind

Marken oder eingetragene Marken der

SAP AG, Walldorf.

Inhalt 5

Inhalt

Vorwort 13

Danksagung 15

Einleitung 17

1 Grundlagen der Datenarchivierung 23

1.1 Die E-Business-Plattform mySAP.com 231.1.1 Die Komponenten von mySAP.com 241.1.2 SAP Web Application Server 26

1.2 Datenarchivierung als Teil von mySAP Technology 301.2.1 Nutzenbetrachtung 301.2.1.1 Systemverfügbarkeit 311.2.1.2 Nutzung von Ressourcen 311.2.1.3 Antwortzeiten 321.2.2 Leistungsumfang 331.2.3 Einsatzgebiete 341.2.4 Das Archive Development Kit 351.2.5 Das Archivierungsobjekt 37

1.3 Ablauf der Datenarchivierung 381.3.1 Der Zugriff auf archivierte Daten 401.3.2 Die Ablage von Archivdateien 45

1.4 Performance-Aspekte 48

1.5 Archivierungsprojekte 491.5.1 Der richtige Zeitpunkt 511.5.2 Datenvermeidung 51

1.6 Steuerrechtliche Anforderungen an archivierte Daten 531.6.1 Audit Information System 541.6.2 Data Retention Tool 55

2 Prozesse in der Datenarchivierung 57

2.1 Prüfung auf Archivierbarkeit 572.1.1 Vernetzte Anwendungsdaten 592.1.2 Durchführung der Archivierbarkeitsprüfung 63

2.2 Hauptprozesse in der Datenarchivierung 662.2.1 Daten aus der Datenbank ins Archiv schreiben 682.2.2 Daten aus der Datenbank löschen 712.2.2.1 Löschen nach dem Schreiben 732.2.2.2 Löschen parallel zum Schreiben 74

6 Inhalt

2.2.3 Archivdateien ablegen (optional) 75

2.3 Weitere Prozesse und Tätigkeiten 792.3.1 Auf archivierte Daten zugreifen 792.3.1.1 Archivdateien auswerten 802.3.1.2 Archivierte Einzelobjekte anzeigen 812.3.2 Archivierte Daten zurückladen 822.3.3 Vor- und Nachlaufprogramme ausführen 84

3 Ablage von archivierten Daten 87

3.1 Kriterien zur Wahl der Ablagestrategie 873.1.1 Sicherheit 883.1.1.1 Wie sicher ist der Weg in die Ablage? 893.1.1.2 Wie sicher ist die Ablage selbst? 893.1.1.3 Welche Sicherungsmöglichkeiten bietet das Ablagesystem? 913.1.2 Kosten 923.1.2.1 Anschaffungskosten 923.1.2.2 Betriebskosten 933.1.3 Integration 943.1.3.1 Wie passt das Ablagesystem in die bestehende IT-Landschaft? 943.1.3.2 Welchen Zusatznutzen hat die verwendete Ablage neben der

Datenarchivierung? 943.1.4 Performance 953.1.4.1 Parallele Auftragsabarbeitung 953.1.4.2 Blockweiser Zugriff 963.1.5 Langfristigkeit 96

3.2 Ablage auf einem zertifizierten Ablagesystem 983.2.1 Begriffsdefinitionen: ArchiveLink, KPro, CMS 993.2.2 Was ist ArchiveLink? 1023.2.2.1 Zentrale Aufgabe von ArchiveLink 1033.2.2.2 Der Begriff Dokument 1053.2.2.3 Dokumentenrecherche 1073.2.3 Dokumentenszenarien 1133.2.3.1 Workflow-basierte Dokumentenszenarien 1143.2.3.2 Barcodeszenario 1163.2.3.3 Ausgehende Dokumente 1183.2.3.4 DrucklistenErgebnis von Auswertungsprogrammen 1203.2.4 Schnittstelle zu externen Systemen 1213.2.4.1 Kommunikation 1213.2.4.2 Zertifizierung von Ablagesystemen 1243.2.4.3 Zertifizierte Systeme und SAP Content Server 1253.2.5 Ablage von Archivdateien 1263.2.5.1 Asynchrone Ablage 1273.2.5.2 Synchrone Ablage 1273.2.6 Bekannte technische Probleme bei der Ablage von Archivdateien 1283.2.6.1 Synchronproblem 129

Inhalt 7

3.2.6.2 Sicherheitslücke 1293.2.6.3 Performance-Problem 1303.2.7 Zugriff auf Archivdateien 1303.2.8 Bekannte technische Probleme beim Zugriff auf

Archivdateien über ArchiveLink 1313.2.9 Vorteile des Einsatzes von ArchiveLink 131

3.3 Ablage über HSM-Systeme 1323.3.1 Was ist HSM? 1323.3.2 Ablage von Archivdateien 1353.3.3 Zugriff auf Archivdateien 1363.3.4 Typische technische Probleme 1373.3.5 Vorteile des Einsatzes von HSM-Systemen 138

3.4 Manuelle Ablage 1383.4.1 Direkte Integration 1383.4.2 Indirekte Integration 1393.4.3 Vor- und Nachteile der manuellen Ablage 139

3.5 Resümee 140

4 Zugriff auf archivierte Daten 141

4.1 Einführung 1414.1.1 Was in diesem Kapitel nicht behandelt wird 1424.1.1.1 Drucklistenablage 1424.1.1.2 Dokumentenablage 1424.1.1.3 Rückladen 1434.1.1.4 DART 1434.1.1.5 Kontenschreibung in der Finanzbuchhaltung 1434.1.1.6 Zugriffe auf abgelegte Archivdateien 143

4.2 Grundlagen 144

4.3 Sequenzielle Leseprogramme 145

4.4 Direktzugriffe 147

4.5 Archivinformationssystem 1494.5.1 Anlegen einer Infostruktur 1514.5.2 Aktivieren einer Infostruktur 1534.5.3 Aufbau einer Infostruktur 1544.5.4 Auswerten einer Infostruktur 1544.5.5 Abbau einer Infostruktur 1564.5.6 Anlegen eines Feldkatalogs 1574.5.6.1 Anlegen eines Feldkatalogs mit einer Quelltabelle 1584.5.6.2 Anlegen eines Feldkatalogs mit mehreren Quelltabellen 1594.5.6.3 Typische Fallstricke beim Anlegen von Feldkatalogen 161

4.6 Auf dem Archivinformationssystem basierende Archivzugriffe 162

4.7 Document Relationship Browser 1644.7.1 Angebundene Objekttypen im Detail 167

8 Inhalt

4.7.1.1 Buchhaltungsbeleg 1694.7.1.2 Kostenrechnungsbeleg 1704.7.1.3 Kundenauftrag 1714.7.2 Konfiguration des Document Relationship Browser 1734.7.2.1 Vorbelegung der Einstiegsprogramme 1744.7.2.2 Auswahl der Felder der Einstiegslisten 1754.7.2.3 Auswahl der anzuzeigenden Objekttypen 1754.7.2.4 Auswahl der Felder im DRB 177

5 Technologie und Administration 179

5.1 Basistechnologie der SAP-Archivierungslösungen: Das Archive Development Kit 179

5.1.1 Einordnung und Komponenten des ADK 1795.1.2 ADK als Laufzeitumgebung 1805.1.3 ADK als Entwicklungsumgebung 1825.1.3.1 Entwicklung neuer Archivierungsobjekte 1835.1.3.2 Erweiterung von SAP-Archivierungsobjekten 1845.1.4 Datenarchivierung und Unicode 186

5.2 Aufgaben des Datenarchivierungsadministrators 1885.2.1 Die Rolle »Datenarchivierungsadministrator« 1885.2.2 Überwachung von Archivierungsläufen 1925.2.2.1 Archivverwaltung 1925.2.2.2 DA-Monitor 1965.2.3 Sicherheit versus Performance 1995.2.3.1 Verifikation von Archivdateien 1995.2.3.2 Dateizugriffsprüfung bei Archivauswahl 2005.2.3.3 Umstellung der Reihenfolge: Ablegen vor Löschen 2005.2.4 Statistiken der Datenarchivierung 2025.2.5 Reorganisation der Datenbank nach einer Datenarchivierung 206

5.3 Automatisierter Produktivbetrieb 2095.3.1 Periodisches Archivieren 2105.3.2 Einplanung von Datenarchivierungsjobs 2115.3.2.1 Jobtypen 2115.3.2.2 Benutzung von Servergruppen 2125.3.3 Unterbrechen und Fortsetzen 2135.3.4 Möglichkeiten zur Automatisierung abhängiger Prozesse 2145.3.5 Steuerung von Datenarchivierungsjobs durch externe Job-

Scheduler 2165.3.5.1 Einplanung von Schreibjobs 2165.3.5.2 Einplanung von Löschjobs 2175.3.5.3 Ausblick 218

5.4 Anwendungsunabhängige Fehler und ihre Beseitigung 2185.4.1 Verhalten bei Abbrüchen 2185.4.1.1 Abbruch während der Schreibphase 2195.4.1.2 Abbruch während der Löschphase 221

Inhalt 9

5.4.2 Typische Fallstricke 2225.4.2.1 Kein Zugriff auf Dateisystem möglich 2225.4.2.2 Speicherplatz im Dateisystem unzureichend 2235.4.2.3 Überlauf der Protokolldateien für Datenbankänderungen 2235.4.2.4 Datenbankfehler ORA-1555 – Snapshot too old (nur auf

Datenbanksystem Oracle) 2245.4.2.5 Probleme mit Datenbanksperren 224

6 Datenarchivierung in verschiedenen Komponenten vonmySAP.com 227

6.1 SAP R/3 Enterprise 2276.1.1 Archivierung in der Finanzbuchhaltung (FI) 2276.1.1.1 Datenvermeidung 2286.1.1.2 Customizing 2296.1.1.3 Datenarchivierung 2336.1.1.4 Zugriff auf archivierte Daten 2376.1.2 Archivierung in der Kostenrechnung (CO) 2406.1.2.1 Die Tabelle COEP im Zusammenhang 2416.1.2.2 Objektnummer und Objektart 2426.1.2.3 Analyse der Tabellen des Gemeinkosten-Controllings 2426.1.2.4 Datenvermeidung – Einzelpostenverdichtung 2436.1.2.5 Auswahl der Archivierungsobjekte 2446.1.2.6 CO_ITEM: zentrales Archivierungsobjekt 247

6.2 CRM Server 2486.2.1 Der CRM Server in der Lösung mySAP CRM 2486.2.2 Besonderheiten der Datenarchivierung im CRM Server 2506.2.3 Die Beziehung zwischen Business-Objekt und Archivierungsobjekt 2526.2.4 Das Dreiphasenmodell der Datenarchivierung 2546.2.5 Rahmenprogramme für eine kontinuierliche Datenarchivierung 2566.2.6 Das Datenmodell des CRM-Geschäftsvorgangs 2576.2.7 Das Archivierungsobjekt CRM_ACT_ON 2586.2.8 Resümee und Ausblick 262

6.3 SAP Business Information Warehouse 2636.3.1 SAP BW in mySAP.com 2636.3.1.1 Technische Grundlagen 2636.3.1.2 Überlegungen zur Datenarchivierung 2666.3.2 Datenarchivierung in SAP BW 2686.3.3 Modellierung von Archivierungsobjekten 2706.3.4 Der Datenarchivierungsprozess 2736.3.4.1 Daten ins Archiv schreiben 2736.3.4.2 Daten in der Datenbank löschen 2756.3.5 Typische Fehler und ihre Beseitigung 2776.3.6 Zugriff auf archivierte Daten 2786.3.7 Ausblick 278

10 Inhalt

7 Planung und Durchführung von Archivierungsprojekten 281

7.1 Einführung 2817.1.1 Frühzeitiges Aufsetzen eines Archivierungsprojekts 2827.1.2 Spätes Aufsetzen eines Archivierungsprojekts 2837.1.3 Überlegungen im Vorfeld der Datenarchivierung 283

7.2 Vorgehen nach ASAP-Einführungsphasen 283

7.3 Projektphasen 2867.3.1 Projektvorbereitung 2867.3.1.1 Zusammenstellung des Projektteams 2877.3.1.2 Analyse der Datenbank 2907.3.1.3 Erstellen des Grobkonzepts 3007.3.2 Business Blueprint: Design und Konzeption 3037.3.2.1 Erstellung eines Detailkonzepts 3047.3.3 Realisierung 3127.3.3.1 Konfiguration und Customizing 3127.3.3.2 Integrationstest 3157.3.4 Produktionsvorbereitung 3157.3.4.1 Überprüfung der Einstellungen und Hinweise 3167.3.4.2 Testphase 3167.3.4.3 Schulung der Endanwender 3167.3.4.4 Freigabe für das Produktivsystem 3177.3.5 Go-Live & Support 3177.3.5.1 Produktivsetzen 3177.3.5.2 Aufstellung eines langfristigen Archivierungsplans 3197.3.5.3 Projektende-Workshop 319

7.4 Qualitätssicherung im Projekt 320

7.5 Durchführung eines Archivierungsprojekts am Beispiel des Vertriebs (SD) 321

7.5.1 Einführung 3217.5.2 Projektvorbereitung 3227.5.2.1 Zusammenstellung des Projektteams 3227.5.2.2 Analyse 3237.5.2.3 Grobkonzept 3237.5.3 Business Blueprint 3247.5.3.1 Detailkonzept 3247.5.4 Realisierung 3287.5.5 Produktionsvorbereitung 3297.5.6 Go-Live & Support 3297.5.6.1 Vorbereitung und Durchführung der Datenarchivierung 3297.5.7 Beispiel: Archivierung eines Verkaufsbelegs 329

7.6 Kritische Erfolgsfaktoren in einem Archivierungsprojekt 333

7.7 Wahl der richtigen Residenzzeiten 334

7.8 Wahl der richtigen Archivierungsreihenfolge 336

Inhalt 11

A Beispiel einer Objektbeschreibung für das Detailkonzept 339

B Checkliste für Archivierungsprojekte 343

C Weitere Informationen und Services 347

C.1 Informationen 347

C.2 Services 347

C.3 Schulungen 348

D Glossar 351

E Verzeichnis der verwendeten Abkürzungen 357

F Literaturverzeichnis 359

G Die Autoren 361

Index 365

Zugriff auf archivierte Daten 141

4 Zugriff auf archivierte Daten

Thorsten Pferdekämper

Dieses Kapitel erläutert, welche Möglichkeiten es gibt, um auf archivierte Daten zum Zweck der Anzeige oder Auswer-tung zuzugreifen. Der Schwerpunkt des Kapitels liegt auf dem Einsatz und der Optimierung der Werkzeuge Archivinforma-tionssystem und Document Relationship Browser. Es richtet sich insbesondere an Administratoren, die diese Werkzeuge einstellen und bedienen.

Auch nachdem die Daten archiviert und somit aus der Datenbank ausge-lagert wurden, kann das System noch darauf zugreifen. Wäre es grund-sätzlich nicht möglich, archivierte Daten anzuzeigen, müssten diesewomöglich in die Datenbank zurückgeladen werden (siehe auchAbschnitt 2.3.2), was die Datenarchivierung ad absurdum führen würde.Sinn und Zweck der Datenarchivierung ist es ja schließlich, nicht mehrbenötigte Anwendungsdaten zur Entlastung der Datenbank auszulagern,sie aber so zu speichern, dass ein Lesezugriff darauf jederzeit möglich ist.

Die archivierten Daten unterliegen jedoch nicht mehr der Kontrolle durchdie Datenbank, wodurch – mindestens rein technisch – andere Zugriffs-konzepte verwendet werden müssen als bei Daten, die sich noch in derDatenbank befinden (das SELECT-Statement kann nicht auf archivierteDaten zugreifen). Ob sich dieser Sachverhalt allerdings bis zum Endbe-nutzer auswirkt, hängt davon ab, wie die Archivzugriffe im konkreten Fallimplementiert sind.

4.1 EinführungZugriffsmöglich-keiten

Es gibt verschiedene Möglichkeiten, um auf archivierte Daten zuzugreifen.Prinzipiell kann jede Archivdatei gelesen werden, die im selben Systemund Mandant entstanden ist. Wie ein Archivzugriff für ein bestimmtesArchivierungsobjekt in Bezug auf Handhabung, Protokoll, Aufbereitungder Ergebnisse etc. ausgeprägt ist, hängt von den Programmen ab, die diejeweilige Anwendung bereitstellt. Die Bandbreite der Möglichkeiten isthier jedoch sehr groß: Am unteren Rand des Spektrums gibt es Anwendun-gen, die keine speziellen Programme zur Verfügung stellen. In diesem Falllassen sich die archivierten Daten nur mit Hilfe des Archivinformationssys-


tems darstellen. Eine solche Darstellung ist aber eher technischer Natur,ähnlich der Anzeige von Daten aus der Datenbank im Data Browser (Trans-aktion SE16). Am oberen Rand des Spektrums sind die Archivzugriffe sogut in die Anwendung eingebunden, dass der Endanwender gar nichtmerkt, ob die angezeigten Daten aus der Datenbank oder aus dem Archivstammen.

In diesem Kapitel beschreiben wir die verschieden Zugriffskonzepte bei-spielhaft an Archivierungsobjekten aus dem Rechnungswesen. Die vorge-stellten Szenarien erheben jedoch keinen Anspruch auf Allgemeingültig-keit, da kaum ein Archivierungsobjekt tatsächlich über jede derbeschriebenen Zugriffsmöglichkeiten verfügt. Fast alle Archivierungsob-jekte weisen jedoch zumindest eine der aufgezeigten Möglichkeiten auf.

4.1.1 Was in diesem Kapitel nicht behandelt wird

Die folgenden Begriffe und Konzepte werden häufig im Zusammenhangmit dem Zugriff auf archivierte Daten verwendet, berühren diese Thema-tik jedoch nur am Rande und sollen daher in diesem Kapitel nicht weiterbeschrieben werden. Wir möchten jedoch kurz auf diese Themen einge-hen, um sie deutlich vom Kontext der Archivzugriffe abzugrenzen.

4.1.1.1 Drucklistenablage

Wenn Sie bereits vor der Datenarchivierung eine genaue Vorstellungdavon haben, wie die späteren Archivzugriffe aussehen sollen, könntenSie diese Art der Auswertung vor der Datenarchivierung durchführen unddie entstandenen Drucklisten auf geeigneten Medien ablegen. Wird einspäterer Zugriff gewünscht, kann dann die entsprechende Liste herausge-sucht und angezeigt werden. Hierbei handelt es sich jedoch nicht umeinen echten Archivzugriff. Weitere Informationen zu Drucklisten findenSie in Abschnitt 3.2.3.4.

4.1.1.2 Dokumentenablage

Mit der Dokumentenablage, die oft auch »optische Archivierung«genannt wird, können gescannte Originaldokumente oder andereDateien, die zu einem Business-Objekt – etwa einem Finanzbuchhal-tungsbeleg – gehören, abgelegt, mit dem entsprechenden Objekt ver-knüpft und später wieder angezeigt werden. Zugriffe auf diese Doku-mente haben allerdings wenig mit der Datenarchivierung zu tun.

Einführung 143

4.1.1.3 Rückladen

Durch Rückladen der archivierten Daten in die Datenbank könnte prinzi-piell der Zustand vor der Archivierung wiederhergestellt werden. Danachkönnten die normalen Auswertungen über diese Daten durchgeführtwerden. Aus verschiedenen Gründen, die bereits in Abschnitt 2.3.2erläutert wurden, sollte das Rückladen jedoch als Korrektur einer fehler-haften Archivierung angesehen werden und nicht als Möglichkeit, archi-vierte Daten auszuwerten.

4.1.1.4 DART

DART (Data Retention Tool) wurde ursprünglich entwickelt, um die Anfor-derungen der US-amerikanischen Steuerbehörden an die Auswertungelektronischer Daten zu erfüllen. DART gewinnt derzeit aber auch imeuropäischen Raum zunehmend an Bedeutung. Es ermöglicht die Extrak-tion steuerrelevanter Daten aus dem System und deren Speicherung ineinfachen Textdateien, so genannten flat files. Das Werkzeug beinhaltetauch Funktionen zur Suche und Anzeige der gespeicherten Daten. Bei derBetrachtung von Daten, die über DART extrahiert und abgelegt wurden,ist es nicht von Bedeutung, ob die Quelldaten inzwischen archiviert wur-den. Allerdings kann mit DART nur auf einen eng definierten Umfangsteuerrelevanter Daten zugegriffen werden. Weitere Informationen zuDART finden Sie in Abschnitt 1.6.2.

4.1.1.5 Kontenschreibung in der Finanzbuchhaltung

Ähnlich wie bei DART werden bei der Kontenschreibung in der Finanz-buchhaltung Dateien exportiert, die eine bestimmte Sicht auf Belege desSystems repräsentieren. Allerdings handelt es sich hier ausschließlich umBuchhaltungsbelege.

4.1.1.6 Zugriffe auf abgelegte Archivdateien

In diesem Kapitel wird davon ausgegangen, dass das ADK auf die Archiv-dateien zugreifen kann. Das heißt, die Dateien liegen entweder direkt imDateisystem oder die Ablage ist so konfiguriert, dass die Funktionen desADK auf das Ablagemedium zugreifen können. Weitere Informationenzur Ablage der Archivdateien finden Sie in Kapitel 3.


4.2 GrundlagenGrundlegende

SchritteUnabhängig von der Art des Zugriffs sind prinzipiell folgende Schritte fürdie Identifizierung und Anzeige der archivierten Daten erforderlich. Es istvor allem die Realisierung dieser Schritte, in der sich die verschiedenenZugriffsmöglichkeiten unterscheiden.

Auswahl 1. Auswahl der Archivdateien sowie der zu lesenden Business-Objekteinnerhalb einer Archivdatei Hier lassen sich zwei verschiedene Techniken unterscheiden:

� Bei der ersten handelt es sich um die manuelle Auswahl durch denBenutzer. Die Auswahl der gewünschten Archivdateien erfolgtanhand eines vom System angebotenen Auswahlfensters, wie es inAbbildung 4.1 zu sehen ist.

� Die zweite Technik besteht darin, die Bestimmung der zu lesendenArchivdateien ohne weitere Benutzerinteraktion dem System zuüberlassen. Die Bestimmung basiert auf einem so genannten Archiv-index, den das System nach Selektionskriterien, die der Benutzer ein-gegeben hat, liest. Bei einem Archivindex handelt es sich um eineDatenbanktabelle, die außer anwendungsspezifischen Selektionsfel-dern, wie zum Beispiel einer Belegnummer, auch den Schlüssel derArchivdatei enthält, in der die entsprechenden Daten zu finden sind.

Abbildung 4.1 Dialogfenster zur Auswahl von Archivdateien

Sequenzielle Leseprogramme 145

Öffnen2. Öffnen der Archivdateien und Lesen des Inhalts Hier gibt es ebenfalls zwei Möglichkeiten: Die erste besteht darin, dieArchivdatei zu öffnen und den Inhalt sequenziell zu lesen. Die zweiteMöglichkeit ist der Direktzugriff: Dabei wird der Dateizeiger innerhalbder Archivdatei direkt an die Stelle positioniert, an der das zu lesendeBusiness-Objekt beginnt. Diese Stelle wird als Offset bezeichnet.

Filtern3. Herausfiltern der gewünschten Daten Die Selektion, mit der Daten aus dem Archiv gelesen werden sollen,entspricht im Allgemeinen nicht der Selektion, mit der der Archivie-rungslauf gestartet wurde. Das heißt, dass durch die Auswahl derArchivdateien mehr als der gewünschte Datenumfang im Archiv gele-sen wird. Daher muss das Programm – auch wenn es bereits nur dieBusiness-Objekte gelesen hat, die von Belang sind – in einem weiterenSchritt die tatsächlich vom Benutzer gewünschten Daten herausfiltern.

Aufbereitung zur Anzeige

4. Anzeige der gewünschten Daten Die Aufbereitung der im Archiv gelesenen Daten zur Anzeige kann aufunterschiedliche Weise erfolgen. Das Spektrum der Möglichkeitenerstreckt sich von einer rein technischen Anzeige, die dem Data Brow-ser (Transaktion SE16) entspricht, bis hin zu einer für Daten aus derDatenbank üblichen betriebswirtschaftlichen Anzeige. Die erste Mög-lichkeit findet man beispielsweise beim Archivinformationssystem,während die zweite Möglichkeit bei solchen Anwendungen zu findenist, die den Archivzugriff voll in ihre Anzeigefunktionen integrierthaben. Dort ist dann den Daten nicht mehr anzusehen, ob sie aus demArchiv oder aus der Datenbank stammen.

4.3 Sequenzielle Leseprogramme

Benutzern, die sich mit der Datenarchivierung befassen, fällt zum ThemaArchivzugriff meist zuerst die Drucktaste LESEN in der Archivadministra-tion (Transaktion SARA) auf. Dahinter verbergen sich in der Regel Pro-gramme, mit denen vom Benutzer ausgewählte Archivdateien sequenziellgelesen werden. Diese Programme wurden speziell für die Auswertungvon Archivdateien geschrieben und operieren in der Regel ausschließlichauf archivierten Daten. Die Anzeige der Daten erfolgt in den meisten Fäl-len in einer auf die Bedürfnisse des Endbenutzers abgestimmten Art.Diese Programme eignen sich insbesondere zur Kontrolle der archiviertenDaten.


Beispiel Ein Beispiel für ein solches sequenzielles Leseprogramm ist das zumArchivierungsobjekt CO_ORDER (Innenaufträge) gehörende ProgrammRKAARCS1, das ebenfalls über die oben genannte Drucktaste zur Verfü-gung steht. Nach der Eingabe der Selektionskriterien können Sie das Pro-gramm ausführen und erhalten das bereits oben (Abbildung 4.1) darge-stellte Dialogfenster zur Auswahl der Archivdateien. Dabei ist zubeachten, dass die Selektionskriterien keinen Einfluss darauf haben, wel-che Archivdateien zur Auswahl angeboten werden. Unabhängig von denSelektionskriterien werden immer alle zugreifbaren Dateien zur Auswer-tung angeboten. Sie sollten also darauf achten, dass die Auswahl derArchivdateien zu den gewählten Selektionskriterien passt. Wählen Sienicht alle relevanten Dateien aus, werden unter Umständen nicht allegewünschten Daten angezeigt. Da das Programm alle Dateien sequenziellliest, dürfen Sie dagegen auch nicht zu viele Archivdateien auswählen,denn dies führt dann zu längeren Antwortzeiten.

Das Leseprogramm liest nun die ausgewählten Archivdateien sequenzielldurch und filtert die Daten nach den angegebenen Selektionskriterien.Für die Laufzeit des Programms fallen die Selektionskriterien kaum insGewicht. Entscheidend ist die Auswahl der Archivdateien. Nach derSelektion wird der Inhalt der Archivdatei meist als Liste dargestellt. Imobigen Beispiel der Innenaufträge können Sie aus der erzeugten Listeweiternavigieren; dies ist aber eher untypisch für diese Art von Auswer-tungen.

Einplanung imHintergrund

Neben der Ausführung im Dialog können Sie ein Archivleseprogrammauch im Hintergrund einplanen. Die Einplanung entspricht im Wesentli-chen der manuellen Einplanung eines Löschprogramms. Der Unterschiedbesteht darin, dass das Leseprogramm eine Variante zur Übergabe derSelektionskriterien benötigt.

Programme mitnachträglicherweiterterArchivlese-

funktion

Während die über die Archivadministration verfügbaren Programme inder Regel dedizierte Archivleseprogramme sind, gibt es auch Programme,die ursprünglich für normale Auswertungen von Daten aus der Daten-bank entwickelt, jedoch nachträglich um Funktionen für Archivzugriffeerweitert wurden. Ein gewisser Nachteil dieser Programme ist, dass dieBenutzer wissen müssen, ob sich die Daten im Archiv befinden, und fallsja, in welcher Archivdatei sie gespeichert sind. Das Ergebnis dieser Müheist jedoch, dass die Daten in einem ihnen vertrauten Format dargestelltwerden. Ein Beispiel hierfür sind die Summenberichte (Report-Writer-Berichte) im Gemeinkosten-Controlling.

Direktzugriffe 147

Über die Drucktaste DATENQUELLE können Sie auf dem Selektionsbildeines solchen Programms festlegen, dass nicht aus der Datenbank, son-dern aus dem Archiv gelesen werden soll (siehe Abbildung 4.2). An dieserStelle werden auch die Archivdateien gewählt.

Technisch betrachtet, gehört die Auswahl der Datenquelle (Datenbankoder Archiv) sowie der zu lesenden Archivdateien zum Selektionsbild,obwohl die Angaben dazu nicht direkt auf dem Selektionsbild zu sehensind. Dies bedeutet, dass beim Speichern einer Selektionsvariante auchdie Datenquelle mit abgespeichert wird. Dies ermöglicht beispielsweisedas Anlegen einer Variante zur Auswertung bestimmter Archive im Hin-tergrund. In der Liste, die nach der Ausführung des Programms angezeigtwird, ist nicht mehr zu erkennen, ob es sich um Daten aus der Datenbankoder aus dem Archiv handelt.

4.4 Direktzugriffe

Das sequenzielle Lesen ganzer Archivdateien mit vorheriger manuellerDateiauswahl ist insbesondere dann sinnvoll, wenn ein großer Anteil derDaten in der Archivdatei gelesen werden soll und der Benutzer weiß, inwelchen Dateien sie sich befinden. Dies ist zum Beispiel dann der Fall,wenn der Inhalt einer Archivdatei überprüft werden soll. Für die meistenEndbenutzer eignen sich aber eher Funktionen, die möglichst wenig Wis-sen über die Archivierung erfordern. Am besten sind automatischeArchivzugriffe dafür geeignet. Zwar ist hier der Konfigurations- und Admi-nistrationsaufwand etwas höher, aber dem Endbenutzer wird die meisteArbeit abgenommen.

Abbildung 4.2 Auswahl der Datenquelle in Report-Writer-Berichten


Beispiel Ein Beispiel für eine solche Funktion bietet die Anzeige der Buchhaltungs-belege (Transaktion FB03). Diese können Sie über die Transaktion FB00so konfigurieren, dass ein automatischer Direktzugriff auf das Archiverfolgt, falls ein Beleg nicht in der Datenbank gefunden wird. Bei diesemBeispiel können Sie sogar konfigurieren, ob vor dem Archivzugriff einDialogfenster erscheinen soll, auf dem der Benutzer entscheidet, ob imArchiv gesucht werden soll oder nicht. Wird diese Abfrage ausgeschaltet,merkt der Benutzer unter Umständen gar nicht mehr, dass die angezeig-ten Daten bereits archiviert wurden. Insbesondere muss er sich nichtüberlegen, ob die Daten gegebenenfalls archiviert sein könnten, bevor erdie Transaktion ausführt.

Archivindex zurLokalisierung der

Daten

Die Information darüber, dass der gesuchte Beleg archiviert wurde und anwelcher Stelle er sich im Archiv befindet, wird im Archivindex gespei-chert. Mit Hilfe der Selektionskriterien des entsprechenden Programmswird aus dem Archivindex der Ort im Archiv (also die Archivdatei und derOffset) bestimmt, an dem sich die Daten befinden. Der Archivindex wirdanwendungsspezifisch in Datenbanktabellen abgelegt. Im vorliegendenBeispiel handelt es sich um die Datenbanktabelle ARIX_BKPF. In Tabelle4.1 sehen Sie die für das Beispiel relevanten Felder.

Wenn die Beleganzeige einen Beleg im Archiv sucht, greift sie zuerst aufdiese Datenbanktabelle zu. Anhand der Felder BUCHUNGSKREIS, BELEGNUM-MER und GESCHÄFTSJAHR ist sie in der Lage, die Archivdatei sowie den Offsetdes Business-Objekts, in dem sich der gesuchte Beleg befindet, zu ermitteln.Das Lesen im Archiv erfolgt dann per Direktzugriff. Das Programm liest alsonicht die ganze Archivdatei sequenziell durch, sondern positioniert beimÖffnen der Datei den Zeiger direkt auf den gewünschten Offset und liest nurdas in Frage kommende Business-Objekt. Diese Art des Archivzugriffs istwesentlich effizienter als das sequenzielle Lesen von archivierten Daten,wenn nur ein oder weniger Business-Objekte gelesen werden sollen.

Feld Beschreibung

BUKRS Buchungskreis

BELNR Belegnummer

GJAHR Geschäftsjahr

ARCHIV_KEY Schlüssel der Archivdatei

OFFST Offset des Business-Objekts

Tabelle 4.1 Die Tabelle ARIX_BKPF

Archivinformationssystem 149

Suche nur über Felder, die im Archivindex enthalten sind

Diese Methode ist allerdings nicht dafür geeignet, einen schnellen Zugriffanhand anderer Felder als der im Archivindex enthaltenen durchzufüh-ren. In unserem Beispiel kann über den Archivindex auf das Archiv nurzugegriffen werden, wenn Buchungskreis, Belegnummer und Geschäfts-jahr bekannt sind. Eine Suche über andere Felder des Belegs, zum Beispielüber das Konto, ist nicht möglich, da dieses Feld nicht im Archivindexenthalten ist.

Aufbau des Archivindex

Der Archivindex wird bei Archivierungsobjekten, die dieses Konzeptunterstützen, während der Löschphase automatisch aufgebaut. Ein nach-träglicher manueller Auf- und Abbau dieser Indexinformationen ist eben-falls möglich. Dazu erscheint bei Archivierungsobjekten, die diese Funk-tion unterstützen, im Einstiegsbild der Archivadministration dieDrucktaste INDEX.

Der automatische Aufbau während der Löschphase erfolgt nur, wenn derIndexaufbau im archivierungsobjektspezifischen Customizing durch Set-zen des gleichnamigen Kennzeichens aktiviert wurde. Dieses Kennzei-chen wird aber nur angeboten, wenn das Archivierungsobjekt die Index-funktion unterstützt. Durch Setzen des Kennzeichens erreichen Sie, dassder Archivindex bei künftigen Löschläufen automatisch aufgebaut wird.

Für Archivdateien, die das Löschprogramm vor dem Setzen dieses Kenn-zeichens bearbeitet hat, wurde kein Archivindex aufgebaut. Dies geht ausden Details zur jeweiligen Archivdatei hervor, die Sie der Archivverwal-tung entnehmen können. Für solche Archivdateien können Sie den nach-träglichen Indexaufbau starten. Dabei handelt es sich im Wesentlichenum ein sequenzielles Leseprogramm, das die gelesenen Daten jedochnicht ausgibt, sondern lediglich einen Extrakt davon erzeugt und ihn –angereichert mit dem Schlüssel der Archivdatei und dem Offset – in dieDatenbanktabelle des Archivindex schreibt.

4.5 ArchivinformationssystemNachteile konventioneller Zugriffsmethoden

Trotz vieler Vorteile weisen die bisher beschriebenen konventionellenZugriffsmethoden auch eine Reihe von Nachteilen auf, die hauptsächlichauf technische Einschränkungen sowie die Anwendungsabhängigkeit derMethoden zurückzuführen sind:

� Bei sequenziellen Zugriffen muss der Benutzer die richtigen Archiv-dateien kennen.

� Sequenzielle Zugriffe dauern zu lange, wenn nur einzelne Belege ausdem Archiv angezeigt werden sollen.


� Direktzugriffe über anwendungsspezifische Archivindizes sind nicht inallen Fällen implementiert.

� Anwendungsspezifische Direktzugriffe funktionieren nur über die vomEntwickler vorgesehenen Felder.

� Der Auf- und Abbau von Archivindizes ist anwendungsspezifisch. Esgibt zwar eine allgemeine Vorgehensweise des Auf- und Abbaus vonArchivindizes aus der Archivadministration, aber die Programme, dieden Auf- oder Abbau tatsächlich durchführen, sind anwendungsspezi-fisch.

Vorteile desArchiv-

informations-systems

Diese Nachteile entfallen bei Verwendung des Archivinformationssystems(AS). Dieses speziell für Archivzugriffe konzipierte Werkzeug ermöglichtIhnen, eigene Archivindizes zu konfigurieren, sie mit Daten aus demArchiv zu füllen und nach archivierten Daten zu recherchieren. Genausowie bei einem anwendungsspezifischen Archivindex werden auch hierArchivdatei und Offset ergänzt, was einen Direktzugriff auf die archivier-ten Daten erlaubt. Zusätzlich bietet das Archivinformationssystem einegenerische, also nicht anwendungsspezifische, Anzeige aller Inhalte einesBusiness-Objekts aus dem Archiv. Es funktioniert mit allen, also auch kun-deneigenen, Archivierungsobjekten und erfordert keine anwendungsspe-zifischen Programme oder Modifikationen.

Werkzeug derWahl für

Archivzugriffe

Das Archivinformationssystem ist also das Werkzeug, wenn es um denschnellen Zugriff auf archivierte Daten geht. Allerdings ist hier dem Begriff»Werkzeug« besondere Beachtung zu schenken: Durch die generischeAusrichtung des Archivinformationssystems können anwendungsspezifi-sche Besonderheiten nicht bzw. nur teilweise berücksichtigt werden. Eshandelt sich also um ein eher technisches Werkzeug, das den Bedürfnis-sen des Endanwenders nicht in jeder Hinsicht genügen kann.

Archivinforma-tionsstruktur

Der zentrale Begriff im Umfeld des Archivinformationssystems ist dieArchivinformationsstruktur.1 Dieser Begriff ersetzt gewissermaßen denoben eingeführten Begriff des Archivindex. Jeder Archivzugriff durch dasArchivinformationssystem erfolgt über eine Infostruktur. Infostrukturenwerden mit Hilfe des Archive Retrieval Configurator, der Customizing-Komponente des Archivinformationssystems, angelegt. Das Füllen derDaten in die Infostruktur erfolgt – analog zu den Archivindizes – entwe-der direkt während der Löschphase oder nachträglich durch den Benut-zer. Wie auch bei einem Archivindex werden die Daten zu einerInfostruktur in einer Datenbanktabelle gehalten. Eine weitere Kompo-

1 Wegen der besseren Lesbarkeit wird im Folgenden die Kurzform »Infostruktur«dafür verwendet.


nente des Archivinformationssystems, der Archive Explorer, unterstütztdie Datensuche innerhalb einer Infostruktur und ermöglicht Direktzu-griffe auf die archivierten Daten und letztlich deren Anzeige.

FeldkatalogJede Infostruktur gehört nicht nur eindeutig zu einem Archivierungsob-jekt, sie bezieht sich auch eindeutig auf einen bestimmen Feldkatalog. EinFeldkatalog ist im Wesentlichen eine Sammlung von Feldern, die für dieIndizierung der Archivdateien des betreffenden Archivierungsobjektsgeeignet sind. Die Felder einer Infostruktur sind immer eine Auswahl derFelder des zugehörigen Feldkatalogs. Außerdem enthält der Feldkatalogeine Reihe von technischen Eigenschaften, die ebenfalls in die Infostruk-tur übernommen werden. Durch das Konzept der Feldkataloge ist es zumAnlegen einer Infostruktur nicht notwendig, technische Einzelheiten desArchivierungsobjekts zu kennen, da diese im Feldkatalog bereits abgelegtsind. Zum Anlegen einer Infostruktur muss der Benutzer lediglich die Fel-der auswählen.

Im Folgenden werden der Einsatz des Archivinformationssystems undeinige Hintergründe dazu beschrieben. Die einzelnen Schritte sind in derReihenfolge aufgeführt, in der sie der Benutzer oder Administrator norma-lerweise ausführt, wenn das Archivinformationssystem für ein Archivie-rungsobjekt erstmalig eingesetzt werden soll. Sämtliche hier aufgeführtenFunktionen sind über die zentrale Verwaltung des Archivinformationssys-tems (Transaktion SARI) zu erreichen. Weitergehende Informationen zumArchivinformationssystem bietet Ihnen die Hilfe zur Anwendung.

4.5.1 Anlegen einer Infostruktur

Standard-Infostrukturen nicht ändern

Bevor Sie eine eigene Infostruktur anlegen, sollten Sie prüfen, ob bereitseine Infostruktur vorhanden ist, die Sie zur Auswertung der archiviertenDaten verwenden können. Diese Infostruktur können Sie bei Bedarfkopieren und an eigene Anforderungen anpassen. Sie sollten aber keinevon SAP ausgelieferten Infostrukturen ändern. Eine solche Änderungbedeutet eine Modifikation und wird beim nächsten Upgrade oder beider Installation von Support Packages unter Umständen rückgängiggemacht.

Felder übernehmen

Beim Anlegen einer Infostruktur legen Sie fest, welche Felder aus demArchiv in die Infostruktur übernommen werden. Dazu wählen Sie diegewünschten Felder aus einem Feldkatalog aus und übernehmen diese indie Infostruktur (siehe Abbildung 4.3). Zu vielen Archivierungsobjekten


sind bereits Feldkataloge in der Standardauslieferung enthalten. Falls fürIhre Anforderungen kein Feldkatalog existiert, können Sie einen eigenenanlegen. Näheres dazu finden Sie in Abschnitt 4.5.6.

Schlüsselfelder Einige Felder des Feldkatalogs werden aus technischen Gründen sofort indie Infostruktur übernommen und können nicht entfernt werden. Meisthandelt es sich dabei um die Schlüsselfelder. Die meisten Felder einesFeldkatalogs gehören jedoch zum Vorrat der wählbaren Felder, die Sie indie Infostruktur übernehmen können. Über alle Felder der Infostrukturkönnen Sie später nach archivierten Daten suchen. Beachten Sie jedoch,dass Infostrukturen in der Datenbank abgelegt werden und somit auchjedes weitere Feld, das in die Infostruktur übernommen wird, zusätzli-chen Platz in der Datenbank beansprucht.

Abbildung 4.3 Anlegen einer Infostruktur im Archive Retrieval Configurator


4.5.2 Aktivieren einer Infostruktur

Um eine Infostruktur verwenden zu können, müssen Sie sie aktivieren.Erst wenn eine Infostruktur aktiv ist, kann sie mit Daten aus dem Archivgefüllt und ausgewertet werden. Aktive Infostrukturen können jedochnicht mehr geändert werden.

Datenbanktabelle für Indexdaten

Wie es schon beim Konzept der anwendungsspezifischen Archivindizesder Fall war, benötigt auch das Archivinformationssystem eine Daten-banktabelle, um die Indexdaten zu speichern. Diese ist allerdings nichtfest vorgegeben, sondern wird beim Aktivieren der Infostruktur anhandder verfügbaren Informationen generiert. Die Felder dieser Tabelle setzensich zusammen aus

� dem Mandanten

� den Feldern der Infostruktur

� dem Schlüssel der Archivdatei

� dem Offset des Business-Objekts in der Archivdatei

Für das obige Beispiel sieht die generierte Datenbanktabelle aus, wie inAbbildung 4.4 dargestellt.

Auswertungs-programm

Zur Auswertung dieser Tabelle und für den Zugriff aufs Archiv zur Anzeigeder archivierten Daten wird außerdem ein Auswertungsprogramm gene-riert. Nach der Generierung der Datenbanktabelle und des Auswertungs-programms setzt das System für die betreffende Infostruktur ein Aktiv-Kennzeichen. Dieses Kennzeichen besagt, dass die Infostruktur nun fürAuswertungen genutzt werden kann und dass sie während des Laufs desentsprechenden Löschprogramms automatisch aufgebaut werden soll.

Abbildung 4.4 Datenbanktabelle zur Infostruktur


4.5.3 Aufbau einer Infostruktur

Während der Löschphase der Datenarchivierung werden alle zu einemArchivierungsobjekt gehörenden aktiven Infostrukturen automatisch mitDaten aus der betreffenden Archivdatei gefüllt. Ausgehend von der defi-nierten Infostruktur, filtert das Archivinformationssystem die Daten ausden Datensätzen im Archiv und fügt sie zusammen mit dem Schlüssel derArchivdatei und dem Offset des Business-Objekts in die generierteDatenbanktabelle ein. Diese Einträge dienen als Grundlage für die spä-tere Recherche.

NachträglicherAufbau

Neben dem automatischen Aufbau durch das Löschprogramm kann eineInfostruktur auch nachträglich für schon vorhandene Archive aufgebautwerden. Sie haben somit die Möglichkeit, Infostrukturen bei Bedarf auf-zubauen, etwa um Daten auszuwerten, die bereits vor der Einführung desArchivinformationssystems archiviert wurden, oder um die Felder einerInfostruktur zu ändern.

Aufbaustatus Beim Aufbau einer Infostruktur erfolgt neben dem Füllen der generiertenDatenbanktabelle mit Daten aus dem Archiv auch die Führung eines Auf-baustatus. Anhand dieses Status können Sie in der Statusverwaltung desArchivinformationssystems erkennen, für welche Archivdateien die zuge-hörigen Infostrukturen aufgebaut wurden.

4.5.4 Auswerten einer Infostruktur

Auswertungs-programm als

Grundlage

Die Suche nach archivierten Daten im Archive Explorer erfolgt stets aufder Grundlage des beim Aktivieren der Infostruktur erzeugten Auswer-tungsprogramms. Das Selektionsbild des Auswertungsprogramms enthältalle Felder der Infostruktur, außer den Feldern MANDANT, SCHLÜSSEL DER

ARCHIVDATEI und OFFSET. Bei Ausführung des Programms erhalten Sie eineListe aller Einträge in der Infostruktur, die zu Ihren Selektionskriterienpassen. Bis zu diesem Punkt im Auswertungsprozess ist noch kein Zugriffaufs Archiv erfolgt; das System hat lediglich die in der Infostruktur gespei-cherten Indexdaten gelesen. Per Doppelklick auf einen Listeneintrag kön-nen Sie nun einen Direktzugriff ins Archiv vornehmen und in der Daten-hierarchie bis auf Feldebene hinunternavigieren.

Technische undbetriebswirt-

schaftlicheSichten

Die vom Archive Explorer gezeigte Sicht der Daten ist sehr technisch unddaher für Endanwender weniger geeignet. Eine solche technische Sichtstellt das Archivinformationssystem für jedes Archivierungsobjekt zur Ver-fügung. Zum Anpassen der Anzeige an die Anforderungen der Endanwen-der hat SAP das Konzept der betriebswirtschaftlichen Sichten eingeführt.


Dieses Konzept besagt, dass die archivierten Daten in einer Form darge-stellt werden, wie sie der Endanwender erwarten würde bzw. die er vonder Anzeige der betreffenden Daten aus der Datenbank kennt. Inwieferndiese Art der Darstellung unterstützt wird, hängt vom Archivierungsobjektab. Die meisten Archivierungsobjekte haben gar keine betriebswirtschaft-liche Sicht im Archivinformationssystem, während beispielsweise zumArchivierungsobjekt CO_ORDER sogar mehrere betriebswirtschaftlicheSichten ausgeliefert werden. Beim Doppelklick auf einen Eintrag derInfostruktur werden Sie erst zur Auswahl der gewünschten Sicht aufgefor-dert, wie in Abbildung 4.5 dargestellt.

Ad-hoc-Auswertungen

Die normale Auswertung einer Infostruktur durch den Archive Explorersetzt voraus, dass die Infostruktur vorher aufgebaut wurde. Das bedeutet,dass nur Dateien, die den Status »Löschen fertig« haben, ausgewertet wer-den können. Das ist auch sinnvoll, da alle anderen Daten prinzipiell nochin der Datenbank sind, also kein Grund besteht, diese Daten im Archiv zusuchen. Möglicherweise möchten Sie aber im Vorfeld der Löschphase diearchivierten Daten nur überprüfen. Zu diesem Zweck steht Ihnen dieFunktion AD-HOC-AUSWERTUNG zur Verfügung. Bei dieser Art der Auswer-tung greift das System nicht auf die generierte Datenbanktabelle zu, son-dern führt einen sequenziellen Lesezugriff auf die von Ihnen gewähltenArchivdateien durch. Der Datenbestand, der sonst beim Aufbau einerInfostruktur anfallen würde, wird lediglich intern gespeichert. Die nachfol-gende Anzeige der Daten und die Navigationsmöglichkeiten entsprechendann denen einer normalen Auswertung einer Infostruktur.

Abbildung 4.5 Auswahl einer Sicht für archivierte CO-Aufträge

Die Auswertung aufgebauter Infostrukturen mit dem Archive Exploreroder auch andere Zugriffe auf das Archivinformationssystem (sieheAbschnitt 4.6) sind dann besonders schnell, wenn das System überden Primärindex der zugehörigen Datenbanktabelle zugreifen kann.


Datenbankindizesfür Infostrukturen

4.5.5 Abbau einer Infostruktur

Die in einer generierten Datenbanktabelle gespeicherten Daten benöti-gen – wie Daten in anderen Datenbanktabellen auch – Plattenplatz. Ausdiesem Grund ist es im Allgemeinen sinnvoll, Daten für ältere Archivda-teien nach einer bestimmten Zeit wieder zu löschen. Da die Quelldatenbereits archiviert wurden, kommt eine Archivierung dieser Daten nichtmehr in Betracht. Grundsätzlich haben Sie jedoch die Möglichkeit,Infostrukturen manuell wieder abzubauen. Diese Funktion liefert Ihnendie zusätzliche Flexibilität, Infostrukturen je nach Bedarf auf- bzw. abzu-bauen, beispielsweise wenn die Archivzugriffe nicht ständig benötigtwerden.

ExplizitesAbbauen

Im Gegensatz zum Aufbau von Infostrukturen gibt es für den Abbau keineIntegration mit dem ADK. Das bedeutet, dass der Abbau immer explizitangesteuert werden muss. Dies ist insbesondere beim Zurückladen vonArchiven zu beachten. Wenn Sie archivierte Daten zurückladen, müssenSie aktive Infostrukturen für die entsprechenden Dateien explizitabbauen und für die beim Rückladeprozess gegebenenfalls entstandenenArchivdateien die Infostrukturen explizit aufbauen.

Für Zugriffe über andere Felder als die des Primärindex werden unterUmständen zusätzliche Datenbankindizes benötigt. Da die Tabellendes Archivinformationssystems im Produktivsystem generiert werden,ist das Anlegen eines solchen Index über das ABAP-Dictionary in denmeisten Fällen nicht durchführbar. Außerdem könnte es passieren,dass bei einer Neugenerierung der Datenbanktabelle der Index wiedergelöscht wird.

Für diesen Fall bietet das Archivinformationssystem die Möglichkeit,Informationen zu den gewünschten Datenbankindizes in die Defini-tion einer Infostruktur aufzunehmen. Dabei können Sie zu SAP-Stan-dardinfostrukturen auch kundeneigene Indizes anlegen, indem Sie dieIndex-ID und die zugehörigen Felder in die Tabelle AIND_STR8 eintra-gen. Nähere Informationen dazu finden Sie im SAP-Hinweis 164704.


4.5.6 Anlegen eines Feldkatalogs

Standardfeldkata-loge nicht ändern

Für viele Anwendungsfälle werden Standardfeldkataloge von SAP ausgelie-fert. Diese erkennen Sie an ihrem Namen, der mit »SAP_« beginnt. BevorSie also eigene Feldkataloge anlegen, sollten Sie auf jeden Fall prüfen, obSie nicht doch einen Standardfeldkatalog benutzen können. Auf keinen Fallsollten Sie einen Standardfeldkatalog modifizieren, auch nicht durch Auf-nahme neuer Felder. Bei einem Release-Wechsel oder bei der Installationvon Support Packages kann es vorkommen, dass Standardfeldkatalogeüberschrieben werden. Außerdem gehen manche Programme davon aus,dass die Feldkataloge genauso aussehen, wie sie ausgeliefert wurden.

Sie können jedoch einen Standardfeldkatalog in Ihren eigenen Namens-raum kopieren und die gewünschten Änderungen an der Kopie vorneh-men. Sie sollten allerdings auch bedenken, dass Standardprogramme inder Regel Infostrukturen, die auf der Basis kundeneigener Feldkatalogeerstellt wurden, ignorieren. Solche Infostrukturen können Sie also meistnur im Archive Explorer und in eigenen Programmen nutzen.

Expertenwissen erforderlich

Das Anlegen eines Feldkatalogs setzt ein bestimmtes Expertenwissenvoraus. So müssen Sie beispielsweise wissen, welche Tabellen mit einembestimmten Archivierungsobjekt archiviert werden und aus welchen Ein-trägen dieser Tabellen ein Business-Objekt jeweils besteht. Diese Zusam-menhänge sollten Sie kennen, bevor Sie für ein Archivierungsobjekt einenneuen Feldkatalog anlegen. Dies ist insbesondere für die Abschätzung derzu erwartenden Datenmenge und für Feldkataloge mit mehreren Quell-tabellen wichtig.

Ein Beispiel für Finanzbuchhal-tungsbelege

Im Folgenden wird ein typisches Vorgehen beschrieben, das für die meis-ten Fälle angewandt werden kann. Dabei wird zwischen Feldkatalogenmit einer und mit mehreren Quelltabellen unterschieden. Wie Sie beimAnlegen eines Feldkatalogs im Einzelnen vorgehen und welche Bedeu-tung die jeweiligen Felder und Kennzeichen haben, können Sie der Hilfezur Anwendung sowie der Feldhilfe entnehmen. Bei der nachfolgendenVorgangsbeschreibung gehen wir daher davon aus, dass Sie die Bedeu-tung der einzelnen Felder kennen und dass Sie sich mit der Art, wie Ein-träge vorgenommen werden, vertraut gemacht haben.

Als Beispiel soll uns ein Feldkatalog für Finanzbuchhaltungsbelege die-nen, die mit Hilfe des Archivierungsobjekts FI_DOCUMNT archiviert wer-den. Ein solcher Beleg besteht unter anderem aus einem Belegkopf undmehreren Positionen. Der Belegkopf ist in der Tabelle BKPF gespeichert,die Positionen befinden sich in der Tabelle BSEG.


4.5.6.1 Anlegen eines Feldkatalogs mit einer Quelltabelle

1. Auswahl der QuelltabelleDas Archivinformationssystem kann zum Füllen einer Infostruktur jedeTabelle und jede Struktur verwenden, die in den entsprechendenArchivdateien gespeichert ist. Welche der Tabellen eines Archivie-rungsobjekts verwendet wird, hängt davon ab, über welche Felder Sienach archivierten Objekten suchen möchten. Beachten Sie jedoch,dass eine Suche über die Felder einer Positionstabelle grundsätzlichmehr Platz in der Datenbank benötigt als die Suche in einer Kopfta-belle. Dies liegt daran, dass eine Positionstabelle im Allgemeinen mehrEinträge besitzt als eine Kopftabelle. Außerdem enthält die generierteDatenbanktabelle nach dem Aufbau der Infostruktur in der Regelgenauso viele Einträge, wie es Einträge der führenden Tabelle des Feld-katalogs in den Archivdateien gibt.

In unserem Beispiel wurde die Tabelle BKPF des ArchivierungsobjektsFI_DOCUMNT gewählt. Es soll möglich sein, nach den Feldern BELEG-NUMMER, GESCHÄFTSJAHR und BUCHUNGSDATUM zu suchen.

2. Name des FeldkatalogsDer Name eines Feldkatalogs unterliegt denselben Beschränkungenwie die Namen anderer Systemobjekte, zum Beispiel Datenbanktabel-len. Verwenden Sie nur Buchstaben, Zahlen und den Unterstrich. DerName sollte mit einem Buchstaben beginnen, aber nicht mit dem Kür-zel »SAP«. Es wird empfohlen, einen Namen im eigenen Namensraumzu verwenden.

In unserem Beispiel wählen wir »ZDEMO_BKPF« als Namen.

3. Kopfeintrag des FeldkatalogsGeben Sie den Namen, die Bezeichnung und das Archivierungsobjektdes neuen Feldkatalogs ein. Tragen Sie in der Spalte DATEI IM INDEX ein»K« (Schlüsselfeld) und in der Spalte OFFSET IM INDEX ein »D« (Daten-feld) ein.

4. Schlüsselfelder des FeldkatalogsFür die meisten Fälle ist es sinnvoll, alle Schlüsselfelder der Referenz-tabelle, mit Ausnahme des Mandanten, als Schlüsselfelder des Feldka-talogs zu verwenden. Es wird empfohlen, als Feldnummern die Num-mern 10, 20, 30 usw. zu verwenden. Auf jeden Fall sollten Siesicherstellen, dass die Nummern der Schlüsselfelder kleiner als dieNummern der Datenfelder sind. Ebenso ist es empfehlenswert, alsFeldnamen den auch in der Referenztabelle verwendeten Feldnamenzu verwenden.


Stellen Sie sicher, dass die Kennzeichen OBLIGATORISCHES SCHLÜSSELFELD

und WÄHLBARES FELD für Schlüsselfelder nicht gesetzt sind. Das Kenn-zeichen KEY muss für Schlüsselfelder gesetzt sein.

Im Beispiel wurden alle Schlüsselfelder der Tabelle BKPF (außer demMandanten) als Schlüsselfelder in den Feldkatalog aufgenommen.

5. Datenfelder des FeldkatalogsIn den meisten Fällen ist es sinnvoll, alle Datenfelder der Referenzta-belle zu Datenfeldern des Feldkatalogs zu machen. Für die Nummerie-rung der Datenfelder wird empfohlen, die Nummern 100, 110, 120usw. zu verwenden. Stellen Sie sicher, dass die Kennzeichen KEY undOBLIGATORISCHES SCHLÜSSELFELD für Datenfelder nicht gesetzt sind. DasKennzeichen WÄHLBARES FELD sollte für Datenfelder eingeschaltet sein.

Bei den Datenfeldern ist es in der Regel sinnvoll, möglichst viele Felderder Referenztabelle in den Feldkatalog aufzunehmen. Ein weiteresDatenfeld in einem Feldkatalog kostet, im Gegensatz zur Aufnahmeeines Felds in eine Infostruktur, weder nennenswerten Speicherplatznoch Laufzeit. Allerdings sollten Sie nur Felder in den Feldkatalog auf-nehmen, die auch als Selektionskriterien von Programmen funktionie-ren. Insbesondere sollten also keine Felder des Datentyps FLTP (Gleit-kommazahl) verwendet werden. Auch Felder der Datentypen CURRund QUAN sollten weggelassen werden, da diese im Allgemeinenfalsch aufbereitet werden. Weitere Informationen zu diesen Daten-typen finden Sie im SAP-Hinweis 309384.

4.5.6.2 Anlegen eines Feldkatalogs mit mehreren Quelltabellen

1. Auswahl der QuelltabellenFür die Auswahl mehrer Quelltabellen gilt das Gleiche wie für die Aus-wahl einer Quelltabelle. Zusätzlich ist aber darauf zu achten, dass dieQuelltabellen gewissen Abhängigkeitsbedingungen genügen müssen.Tabellen, die in keinem Verhältnis zueinander stehen, können auchnicht gemeinsam in einem Feldkatalog verwendet werden. In der Regelsollten Sie Tabellen wählen, die gemeinsam zu einem Beleg gehören,wie zum Beispiel Belegkopf und Belegposition, oder die zumindestüber gemeinsame Felder verknüpft werden können.

Bezogen auf unser Beispiel zum Archivierungsobjekt FI_DOCUMNT,sind dies die Tabellen BKPF und BSEG.

2. Ermittlung der AbhängigkeitenDie Verwendung mehrerer Quelltabellen durch das Archivinforma-tionssystem ist nur möglich, wenn die Tabellen in einer hierarchischen


Abhängigkeitsbeziehung stehen. Welche Tabelle von welcher abhängigist, wird über Schlüsselfelder mit gleicher Semantik definiert. In derRegel verfügen diese Felder in den verschiedenen Tabellen über den-selben Namen. Für die Definition eines Feldkatalogs muss es möglichsein, alle Quelltabellen so anzuordnen, dass jede Tabelle, die von eineranderen Tabelle abhängt, auch deren Schlüsselfelder als Schlüsselfelderbesitzt.

Im Beispiel der Finanzbuchhaltungsbelege sind die Tabellen BKPF undBSEG über die Felder BUCHUNGSKREIS, BELEGNUMMER und GESCHÄFTS-JAHR verbunden. Einträge aus BKPF und BSEG, die in diesen Felderngleich sind, gehören zusammen. Die Tabelle BSEG ist abhängig von derübergeordneten Tabelle BKPF und enthält deren Schlüsselfelder alsSchlüsselfelder.

3. Ermittlung der führenden TabelleNach der Ermittlung möglicher Beziehungen zwischen den beteiligtenTabellen werden Sie feststellen, dass in der Regel mindestens eineTabelle in Frage kommt, die alle Schlüsselfelder des Feldkatalogs alseigene Felder hat. Möglicherweise gibt es auch mehrere Tabellen mitdieser Eigenschaft. Dies ist dann der Fall, wenn mindestens zwei Tabel-len exisitieren, die gleich viele Schlüsselfelder im Feldkatalog haben. Ineinem solchen Fall können Sie eine beliebige der in Frage kommendenTabellen als führende Tabelle wählen.

Gibt es jedoch keine Tabelle, die alle Schlüsselfelder des Feldkatalogsals eigene Felder hat, können Sie den Feldkatalog auf diese Weise nichtanlegen. In diesem Fall müssen Sie andere Quelltabellen wählen oderdie Beziehungen zwischen den Tabellen überprüfen. In unserem Bei-spiel handelt es sich dabei um die Tabelle BSEG.

4. Anlegen des Feldkatalogs für die führende TabelleIgnorieren Sie vorerst alle Tabellen, außer der führenden. Legen Sie denFeldkatalog wie in Abschnitt 4.5.6.2 beschrieben an. Im Beispiel wirdzuerst ein Feldkatalog zur Quelltabelle BSEG angelegt.

5. Schrittweises Ergänzen der anderen Tabelle(n)Für alle anderen Tabellen müssten zu diesem Zeitpunkt schon alleSchlüsselfelder im Feldkatalog sein. Sollte dies nicht der Fall sein,haben Sie entweder bei der Ermittlung der Tabellenabhängigkeiteneinen Fehler gemacht oder Sie haben im letzten Schritt nicht die rich-tige Tabelle ausgewählt.

Wählen Sie nun eine beliebige der verbliebenen Tabellen aus und tra-gen Sie deren Schlüsselfelder als weitere Quellfelder beim entsprechen-


den Schlüsselfeld des Feldkatalogs ein. Übertragen auf unser Beispiel,heißt dies, dass das Feld BUKRS der Tabelle BKPF als weiteres Quellfelddes Felds BUKRS, BKPF-BELNR als weiteres Quellfeld für BELNR sowieBKPF-GJAHR als weiteres Quellfeld für GJAHR eingetragen wird. (ZumFeld BUZEI gibt es keine Entsprechung in der Tabelle BKPF.)

Tragen Sie anschließend jedes Datenfeld der Tabelle als neues Daten-feld in den Feldkatalog ein. Beachten Sie dabei dieselben Einschrän-kungen für Felder des Feldkatalogs, wie sie auch für Feldkataloge mitnur einer Quelltabelle gelten.

Wiederholen Sie diesen Schritt für jede noch aufzunehmende Tabelle.

4.5.6.3 Typische Fallstricke beim Anlegen von Feldkatalogen

Wenn Sie einen Feldkatalog wie oben beschrieben anlegen, sollte es inden meisten Fällen keine Fehler beim Aufbau der zugehörigen Infostruk-turen geben. In einigen Fällen kommt es unter Umständen aber doch zuProblemen, die bisher noch nicht besprochen wurden. Dies möchten wirim Folgenden anhand zweier typischer Fehlerszenarien nachholen.

Fehlerszenario 1: »Sätze in Infostruktur nicht eingefügt«Es kann vorkommen, dass während der Löschphase oder beim nachträg-lichen Aufbau einer Infostruktur die Fehlermeldung »Sätze in Infostrukturnicht eingefügt« (Q6330) erscheint. Neben den anderen im Langtext die-ser Meldung erwähnten Ursachen kann auch ein fehlerhafter Feldkatalogdafür verantwortlich sein. Dies liegt dann daran, dass der Schlüssel desFeldkatalogs nicht vollständig definiert wurde bzw. nicht zur Struktur derArchivdateien passt. Die oben beschriebene Vorgehensweise beruht aufder Annahme, dass die Tabelleneinträge, die durch den im Feldkatalogangegebenen Schlüssel definiert wurden, in einer Archivdatei nicht mehr-fach vorkommen. Ist dies dennoch der Fall, kommt es bei dem Versuch,die entsprechenden Sätze in die generierte Datenbanktabelle einzufügen,zu dem beschriebenen Fehler.

LösungZur Lösung dieses Problems kommen prinzipiell zwei Strategien inBetracht: Einerseits können Sie versuchen, den Schlüssel des Feldkatalogsdurch Ergänzen weiterer Schlüsselfelder eindeutig zu machen. Anderer-seits besteht die Möglichkeit, das Business-Objekt selbst, also den Offsetin der Archivdatei, zum Schlüsselfeld zu machen. Dies erreichen Sie durchEintragen eines »K« in der Spalte OFFSET IM INDEX im Kopfeintrag desFeldkatalogs. Dadurch wird der Offset zum Schlüsselfeld der generiertenDatenbanktabelle.


Fehlerszenario 2: »Infostruktur ist inkonsistent«Erscheint hingegen während der Löschphase oder beim nachträglichenAufbau einer Infostruktur die Meldung »Infostruktur ist inkonsistent«(Q6234), liegt das meistens nicht an der Infostruktur selbst, sondern ander Definition des Feldkatalogs. Wie oben bereits dargelegt, müssenFeldkataloge mit mehreren Quelltabellen bestimmten Konsistenzbedin-gungen genügen. So müssen die Quelltabellen so sortiert werden, dassdie Schlüsselfelder jeder Quelltabelle eine Untermenge der Schlüsselfel-der der vorhergehenden Quelltabelle in der Sortierreihenfolge sind.

Lösung Überprüfen Sie daher, ob die weiteren Quellfelder für alle Schlüsselfelderrichtig eingegeben wurden und ob der Feldkatalog nach der oben ange-gebenen Vorgehensweise erstellt wurde. Möglicherweise müssen Sie eineQuelltabelle aus dem Feldkatalog entfernen, um die Konsistenz des Feld-katalogs herzustellen.

4.6 Auf dem Archivinformationssystem basierende Archivzugriffe

Im Kapitel über Direktzugriffe wurde eine Möglichkeit beschrieben, beider ein Endbenutzer auf archivierte Daten zugreifen kann, ohne Näheresüber die Archivierung wissen zu müssen, beziehungsweise ohne zu wis-sen, ob sich die Daten im Archiv oder noch in der Datenbank befinden.Das System ermittelt bei solchen Zugriffen selbständig, ob sich die Datenim Archiv befinden und in welcher Archivdatei sie gespeichert sind. DerArchivzugriff erfolgt dann in der Regel automatisch durch das System,ohne Interaktion mit dem Benutzer. Der Vorteil solcher Zugriffe ist diekonsequente Integration archivierter Daten in die gewohnte Anzeige-transaktion. Allerdings ist bei der oben beschriebenen Lösung ein anwen-dungsspezifisches Konzept zur Indizierung archivierter Daten notwendig.

Beim Archivinformationssystem verhält es sich genau umgekehrt: Es han-delt sich um ein einheitliches Verfahren zur Indizierung archivierterDaten, bei dem jedoch keine ausreichende Integration mit den gewohn-ten Anzeigetransaktionen stattfindet.

Mit Hilfe der Programmierschnittstelle des Archivinformationssystems istes möglich, aus einem Programm auf die Daten einer Infostruktur zuzu-greifen und diese wie einen anwendungsspezifischen Archivindex zu nut-zen. Dies ermöglicht die Integration archivierter Daten in die gewohnteAnwendungstransaktion, ohne den Nachteil verschiedener anwendungs-spezifischer Indexlösungen in Kauf nehmen zu müssen.

Auf dem Archivinformationssystem basierende Archivzugriffe 163

BeispielEin Beispiel für eine solche Funktionalität stellen die Einzelpostenberichteder Kostenrechnung in SAP R/3 Enterprise dar. Abbildung 4.6 zeigt denEinzelpostenbericht für Innenaufträge (KOB1) mit den Einzelposten einesarchivierten Innenauftrags. Aus ihm ist nicht mehr ersichtlich, ob dieDaten aus der Datenbank oder aus dem Archiv stammen. Der Benutzermuss dies auch nicht wissen, um sich die Einzelposten anzeigen zu lassen.

Standardmäßig greifen die Einzelpostenberichte der Kostenrechnungnicht automatisch auf archivierte Daten zu. Dies muss dem System erstüber die Tabelle ASACCESS01 mitgeteilt werden. Hier lässt sich einstel-len, ob der Bericht grundsätzlich nur von der Datenbank liest oder überdas Archivinformationssystem automatisch die archivierten Daten miteinbezieht.

Damit die Berichte über das Archivinformationssystem archivierte Datenfinden können, müssen entsprechende Infostrukturen aufgebaut sein.Hier kommt es darauf an, dass eine Infostruktur zu einem bestimmten,von SAP ausgelieferten Standardfeldkatalog aktiviert und aufgebautwurde.

Standardfeldkata-log verwenden

Im oben gezeigten Beispiel wurden die Einzelposten mit dem Archivie-rungsobjekt CO_ITEM archiviert. Aus diesem Grund wird eine Infostruk-tur zu einem der Feldkataloge SAP_CO_ITEM_001 oder SAP_CO_ITEM_002 benötigt. Im Beispiel wurde eine Infostruktur zum Feldkatalog SAP_CO_ITEM_001 verwendet. Entscheidend ist hier nicht die Verwendungeiner von SAP ausgelieferten Infostruktur, sondern die Verwendung eines

Abbildung 4.6 Einzelpostenbericht für Aufträge


passenden, von SAP ausgelieferten Feldkatalogs. Infostrukturen, die mitBezug auf kundeneigene Feldkataloge angelegt wurden, werden von denEinzelpostenberichten ignoriert. Ein Grund dafür ist, dass die Anwendung– in diesem Fall der Einzelpostenbericht – die Anwesenheit bestimmterFelder mit einer bestimmten Bedeutung im Feldkatalog voraussetzt. Beider Verwendung kundeneigener Feldkataloge wäre dies nicht mit ausrei-chender Sicherheit gegeben. Es ist allerdings möglich, neben der für dieEinzelpostenberichte benötigten Infostruktur eine weitere Infostrukturmit Bezug auf einen anderen Feldkatalog zu verwenden. Diese ist für denEinzelpostenbericht unproblematisch, verbraucht aber zusätzlichen Spei-cherplatz in der Datenbank.

Ein solcher Archivzugriff verläuft im Wesentlichen wie das Lesen einesanwendungsspezifischen Index, mit dem Unterschied, dass statt von deranwendungsspezifischen Indextabelle von einer geeigneten Infostrukturgelesen wird. Obwohl sich hinter der Infostruktur auch eine Datenbank-tabelle verbirgt, sind deren Felder nicht fest vorgegeben, sondern werdenerst bei der Konfiguration der Infostruktur ausgewählt.

Ein weiterer Unterschied zwischen dem vorgestellten Einzelpostenberichtund einem Direktzugriff – etwa zur Anzeige der Buchhaltungsbelege(Transaktion FB03) – besteht darin, dass beim Einzelpostenbericht oftmehrere Business-Objekte aus dem Archiv gelesen werden, die dannüber die Selektionskriterien weiter gefiltert werden. Es handelt sich hiergewissermaßen um einen indexsequenziellen Zugriff.

4.7 Document Relationship BrowserDaten aus dem

Archiv und aus derDatenbank

Der Document Relationship Browser (DRB) dient zur Anzeige miteinan-der verknüpfter Business-Objekte. In der Regel handelt es sich dabei umBelege, die bei einem gemeinsamen Geschäftsvorfall entstanden sindoder die zu einem gemeinsamen Prozess gehören. Dabei ist der DRBnicht auf eine spezielle Anwendung beschränkt, sondern liefert ver-knüpfte Belege aus verschiedenen Anwendungsbereichen. Außerdem lie-fert der DRB auch eine für den Endanwender einfache Integration überSystemgrenzen hinweg, etwa beim Einsatz verschiedener ALE-Szenarien(Application Link Enabling).

Eine weitere Stärke des DRB ist die Anzeige archivierter Objekte, sein Ein-satz ist aber auch dann sinnvoll, wenn die Datenarchivierung noch nichtgenutzt wird. In diesem Kapitel möchten wir vor allem auf die Fähigkeitendes DRB in Bezug auf archivierte Daten eingehen. Wie Sie weitere Informa-tionen zum DRB erhalten, können Sie im SAP-Hinweis 492938 nachlesen.

Document Relationship Browser 165

Archivinforma-tionssystem als Basis

Bei den im Rahmen des DRB vorgenommenen Archivzugriffen handelt essich stets um automatische Zugriffe, denen fast immer das Archivinforma-tionssystem zugrunde liegt. Es ist also nicht erforderlich, zu wissen, obsich die Daten im Archiv befinden, Sie können dies aber mit Hilfe desDRB herausfinden.

DRB ist ein Service

Der DRB stellt keine eigenständige Anwendung dar, sondern nur einenService, der für jeweils ein Einstiegsobjekt aufgerufen wird. Es gibt in denAnwendungen verschiedene Transaktionen und Reports, von denen ausfür jeweils ein Einstiegsobjekt in den DRB verzweigt werden kann. Diemeisten dieser Funktionen sind in der Rolle »Document RelationshipBrowser« (SAP_DRB) zusammengefasst. Neben einigen einfachen Listenzum Auffinden von Belegen gehören auch die Beleganzeige in der Finanz-buchhaltung (Transaktion FB03) sowie die Einzelpostenberichte desGemeinkosten-Controllings dazu.

Nach dem Einstieg über ein Business-Objekt eines bestimmten Typs, bei-spielsweise eines Kundenauftrags, wie in Abbildung 4.7 dargestellt, zeigtdas Programm an, welche Business-Objekte mit dem Einstiegsobjekt ver-knüpft sind. Die Anwendungen liefern zu einem Objekt jeweils die direktdamit verknüpften Objekte. Was das im Einzelnen bedeutet, ist in derjeweiligen Anwendung festgelegt. Die Verknüpfungen zwischen denBusiness-Objekten haben keine weitere Semantik; es ist also nicht zuerkennen, ob ein Objekt Vorgänger oder Nachfolger eines anderenObjekts ist. Die Darstellung im DRB verdeutlicht lediglich, dass zwischenden Objekten eine Verknüpfung besteht.

Mehrfach ver-knüpfte Objekte werden nur ein-mal angezeigt

Um eine zyklische und damit unnötig komplizierte Darstellung der ver-knüpften Business-Objekte zu vermeiden, wird jedes Objekt innerhalbdes zugrunde liegenden Geschäftsprozesses nur einmal angezeigt. Dies istauch dann der Fall, wenn ein Objekt mit mehreren Objekten direkt ver-knüpft ist. Das führt dazu, dass nicht alle direkten Verknüpfungen auchtatsächlich dargestellt werden. Außerdem kann die Darstellung – abhän-gig davon, welches Einstiegsobjekt Sie gewählt haben und in welcher Rei-henfolge Sie durch den Verknüpfungsbaum navigieren – variieren. Es istjedoch sichergestellt, dass die Menge der insgesamt angezeigten Objektegleich bleibt, unabhängig von der Reihenfolge der einzelnen Navigations-schritte. Bei der Darstellung des DRB werden im ersten Schritt nur dieObjekte angezeigt, die direkt mit dem Einstiegsobjekt verknüpft sind.Sind weitere Objekte mit diesen Objekten verknüpft, können Sie diesedurch Navigieren in dem angezeigten Verknüpfungsbaum ebenfalls anzei-gen. In Abbildung 4.7 wurde als Einstiegsobjekt der Kundenauftrag 132


gewählt. Im Verknüpfungsbaum sehen Sie alle Business-Objekte, die mitdiesem Kundenauftrag verknüpft sind.

Durch Doppelklick auf einen Objektschlüssel – in der Regel ist dies dieBelegnummer – gelangen Sie in die Objektanzeige. Wie diese Anzeige imEinzelnen aussieht, liegt in der Verantwortung der jeweiligen Anwendungund hängt vom Typ des Business-Objekts ab.

Die Komponen-ten des DRB

Der DRB teilt sich in einen allgemeinen Basiskern und weitere anwen-dungsspezifische Komponenten auf, zum Beispiel für Vertrieb, Materialwirt-schaft und Rechnungswesen. Der Basiskern ist für die oben dargestellteAnzeige der Verknüpfungen sowie für die Weiterleitung der vom Objekt-typ abhängigen Funktionen in die jeweilige Anwendung zuständig. DieAnwendungskomponenten sind unter anderem für die Ermittlung der Ver-knüpfungen und die Anzeige der einzelnen Business-Objekte zuständig.

Archivzugriffe sind genau bei den Funktionen notwendig, die von denAnwendungskomponenten durchgeführt werden. Daher greift auch nicht

Abbildung 4.7 Mit einem Kundenauftrag verknüpfte Business-Objekte


der Basiskern des DRB auf die archivierten Daten zu, sondern die jeweiligeAnwendung. Auf welche Weise der Archivzugriff erfolgt und welche Vor-aussetzungen dafür gelten, hängt somit vom Typ des Business-Objekts ab.

Damit der DRB in der Lage ist, auf archivierte Daten zuzugreifen, müssenSie aber in der Regel für alle Objekttypen Einstellungen im Archivinfor-mationssystem vornehmen. In den meisten Fällen umfasst dies den Auf-bau von Infostrukturen zu bestimmten Standardfeldkatalogen (»SAP_...«). Große Teile der Dokumentation zum DRB befassen sich mit den Ein-zelheiten dieser Einstellungen.

Einstieg in den DRB über die Rolle SAP_DRB

Wie bereits erwähnt, ist der DRB nicht in der Lage, sämtliche Aufgabenzur Ermittlung und Anzeige der verknüpften Business-Objekte eigenstän-dig durchzuführen. Er benötigt vielmehr die Unterstützung der Anwen-dungen, beispielsweise zum Auffinden des vom Benutzer gewählten Ein-stiegsobjekts. Diese Aufgabe lässt sich mit den schon erwähntenFunktionen aus der Rolle »Document Relationship Browser« (SAP_DRB)bewältigen. Sämtliche in dieser Rolle enthaltenen Funktionen verfügenüber einen automatischen Archivzugriff.

Ebenfalls anwendungsspezifisch ist die Art und Weise, wie ein bestimm-tes Business-Objekt in der Sicht des DRB angezeigt wird. Auch ob einarchiviertes Objekt anders angezeigt wird als ein entsprechendes Objektaus der Datenbank, hängt von der Anwendung beziehungsweise demObjekttyp ab.

4.7.1 Angebundene Objekttypen im Detail

In diesem Kapitel möchten wir einige wichtige der an den DRB angebun-denen Objekttypen herausgreifen und näher untersuchen. Dabei gehenwir auf die Voraussetzungen ein, die gegeben sein müssen, damit derDRB archivierte Daten dieser Objekttypen auffinden und anzeigen kann.Darüber hinaus sprechen wir über die Verknüpfungen, die es zwischendiesen Objekttypen gibt, und darüber, wie sie im DRB dargestellt werden.Details zu weiteren Objekttypen finden Sie in der Dokumentation zumDocument Relationship Browser.

ÜberblickTabelle 4.2 gibt Ihnen einen Überblick, welche Objekttypen zu SAP R/3Enterprise an den DRB angebunden sind.


Bei dieser Aufstellung ist zu beachten, dass nicht alle aufgeführtenObjekttypen in gleicher Weise an den DRB angebunden sind. Beispiels-weise gibt es nicht für jeden Objekttyp eine Funktion im System, die dasbetreffende Objekt im DRB als Einstiegsobjekt aufruft.

Anwendung Objekttypen

SAP Web Application Server

� Intermediate Document (IDoc)

� Workitems des Workflows

Rechnungswesen � Abrechnungsbeleg

� Buchhaltungsbeleg

� Buchhaltungsbeleg Direct Input

� Kostenrechnungsbeleg

� Profit Center-Beleg

� Kontoauszugseinzelposten

� Ergebnisrechnung

� Belege Spezielle Ledger

Vertrieb � Kundenanfrage

� Kundenangebot

� Kundenauftrag

� Kundenreklamationsauftrag

� Kundenkontrakt

� Kundenlieferplan

� Kundenrahmenvertrag

� Gutschriftanforderung

� Gruppenkontrakt

� Retoure

� Kostenlose Nachlieferung

� Kundenlieferung

� Vertriebsunterstützungsbeleg

� Kundeneinzelfaktura

� Rechnungsliste

Materialwirtschaft � Belegzeile Rechnung

� Eingangsrechnung

� Bestellanforderung

� Bestellung

� Wareneingang

Produktionsplanung und -steuerung

� Fertigungsauftrag

� Fertigungsauftragsrückmeldung

Tabelle 4.2 An den DRB angebundene Objekttypen


Es können auch Objekttypen im DRB erscheinen, die in der Tabelle nichtaufgeführt sind. Dies liegt daran, dass einige Funktionen zur Ermittlungder Beziehungen auf generischen Eigenschaften der betreffenden Bezie-hung beruhen. So findet das System zum Beispiel den Ursprungsbeleg(siehe Absatz 4.7.1.1) zu einem Rechnungswesenbeleg stets mit demsel-ben Mechanismus, unabhängig vom Objekttyp des Ursprungsbelegs. Aufdiese Weise können Ursprungsbelege gefunden werden, auch wennderen Objekttyp nicht explizit an den DRB angebunden ist und daherauch nicht in der Tabelle erscheint. In der Regel können solche Objektejedoch nicht angezeigt werden, wenn sie bereits archiviert sind.

4.7.1.1 Buchhaltungsbeleg

UrsprungsbelegIm Rechnungswesen gilt das Prinzip des Ursprungsbelegs. Es besagt, dassjeder Geschäftsvorfall, der im Rechnungswesen sichtbar wird, einen denVorfall auslösenden Beleg – den Ursprungsbeleg – besitzt. Dieser Belegselbst muss aber nicht unbedingt im Rechnungswesen liegen. Wird bei-spielsweise eine Faktura im Vertrieb (SD) gebucht, entstehen in der Regelauch ein Buchhaltungs- und ein Kostenrechnungsbeleg (sowie gegebe-nenfalls weitere Belege im Rechnungswesen). Ursprungsbeleg diesesGeschäftsvorfalls ist die Faktura, obwohl sich diese nicht im Rechnungs-wesen befindet. Im Sinne des DRB gelten nun alle Rechnungswesenbe-lege als mit ihrem Ursprungsbeleg verknüpft und umgekehrt. Im obigenBeispiel ist also der Kostenrechnungsbeleg nicht direkt mit dem Buchhal-tungsbeleg verknüpft, sondern beide sind mit der Faktura verknüpft.Über diese kann dann auch die zweistufige Beziehung zwischen Kosten-rechnungs- und Buchhaltungsbeleg hergestellt werden.

Voraussetzungen für die Anzeige im DRB

Der Absprung in den Document Relationship Browser aus der Belegan-zeige wurde weiter oben schon gezeigt. Hierzu sind keine weiteren Vor-aussetzungen notwendig, außer dass der anzuzeigende Beleg über dieBeleganzeige (Transaktion FB03) darstellbar sein muss. Für archivierteBelege bedeutet dies, dass entweder der anwendungsspezifische Archiv-index für das Archivierungsobjekt FI_DOCUMNT (Tabelle ARIX_BKPF)aufgebaut ist oder dass eine aktive und aufgebaute Infostruktur zu einemder Feldkataloge SAP_FI_DOC_001 oder SAP_FI_DOC_002 existiert.Über die Transaktion FB00 können Sie dann die Beleganzeige so einstellen,dass auch archivierte Belege gefunden und im DRB angezeigt werden.

In der Rolle »Document Relationship Browser« (SAP_DRB) ist außerdemein Programm enthalten, das sich ebenfalls für den Einstieg in den DRBaus einem Buchhaltungsbeleg heraus eignet. Den Absprung in den DRBerhalten Sie durch Doppelklick auf den gewünschten Beleg in der Ergeb-


nisliste dieses Programms. Dabei können Sie – ähnlich wie bei den weiteroben beschriebenen Einzelpostenberichten der Kostenrechnung – wäh-len, ob das Programm aus dem Archiv oder aus der Datenbank lesen soll.Auch der bereits beschriebene Mechanismus, der über die TabelleASACCESS01 gesteuert wird, funktioniert mit diesem Programm. Dazumuss lediglich der entsprechende Eintrag für das Programm RDRBFI00vorgenommen werden.

Anbindung archi-vierter Buchhal-

tungsbelege

Eine komplette Anbindung archivierter Buchhaltungsbelege an denDocument Relationship Browser erhalten Sie folgendermaßen:

� Falls Sie das in der Rolle »Document Relationship Browser« enthalteneProgramm RDRBFI00 einsetzen wollen und dabei auch über die FelderBUCHUNGSPERIODE (BKPF-MONAT) und REFERENZ (BKPF-XBLNR) selek-tieren möchten, sollten Sie eine Infostruktur zu einem der Feldkata-loge SAP_FI_DOC_001 oder SAP_FI_DOC_002 verwenden, die auchdie Felder BUCHUNGSPERIODE, BUCHUNGSDATUM, BELEGART, REFERENZBE-LEGNUMMER, REFERENZVORGANG, REFERENZSCHLÜSSEL und LOGISCHES SYS-TEM enthält.

� Falls Sie dieses Programm nicht einsetzen wollen, darin keinen auto-matischen Archivzugriff benötigen oder nicht über die genannten Fel-der selektieren möchten, genügt der anwendungsspezifische Archivin-dex (ARIX_BKPF), der in der Regel ohnehin aufgebaut wird.

� Stellen Sie die Beleganzeige in der Transaktion FB00 so ein, dass dasLesen aus dem Archiv mit Hilfe des Archivindex erfolgt.

4.7.1.2 Kostenrechnungsbeleg

Verteilung aufArchive

Die Behandlung archivierter Kostenrechnungsbelege im DRB ist aufwän-diger als zum Beispiel der Umgang mit Buchhaltungsbelegen. Dies liegt ander Art, wie die Belegzeilen auf die Archive verteilt werden. Kostenrech-nungsbelege können mit verschiedenen Archivierungsobjekten archiviertwerden, wie zum Beispiel CO_ITEM, PP_ORDER, CO_COSTCTR oderSD_VBAK. Ein weiteres Problem besteht darin, dass die Kostenrech-nungsbelege nicht belegweise archiviert werden. Bei einer Buchung, ander ein Fertigungsauftrag und eine Kostenstelle beteiligt sind, kommt esvor, dass ein Teil des Belegs in einem PP_ORDER-Archiv steht, währendder andere Teil sich noch in der Datenbank befindet. Für einen Kosten-rechnungsbeleg ist es also weder möglich, eindeutig zu bestimmen, inwelcher Archivdatei er sich befindet, noch lässt sich feststellen, ob erbereits archiviert wurde oder nicht. Dies kann nur für einzelne Belegzei-len (Einzelposten) ermittelt werden.


Mehrere Feld-kataloge und Infostrukturen

Da ein Feldkatalog des Archivinformationssystems vom Archivierungsob-jekt abhängt, kann es sein, dass mehrere Feldkataloge und damitInfostrukturen benötigt werden. Für den Zugriff auf Kostenrechnungsbe-lege werden für die verschiedenen Archivierungsobjekte Feldkatalogeausgeliefert, die mit »SAP_COBK_« beginnen. Um also archivierte Kos-tenrechnungsbelege an den DRB anzubinden, benötigen Sie für jedesArchivierungsobjekt, mit dem Sie Einzelposten der Kostenrechnungarchivieren, eine Infostruktur zum entsprechenden SAP_COBK-Feldkata-log. Damit die Verknüpfungen ermittelt werden können, müssen dieseInfostrukturen das Feld REFBN enthalten. Solche Infostrukturen werdenvon SAP standardmäßig ausgeliefert, ihr Name beginnt ebenfalls mit»SAP_COBK_«. In der Regel ist es ausreichend, wenn Sie diese Infostruk-turen aktivieren und aufbauen. Ein besseres Laufzeitverhalten des Pro-gramms erreichen Sie durch Aufnahme der Felder REFBT, AWTYP undAWORG in Ihre Infostrukturen. Allerdings benötigen die Infostrukturendadurch auch mehr Speicherplatz in der Datenbank, was gegen den Lauf-zeitvorteil abzuwägen ist.

Auf Grund der Art und Weise, wie Kostenrechnungsbelege archiviertwerden, entspricht die Anzahl der Einträge in den benötigten Infostruk-turen ungefähr der Anzahl der Belegzeilen. Entscheidend sind hier abernur die Belegzeilen aus Archivdateien, für die die entsprechendeInfostruktur aufgebaut wurde. Angesichts des großen Umfangs, den einesolche Infostruktur erreichen kann, sollten Sie daher genau abwägen, obdie Anzeige von archivierten Kostenrechnungsbelegen erforderlich ist.

Mit Kostenrechnungsbelegen (wie bei anderen Belegen des Rechnungs-wesens auch) sind nur die jeweiligen Ursprungsbelege verknüpft. DieObjekte, auf denen die Kosten gesammelt werden, wie zum Beispiel Auf-träge und Kostenstellen, gelten nicht als mit dem Kostenrechnungsbelegverknüpft. Ansonsten könnte der Fall eintreten, dass mit einem Objektmehrere Millionen Belege verknüpft wären, was den Rahmen des DRBsprengen würde.

4.7.1.3 Kundenauftrag

Im Vertrieb entspricht eine Verknüpfung zwischen zwei Belegen derBeziehung, die im Belegfluss als Vorgänger beziehungsweise Nachfolgerbezeichnet wird. Allerdings entfällt im DRB die Semantik der Beziehung,so dass man nicht mehr erkennen kann, welcher Beleg der Vorgängerbeziehungsweise der Nachfolger ist. Um archivierte Kundenaufträge undandere Verkaufsbelege, die mit dem Archivierungsobjekt SD_VBAK archi-


viert werden, an den DRB anzubinden, wird lediglich eine aktive undgefüllte Infostruktur zu einem der Feldkataloge SAP_SD_VBAK_001 oderSAP_SD_VBAK_002 benötigt.

Für Verkaufsbelege existiert in der Rolle »Document Relationship Brow-ser« ein spezielles Programm, das den Einstieg in den DRB ermöglicht(siehe Abbildung 4.8).

Als Selektionskriterien können Sie hier außer der Belegnummer im FeldVERKAUFSBELEG auch andere Felder benutzen. Es ist sinnvoll, diese Felderin die Infostruktur aufzunehmen.

Suchoptionen Beachten Sie auch die drei Auswahlknöpfe auf dem Selektionsbild, mitdenen Sie steuern können, wo die Verkaufsbelege gesucht werden.

� Suche in DBBei Wahl dieser Option werden die Verkaufsbelege nur in der Daten-bank gesucht. Archivierte Verkaufsbelege werden vollständig ignoriert.

� Suche in DB und SAP ASWenn Sie diese Option wählen, werden Verkaufsbelege in der Daten-bank und in den oben aufgeführten Infostrukturen des Archivinforma-tionssystems gesucht. Es werden allerdings keine Archivzugriffe durch-geführt. Dies hat zur Folge, dass in der Ergebnisliste unter Umständen

Abbildung 4.8 Einstieg in den DRB über Verkaufsbelege


nicht alle Felder gefüllt und nicht alle gewünschten Sätze gefundenwerden, da das Programm Felder, die nicht in der Infostruktur enthal-ten sind, als leer ansieht und daher nicht weiterverfolgt.

� Suche in DB, SAP AS und ArchivBei Wahl dieser Option werden Verkaufsbelege in der Datenbank undim Archivinformationssystem gesucht. Für die Belege, die laut Archiv-informationssystem gefunden wurden, werden im Archiv die gegebe-nenfalls fehlenden Daten nachgelesen. Es werden also auch hier nurBelege gelesen, die sich in einer passenden Infostruktur befinden.

Bekannte Fallstricke

Diese Auswahl steuert lediglich, was in der Ergebnisliste des Programmsangezeigt wird, und nicht, welche verknüpften Belege der DRB später fin-det. Es kann also vorkommen, dass trotz der Wahl der Option SUCHE INDB archivierte Belege als verknüpfte Objekte im DRB angezeigt werden.In vielen Fällen lassen sich nur die beiden Optionen SUCHE IN DB undSUCHE IN DB, SAP AS UND ARCHIV sinnvoll einsetzen. Die Option SUCHE INDB UND SAP AS ist zwar häufig schneller als die letztgenannte Option,führt allerdings auch häufig zu verwirrenden Ergebnissen, da dem Endan-wender in den wenigsten Fällen klar sein dürfte, welche Felder in denInfostrukturen enthalten sind und welche Auswirkungen dies auf dieSelektion hat.

Anzeige archivier-ter Logistikbelege

Im Gegensatz zum Rechnungswesen werden archivierte Belege aus derLogistik im DRB nicht genauso angezeigt wie Belege, die sich noch in derDatenbank befinden. Allerdings wurde die Anzeige für archivierte Belegeder jeweiligen Anzeigetransaktion für Belege aus der Datenbank nach-empfunden. Außerdem ist sichergestellt, dass die wesentlichen Felderangezeigt werden. Befinden sich die Belege noch in der Datenbank, wer-den die üblichen Beleganzeige-Transaktionen, wie zum Beispiel VA03,verwendet.

Alle weiteren Objekttypen der Logistik sind in ähnlicher Weise wie dieKundenaufträge an den DRB angebunden. Unterschiede gibt es lediglichbei den verwendeten Feldkatalogen sowie den Feldern, über die selek-tiert werden kann und die in die Infostrukturen aufgenommen werdensollten. Näheres hierzu finden Sie in der Dokumentation der anwen-dungsspezifischen Komponenten des Document Relationship Browser.

4.7.2 Konfiguration des Document Relationship Browser

Die bisherige Darstellung des DRB konzentrierte sich hauptsächlich aufdie Nutzung des Archivinformationssystems und anderer Funktionen derDatenarchivierung für den Zugriff auf archivierte Daten. Hinsichtlich der


Konfiguration wurde dabei im Wesentlichen auf die Definition vonInfostrukturen eingegangen. Neben dieser wichtigsten Einstellungsmög-lichkeit gibt es jedoch weitere Möglichkeiten, um den Zugriff auf archi-vierte Daten zu optimieren und die Funktionen besser an die Bedürfnissedes Endbenutzers anzupassen.

In diesem Zusammenhang sollen folgende Konfigurationsmöglichkeitenangesprochen werden:

� Vorbelegung der Einstiegsprogramme

� Auswahl der Felder der Einstiegslisten

� Auswahl der anzuzeigenden Objekttypen

� Auswahl der Felder im DRB

Prinzipiell können sämtliche Einstellungen benutzerspezifisch vorgenom-men werden. Alle Einstellungen, bis auf die Auswahl der anzuzeigendenObjekttypen, sind eigentlich nicht spezifisch für den Document Relation-ship Browser, sondern stammen von den darin verwendeten Werkzeu-gen. Da sich aber gerade diese Einstellungen hervorragend dafür eignen,den DRB besser an die Datenarchivierung anzupassen, möchten wir imFolgenden näher darauf eingehen und aufzeigen, wie Sie dem Benutzerden Zugriff auf archivierte Daten noch komfortabler ermöglichen können.

4.7.2.1 Vorbelegung der Einstiegsprogramme

Die Rolle »Document Relationship Browser« enthält in der Standardaus-lieferung zwar einige Programme, die für den Einstieg in den DRB geeig-net sind, diese Programme sind jedoch so eingestellt, dass sie keineArchivzugriffe vornehmen. Bei den Programmen der Logistik ist die Such-option SUCHE IN DB voreingestellt. Bei den Programmen des Rechnungs-wesens ist der automatische Archivzugriff in der Tabelle ASACCESS01standardmäßig ausgeschaltet. Im Folgenden beschreiben wir, wie Siediese Programme einer Rolle so zuordnen können, dass die automati-schen Archivzugriffe eingeschaltet sind.

Selektions-variante anlegen

Hierzu müssen Sie zunächst für jedes Programm, das Sie verwenden wol-len, eine Selektionsvariante anlegen. Über die Feldeigenschaften derSelektionsvariante können Sie unter anderem die SUCHE IN...-Felder vor-belegen und ausblenden. Wird das Programm nun mit dieser Variantegestartet, sieht der Benutzer diese Felder auf dem Selektionsbild nichtmehr und der gewünschte Wert wird automatisch eingesetzt.


Für die Einstiegslisten für Buchhaltungsbelege sowie für die Einzelposten-berichte in der Kostenrechnung können Sie analog verfahren. Allerdingskönnen Sie die Felder zur Auswahl der Datenquelle hier nicht ausblen-den, da diese Felder ohnehin nicht auf dem Selektionsbild erscheinen. Siewerden jedoch mit der Variante abgespeichert. Natürlich können Sie dieEinstiegslisten für Buchhaltungs- und Kostenrechnungsbelege auch überdie Tabelle ASACCESS01 steuern, wie weiter oben beschrieben. Aller-dings ändert sich dann das Verhalten für alle Benutzer. Falls Sie das Sys-tem tatsächlich so einstellen wollen, dass die Einzelpostenberichte derKostenstellenrechnung für alle Benutzer automatisch aus dem Archivlesen, ist die Einstellung über ASACCESS01 vorzuziehen.

Selektions-variante einer Rolle zuweisen

Nachdem Sie für alle zu verwendenden Programme entsprechende Vari-anten angelegt haben, können Sie diese Programme (über die TransaktionPFCG) in eine Rolle eintragen. Wird ein solches Programm aus der Rolle,der es zugewiesen wurde, aufgerufen, startet es automatisch mit den Vor-einstellungen aus der Variante. Auf diese Weise können Sie eine Rollezusammenstellen, die alle Programme enthält, die zum Aufruf des DRBführen und die so konfiguriert sind, dass sie automatisch auf das Archivzugreifen. Über diesen Mechanismus können Sie natürlich auch andereSelektionskriterien als die genannten vorbelegen.

4.7.2.2 Auswahl der Felder der Einstiegslisten

Sämtliche in der Rolle »Document Relationship Browser« enthaltenenProgramme wurden mit Hilfe des ABAP List-Viewers realisiert. Immerwenn eine Liste angezeigt wird, können Sie daher deren Layout ändern,das geänderte Layout abspeichern und als Voreinstellung einstellen.Diese Einstellungen können benutzerspezifisch oder für alle Benutzerübergreifend erfolgen.

4.7.2.3 Auswahl der anzuzeigenden Objekttypen

Komplexe Geschäftsvorfälle und Prozesse werden im Document Rela-tionship Browser meistens auch relativ komplex dargestellt. Außerdemkann es auf Grund der Vielzahl von Objekttypen, die der DRB in SAP R/3Enterprise unterstützt, zu Laufzeitproblemen bei der Ermittlung der Ver-knüpfungen kommen, da das Programm versucht, alle Verknüpfungenaufzulösen, obwohl der Benutzer in der Regel nicht alle Objekttypenbenötigt.


PersonalisierteAnzeige

Beispielsweise interessiert sich ein Benutzer zwar für die logistische Ketteeines Geschäftsprozesses, nicht aber für die Details im Rechnungswesen.In diesem Fall wäre es sinnvoll, die unerwünschten Objekttypen bei derAnzeige einfach auszublenden. Das Werkzeug, mit dem Sie eine solcheselektive Anzeige erreichen können, ist die Personalisierung. Je nachdem,ob die Einstellungen für einzelne Benutzer oder für eine Rolle gelten sol-len, erreichen Sie die Personalisierung entweder über die Benutzerpflege(Transaktion SU01) oder über die Rollenpflege (Transaktion PFCG). Ein-stellungen, die für eine Rolle vorgenommen werden, können automa-tisch für alle Benutzer, die dieser Rolle zugeordnet sind, übernommenwerden. In der Rolle »Document Relationship Browser« ist die Auswahlder Objekttypen so eingestellt, dass alle Objekte angezeigt werden.

Beim Ausblenden von Objekttypen ist zu beachten, dass die betreffendenBelege nicht nur aus der Anzeige entfernt werden, sondern auch nichtmehr für die Ermittlung weiterer Beziehungen herangezogen werdenkönnen. Dies bedeutet, dass nicht nur die explizit ausgeblendetenObjekte von der Anzeige ausgenommen sind, sondern auch diejenigenObjekte, die von den ausgeblendeten Objekten abhängig sind.

Abbildung 4.9 Auswahl der anzuzeigenden Objekttypen in der Benutzerpflege


4.7.2.4 Auswahl der Felder im DRB

Im Navigationsbaum des DRB werden standardmäßig nur Typ undBeschreibung eines Objekts angezeigt. Sie können diese Anzeige erwei-tern, indem Sie weitere relevante Felder aufnehmen. Außer den techni-schen Entsprechungen des Objektschlüssels und des Objekttyps sind hiervor allem zwei Felder von Bedeutung:

Die Felder Logisches System und Herkunft

� Das Feld LOGISCHES SYSTEM gibt an, von welchem logischen System dieDaten stammen. Dies ist dann relevant, wenn es sich um systemüber-greifende Prozesse oder Geschäftsvorfälle handelt.

� Im Hinblick auf die Datenarchivierung ist insbesondere das Feld HER-KUNFT erwähnenswert. Es gibt an, ob sich ein angezeigtes Business-Objekt in der Datenbank oder im Archiv befindet. Ähnlich wie bei denEinstiegslisten können Sie auch hier die Feldauswahl über Layoutssteuern sowie die Layouts benutzerspezifisch speichern und vorein-stellen.

Documents

mit SAP - bücher.de