TODO: Beschreibung ist im Hinblick auf das Ziel zu überarbeiten ## Warum <!-- Erläutern Sie den Grund/die Ursache für diese Anforderung in Form einer User Story. --> 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 neben statischen Metriken auch historische Daten aus Logs 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 sowohl Metriken, die die strukturelle Größe von FIT-Connect beschreiben, als auch Metriken, die die dynamische Größe (Nutzungshäufigkeit) von FIT-Connect beschreiben. Dafür werden die Metriken aus den entsprechenden Logs ausgelesen. Zur Umsetzung dieser maschinellen Auslesung ist die Implementierung einer API notwendig. Eine Liste der bislang identifizierten erforderlichen Kenngrößen ist unter Akzeptanzkriterium 1 zu entwickeln bzw. zu finden. Die Metriken sollen **auf allen Stages** erfasst werden. 1. [ ] Der Zugriff auf diese Endpunkte ist auf einzelne User beschränkt (ggf. Benutzeradministration light notwendig). Es sind nicht die aktuellen SSP User. * [ ] Daten und Verknüpfungen zwischen den Datenobjekten werden als Rohdaten exportiert, damit die Auswertungen und Konsolidierungen im Nachgelagerten Tool erfolgen können * [ ] kein Performanceeinfluss auf den Zustelldienst – Rechenintensive Abfragen sollten separat über z.B. einen Nachtjob laufen und diese Ergebnisse dann bis zum nächsten Nachtjob ausgegeben werden (fachlich führt das dazu, dass es keine Echtzeitdaten gibt) 2. [ ] Die Metriken wurden bewertet und entschieden, welche Metriken schützenswert sind und welche nicht (DSB FITKO) https://git.fitko.de/fit-connect/planning/-/issues/111#note_94177 3. [ ] Die Metriken werden in den entsprechenden Diensten erfasst 4. [ ] Die nicht schützenswerten Metriken werden in einem zentralen öffentlich zugänglichen Dashboard und dahinter liegenden APIs zur Verfügung gestellt 5. [ ] Der Zugriff auf das öffentliche Dashboard und die dahinterliegenden APIs beeinträchtigt den Regelbetrieb der FIT-Connect Infrastruktur nicht. 6. [ ] Daten können exportiert werden in Excel- und/oder PDF-Format 7. [ ] Daten können mindestens 1x die Woche exportiert werden (Optimal Verhalten per Knopfdruck zu jeder Zeit) 8. [ ] Daten stellen den aktuellen Stand von der Minute dar 9. [ ] Die Sprachauswahl der SDKs wird per Logs in den Nutzungsstatistiken abgebildet, sodass wir nachvollziehen können, wie viele Anbindungsprojekte Java bzw. .Net nutzen Ablaufplan 1. Log-Thema ist abgeschlossen 2. API bauen mit Komponenten aus SSP und Zustelldienst (SDK ist aus dem Header auszulesen, Destinations, ARS, Leika und Antragsgrößen aus den Submissionstatistiken) 3. Anbindungsreporting überarbeiten, sodass die neuen Daten eingearbeitet werden Erste Ideen, welche in der ersten Evaluierungsphase aufgekommen sind: - Wir loggen den User-Agent header. Daraus kann man zumindest ein bisschen was ableiten. Außerdem speichern wir für welche Leistungen Anträge an welche Fachverfahren verschickt werden (+Fachdaten/Attachmentgrößen). --\> Log im Traefik  -  ## Ziel <!-- Erläutern Sie den Wert dieser Anforderung in Form einer User Story. --> Nutzungsstatistiken sollen auch der Öffentlichkeit maschinenlesbar, als auch in Form von Standardreports bereitgestellt werden. In dem Zusammenhang sollen auch historische Daten auf Basis von Logs entsprechend intern oder extern auswertbar gemacht werden.  ## Links, Hinweise, Bemerkungen <!-- Sammlung von Hinweisen, die beim Schreiben / Implementieren hilfreich sind. --> ## Stories <!-- - Jede Story ist eindeutig einem Team zugeordnet. - Die Reihenfolge der Stories ist entscheidend. - Die chronologische Reihenfolge sollte im Epic ersichtlich sein. - Fügen Sie ein Quality Gate ein, um den Zwischenstand zu sichern - Stories erst nach QG fertig! --> ## Akzeptanzkriterien 1. [ ] ... 1. [ ] ... 1. [ ] ... 1. [ ] [Definition of Done](https://wiki.fit-connect.fitko.dev/de/Allgemeines/Teamvereinbarung#definition-of-done-dod) wurde überprüft. ## Mögliche Folgeaktivitäten <!-- - Alle Maßnahmen, die nach der PO-Genehmigung der Stories zu ergreifen sind. - Maßnahmen für zukünftige Epics/Stories identifizieren. - Erstellen Sie Stories nicht zu früh/übereilt - Verwendung/ Abgrenzung für "Tailoring" Epics --> ## Offene Fragen <!-- -Jeder kann Fragen eingeben (besonders nützlich vor der Verfeinerung) - PO differenziert und leitet die Ergebnisse an die Arbeitsgruppen weiter -->