[Epic] Standardvorgehen für große Fachdatensätze

Warum

Anlagen sollten als separate Attachments in FIT-Connect übertragen werden. Derzeit gibt es allerdings noch XÖV-Standards, die fordern, die Anlagen in den Fachdatensatz einzubetten. Auch viele Onlinedienste und Verwaltungssysteme haben dieses Vorgehen implementiert.

FIT-Connect unterstützt nur maximal ca. 10-14 MB große Fachdatensätze, was im Normalfall ausreichend ist. Werden Anlagen in den Fachdatensatz eingebettet, so kann dieser das gesetzte Limit überschreiten.

Damit betroffene Onlinedienste und Verwaltungssystem keine bilateralen Absprachen treffen müssen, soll FIT-Connect ein Standardvorgehen für große Fachdatensätze definieren.

Ziel

Wir definieren eine Maximalgröße des Fachdatensatzes von 10 MB. Größere Fachdatensätze müssen als Attachment gesendet werden.

Als encryptedData wird als Platzhalter ein leerer String übertragen.

Der Metadatensatz wird wie folgt befüllt:

  • contentStructure:
    • data:
      • submissionSchema: Wird normal befüllt
      • hash: Hash über den Platzhalter
        • type: immer sha512
        • content: immer cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e (Hash über 0 Bytes)
    • attachments: Enthält in diesem Fall normalerweise nur eine Anlage (der Fachdatensatz), da die eigentlichen Anlagen im Fachdatensatz eingebettet sind.
      • attachmentId: Zufällige UUID
      • purpose: immer data; neuer Wert für "Fachdatensatz" (siehe Hinweis untern)
      • filename: Kann frei gewählt werden; Empfehung: data.json bzw. data.xml, je nach Datentyp
      • description: Kann frei gewählt werden, z.B. "Fachdatensatz als Anlage"
      • mimeType: Je nach Datentyp application/json oder application/xml
      • hash: Hash des Fachdatensatzes
        • type: immer sha512
        • content: SHA-512-Hash des Fachdatensatzes

Beispiel für den Eintrag des Fachdatensatz im Metadatensatz:

{
  "contentStructure": {
    "data": {
      "submissionSchema": {
        "schemaUri": "urn:xoev-de:d-nrw:standard:xsozialbasis_2.2.0#vorgang.transportieren.1000001",
        "mimeType": "application/xml"
      },
      "hash": {
        "type": "sha512",
        "content": "cf83e1357eefb8bdf1542850d66d8007d620e4050b5715dc83f4a921d36ce9ce47d0d13c5d85f2b0ff8318d2877eec2f63b931bd47417a81a538327af927da3e"
      }
    },
    "attachments": [
      {
        "attachmentId": "32e522fa-2fde-4893-bcf9-a57c1a07398e",
        "purpose": "data",
        "filename": "data.xml",
        "description": "Fachdatensatz als Anlage",
        "mimeType": "application/xml",
        "hash": {
          "type": "sha512",
          "content": "246065c584233bf35406872c180f96f05ff9f6d62d3daa830a37e149891ac5dcf533981bf2cdc98a3f06464683d372052f1ffcd2937988f9f59cb325f3518afc"
        }
      }
    ]
  }
}

Das Verwaltungssystem erkennt an der purpose: data, dass es sich bei dieser Anlage um den Fachdatensatz handelt und verwendet diese statt dem in encryptedData übertragenen Platzhalter.

Die Kennzeichnung purpose: data darf nur bei einer Anlage gesetzt werden. Ist mehr als eine Anlage gekennzeichnet, so muss das Verwaltungssystem die Übertragung mit einem Fehler (reject-submission) abbrechen.

Für die Einführung von purpose: data ist eine neue Metadatenschemaversion notwendig. Bis dahin kann ersatzweise der Wert form verwendet werden.

Links, Hinweise, Bemerkungen

Stories

Akzeptanzkriterien

  1. Überprüfen der Möglichkeit, ob eine Validierung der Fachdaten weiterhin möglich ist
  2. Große Fachdaten werden als Attachment gesendet
  3. ...
  4. Definition of Done wurde überprüft.

Mögliche Folgeaktivitäten

Offene Fragen

  • Wird in den SDKs bei der Übertragung des Fachdatensatzes als Anlage die Schema-Validierung automatisch deaktiviert?
    • Falls ja: Wo dokumentieren wir das?
Edited by Martin Vogel