Skip to content

SET-Payload-Schemas mitliefern [M]

Warum?

Derzeit wird zum Prüfen eines SET das SET-Payload-Schema von schema.fitko.de heruntergeladen. Dies führt dazu, dass wenn dies nicht möglich ist, ein Timeout auftritt und SETs evtl. zurückgewiesen werden.

Deswegen sollen alle zulässigen Schemas integriert werden.

Relevante Links und Bemerkungen

  • In der Klasse de.fitko.fitconnect.Schemas sind im Array SET_PAYLOAD_SCHEMAS_ALLOWED alle zulässigen Schemas aufgelistet.

Akzeptanzkriterien

  1. Der Zustelldienst kann alle zulässigen Schemas prüfen, ohne dafür zur Laufzeit einen Download durchzuführen

Durchführungsplan

Design Entscheidung Zustelldienst:

  • URL Rewriter mit gecachtem load beim startup vs Static Files storage und simplem cache store beim startup.
    • Letzteres -> Weniger code
  • Config Statisch vs Spring injected dep
    • statisch -> einfacher zu testen. Lösung für resource loading gefunden.
  • Welcher String in Config ablegen.
    • Nur die Version. Extrapolation zur vollen URI hardcodiert im code. Sollte sich in Zukunft nicht ändern.
  • Folder path mit sub folder für versionen oder soll ich die Version im Dateinamen encoden ?
    • version encoden nur als $(version).json. Ist simpler und übersichtlicher

Umsetzung:

  • Zustelldienst Anpassen (https://git.fitko.de/fit-connect/zustelldienst/-/merge_requests/79#910754821ef76ca29b24377e80c83c85b1ac64cb)
    • Festlegen, wie aus einer URI (ID des Schemas) ein Dateiname abgelteit wird
    • Das Array SET_PAYLOAD_SCHEMAS_ALLOWED in die application.yml extrahieren
    • Eine Config-Klasse dafür schreiben
    • Beim Validieren das Schema laden und über SchemaStore.store(uri, schema) ablegen
  • In der CI-Pipeline alle Schemas laden und in ein Verzeichnis im Docker-Container legen, damit es beim bauen des Zustelldienst gepackaged werden kann (optional Delay für Ticket fertigstellung Speedup)
    • Wird jetzt über den maven build Prozess gelöst (via com.googlecode.maven-download-plugin)
  • Dev deployen und manuell testen (ob das Schema lokal geladen wird)
    • Abchecken auf welcher Version wir aufbauen (main, 1.5.1) ?
  • Test ausrollen
  • Docu anpassen (docs!154 (merged))
    • Zu verwendende SET payload version ( [0.1.0, 1.0.0] ) oder ohne schema version erlaubt
    • Zu erwartende SET payload versions ([0.1.0, 1.0.0]) oder ohne schema version erlaubt
  • set payload spec 1.0.0 releasen (docs!151 (merged))
  • Zustelldienst api tests für payload spec version schreiben (https://git.fitko.de/fit-connect/zustelldienst-api-tests/-/merge_requests/40)
  • Api Spec anpassen
    • post Set - Hinzufügen der allowed set payload version ( [0.1.0, 1.0.0] ) oder ohne schema version erlaubt
      • Nichts zu machen. Es wird nur auf die Doku verwiesen
    • get Set - Hinzufügen der verfügbaren set payload version ([0.1.0, 1.0.0]) oder ohne schema version erlaubt
      • Nichts zu machen. Es wird nur auf die Doku verwiesen
  • Ticket für Auto Deletion of Sets erstellen ?
    • Via Zustelldienst Versionsänderung inclusive Datenmigration ?
  • Ticket für Rückkanal anpassen: Set payload version hinzufügen + docu und api spec anpassung
  • Zustelldienst SET Refactoring durchführen (https://git.fitko.de/fit-connect/zustelldienst/-/merge_requests/82)
Edited by Florian Kaufmann