Umsetzung der Datenarchivierung im SAP-ERP-System

Diplomarbeit von Daniel Intrup

Diese Diplomarbeit richtet sich an ein breites Publikum vom Manager bis zum Mitarbeiter, der die Archivierung technisch umsetzt. Für Projektverantwortliche und Manager, die über die Umsetzung eines solchen Projektes entscheiden müssen, liegt das Hauptaugenmerk auf den Vor- und Nachteilen des Projektes. Für Projektleiter und Mitarbeiter, die das Archivierungsprojekt umsetzen, soll die Herangehensweise und eventuell auftretende Probleme im Projekt beschrieben werden. Neben der allgemeinen technischen Erklärung der Umsetzung befindet sich im Anhang eine detaillierte technische Dokumentation, die die Umsetzung des Projektes bei arvato dokumentiert. Dieser Aspekt der Dokumentation des bei arvato Geleisteten nimmt einen hohen Stellenwert in der Diplomarbeit ein.

Inhaltsverzeichnis:

Textprobe:

Kapitel 7.2, Daten aus der Datenbank löschen:

Nachdem die zu archivierenden Daten vollständig in Archivdateien geschrieben wurden, werden sie vom Löschprogramm aus der Datenbank entfernt. Aus Sicherheitsgründen wird der Löschlauf jedoch erst gestartet, wenn die zuvor angelegten Archivdateien erfolgreich gelesen werden konnten. Zu Beginn der Löschphase öffnet das Löschprogramm eine Archivdatei, um die dort gespeicherten Daten aus der Datenbank zu löschen. Das Löschen der Daten erfolgt immer objektweise. Doch bevor ein Business-Objekt gelöscht werden kann, stellt ein entsprechender ADK-Funktionsbaustein sicher, dass der Inhalt des Business-Objekts im Archiv lesbar ist. Diese als ‘Probelesen’ bezeichnete Vorgehensweise garantiert, dass nur solche Business-Objekte in der Datenbank gelöscht werden, die fehlerfrei in die Archivdatei übertragen wurden. Für jede erzeugte Archivdatei wird ein Löschjob gestartet, weshalb darauf geachtet werden sollte, dass nicht zu viele Löschjobs gleichzeitig laufen.

Alternativ zu der in diesem Projekt angewandten Methode des Löschens nach dem Schreiben, bei der der Löschjob nach Beendigung der Schreibphase separat eingeplant werden muss, gibt es noch die Variante des Löschen parallel zum Schreiben. Hierbei wird der Löschjob gestartet, sobald die erste Archivdatei geschlossen wurde und während schon die nächste geschrieben wird. Das ADK-Laufzeitsystem übernimmt dabei automatisch die Einplanung der entsprechenden Löschjobs. Dieser Vorgang erhöht die Performance, weil die Jobs parallel abgearbeitet werden können. Er bietet aber weniger Sicherheit, da die manuelle Kontrolle wegfällt.

Archivdateien ablegen:

Die in der Schreibphase erzeugten Archivdateien können an Ablagesysteme übergeben oder auf Tertiärspeichermedien ausgelagert werden. Die Ablagephase ist nicht Teil des eigentlichen Archivierungsprozesses, sondern kann optional erfolgen. Dabei kann im Customizing eingestellt werden, ob die Ablage vor oder nach der Löschphase erfolgt. Bei der Wahl des Ablagezeitpunkts sind hauptsächlich Sicherheitsaspekte interessant. So bewirkt die Wahl der Option ‘Ablage vor Löschphase’, dass die Daten in der Datenbank erst nach erfolgter Ablage einer Archivdatei im Ablagesystem gelöscht werden. Dies schließt das Risiko eines Datenverlustes beim Ablegen aus. Weitere Informationen zur Ablage von Archivdateien finden Sie im Kapitel 5.3 (Ablage der Archivdateien).

Rückladen:

Archiv Files können nur in einem SAP-System mit ADK-Umgebung wieder eingespielt werden. Da archivierte Daten auch nach längerer Zeit und über Releasewechsel hinweg noch auswertbar sind, ist ein Rückladen in die Datenbank selten nötig. Des Weiteren ist ein solches Rückladen immer mit Risiken verbunden, wie im Folgenden beschrieben wird. Es gibt zwei mögliche Szenarien, in denen Daten in die Datenbank zurückgeladen werden:

- Rückladen im Anschluss an die Archivierung.

- Rückladen nach längerem zeitlichen Abstand.

Rückladen im Anschluss an die Archivierung:

Dieser Fall entsteht, wenn direkt nach der Archivierung festgestellt wird, dass für den Archivlauf falsche Einstellungen gemacht wurden. Ein Beispiel dafür ist, dass das Customizing fehlerhaft war oder eine zu kurze Residenzzeit gewählt wurde und somit Daten archiviert wurden, die eigentlich noch online benötigt werden. Bei dieser Variante handelt es sich um einen Notfall und genau dafür wurde die Rückladefunktion entwickelt. Ein Rückladen ist meistens problemlos möglich. Es sollte allerdings so schnell wie möglich geschehen. Es gibt Archivierungsobjekte bei denen Probleme auftauchen können. So können z.B. bei den Verkaufsbelegen die zughörigen Controlling Daten nicht mit zurückgeladen werden. Vor dem Rückladen sollten immer die zugehörige Dokumentationen und die SAP-Hinweise im Service Marketplace studiert werden.

Rückladen nach längerem zeitlichen Abstand:

Falls Daten nach einer langen Zeit zurück in die Datenbank geladen werden sollen, ist dies theoretisch genauso möglich wie in der Variante direkt nach dem Archivieren. Es birgt allerdings einige Gefahren. So kann es vorkommen, dass die archivierten Daten und die Daten aus der Datenbank nicht mehr zusammenpassen. Wenn z.B. in der Datenbank ein Nummernkreisintervall zurückgesetzt wird und anschließend die Archivdaten zurückgeladen werden, werden die Daten in der Datenbank überschrieben. Es kann auch vorkommen, dass zurückgeladene Daten Organisationsdaten wie etwa Verkaufsorganisation oder Sparte enthalten, die im aktuellen System nicht mehr enthalten sind. Dies würde zu inkonsistenten Daten führen.

Praktische Informationen zu den Archivierungsjobs:

Nachdem die allgemeinen Einstellungen abgeschlossen sind, liegt die zeitlich größte Aufgabe im Starten und Überwachen der Archivierungsjobs. Dies können je nach Projektgröße weit über 1.000 Jobs sein, die gestartet, eingeplant und überwacht werden wollen. Deshalb folgen hier ein paar Tipps zu den Archivjobs:

Es sollten niemals ähnliche Archivierungsobjekte, also Objekte, die auf die gleichen Tabellen zugreifen, parallel laufen. Diese könnten sich gegenseitig behindern und zum Absturz der Jobs führen. Wie schon in Kapitel 6.2.2 beschrieben, muss die Reihenfolge der Archivierungsobjekte unbedingt eingehalten werden, um die Archivierung aller gewünschten Dokumente zu gewährleisten.

Allgemein sollte der Zeitpunkt des Durchlaufes auf Performance hin überprüft werden. Wenn auf dem Server zu viele Archivjobs parallel ablaufen, behindert dies die Arbeit in anderen Bereichen. In dem Projekt bei arvato wurden sechs parallel laufenden Jobs als problemlos angesehen. Dies ist abhängig vom Applikationsserver und dessen Einstellungen.

Bei arvato wurden Laufzeiten der Archivierungsjobs von 30 Minuten bis zu 48 Stunden festgestellt. Deshalb kann hier keine genaue Aussage darüber getroffen werden, wie lange ein Archivierungsjob läuft. Jeder Archivierungsjob kann andere Laufzeiten besitzen. Daher sollten die Laufzeiten für jedes Archivierungsobjekt durch Tests analysiert werden. Durch die Festlegung der Startzeiten ist ein 24/7 Betrieb möglich, wobei auch hier immer wieder Zeitfenster für unerwartet lange Laufzeiten freigehalten werden sollten.

Die hier vorgestellte Vorgehensweise erhebt keinen Anspruch auf Vollständigkeit. Es soll einen ungefähren Ausblick auf die durchzuführenden Arbeiten geben. Eine detaillierte und vollstände Anleitung finde Sie im Anhang unter ‘Technical Documentation Archiving by arvato digital services’.