Sperrobjekt

Definition

Ein Sperrobjekt in SAP ist ein zentrales Konzept zur logischen Sperrung von Daten, damit mehrere Benutzer oder Prozesse sich nicht gegenseitig überschreiben.

Das Ziel ist Datenkonsistenz und Vermeidung von Paralleländerungen.

Wichtige Punkte:

• SAP verwendet keine Datenbanksperren für Geschäftslogik, sondern logische Sperren
• Diese Sperren liegen in der Sperrtabelle (Enqueue-Tabelle) des SAP-Systems
• Sperrobjekte werden im ABAP Dictionary (Transaktion SE11) definiert
• Zur Laufzeit werden automatisch Funktionsbausteine generiert:
  • ENQUEUE_<Sperrobjekt>
  • DEQUEUE_<Sperrobjekt>

Arten von Sperren

Ein Sperrobjekt kann verschiedene Sperrmodi haben:

Modus Bedeutung E Exklusive Sperre (schreibend, niemand sonst darf ran) S Shared Sperre (mehrere Leser erlaubt) X Erweiterte exklusive Sperre O Optimistische Sperre In der Praxis wird meist E (exklusiv) verwendet.

Beispiel anhand Kundenauftrag

Zwei Benutzer öffnen denselben Kundenauftrag gleichzeitig:

• Benutzer A ändert Positionen
• Benutzer B ändert Preise

Ohne Sperre: Datenüberschreibung Mit Sperrobjekt: Nur ein Benutzer darf ändern

Sperrobjekt anlegen (SE11)

Annahme Tabelle ist: ZAUFTRAG Schlüssel: AUFTRAG_ID

Schritte in SE11:

• Name z. B.: EZ_AUFTRAG
• Tabelle hinzufügen: ZAUFTRAG
• Sperrparameter:
  • AUFTRAG_ID
  • Sperrmodus: E

SAP erzeugt automatisch:

• ENQUEUE_EZ_AUFTRAG
• DEQUEUE_EZ_AUFTRAG

ABAP Coding – Sperren

Sperren eines Auftrags

DATA: lv_auftrag_id TYPE zauftrag-auftrag_id.

lv_auftrag_id = '4711'.

CALL FUNCTION 'ENQUEUE_EZ_AUFTRAG'
  EXPORTING
    mode_zauftrag = 'E'
    auftrag_id    = lv_auftrag_id
  EXCEPTIONS
    foreign_lock  = 1
    system_failure = 2
    OTHERS        = 3.

Erklärung:

• foreign_lock: jemand anderes hat schon gesperrt
• system_failure: Enqueue-Server nicht erreichbar

Sperre gilt logisch, nicht auf DB-Ebene

ABAP Coding – Entsperren

CALL FUNCTION 'DEQUEUE_EZ_AUFTRAG'
  EXPORTING
    auftrag_id = lv_auftrag_id.

Am besten nach COMMIT WORK und ROLLBACK WORK oder im CLEANUP etc. entsperren.

Typische Best Practices

• Sperren so früh wie nötig
• Entsperren so schnell wie möglich
• Sperren vor SELECT … FOR UPDATE vermeiden
• Sperrobjekte pro Geschäftsobjekt, nicht pro Tabelle
• Sperrprüfung vor Änderungen

Kontrolle & Analyse

• SM12: Aktive Sperren anzeigen
• SM21: Enqueue-Fehler
• ST22: Dumps bei Sperrproblemen

Angelegtes Beispiel im System