Pilotierung Exporte Statistiktabellen

User Story

  • Als PO & Entwickler
  • möchte ich die Zieldateien genau kennen und die notwendigen fachlichen Änderungen an der Implementierung genau kennen
  • um schnell und ohne Komplikationen das Epic #1216 (closed) umzusetzen und sicherzustellen, dass alle notwendigen Auswertungen realisierbar sind.

Warum?

Im ersten Schritt des Epics #1216 (closed) sollen aus der Datenbank CSV Dateien manuell exportiert werden um diese zu laden und zu identifizieren wo Nachbesserungsbedarf abzudecken um die Anforderungen des Epics (Liste der Daten) abzudecken.

Relevante Links und Bemerkungen

Akzeptanzkriterien

  1. Inhalte der folgenden CSV-Dateien sind aus der DB exportiert und der Zielzustand ist mit dem PO abgestimmt (gewünschte Parameter siehe EPIC #1216 (closed) AK4)
    1. Liste der Clients mit den Daten: (Quelle: SSP) - [file1_1]
      1. clientId
      2. Kategorie Sender / Subscriber
      3. Owner (System + ID) (TODO: ggf. relevant für Datenschutz)
    2. Liste der Destinations mit den Daten: (Quelle: Zustelldienst-DB & angelehnt an GET /v1/destinations) - [file2]
      1. Verknüpfung zu der clientId über AK 1.6 (multiple Zuordnungen möglich)
      2. destinationId
      3. status
      4. Liste der services mit (mehrfacheinträge je Servicebündel)
        1. Liste der Leikas identifier
        2. Liste der ARS regions
        3. Liste der Schemas submissionSchemas (schemaUri / mimeType)
      5. Unterstützte Metadatenschemas metadataVersions
      6. Verantwortliche Stelle contactInformation -> unit (aus #722 (closed))
        • bis auf einen Antrag leer, wäre noch auf einer anderen Umgebung zu prüfen
      7. Hinterlegte Callback Adresse
    3. Liste aller Cases (Quelle: Zustelldienst-DB & angelehnt an GET /v1/cases)
      1. Verknüpfung zu destinationId
      2. Verknüpfung zum Sender /Online Service (KOMMT ERST MIT BIDIKO) subject in case table (siehe auch #510 (closed))
      3. caseId
      4. Status - erst in der nächsten Ausbaustufe
      5. Datum Anlage [DISCUS]: bekommen wir das einfach raus, oder nur über SETs - ggf. Dautum der ersten Submission sollten wir über submissions und das älteste Datum submitted bekommen (in BI)
      6. Datum Schließung [DISCUS]: bekommen wir das einfach raus, oder nur über SETs
    4. Liste aller Submissions (Quelle: Zustelldienst-DB & angelehnt an GET /v1/submissions & /v1/replies)
      1. Verknüpfung zu caseId
      2. submissionId
      3. Status (accepted / replied / deleted)
      4. `serviceType
        1. name
        2. ARS wird nicht übertragen, da Sender nur an zulässige Endpunkte senden kann
        3. identifier
      5. Datum submitted (Token -> jwt.io - iat) -> 1.8
      6. Datum accepted -> 1.8
      7. Datum rejected -> 1.8
      8. Datum deleted -> 1.8
      9. Anzahl Attachments (aus submission_stats_attachment) ->1.7
      10. ggf. Größe Attachments (aus submission_stats_attachment) ->1.7
    5. Liste aller Replies (Quelle: Zustelldienst-DB & angelehnt an GET /v1/submissions & /v1/replies) - KOMMT ERST MIT BIDIKO
      1. Verknüpfung zu caseId
      2. replyId
      3. Status (accepted / replied / deleted)
      4. `serviceType
        1. name
        2. ARS wird nicht übertragen, da Sender nur an zulässige Endpunkte senden kann
        3. identifier
      5. Datum submitted (Token -> jwt.io - iat) -> 1.8
      6. Datum accepted -> 1.8
      7. Datum rejected -> 1.8
      8. Datum deleted -> 1.8
      9. Anzahl Attachments (aus submission_stats_attachment) eigene Tabelle 1.7
      10. ggf. Größe Attachments (aus submission_stats_attachment) eigene Tabelle 1.7
    6. Liste aller Verknüpfungen zwischen Destinations & Clients (Quelle SSP?)
      1. destinationID
      2. clientID
    7. Liste aller Attachments
      1. AttachmentID
      2. SubmissionID
      3. / ReplyID - KOMMT ERST MIT BIDIKO
      4. Größe des Attachments
    8. Event Log (Token -> jwt.io - iat)
      1. SubmissionID
      2. / ReplyID - KOMMT ERST MIT BIDIKO
      3. current_status
      4. state_changed_at
      5. event
      6. token (Base64 codiert - decodieren erfolgt in PowerBI) 2. [X] $schema 3. [X] events 4. [X] iat 5. [X] iss 6. [X] jti 7. [X] sub 8. [X] txn
  2. Notwendige Änderungen bei der Ergänzung der Statistiktabellen während der Übertragungsprozesse ist definiert und abgestimmt (und in #1391 (closed) dokumentiert)
    • keine Erweiterungen notwendig
  3. Format der CSV Dateien ist final festgelegt

Durchführungsplan (von Entwickler:in bei Umsetzungsplanung auszufüllen)

Edited by Wojciech Gdaniec