ETag steht für Entity Tag und ist ein HTTP-Header, der eine aktuelle Versionskennung einer Ressource transportiert. In REST- und OData-APIs wird er vor allem für optimistische Nebenläufigkeitskontrolle genutzt: Der Client darf eine Ressource nur dann verändern, wenn der ETag noch mit dem serverseitigen Stand übereinstimmt. So werden Überschreibungen paralleler Änderungen verhindert, ohne dass der Server serverseitige Sperren halten muss.
Kontext
Ablauf in der Praxis: Der Client ruft eine Ressource per GET ab und erhält im Response-Header einen ETag: "123abc". Will er sie ändern, sendet er bei PATCH oder PUT den Header If-Match: "123abc" mit. Stimmt der aktuelle Server-ETag noch überein, wird die Änderung ausgeführt und ein neuer ETag zurückgegeben. Hat inzwischen jemand anders geschrieben, antwortet der Server mit HTTP 412 Precondition Failed; der Client muss den aktuellen Stand nachladen, den Konflikt auflösen und erneut versuchen. Im SAP-B1-Service-Layer ist dieses Muster relevant, wenn mehrere Integrationen gleichzeitig auf denselben Geschäftspartner, Artikel oder offenen Beleg schreiben — etwa Webshop-Sync, ERP-Front-End und ein Migrationstool. ETags entstehen in OData automatisch für Entitäten mit konfigurierten Concurrency-Properties; clientseitig empfiehlt sich ein Wrapper, der If-Match konsistent setzt und 412-Antworten in einen Reload-und-Retry-Flow überführt.
Abgrenzung
ETag-basierte Concurrency ist optimistisch: Es gibt keine Sperre, Konflikte werden erst beim Schreibversuch erkannt. Das unterscheidet sie von pessimistischem Locking (z.B. SELECT FOR UPDATE), das in der Datenbank oder durch einen Sperrservice durchgesetzt wird. ETags sind auch kein Cache-Control-Mechanismus im engeren Sinne, obwohl sie mit If-None-Match zusätzlich HTTP-Caching unterstützen. Und sie ersetzen nicht die fachliche Konsistenzprüfung: Dass zwei Schreibvorgänge technisch sauber aufeinander folgen, heißt noch nicht, dass das inhaltliche Ergebnis korrekt ist — dafür bleiben Validierungen und Transaktionsgrenzen im Server Pflicht.
LATS: Mehrere Wege gleichzeitig durchdenkt mit KI — und die Verfügbarkeitsprüfung in SAP B1
ReAct und RLEF: Wie Künstliche Intelligenz aus echten Fehlern lernt — und was der automatische Bankabgleich in SAP Business One damit zu tun hat
SAP B1 10.0 FP2608: Service Layer KI als transaktionalen Schicht
Process Reward Models: Warum ein richtiges Ergebnis noch keinen richtigen Weg beweist
Test-Time Compute Scaling: Warum ein kleineres KI-Modell am Ende gewinnen kann — und was der Lieferantenvergleich in SAP Business One damit zu tun hat
