Da wir agil und stufenweise arbeiten, gehen wir in aller Regel zunächst mit einer fachlich abgenommenen Minimalversion auf unseren technisch soliden Infrastrukturen in Betrieb und bauen diese dann sukzessive gemäß der Priorisierungen der Projektgruppen aus.

Die Pilotierung übernehmen diejenigen Kommunen, die den Dienst auch selbst mit ausgewählt und gestaltet haben in den gemeinsamen Projektteams. Wir suchen in vielen Projekten noch kommunale Beteiligung und Sie können sich bei Interesse gern bei den jeweils angegebenen Themenfeldkoordinator*innen im KDN-Kompetenzzentrum Digitalisierung melden, um einen Dienst frühzeitig zu nutzen: https://mitgliederportal.kdn.de/pages/viewpage.action?pageId=23858255

"EfA" ist die Abkürzung für "Einer für Alle" und bedeutet: bundesweite Lösung.

Das OZG ist in meherere "Granularitätsstufen" unterteilt:

Die Projekte setzen in der Regel mehrere Leika-Leistungen um. Diese sind allerdings nicht alle gleich hoch priorisiert.

Phasen bei EfA-Nachnutzungen aus einem anderen Bundesland in unserer Datenbank:

• Vorbereitung = NRW trommelt erste interessierte Kommunen etc. zusammen
• Konzeption = NRW screent die (ersten) Ergebnisse aus dem EfA-Projekt des Federführenden Bundeslandes
• Umsetzung = NRW veranlasst nötigenfalls Anpassungen des Dienstes

Die Daten der Liste https://ozg.kdn.de/ozg-leistungen stammen von d-NRW, die sie, aufbereitet mit NRW-spezifischen Zuständigkeitsinformationen, von der bundesweiten Plattform https://informationsplattform.ozg-umsetzung.de/iNG/app/ erhalten. Aufgrund der NRW- und kommunal-spezifischen Aufbereitung kann es in Einzelfällen zu Zeitverzögerungen und Differenzen zur bundesweiten Plattform kommen.

Für die Kommunen in NRW kann unsere offene Datenbank als führende Informationsquelle zur Umsetzung des OZG gelten.

Die Prioritäten haben wir in einer NRW-weiten Workshopreihe initial bestimmt:

https://mitgliederportal.kdn.de/display/ONK/Informationsveranstaltungen+OZG+NRW+kommunal+-+Dokumentation und https://mitgliederportal.kdn.de/display/ONK/Themenfelder#category:42

In den Umsetzungs-Projektgruppen haben wir die Prioritäten dann weiter verfeinert.

Hier eine Erläuterung:

Die Daten zu Leika-Einzelleistungen beziehen wir teilweise automatisiert über die APIs vom Portalverbund.NRW: https://ozg.kdn.de/verwaltungssuchmaschine

Wir reichern sie an mit Informationen zur kommunalen OZG-Umsetzung in NRW.

Für eine Liste der Leistungen, die Ihre Kommune im OZG umsetzen muss, geben Sie Ihre Kommune hier ein: https://ozg.kdn.de/kommunen

Erklär-Video: https://youtu.be/52QBPdx68Mo

Es ist also eine grobe Zuordnung aufgrund der kommunalen Größenklassen. Wenn Sie da Korrekturen haben, können Sie uns diese SEHR gerne melden !

Sie können sich der offenen Schnittstellen unserer offenen Datenbank bedienen. Diese enthalten alle öffentlich zugänglichen Daten: https://ozg.kdn.de/api

Erklär-Video: https://youtu.be/qEXxDe-fEY0

Einer unserer Nutzer hat uns als kleiner Einstieg in Excel/PowerQuery mit der API/Datenabfrage folgende Videos empfohlen, um bisschen mit der API in Excel zu spielen. Es handelt sich um externe Inhalte, die der KDN nicht verantwortet und geprüft hat.

• Teil 1: https://www.youtube.com/watch?v=hEI5xckBKs8
• Teil 2: https://www.youtube.com/watch?v=npzG-Br0GQs
• Teil 3 (Wichtig für die API!) https://www.youtube.com/watch?v=frKiyotmJzY
• Teil 4: https://www.youtube.com/watch?v=mPxDwZTKU_0
• Teil 5: https://www.youtube.com/watch?v=NY3m_nLGuTg
• Teil 6: https://www.youtube.com/watch?v=c3cchCZscjo

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

Man kann die API in Excel nicht nur via „Schleife“ einbinden, sondern wie hier im Video https://www.youtube.com/watch?v=STjBoS1rQuQ in Form von Tabellen mit den Links zur API.

Mag nicht so super professionell wirken, hat aber den Vorteil, dass auch nicht Excel-Experten das Anzapfen der Daten gut nachvollziehen können. Die Überschriften der angezapften Daten sind unterschiedlich bspw. Column1.serviceKey entspricht der OZG-ID. Wenn nicht alle Spalten benötigt werden, kann man nur jene Spalten eingetragen, die auch aktiv genutzt werden.

Um Daten der Datenbank zu konsumieren, also zu nutzen, benötigen Sie kein Log-in: Es ist Open Data!

Das heißt: Wir stellen Daten zur Digitalisierung der Kommunen in NRW kostenfrei, strukturiert, exportierbar und sogar per API zur Verfügung.

Die Anmelde-Funktion dient lediglich folgenden Zwecken:

• Schutz personenbezogener Daten, in unserem Fall: Projektkontakte
• Aktiver Eingabe von Daten

Wenn Sie als Kommune Daten selbst pflegen möchten, also zum Beispiel Dienste eintragen, dann kommen Sie zunächst in eine unserer offenen Austauschrunden zur Datenbank, um sich mit dem Tool vertraut zu machen. Anschließend können Sie uns kontaktieren, um einen kostenfreien Zugriff zu erhalten.

unter https://data-warehouse.kdn.de/admin/login

Rechts oben auf Mein Profil klicken und ein neues "Klartextpasswort" eingeben.

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:

Der Code ist nachvollziehbar und offen auf https://github.com/kdn-nrw/ozg

Bisher waren noch keine Änderungen an der Datenstruktur notwendig, daher gibt es bisher keine Versionierung.
Seit der Einrichtung der API wurde nichts mehr verändert, abgesehen von Beschreibungstexten für Swagger (https://ozg.kdn.de/api).

Die Datenstruktur ist grundsätzlich stabil und wird sich sehr wahrscheinlich nicht mehr stark verändern.
Falls doch grundlegende Änderungen notwendig sein sollten, würden wir Versionierung implementieren.

Wahrscheinlicher ist allerdings, dass nur einzelne Felder bzw. Eigenschaften entfallen oder geändert werden.
Für diesen Fall würden die alten Felder nicht entfernt, sondern als "Deprecated" markiert:
https://api-platform.com/docs/core/deprecations/

Falls wir Versionierung einführen, würde die jetzige Version weiterhin unter der bestehenden URL zugreifbar bleiben, die neuen API-Aufrufe wären dann unter neuen URLs zugreifbar.
D.h. die API wird auf jeden Fall rückwärtskompatibel bleiben.

Melden Sie sich an zu unseren regelmäßigen Austauschterminen zur Nutzung der offenen Datenbank des KDN, OZG-Steuerung und -Lösungsaustausch: https://www.kdn.de/veranstaltungen/termine/