Habt ihr schon einmal Probleme mit Enqueue-Locks oder Drafts gehabt, die nicht automatisch entfernt wurden?
Wir hatten kürzlich genau so einen Fall in einem unserer Systeme und konnten die Ursache schließlich identifizieren und das Problem beheben.
Hintergrund
Draft-Daten werden in den Draft-Tabellen der jeweiligen Entitäten gespeichert. Die Namen dieser Tabellen werden in der BDEF des Draft-fähigen Business Objects definiert.
Zusätzlich werden administrative Informationen in I_DraftAdministrativeData gespeichert.
Drafts verwenden keine „normalen“ Sperren. Stattdessen setzen sie auf Enqueue-Locks. Diese wurden speziell dafür eingeführt, Sperren für Drafts aufrechtzuerhalten, auch wenn die ursprüngliche ABAP-Session zwischen zwei Roundtrips nicht mehr existiert (zustandsbehaftetes Anwendungsverhalten auf einem zustandslosen Protokoll).
RAP Draft Lifecycle
RAP verwendet zwei Hintergrundmechanismen zur Verwaltung des Draft-Lifecycles:
Lock Expiration (15 Minuten)
Im SAP GUI führte ein Session-Timeout dazu, dass die ABAP-Session beendet wurde. Dadurch gingen sowohl alle noch nicht gespeicherten Änderungen als auch die dazugehörigen Sperren verloren.
Bei Fiori-Anwendungen wurde dieses Verhalten durch das Draft-Konzept verbessert. Nach 15 Minuten laufen die Draft-Sperren ab und werden entfernt, während die Draft-Daten weiterhin erhalten bleiben. Der Benutzer kann seine Änderungen später wieder aufnehmen, falls dies erforderlich ist.
Andere Benutzer können das gleiche Objekt in dieser Situation weiterbearbeiten und die Draft-Änderungen überschreiben (natürlich mit einer entsprechenden Warnung).
Draft Cleanup (28 Tage)
Draft-Instanzen werden 28 Tage nach der letzten Änderung gelöscht.
Sobald ein Draft durch den Cleanup-Prozess gelöscht wurde, können die darin enthaltenen Änderungen nicht mehr fortgesetzt werden.
Technische Details
Für die Lock Expiration gibt es einen AutoABAP-Job, der alle fünf Minuten ausgeführt wird. Den Job findet man in der Transaktion ST03N.
Er ruft die Methode CL_DRAFT_LIFECYCLE_MANAGER=>RUN auf, die letztlich den Programmzweig für EXPIRY_LOCKS ausführt.
Zusätzlich gibt es einen technischen Hintergrundjob, der den Report RSDRAFT_LIFECYCLE_MANAGER ausführt (siehe SJOBREPO).
Dieser Report ruft ebenfalls denselben Lifecycle Manager auf, durchläuft jedoch den ersten Teil der Logik in der IF-Abfrage, der für das Draft Cleanup verantwortlich ist.
Die Ursache in unserem Fall
In unserem System lief der AutoABAP-Job wie erwartet alle fünf Minuten. Allerdings existierte seit mehr als drei Wochen ein globaler Lock: SDSP_DLH_LOCK_EXPIRY. Der Lock war im Mandanten 000 gesetzt und wurde nie wieder freigegeben. Dadurch war der Lock-Expiration-Job effektiv blockiert und konnte über den gesamten Zeitraum keinerlei Wirkung entfalten.
Zusätzlich lief der Draft-Cleanup-Report jeden Morgen um 04:00 Uhr in einen Short Dump, also genau zu dem Zeitpunkt, zu dem der technische Cleanup-Job eingeplant war. Die Ursache war letztlich ein Problem im Zusammenhang mit einem Purchase-Order-Attachment. Eine Fehlermeldung führte dazu, dass ein RAISE SHORTDUMP ausgelöst wurde. Nachdem wir den betroffenen Datensatz im Debugger umgangen hatten, lief das Cleanup erfolgreich durch und der betreffende Draft wurde gelöscht.
Fazit
Falls ihr feststellt, dass Draft-Sperren nicht ablaufen oder Drafts auch nach Ablauf der Aufbewahrungsfrist nicht gelöscht werden, lohnt sich ein Blick auf folgende Punkte:
- Globale Locks wie SDSP_DLH_LOCK_EXPIRY
- Dumps in ST22 während der Ausführungszeit des technischen Jobs für RSDRAFT_LIFECYCLE_MANAGER
- Debugging von CL_DRAFT_LIFECYCLE_MANAGER=>RUN
Vielleicht hilft das ja jemandem, der vor einem ähnlichen Problem steht.
