Übernahme Landesredaktions-Schemata

Warum machen wir das?

Als Anwender des FIM-Sammelrepository

möchte ich, dass die Daten alles Landesrepositories, die bisher über die FIM-Portal-Schnittstelle bezogen wurden, im FIM-Sammelrepository enthalten sind,

sodass ein API-Zugriff auf diese Daten möglich sein wird (bisher nur manuell über das FIM-Portal).

Relevante Informationen

• Quelle für Adressen der Landesrepository-Daten ist eine Datei source.txt
• Die verlinkten Codelisten (Genericode-Dateien) können vom bereitstellenden Redaktionssystem mehrfach in der JSON-Datei enthalten sein; das führt im FIM-Portal zu einer Liste von verlinkten Codelisten, die Dubletten enthält. Beispiel für S00000221V1.0
• Die verlinkten Codelisten sind dem Namen nach identisch für verschiedene Datenschemata. Beispiel: C60000031_genericode.xml für S00000221V1.0 und für S00000205V1.3. Arbeitsannahme: Dann hat das Landesredaktionssystem, in dessen Schema-Beschreibungen diese Codelisten verwendet werden, diese Codelisten nur einmal für verschiedene Schemata definiert, so dass Mehrfachablage der Codelisten im FIM-Sammelrepository nicht nötig ist.
• Die JSON-Dateien, welche für die FIM-Portal-Schnittstelle von den Landesredaktionssystemen bereitgestellt werden, werden lediglich für Dokumentsteckbriefe und Schemata im Status "Veröffentlicht" erstellt.
• Nicht alle Landesredaktionen veröffentlichen ihre Daten; zurzeit sind es gemäß obiger source.txt nur folgende acht Bundesländer sowie Bundesredaktion und Phönix (17)
  • 00 FIM Datenfelder Bundesredaktion
  • 03 Landesredaktion Niedersachsen
  • 05 Landesredaktion NRW
  • 06 Landesredaktion Hessen
  • 07 Landesredaktion Rheinland-Pfalz
  • 09 Landesredaktion Bayern
  • 12 Landesredaktion Brandenburg
  • 13 Landesredaktion Mecklenburg-Vorpommern
  • 16 Landesredaktion Thüringen
  • 17 Temporäres FIM-System im Rahmen der OZG-Umsetzung
• Das Projekt hat entschieden, die Dateien im Originalformat in der Datenbank vorzuhalten und über Metadaten ("allgemeine Angaben" in der XDatenfelder-3-Spezifikation) zugänglich zu machen. Der Parser, der für diese User Story benötigt wird, kann daher auf die Metadaten beschränkt werden. In einer späteren Projektphase werden die Datei-Inhalte ebenfalls geparsed und so für eine Prüfung, Qualitätskontrolle und Suchfunktionen zugänglich.
• Diese User Story beschränkt sich auf die Speicherung; die Suche über API und Web-GUI ist Gegenstand anderer User Stories.

Akzeptanzkriterien

1. Automatisierter Import der Datenschemata und Codelisten aus den Landesrepos.
2. Speichern der Schemata und Codelisten im Originaltext in der Datendank fuer einen spaeteren Export.
3. Automatisierte Tests