Verlorene Aktualisierungen

Geschäftsprozesse erstrecken sich oft über mehrere System-API-Aufrufe. In diesem Fall ist der erste Aufruf in der Regel entweder ein GET, das Daten abruft, oder ein POST, das Daten erstellt. Ein späterer API-Aufruf kann versuchen, die im ersten GET oder POST abgefragte oder erstellte Ressource zu ändern.

Ein anderer Prozess könnte die Ressource zwischen dem GET/POST und dem anschließenden Versuch ändern, diese zu ändern. Als Beispiel folgende Annahme:

1. Eine aufrufende Anwendung ruft mit einem GET die Aktivität xc:20 ab. Der Betreff der Aktivität lautet „Kontakt mit weiterem Versicherten“, und die Priorität lautet „Normal“.
2. Ein interner Benutzer ändert den Betreff der Aktivität xc:20 manuell in „Kontakt mit dem Versicherungsnehmer“ und setzt die Priorität auf „Dringend“.
3. Die aufrufende Anwendung ändert mit einem PATCH die Aktivität xc:20 und setzt die Priorität auf „Niedrig“.

Das PATCH der aufrufenden Anwendung überschreibt einige der vom internen Benutzer vorgenommenen Änderungen. Dies kann aus mehreren Gründen problematisch sein:

• Die Änderung der aufrufenden Anwendung kann auf den ursprünglich abgerufenen Daten basieren. Die aufrufende Anwendung hat die Änderung möglicherweise nicht initiiert, wenn ihr bekannt gewesen wäre, dass der Betreff oder die Priorität später von einer anderen Person geändert wurde.
• Dem internen Benutzer ist möglicherweise nicht bekannt, dass einige seiner Änderungen tatsächlich verworfen wurden.
• Die Aktivität kann sich nun in einem inkonsistenten Zustand befinden (z. B. wenn ein Betreff normalerweise für dringende Aktivitäten verwendet wird und die Priorität „Niedrig“ ist).

Diese Art der Änderung wird als verlorene Aktualisierung bezeichnet. In den System-APIs ist eine verlorene Aktualisierung eine Änderung an einer Ressource, die unbeabsichtigt Änderungen überschreibt, die von einem anderen Prozess vorgenommen wurden. Sie können verlorene Aktualisierungen durch die Verwendung von Prüfsummen verhindern.