IDocs in SAP HCM löschen: ILM-Objekt IDOC oder Transaktion WE11?

In fast jedem SAP-HCM-System liegen IDocs, die niemand mehr braucht: Stammdatenverteilungen per HRMD_A aus der Zeit vor der letzten Migration, Buchungsschnittstellen zur Finanzbuchhaltung, Testläufe, hängengebliebene Fehlerstatus. Wer diese IDocs DSGVO-konform löschen will, steht vor einer Richtungsentscheidung: der Weg über das ILM-Objekt IDOC mit den Programmen RSEXARCA und RSEXARCD, oder der direkte Weg über die Transaktion WE11 mit dem Report RSETESTD. Beide Wege löschen IDocs aus der Datenbank, aber nach unterschiedlichen Regeln. Dieser Beitrag erklärt, was die drei Programme tatsächlich tun, warum das ILM-Objekt beim Löschen denselben Restriktionen unterliegt wie beim Archivieren und welches Risiko Sie sich mit WE11 dafür einhandeln.

Zwei Wege, zwei Grundprinzipien

Das ILM-Objekt IDOC arbeitet zweistufig über das Archive Development Kit. Das Schreibprogramm RSEXARCA selektiert IDocs auf der Tabelle EDIDC, schreibt sie in eine Archivdatei und protokolliert jeden einzelnen Beleg. Erst das Löschprogramm RSEXARCD entfernt anschließend genau die IDocs aus der Datenbank, die nachweislich in der Datei stehen. Dazwischen liegt eine Verifikation: Es wird nichts gelöscht, wovon nicht vorher eine Kopie existiert. Das Ergebnis ist eine echte Löschung aus der Datenbank, nicht nur eine Archivierung. Entscheidend ist aber: Der Löschlauf kann nur entfernen, was der Schreiblauf zuvor selektiert hat. Jede Einschränkung, die für das Archivieren gilt, gilt damit automatisch auch für das Löschen über ILM.

WE11 kennt diese Zwischenstufe nicht. RSETESTD selektiert ebenfalls auf EDIDC, löscht die Treffer aber unmittelbar über den Funktionsbaustein EDI_DOCUMENT_DELETE_MASS, paketweise mit Datenbank-Commit. Es gibt keine Archivdatei, keine Rückholmöglichkeit und keinen belegbezogenen Nachweis. Dafür gibt es vier Zusatzoptionen, die über die reinen IDoc-Tabellen hinausgehen: Workflow-Workitems, tRFC-Einträge, Anwendungsprotokolle und Objektverknüpfungen können im selben Lauf mit entfernt werden.

Dieselben Restriktionen wie beim Archivieren

Die wichtigste Restriktion steckt in einem unscheinbaren Filter. RSEXARCA liest aus der Tabelle STACUST alle Status, die als archivierbar gekennzeichnet sind, und lässt nur IDocs mit genau diesen Status durch. Fachlich ist das eine Schutzlogik des IDoc-Frameworks: Es soll nichts wegarchiviert werden, was noch verarbeitet werden könnte. Weil der Löschlauf an die Selektion des Schreiblaufs gebunden ist, wird aus der Archivierungsregel eine Löschregel. Ein IDoc im Fehlerstatus 51 oder ein Eingangs-IDoc im Status 64, das nie verarbeitet wurde, bleibt deshalb auch beim Löschen über ILM stehen.

Warum das im DSGVO-Kontext stört: Der Löschanspruch nach Art. 17 und der Grundsatz der Speicherbegrenzung nach Art. 5 Abs. 1 lit. e DSGVO fragen nicht nach dem Verarbeitungsstatus eines IDocs. Ein zehn Jahre altes HRMD_A-IDoc enthält Personalstammdaten, egal ob es im Status 53 erfolgreich gebucht oder im Status 51 liegen geblieben ist. Aus Datenschutzsicht ist der Status schlicht irrelevant, sobald Zweck und Aufbewahrungsfrist entfallen sind. Das ILM-Objekt sortiert aber genau nach diesem Kriterium und lässt einen Teil der zu löschenden Daten stehen, obwohl es sie fachlich löschen könnte.

Die zweite Restriktion betrifft den Verbleib der Daten. Der Löschlauf entfernt die IDocs aus der Datenbank, die Archivdatei bleibt bestehen und ist über das Archivinformationssystem lesbar. Die personenbezogenen Daten sind damit aus dem operativen System verschwunden, aber noch nicht beseitigt. Erst die Vernichtung der Archivdatei nach Ablauf der ILM-Regel schließt den Vorgang ab, und die muss als eigener Schritt geplant und ausgeführt werden.

Die dritte Restriktion betrifft das Umfeld des IDocs. RSEXARCD löscht nur, was RSEXARCA in die Datei geschrieben hat. Workitems aus der IDoc-Eingangsverarbeitung und Anwendungsprotokolle, die Teile des IDoc-Inhalts spiegeln können, bleiben unberührt und müssen über die eigenen Archivierungsobjekte für Workitems und Anwendungsprotokolle behandelt werden. Objektverknüpfungen werden nur mitarchiviert, wenn die Option für Verknüpfungen gesetzt ist.

Was häufig falsch eingeschätzt wird: Legal Hold

Ein verbreitetes Argument für den ILM-Weg lautet, dass dort Vernichtungssperren greifen. Bei IDocs trifft das nicht zu. Das ILM-Objekt IDOC führt keine Personalnummer und keinen anderen Personenbezug als Konditionsfeld. Eine Sperre, die in SAP HCM über die Personalnummer gesetzt wird, erreicht ein IDoc technisch nicht. Wie Legal Hold in SAP ILM generell funktioniert und wo er greift, haben wir an anderer Stelle beschrieben; für die Abgrenzung zwischen ILM-Objekt und WE11 spielt er keine Rolle, weil beide Wege ihn gleichermaßen nicht kennen.

Damit schrumpft der Vorsprung des ILM-Objekts beim reinen Löschen auf einen Punkt: die mitgelieferte Nachweisstruktur mit Protokoll pro Beleg und Archivverwaltung. Und genau dieser Punkt führt zum Risiko von WE11.

Das Risiko von WE11: Sie sind die Löschregel

Beim ILM-Objekt liegt die Löschregel im System. Wer im Destroy-Modus zu weit selektiert, löst keine verfrühte Löschung aus, weil das ADK jedes Objekt gegen die hinterlegte Regel prüft; eine Falscheingabe im Selektionsbild wird verziehen. Bei WE11 gibt es diese zweite Instanz nicht. Die Jobvariante ist die Regel. Wer dort das Erstelldatum falsch setzt, löscht falsch, und zwar endgültig.

Der Code von RSETESTD macht das Risiko greifbar. Der Testmodus ist zwar vorbelegt, aber nur vorbelegt. Im Dialog erzwingt das Programm vor einem Produktivlauf ein Bestätigungspopup; im Batch entfällt es. Ein eingeplanter Job mit abgewähltem Testlauf löscht ohne Rückfrage. Der Filter auf archivierbare Status existiert auch in WE11, ist dort aber eine optionale Checkbox. Das ist für den DSGVO-Fall genau richtig, weil Sie alte IDocs unabhängig vom Status loswerden wollen, es bedeutet aber zugleich, dass nichts im Programm Sie vor einer zu jungen Datumsgrenze schützt.

Wichtig für die Praxis: Das Risiko von WE11 ist kein Konformitätsproblem, sondern ein Prozessproblem. Die DSGVO schreibt kein Werkzeug vor. Sie verlangt, dass eine Löschregel existiert, dokumentiert ist und nachweislich regelmäßig ausgeführt wird. Das kann WE11 leisten, wenn der Prozess darum herum stimmt. Wie ein solches Löschkonzept für SAP HCM aufgebaut ist, haben wir bereits beschrieben; IDocs gehören als eigene Löschklasse hinein, ähnlich wie andere betriebsinterne Daten ohne Personalnummernbezug.

Was Sie jetzt prüfen sollten

Erstens: Was ist Ihr Ziel? Wenn IDocs tatsächlich über die Datenbank hinaus aufbewahrt werden müssen oder unterschiedliche Nachrichtentypen unterschiedliche Fristen haben, ist das ILM-Objekt IDOC der richtige Weg, ergänzt um die spätere Vernichtung der Archivdateien. Wenn das Ziel schlicht lautet, alte IDocs unabhängig vom Status loszuwerden, ist WE11 das sachgerechtere Werkzeug, weil ILM genau diese Statusunabhängigkeit nicht bietet.

Zweitens: Steht die Löschregel schriftlich? Formulieren Sie sie im Löschkonzept als Regel, nicht als Datum, etwa als Erstelldatum älter als zehn Jahre zum Stichtag des Laufs. Die Jobvariante wird vor jedem Lauf aus dieser Regel abgeleitet und im Vier-Augen-Prinzip geprüft. Für Buchungs-IDocs klären Sie vorab, ob eine laufende Außenprüfung die Frist hemmt; das ist eine organisatorische Prüfung, keine Systemfunktion, und sie gilt für beide Wege.

Drittens: Ist der Testlauf Pflichtschritt? WE11 liefert im Testmodus eine Summenliste pro Nachrichtentyp und Status. Legen Sie diese Liste zu jedem Produktivlauf ab. Zusammen mit dem Joblog und dem Syslog-Eintrag, den RSETESTD mit der Anzahl gelöschter IDocs schreibt, ist das Ihr Nachweis nach Art. 5 Abs. 2 DSGVO.

Viertens: Sind alle vier Zusatzoptionen gesetzt? Workitems, tRFC-Einträge, Anwendungsprotokolle und Verknüpfungen gehören bei einem DSGVO-Lauf mit in die Variante, sonst bleiben Spuren des IDoc-Inhalts im System. Und schützen Sie die Variante gegen Änderung; die Berechtigung für WE11 im Löschmodus gehört ausschließlich zum Jobbenutzer.

Fünftens: Wo endet der Lauf? Beide Wege lassen GOS-Anhänge, Änderungszeiger und ALE-Audit-Daten unberührt. Prüfen Sie, ob solche Objekte in Ihrem System an IDocs hängen, bevor Sie Vollständigkeit behaupten.

Fazit

Das ILM-Objekt IDOC kann archivieren und löschen, und für die Archivierung ist es das Werkzeug der Wahl. Beim Löschen aus DSGVO-Sicht bringt es dieselben Restriktionen mit wie beim Archivieren: Es sortiert nach Verarbeitungsstatus, obwohl der Status für den Löschanspruch unerheblich ist, es lässt Folgeobjekte stehen und es hinterlässt eine Archivdatei, die separat vernichtet werden muss. WE11 löscht dagegen rigoros und vollständig, verlangt aber, dass Sie die Löschregel selbst in eine Selektion übersetzen und dafür geradestehen.

Der Befund gilt für die drei analysierten Programme RSETESTD, RSEXARCA und RSEXARCD in der uns vorliegenden Fassung. Ob er sich auf andere ILM-Objekte übertragen lässt, deren Statuslogik anders aufgebaut ist, haben wir nicht geprüft.

Aus über hundert DSGVO-Projekten im SAP-HCM-Umfeld nehmen wir bei hoelterhoff.consulting vor allem eines mit: Nicht das Werkzeug entscheidet über die Konformität, sondern die Frage, wer die Löschregel hütet, das System oder der Prozess. Bei WE11 ist es der Prozess, und der muss dann auch dokumentiert sein.

Wie IDocs und andere Daten ohne Personalnummernbezug in ein belastbares Löschkonzept gehören, zeigen wir auf unserer Seite zum SAP HCM Löschkonzept. Wenn Sie Ihre IDoc-Bestände konkret bewerten lassen möchten, sprechen Sie uns an.