Menüpunkt "OZG Überblick"
OZG-Umsetzungsprojekte
Das OZG ist in meherere "Granularitätsstufen" unterteilt:
OZG-Leistungen
Leika-Leistungen
Menüpunkt "Kommunen in NRW"
Datennutzung per API
Man muss zwischen Anwendungsfehlern (Code >= 500) und HTTP-Fehlern (Code >= 400) unterscheiden. Fehlermeldungen mit Code 4xx sind keine Fehler in der Programmierung, sondern dienen als Information, das bei der Anfrage etwas nicht gestimmt hat. Der Hauptzweck der API ist die automatische Verarbeitung der Daten durch externe Anwendungen. Daher sind hier Fehlermeldungen bei ungültigen Aufrufen notwendig, damit die externen Anwendungen diese falschen Aufrufe erkennen können und per Exception-Handling verarbeiten können. Die Seite https://ozg.kdn.de/api dient der Dokumentation der vorhandenen Aufrufe.
Bei Aktivierung der Checkbox "Send Empty value" wird die API mit page=0 (identisch mit "page=") aufgerufen. Diese Seite gibt es nicht, da die Seiten bei 1 anfangen. Der Sinn der Fehlermeldung ist, die aufrufende Anwendung über einen falschen Aufruf ("Bad Request") zu informieren.
Die Angaben für die Seitenanzahl stehen in den Ergebnissen ("hydra:first", "hydra:last"). Gemäß der Spezifikation der Hydra RESTful API Description Languages des W3C: https://www.hydra-cg.com/spec/latest/core/ Eine Paginierung in der REST-API zu haben gehört generell zu den Best-Practices für die API-Implementierung. Die API-Aufrufe für die Listen können ggfs. mehrere Tausend Datensätze beinhalten. Bei einem Aufruf ohne Paginierung müssten diese dann alle auf einmal zurückgegeben werden. Das würde sowohl beim OZG-Server als auch auf dem externen Server (bei einem Datenimport) für eine sehr hohe Speicher- und Prozessorauslastung bei dem Aufruf ohne Paginierung führen.
Beim Dynamic Content Loading ist die Paginierung zwingend notwendig, wenn die Daten direkt von der API in ein CMS eingebunden werden sollen und nicht in lokale Datenbanken importiert werden.
Beim nachladen der nächsten Datensätze muss es dann eine Möglichkeit geben, die zu ladenden Datensätze in der API einzuschränken. Dafür ist der page-Parameter gedacht.
Auch wenn die API-Daten in ein anderes System importiert werden sollen, muss für den Import nur eine Schleife verwendet werden, die alle Seiten durchläuft. Dafür sind nur wenige Zeilen Code notwendig.
Um die Flexibilität der API zu erhöhen, ist der zusätzliche Parameter "itemsPerPage" eingefügt, damit man die Anzahl der pro Seite geladenen Datensätze steuern kann.
Der Wert ist auf maximal 100 Einträge pro Seite beschränkt, um eine zu hohe Serverauslastung zu vermeiden. Der Standardwert ist unverändert 25. https://ozg.kdn.de/api/implementation_projects.json?page=1&itemsPerPage=100
Wir danken unserem Kollegen aus Gelsenkirchen für Input zu diesem Kapitel.
Daten-Pflege
Log-in (im Prinzip nicht notwendig, da wir Open Data liefern)Kontakte
Im passwortgescützten Bereich hinterlegen wir zu Projekten und Lösungen Ansprechpersonen, um auch in dieser Hinsicht den Überblick zu behalten. Darüber hinaus pflegen wir Mailverteiler auf der Basis dieser Kontakte:
| Öffentlich abonnierbar (nicht mehr in Datenbank, sondern inzwischen im Newsletter-Tool gepflegt) | Manuell hinterlegt aufgrund von Benennung - in der Datenbank gepflegt - im Link hinterlegt sind die Landing Pages für die jeweilige Zielgruppe | Aus Teilnahmen generiert - in der Datenbank gepflegt |
|---|---|---|
Kaskadierende Verteiler (je übergelagerte immer in cc):
| Verteiler der Umsetzungsprojekte (mit jeweiligen Zusammenarbeitsbereichen im KDN-Mitgliederportal) |
Bereitstellung von Lösungen
Weiterentwicklung der Datenbank selbst
Die Anwendung basiert auf Standardsoftware, die sehr gut dokumentiert ist:
Hauptsächlich basiert die Anwendung auf dem Symfony-Framework.
Für das Backend verwenden wir Sonata Admin, hiermit werden die Listen-, Formular- und Detailansichten umgesetzt.
Für die API wird das Framework API-Platform verwendet.