Skip to content

[Epic] Bidirektionale Kommunikation (Rückkanal)

Warum?

Es soll die Rückkanal Erweiterung der Submission implementiert werden. (Das ist kein Warum 😄 )

TODO

Links

Akzeptanzkriterien

  1. Die Implementierung der Submission API im Zustelldienst ist gemäß den Vorgaben aus #42 (closed) erfolgt.
  2. Die neue Implementierung der Submission API im Zustelldienst und die neuen Schemata wurden auf Abwärtskompatibilität getestet. Ggf. auch mit den .Net und Java SDKs geprüft.
  3. Die Implementierung im SSP ist gemäß den Vorgaben aus #42 (closed) erfolgt.
    • Destinations können mit den zusätzlichen Parametern für einen Rückkanal über FIT-Connect umgesetzt werden
    • Für Clients können die notwendigen Scopes hinterlegt werden
  4. In der Dokumentation wurden alle Aspekte der Umsetzung durch Subscriber und Sender beschrieben.
  5. Mit der Veröffentlichung der Dokumentation wurden auch die Aktualisierungen der API Spec und Schemata (Metadata und Security Event Token durchgeführt)
  6. Die Einträge in den Collection-Resourcen sind zeitlich aufsteigend (neueste zuletzt) zu sortieren (ORDER BY id). Betrifft:
    • GET /v1/replies
    • GET /v1/cases
    • CaseInformation/caseMessages <- Hier reicht ORDER BY id nicht, da sie aus zwei Tabellen kommen.
  7. Die spätere Umsetzung von #516 führt zu keinen Problemen.
Alte Sammlung von Akzeptanzkriterien und Issue-Verweisen
  1. Die Implementierung im Zustelldienst ist gemäß den Vorgaben aus #42 (closed) erfolgt.
  2. In der Dokumentation wurde das Rückkanal-Feature in einem Überblicks-Artikel beschrieben. -> #515 (closed)
  3. In der Dokumentation wurde das Rückkanal-Feature aus Sender-Sicht beschrieben. -> #515 (closed)
  4. In der Dokumentation wurde das Rückkanal-Feature aus Subscriber-Sicht beschrieben. -> #515 (closed)
  5. In der Dokumentation wurden alle neuen Events beschrieben (siehe https://git.fitko.de/fit-connect/konzepte/-/blob/main/Event_Log.md). -> #515 (closed)
  6. Im Glossar ist der Begriff processStandards definiert -> #514 (closed)
  7. Die Einträge in den Collection-Resourcen sind zeitlich aufsteigend (neueste zuletzt) zu sortieren (ORDER BY id). Betrifft:
    • GET /v1/replies
    • GET /v1/cases
    • CaseInformation/caseMessages <- Hier reicht ORDER BY id nicht, da sie aus zwei Tabellen kommen.
  8. Nach dem Schließen eines Cases dürfen keine Einreichungen und Antworten mehr begonnen oder abgesendet werden. Folgende Events dürfen nach einem close-case nicht mehr auftreten: create-submission, submit-submission, create-reply, submit-reply.
  9. Der Zustelldienst prüft die Zugriffsberechtigung des Senders anhand des sub-Claims (Subject).
  10. DVDV und Routing-Dienst / Routing API angepasst (Verbundendes Issue #278 prüfen)
  11. SSP für FIT-Connect Rückkanal Option angepasst

Stories zur Umsetzung der Akzeptanzkriterien im EPIC

Backend Stories

neue Stories nach PO Review (Teil 1):

Ergänzend Umsetzung von folgendem Issue prüfen: #278 (aktuell in Buffer und nicht in Ready)

Frontend Stories

Doku Stories

Klärungspunkt: Wie sinnvoll die einzelnen Issues umsetzen und in Main mergen?

Durchführungsplan (vom Entwickler bei Storyplanung auszufüllen)

  • Implementierung im Zustelldienst (API-Verhalten & Erstellung von SETs)
  • Rückkanal-Möglichkeiten im SSP ist angepasst
  • Aufnehmen ins Glossar: processStandards
  • Die Client-IDDer Subject-Claim (sub) des Senders wird in den Case übernommen.
  • Die Client-IDDer Subject-Claim (sub) aus dem Case wird bei allen Zugriffen des Senders geprüft. Achtung: Zugriffe des Subscribers werden weiterhin über die Destination geprüft.
  • ...

Follow-Up Stories oder Epics

Edited by Wojciech Gdaniec