Skip to content

Zwischenspeichern von Zustellpunkten im ZSD für das SSP

User Story

  • Als Benutzer des SSP
  • möchte ich auch unfertige destinationen als Entwurf speichern
  • um unter anderem unbekannte Informationen erst später nachpflegen zu können

Use Cases

  1. ARS muss von jemanden erfragt werden
  2. Fachdatensatz muss von Fachverfahren erfragt werden
  3. Diskussion über Version vom Fachdatensatz läuft noch
  4. Metadatensatz muss von Fachverfahren erfragt werden
  5. Callback und Polling sagen mir nichts, weswegen ich erst unsere Techniker fragen muss
  6. Ich habe noch keine V-PKI-Zertifikat
  7. Ich habe das V-PKI-Zertifikat noch nicht umgewandelt
  8. Ich weiß nicht, welche genaue Leika genutzt werden soll und muss es mit dem Fachverfahren besprechen
  9. Werde nicht fertig, weil ich gestört wurde und mache es morgen fertig

Why

Der Benutzer füllt das Formular für den Zustellpunkt aus und stellt fest, dass er nicht alle Informationen hat. Deshalb muss er das Formular vorübergehend speichern und nach einer bestimmten Zeit zurückkehren, um es fertig auszufüllen.

Zusätzlich gibt es die Herausforderung, dass diese Informationen nicht nur von einer, sondern eher von 2-3 Personen in unterschiedlichen Organisationen bekannt sind. Mit der Teamfunktionalität wird es die Möglichkeit geben, das alle 3 Personen selbst die notwendigen Infos einpflegen. Beispiel:

  • Fachverfahren(z.B. priv. Unternehmen) kennt die Callbacks und Serviceleistung
  • IT Betreiber(z.B. Landes-RZ) des Fachverfahrens hat die V-PKI Zertifikate und Keys

Weiteres Szenario ist, dass die "Massenanleger" von Zustellpunkten (z.B. Middleware Anbieter) ebenfalls Frontends oder ähnliches haben um die Informationen zum Zustellpunkt anzulegen. Daher ist eine Speicherung im Browser keine gute Option.

Um diese Funktionalität im SSP zu ermöglichen soll ein neuer Status "draft" eingeführt werden. (https://docs.fitko.de/fit-connect/docs/details/destination-management#statusmodell-eines-zustellpunktes)

In Zukunft werden alle Information zur destination vom ZSD Team verwaltet in der Destination-API. Technische Herausforderung an der Stelle ist, dass die Informationen in vielen unterschiedlichen Tabellen gespeichert werden, so dass fast alle Endpunkte dafür auch angepasst werden müssten und die Tabellen jetzt bereits viele Pflichtfelder haben. Option zur Umsetzung wäre, die Informationen in einer separaten Tabelle zu speichern mit den Zustellpunkten im Status "draft" das würde aber bedeuten, dass die destination Endpunkte auch dupliziert werden würden.

Links, Notes, Remarks

Konzeptionierung:

Was soll zwischengespeichert werden können?

  • Alle Felder
  • Achtung bei Schlüsseldateien - muss hier etwas beachtet werden?

Wo sollen Informationen zwischengespeichert werden?

  • Möglichkeiten:
  1. Kundenbrowser: Daten beim Kunden, Was passiert bei Teilung des Rechners? Daten müssen verschlüsselt sein und nutzergebunden sein
  2. SSP: Datenbank würde bestehen
  3. Präferierte Option: Zustelldienst: Zustellpunkt mit Minimalangaben zulassen, Aktivierung hängt Prüfung ab

Wie lange sollen die Informationen vorhanden sein?

  • 2 Wochen (Muss konfigurierbar sein) - Gesetzliche Vorschriften?

Wie sind die Informationen bei uns zwischengespeichert?

  • TBD

Acceptance criteria

  1. Zustellpunkte können im Status "draft" gespeichert werden (POST /v1/destinations) und auch aktualisiert (PUT&PATCH /v1/destinations/{destinationId} & /v1/destinations/{destinationId}/keys) - ohne die Beachtung der Pflichtfelder
  2. "draft" Zustellpunkte können in den Status "created" überführt werden (hier erfolgen erst die relevanten Prüfungen
  3. "draft" Zustellpunkte werden nach 14 Tagen (Zeitraum über Config definerbar) automatisch gelöscht (wie vom decommissioned -> deleted)
  4. "draft" Zustellpunkte können manuell jederzeit gelöscht werden (DELETE /v1/destinations/{destinationId})
  5. Es kann kein Zustellpunkt zurück auf den Status "draft" gesetzt werden
  6. "draft" Zustellpunkte können nur vom Owner-Client (&SSP Client) abgerufen werden (GET /v1/destinations/{destinationId} & GET /v1/destinations/{destinationId}/keys/{keyId}
  7. Es können keine Submissions an "draft" Zustellpunkte gesendet werden
  8. externe Dokumentation ist entsprechend den Änderungen angepasst
  9. Bevor das Zwischengespeicherte gelöscht wird gibt es eine Information an den Nutzenden

Implementation plan (to be completed by the developer)

Follow-Up

  • Nutzung dieser Endpunkte durch das SSP

Offene Fragen

  • Die neuen bzw. angepassten Endpunkte sollen vermutlich auch unter dem Abschnitt internal auf der Submission API Spezifikation gelistet bzw. angepasst werden, oder? Dann muss auch die Submission API angepasst werden (d.h. AK ergänzen und Label hinzufügen) (  @Christoph_Metzger)
Edited by Andreas Aschauer