Skip to content
Snippets Groups Projects

[Epic] Bidirektionale Kommunikation (Rückkanal)

    • Closed Issue created by Marco Holz @Marco_Holz

    Warum?

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

    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

    38 of 67 checklist items completed · Edited

    Designs

      Child items ...

      2. Activity

      Please register or sign in to reply