796.book Seite 3 Montag, 6. November 2006 7:40 19

Helmut Stefani

Datenarchivierung mit SAP®

Bonn 폷 Boston

796.book Seite 4 Montag, 6. November 2006 7:40 19

Liebe Leserin, lieber Leser, vielen Dank, dass Sie sich für ein Buch von SAP PRESS entschieden haben. Dass ich Ihnen heute die Neuauflage des Buches »Datenarchivierung mit SAP« präsentieren darf, ist mir eine besondere Freude: Markierte doch die erste Auflage dieses Buches aus dem Frühjahr 2002 den Anfang meiner Tätigkeit als Lektor bei SAP PRESS. Mittlerweile sind fast fünf Jahre ins Land gezogen – für ein IT-Fachbuch eine halbe Ewigkeit; es wurde also höchste Zeit für eine gründliche Überarbeitung. Dass wir diese angehen würden, daran bestanden weder für Verlag noch für Autoren je ernsthafte Zweifel. Schaut man nämlich mit dem Blick des Programmplaners auf das Thema Datenarchivierung, so stellt man fest: Hier befindet man sich im Kernbereich des Themenspektrums von SAP PRESS. Natürlich fehlt der Hype, auf spektakuläre Ankündigungen neuer Archivierungstechnologien im Rahmen von SAPPHIREs oder TechEDs wartet man vergebens. Doch die Datenarchivierung – das wird auch in dieser zweiten Auflage wieder sehr deutlich – ist ein Thema, an dem Sie als SAP-Kunde schlicht nicht vorbeikommen. Für uns ist das Grund genug, Ihnen aktualisierte und weiterführende Informationen anzubieten. Jedes unserer Bücher will Sie überzeugen. Damit uns das immer wieder gelingt, sind wir auf Ihre Rückmeldung angewiesen. Kritik oder Zuspruch hilft uns bei der Arbeit an weiteren Auflagen. Ich freue mich deshalb, wenn Sie sich mit Ihren kritischen Anmerkungen oder Ihrem Lob an mich wenden.

Ihr Florian Zimniak Lektorat SAP PRESS

Galileo Press Rheinwerkallee 4 53227 Bonn [email protected] www.sap-press.de

796.book Seite 5 Montag, 6. November 2006 7:40 19

Auf einen Blick Vorwort zur zweiten Auflage ..................................

15

Geleitwort der DSAG ..............................................

17

Danksagung zur ersten Auflage ..............................

19

Einleitung ................................................................

21

1

Grundlagen der Datenarchivierung .........................

29

2

Prozesse in der Datenarchivierung .........................

67

3

Ablage von archivierten Daten ...............................

99

4

Zugriff auf archivierte Daten .................................. 161

5

Technologie und Administration ............................ 203

6

Datenarchivierung in verschiedenen SAP-Anwendungen und -Komponenten ................ 269

7

Planung und Durchführung von Archivierungsprojekten ................................................................. 339

A

Beispiel einer Objektbeschreibung für das Detailkonzept ......................................................... 405

B

Checkliste für Archivierungsprojekte ..................... 409

C

Weitere Informationen und Services ...................... 413

D

Glossar .................................................................... 417

E

Verzeichnis der verwendeten Abkürzungen ........... 425

F

Literaturverzeichnis ................................................ 427

G

Die Autoren ............................................................. 429 Index ....................................................................... 435

796.book Seite 7 Montag, 6. November 2006 7:40 19

Inhalt Vorwort zur zweiten Auflage ....................................................... Geleitwort der DSAG ................................................................... Danksagung zur ersten Auflage .................................................... Einleitung ...................................................................................

1

Grundlagen der Datenarchivierung .......................... 29 1.1 1.2

1.3

1.4 1.5

1.6

2

15 17 19 21

Information Lifecycle Management in einer SAP-Umgebung .......................................................... Datenarchivierung als Teil des Datenmanagements ..... 1.2.1 Nutzenbetrachtung ........................................ 1.2.1.1 Systemverfügbarkeit ....................................... 1.2.1.2 Nutzung von Ressourcen ................................ 1.2.1.3 Antwortzeiten ................................................ 1.2.1.4 Einhaltung gesetzlicher Vorschriften ............... 1.2.2 Leistungsumfang ............................................ 1.2.3 Einsatzgebiete ................................................ 1.2.4 Das Archive Development Kit ........................ 1.2.5 Das Archivierungsobjekt ................................ Ablauf der Datenarchivierung ..................................... 1.3.1 Der Zugriff auf archivierte Daten .................... 1.3.2 Die Ablage von Archivdateien ........................ Performanceaspekte ................................................... Archivierungsprojekte ................................................. 1.5.1 Der richtige Zeitpunkt .................................... 1.5.2 Datenmanagement ........................................ Steuerrechtliche Anforderungen an archivierte Daten ......................................................................... 1.6.1 Audit Information System .............................. 1.6.2 Data Retention Tool .......................................

29 34 34 35 36 36 36 38 39 41 43 45 47 52 55 58 60 60 62 63 64

Prozesse in der Datenarchivierung .......................... 67 2.1

2.2

Prüfung auf Archivierbarkeit ....................................... 2.1.1 Vernetzte Anwendungsdaten ......................... 2.1.2 Durchführung der Archivierbarkeitsprüfung .... Hauptprozesse in der Datenarchivierung ..................... 2.2.1 Daten aus der Datenbank ins Archiv schreiben ....................................................... 2.2.2 Daten aus der Datenbank löschen ..................

67 69 74 77 79 82 7

796.book Seite 8 Montag, 6. November 2006 7:40 19

Inhalt

2.3

3

84 85 86 90 91 91 93 94 96

Ablage von archivierten Daten ................................. 99 3.1

3.2

8

2.2.2.1 Löschen nach dem Schreiben ........................ 2.2.2.2 Löschen parallel zum Schreiben ..................... 2.2.3 Archivdateien ablegen (optional) ................... Weitere Prozesse und Tätigkeiten .............................. 2.3.1 Auf archivierte Daten zugreifen ..................... 2.3.1.1 Archivdateien auswerten ............................... 2.3.1.2 Archivierte Einzelobjekte anzeigen ................ 2.3.2 Archivierte Daten zurückladen ....................... 2.3.3 Vor- und Nachlaufprogramme ausführen .......

Kriterien zur Wahl der Ablagestrategie ....................... 3.1.1 Sicherheit ...................................................... 3.1.1.1 Wie sicher ist der Weg in die Ablage? ............ 3.1.1.2 Wie sicher ist die Ablage selbst? .................... 3.1.1.3 Welche Sicherungsmöglichkeiten bietet das Ablagesystem? ........................................ 3.1.2 Kosten .......................................................... 3.1.2.1 Anschaffungskosten ....................................... 3.1.2.2 Betriebskosten .............................................. 3.1.3 Integration .................................................... 3.1.3.1 Wie passt das Ablagesystem in die bestehende IT-Landschaft? ............................ 3.1.3.2 Welchen Zusatznutzen hat die verwendete Ablage neben der Datenarchivierung? ........... 3.1.4 Performance .................................................. 3.1.4.1 Parallele Auftragsabarbeitung ........................ 3.1.4.2 Blockweiser Zugriff ........................................ 3.1.5 Langfristigkeit ................................................ Ablage auf einem zertifizierten Ablagesystem ............. 3.2.1 Begriffsdefinitionen: ArchiveLink, KPro, CMS .............................................................. 3.2.2 Was ist ArchiveLink? ..................................... 3.2.2.1 Zentrale Aufgabe von ArchiveLink ................. 3.2.2.2 Der Begriff Dokument ................................... 3.2.2.3 Dokumentenrecherche .................................. 3.2.3 Dokumentenszenarien ................................... 3.2.3.1 Workflow-basierte Dokumentenszenarien ..... 3.2.3.2 Barcodeszenario ............................................ 3.2.3.3 Ausgehende Dokumente ............................... 3.2.3.4 Drucklisten ....................................................

99 101 101 102 104 105 105 106 107 107 107 108 108 109 110 112 113 116 117 120 122 128 129 132 133 136

796.book Seite 9 Montag, 6. November 2006 7:40 19

Inhalt

3.2.4 3.2.4.1 3.2.4.2 3.2.4.3

3.3

3.4

3.5

4

Schnittstelle zu externen Systemen ................ Kommunikation ............................................. Zertifizierung von Ablagesystemen ................. Zertifizierte Systeme und SAP Content Server ............................................................ 3.2.5 Ablage von Archivdateien .............................. 3.2.5.1 Asynchrone Ablage ........................................ 3.2.5.2 Synchrone Ablage .......................................... 3.2.6 Bekannte technische Probleme bei der Ablage von Archivdateien .............................. 3.2.6.1 Synchronproblem ........................................... 3.2.6.2 Sicherheitslücke ............................................. 3.2.6.3 Performanceproblem ..................................... 3.2.7 Zugriff auf Archivdateien ................................ 3.2.8 Bekannte technische Probleme beim Zugriff auf Archivdateien über ArchiveLink ................ 3.2.9 Vorteile des Einsatzes von ArchiveLink ........... Ablage über HSM-Systeme ......................................... 3.3.1 Was ist HSM? ................................................ 3.3.2 Ablage von Archivdateien .............................. 3.3.3 Zugriff auf Archivdateien ................................ 3.3.4 Typische technische Probleme ....................... 3.3.5 Vorteile des Einsatzes von HSM-Systemen ..... Manuelle Ablage ........................................................ 3.4.1 Direkte Integration ........................................ 3.4.2 Indirekte Integration ...................................... 3.4.3 Vor- und Nachteile der manuellen Ablage ...... Resümee ....................................................................

137 137 141 143 144 145 146 147 147 147 148 149 150 150 151 151 155 155 157 157 158 158 158 159 159

Zugriff auf archivierte Daten .................................... 161 4.1 4.2 4.3 4.4 4.5

Einführung .................................................................. Grundlagen ................................................................ Sequenzielle Leseprogramme ...................................... Direktzugriffe ............................................................. Archivinformationssystem ........................................... 4.5.1 Anlegen einer Infostruktur ............................. 4.5.2 Partitionieren einer Infostruktur ..................... 4.5.3 Aktivieren einer Infostruktur .......................... 4.5.4 Aufbau einer Infostruktur ............................... 4.5.5 Auswerten einer Infostruktur ......................... 4.5.6 Abbau einer Infostruktur ................................

161 164 165 167 170 172 174 175 176 176 178

9

796.book Seite 10 Montag, 6. November 2006 7:40 19

Inhalt

4.6 4.7

5

179 180 182 184 185 187 190 192 194 195 197 198 199 199 201

Technologie und Administration .............................. 203 5.1

5.2

10

4.5.7 Anlegen eines Feldkatalogs ........................... 4.5.7.1 Anlegen eines Feldkatalogs mit einer Quelltabelle .................................................. 4.5.7.2 Anlegen eines Feldkatalogs mit mehreren Quelltabellen ................................................ 4.5.7.3 Typische Fallstricke beim Anlegen von Feldkatalogen ................................................ Auf dem Archivinformationssystem basierende Archivzugriffe ............................................................. Document Relationship Browser ................................ 4.7.1 Angebundene Objekttypen im Detail ............ 4.7.1.1 Buchhaltungsbeleg ........................................ 4.7.1.2 Kostenrechnungsbeleg .................................. 4.7.1.3 Kundenauftrag .............................................. 4.7.2 Konfiguration des Document Relationship Browser ......................................................... 4.7.2.1 Vorbelegung der Einstiegsprogramme ........... 4.7.2.2 Auswahl der Felder der Einstiegslisten ........... 4.7.2.3 Auswahl der anzuzeigenden Objekttypen ...... 4.7.2.4 Auswahl der Felder im DRB ...........................

Basistechnologie der SAP-Archivierungslösungen ....... 5.1.1 Das Archive Development Kit: Einordnung und Komponenten ........................................ 5.1.2 ADK als Laufzeitumgebung ............................ 5.1.3 ADK als Entwicklungsumgebung ................... 5.1.3.1 Entwicklung neuer Archivierungsobjekte ....... 5.1.3.2 Erweiterung von SAP-Archivierungsobjekten ........................................................ 5.1.4 Datenarchivierung und Unicode .................... 5.1.5 XML-basiertes Archivieren ............................ 5.1.5.1 Positionierung der XML-Archivierung ............ 5.1.5.2 Gemeinsamkeiten und Unterschiede zum ADK aus Administrationssicht ....................... 5.1.5.3 Verfügbarkeit und Dokumentation ................ Aufgaben des Datenarchivierungsadministrators ........ 5.2.1 Die Rolle Datenarchivierungsadministrator .... 5.2.2 Überwachung von Archivierungsläufen .......... 5.2.2.1 Archivverwaltung .......................................... 5.2.2.2 Datenarchivierungsmonitor ...........................

203 203 204 207 207 209 211 214 215 215 218 219 219 222 223 227

796.book Seite 11 Montag, 6. November 2006 7:40 19

Inhalt

5.2.3 5.2.3.1 5.2.3.2 5.2.3.3

5.3 5.4

5.5

Sicherheit versus Performance ........................ Verifikation von Archivdateien ....................... Dateizugriffsprüfung bei Archivauswahl .......... Umstellung der Reihenfolge: Ablegen vor Löschen ......................................................... 5.2.4 Statistiken der Datenarchivierung ................... 5.2.5 Protokolle der Datenarchivierung ................... 5.2.5.1 Das Anwendungsprotokoll ............................. 5.2.5.2 Das Standardprotokoll ................................... 5.2.6 Reorganisation der Datenbank nach einer Datenarchivierung .......................................... 5.2.7 Archive File Browser ...................................... Archive Routing .......................................................... Automatisierter Produktivbetrieb ................................ 5.4.1 Periodisches Archivieren ................................ 5.4.2 Einplanung von Datenarchivierungsjobs ......... 5.4.2.1 Jobtypen ........................................................ 5.4.2.2 Benutzung von Servergruppen ....................... 5.4.3 Unterbrechen und Fortsetzen ......................... 5.4.4 Möglichkeiten zur Automatisierung abhängiger Prozesse ....................................... 5.4.5 Steuerung von Datenarchivierungsjobs durch externe Job-Scheduler .......................... 5.4.5.1 Einplanung von Schreibjobs ........................... 5.4.5.2 Einplanung von Löschjobs .............................. Anwendungsunabhängige Fehler und ihre Beseitigung ................................................................. 5.5.1 Verhalten bei Abbrüchen ............................... 5.5.1.1 Abbruch während der Schreibphase ............... 5.5.1.2 Abbruch während der Löschphase ................. 5.5.2 Typische Fallstricke ........................................ 5.5.2.1 Kein Zugriff auf Dateisystem möglich ............. 5.5.2.2 Speicherplatz im Dateisystem unzureichend ... 5.5.2.3 Überlauf der Protokolldateien für Datenbankänderungen ................................... 5.5.2.4 Datenbankfehler ORA-1555 – Snapshot too old (nur auf Datenbanksystem Oracle) ..... 5.5.2.5 Probleme mit Datenbanksperren ....................

230 230 231 232 234 236 238 239 241 246 247 250 251 252 252 253 254 255 257 257 258 260 260 260 263 264 264 265 265 266 267

11

796.book Seite 12 Montag, 6. November 2006 7:40 19

Inhalt

6

Datenarchivierung in verschiedenen SAP-Anwendungen und -Komponenten .................. 269 6.1

6.2

6.3

12

mySAP ERP ................................................................ 6.1.1 Archivierung in der Finanzbuchhaltung .......... 6.1.1.1 Datenmanagement ........................................ 6.1.1.2 Customizing .................................................. 6.1.1.3 Datenarchivierung ......................................... 6.1.1.4 Zugriff auf archivierte Daten .......................... 6.1.2 Archivierung in der Kostenrechnung .............. 6.1.2.1 Die Tabelle COEP im Zusammenhang ............ 6.1.2.2 Objektnummer und Objektart ....................... 6.1.2.3 Analyse der Tabellen des GemeinkostenControlling .................................................... 6.1.2.4 Datenmanagement – Einzelpostenverdichtung ............................... 6.1.2.5 Auswahl der Archivierungsobjekte ................. 6.1.2.6 CO_ITEM: zentrales Archivierungsobjekt ....... 6.1.3 Archivierung in mySAP ERP HCM .................. 6.1.3.1 Archivierung in Umfeld der Personalabrechnung ...................................... 6.1.3.2 Archivierung sonstiger Anwendungsdaten des HCM ....................................................... mySAP CRM .............................................................. 6.2.1 Der CRM Server in der Anwendung mySAP CRM .................................................. 6.2.2 Besonderheiten der Datenarchivierung in mySAP CRM .................................................. 6.2.3 Die Beziehung zwischen Business-Objekt und Archivierungsobjekt ................................ 6.2.4 Das Dreiphasenmodell der Datenarchivierung ......................................... 6.2.5 Rahmenprogramme für eine kontinuierliche Datenarchivierung ......................................... 6.2.6 Das Datenmodell des CRM-Geschäftsvorgangs ....................................................... 6.2.7 Das Archivierungsobjekt CRM_ACT_ON ........ 6.2.8 Resümee und Ausblick .................................. SAP NetWeaver Business Intelligence ........................ 6.3.1 Technische Grundlagen ................................. 6.3.2 Überlegungen zur Datenarchivierung .............

269 270 271 272 275 279 280 282 283 283 284 285 288 289 290 297 298 298 301 303 305 308 310 311 315 316 316 319

796.book Seite 13 Montag, 6. November 2006 7:40 19

Inhalt

6.3.3 6.3.4

Datenarchivierung in SAP NetWeaver BI ........ Modellierung von Datenarchivierungsprozessen ....................................................... 6.3.5 Der Datenarchivierungsprozess ...................... 6.3.5.1 Daten ins Archiv schreiben ............................. 6.3.5.2 Daten in der Datenbank löschen .................... 6.3.6 Rückladen archivierter Daten ......................... 6.3.7 Zugriff auf archivierte Daten ........................... 6.3.8 Ausblick .........................................................

7

322 325 330 331 333 336 337 337

Planung und Durchführung von Archivierungsprojekten ............................................ 339 7.1

7.2 7.3

Einführung .................................................................. 7.1.1 Frühzeitiges Aufsetzen eines Archivierungsprojekts ..................................... 7.1.2 Spätes Aufsetzen eines Archivierungsprojekts ......................................................... 7.1.3 Überlegungen im Vorfeld der Datenarchivierung .......................................... Vorgehen nach ASAP-Einführungsphasen ................... Projektphasen ............................................................. 7.3.1 Projektvorbereitung ....................................... 7.3.1.1 Zusammenstellung des Projektteams .............. 7.3.1.2 Analyse der Datenbank .................................. 7.3.1.3 Erstellen des Grobkonzepts ............................ 7.3.2 Business Blueprint: Design und Konzeption .... 7.3.2.1 Erstellung eines Detailkonzepts ...................... 7.3.3 Realisierung ................................................... 7.3.3.1 Konfiguration und Customizing ...................... 7.3.3.2 Integrationstest .............................................. 7.3.4 Produktionsvorbereitung ................................ 7.3.4.1 Überprüfung der Einstellungen und Hinweise ........................................................ 7.3.4.2 Testphase ....................................................... 7.3.4.3 Schulung der Endanwender ............................ 7.3.4.4 Freigabe für das Produktivsystem ................... 7.3.5 Go-Live & Support ......................................... 7.3.5.1 Produktivsetzen ............................................. 7.3.5.2 Aufstellung eines langfristigen Archivierungsplans .........................................

339 340 341 341 342 345 345 345 349 362 366 367 375 375 377 378 378 379 379 380 380 380 382

13

796.book Seite 14 Montag, 6. November 2006 7:40 19

Inhalt

7.4 7.5

7.6 7.7 7.8

7.3.5.3 Projektende-Workshop ................................. Qualitätssicherung im Projekt .................................... Durchführung eines Archivierungsprojekts am Beispiel des Vertriebs ................................................. 7.5.1 Einführung .................................................... 7.5.2 Projektvorbereitung ...................................... 7.5.2.1 Zusammenstellung des Projektteams ............. 7.5.2.2 Analyse ......................................................... 7.5.2.3 Grobkonzept ................................................. 7.5.3 Business Blueprint ......................................... 7.5.3.1 Detailkonzept ................................................ 7.5.4 Realisierung ................................................... 7.5.5 Produktionsvorbereitung ............................... 7.5.6 Go-Live & Support ......................................... 7.5.7 Beispiel: Archivierung eines Verkaufsbelegs ... Kritische Erfolgsfaktoren in einem Archivierungsprojekt .................................................. Wahl der richtigen Residenzzeiten ............................. Wahl der richtigen Archivierungsreihenfolge ..............

383 383 384 384 385 385 386 387 387 387 392 392 392 393 398 398 401

Anhang ............................................................................ 403 A B C

D E F G

Beispiel einer Objektbeschreibung für das Detailkonzept ...... Checkliste für Archivierungsprojekte ..................................... Weitere Informationen und Services ..................................... C.1 Informationen ............................................................ C.2 Services ...................................................................... C.3 Schulungen ................................................................ Glossar ................................................................................. Verzeichnis der verwendeten Abkürzungen .......................... Literaturverzeichnis .............................................................. Die Autoren .........................................................................

405 409 413 413 413 414 417 425 427 429

Index ........................................................................................... 435

14

796.book Seite 15 Montag, 6. November 2006 7:40 19

Vorwort zur zweiten Auflage

Seit dem erstmaligen Erscheinen dieses Buches im Jahre 2002 hat sich die SAP-Datenarchivierung sowohl funktional als auch qualitativ weiterentwickelt. Eine Fülle neuer Funktionen und Verbesserungen, die mit den Releases SAP NetWeaver 2004s und mySAP ERP 2005 zur Verfügung stehen, erleichtern ihren Einsatz und komplettieren sie in zentralen Bereichen. Die vielleicht auffälligste Neuerung in konzeptioneller Hinsicht stellt die Einbettung der Datenarchivierung in den erweiterten Kontext des Information Lifecycle Managements (ILM) dar. ILM ist ein holistischer Ansatz zur aktiven Verwaltung aller Informationsobjekte in einem System über deren gesamten Lebenszyklus hinweg. Es umfasst Technologien, Prozesse und Konzepte, deren primäres Ziel es ist, dem Nutzer stets die richtigen Informationen zur richtigen Zeit am richtigen Ort und zu den niedrigsten Kosten bereitzustellen. Weitere Neuerungen, die Eingang in die zweite Auflage gefunden haben, sind die XML-basierte Archivierung, die die »klassische«, ADK-basierte Archivierung im Java- und XML-Umfeld ergänzt, die Partitionierung im Bereich des Archivinformationssystems zum besseren Management großer Tabellen sowie Archive Routing, das eine automatische Separierung der archivierten Daten ermöglicht, z. B. um gesetzliche Anforderungen besser zu erfüllen. Neu im Vergleich zur Erstauflage ist auch die Beschreibung des Archive File Browser (AFB), der den Archivadministrator bei der Lösung von Problemen mit Archivdateien unterstützt, sowie ein Kapitel zur Archivierung in mySAP ERP HCM. Das Kapitel zur Analysetransaktion TAANA wurde komplett aktualisiert und ergänzt, etwa durch die Beschreibung der Funktionen für virtuelle Feldkataloge und zur Durchführung von Analysen im Massenbetrieb. Auch die Archivierung in SAP NetWeaver BI hat sich im Vergleich zur Archivierung in der Vorgängerkomponente SAP BW erheblich gewandelt, etwa durch die Entwicklung des Konzepts der Nearline-Ablage. Dies spiegelt sich auch im Kapitel zur Archivierung in SAP NetWeaver BI wider, das zu großen Teilen ergänzt und aktu-

15

Neue Themen in dieser Auflage

796.book Seite 16 Montag, 6. November 2006 7:40 19

Vorwort zur zweiten Auflage

alisiert wurde. Ein weiterer Schwerpunkt der Entwicklung lag auf der Vereinheitlichung und Verbesserung der Archivierungsprotokolle, die jetzt zentral aus der Transaktion SARA erreichbar sind. Des Weiteren wurde der gesamte Inhalt des Buches auf den neuesten Stand gebracht. Dies schließt die Anpassung der Terminologie sowie, wo erforderlich, eine Aktualisierung der Grafiken und Screenshots mit ein. Angesichts der Fülle an neuen und aktualisierten Informationen in dieser neuen Auflage bin ich überzeugt, dass dieses Buch nicht nur dem Einsteiger in das Thema Datenarchivierung, sondern auch dem versierten Anwender und Leser der ersten Auflage eine wertvolle Hilfe bei allen archivierungsrelevanten Aufgaben sein wird; ich wünsche viel Erfolg dabei. Danksagung

Neben den neuen Autoren, die bei der Erstellung der aktuellen Auflage mitgewirkt haben und denen ich an dieser Stelle nochmals herzlich danke, möchte ich es nicht versäumen, folgenden Kolleginnen und Kollegen im Namen des gesamten Autorenteams ebenfalls meinen Dank auszusprechen: Olaf Schmidt für das Korrekturlesen des Kapitels zum Document Relationship Browser; Tanja Kaufmann für ihre terminologische Unterstützung und Hilfe bei der Verfassung des Kapitels zum Information Lifecycle Management; Harold »Ken« Campbell, ohne den viele der neuen Beispiele und Screenshots nicht möglich gewesen wären; und nicht zu vergessen Dr. Ulrich Marquard, Senior Vice President bei SAP, dem als aktiver Sponsor dieses Projekts besonderer Dank gebührt. Walldorf, November 2006 Helmut Stefani, Herausgeber und Co-Autor

16

796.book Seite 17 Montag, 6. November 2006 7:40 19

Geleitwort der DSAG

Datenarchivierung in SAP-Systemen – ein sich weiterentwickelndes Arbeitsgebiet mit wachsenden Aufgaben und wachsender Bedeutung für Unternehmen. Bei der Betreuung von SAP-Systemen stellt sich schon kurze Zeit nach dem Produktivstart jedes Systems aufgrund wachsender Datenvolumen und unbefriedigender Performance die Frage, welche Daten wie lange im System gehalten werden müssen, welche aufbewahrungspflichtig sind und welche gelöscht werden können. Eine frühzeitige Berücksichtigung des Themas Datenarchivierung innerhalb eines SAP-Projekts ist also notwendig, um Probleme im Systembetrieb von Beginn an zu vermeiden. Durch regelmäßige Archivierungsmaßnahmen kann das Datenwachstum verlangsamt und das System in einen Gleichgewichtszustand mit guter Performance gebracht werden. Bei der Datenarchivierung sind unterschiedliche Anforderungen zu berücksichtigen: Zum einen sind dies gesetzliche Vorgaben zur Aufbewahrung und Auswertbarkeit von Unternehmensdaten sowie Anforderungen von Anwendern an den komfortablen Zugriff auf ältere Daten. Zum anderen sind es technische Erfordernisse hinsichtlich Systemperformance, Backup- und Recovery-Zeiten, aber auch Hardware- und Administrationskosten. Die Berücksichtigung dieser unterschiedlichen Aspekte hat zur Folge, dass in Archivierungsprojekten Experten verschiedenster Unternehmensbereiche zusammenarbeiten müssen: Systemtechniker und Basisbetreuer, Anwendungsbetreuer, Key-User aus den betroffenen Abteilungen, Mitarbeiter aus Rechenzentren und aus Revisions- und Sicherheitsabteilungen sowie Wirtschaftsprüfer. Ihre Aufgaben reichen von der Datenbankanalyse und der Auswahl geeigneter Archivierungsobjekte über Customizing und eventuell auch Programmierung und den Test der Archivierungsabläufe bis hin zu ersten Archivierungsläufen in der Produktivumgebung und dem Routinebetrieb mit Überprüfung der Auswirkungen auf System-

17

796.book Seite 18 Montag, 6. November 2006 7:40 19

Geleitwort der DSAG

größe und -performance. Auch die Berücksichtigung von Abhängigkeiten zwischen der Datenarchivierung und der Dokumentenablage und die Klärung von Fragen zu Berechtigungen, zur Ablage und zum Zugriff auf archivierte Daten gehören dazu. Die Erweiterungen der Funktionen und Tools der SAP-Datenarchivierung in den letzen Jahren unterstützen die Durchführung dieser Aufgaben. Mit SAP R/3 Enterprise wurde die Vereinheitlichung in der Datenarchivierung realisiert, die die Administration wesentlich vereinfacht und übersichtlicher gemacht hat. Das Anhalten von Archivierungsläufen, eine Statistikfunktion, die Steuerung der Hintergrundjobs vollständig durch externe Scheduler über die neue XBP-2.0-Schnittstelle und die Tabellenanalyse über Transaktion TAANA gehören auch zu den Weiterentwicklungen. Im Rahmen von mySAP ERP 2005/SAP NetWeaver 2004s sind Archive Routing, die Partitionierung von Tabellen des Archivinformationssystems und die XML-basierte Archivierung hinzugekommen. Mit dem Konzept des Information Lifecycle Management (ILM) stellen sich neue Aufgaben und Herausforderungen an alle, die sich mit Datenarchivierung in SAP-Systemen beschäftigen. Allen Leserinnen und Lesern wünsche ich, dass sie mit Datenarchivierung mit SAP die neuen Möglichkeiten in der Datenarchivierung entdecken und für ihre tägliche Arbeit, aber auch für neue Projekte und Strategien nutzen können. Gütersloh, November 2006 Dipl-Inf. Jutta Gimpel

Miele & Cie KG GTZ/IT Betrieb Sprecherin der DSAG-Arbeitsgruppe Datenarchivierung

18

796.book Seite 19 Montag, 6. November 2006 7:40 19

Danksagung zur ersten Auflage

Am Gelingen eines solch umfangreichen Projekts, wie es das vorliegende Buch darstellt, haben erfahrungsgemäß nicht nur die Autoren einen gehörigen Anteil, sondern auch eine Vielzahl anderer »hilfreicher Geister«, die namentlich aufzuführen den Umfang dieses Textes sprengen würde. Ihnen allen gebührt der Dank des gesamten Autorenteams. Ein besonderer Dank gilt Dr. Peter Zencke und Dr. Ulrich Marquard, ohne deren Unterstützung dieses Buch nicht möglich gewesen wäre. Erwähnen möchten wir gerne auch Wolfgang Röder, den »Urvater« der SAP-Datenarchivierung, der ihre Entwicklung initiiert und über einen langen Zeitraum mit geprägt hat. Dank schulden wir auch Dr. Rolf Gersbacher, der an vielen Dokumenten mitgewirkt hat, die in das Buch eingeflossen sind, Erik Meyers für seine Grafikentwürfe, Dokumentationsbeiträge und Terminologiearbeit sowie René Bacher für seinen sprachlichen Spürsinn bei der Durchsicht mehrerer Kapitel. Ihnen und allen anderen, die uns bei der Realisierung dieses Buches mit Rat und Tat unterstützt haben, sei auf diesem Wege herzlich gedankt. Walldorf, im Mai 2002 Das Autorenteam

Helmut Stefani (Herausgeber und Co-Autor)

19

796.book Seite 161 Montag, 6. November 2006 7:40 19

Dieses Kapitel erläutert, welche Möglichkeiten es gibt, um auf archivierte Daten für die Anzeige oder Auswertung zuzugreifen. Der Schwerpunkt des Kapitels liegt auf dem Einsatz und der Optimierung der Werkzeuge Archivinformationssystem und Document Relationship Browser. Es richtet sich insbesondere an Administratoren, die diese Werkzeuge einstellen und bedienen.

4

Zugriff auf archivierte Daten von Dr. Martin Fischer, Thorsten Pferdekämper

Auch nachdem die Daten archiviert und somit aus der Datenbank ausgelagert wurden, kann das System noch darauf zugreifen. Wäre es grundsätzlich nicht möglich, archivierte Daten anzuzeigen, müssten diese womöglich in die Datenbank zurückgeladen werden (siehe auch Abschnitt 2.3.2), was die Datenarchivierung ad absurdum führen würde. Sinn und Zweck der Datenarchivierung ist es ja schließlich, nicht mehr benö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 durch die Datenbank, wodurch – mindestens rein technisch – andere Zugriffskonzepte verwendet werden müssen als bei Daten, die sich noch in der Datenbank befinden (das SELECT-Statement kann nicht auf archivierte Daten zugreifen). Ob sich dieser Sachverhalt allerdings bis zum Endbenutzer auswirkt, hängt davon ab, wie die Archivzugriffe im konkreten Fall implementiert sind.

4.1

Einführung

Es gibt verschiedene Möglichkeiten, um auf archivierte Daten zuzugreifen. Prinzipiell kann jede Archivdatei gelesen werden, die im selben System und Mandanten entstanden ist. Wie ein Archivzugriff für ein

161

Zugriffsmöglichkeiten

796.book Seite 162 Montag, 6. November 2006 7:40 19

4

Zugriff auf archivierte Daten

bestimmtes Archivierungsobjekt in Bezug auf Handhabung, Protokoll, Aufbereitung der Ergebnisse etc. ausgeprägt ist, hängt von den Programmen ab, die die jeweilige Anwendung bereitstellt. Die Bandbreite der Möglichkeiten ist hier jedoch sehr groß: Am unteren Rand des Spektrums gibt es Anwendungen, die keine speziellen Programme zur Verfügung stellen. In diesem Fall lassen sich die archivierten Daten nur mit Hilfe des Archivinformationssystems darstellen. Eine solche Darstellung ist aber eher technischer Natur, ähnlich der Anzeige von Daten aus der Datenbank im Data Browser (Transaktion SE16). Am oberen Rand des Spektrums sind die Archivzugriffe so gut in die Anwendung eingebunden, dass der Endanwender gar nicht merkt, ob die angezeigten Daten aus der Datenbank oder aus dem Archiv stammen. In diesem Kapitel beschreiben wir die verschieden Zugriffskonzepte beispielhaft an Archivierungsobjekten aus dem Rechnungswesen. Die vorgestellten Szenarien erheben jedoch keinen Anspruch auf Allgemeingültigkeit, da kaum ein Archivierungsobjekt tatsächlich über jede der beschriebenen Zugriffsmöglichkeiten verfügt. Fast alle Archivierungsobjekte weisen jedoch zumindest eine der aufgezeigten Möglichkeiten auf. Was in diesem Kapitel nicht behandelt wird

Die folgenden Begriffe und Konzepte werden häufig im Zusammenhang mit dem Zugriff auf archivierte Daten verwendet, berühren diese Thematik jedoch nur am Rande und sollen daher in diesem Kapitel nicht weiter beschrieben werden. Wir möchten jedoch kurz auf diese Themen eingehen, um sie deutlich vom Kontext der Archivzugriffe abzugrenzen: 왘

Drucklistenablage

Wenn Sie bereits vor der Datenarchivierung eine genaue Vorstellung davon haben, wie die späteren Archivzugriffe aussehen sollen, könnten Sie diese Art der Auswertung vor der Datenarchivierung durchführen und die entstandenen Drucklisten auf geeigneten Medien ablegen. Wird ein späterer Zugriff gewünscht, kann dann die entsprechende Liste herausgesucht und angezeigt werden. Hierbei handelt es sich jedoch nicht um einen echten Archivzugriff. Weitere Informationen zu Drucklisten finden Sie in Abschnitt 3.2.3.4. 왘

Dokumentenablage

Mit der Dokumentenablage, die oft auch optische Archivierung genannt wird, können gescannte Originaldokumente oder andere

162

796.book Seite 163 Montag, 6. November 2006 7:40 19

Einführung

Dateien, die zu einem Business-Objekt – etwa einem Finanzbuchhaltungsbeleg – gehören, abgelegt, mit dem entsprechenden Objekt verknüpft und später wieder angezeigt werden. Zugriffe auf diese Dokumente haben allerdings wenig mit der Datenarchivierung zu tun. 왘

Rückladen

Durch Rückladen der archivierten Daten in die Datenbank könnte prinzipiell der Zustand vor der Archivierung wiederhergestellt werden. Danach könnten die normalen Auswertungen über diese Daten durchgeführt werden. Aus verschiedenen Gründen, die bereits in Abschnitt 2.3.2 erläutert wurden, sollte das Rückladen jedoch als Korrektur einer fehlerhaften Archivierung angesehen werden und nicht als Möglichkeit, archivierte Daten auszuwerten. 왘

DART

DART (Data Retention Tool) wurde ursprünglich entwickelt, um die Anforderungen der US-amerikanischen Steuerbehörden an die Auswertung elektronischer Daten zu erfüllen. DART gewinnt derzeit aber auch im europäischen Raum zunehmend an Bedeutung. Es ermöglicht die Extraktion steuerrelevanter Daten aus dem System und deren Speicherung in einfachen Textdateien, so genannten Flat Files. Das Werkzeug beinhaltet auch Funktionen zur Suche und Anzeige der gespeicherten Daten. Bei der Betrachtung von Daten, die über DART extrahiert und abgelegt wurden, ist es nicht von Bedeutung, ob die Quelldaten inzwischen archiviert wurden. Allerdings kann mit DART nur auf einen eng definierten Umfang steuerrelevanter Daten zugegriffen werden. Weitere Informationen zu DART finden Sie in Abschnitt 1.6.2. 왘

Kontenschreibung in der Finanzbuchhaltung

Ähnlich wie bei DART werden bei der Kontenschreibung in der Finanzbuchhaltung Dateien exportiert, die eine bestimmte Sicht auf Belege des Systems repräsentieren. Allerdings handelt es sich hier ausschließlich um Buchhaltungsbelege. 왘

Zugriffe auf abgelegte Archivdateien

In diesem Kapitel wird davon ausgegangen, dass das ADK auf die Archivdateien zugreifen kann. Das heißt, die Dateien liegen entweder direkt im Dateisystem, oder die Ablage ist so konfiguriert, dass die Funktionen des ADK auf das Ablagemedium zugreifen können. Weitere Informationen zur Ablage der Archivdateien finden Sie in Kapitel 3.

163

4.1

796.book Seite 164 Montag, 6. November 2006 7:40 19

4

Zugriff auf archivierte Daten

4.2

Grundlagen

Grundlegende Schritte

Unabhängig von der Art des Zugriffs sind prinzipiell folgende Schritte für die Identifizierung und Anzeige der archivierten Daten erforderlich. Es ist vor allem die Realisierung dieser Schritte, durch die sich die verschiedenen Zugriffsmöglichkeiten unterscheiden.

Auswahl

1. Auswahl der Archivdateien sowie der zu lesenden BusinessObjekte innerhalb einer Archivdatei

Hier lassen sich zwei verschiedene Techniken unterscheiden: Bei der ersten handelt es sich um die manuelle Auswahl durch den Benutzer. Die Auswahl der gewünschten Archivdateien erfolgt anhand eines vom System angebotenen Auswahlfensters, wie es in Abbildung 4.1 zu sehen ist. Die zweite Technik besteht darin, die Bestimmung der zu lesenden Archivdateien ohne weitere Benutzerinteraktion dem System zu überlassen. Die Bestimmung basiert auf einem so genannten Archivindex, den das System nach Selektionskriterien, die der Benutzer eingegeben hat, liest. Bei einem Archivindex handelt es sich um eine Datenbanktabelle, die außer anwendungsspezifischen Selektionsfeldern, wie zum Beispiel einer Belegnummer, auch den Schlüssel der Archivdatei enthält, in der die entsprechenden Daten zu finden sind.

Abbildung 4.1 Dialogfenster zur Auswahl von Archivdateien

164

796.book Seite 165 Montag, 6. November 2006 7:40 19

Sequenzielle Leseprogramme

4.3

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

Öffnen

3. 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 Archivierungslauf gestartet wurde. Das heißt, dass durch die Auswahl der Archivdateien mehr als der gewünschte Datenumfang im Archiv gelesen wird. Daher muss das Programm – auch wenn es bereits nur die Business-Objekte gelesen hat, die von Belang sind – in einem weiteren Schritt die tatsächlich vom Benutzer gewünschten Daten herausfiltern.

Filtern

4. Anzeige der gewünschten Daten Die Aufbereitung der im Archiv gelesenen Daten zur Anzeige kann auf unterschiedliche Weise erfolgen. Das Spektrum der Möglichkeiten erstreckt sich von einer rein technischen Anzeige, die dem Data Browser (Transaktion SE16) entspricht, bis hin zu einer für Daten aus der Datenbank üblichen betriebswirtschaftlichen Anzeige. Die erste Möglichkeit findet man beispielsweise beim Archivinformationssystem, während die zweite Möglichkeit bei solchen Anwendungen zu finden ist, die den Archivzugriff voll in ihre Anzeigefunktionen integriert haben. Dort ist dann den Daten nicht mehr anzusehen, ob sie aus dem Archiv oder aus der Datenbank stammen.

Aufbereitung zur Anzeige

4.3

Sequenzielle Leseprogramme

Benutzern, die sich mit der Datenarchivierung befassen, fällt zum Thema Archivzugriff meist zuerst die Drucktaste Lesen in der Archivadministration (Transaktion SARA) auf. Dahinter verbergen sich in der Regel Programme, mit denen vom Benutzer ausgewählte Archivdateien sequenziell gelesen werden. Diese Programme wurden speziell für die Auswertung von Archivdateien geschrieben und operieren in der Regel ausschließlich auf archivierten Daten. Die Anzeige

165

796.book Seite 166 Montag, 6. November 2006 7:40 19

4

Zugriff auf archivierte Daten

der Daten erfolgt in den meisten Fällen in einer auf die Bedürfnisse des Endbenutzers abgestimmten Art. Diese Programme eignen sich insbesondere zur Kontrolle der archivierten Daten. Beispiel

Ein Beispiel für ein solches sequenzielles Leseprogramm ist das zum Archivierungsobjekt CO_ORDER (Innenaufträge) gehörende Programm RKAARCS1, das ebenfalls über die oben genannte Drucktaste zur Verfügung steht. Nach der Eingabe der Selektionskriterien können Sie das Programm ausführen und erhalten das bereits oben (siehe Abbildung 4.1) dargestellte Dialogfenster zur Auswahl der Archivdateien. Dabei ist zu beachten, dass die Selektionskriterien keinen Einfluss darauf haben, welche Archivdateien zur Auswahl angeboten werden. Unabhängig von den Selektionskriterien werden immer alle zugreifbaren Dateien zur Auswertung angeboten. Sie sollten also darauf achten, dass die Auswahl der Archivdateien zu den gewählten Selektionskriterien passt. Wählen Sie nicht alle relevanten Dateien aus, werden unter Umständen nicht alle gewünschten Daten angezeigt. Da das Programm alle Dateien sequenziell liest, 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 sequenziell durch und filtert die Daten nach den angegebenen Selektionskriterien. Für die Laufzeit des Programms fallen die Selektionskriterien kaum ins Gewicht. Entscheidend ist die Auswahl der Archivdateien. Nach der Selektion wird der Inhalt der Archivdatei meist als Liste dargestellt. Im obigen Beispiel der Innenaufträge können Sie aus der erzeugten Liste weiternavigieren; dies ist aber eher untypisch für diese Art von Auswertungen.

Einplanung im Hintergrund

Neben der Ausführung im Dialog können Sie ein Archivleseprogramm auch im Hintergrund einplanen. Die Einplanung entspricht im Wesentlichen der manuellen Einplanung eines Löschprogramms. Der Unterschied besteht darin, dass das Leseprogramm eine Variante zur Übergabe der Selektionskriterien benötigt.

Programme mit nachträglich erweiterter Archivlesefunktion

Während die über die Archivadministration verfügbaren Programme in der Regel dedizierte Archivleseprogramme sind, gibt es auch Programme, die ursprünglich für normale Auswertungen von Daten aus der Datenbank entwickelt, jedoch nachträglich um Funktionen für Archivzugriffe erweitert wurden. Ein gewisser Nachteil dieser Programme ist, dass die Benutzer wissen müssen, ob sich die Daten im

166

796.book Seite 167 Montag, 6. November 2006 7:40 19

Direktzugriffe

Archiv befinden und, falls ja, in welcher Archivdatei sie gespeichert sind. Das Ergebnis dieser Mühe ist jedoch, dass die Daten in einem ihnen vertrauten Format dargestellt werden. Ein Beispiel hierfür sind die Summenberichte (Report-Writer-Berichte) im Gemeinkosten-Controlling. Über die Drucktaste Datenquelle können Sie auf dem Selektionsbild eines solchen Programms festlegen, dass nicht aus der Datenbank, sondern aus dem Archiv gelesen werden soll (siehe Abbildung 4.2). An dieser Stelle werden auch die Archivdateien gewählt.

Abbildung 4.2 Auswahl der Datenquelle in Report-Writer-Berichten

Technisch betrachtet, gehört die Auswahl der Datenquelle (Datenbank oder Archiv) sowie der zu lesenden Archivdateien zum Selektionsbild, obwohl die Angaben dazu nicht direkt auf dem Selektionsbild zu sehen sind. Dies bedeutet, dass beim Speichern einer Selektionsvariante auch die Datenquelle mit abgespeichert wird. Dies ermöglicht beispielsweise das Anlegen einer Variante zur Auswertung bestimmter Archive im Hintergrund. In der Liste, die nach der Ausführung des Programms angezeigt wird, ist nicht mehr zu erkennen, ob es sich um Daten aus der Datenbank oder aus dem Archiv handelt.

4.4

Direktzugriffe

Das sequenzielle Lesen ganzer Archivdateien mit vorheriger manueller Dateiauswahl ist insbesondere dann sinnvoll, wenn ein großer Anteil der Daten in der Archivdatei gelesen werden soll und der

167

4.4

796.book Seite 168 Montag, 6. November 2006 7:40 19

4

Zugriff auf archivierte Daten

Benutzer weiß, in welchen Dateien sie sich befinden. Dies ist zum Beispiel dann der Fall, wenn der Inhalt einer Archivdatei überprüft werden soll. Für die meisten Endbenutzer eignen sich aber eher Funktionen, die möglichst wenig Wissen über die Archivierung erfordern. Am besten sind automatische Archivzugriffe dafür geeignet. Zwar ist hier der Konfigurations- und Administrationsaufwand etwas höher, aber dem Endbenutzer wird die meiste Arbeit abgenommen. Beispiel

Ein Beispiel für eine solche Funktion bietet die Anzeige der Buchhaltungsbelege (Transaktion FB03). Diese greift immer automatisch auch auf archivierte FI-Belege zu, so dass der Benutzer unter Umständen gar nicht mehr merkt, dass die angezeigten Daten bereits archiviert wurden. Insbesondere muss er sich nicht überlegen, ob die Daten gegebenenfalls archiviert sein könnten, bevor er die Transaktion ausführt.

Datenquelle

Bei einigen Anzeigetransaktionen, wie z. B. KE5Z zur Auswertung von Ist-Einzelposten (siehe Abbildung 4.3) oder KE5Y von Plan-Einzelposten im Profit Center, kann der Benutzer vor Ausführen der Transaktion über Zusätze • Datenquelle… festlegen, ob die Daten in der Datenbank, im Archiv oder in beiden Quellen gelesen werden sollen. Bei Wahl des Archivs kann er zusätzlich festlegen, ob der Archivzugriff automatisch über das Archivinformationssystem oder manuell durch Auswahl der entsprechenden Archivdateien erfolgen soll.

Abbildung 4.3 Auswahl der Datenquelle bei Anzeigetransaktionen Archivindex zur Lokalisierung der Daten

Die Information darüber, dass der gesuchte Beleg archiviert wurde und an welcher Stelle er sich im Archiv befindet, ist dabei in der Regel in einer Archivinfostruktur des Archivinformationssystems oder eventuell noch in einem anwendungsspezifischen Archivindex

168

796.book Seite 169 Montag, 6. November 2006 7:40 19

Direktzugriffe

4.4

gespeichert. Mit Hilfe der Selektionskriterien des entsprechenden Programms wird aus dem Archivindex der Ort im Archiv (also die Archivdatei und der Offset) bestimmt, an dem sich die Daten befinden. Im vorliegenden Beispiel wird der anwendungsspezifische Archivindex nur noch bei lesenden Zugriffen unterstützt, aber nicht mehr fortgeschrieben.1 Es handelt sich hierbei um die Datenbanktabelle ARIX_BKPF. In Tabelle 4.1 sehen Sie die für das Beispiel relevanten Felder. 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

Wenn die Beleganzeige einen Beleg mit Hilfe des anwendungsspezifischen Archivindex im Archiv sucht, greift sie zuerst auf diese Datenbanktabelle zu. Anhand der Felder Buchungskreis, Belegnummer und Geschäftsjahr ist sie in der Lage, die Archivdatei sowie den Offset des Business-Objekts, in dem sich der gesuchte Beleg befindet, zu ermitteln. Das Lesen im Archiv erfolgt dann per Direktzugriff. Das Programm liest also nicht die ganze Archivdatei sequenziell durch, sondern positioniert beim Öffnen der Datei den Zeiger direkt auf den gewünschten Offset und liest nur das in Frage kommende Business-Objekt. Diese Art des Archivzugriffs ist wesentlich effizienter als das sequenzielle Lesen von archivierten Daten, wenn nur ein oder wenige Business-Objekte gelesen werden sollen. Diese Methode ist allerdings nicht dafür geeignet, einen schnellen Zugriff über andere Felder als die im Archivindex enthaltenen durchzuführen. In unserem Beispiel kann über den anwendungsspezifi1 Dies ist ab mySAP ERP 2005 der Fall. Ab diesem Release wird für die Indizierung von archivierten FI-Belegen nur noch das Archivinformationssystem unterstützt. Falls Sie alte anwendungsspezifische Indizes auf der Basis von ARIX_BKPF aufgebaut haben, können Sie diese jedoch weiterhin lesen. Weitere Informationen finden Sie in den SAP-Hinweisen 807726 und 596865.

169

Suche nur über Felder, die im Archivindex enthalten sind

796.book Seite 170 Montag, 6. November 2006 7:40 19

4

Zugriff auf archivierte Daten

schen Archivindex auf das Archiv nur zugegriffen werden, wenn Buchungskreis, Belegnummer und Geschäftsjahr bekannt sind. Eine Suche über andere Felder des Belegs, zum Beispiel über das Konto, ist nicht möglich, da dieses Feld nicht im Archivindex enthalten ist. Hier sind die Archivindizes des Archivinformationssystems dem starren Konzept des anwendungsspezifischen Archivindex überlegen. Aufbau des Archivindex

Der Archivindex wird bei Archivierungsobjekten, die dieses Konzept unterstützen, während der Löschphase automatisch aufgebaut. Ein nachträglicher manueller Auf- und Abbau dieser Indexinformationen ist ebenfalls möglich. Dazu erscheint bei Archivierungsobjekten, die diese Funktion unterstützen, im Einstiegsbild der Archivadministration die Drucktaste Index. Der automatische Aufbau während der Löschphase erfolgt nur, wenn der Indexaufbau im archivierungsobjektspezifischen Customizing durch Setzen des gleichnamigen Kennzeichens aktiviert wurde. Dieses Kennzeichen wird aber nur angeboten, wenn das Archivierungsobjekt die Indexfunktion unterstützt. Durch Setzen des Kennzeichens erreichen Sie, dass der Archivindex bei künftigen Löschläufen automatisch aufgebaut wird. Für Archivdateien, die das Löschprogramm vor dem Setzen dieses Kennzeichens bearbeitet hat, wurde kein Archivindex aufgebaut. Dies geht aus den Details zur jeweiligen Archivdatei hervor, die Sie der Archivverwaltung entnehmen können. Für solche Archivdateien können Sie den nachträglichen Indexaufbau starten. Dabei handelt es sich im Wesentlichen um ein sequenzielles Leseprogramm, das die gelesenen Daten jedoch nicht ausgibt, sondern lediglich einen Extrakt davon erzeugt und ihn – angereichert mit dem Schlüssel der Archivdatei und dem Offset – in die Datenbanktabelle des Archivindex schreibt.

4.5 Nachteile konventioneller Zugriffsmethoden

Archivinformationssystem

Trotz vieler Vorteile weisen die bisher beschriebenen konventionellen Zugriffsmethoden auch eine Reihe von Nachteilen auf, die hauptsächlich auf technische Einschränkungen sowie die Anwendungsabhängigkeit der Methoden zurückzuführen sind: 왘

Bei sequenziellen Zugriffen muss der Benutzer die richtigen Archivdateien kennen.

170

796.book Seite 171 Montag, 6. November 2006 7:40 19

Archivinformationssystem

왘

Sequenzielle Zugriffe dauern zu lange, wenn nur einzelne Belege aus dem Archiv angezeigt werden sollen.

왘

Direktzugriffe über anwendungsspezifische Archivindizes sind nicht in allen Fällen implementiert.

왘

Anwendungsspezifische Direktzugriffe funktionieren nur über die vom Entwickler vorgesehenen Felder.

왘

Der Auf- und Abbau von Archivindizes ist anwendungsspezifisch. Es gibt zwar eine allgemeine Vorgehensweise des Auf- und Abbaus von Archivindizes aus der Archivadministration, aber die Programme, die den Auf- oder Abbau tatsächlich durchführen, sind anwendungsspezifisch.

4.5

Diese Nachteile entfallen bei Verwendung des Archivinformationssystems (AS). Dieses speziell für Archivzugriffe konzipierte Werkzeug ermöglicht Ihnen, eigene Archivindizes zu konfigurieren, sie mit Daten aus dem Archiv zu füllen und nach archivierten Daten zu recherchieren. Genauso wie bei einem anwendungsspezifischen Archivindex werden auch hier Archivdatei und Offset ergänzt, was einen Direktzugriff auf die archivierten Daten erlaubt. Zusätzlich bietet das Archivinformationssystem eine generische, also nicht anwendungsspezifische, Anzeige aller Inhalte eines Business-Objekts aus dem Archiv. Es funktioniert mit allen, also auch kundeneigenen, Archivierungsobjekten und erfordert keine anwendungsspezifischen Programme oder Modifikationen.

Vorteile des Archivinformationssystems

Das Archivinformationssystem ist also das Werkzeug, wenn es um den schnellen Zugriff auf archivierte Daten geht. Allerdings ist hier dem Begriff »Werkzeug« besondere Beachtung zu schenken: Durch die generische Ausrichtung des Archivinformationssystems können anwendungsspezifische Besonderheiten nicht bzw. nur teilweise berücksichtigt werden. Es handelt sich also um ein eher technisches Werkzeug, das den Bedürfnissen des Endanwenders nicht in jeder Hinsicht genügen kann.

Werkzeug der Wahl für Archivzugriffe

Der zentrale Begriff im Umfeld des Archivinformationssystems ist die Archivinformationsstruktur2. Dieser Begriff ersetzt gewissermaßen den oben eingeführten Begriff des Archivindex. Jeder Archivzugriff durch das Archivinformationssystem erfolgt über eine

Archivinformationsstruktur

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

171

796.book Seite 172 Montag, 6. November 2006 7:40 19

4

Zugriff auf archivierte Daten

Infostruktur. Infostrukturen werden mit Hilfe des Archive Retrieval Configurator (Transaktion SARJ), der Customizing-Komponente des Archivinformationssystems, angelegt. Das Füllen der Daten in die Infostruktur erfolgt – analog zu den Archivindizes – entweder direkt während der Löschphase oder nachträglich durch den Benutzer. Wie auch bei einem Archivindex werden die Daten zu einer Infostruktur in einer Datenbanktabelle gehalten. Eine weitere Komponente des Archivinformationssystems, der Archive Explorer, unterstützt die Datensuche innerhalb einer Infostruktur und ermöglicht Direktzugriffe auf die archivierten Daten und letztlich deren Anzeige. Feldkatalog

Jede Infostruktur gehört nicht nur eindeutig zu einem Archivierungsobjekt, sie bezieht sich auch eindeutig auf einen bestimmen Feldkatalog. Ein Feldkatalog ist im Wesentlichen eine Sammlung von Feldern, die für die Indizierung der Archivdateien des betreffenden Archivierungsobjekts geeignet sind. Die Felder einer Infostruktur sind immer eine Auswahl der Felder des zugehörigen Feldkatalogs. Außerdem enthält der Feldkatalog eine Reihe von technischen Eigenschaften, die ebenfalls in die Infostruktur übernommen werden. Durch das Konzept der Feldkataloge ist es zum Anlegen einer Infostruktur nicht notwendig, technische Einzelheiten des Archivierungsobjekts zu kennen, da diese im Feldkatalog bereits abgelegt sind. Zum Anlegen einer Infostruktur muss der Benutzer lediglich die Felder auswählen. Im Folgenden werden der Einsatz des Archivinformationssystems und einige Hintergründe dazu beschrieben. Die einzelnen Schritte sind in der Reihenfolge aufgeführt, in der sie der Benutzer oder Administrator normalerweise ausführt, wenn das Archivinformationssystem für ein Archivierungsobjekt erstmalig eingesetzt werden soll. Sämtliche hier aufgeführten Funktionen sind über die zentrale Verwaltung des Archivinformationssystems (Transaktion SARI) zu erreichen. Weitergehende Informationen zum Archivinformationssystem bietet Ihnen die Hilfe zur Anwendung.

4.5.1 StandardInfostrukturen nicht ändern

Anlegen einer Infostruktur

Bevor Sie eine eigene Infostruktur anlegen, sollten Sie prüfen, ob bereits eine Infostruktur vorhanden ist, die Sie zur Auswertung der archivierten Daten verwenden können. Diese Infostruktur können Sie bei Bedarf kopieren und an eigene Anforderungen anpassen. Sie

172

796.book Seite 173 Montag, 6. November 2006 7:40 19

Archivinformationssystem

sollten aber keine von SAP ausgelieferten Infostrukturen ändern. Eine solche Änderung bedeutet eine Modifikation und wird beim nächsten Upgrade oder bei der Installation von Support Packages unter Umständen rückgängig gemacht. Beim Anlegen einer Infostruktur legen Sie fest, welche Felder aus dem Archiv in die Infostruktur übernommen werden. Dazu wählen Sie die gewünschten Felder aus einem Feldkatalog aus und übernehmen diese in die Infostruktur (siehe Abbildung 4.4). Zu vielen Archivierungsobjekten sind bereits Feldkataloge in der Standardauslieferung enthalten. Falls für Ihre Anforderungen kein Feldkatalog existiert, können Sie einen eigenen anlegen. Näheres dazu finden Sie in Abschnitt 4.5.7.

Felder übernehmen

Abbildung 4.4 Anlegen einer Infostruktur im Archive Retrieval Configurator

Einige Felder des Feldkatalogs werden aus technischen Gründen sofort in die Infostruktur übernommen und können nicht entfernt werden. Meist handelt es sich dabei um die Schlüsselfelder. Die meisten Felder eines Feldkatalogs gehören jedoch zum Vorrat der

173

Schlüsselfelder

4.5

796.book Seite 174 Montag, 6. November 2006 7:40 19

4

Zugriff auf archivierte Daten

wählbaren Felder, die Sie in die Infostruktur übernehmen können. Über alle Felder der Infostruktur können Sie später nach archivierten Daten suchen. Beachten Sie jedoch, dass Infostrukturen in der Datenbank abgelegt werden und somit auch jedes weitere Feld, das in die Infostruktur übernommen wird, zusätzlichen Platz in der Datenbank beansprucht.

4.5.2

Partitionieren einer Infostruktur

Bessere Handhabung der Tabellen zu Infostrukturen

Um sehr große Datenmengen in den Infostrukturen handhaben zu können, besteht die Möglichkeit, Infostrukturen zu partitionieren, d. h., die Daten der Infostruktur auf mehrere Datenbanktabellen zu verteilen. Dann werden nicht alle Daten in eine einzige Tabelle geschrieben, sondern auf mehrere Tabellen verteilt. Das Partitionierungskriterium ist dabei das Entstehungsdatum des Archivierungslaufs. So könnte die Partitionierung beispielsweise so konfiguriert werden, dass die Sätze einer Infostruktur für die Läufe jedes Kalenderjahres in eine andere Tabelle geschrieben würden. Das zugrunde liegende Konzept ist dabei so flexibel, dass die Partitionierung nicht von Anfang an festgelegt werden muss und jederzeit geändert werden kann.

Tabellennamen selbst festlegen

Im Rahmen der Partitionierung wurde auch die Möglichkeit geschaffen, die Tabelle (bzw. die Tabellen) zu einer Infostruktur fest vorzugeben. Dadurch ist es möglich, die Tabellennamen und die gewünschten technischen Einstellungen der Tabellen frei zu wählen und die Tabellen selbst zu transportieren. Dies bietet den Vorteil, dass die Tabellen zu einer Infostruktur in einer Systemlandschaft überall denselben Namen und dieselben Eigenschaften haben und leichter zu administrieren sind. Hinweis

Die Konfiguration der Partitionierung ist Teil der Infostruktur selbst und wird somit mit dieser transportiert und ausgeliefert. Eine Änderung der Partitionierung an SAP-Infostrukturen wäre somit eine Modifikation, so dass Sie die Partitionierung praktisch nur für kundeneigene Infostrukturen verwenden können. Wenn eine SAP-Infostruktur schon sehr viele Daten enthält, können Sie diese über Hilfsmittel 폷 Daten übernehmen direkt in eine eigene Infostruktur mit geeigneter Partitionierung übernehmen, ohne die SAPInfostruktur ab- und die eigene Infostruktur neu aufbauen zu müssen.

174

796.book Seite 175 Montag, 6. November 2006 7:40 19

Archivinformationssystem

4.5

Die Ausführung dieser Funktion dauert in der Regel nur wenige Sekunden. Achten Sie darauf, dass die eigene Infostruktur dabei auf demselben Feldkatalog basiert wie die SAP-Infostruktur, da sich sonst Lesezugriffe in der Applikation anders verhalten können.

4.5.3

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 Archiv gefüllt und ausgewertet werden. Aktive Infostrukturen können jedoch nicht mehr geändert werden. Wie es schon beim Konzept der anwendungsspezifischen Archivindizes der Fall war, benötigt auch das Archivinformationssystem eine Datenbanktabelle, um die Indexdaten zu speichern. Diese ist allerdings nicht fest vorgegeben, sondern wird beim Aktivieren der Infostruktur anhand der verfügbaren Informationen generiert. Die Felder dieser Tabelle setzen sich zusammen aus 왘

dem Mandanten

왘

den Feldern der Infostruktur

왘

dem Schlüssel der Archivdatei

왘

dem Offset des Business-Objekts in der Archivdatei

Datenbanktabelle für Indexdaten

Für das obige Beispiel sieht die generierte Datenbanktabelle aus, wie in Abbildung 4.5 dargestellt.

Abbildung 4.5 Datenbanktabelle zur Infostruktur

Zur Auswertung dieser Tabelle und für den Zugriff aufs Archiv zur Anzeige der archivierten Daten wird außerdem ein Auswertungsprogramm generiert. Nach der Generierung der Datenbanktabelle und des Auswertungsprogramms setzt das System für die betreffende

175

Auswertungsprogramm

796.book Seite 176 Montag, 6. November 2006 7:40 19

4

Zugriff auf archivierte Daten

Infostruktur ein Aktiv-Kennzeichen. Dieses Kennzeichen besagt, dass die Infostruktur nun für Auswertungen genutzt werden kann und dass sie während des Laufs des entsprechenden Löschprogramms automatisch aufgebaut werden soll.

4.5.4

Aufbau einer Infostruktur

Während der Löschphase der Datenarchivierung werden alle zu einem Archivierungsobjekt gehörenden aktiven Infostrukturen automatisch mit Daten aus der betreffenden Archivdatei gefüllt. Ausgehend von der definierten Infostruktur, filtert das Archivinformationssystem die Daten aus den Datensätzen im Archiv und fügt sie zusammen mit dem Schlüssel der Archivdatei und dem Offset des Business-Objekts in die generierte Datenbanktabelle ein. Diese Einträge dienen als Grundlage für die spätere Recherche. Nachträglicher Aufbau

Neben dem automatischen Aufbau durch das Löschprogramm kann eine Infostruktur auch nachträglich für schon vorhandene Archive aufgebaut werden. Sie haben somit die Möglichkeit, Infostrukturen bei Bedarf aufzubauen, etwa um Daten auszuwerten, die bereits vor der Einführung des Archivinformationssystems archiviert wurden, oder um die Felder einer Infostruktur zu ändern.

Aufbaustatus

Beim Aufbau einer Infostruktur erfolgt neben dem Füllen der generierten Datenbanktabelle mit Daten aus dem Archiv auch die Führung eines Aufbaustatus. Anhand dieses Status können Sie in der Statusverwaltung des Archivinformationssystems erkennen, für welche Archivdateien die zugehörigen Infostrukturen aufgebaut wurden.

4.5.5 Auswertungsprogramm als Grundlage

Auswerten einer Infostruktur

Die Suche nach archivierten Daten im Archive Explorer erfolgt stets auf der Grundlage des beim Aktivieren der Infostruktur erzeugten Auswertungsprogramms. Das Selektionsbild des Auswertungsprogramms enthält alle Felder der Infostruktur, außer den Feldern Mandant, Schlüssel der Archivdatei und Offset. Bei Ausführung des Programms erhalten Sie eine Liste aller Einträge in der Infostruktur, die zu Ihren Selektionskriterien passen. Bis zu diesem Punkt im Auswertungsprozess ist noch kein Zugriff aufs Archiv erfolgt; das System hat lediglich die in der Infostruktur gespeicherten Indexdaten gelesen. Per Doppelklick auf einen Listeneintrag können Sie nun einen

176

796.book Seite 177 Montag, 6. November 2006 7:40 19

Archivinformationssystem

4.5

Direktzugriff ins Archiv vornehmen und in der Datenhierarchie bis auf Feldebene hinunternavigieren. Die vom Archive Explorer gezeigte Sicht der Daten ist sehr technisch und daher für Endanwender weniger geeignet. Eine solche technische Sicht stellt das Archivinformationssystem für jedes Archivierungsobjekt zur Verfügung. Zum Anpassen der Anzeige an die Anforderungen der Endanwender hat SAP das Konzept der betriebswirtschaftlichen Sichten eingeführt. Dieses Konzept besagt, dass die archivierten Daten in einer Form dargestellt werden, wie sie der Endanwender erwarten würde bzw. die er von der Anzeige der betreffenden Daten aus der Datenbank kennt. Inwiefern diese Art der Darstellung unterstützt wird, hängt vom Archivierungsobjekt ab. Die meisten Archivierungsobjekte haben gar keine betriebswirtschaftliche Sicht im Archivinformationssystem, während beispielsweise zum Archivierungsobjekt CO_ORDER sogar mehrere betriebswirtschaftliche Sichten ausgeliefert werden. Beim Doppelklick auf einen Eintrag der Infostruktur werden Sie erst zur Auswahl der gewünschten Sicht aufgefordert, wie in Abbildung 4.6 dargestellt.

Technische und betriebswirtschaftliche Sichten

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

Die normale Auswertung einer Infostruktur durch den Archive Explorer setzt voraus, dass die Infostruktur vorher aufgebaut wurde. Das bedeutet, dass nur Dateien, die den Status Löschen fertig haben, ausgewertet werden können. Das ist auch sinnvoll, da alle anderen Daten prinzipiell noch in der Datenbank sind, also kein Grund besteht, diese Daten im Archiv zu suchen. Möglicherweise möchten Sie aber im Vorfeld der Löschphase die archivierten Daten nur überprüfen. Zu diesem Zweck steht Ihnen die Funktion Ad-hoc-Auswer-

177

Ad-hocAuswertungen

796.book Seite 178 Montag, 6. November 2006 7:40 19

4

Zugriff auf archivierte Daten

tung zur Verfügung. Bei dieser Art der Auswertung greift das System nicht auf die generierte Datenbanktabelle zu, sondern führt einen sequenziellen Lesezugriff auf die von Ihnen gewählten Archivdateien durch. Der Datenbestand, der sonst beim Aufbau einer Infostruktur anfallen würde, wird lediglich intern gespeichert. Die nachfolgende Anzeige der Daten und die Navigationsmöglichkeiten entsprechen dann denen einer normalen Auswertung einer Infostruktur. Hinweis

Die Auswertung aufgebauter Infostrukturen mit dem Archive Explorer oder auch andere Zugriffe auf das Archivinformationssystem (siehe Abschnitt 4.6) sind dann besonders schnell, wenn das System über den Primärindex der zugehörigen Datenbanktabelle zugreifen kann. Für Zugriffe über andere Felder als die des Primärindex werden unter Umständen zusätzliche Datenbankindizes benötigt. Da die Tabellen des Archivinformationssystems im Produktivsystem generiert werden, ist das Anlegen eines solchen Index über das ABAP Dictionary in den meisten Fällen nicht durchführbar. Außerdem könnte es passieren, dass bei einer Neugenerierung der Datenbanktabelle der Index wieder gelöscht wird. Datenbankindizes für Infostrukturen

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

4.5.6

Abbau einer Infostruktur

Die in einer generierten Datenbanktabelle gespeicherten Daten benötigen – wie Daten in anderen Datenbanktabellen auch – Plattenplatz. Aus diesem Grund ist es im Allgemeinen sinnvoll, Daten für ältere Archivdateien nach einer bestimmten Zeit wieder zu löschen. Da die Quelldaten bereits archiviert wurden, kommt eine Archivierung dieser Daten nicht mehr in Betracht. Grundsätzlich haben Sie jedoch die Möglichkeit, Infostrukturen manuell wieder abzubauen. Diese Funktion liefert Ihnen die zusätzliche Flexibilität, Infostrukturen je nach Bedarf auf- bzw. abzubauen, beispielsweise wenn die Archivzugriffe nicht ständig benötigt werden. Explizites Abbauen

Im Gegensatz zum Aufbau von Infostrukturen gibt es für den Abbau keine Integration mit dem ADK. Das bedeutet, dass der Abbau immer explizit angesteuert werden muss. Dies ist insbesondere beim

178

796.book Seite 179 Montag, 6. November 2006 7:40 19

Archivinformationssystem

4.5

Zurückladen von Archiven zu beachten. Wenn Sie archivierte Daten zurückladen, müssen Sie aktive Infostrukturen für die entsprechenden Dateien explizit abbauen und für die beim Rückladeprozess gegebenenfalls entstandenen Archivdateien die Infostrukturen explizit aufbauen.

4.5.7

Anlegen eines Feldkatalogs

Für viele Anwendungsfälle werden Standardfeldkataloge von SAP ausgeliefert. Diese erkennen Sie an ihrem Namen, der mit »SAP_« beginnt. Bevor Sie also eigene Feldkataloge anlegen, sollten Sie auf jeden Fall prüfen, ob Sie nicht doch einen Standardfeldkatalog benutzen können. Auf keinen Fall sollten Sie einen Standardfeldkatalog modifizieren, auch nicht durch Aufnahme neuer Felder. Bei einem Releasewechsel oder bei der Installation von 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.

Standardfeldkataloge nicht ändern

Sie können jedoch einen Standardfeldkatalog in Ihren eigenen Namensraum kopieren und die gewünschten Änderungen an der Kopie vornehmen. Sie sollten allerdings auch bedenken, dass Standardprogramme in der Regel Infostrukturen, die auf der Basis kundeneigener Feldkataloge erstellt wurden, ignorieren. Solche Infostrukturen können Sie also meist nur im Archive Explorer und in eigenen Programmen nutzen. Das Anlegen eines Feldkatalogs setzt ein bestimmtes Expertenwissen voraus. So müssen Sie beispielsweise wissen, welche Tabellen mit einem bestimmten Archivierungsobjekt archiviert werden und aus welchen Einträgen dieser Tabellen ein Business-Objekt jeweils besteht. Diese Zusammenhänge sollten Sie kennen, bevor Sie für ein Archivierungsobjekt einen neuen Feldkatalog anlegen. Dies ist insbesondere für die Abschätzung der zu erwartenden Datenmenge und für Feldkataloge mit mehreren Quelltabellen wichtig.

Expertenwissen erforderlich

Im Folgenden wird ein typisches Vorgehen beschrieben, das für die meisten Fälle angewandt werden kann. Dabei wird zwischen Feldkatalogen mit einer und mit mehreren Quelltabellen unterschieden. Wie Sie beim Anlegen eines Feldkatalogs im Einzelnen vorgehen und welche Bedeutung die jeweiligen Felder und Kennzeichen

Ein Beispiel für Finanzbuchhaltungsbelege

179

796.book Seite 180 Montag, 6. November 2006 7:40 19

4

Zugriff auf archivierte Daten

haben, können Sie der Hilfe zur Anwendung sowie der Feldhilfe entnehmen. Bei der nachfolgenden Vorgangsbeschreibung gehen wir daher davon aus, dass Sie die Bedeutung der einzelnen Felder kennen und dass Sie sich mit der Art, wie Einträge vorgenommen werden, vertraut gemacht haben. Als Beispiel soll uns ein Feldkatalog für Finanzbuchhaltungsbelege dienen, die mit Hilfe des Archivierungsobjekts FI_DOCUMNT archiviert werden. Ein solcher Beleg besteht unter anderem aus einem Belegkopf und mehreren Positionen. Der Belegkopf ist in der Tabelle BKPF gespeichert, die Positionen befinden sich in der Tabelle BSEG.

4.5.7.1 Anlegen eines Feldkatalogs mit einer Quelltabelle Zum Anlegen eines Feldkatalogs mit einer Quelltabelle gehen Sie wie folgt vor: 1. Auswahl der Quelltabelle Das Archivinformationssystem kann zum Füllen einer Infostruktur jede Tabelle und jede Struktur verwenden, die in den entsprechenden Archivdateien gespeichert ist. Welche der Tabellen eines Archivierungsobjekts verwendet wird, hängt davon ab, über welche Felder Sie nach archivierten Objekten suchen möchten. Beachten Sie jedoch, dass eine Suche über die Felder einer Positionstabelle grundsätzlich mehr Platz in der Datenbank benötigt als die Suche in einer Kopftabelle. Dies liegt daran, dass eine Positionstabelle im Allgemeinen mehr Einträge besitzt als eine Kopftabelle. Außerdem enthält die generierte Datenbanktabelle nach dem Aufbau der Infostruktur in der Regel genauso viele Einträge, wie es Einträge der führenden Tabelle des Feldkatalogs in den Archivdateien gibt. In unserem Beispiel wurde die Tabelle BKPF des Archivierungsobjekts FI_DOCUMNT gewählt. Es soll möglich sein, nach den Feldern Belegnummer, Geschäftsjahr und Buchungsdatum zu suchen. 2. Name des Feldkatalogs Der Name eines Feldkatalogs unterliegt denselben Beschränkungen wie die Namen anderer Systemobjekte, zum Beispiel Datenbanktabellen. Verwenden Sie nur Buchstaben, Zahlen und den Unterstrich. Der Name sollte mit einem Buchstaben beginnen, aber nicht mit dem Kürzel »SAP«. Es wird empfohlen, einen Namen im eigenen Namensraum zu verwenden.

180

796.book Seite 181 Montag, 6. November 2006 7:40 19

Archivinformationssystem

In unserem Beispiel wählen wir »ZDEMO_BKPF« als Namen. 3. Kopfeintrag des Feldkatalogs Geben Sie den Namen, die Bezeichnung und das Archivierungsobjekt des neuen Feldkatalogs ein. Tragen Sie in der Spalte Datei im Index ein »K« (Schlüsselfeld) und in der Spalte Offset im Index ein »D« (Datenfeld) ein. 4. Schlüsselfelder des Feldkatalogs Für die meisten Fälle ist es sinnvoll, alle Schlüsselfelder der Referenztabelle, mit Ausnahme des Mandanten, als Schlüsselfelder des Feldkatalogs zu verwenden. Es wird empfohlen, als Feldnummern die Nummern 10, 20, 30 usw. zu wählen. Auf jeden Fall sollten Sie sicherstellen, dass die Nummern der Schlüsselfelder kleiner als die Nummern der Datenfelder sind. Ebenso ist es empfehlenswert, als Feldnamen den auch in der Referenztabelle verwendeten Feldnamen zu verwenden. Stellen Sie sicher, dass die Kennzeichen Obligatorisches Schlüsselfeld und Wählbares Feld für Schlüsselfelder nicht gesetzt sind. Das Kennzeichen Key muss für Schlüsselfelder gesetzt sein. Im Beispiel wurden alle Schlüsselfelder der Tabelle BKPF (außer dem Mandanten) als Schlüsselfelder in den Feldkatalog aufgenommen. 5. Datenfelder des Feldkatalogs In den meisten Fällen ist es sinnvoll, alle Datenfelder der Referenztabelle zu Datenfeldern des Feldkatalogs zu machen. Für die Nummerierung der Datenfelder wird empfohlen, die Nummern 100, 110, 120 usw. zu verwenden. Stellen Sie sicher, dass die Kennzeichen Key und Obligatorisches Schlüsselfeld für Datenfelder nicht gesetzt sind. Das Kennzeichen Wählbares Feld sollte für Datenfelder eingeschaltet sein. Bei den Datenfeldern ist es in der Regel sinnvoll, möglichst viele Felder der Referenztabelle in den Feldkatalog aufzunehmen. Ein weiteres Datenfeld in einem Feldkatalog kostet, im Gegensatz zur Aufnahme eines Feldes in eine Infostruktur, weder nennenswerten Speicherplatz noch Laufzeit. Allerdings sollten Sie nur Felder in den Feldkatalog aufnehmen, die auch als Selektionskriterien von Programmen funktionieren. Insbesondere sollten also keine Felder des Datentyps FLTP (Gleitkommazahl) verwendet werden. Auch Felder der Datentypen CURR und QUAN sollten weggelas-

181

4.5

796.book Seite 182 Montag, 6. November 2006 7:40 19

4

Zugriff auf archivierte Daten

sen werden, da diese im Allgemeinen falsch aufbereitet werden. Weitere Informationen zu diesen Datentypen finden Sie im SAPHinweis 309384.

4.5.7.2 Anlegen eines Feldkatalogs mit mehreren Quelltabellen Um einen Feldkatalog mit mehreren Quelltabellen anzulegen, verfahren Sie nach folgendem Muster: 1. Auswahl der Quelltabellen Für die Auswahl mehrerer Quelltabellen gilt das Gleiche wie für die Auswahl einer Quelltabelle. Zusätzlich ist aber darauf zu achten, dass die Quelltabellen gewissen Abhängigkeitsbedingungen genügen müssen. Tabellen, die in keinem Verhältnis zueinander stehen, können auch nicht gemeinsam in einem Feldkatalog verwendet werden. In der Regel sollten 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 DOCUMNT, sind dies die Tabellen BKPF und BSEG.

FI_

2. Ermittlung der Abhängigkeiten Die Verwendung mehrerer Quelltabellen durch das Archivinformationssystem ist nur möglich, wenn die Tabellen in einer hierarchischen Abhängigkeitsbeziehung stehen. Welche Tabelle von welcher abhängig ist, wird über Schlüsselfelder mit gleicher Semantik definiert. In der Regel verfügen diese Felder in den verschiedenen Tabellen über denselben Namen. Für die Definition eines Feldkatalogs muss es möglich sein, alle Quelltabellen so anzuordnen, dass jede Tabelle, die von einer anderen Tabelle abhängt, auch deren Schlüsselfelder als Schlüsselfelder besitzt. Im Beispiel der Finanzbuchhaltungsbelege sind die Tabellen BKPF und BSEG über die Felder Buchungskreis, Belegnummer und Geschäftsjahr verbunden. Einträge aus BKPF und BSEG, die in diesen Feldern gleich sind, gehören zusammen. Die Tabelle BSEG ist abhängig von der übergeordneten Tabelle BKPF und enthält deren Schlüsselfelder als Schlüsselfelder. 3. Ermittlung der führenden Tabelle Nach der Ermittlung möglicher Beziehungen zwischen den beteiligten Tabellen werden Sie feststellen, dass in der Regel mindes-

182

796.book Seite 183 Montag, 6. November 2006 7:40 19

Archivinformationssystem

tens eine Tabelle in Frage kommt, die alle Schlüsselfelder des Feldkatalogs als eigene Felder hat. Möglicherweise gibt es auch mehrere Tabellen mit dieser Eigenschaft. Dies ist dann der Fall, wenn mindestens zwei Tabellen existieren, die gleich viele Schlüsselfelder im Feldkatalog haben. In einem solchen Fall können Sie eine beliebige der in Frage kommenden Tabellen als führende Tabelle wählen. Gibt es jedoch keine Tabelle, die alle Schlüsselfelder des Feldkatalogs als eigene Felder hat, können Sie den Feldkatalog auf diese Weise nicht anlegen. In diesem Fall müssen Sie andere Quelltabellen wählen oder die Beziehungen zwischen den Tabellen überprüfen. In unserem Beispiel handelt es sich dabei um die Tabelle BSEG. 4. Anlegen des Feldkatalogs für die führende Tabelle Ignorieren Sie vorerst alle Tabellen, außer der führenden. Legen Sie den Feldkatalog an, wie in Abschnitt 4.5.6.2 beschrieben. Im Beispiel wird zuerst 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 alle Schlüsselfelder im Feldkatalog sein. Sollte dies nicht der Fall sein, haben Sie entweder bei der Ermittlung der Tabellenabhängigkeiten einen Fehler gemacht, oder Sie haben im letzten Schritt nicht die richtige Tabelle ausgewählt. Wählen Sie nun eine beliebige der verbliebenen Tabellen aus, und tragen Sie deren Schlüsselfelder als weitere Quellfelder beim entsprechenden Schlüsselfeld des Feldkatalogs ein. Übertragen auf unser Beispiel heißt dies, dass das Feld BUKRS der Tabelle BKPF als weiteres Quellfeld des Feldes BUKRS, BKPF-BELNR als weiteres Quellfeld für BELNR sowie BKPF-GJAHR als weiteres Quellfeld für GJAHR eingetragen wird. (Zum Feld BUZEI gibt es keine Entsprechung in der Tabelle BKPF.) Tragen Sie anschließend jedes Datenfeld der Tabelle als neues Datenfeld in den Feldkatalog ein. Beachten Sie dabei dieselben Einschränkungen für Felder des Feldkatalogs, wie sie auch für Feldkataloge mit nur einer Quelltabelle gelten. Wiederholen Sie diesen Schritt für jede noch aufzunehmende Tabelle.

183

4.5

796.book Seite 184 Montag, 6. November 2006 7:40 19

4

Zugriff auf archivierte Daten

4.5.7.3 Typische Fallstricke beim Anlegen von Feldkatalogen Wenn Sie einen Feldkatalog wie oben beschrieben anlegen, sollte es in den meisten Fällen keine Fehler beim Aufbau der zugehörigen Infostrukturen geben. In einigen Fällen kommt es unter Umständen aber doch zu Problemen, die bisher noch nicht besprochen wurden. Dies möchten wir im 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äglichen Aufbau einer Infostruktur die Fehlermeldung »Sätze in Infostruktur nicht eingefügt« (Q6330) erscheint. Neben den anderen im Langtext dieser Meldung erwähnten Ursachen kann auch ein fehlerhafter Feldkatalog dafür verantwortlich sein. Dies liegt dann daran, dass der Schlüssel des Feldkatalogs nicht vollständig definiert wurde bzw. nicht zur Struktur der Archivdateien passt. Die oben beschriebene Vorgehensweise beruht auf der Annahme, dass die Tabelleneinträge, die durch den im Feldkatalog angegebenen Schlüssel definiert wurden, in einer Archivdatei nicht mehrfach 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ösung

Zur Lösung dieses Problems kommen prinzipiell zwei Strategien in Betracht: Einerseits können Sie versuchen, den Schlüssel des Feldkatalogs durch Ergänzen weiterer Schlüsselfelder eindeutig zu machen. Andererseits besteht die Möglichkeit, das Business-Objekt selbst, also den Offset in der Archivdatei, zum Schlüsselfeld zu machen. Dies erreichen Sie durch Eintragen eines »K« in der Spalte Offset im Index im Kopfeintrag des Feldkatalogs. Dadurch wird der Offset zum Schlüsselfeld der generierten Datenbanktabelle. Fehlerszenario 2: »Infostruktur ist inkonsistent«

Erscheint hingegen während der Löschphase oder beim nachträglichen Aufbau einer Infostruktur die Meldung »Infostruktur ist inkonsistent« (Q6234), liegt das meistens nicht an der Infostruktur selbst, sondern an der Definition des Feldkatalogs. Wie oben bereits dargelegt, müssen Feldkataloge mit mehreren Quelltabellen bestimmten Konsistenzbedingungen genügen. So müssen die Quelltabellen so sortiert werden, dass die Schlüsselfelder jeder Quellta-

184

796.book Seite 185 Montag, 6. November 2006 7:40 19

Auf dem Archivinformationssystem basierende Archivzugriffe

belle eine Untermenge der Schlüsselfelder der vorhergehenden Quelltabelle in der Sortierreihenfolge sind. Überprüfen Sie daher, ob die weiteren Quellfelder für alle Schlüsselfelder richtig eingegeben wurden und ob der Feldkatalog nach der oben angegebenen Vorgehensweise erstellt wurde. Möglicherweise müssen Sie eine Quelltabelle aus dem Feldkatalog entfernen, um die Konsistenz des Feldkatalogs herzustellen.

4.6

Lösung

Auf dem Archivinformationssystem basierende Archivzugriffe

Im Abschnitt über Direktzugriffe wurde eine Möglichkeit beschrieben, bei der ein Endbenutzer auf archivierte Daten zugreifen kann, ohne Näheres über die Archivierung wissen zu müssen bzw. ohne zu wissen, ob sich die Daten im Archiv oder noch in der Datenbank befinden. Das System ermittelt bei solchen Zugriffen selbstständig, ob sich die Daten im Archiv befinden und in welcher Archivdatei sie gespeichert sind. Der Archivzugriff erfolgt dann in der Regel automatisch durch das System, ohne Interaktion mit dem Benutzer. Der Vorteil solcher Zugriffe ist die konsequente Integration archivierter Daten in die gewohnte Anzeigetransaktion. Allerdings ist bei der oben beschriebenen Lösung ein anwendungsspezifisches Konzept zur Indizierung archivierter Daten notwendig. Beim Archivinformationssystem verhält es sich genau umgekehrt: Es handelt sich um ein einheitliches Verfahren zur Indizierung archivierter Daten, bei dem jedoch keine ausreichende Integration mit den gewohnten Anzeigetransaktionen stattfindet. Mit Hilfe der Programmierschnittstelle des Archivinformationssystems ist es möglich, aus einem Programm auf die Daten einer Infostruktur zuzugreifen und diese wie einen anwendungsspezifischen Archivindex zu nutzen. Dies ermöglicht die Integration archivierter Daten in die gewohnte Anwendungstransaktion, ohne den Nachteil verschiedener anwendungsspezifischer Indexlösungen in Kauf nehmen zu müssen. Ein Beispiel für eine solche Funktionalität stellen die Einzelpostenberichte der Kostenrechnung in mySAP ERP dar. Abbildung 4.6 zeigt den Einzelpostenbericht für Innenaufträge (Transaktion KOB1) mit

185

Beispiel

4.6

796.book Seite 186 Montag, 6. November 2006 7:40 19

4

Zugriff auf archivierte Daten

den Einzelposten eines archivierten Innenauftrags. Aus ihm ist nicht mehr ersichtlich, ob die Daten aus der Datenbank oder aus dem Archiv stammen. Der Benutzer muss dies auch nicht wissen, um sich die Einzelposten anzeigen zu lassen.

Abbildung 4.7 Einzelpostenbericht für Aufträge

Standardmäßig greifen die Einzelpostenberichte der Kostenrechnung nicht automatisch auf archivierte Daten zu. Dies muss dem System erst über die Tabelle ASACCESS01 mitgeteilt werden. Hier lässt sich einstellen, ob der Bericht grundsätzlich nur von der Datenbank liest oder über das Archivinformationssystem automatisch die archivierten Daten mit einbezieht. Damit die Berichte über das Archivinformationssystem archivierte Daten finden 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 aufgebaut wurde. Standardfeldkatalog verwenden

Im oben gezeigten Beispiel wurden die Einzelposten mit dem Archivierungsobjekt CO_ITEM archiviert. Aus diesem Grund wird eine Infostruktur 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 Verwendung einer von SAP ausgelieferten Infostruk-

186

796.book Seite 187 Montag, 6. November 2006 7:40 19

Document Relationship Browser

4.7

tur, sondern die Verwendung eines passenden, von SAP ausgelieferten Feldkatalogs. Infostrukturen, die mit Bezug auf kundeneigene Feldkataloge angelegt wurden, werden von den Einzelpostenberichten ignoriert. Ein Grund dafür ist, dass die Anwendung – in diesem Fall der Einzelpostenbericht – die Anwesenheit bestimmter Felder mit einer bestimmten Bedeutung im Feldkatalog voraussetzt. Bei der Verwendung kundeneigener Feldkataloge wäre dies nicht mit ausreichender Sicherheit gegeben. Es ist allerdings möglich, neben der für die Einzelpostenberichte benötigten Infostruktur eine weitere Infostruktur mit Bezug auf einen anderen Feldkatalog zu verwenden. Diese ist für den Einzelpostenbericht unproblematisch, verbraucht aber zusätzlichen Speicherplatz in der Datenbank. Ein solcher Archivzugriff verläuft im Wesentlichen wie das Lesen eines anwendungsspezifischen Index, mit dem Unterschied, dass statt von der anwendungsspezifischen Indextabelle von einer geeigneten Infostruktur gelesen wird. Obwohl sich hinter der Infostruktur auch eine Datenbanktabelle verbirgt, sind deren Felder nicht fest vorgegeben, sondern werden erst bei der Konfiguration der Infostruktur ausgewählt. Ein weiterer Unterschied zwischen dem vorgestellten Einzelpostenbericht und einem Direktzugriff – etwa zur Anzeige der Buchhaltungsbelege (Transaktion FB03) – besteht darin, dass beim Einzelpostenbericht oft mehrere Business-Objekte aus dem Archiv gelesen werden, die dann über die Selektionskriterien weiter gefiltert werden. Es handelt sich hier gewissermaßen um einen indexsequenziellen Zugriff.

4.7

Document Relationship Browser

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

187

Daten aus dem Archiv und aus der Datenbank

796.book Seite 188 Montag, 6. November 2006 7:40 19

4

Zugriff auf archivierte Daten

Eine weitere Stärke des DRB ist die Anzeige archivierter Objekte, sein Einsatz ist aber auch dann sinnvoll, wenn die Datenarchivierung noch nicht genutzt wird. In diesem Kapitel möchten wir vor allem auf die Fähigkeiten des DRB in Bezug auf archivierte Daten eingehen. Wie Sie weitere Informationen zum DRB erhalten, können Sie im SAP-Hinweis 492938 nachlesen. Archivinformationssystem als Basis

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

DRB ist ein Service

Der DRB stellt keine eigenständige Anwendung dar, sondern nur einen Service, der für jeweils ein Einstiegsobjekt aufgerufen wird. Es gibt in den Anwendungen verschiedene Transaktionen und Reports, von denen aus für jeweils ein Einstiegsobjekt in den DRB verzweigt werden kann. Die meisten dieser Funktionen sind in der Rolle Document Relationship Browser (SAP_DRB) zusammengefasst. Neben einigen einfachen Listen zum Auffinden von Belegen gehören auch die Beleganzeige in der Finanzbuchhaltung (Transaktion FB03) sowie die Einzelpostenberichte des Gemeinkosten-Controlling dazu. Nach dem Einstieg über ein Business-Objekt eines bestimmten Typs, beispielsweise eines Kundenauftrags, wie in Abbildung 4.7 dargestellt, zeigt das Programm an, welche Business-Objekte mit dem Einstiegsobjekt verknüpft sind. Die Anwendungen liefern zu einem Objekt jeweils die direkt damit verknüpften Objekte. Was das im Einzelnen bedeutet, ist in der jeweiligen Anwendung festgelegt. Die Verknüpfungen zwischen den Business-Objekten haben keine weitere Semantik; es ist also nicht zu erkennen, ob ein Objekt Vorgänger oder Nachfolger eines anderen Objekts ist. Die Darstellung im DRB verdeutlicht lediglich, dass zwischen den Objekten eine Verknüpfung besteht.

Mehrfach verknüpfte Objekte werden nur einmal angezeigt

Um eine zyklische und damit unnötig komplizierte Darstellung der verknüpften Business-Objekte zu vermeiden, wird jedes Objekt innerhalb des zugrunde liegenden Geschäftsprozesses nur einmal angezeigt. Dies ist auch dann der Fall, wenn ein Objekt mit mehreren Objekten direkt verknüpft ist. Das führt dazu, dass nicht alle direkten Verknüpfungen auch tatsächlich dargestellt werden. Außerdem kann die Darstellung – abhängig davon, welches Einstiegsobjekt

188

796.book Seite 189 Montag, 6. November 2006 7:40 19

Document Relationship Browser

4.7

Sie gewählt haben und in welcher Reihenfolge Sie durch den Verknüpfungsbaum navigieren – variieren. Es ist jedoch sichergestellt, dass die Menge der insgesamt angezeigten Objekte gleich bleibt, unabhängig von der Reihenfolge der einzelnen Navigationsschritte. Bei der Darstellung des DRB werden im ersten Schritt nur die Objekte angezeigt, die direkt mit dem Einstiegsobjekt verknüpft sind. Sind weitere Objekte mit diesen Objekten verknüpft, können Sie diese durch Navigieren in dem angezeigten Verknüpfungsbaum ebenfalls anzeigen. In Abbildung 4.7 wurde als Einstiegsobjekt der Kundenauftrag 132 gewählt. Im Verknüpfungsbaum sehen Sie alle Business-Objekte, die mit diesem Kundenauftrag verknüpft sind.

Abbildung 4.8 Mit einem Kundenauftrag verknüpfte Business-Objekte

Durch Doppelklick auf einen Objektschlüssel – in der Regel ist dies die Belegnummer – gelangen Sie in die Objektanzeige. Wie diese Anzeige im Einzelnen aussieht, liegt in der Verantwortung der jeweiligen Anwendung und hängt vom Typ des Business-Objekts ab. Der DRB teilt sich in einen allgemeinen Basiskern und weitere anwendungsspezifische Komponenten auf, zum Beispiel für Vertrieb, Materialwirtschaft und Rechnungswesen. Der Basiskern ist für die oben

189

Die Komponenten des DRB

796.book Seite 190 Montag, 6. November 2006 7:40 19

4

Zugriff auf archivierte Daten

dargestellte Anzeige der Verknüpfungen sowie für die Weiterleitung der vom Objekttyp abhängigen Funktionen in die jeweilige Anwendung zuständig. Die Anwendungskomponenten sorgen unter anderem für die Ermittlung der Verknüpfungen und die Anzeige der einzelnen Business-Objekte. Archivzugriffe sind genau bei den Funktionen notwendig, die von den Anwendungskomponenten durchgeführt werden. Daher greift auch nicht der Basiskern des DRB auf die archivierten Daten zu, sondern die jeweilige Anwendung. Auf welche Weise der Archivzugriff erfolgt und welche Voraussetzungen dafür gelten, hängt somit vom Typ des Business-Objekts ab. Damit der DRB in der Lage ist, auf archivierte Daten zuzugreifen, müssen Sie aber in der Regel für alle Objekttypen Einstellungen im Archivinformationssystem vornehmen. In den meisten Fällen umfasst dies den Aufbau von Infostrukturen zu bestimmten Standardfeldkatalogen (»SAP_...«). Große Teile der Dokumentation zum DRB befassen sich mit den Einzelheiten dieser Einstellungen. Einstieg in den DRB über die Rolle SAP_DRB

Wie bereits erwähnt, ist der DRB nicht in der Lage, sämtliche Aufgaben zur Ermittlung und Anzeige der verknüpften Business-Objekte eigenständig durchzuführen. Er benötigt vielmehr die Unterstützung der Anwendungen, beispielsweise zum Auffinden des vom Benutzer gewählten Einstiegsobjekts. Diese Aufgabe lässt sich mit den schon erwähnten Funktionen 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 bestimmtes Business-Objekt in der Sicht des DRB angezeigt wird. Auch ob ein archiviertes Objekt anders angezeigt wird als ein entsprechendes Objekt aus der Datenbank, hängt von der Anwendung bzw. dem Objekttyp ab.

4.7.1

Angebundene Objekttypen im Detail

In diesem Kapitel möchten wir einige wichtige der an den DRB angebundenen Objekttypen herausgreifen und näher untersuchen. Dabei gehen wir auf die Voraussetzungen ein, die gegeben sein müssen, damit der DRB archivierte Daten dieser Objekttypen auffinden und anzeigen kann. Darüber hinaus sprechen wir über die Verknüp-

190

796.book Seite 191 Montag, 6. November 2006 7:40 19

Document Relationship Browser

fungen, die es zwischen diesen Objekttypen gibt, und darüber, wie sie im DRB dargestellt werden. Details zu weiteren Objekttypen finden Sie in der Dokumentation zum Document Relationship Browser. Tabelle 4.2 gibt Ihnen einen Überblick, welche Objekttypen in mySAP ERP an den DRB angebunden sind. Anwendung

Objekttypen

SAP NetWeaver Application Server

왘

Intermediate Document (IDoc)

왘

Workitems des Workflows

Rechnungswesen

왘

Abrechnungsbeleg

왘

Buchhaltungsbeleg

왘

Buchhaltungsbeleg Direct Input

왘

Kostenrechnungsbeleg

왘

Profit Center-Beleg

왘

Kontoauszugseinzelposten

왘

Ergebnisrechnung

왘

Belege Spezielle Ledger

왘

elektronische Kontoauszüge

왘

Kundenanfrage

왘

Kundenangebot

왘

Kundenauftrag

왘

Kundenreklamationsauftrag

왘

Kundenkontrakt

왘

Kundenlieferplan

왘

Kundenrahmenvertrag

왘

Gutschriftanforderung

왘

Gruppenkontrakt

왘

Retoure

왘

Kostenlose Nachlieferung

왘

Kundenlieferung

왘

Vertriebsunterstützungsbeleg

왘

Kundeneinzelfaktura

왘

Rechnungsliste

왘

Handling Units

왘

Transporte

왘

Anlieferungen

왘

Grobwareneingang

왘

Transportbedarfe

왘

Transportaufträge

Vertrieb

Tabelle 4.2 An den DRB angebundene Objekttypen

191

Überblick

4.7

796.book Seite 192 Montag, 6. November 2006 7:40 19

4

Zugriff auf archivierte Daten

Anwendung

Objekttypen

Materialwirtschaft

왘

Belegzeile Rechnung

왘

Eingangsrechnung

왘

Bestellanforderung

왘

Bestellung

왘

Wareneingang

왘

Instandhaltungsauftrag

왘

Instandhaltungsauftragsrückmeldung

왘

Instandhaltungsmeldung

왘

Servicemeldung

왘

Serviceauftragsrückmeldung

왘

Fertigungsauftrag

왘

Fertigungsauftragsrückmeldung

Instandhaltung und Service

Produktionsplanung und -steuerung

Tabelle 4.2 An den DRB angebundene Objekttypen (Forts.)

Bei dieser Aufstellung ist zu beachten, dass nicht alle aufgeführten Objekttypen in gleicher Weise an den DRB angebunden sind. Beispielsweise gibt es nicht für jeden Objekttyp eine Funktion im System, die das betreffende Objekt im DRB als Einstiegsobjekt aufruft. Es können auch Objekttypen im DRB erscheinen, die in der Tabelle nicht aufgeführt sind. Dies liegt daran, dass einige Funktionen zur Ermittlung der Beziehungen auf generischen Eigenschaften der betreffenden Beziehung beruhen. So findet das System zum Beispiel den Ursprungsbeleg (siehe Abschnitt 4.7.1.1) zu einem Rechnungswesenbeleg stets mit demselben Mechanismus, unabhängig vom Objekttyp des Ursprungsbelegs. Auf diese Weise können Ursprungsbelege gefunden werden, auch wenn deren Objekttyp nicht explizit an den DRB angebunden ist und daher auch nicht in der Tabelle erscheint. In der Regel können solche Objekte jedoch nicht angezeigt werden, wenn sie bereits archiviert sind.

4.7.1.1 Ursprungsbeleg

Buchhaltungsbeleg

Im Rechnungswesen gilt das Prinzip des Ursprungsbelegs. Es besagt, dass jeder Geschäftsvorfall, der im Rechnungswesen sichtbar wird, einen den Vorfall auslösenden Beleg – den Ursprungsbeleg – besitzt. Dieser Beleg selbst muss aber nicht unbedingt im Rechnungswesen liegen. Wird beispielsweise eine Faktura im Vertrieb gebucht, entste-

192

796.book Seite 193 Montag, 6. November 2006 7:40 19

Document Relationship Browser

4.7

hen in der Regel auch ein Buchhaltungs- und ein Kostenrechnungsbeleg (sowie gegebenenfalls weitere Belege im Rechnungswesen). Ursprungsbeleg dieses Geschäftsvorfalls ist die Faktura, obwohl sich diese nicht im Rechnungswesen befindet. Im Sinne des DRB gelten nun alle Rechnungswesenbelege als mit ihrem Ursprungsbeleg verknüpft und umgekehrt. Im obigen Beispiel ist also der Kostenrechnungsbeleg nicht direkt mit dem Buchhaltungsbeleg verknüpft, sondern beide sind mit der Faktura verknüpft. Über diese kann dann auch die zweistufige Beziehung zwischen Kostenrechnungs- und Buchhaltungsbeleg hergestellt werden. Der Absprung in den Document Relationship Browser aus der Beleganzeige wurde weiter oben schon gezeigt. Hierzu sind keine weiteren Voraussetzungen notwendig, außer dass der anzuzeigende Beleg über die Beleganzeige (Transaktion FB03) darstellbar sein muss. Für archivierte Belege bedeutet dies, dass entweder der anwendungsspezifische Archivindex für das Archivierungsobjekt FI_DOCUMNT (Tabelle ARIX_BKPF) aufgebaut ist oder dass eine aktive und aufgebaute Infostruktur zu einem der 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.

Voraussetzungen für die Anzeige im DRB

In der Rolle Document Relationship Browser (SAP_DRB) ist außerdem ein Programm enthalten, das sich ebenfalls für den Einstieg in den DRB aus einem Buchhaltungsbeleg heraus eignet. Den Absprung in den DRB erhalten Sie durch Doppelklick auf den gewünschten Beleg in der Ergebnisliste dieses Programms. Dabei können Sie – ähnlich wie bei den weiter oben beschriebenen Einzelpostenberichten der Kostenrechnung – wählen, ob das Programm aus dem Archiv oder aus der Datenbank lesen soll. Auch der bereits beschriebene Mechanismus, der über die Tabelle ASACCESS01 gesteuert wird, funktioniert mit diesem Programm. Dazu muss lediglich der entsprechende Eintrag für das Programm RDRBFI00 vorgenommen werden. Eine komplette Anbindung archivierter Buchhaltungsbelege an den Document Relationship Browser erhalten Sie folgendermaßen: 왘

Falls Sie das in der Rolle Document Relationship Browser enthaltene Programm RDRBFI00 einsetzen wollen und dabei auch über die Felder Buchungsperiode (BKPF-MONAT) und Referenz (BKPFXBLNR) selektieren möchten, sollten Sie eine Infostruktur zu

193

Anbindung archivierter Buchhaltungsbelege

796.book Seite 194 Montag, 6. November 2006 7:40 19

4

Zugriff auf archivierte Daten

einem der Feldkataloge SAP_FI_DOC_001 oder SAP_FI_DOC_002 verwenden, die auch die Felder Buchungsperiode, Buchungsdatum, Belegart, Referenzbelegnummer, Referenzvorgang, Referenzschlüssel und Logisches System enthält. 왘

Falls Sie dieses Programm nicht einsetzen wollen, darin keinen automatischen Archivzugriff benötigen oder nicht über die genannten Felder selektieren möchten, genügt der anwendungsspezifische Archivindex (ARIX_BKPF), der in der Regel ohnehin aufgebaut wird.

왘

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

4.7.1.2

Kostenrechnungsbeleg

Verteilung auf Archive

Die Behandlung archivierter Kostenrechnungsbelege im DRB ist aufwändiger als zum Beispiel der Umgang mit Buchhaltungsbelegen. Dies liegt an der Art, wie die Belegzeilen auf die Archive verteilt werden. Kostenrechnungsbelege können mit verschiedenen Archivierungsobjekten archiviert werden, wie zum Beispiel CO_ITEM, PP_ ORDER oder SD_VBAK. Ein weiteres Problem besteht darin, dass die Kostenrechnungsbelege nicht belegweise archiviert werden. Bei einer Buchung, an der ein Fertigungsauftrag und eine Kostenstelle beteiligt sind, kommt es vor, dass ein Teil des Belegs in einem PP_ ORDER-Archiv steht, während der andere Teil sich noch in der Datenbank befindet. Für einen Kostenrechnungsbeleg ist es also weder möglich, eindeutig zu bestimmen, in welcher Archivdatei er sich befindet, noch lässt sich feststellen, ob er bereits archiviert wurde oder nicht. Dies kann nur für einzelne Belegzeilen (Einzelposten) ermittelt werden.

Mehrere Feldkataloge und Infostrukturen

Da ein Feldkatalog des Archivinformationssystems vom Archivierungsobjekt abhängt, kann es sein, dass mehrere Feldkataloge und damit Infostrukturen benötigt werden. Für den Zugriff auf Kostenrechnungsbelege werden für die verschiedenen Archivierungsobjekte Feldkataloge ausgeliefert, die mit »SAP_COBK_« beginnen. Um also archivierte Kostenrechnungsbelege an den DRB anzubinden, benötigen Sie für jedes Archivierungsobjekt, mit dem Sie Einzelposten der Kostenrechnung archivieren, eine Infostruktur zum entsprechenden SAP_COBK-Feldkatalog. Damit die Verknüpfungen ermittelt werden können, müssen diese Infostrukturen das Feld REFBN

194

796.book Seite 195 Montag, 6. November 2006 7:40 19

Document Relationship Browser

enthalten. Solche Infostrukturen werden von SAP standardmäßig ausgeliefert, ihr Name beginnt ebenfalls mit »SAP_COBK_«. In der Regel ist es ausreichend, wenn Sie diese Infostrukturen aktivieren und aufbauen. Ein besseres Laufzeitverhalten des Programms erreichen Sie durch Aufnahme der Felder REFBT, AWTYP und AWORG in Ihre Infostrukturen. Allerdings benötigen die Infostrukturen dadurch auch mehr Speicherplatz in der Datenbank, was gegen den Laufzeitvorteil abzuwägen ist. Auf Grund der Art und Weise, wie Kostenrechnungsbelege archiviert werden, entspricht die Anzahl der Einträge in den benötigten Infostrukturen ungefähr der Anzahl der Belegzeilen. Entscheidend sind hier aber nur die Belegzeilen aus Archivdateien, für die die entsprechende Infostruktur aufgebaut wurde. Angesichts des großen Umfangs, den eine solche Infostruktur erreichen kann, sollten Sie daher genau abwägen, ob die Anzeige von archivierten Kostenrechnungsbelegen erforderlich ist. Mit Kostenrechnungsbelegen (wie bei anderen Belegen des Rechnungswesens auch) sind nur die jeweiligen Ursprungsbelege verknüpft. Die Objekte, auf denen die Kosten gesammelt werden, wie zum Beispiel Aufträge und Kostenstellen, gelten nicht als mit dem Kostenrechnungsbeleg verknüpft. Ansonsten könnte der Fall eintreten, dass mit einem Objekt mehrere Millionen Belege verknüpft wären, was den Rahmen des DRB sprengen würde.

4.7.1.3 Kundenauftrag Im Vertrieb entspricht eine Verknüpfung zwischen zwei Belegen der Beziehung, die im Belegfluss als Vorgänger bzw. Nachfolger bezeichnet wird. Allerdings entfällt im DRB die Semantik der Beziehung, so dass man nicht mehr erkennen kann, welcher Beleg der Vorgänger bzw. der Nachfolger ist. Um archivierte Kundenaufträge und andere Verkaufsbelege, die mit dem Archivierungsobjekt SD_VBAK archiviert werden, an den DRB anzubinden, wird lediglich eine aktive und gefüllte Infostruktur zu einem der Feldkataloge SAP_SD_VBAK_ 001 oder SAP_SD_VBAK_002 benötigt. Für Verkaufsbelege existiert in der Rolle Document Relationship Browser ein spezielles Programm, das den Einstieg in den DRB ermöglicht (siehe Abbildung 4.9).

195

4.7

796.book Seite 196 Montag, 6. November 2006 7:40 19

4

Zugriff auf archivierte Daten

Abbildung 4.9 Einstieg in den DRB über Verkaufsbelege

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

Beachten Sie auch die drei Auswahlknöpfe auf dem Selektionsbild, mit denen Sie steuern können, wo die Verkaufsbelege gesucht werden: 왘

Suche in DB

Bei Wahl dieser Option werden die Verkaufsbelege nur in der Datenbank gesucht. Archivierte Verkaufsbelege werden vollständig ignoriert. 왘

Suche in DB und SAP AS

Wenn Sie diese Option wählen, werden Verkaufsbelege in der Datenbank und in den oben aufgeführten Infostrukturen des Archivinformationssystems gesucht. Es werden allerdings keine Archivzugriffe durchgeführt. Dies hat zur Folge, dass in der Ergebnisliste unter Umständen nicht alle Felder gefüllt und nicht alle gewünschten Sätze gefunden werden, da das Programm Felder, die nicht in der Infostruktur enthalten sind, als leer ansieht und daher nicht weiterverfolgt.

196

796.book Seite 197 Montag, 6. November 2006 7:40 19

Document Relationship Browser

왘

4.7

Suche in DB, SAP AS und Archiv

Bei Wahl dieser Option werden Verkaufsbelege in der Datenbank und im Archivinformationssystem gesucht. Für die Belege, die laut Archivinformationssystem gefunden wurden, werden im Archiv die gegebenenfalls fehlenden Daten nachgelesen. Es werden also auch hier nur Belege gelesen, die sich in einer passenden Infostruktur befinden. Diese Auswahl steuert lediglich, was in der Ergebnisliste des Programms angezeigt wird, und nicht, welche verknüpften Belege der DRB später findet. Es kann also vorkommen, dass trotz der Wahl der Option Suche in DB archivierte Belege als verknüpfte Objekte im DRB angezeigt werden. In vielen Fällen lassen sich nur die beiden Optionen Suche in DB und Suche in DB, SAP AS und Archiv sinnvoll einsetzen. Die Option Suche in DB und SAP AS ist zwar häufig schneller als die letztgenannte Option, führt allerdings auch oft zu verwirrenden Ergebnissen, da dem Endanwender in den wenigsten Fällen klar sein dürfte, welche Felder in den Infostrukturen enthalten sind und welche Auswirkungen dies auf die Selektion hat.

Bekannte Fallstricke

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

Anzeige archivierter Logistikbelege

Alle weiteren Objekttypen der Logistik sind in ähnlicher Weise wie die Kundenaufträge an den DRB angebunden. Unterschiede gibt es lediglich bei den verwendeten Feldkatalogen sowie den Feldern, über die selektiert werden kann und die in die Infostrukturen aufgenommen werden sollten. Näheres hierzu finden Sie in der Dokumentation der anwendungsspezifischen Komponenten des Document Relationship Browser.

4.7.2

Konfiguration des Document Relationship Browser

Die bisherige Darstellung des DRB konzentrierte sich hauptsächlich auf die Nutzung des Archivinformationssystems und anderer Funk-

197

796.book Seite 198 Montag, 6. November 2006 7:40 19

4

Zugriff auf archivierte Daten

tionen der Datenarchivierung für den Zugriff auf archivierte Daten. Hinsichtlich der Konfiguration sind wir dabei im Wesentlichen auf die Definition von Infostrukturen eingegangen. Neben dieser wichtigsten Einstellungsmöglichkeit gibt es jedoch weitere Möglichkeiten, um den Zugriff auf archivierte Daten zu optimieren und die Funktionen besser an die Bedürfnisse des Endbenutzers anzupassen. In diesem Zusammenhang sprechen wir folgende Konfigurationsmöglichkeiten an: 왘

Vorbelegung der Einstiegsprogramme

왘

Auswahl der Felder der Einstiegslisten

왘

Auswahl der anzuzeigenden Objekttypen

왘

Auswahl der Felder im DRB

Prinzipiell können sämtliche Einstellungen benutzerspezifisch vorgenommen werden. Alle Einstellungen, bis auf die Auswahl der anzuzeigenden Objekttypen, sind eigentlich nicht spezifisch für den Document Relationship Browser, sondern stammen von den darin verwendeten Werkzeugen. Da sich aber gerade diese Einstellungen hervorragend dafür eignen, den DRB besser an die Datenarchivierung anzupassen, möchten wir im Folgenden näher darauf eingehen und aufzeigen, wie Sie dem Benutzer den 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 Standardauslieferung zwar einige Programme, die für den Einstieg in den DRB geeignet sind, diese Programme sind jedoch so eingestellt, dass sie keine Archivzugriffe vornehmen. Bei den Programmen der Logistik ist die Suchoption Suche in DB voreingestellt. Bei den Programmen des Rechnungswesens ist der automatische Archivzugriff in der Tabelle ASACCESS01 standardmäßig ausgeschaltet. Im Folgenden beschreiben wir, wie Sie diese Programme einer Rolle so zuordnen können, dass die automatischen Archivzugriffe eingeschaltet sind. Selektionsvariante anlegen

Hierzu müssen Sie zunächst für jedes Programm, das Sie verwenden wollen, eine Selektionsvariante anlegen. Über die Feldeigenschaften der Selektionsvariante können Sie unter anderem die Suche in...-Felder vorbelegen und ausblenden. Wird das Programm nun mit dieser

198

796.book Seite 199 Montag, 6. November 2006 7:40 19

Document Relationship Browser

4.7

Variante gestartet, sieht der Benutzer diese Felder auf dem Selektionsbild nicht mehr, und der gewünschte Wert wird automatisch eingesetzt. Für die Einstiegslisten für Buchhaltungsbelege sowie für die Einzelpostenberichte in der Kostenrechnung können Sie analog verfahren. Allerdings können Sie die Felder zur Auswahl der Datenquelle hier nicht ausblenden, da diese Felder ohnehin nicht auf dem Selektionsbild erscheinen. Sie werden jedoch mit der Variante abgespeichert. Natürlich können Sie die Einstiegslisten für Buchhaltungs- und Kostenrechnungsbelege auch über die Tabelle ASACCESS01 steuern, wie weiter oben beschrieben. Allerdings ändert sich dann das Verhalten für alle Benutzer. Falls Sie das System tatsächlich so einstellen wollen, dass die Einzelpostenberichte der Kostenstellenrechnung für alle Benutzer automatisch aus dem Archiv lesen, sollten Sie die Einstellung über ASACCESS01 vorziehen. Nachdem Sie für alle zu verwendenden Programme entsprechende Varianten angelegt haben, können Sie diese Programme (über die Transaktion PFCG) in eine Rolle eintragen. Wird ein solches Programm aus der Rolle, der es zugewiesen wurde, aufgerufen, startet es automatisch mit den Voreinstellungen aus der Variante. Auf diese Weise können Sie eine Rolle zusammenstellen, die alle Programme enthält, die zum Aufruf des DRB führen und die so konfiguriert sind, dass sie automatisch auf das Archiv zugreifen. Über diesen Mechanismus können Sie natürlich auch andere Selektionskriterien als die genannten vorbelegen.

4.7.2.2 Auswahl der Felder der Einstiegslisten Sämtliche in der Rolle Document Relationship Browser enthaltenen Programme wurden mit Hilfe des SAP List Viewer realisiert. Immer wenn 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 Relationship Browser meistens auch relativ komplex dargestellt.

199

Selektionsvariante einer Rolle zuweisen

796.book Seite 200 Montag, 6. November 2006 7:40 19

4

Zugriff auf archivierte Daten

Außerdem kann es auf Grund der Vielzahl von Objekttypen, die der DRB in mySAP ERP unterstützt, zu Laufzeitproblemen bei der Ermittlung der Verknüpfungen kommen, da das Programm versucht, alle Verknüpfungen aufzulösen, obwohl der Benutzer in der Regel nicht alle Objekttypen benötigt. Personalisierte Anzeige

Beispielsweise interessiert sich ein Benutzer zwar für die logistische Kette eines Geschäftsprozesses, nicht aber für die Details im Rechnungswesen. In diesem Fall wäre es sinnvoll, die unerwünschten Objekttypen bei der Anzeige einfach auszublenden. Das Werkzeug, mit dem Sie eine solche selektive Anzeige erreichen können, ist die Personalisierung. Je nachdem, ob die Einstellungen für einzelne Benutzer oder für eine Rolle gelten sollen, erreichen Sie die Personalisierung entweder über die Benutzerpflege (Transaktion SU01) oder über die Rollenpflege (Transaktion PFCG). Einstellungen, die für eine Rolle vorgenommen werden, können automatisch für alle Benutzer, die dieser Rolle zugeordnet sind, übernommen werden. In der Rolle Document Relationship Browser ist die Auswahl der Objekttypen so eingestellt, dass alle Objekte angezeigt werden.

Abbildung 4.10 Auswahl der anzuzeigenden Objekttypen in der Benutzerpflege

200

796.book Seite 201 Montag, 6. November 2006 7:40 19

Document Relationship Browser

4.7

Beim Ausblenden von Objekttypen ist zu beachten, dass die betreffenden Belege nicht nur aus der Anzeige entfernt werden, sondern auch nicht mehr für die Ermittlung weiterer Beziehungen herangezogen werden können. Dies bedeutet, dass nicht nur die explizit ausgeblendeten Objekte von der Anzeige ausgenommen sind, sondern auch diejenigen Objekte, die von den ausgeblendeten Objekten abhängig sind.

4.7.2.4 Auswahl der Felder im DRB Im Navigationsbaum des DRB werden standardmäßig nur Typ und Beschreibung eines Objekts angezeigt. Sie können diese Anzeige erweitern, indem Sie weitere relevante Felder aufnehmen. Außer den technischen Entsprechungen des Objektschlüssels und des Objekttyps sind hier vor allem zwei Felder von Bedeutung: 왘

Das Feld Logisches System gibt an, von welchem logischen System die Daten stammen. Dies ist dann relevant, wenn es sich um systemübergreifende Prozesse oder Geschäftsvorfälle handelt.

왘

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

201

Die Felder Logisches System und Herkunft

796.book Seite 435 Montag, 6. November 2006 7:40 19

Index A Abhängigkeiten zwischen Daten 70 Ablage von Archivdateien alternative 88 asynchrone 145 auf einem Ablagesystem 87, 112 auf einem externen Ablagesystem 53 auf einem HSM-System 53, 87, 151, 155 auf einem magnetplattenbasierten Ablagesystem 54 bekannte technische Probleme 147 manuelle 89, 158 Reihenfolge 89 synchrone 146 über ArchiveLink 52 über WebDAV 52 vor der Löschphase 90 Ablagekriterien 100 Ablagephase 417 Prozessablauf 89 Ablagestrategie Kriterien zur Wahl 99 Ablagesystem 417 Begriffsdefinition 113 blockweiser Zugriff 109 Integration 107 Kosten 105 Langfristigkeit der Ablage 110 mit Dateischnittstelle 53 parallele Auftragsabarbeitung 108 Performance 108 Sicherheit 101 Sicherungsmöglichkeiten 104 Zertifizierung 141 Ablegen für spätere Erfassung 130 AcceleratedSAP 342 Einführungsphasen 342 Ad-hoc Auswertung 178 ADK siehe Archive Development Kit AFB siehe Archive File Browser Aggregate 319, 335 Definition 319

AIND_STR8 178 AIS siehe Audit Information System allgemeine Statusverwaltung 68 Analysetransaktion für Statistikdaten 235 Antwortzeiten 36 Anwendungsanalyse 355 Anwendungsdaten Abhängigkeiten 70 Anwendungsschnittstelle anwendungsnah 115 dokumentennah 115 anwendungsunabhängige Fehler 260 Abbruch während der Löschphase 263 Abbruch während der Schreibphase 260 Anzeige archivierter Daten im Archivinformationssystem 48 im Document Relationship Browser 49 in der Anwendungstransaktion 48 Anzeigevarianten 48 Archivadministration 81, 417 Archivauswahl Dateizugriffsprüfung 231 Archivdateien 417 ablegen 52, 86 auswerten 91 komprimieren 79 mit gespeicherten Metadaten 38 Verifikation 230 Archive Development Kit 41, 417 als Entwicklungsumgebung 207 als Laufzeitumgebung 204 API 207, 417 Auslösen von Ereignissen 256 Dateiverwaltung 206 gekapselte Funktionen 42 interne Datenobjektdienste 205 Komponenten 203, 204 Konvertierungen 205 Archive Explorer 172 Archive File Browser 246, 417 Benutzungsoberfläche 246 Archive Routing 247, 417 Ablageort 249 Definition 248

435

796.book Seite 436 Montag, 6. November 2006 7:40 19

Index

Routing-Regeln 248 Routing-Regeln am Beispiel von SD_VBAK 249 Verfügbarkeit 250 ArchiveLink 112, 417 3.1 und 4.5 im Vergleich 139 Ablagearten 144 Begriffsdefinition 116 Dokumentenbegriff 140 Schnittstelle zu externen Systemen 137 Verwaltung 119 zertifizierte Versionen 137 ArchiveLink-Schnittstelle aktuelle Version 111 ArchiveLink-System typische Konfiguration 119 Archivierbarkeitskriterien 42, 67, 68 applikationsspezifische 69 Archivierbarkeitsprüfung 34, 67 durchführen 74 Finanzbuchhaltungsbelege 276 im Schreibprogramm 74 im Vorlaufprogramm 74 Performance 76 archivierte Daten aus der Datenbank löschen 82 steuerrechtliche Anforderungen 62 Zugriff auf 91 zurückladen 94 Archivierung in der Personalabrechnung 289 Archivierungsgruppen anlegen 292 Durchführung 296 Rückrechnungen 291 Archivierung in SAP NetWeaver BI 322 ADK-basierte Archivierung 328 Archivdateiaufbau 326 Archivierung von Zeitscheiben 331 Archivierungsläufe zusammenfassen 334 Archivierungsprozess 330 Archivzugriff 337 Löschphase 333 Löschstrategien 334 Nearline-Ablage 328 Queries auf ausgelagerte Daten 337 Rückladen 336 Schreibphase 331 Schreibvariante anlegen 331

436

Zeitscheibenmethode 325 Archivierungscustomizing Beispiele 221 Definition logischer Dateiname 221 Parallelisierung der Schreib- und Löschjobs 85 Archivierungsdokumentation i-Drucktaste 26 Pfadnamen in der SAP-Bibliothek 27 SAP-Hinweise zu Informationsquellen 27 Archivierungsgruppen 292 anlegen 292 arbeiten mit 294 Archivierungsklasse 418 Definition 45, 209 Archivierungslauf 418 überwachen 222 unterbrechen 82 vollständig 46, 77 Archivierungsobjekte 43, 418 Archivierungsprogramme 43, 208 Beschreibung 43 Customizing-Einstellungen 44 Definition 208 erweitern 209 erweitern durch kundeneigene AppendStrukturen 210 erweitern durch kundeneigene Tabellen 210 im Vertrieb 386 in der Finanzbuchhaltung 270 in der Kostenrechnung 280 in mySAP CRM 316 in SAP NetWeaver BI 323 Residenzzeiten 399 archivierungsobjektspezifisches Customizing Prüfen und Löschen 309 Archivierungsprogramm 418 Archivierungsprojekte 58 ASAP-Einführungsphasen 342 Audit 384 Beispiel Vertrieb 384 Berechtigungskonzept erstellen 369 betriebswirtschaftliche Analyse 361 Business Blueprint 366 Datenarchivierungsleitfaden 344, 351 der richtige Zeitpunkt 60

796.book Seite 437 Montag, 6. November 2006 7:40 19

Index

Erstellen des Grobkonzepts 362 Festlegung der Archivierungsstrategie 364 Festlegung der Residenzzeiten 365 frühzeitiges Aufsetzen 340 Go-Live & Support 380 Integrationstest 377 langfristigen Archivierungsplan aufstellen 382 Merkmale erfolgreicher Teams 346 Produktionsvorbereitung 378 Projektleitung 347 Projektvorbereitung 345 Qualitätssicherung 383 Review 383 Sizing-Phase 60 spätes Aufsetzen 341 technische Analyse 350 Testphase 379 Vier-Augen-Prinzip 383 Zusammenstellung des Projektteams 345 Archivierungsprotokolle 236 Anwendungsprotokoll 237, 238 anzeigen 237 Detailprotokoll 238 Informationen abrufen 240 Job-Log 237 Jobübersicht 237 Spool-Liste 237 Standardprotokoll 239 zusammengefasstes Protokoll 238 Archivierungsprozess Ressourcenbedarf 60 Zweischrittverfahren 77 Archivierungsreihenfolge 71 Beispiel 401 festlegen 369 im Vertrieb 392 umstellen 232 Archivierungsrequests 331 Archivindex 418 ARIX_BKPF 169 aufbauen 93, 170 Archivinformationsstruktur 48, 418 Archivinformationssystem 170, 418 Anzeigevarianten 48 in der Finanzbuchhaltung 280 Vorteile 171

Archivserver 53 Archivverwaltung 223, 418 Details zum Archivierungslauf 224 Details zur Archivdatei 225 Selektionskriterien anzeigen 227 Übersicht der Archivierungsläufe 223 Übersicht zu den abgelegten Archivdateien 227 Zugriffsprüfung 225 Archivzugriff über das Archivinformationssystem 185 Beispiel 185 ARIX_BKPF 93, 169, 193, 194 AS siehe Archivinformationssystem AS_AFB 246 ASAP 59 ASAP siehe AcceleratedSAP 342 ASUG 23 asynchrone Ablage 145 Audit Information System 63 ausgehende Dokumente 121 Auswertung 47 Archivdateien 91 kombinierte 92 automatische Jobübernahme 259 automatisierter Produktivbetrieb 245, 250 Automatisierung nachgeordnete Tätigkeiten 82, 86

B Backup 104, 419 BAdIs ARC_MM_MATBEL_CHECK 408 ARC_MM_MATBEL_WRITE 408 FI_DOCUMNT_CHECK 276 Barcodeszenario 132 BC_ARCHIVE 215, 223, 224, 239, 261, 262 BC_SBOOK_X 218 BC_SFLIGHT 213 Bearbeitungsstatus eines Business-Objekts 68 Erledigt 68 Begriffsdefinition Ablagesystem 113 Anwendungsschnittstelle 113 ArchiveLink 116

437

796.book Seite 438 Montag, 6. November 2006 7:40 19

Index

Content-Server-Schnittstelle 113 Dokument 120 externer Content Server 113 Verwaltungsschicht 114 Belegartenlaufzeit 69 Beispiel 275 Einstellungsregeln 275 Belegfluss 70, 385 Belegkompaktjournal 92 Beleglaufzeiten in der Finanzbuchhaltung 273 mögliche Zugriffseinschränkungen 273 Steuerung 274 Belegverdichtung 271 Benutzermodell 106 Benutzerrolle Datenarchivierungsadministrator 219 SAP_BC_CCM_DATA_ARCHIVING 220 SAP_DRB 49, 190 bereitgestellte Archivdateien 226 löschen 226 Betriebskosten 106 betriebswirtschaftliche Sicht 419 BI Accelerator 319 Blockzugriff 157 BR*Tools 354, 355 Branchenlösungen Besonderheit bei Archivierungsobjekten 44 Business Content 419 Business Object Repository 303, 419 Business-Objekt 34, 419 Archivierbarkeitskriterien 68 Bearbeitungsstatus 68 Beziehung zum Archivierungsobjekt 303

C Case Management 124 CBO siehe Cost Based Optimizer CCMS-Alert-Monitor 227 CHANGEDOCU 246 CO_CCMAST 284, 285 CO_COSTCTR 194, 284, 285, 286 CO_ITEM 186, 194, 284, 285, 287, 288 Laufzeit 288 CO_ORDER 166, 177, 287, 288 CO_TOTAL 284, 285 CO-Analyseprogramme

438

RARCOA1 283 RARCOA2 283 Codepage 39, 91, 419 ASCII 39 EBCDIC 39 Unicode 39 COEP 288 Computing Center Management System 419 Concurrent-User-Modell 106 Content 140 Einheit 140 Content Management Service 420 Content-Server 53 Schnittstelle 115 CO-Objekt Objektnummer und Objektart 283 Struktur 282 Cost Based Optimizer 244 CRC-32-Prüfsumme 230 CRM Middleware 299, 420 CRM Server 299, 420 CRM_ACT_ON 304, 311, 312, 316 Leseprogramm 314 Löschprogramm 314 Parallelisierung 312 Schreibprogramm 313 Vorlaufprogramm 311 CRM_COMP 316 CRM_IBASE 316 CRM_LEAD 316 CRM_OPPT 316 CRM_SACONT 316 CRM_SALDOC 316 CRM_SERORD 316 CRMD_ORDERADM_H 312 CRM-Geschäftsvorgang Datenmodell 310 Vererbungshierarchie 305

D DART siehe Data Retention Tool Data Retention Tool 64, 163, 415 DataManager-Schnittstelle 324 DataStore-Objekte 317 Definition 317 Dateizugriffsprüfung bei Archivauswahl 231

796.book Seite 439 Montag, 6. November 2006 7:40 19

Index

Datenarchivierung Ablauf 45 als Teil des Datenmanagements 34 anwendungsunabhängige Fehler 260 Aufbau von Entwicklungs- und Testsystemen 41 Beispiel für einen Verkaufsbeleg 393 Datensicherheit 81 Einsatzgebiete 39 Hauptprozesse 77 in der Finanzbuchhaltung 270 in der Kostenrechnung 280 in der Personalabrechnung 290 in mySAP CRM 298 in mySAP ERP Financials 270 in mySAP ERP HCM 289 in SAP NetWeaver BI 322 Komprimierung 38 Leistungsumfang 38 Nutzenbetrachtung 34 parallel zum Produktivbetrieb 78 Performanceaspekte 55 Rückblick zur Entwicklung 37 Selektionskriterien 45 Statistikdaten 234 typische Fallstricke 264 Unicode 211 verfügbare Protokolle 236 Vorbereitung und Durchführung 393 was sie nicht leistet 40 Zweischrittverfahren 38, 77 Datenarchivierung in mySAP CRM 298, 301 Dreiphasenmodell 305 Rahmenprogramme 308 Datenarchivierungsadministrator Aufgaben 219 Benutzerrolle 219, 220 Datenarchivierungsjobs außerhalb SARA einplanen 257 automatische Jobübernahme durch externe Job-Scheduler 259 Benutzung von Servergruppen 253 einplanen 252 Jobklasse A 253 Jobtypen 252 Löschjobs einplanen 258 RSARCHD 258 Schreibjobs einplanen 257

unterbrechen und fortsetzen 254 Datenarchivierungsleitfaden 344 Datenarchivierungsmonitor 227 Beispielszenario 228 Funktionsumfang 228 Datenarchivierungsprozesse in SAP NetWeaver BI 322, 323, 324 Modellierung 325 Datenbank Fehler ORA-1555 266 Fragmentierung 242 nach Archivierung reorganisieren 241 Wachstum 36 datenbankbasiertes Archivieren 203 Datenbankmonitor 351 Datenbereinigung 362 Datenmanagement 60, 61 Belegverdichtung Finanzbuchhaltung 271 in der Finanzbuchhaltung 271 in der Kostenrechnung 284 Leitfaden 62 Verdichtungssimulation Finanzbuchhaltung 271 Datenobjekt 420 Datenquelle bei Anzeigetransaktionen 168 beim Lesen von Daten 167 in Report-Writer-Berichten 167 Datensicherheit 81 Verifikationsdaten 81 Datenträger CD 102 Festplatten 102 Lebensdauer 103 Magnetbänder 103 MO und WORM 102 Datentransferprozesse 321 Verwendung beim Archivzugriff 337 Datenverdichtung 61 Datenvernichtung 40, 61 Dauer Schreibphase 81 defekte Systeme 104 Detailkonzept betriebswirtschaftliche Sicht 368 technische Sicht 371 Umfang 367 Direktzugriff 47, 93, 420

439

796.book Seite 440 Montag, 6. November 2006 7:40 19

Index

Document Finder 125 Document Relationship Browser 49, 187 Anbindung archivierter Buchungsbelege 193 angebundene Objekttypen in mySAP ERP 190 Anzeige archivierter Logistikbelege 197 bekannte Fallstricke 197 Feld Herkunft 201 Feld Logisches System 201 Komponenten 189 Konfiguration 197 personalisierte Anzeige 199 Selektionsvariante anlegen 198 Suchoptionen 196 Ursprungsbeleg 192 Verwendung 187 Voraussetzungen für die Anzeige im DRB 193 Dokumentation Datenarchivierung 27 Dokumente ausgehende 121, 134 Begriffsdefinition 120 eingehende 121 Kategorien 120 Recherche 122 Dokumentenablage 420 Dokumentenintegration 107 Dokumentenmanagement 107 Dokumentenrecherche Beispiel 126 Dokumentenszenarien 128 Ablage für spätere Erfassung 130 ausgehende Dokumente 133 Barcode 132 Drucklisten 136 eingehende Dokumente 129 Workflow-basiert 129 Dokumentenverwaltung 107 DRB siehe Document Relationship Browser 49, 187 Dreiphasenmodell 305 Löschphase 307 Prüfphase 306 Replizierphase 307 Drucklisten 121, 136, 420 Archivierung 51 DSAG 23

440

E eingehende Dokumente 121 Einhaltung gesetzlicher Vorschriften 36 Einplanung Datenarchivierungsjobs 252 Einzelbeleganzeige 279 Einzelbelegzugriff 47, 93 Einzelobjekte anzeigen 93 Einzelpostenbericht für Aufträge 186 Einzelpostenjournal 92 elektronische Akten 124 Enterprise Storage 34 ereignisgesteuert Einplanung Löschprogramm 82, 255 Extensions 310 externer Content Server 115

F Feldkatalog 172, 420 anlegen 179 Schlüsselfelder 173 Feldkatalog anlegen Beispiel für Finanzbuchhaltungsbelege 179 mit einer Quelltabelle 180 mit mehreren Quelltabellen 182 typische Fallstricke 184 FI_ACCOUNT 270 FI_ACCPAYB 270 FI_ACCRECV 270 FI_BANKS 270 FI_DOCUMNT 78, 97, 180, 182, 193, 224, 270, 370 Laufzeit-Customizing 273 Strukturdefinition 208 technisches Customizing 272 FI_ELBANK 270 FI_MONTHLY 270 FI_PAYRQ 270 FI_SCHECK 270 FI_TCJ_DOC 270 Finanzbuchhaltung Archivierungsobjekte 270 Finanzbuchhaltungsbelege Archivierbarkeitsprüfungen 276 archivierte zurückladen 279 auf archivierte zugreifen 279

796.book Seite 441 Montag, 6. November 2006 7:40 19

Index

aus der Datenbank löschen 278 Auswertungen durchführen 279 ins Archiv schreiben 276 Korrekturprogramm für Sekundärindizes 279 Sekundärindex abbauen 278 Freiplatz ermitteln 79 Frühe Archivierung siehe Ablegen für spätere Erfassung

G GDPdU siehe Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen Gemeinkosten-Controlling Analyse der Tabellen 283 Geschäftsprozess Vertrieb 70 gesetzliche Aufbewahrungsfristen 61 Grobkonzept Umfang 362 Grundsätze zum Datenzugriff und zur Prüfbarkeit digitaler Unterlagen 37, 62

H Hierarchisches Speichermanagementsystem 53, 87, 420 Begriffsdefinition 151 Beispielszenario 154 regelbasierte Organisation der Daten 151 typische technische Probleme 157 Ziele 152 HSM siehe Hierarchisches Speichermanagementsystem HTTP-Content-Management-Service 53 HTTP-Content-Server-Schnittstelle 4.5 142

I I/O-Last 56 ILM siehe Information Lifecycle Management Indizes aufbauen 93 chronologisch sortiert 58

nicht chronologisch sortiert 58 Reorganisation 242 InfoCubes 317, 333 Definition 318 InfoProvider 319 Information Lifecycle Management 29 allgemeine Definition 30 vier Phasen 32 Infostrukturen 48 abbauen 178 aktivieren 175 anlegen 172 aufbauen 176 Aufbaustatus 176 auswerten 176 Datenbankindizes 178 explizit abbauen 178 nachträglich aufbauen 176 partitionieren 174 technische und betriebswirtschaftliche Sichten 177 initiale Datenarchivierung 393 Integration Ablagesystem 107 Integrations- und Zertifizierungsservice 141 Integrationstest 375, 377 intercepted Jobs 259

J J2EE Engine 216 Job-Scheduler extern 83 SAP 83 Jukebox 55, 87, 421

K Knowledge Provider 114, 421 Kollektion 217 kombinierte Auswertung 92 Komprimierung 38 Archivdateien 79 Faustregel 38 Kontoartenlaufzeit 69 Beispiel 274 Einstellungsregeln 274 Korrekturprogramm SAPF048S 279

441

796.book Seite 442 Montag, 6. November 2006 7:40 19

Index

Kosten Ablagesystem 105 kostenbasierter Optimierer 244 Kostenrechnung Archivierungsobjekte 280 KPro siehe Knowledge Provider Kriterien für die Archivierbarkeit 67

L Lebensdauer von Datenträgern 103 Lebenszyklus der SAP-Daten 30 Lesen, sequenzielles 91 Leseprogramm 421 Löschen ereignisgesteuert 255 nach dem Schreiben 84 parallel zum Schreiben 85 Löschjobs 421 direkte Einplanung 258 indirekte Einplanung 258 Löschkennzeichen 42, 69 setzen 74 Löschphase 421 nach Ablagephase 83 Probelesen 83 Prozessablauf 83 Löschprogramm 421 außerhalb Archivadministration 82 einplanen 82 Einstellungen 233 Leseverhalten 233 Löschvormerkung manuell entfernen 75 setzen 75 Löschvormerkung und -kennzeichen kombiniertes Verfahren 75 setzen 75

M magnetplattenbasierte Ablagesysteme 54 manuelle Ablage 89, 158 direkte Integration 158 indirekte Integration 158 Vor- und Nachteile 159 Mengenmodell 106

442

Metadaten 38, 91, 421 Migration automatisierte 110 in andere Ablagesysteme 112 MM_EBAN 71 MM_EKKO 71, 370 MM_MATBEL 251, 405 mySAP CRM Löschen ohne vorherige Archivierung 302 mySAP ERP Financials Datenarchivierung 270

N nachgeordnete Tätigkeiten automatisieren 82, 86 Nachlaufprogramm 421 ausführen 97 Named-User-Modell 106 Nametabs 205 Nearline Ablage 321 Nearline-Objekte 324 Nearline-Storage Schnittstelle 320 Netzgrafik 72 Nicht-SAP-Dokumente 122 Nutzung von Ressourcen 36

O Offset 421 optische Archivierung 422 ORA-1555 266

P PA_CALC 291, 292 PA_LDOC 297 PA_PDOC 298 PA_PIDX 298 PA_TIME 291, 292 PA_TRAVEL 291, 292 parallele Auftragsabarbeitung 108 Partitionierung Konfiguration 174 Tabellennamen selbst festlegen 174

796.book Seite 443 Montag, 6. November 2006 7:40 19

Index

Übernahme von Daten 174 Performance Ablagesystem 108 Archivierbarkeitsprüfung 76 chronologisch sortierte Indizes 58 Datenarchivierung 55 Einfluss des Alters der Daten 57 nicht chronologisch sortierte Indizes 58 periodisches Archivieren 251, 393 Voraussetzungen 251 Personalabrechnung Archivierung 290 Plattformunabhängigkeit 91 PM_ORDER 288 PP_ORDER 194, 288 PR_ORDER 288 Probelesen 83 Prüfen/Löschen 309 Prüfprogramm 76 Prüfung auf Archivierbarkeit 34, 67 Prüfungen vor der Schreibphase 257

Q Quickwins 364

R R/2 422 RAID-Systeme 102 RARCCOA5 285 Records Management 124 Recovery 105 Reihenfolge Ablage 89 bei der Archivierung 71 Releaseunabhängigkeit 91 Reorganisation 422 Datenbank nach der Archivierung 241 Indizes 242, 245 online 245 Tabellen 244 Tablespaces 244 Residenzzeit 42, 45, 68, 422 Beispiele 400 Berechnung 68 Wahl der richtigen 398 Restore 422 RFBELJ00 92

RFEPOJ00 92 RM07MARC 251 Robotersystem 55 Routing-Regeln 248 RSARCH_FLAG_SESSIONS 225 RSARCHD 258 alle Dateien verarbeiten 259 Arbeitsweise steuern 259 Rückladen 50, 78, 94, 422 Einschränkungen 94 ins Produktivsystem 51 ins Testsystem 51 mögliche Risiken 50 Prozessablauf 94 Rückladeprogramm 422 Rückrechnungen Archivierung in der Personalabrechnung 290 RV_LIKP 386, 388, 389

S SAP Content Server 143 SAP Job-Scheduler 83 SAP NetWeaver Application Server 422 SAP NetWeaver BI siehe SAP NetWeaver Business Intelligence SAP NetWeaver Business Intelligence technische Grundlagen 316 SAP Test Data Migration Server 41 SAP_DRB 49, 188, 190, 193 SAP-Bibliothek Dokumentation zur Datenarchivierung 26 SAP-RFC-Schnittstelle 139 School of Information Management and Systems, Studie zur Menge erzeugter Daten 21 Schreib- und Löschjobs Customizing 84 Schreibjobs 422 einplanen 257 im Testmodus starten 80 Schreibphase 422 Dauer 81 Prozessablauf 80 Schreibprogramm 422 einplanen 79 SD_COND 387

443

796.book Seite 444 Montag, 6. November 2006 7:40 19

Index

SD_VBAK 68, 194, 195, 249, 360, 386, 390, 396 SD_VBKA 387 SD_VBRK 386, 389 SD_VFKK 386 SD_VTTK 386, 387, 388 Sekundärindizes Finanzbuchhaltungsbelege 273 löschen 97 Selektionskriterien Datenarchivierung 45 Selektionsvariante anlegen Document Relationship Browser 198 semantische Gruppen 327 sequenzielle Leseprogramme 165 Beispiel 166 im Hintergrund einplanen 166 nachträglich erweiterte Archivlesefunktion 166 sequenzielles Lesen 91, 422 Servergruppen 253 Service Provider 126 Sets 310 Sicherheit Ablagesystem 101 Sizing-Phase 60 Smart Forms 133 Speicherkosten 35 Standardfeldkataloge 179 Standardprotokoll 239 Statistikdaten anzeigen 234 archivieren 239 Cost Based Optimizer 244 sammeln 234 Speicherplatzinformationen 234 Sternschema 318 steuerrechtliche Anforderungen archivierte Daten 62 Streckenauftrag Reihenfolge bei der Archivierung 71 synchrone Ablage 146 Systemarchitektur mySAP CRM 300 systemfremde Archive Zugriff 40 Systemverfügbarkeit 35

444

T TAAN_PROCESS_MULTIPLE 358 TAANA 297 TAANA_AV 356 TAANA_VF 357 Tabellen AIND_STR8 178 Analyse mit TAANA 355 ARIX_BKPF 169, 272 ASACCESS01 186, 193 AUFK 282 BKPF 180, 182, 183, 276 BSEG 180, 182, 276 BSIS 272 CDCLS 361 CDHDR 361 Cluster 38, 291 COEP 281, 285 COSP 283 CRMD_LINK 310 CRMD_ORDERADM_H 310 CRMD_ORDERADM_I 310 PCL1 291, 296 PCL2 291, 296, 297 Reorganisation 244 STXH 361 STXL 361 V_TVARA 390 V_TVARL 389 V_TVARR 389 V_TVARS 388 VBAK 282, 360 VBAP 282 Tabellenanalyse 355 technische Sicht 423 Tertiärspeicher 423 Testmodus Schreibjob starten 80 Statistikinformationen 80 TI_TF_GLC 270 Transaktionen ACLA 204 AOBJ 86, 204, 208, 255, 257, 258, 261, 266 ARCHGUIDE 344, 351 AS_AFB 246 DA_CONTROL 308, 309 DACONTROL 308

796.book Seite 445 Montag, 6. November 2006 7:40 19

Index

DB02 351 DB15 204, 223, 288, 354, 359 FB00 193, 194 FB03 168, 187, 188, 193, 279 FB99 276 FILE 376 KE5Y 168 KE5Z 168 KOB1 185 MB51 405 MBAD 405 MBAL 405 MBAR 405 MBAV 405 OBCY 272 OBR7 274 OBR8 274 PFCG 199, 200, 220 PU22 292, 294, 296 RSDAP 325 RZ20 215, 230 SAR_DA_STAT_ANALYSIS 235 SAR_SHOW_MONITOR 230 SARA 78, 204, 401, 407, 419 SARI 172 SARJ 172 SE16 162, 165, 423 SM36 82, 83, 309 SM61 254 ST03 354 ST14 355 SU01 200 TAANA 355 TAANA_AV 356 TAANA_VF 357 VA03 197

U Unicode 211 ISO/IEC10646 212 Transformation UTF-16 212 Unicode-basiertes Archivieren 213 Unterbrechen und Fortsetzen Archivierungsjobs 254 Ursprungsbeleg 192 User-Exit 278

V V_TVARA 390 V_TVARL 389 V_TVARR 389 V_TVARS 388 VBAK 360 Verdichtungssimulation 271 RARCCOA5 285 Verifikation Verifikationsdaten 81 von Archivdateien 230 vernetzte Anwendungsdaten 69 Vertrieb Archivierungsobjekte 386 Verwaltungsdaten 423 Verweildauer 69 vollständiger Archivierungslauf 77 Vorgänger und Nachfolger 70 Vorlaufprogramm 423 ausführen 96

W WebDAV 52, 214, 217 für XML-Archivierung 142 Wiedervorlagezeit 309 Workshop Projektende 383 Projektstart 345 WORM-Platten 102 Write-through 101, 102, 157

X XML-Archivierung 214 Archivhierarchie 218 Kollektion 217 PACK-Format 216 Positionierung 215 Separierung der Daten 216 verfügbare Dokumentation 218 Verfügbarkeit 218 Vergleich zur ADK-Archivierung 215 XML-DAS siehe XML-Datenarchivierungsservice 214 XML-DAS-Konnektoren 214 XML-DAS-Server 216 XML-Datenarchivierungsservice 214

445

796.book Seite 446 Montag, 6. November 2006 7:40 19

Index

XML-Dokumente 216 XML-Schema 216

Z Zahlenformat 39, 91 Zeitscheiben 325, 331 Zertifizierung Ablagesysteme 141, 142 WebDAV für XML-Archivierung 142 Zugriff auf Archivdateien 149 aus einem HSM-System 155 Probleme beim Zugriff über ArchiveLink 150

446

Zugriff auf archivierte Daten 91, 149 Arten 47, 161 Direktzugriff 167 Grundlagen 164 SAP NetWeaver BI 337 sequenzielles Lesen 165 Suchstrategien für Finanzbuchhaltung 279 über das Archivinformationssystem 185 Zugriff auf systemfremde Archive 40 Zugriffsprüfung 225 zurückladen archivierte Daten 94 Zweischrittverfahren 77