Skip to content

[Epic] Nutzungsstatistiken exportieren (Extrakt DB)

Warum?

Warum machen wir das?

FIT-Connect ist ein Produkt des IT-Planungsrats. Es bekommt jährlich beträchtliche finanzielle Zuwendungen, um Betrieb und Pflege aufrechterhalten zu können. Im Umkehrschluss möchte die Außenwelt, nicht zuletzt auch der IT-Planungsrat selbst, wissen,

  • ob und inwiefern das Produkt FIT-Connect genutzt wird,
  • wie leistungsfähig FIT-Connect ist,
  • wie weitgehend die Verbreitung von FIT-Connect ist und
  • ob es Muster oder Tendenzen gibt, wer (Gruppen von Fachverfahrenshersteller, Onlinedienste) bspw. FIT-Connect (nicht) nutzen.

Vor diesem Hintergrund müssen daher statische Metriken im Bereich der Nutzung von FIT-Connect definiert werden und Implementierungen vorgenommen werden, um die benötigten Kenngrößen nach Möglichkeit automatisiert zu ermitteln. Über eine programmatische Schnittstelle soll die Auswertung dieser Kenngrößen möglich sein.

Inhalt dieses Epics sind Metriken, die die strukturelle Größe von FIT-Connect beschreiben. Metriken auf Basis der Logs, die die dynamische Größe (Nutzungshäufigkeit) von FIT-Connect beschreiben, werden in dem Issue #111 behandelt.

Eine Liste der bislang identifizierten erforderlichen Kenngrößen ist unter Akzeptanzkriterium 1 zu finden.

Zielbild:

  • Anbindungsreporting besteht aus validen Daten aus unserem System.
  • Fehleranfälligkeit der Daten wurde minimiert
  • Wir wissen wie FIT-Connect eingesetzt wird und in welchen Themenfeldern/Anträgen --> Abhängigkeit zu Anbindungsprojekten wird verringert

Relevante Links und Bemerkungen

Erste Ideen, welche in der ersten Evaluierungsphase aufgekommen sind:

Akzeptanzkriterien

Im Rahmen dieses Issues ist der Fokus auf die Extraktion der Daten für FITKO-Interne Zwecke, die dann in das aktuelle Anbindungsmanagement Cockpit in PowerBI geladen werden sollen.

  1. Architektur des Zugriffs ist festgelegt
  2. Daten und Verknüpfungen zwischen den Datenobjekten sind als Rohdaten verfügbar, damit die Auswertungen und Konsolidierungen im Nachgelagerten Tool erfolgen können und im nächsten Schritt von externen öffentlich abgerufen werden können
  3. Der Zugriff auf die Daten beeinträchtigt den Regelbetrieb der FIT-Connect Infrastruktur nicht.
  4. Die Daten für eine Auswertung können über die folgende CSV Dateien abgerufen werden (Sammlung auf Basis von https://docs.fitko.de/fit-connect/docs/apis/submission-api/?version=1.3.0-rc3)
  5. Die Metriken sollen aus allen Umgebungen (TEST; STAGE; PROD) abgerufen werden können normaler Deploymentmodus
    1. Skript zur Ergänzung der Altdaten in den Statistiktabellen ist implementiert
  6. Die Metriken wurden bewertet und entschieden, welche Metriken schützenswert sind und welche nicht (DSB FITKO) (Speziell client->owner wäre noch abzustimmen) -> https://git.fitko.de/fitko/architekturmanagement-standards/fit-connect/projektmanagement/-/issues/758
  7. Follow-Up: Folgeissue ist angelegt: Die nicht schützenswerten Metriken werden in einem zentralen öffentlich zugänglichen Dashboard und dahinter liegenden APIs zur Verfügung gestellt
    1. Daten können exportiert werden in Excel- und/oder PDF-Format
    2. Daten können mindestens 1x die Woche exportiert werden (Optimal Verhalten per Knopfdruck zu jeder Zeit)
    3. Daten stellen den aktuellen Stand von der Minute dar
  8. Folgeissues zu Löschung der gelöschten Submissions( #378) und der Bereinigung der Statistiktabellen sind angelegt keine Nutzung der Statistiktabellen
  9. Definition of Done wurde geprüft

in #111 zu übertragen: 4. erfolgreicher Cases/Submissions/Replys für ein bestimmtes Themenfeld (ermittelt über Leika-Leistung Kopie_von_OZG-IP-Umsetzungskatalog-Export_2023_08_11_0503.xlsx)

Stories zu dem Epic:

  • Festlegung Architektur Reporting API (AK1, AK6) - #1348 (closed)
  • Pilotierung (Export als CSV aus DB, Import in DB und Prüfung mit PO wo Ergänzungen notwendig sind - Abschluss mit dem CSV Zielformat) - #1349 (closed)
  • Implementierung Zugangssteuerung -> TEAM INFRASTRUKTUR - #1350 (closed)

--- Quality Gate mit Laura, Hauke, Elmar & Andreas ---

  • Grundgerüst implementieren auf Basis AK1 (AK2, AK5, AK6) & Bereitstellung Zustelldienst-Endpunkte, inkl. notwendiger Anpassungen an DB / Zustelldienst-Prozessen (AK4.2, AK 4.3, AK4.4) - #1391 (closed)
  • Anpassung der Endpunkte an die BiDiKo (Auswertung von Replies) #1423 (closed)
  • Bereitstellung SSP-Endpunkte, inkl. notwendiger Anpassungen an DB / Zustelldienst-Prozessen (AK4.1) -> TEAM SSP #1424 (closed)

--- Quality Gate mit Laura, Hauke, Elmar & Andreas ---

  • Deployment & Aktivierung auf allen Umgebungen (AK3, AK7, AK8) - traefik Konfiguration über Team Infrastruktur
  • Automatisierung Import der Daten in PowerBi und Abschluss der Cockpits (Produktmanagement)

Follow-Up

  • Prüfen ob über eine veränderte Architektur (Grafana) das Thema grundsätzlich nicht besser gelöst werden könnte. In dem Zusammenhang prüfen wo die LOGs ausgewertet werden können.
  • ggf. Performanceoptimierungen (aktuell lesen wir direkt aus den produktiven Tabellen)
  • Folgeissue ist angelegt: Die nicht schützenswerten Metriken werden in einem zentralen öffentlich zugänglichen Dashboard und dahinter liegenden APIs zur Verfügung gestellt

offene Fragen

Beantwortete und eingearbeitete Fragen
  • Export über REST-API oder Dateiexport?
    • Ziel: CSV Dateien, die mit einem Token (ClientID / ClientSecret) abrufbar wären
    • Über einen eigenen Scope wird der Client berechtigt
    • Stats Tabellen(ggf. zusätzliche für Destinations, Cases & Replies) sollen für die Exporte befüllt werden und dann beim Aufruf der CSV Dateien generiert werden
  • Definition der einzelnen Metriken ( @Christoph_Metzger) - Was heißt "Verbreitung"? Was heißt "leistungsfähig"?
    • sind eher "politische" / "strategische" Kenngrößen die tatsächlich sich noch finden müssen
  • eigene Statistikdatenbank oder über bestehende Statistik-Tabellen
    • bestehende Statistiktabellen ausbauen
  • Wie kommen die Informationen aus der SSP-DB in die Statistik-DB
    • eigene CSV Datei im SSP
  • Welche Informationen aus der SSP-DB werden für den Export benötigt? ( @Christoph_Metzger)
    • die Clientbezogenen Informationen (n:n Beziehung Clients zu Destination)
  • Kann in einer ersten Version auf die Daten aus der SSP-DB verzichtet werden? → Hintergrund: Im Rahmen von #1278 plant das SSP Team seine Datenhaltung aufzugeben und an den zustelldienst zu verschieben - dann sind die Daten auch im zustelldienst verfügbar. ( @Christoph_Metzger)
    • gehen wir erstmal an

Über eine programmatische Schnittstelle soll die Auswertung dieser Kenngrößen möglich sein.

  • Sollen die Daten vom Zustelldienst auch "ausgewertet" oder "nur" exportiert werden? ( @Christoph_Metzger)
    • nur Export der Rohdaten - für die Auswertung lieber auf BI Tools zurückgreifen (Anm. Wojtek)
  • Idee für nächste Ausbaustufe: Auch eingetragene Callback URLs "tracken" ( @Christoph_Metzger)
    • versuchen wir direkt umzusetzen (wer und in welchem Umfang nutzt tatsächlich Callbacks)
  • Es gibt schon die beiden Tabellen
    • submission_stats: id, destination_id, submitted_at, identifier, data_size_bytes
    • submission_stats_attachment: id, fk_submission_stats, size_bytes Wofür werden diese aktuell verwendet? Kann man diese Tabellen für den Use Case des Epics weiter ausbauen? ( @Christoph_Metzger)
    • Entscheidung: Exporte auf Basis dieser Tabellen und Ausweitung auf die anderen Tabellen (SubmissionID, CaseID & ReplyID aufnehmen)
  • Anstelle von Tabellen, sind Views in unserer DB eine Option? ( @Christoph_Metzger)
    • Verworfen, da wir mit den Statistiktabellen arbeiten wollen

Entscheidung eigene DB vs. Tabellen in bestehenden DB, die via Job befüllt werden

  • Gibt es eine Lösung ohne einen Job? Z.B. mit Views? ( @Christoph_Metzger)
    • ja - Statistiktabellen werden in Echtzeit gefüllt und Export erfolgt auch in Echtzeit
  • Was haben gelöschte Submissions für eine Auswirkung auf die Metriken? ( @Christoph_Metzger)
    • sollen mit ausgegeben werden (aber als deleted gekennzeichnet - Status)
  • Wenn die Daten per REST abgefragt werden, wie sieht die Zugriffskontrolle aus? Sind die Daten öffentlich? Falls eine Zugriffskontrolle benötigt wird, welche Teams müssen hier unterstützen? ( @Christoph_Metzger)
    • siehe oben (CSV und eigener Client mit eigenem Scope

Die Metriken sollen aus allen Stages abgerufen werden können

  • Ist das aufgrund der verzögerten Bereitstellungen auf TEST, STAGE und PROD ein realistisches Akzeptanzkriterium für effektiv 2 Sprints? ( @Christoph_Metzger)
    • es muss für alle Umgebungen funktionieren, kann aber auch nachgelagert deployed werden (Anm. Wojtek)

AC6: Die Metriken wurden bewertet und entschieden, welche Metriken schützenswert sind und welche nicht (DSB FITKO)

  • AC6 ist bereits abgehakt. Wo finden wir die Ergebnisse? ( @Christoph_Metzger)
    • Owner wäre noch mit DS abzustimmen
  • In wie weit sind diese Daten von der Löschung und den Löschfristen betroffen? ( @Christoph_Metzger)
    • keine Änderung an Löschfristen (ggf. für Owner prüfen in der Statistiktabelle)
    • Neues Issue zu Löschung der gelöschten Submissions( #378) und der Bereinigung der Statistiktabellen
  • Sollen bestehende bzw. "alte" Daten in die "neue" Metrik-Tabelle/View migriert werden oder nur alles "neue"? ( @Christoph_Metzger)
    • sollten wir soweit möglich versuchen (bei zu komplexen Vorgehen Einzelfallentscheidung)
    • ggf. ein Job, den wir per Hand starten nach dem Deployment
  • Wäre möglich eine Datei auch in Prod bereitzustellen
    • grundsätzlich ja, siehe oben - wäre aber mit ITN abzusprechen
  • sollen auch deleted submissions
    • ja mit Datum der Löschung (ggf. Datum der Submission)
  • Dateigrößen
    • wir schauen wie groß die aktuellen Exporte sind und Entscheiden auf der Basis, ob wir eine Komprimierung einbauen (ggf. über GZIP im HTTP Header)
  • Anzahl CSV Dateien. Jonas hatte verstanden, dass die "Relationen" exportiert werden sollen, sprich pro Entität (Submission, Case, Reply, ...) eine CSV Struktur. Ich habe es jetzt zuletzt so verstanden, dass alle notwendigen Informationen flach in einer CSV Struktur exportiert werden sollen. Oder wahrscheinlich werden es 2 CSV Strukturen: 1x Submissions und 1x Replies?
    • Wojtek: ich bin da bei Jonas: würde pro Entität auch eine CSV Datei erstellen (zum Beispiel könnten wir auch für die Anhänge der Submissions eine eigene CSV Datei bereitstellen) Ich würde hier keinen Invest in irgendwelche Aggregationen stecken. wir können daher auch 1 Datei für Submissions und eine für REplies machen. BI Lösungen können das im Zweifel gut aggregieren.
  • Wir würden das Thema gerne iterativ angehen, also nicht gleich die volle Lösung des Epics umsetzen, sondern schrittweise. Hier wären z.B. erste mögliche Schritte "CSV Struktur(en) mit X (Laura?) abstimmen", "manueller Export auf DEV oder TEST in dieser Struktur und Feedback dazu", ...
    • Wojtek: finde ich gut, in diesem Sinne würde ich versuchen die Stories so zu definieren, dass diese Iterativ abgearbeitet werden können. Im ersten Schritt exportieren wir manuell CSV Dateien und prüfen wo wir dafür was anpassen müssen.
Neue Fragen

- [ ] ...

Edited by Wojciech Gdaniec