Ein Benutzer löscht einen Datensatz in einer Anwendung und findet ihn Stunden später wieder, weil eine andere Anwendung ihn synchronisiert hat. Meist handelt es sich nicht um ein isoliertes Problem mit dem „Löschen“, sondern um eine Abweichung zwischen Systemen darüber, welche Aktion stattgefunden hat, was sie bedeutet und wer sie berücksichtigen muss. Um das Problem zu lösen, müssen Geschäfts- und Integrationsregeln vereinbart werden, bevor die Anwendungen verbunden werden.
In der Praxis geht es nicht nur darum, wie Löschungen zwischen Systemen synchronisiert werden. Ebenso wichtig ist, ob ein Datensatz verschwinden, ausgeblendet, für Prüfzwecke aufbewahrt oder für laufende Prozesse weiterhin verfügbar sein soll. Dieser Artikel unterscheidet diese Entscheidungen und beschreibt Kriterien, um sie zu übertragen, unbeabsichtigte Wiederherstellungen zu verhindern und Ausnahmen zu behandeln.
Warum eine lokale Löschung nicht immer die verbundenen Systeme erreicht
Eine Integration kann neue und geänderte Datensätze übertragen, ohne Löschungen weiterzugeben. Fragt sie beispielsweise regelmäßig verfügbare Datensätze ab und überträgt nur die gefundenen Einträge, löst ein Datensatz, der in der Quelle nicht mehr erscheint, nicht unbedingt eine Nachricht an das Zielsystem aus. Für das empfangende System kann die Abwesenheit bedeuten, dass es den Datensatz nie erhalten hat, die Abfrage fehlgeschlagen ist oder der Datensatz gelöscht wurde. Ohne eine ausdrückliche Regel kann es nicht feststellen, welcher Fall vorliegt.
Das Problem tritt auch auf, wenn eine Anwendung den Datensatz aufbewahrt und eine andere ihn physisch löscht. Veröffentlicht die Synchronisierung den gespeicherten Datensatz später erneut, kann das Zielsystem ihn wieder anlegen. Auch eine Logik nach dem Prinzip „letzte Aktualisierung gewinnt“ reicht nicht immer aus: Für die Löschung gibt es möglicherweise weder einen Zeitstempel noch eine Version, anhand derer sie mit den eingegangenen Änderungen verglichen werden kann.
Ermitteln Sie vor dem Entwurf der Lösung, welche Anwendungen den Datensatz anlegen, bearbeiten oder außer Kraft setzen können, welches System für die einzelnen Daten maßgeblich ist und was es bedeutet, wenn der Datensatz nicht mehr verfügbar ist. Bei einer bidirektionalen Synchronisierung muss außerdem festgelegt werden, was geschieht, wenn eine Anwendung einen Datensatz löscht, während eine andere ihn ändert. Ohne diese Entscheidung kann das System den Konflikt nicht zuverlässig lösen.
Löschen, Archivieren und Deaktivieren sind unterschiedliche Aktionen
- Physisches Löschen: Der Datensatz wird aus dem aktiven Datenbestand des Systems entfernt. Für übliche Funktionen ist er möglicherweise nicht mehr zugänglich, auch wenn für Sicherungskopien, technische Protokolle oder Aufbewahrungsrichtlinien eigene Regeln gelten. Gehen Sie nicht davon aus, dass damit automatisch alle Spuren gelöscht werden.
- Archivieren: Der Datensatz bleibt erhalten, wird aber vom alltäglichen Arbeitsablauf getrennt, beispielsweise aus den Standardansichten entfernt. Das ist sinnvoll, wenn der Verlauf oder der Kontext weiterhin verfügbar sein soll. Legen Sie fest, ob verbundene Systeme den Status „archiviert“ erhalten oder den Datensatz lediglich nicht mehr anzeigen.
- Deaktivieren: Der Datensatz bleibt bestehen, nimmt aber nicht mehr an einem Vorgang teil. Ein deaktiviertes Produkt kann beispielsweise weiterhin mit früheren Bestellungen verknüpft sein, wird aber nicht mehr für neue Verkäufe angeboten. Die genaue Bedeutung hängt vom Prozess ab: „Inaktiv“ hat keine allgemeingültige Definition.
Unterscheiden Sie außerdem eine angeforderte Stilllegung von einer Korrektur. Wurde ein Datensatz versehentlich gelöscht, kann eine Wiederherstellung sinnvoll sein. Handelt es sich dagegen um eine endgültige Stilllegung, ist die Wiederherstellung durch eine Synchronisierung ein Fehler. Modellieren Sie diese Aktionen getrennt, wenn sie unterschiedliche Berechtigungen, Aufbewahrungsregeln oder operative Folgen auslösen.
Die Bedeutung anhand des Geschäftsprozesses festlegen
Beginnen Sie mit den beobachtbaren Folgen und nicht mit der Funktion, die eine Benutzeroberfläche anbietet. Fragen Sie, was jedes Team und jedes System nach der Aktion tun können soll. Kann mit dem Datensatz noch ein neuer Vorgang angelegt werden? Soll er in historischen Suchergebnissen erscheinen? Gibt es Rechnungen, Bestellungen, Fälle oder Berichte, die davon abhängen? Je nach Datensatzart können die Antworten zu unterschiedlichen Entscheidungen führen.
Als Faustregel gilt: Deaktivieren Sie einen Datensatz, wenn er als Referenz weiterhin gültig ist, aber keine neuen Vorgänge auslösen soll; archivieren Sie ihn, wenn er erhalten und aus der normalen Arbeit entfernt werden soll; und löschen Sie ihn physisch nur, wenn die geltenden Richtlinien und Abhängigkeiten das zulassen. Das ist keine zwingende Rangfolge. Die Entscheidung muss zu den geschäftlichen Anforderungen, den Aufbewahrungspflichten und den tatsächlichen Funktionen der Systeme passen.
Dokumentieren Sie die Regel so, dass sie überprüfbar ist. Präzisieren Sie statt „Beim Löschen die Stilllegung synchronisieren“, welche Aktion sie auslöst, welche Systeme sie erhalten, welches Verhalten sich dort ändert und ob sie rückgängig gemacht werden kann. Vereinbaren Sie auch, welches System maßgeblich ist: Wenn nur ein System über die Stilllegung entscheiden darf, sollten Änderungen in anderen Systemen den Datensatz nicht ohne eine autorisierte Aktion erneut aktivieren.
Welches Signal die Integration übertragen muss
Die Integration braucht eine eindeutige Darstellung. Eine Möglichkeit besteht darin, bei der Aktion ein Stilllegungsereignis zu übertragen. Alternativ kann bei jedem relevanten Austausch ein ausdrücklicher Status wie aktiv, archiviert oder deaktiviert gesendet werden. Auch eine Löschmarkierung – etwa ein Stilllegungskennzeichen – kann verwendet werden: Sie erhält den Datensatz und macht ihn bei späteren Synchronisierungen erkennbar.
Welche Variante passt, hängt vom Austauschverfahren ab. Ereignisse übermitteln eine Änderung zum Zeitpunkt ihres Auftretens, doch die Systeme müssen Wiederholungen, Duplikate und Nachrichten in falscher Reihenfolge verarbeiten können. Ein ausdrücklicher Status erleichtert den Vergleich des aktuellen Zustands, setzt aber voraus, dass Abfragen auch inaktive Datensätze oder ihre Stilllegungskennzeichen berücksichtigen. Lässt die Quelle einen gelöschten Datensatz einfach weg, fehlt dem Empfänger ein ausreichendes Signal, um eine Stilllegung von einer vorübergehenden Abwesenheit zu unterscheiden.
Unabhängig vom Mechanismus sollten Sie eine stabile Kennung zur systemübergreifenden Zuordnung des Datensatzes sowie den Status oder Aktionstyp, den Zeitpunkt oder die Version der Änderung und das Quellsystem festlegen. Der Empfänger sollte dasselbe Signal mehrfach verarbeiten können, ohne widersprüchliche Folgen auszulösen. Haben die Anwendungen unterschiedliche Statuswerte, vereinbaren Sie eine ausdrückliche Zuordnung. Nehmen Sie nicht an, dass „archiviert“ in einem System „gelöscht“ in einem anderen bedeutet.
Verhindern, dass eine Synchronisierung Datensätze wiederherstellt
Der wichtigste Schutz besteht darin, die Information über die Stilllegung lange genug aufzubewahren und zu übertragen, bis die anderen Systeme sie erhalten haben. Wird der Datensatz in der Quelle physisch gelöscht, bevor die Integration ihn erkennt, kann auch der einzige Hinweis auf seine frühere Existenz verschwinden. Eine Löschmarkierung oder ein Ereignisprotokoll, das bis zur bestätigten Übertragung aufbewahrt wird, verhindert, dass man sich auf diese Abwesenheit verlassen muss.
Das Zielsystem sollte die Stilllegung als Status erkennen und nicht als flüchtige Anweisung, die nach der Verarbeitung verschwindet. Erhält es später eine ältere Kopie mit dem Status „aktiv“, braucht es eine Vorrangregel: Es kann beispielsweise die Version oder den Änderungszeitpunkt vergleichen und ältere Daten zurückweisen. Wenn eine Wiederherstellung zulässig ist, verlangen Sie eine ausdrückliche, autorisierte Reaktivierung, statt sie aus einer gewöhnlichen Aktualisierung abzuleiten.
Planen Sie auch die Wiederaufnahme nach einer Unterbrechung ein. Eine neu gestartete Synchronisierung muss Änderungen erkennen können, die während des Stillstands aufgetreten sind. Vereinbaren Sie, wie Signale erneut gesendet, bereits angewendete Nachrichten erkannt und Fehler geprüft werden. Ein Bericht über ausstehende Stilllegungen und Warnungen bei neu angelegten Datensätzen helfen dabei, das Problem frühzeitig zu erkennen, bevor daraus eine schwer nachvollziehbare Abweichung wird.
Referenzen, laufende Prozesse und Ausnahmen
Ein Datensatz kann mit anderen Daten verknüpft sein, die erhalten bleiben müssen: etwa mit einer Bestellung, einer Transaktion, einem Supportfall oder einem Änderungsverlauf. Wird er physisch gelöscht, kann eine Referenz ins Leere laufen oder die Interpretation eines früheren Vorgangs unmöglich werden. In solchen Fällen muss das empfangende System möglicherweise eine minimale Version aufbewahren oder den Datensatz für neue Vorgänge als nicht verfügbar kennzeichnen. Die Entscheidung muss geltende Richtlinien und die Funktionen der jeweiligen Systeme berücksichtigen; gehen Sie nicht davon aus, dass alle Systeme dieselbe Art der Stilllegung unterstützen.
Prüfen Sie laufende Vorgänge gesondert. Was geschieht, wenn eine bereits genehmigte Anfrage, ein in einer Bestellung enthaltenes Produkt oder eine laufende Aufgabe deaktiviert wird: Wird der Vorgang abgebrochen, abgeschlossen oder ohne neue Vorgänge fortgeführt? Eine allgemeine Regel reicht möglicherweise nicht aus. Legen Sie fest, welcher Prozess Vorrang hat und wer über Ausnahmen entscheiden darf. Unterstützt eine Anwendung keine Löschungen, weisen Sie ihr einen kompatiblen Stilllegungsstatus zu und dokumentieren Sie, welche Daten sie aufbewahrt und wer sie einsehen darf.
Für Korrekturen sollte es einen eigenen Ablauf geben. Eine fehlerhafte Stilllegung muss möglicherweise rückgängig gemacht werden. Die Reaktivierung eines Datensatzes sollte jedoch weder den Stilllegungsverlauf löschen noch verschleiern, wer die Entscheidung getroffen hat. Die getrennte Behandlung von „Stilllegung korrigieren“, „wiederherstellen“ und „reaktivieren“ sorgt für eine nachvollziehbare Prüfungsspur und verhindert, dass ein automatisierter Prozess Datensätze versehentlich wieder öffnet.
Checkliste vor der Einführung
- Umfang festlegen: Bestimmen Sie die Datensatzarten, beteiligten Systeme und Aktionen, die eine Stilllegung auslösen können.
- Bedeutungen vereinbaren: Legen Sie für jeden Geschäftsprozess fest, was Löschen, Archivieren und Deaktivieren bewirken.
- Zuständigkeit zuweisen: Bestimmen Sie, wer Datensätze stilllegen und wer sie wiederherstellen oder reaktivieren darf.
- Signal entwerfen: Wählen Sie Ereignis, Status oder Löschmarkierung und definieren Sie Kennungen, Versionen und den Umgang mit Duplikaten.
- Abhängigkeiten schützen: Prüfen Sie Referenzen, Verlauf, laufende Prozesse und Systeme, die kein Löschen unterstützen.
- Fehlerszenarien testen: Berücksichtigen Sie wiederholte Nachrichten, unterbrochene Synchronisierung, gleichzeitige Änderungen, veraltete Daten und autorisierte Wiederherstellungen.
- Überwachung vorbereiten: Vereinbaren Sie, wie ausstehende Stilllegungen, Fehler, Neuanlagen und Abweichungen geprüft werden und wer auf Warnungen reagiert.
Die richtige Entscheidung ist nicht immer das Löschen. Entscheidend ist, eine klare geschäftliche Absicht zu übermitteln, die erforderlichen Informationen aufzubewahren und dafür zu sorgen, dass alle verbundenen Systeme sie einheitlich interpretieren. Lassen sich die Regeln als Statuswerte, Zuständigkeiten, Ausnahmen und überprüfbare Tests formulieren, sinkt das Risiko deutlich, dass eine Synchronisierung aus einer Stilllegung unerwartet eine Neuanlage macht.