[Epic] Bidirektionale Kommunikation (Rückkanal)
Warum?
Es soll die Rückkanal Erweiterung der Submission implementiert werden. (Das ist kein Warum
TODO
-
Add more test for permission handling in https://git.fitko.de/fit-connect/zustelldienst/-/merge_requests/235 -
Merge https://git.fitko.de/fit-connect/zustelldienst/-/merge_requests/235 in https://git.fitko.de/fit-connect/zustelldienst/-/tree/epic/bidirectional-communication -
Handle https://git.fitko.de/fit-connect/zustelldienst/-/merge_requests/236 (Issue #511) -
Handle https://git.fitko.de/fit-connect/zustelldienst/-/merge_requests/237 (Issue #512) -
Handle https://git.fitko.de/fit-connect/zustelldienst/-/merge_requests/238 (Issue #513) -
Inform the SDK team that OpenAPI 3.1.0 is used in the branch. They might want to test their model generation (if they do generate something). Ping @Klaus_Fischer and @Martin_Vogel. -
Check why pipeline fails in event-payload!1 (merged) → fixed it: event-payload@13a3539f -
HappyPath API Tests (ohne Callbacks) -
Release SET Schema 1.2.0 (currently released as 1.2.0-rc0) -
Release Metadatenschema 1.2.0 (currently released as 1.2.0-rc1) -
Release Submission API 1.3.0 (currently released as 1.3.0-rc2) -
Merge docs!180 (closed) in docs!426 (closed) by @Michael_Haidner. -
siehe TODOs in allen Stories
Links
- API Spec: #42
- API Spec MR: submission-api!167 (merged)
- Dokumentation der neuen Events: docs!180 (closed)
- Schema der neuen Events: event-payload!1 (merged)
- Initiale Ticketschnitte: https://md.darmstadt.ccc.de/rueckkanal-tickets
Akzeptanzkriterien
-
Die Implementierung der Submission API im Zustelldienst ist gemäß den Vorgaben aus #42 erfolgt. -
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. -
Die Implementierung im SSP ist gemäß den Vorgaben aus #42 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
-
-
In der Dokumentation wurden alle Aspekte der Umsetzung durch Subscriber und Sender beschrieben. -
Mit der Veröffentlichung der Dokumentation wurden auch die Aktualisierungen der API Spec und Schemata (Metadata und Security Event Token durchgeführt) -
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 reichtORDER BY id
nicht, da sie aus zwei Tabellen kommen.
-
-
Die spätere Umsetzung von #516 führt zu keinen Problemen.
Alte Sammlung von Akzeptanzkriterien und Issue-Verweisen
-
Die Implementierung im Zustelldienst ist gemäß den Vorgaben aus #42 erfolgt. -
In der Dokumentation wurde das Rückkanal-Feature in einem Überblicks-Artikel beschrieben.-> #515 -
In der Dokumentation wurde das Rückkanal-Feature aus Sender-Sicht beschrieben.-> #515 -
In der Dokumentation wurde das Rückkanal-Feature aus Subscriber-Sicht beschrieben.-> #515 -
In der Dokumentation wurden alle neuen Events beschrieben (siehe https://git.fitko.de/fit-connect/konzepte/-/blob/main/Event_Log.md).-> #515 -
Im Glossar ist der Begriff-> #514 (closed)processStandards
definiert -
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 reichtORDER BY id
nicht, da sie aus zwei Tabellen kommen.
-
-
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
. -
Der Zustelldienst prüft die Zugriffsberechtigung des Senders anhand des sub
-Claims (Subject). -
DVDV und Routing-Dienst / Routing API angepasst (Verbundendes Issue #278 prüfen) -
SSP für FIT-Connect Rückkanal Option angepasst
Stories zur Umsetzung der Akzeptanzkriterien im EPIC
Backend Stories
-
✅ #506 (merged withepic/bidirectional-communication
branch) -
#507 (merged with
epic/bidirectional-communication
branch) -
✅ #509 (merged withepic/bidirectional-communication
branch) -
✅ #510 (merged withepic/bidirectional-communication
branch) -
✅ #511 (merged withepic/bidirectional-communication
branch) -
✅ #512 -
✅ #513 (merged withepic/bidirectional-communication
branch) -
✅ #1208 (merged withepic/bidirectional-communication
branch) -
✅ #1226
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
- #115 / #515. MR: docs!426 (closed).
- #514 (closed)
- Callback Documentation (general): https://git.fitko.de/fit-connect/arch/-/blob/main/architecture/src/main/asciidoc/src/callbacks.adoc
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
-
Aufräumen der Callbacks (https://git.fitko.de/fit-connect/zustelldienst/-/blob/feature/1295-introduce-notify-reply-event/docs/callbacks.adoc?ref_type=heads) - z.B. warum wird der Sender via Callback informiert, dass er eine Submission angelegt oder versandt hat