Destination zweistufig löschen
Beim Löschen einer Destination muss sichergestellt sein, dass keine Anträge (Applications) verloren gehen. Daher wird das Löschen zweistufig realisiert:
Im ersten Schritt deaktiviert der Subscriber die Destination. Der Zustelldienst teilt dem Subscriber in der Antwort mit, ab wann eine Löschung erfolgen kann. Dieser Wert kann mehrere Tage in der Zukunft liegen. Die Berechnung dieses Zeitraums (Deaktivierungszeit) ergibt sich aus den folgenden Punkten und einem Sicherheitspuffer.
Ab der Deaktivierung können keine neuen Anträge mehr angelegt werden (Create Application), unvollständige Anträge können aber noch komplettiert und abgesendet werden. Es muss festgelegt werden, welche Zeit maximal zwischen dem Anlegen (Create Application) und Absenden (Send Application) vergehen darf.
Während der Deaktivierungszeit muss der Subscriber weiterhin noch eintreffende Anträge abholen.
Ist die Deaktivierungszeit abgelaufen und alle Anträge abgeholt, kann der Subscriber die finale Löschung über einen zweiten API-Aufruf durchführen.
Es ist folgendes zu tun:
-
Neue Operation "Deactivate Destination" einführen, die eine Destination deaktivert und die Deaktivierungszeit zurückgibt. -
Das Modell der Destination um eine Property "inactive" (boolean) ergänzen. Diese ist nur in der Destination mit ID enthalten. -
Dokumentation für sendende & empfangende Systeme erstellen (ggf. innerhalb der API-Spezifikation?). -
Issue zu Implementierungs-Anforderung erstellen: - Beim "Create Application" prüfen, ob die Destination aktiv ist.
- Beim "Delete Destination" prüfen, on die Destination inaktiv ist, die Deaktivierungszeit abgelaufen ist und keine Anträge vorliegen.
- Obige Bedingungen in Fehlerfälle fassen.