Jeder SAP ILM-Berater kennt diesen Moment: Der ILM-Lauf (Information Lifecycle Management) startet vielversprechend, bricht dann aber bei spezifischen Objekten mit einer kryptischen Fehlermeldung ab. Besonders frustrierend sind Fehler, die scheinbar zufällig bei validen Daten auftreten.
In diesem Beitrag analysieren wir einen spezifischen „Edge Case“, der in der Standardklasse CL_LRM_BS_RTP_RULE_EXECauftritt, und zeigen, wie Sie diesen mittels eines Impliziten Enhancements dauerhaft beheben.
Die Situation: Abbruch im ILM-Lauf
Das Szenario ist meist identisch: Während der Verarbeitung von ILM-Regeln bricht der Prozess für bestimmte Objekte ab. Im Anwendungsprotokoll finden Sie die Fehlermeldung:
„Datum für Zeitbezug des ILM-Objektes ungültig“ (Meldungsklasse: LRM_RULE_EXEC, Nummer: 303)
Auf den ersten Blick deutet dies auf korrupte Stammdaten hin. Doch bei genauerer Betrachtung sind die Daten technisch korrekt, enthalten aber einen spezifischen Zeitstempel, der die Standard-Validierung von SAP zum Stolpern bringt.
Die technische Analyse: Warum check_consistance fehlschlägt
Der Fehler entspringt tief im SAP-Standardcode. Konkret betrifft es die Klasse CL_LRM_BS_RTP_RULE_EXEC und dort die Methode CONVERT_RULE.
In Zeile 130 (je nach Release-Stand) wird eine Konsistenzprüfung des berechneten Startdatums durchgeführt:
ABAP
IF lo_calendar->check_consistance( lv_date_for_rtp_begin ) = abap_false.
RAISE EXCEPTION TYPE cx_lrm_rule_exec
...
ENDIF.
Das Problem: Die Variable lv_date_for_rtp_begin kann in bestimmten Konstellationen den technischen Maximalwert für Zeitstempel enthalten: '99991231235959' (31. Dezember 9999).
Obwohl dies in Datenbanktabellen ein valider Wert für „unendlich“ ist, schlägt die Methode check_consistance hier fehl und liefert abap_false.
Warum ist 9999... problematisch? Häufig liegt das Problem in den zugrunde liegenden Kalenderfunktionen des SAP-Basis-Systems. Wenn auf diesen extremen Grenzwert (High-Value) Zeitzonen-Umrechnungen oder Puffer-Additionen angewendet werden, kann das resultierende Datum den zulässigen Wertebereich des SAP-Kalenders überschreiten (Overflow). Das System bewertet den Zeitstempel daher als inkonsistent, was zum Fehler LRM_RULE_EXEC 303(„ILM Zeitbezug ungültig“) führt.
Der Fix: Implizites Enhancement in GET_STARTDATE
Da es sich um Standardcode handelt und wir den Fehler abfangen müssen, bevor die Exception geworfen wird, ist ein Implizites Enhancement die sauberste Lösung. Wir müssen den kritischen „9999er“-Zeitstempel auf einen sicheren Wert korrigieren, der weit genug in der Zukunft liegt, um die Logik nicht zu brechen, aber vom Kalender akzeptiert wird.
Lösung: Wir setzen den Zeitstempel um drei Stunden herunter.
Implementierung
Die Umsetzung sollte in Methode GET_STARTDATE erfolgen. Die Variable dort heißt dann abweichend ev_start_date. Navigieren Sie in der SE24 oder SE80 zur Methode GET_STARTDATE vor dem Aufruf der eigentlich problematischen Methode und erstellen Sie ein Enhancement direkt vor dem Aufruf von lo_calendar->check_consistance (ca. Zeile 130).
Code-Snippet:
ABAP
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
"$SEI-START$ Implicit Enhancement Z_ILM_TIMESTAMP_FIX
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
* Fix für LRM_RULE_EXEC 303:
* Der Timestamp '99991231235959' führt im check_consistance zu einem Fehler.
* Wir setzen ihn auf einen sicheren High-Value (99991231205959).
IF ev_start_date EQ '99991231235959'.
ev_start_date = '99991231205959'.
ENDIF.
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
"$SEI-END$ Implicit Enhancement Z_ILM_TIMESTAMP_FIX
""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""""
Durch diese kleine Manipulation passiert der Wert die Prüfung check_consistance erfolgreich (abap_true), und der ILM-Lauf kann ohne Abbruch fortgesetzt werden. Das Jahr wird nicht verändert, aber der Stundenwert. Damit ist der Timestamp ist immer noch weit genug entfernt, um in der ILM-Logik faktisch als „unendlich“ zu fungieren, verursacht aber keine Überlauffehler in den Basisfunktionen.
Fazit
Fehler wie LRM_RULE_EXEC 303 zeigen, wie wichtig pragmatische Lösungen in der SAP ILM Fehlerbehebung sind. Während der SAP-Standard technisch korrekt auf Inkonsistenzen prüft, sind es oft diese „Edge Cases“ bei maximalen Zeitstempeln, die den produktiven Betrieb stören.
Mit diesem minimal-invasiven Eingriff stabilisieren Sie Ihre ILM-Läufe, ohne die Kernlogik der Regelwerke zu gefährden.
Wir haben den Fehler über einen unserer Kunden dem SAP-Support gemeldet. Nach Korrektur durch einen SAP-Hinweis kann das Enhancement wieder gelöscht werden.
Benötigen Sie Unterstützung bei komplexen ILM-Szenarien oder der Archivierung? Unser Expertenteam hilft Ihnen gerne, Ihre Datenstrategie sauber und performant umzusetzen. Kontaktieren Sie uns für einen Deep-Dive.
