Zum Hauptinhalt springen
Version

1.0.0

Versionierung von Onlinedienst Produkten

Einführung​

Der EfA-Onlinedienst kann durch die Fachbehörde mittels regionaler Parameter konfiguriert werden. Es ist davon auszugehen, dass sich der Bedarf an regionalen Parametern im Laufe der Zeit mit der Weiterentwicklung des Onlinedienstes verändern wird. So können neue Attribute hinzukommen oder bestehende entfernt werden. Außerdem kann es vorkommen, dass Parameter, die früher zwingend zur Konfiguration des EfA-Onlinedienstes zu befüllen waren, nach einer Umstellung, nur optional zu befüllen sind. Auch ist denkbar, dass Parameter, die früher optional waren, nun als Pflichtparameter zu befüllen sind. Ebenfalls bedacht werden muss, dass sich die Ausprägung von Parametern ändern kann, wobei dies auch unabhängig von der Weiterentwicklung des Onlinedienstes geschehen kann.

Sämtliche Änderungen bei Parametern müssen sowohl beim EfA-Onlinedienst selbst als auch potenziell in den zugehörigen Fachverfahren von Kommunen und Ländern berücksichtigt werden. Jede Version des Onlinedienstes hat ein spezifisches Set an Parametrisierungsbedarfen. Unterscheiden sich diese Sets von Onlinedienst Version zu Onlinedienst Version, so kann man auch hier von Versionen der Parametrisierungsbedarfen sprechen. Insbesondere dann, wenn mit einer neuen Version des Onlinedienstes zusätzliche Parameter zwingend konfiguriert werden müssen, oder zuvor optionale Parameter nun zwingend konfiguriert werden müssen, kann die neue Version des Onlinedienstes nur dann für eine Leistung in einem Gebiet genutzt werden, wenn auch das Set der konkreten Parameterwerte überprüft und ggf. angepasst wird.

Während es in der Regel technisch einfach möglich ist, eine neue Version eines EfA-Dienstes und damit die neue Version der Parametrisierungsbedarfe in einem Schritt produktiv zu setzen, stellt die rechtzeitige Anpassung der konkreten Parameterwerte durch die Fachbehörden und Datenredaktionen häufig eine Herausforderung dar. (Dies betrifft sowohl Kommunen als auch Länder). Einige Fachbehörden werden und können ihr Fachverfahren schnell anpassen und schnell das angepasste Parameterset liefern. Andere Fachbehörden benötigen für die gleiche Anpassung mehr Zeit. Zudem kann es sinnvoll sein, die neue Version des Onlinedienstes mit dem neuen Parameterset bei einigen Behörden zu erproben und erst nach erfolgreicher Pilotierung die neue Onlinedienst Version und das angepasste Parameterset bundesweit einzuführen.

Die unterschiedliche Umsetzungsgeschwindigkeit (EfA-Onlinedienst, Fachbehörden) wird in der Verwendung verschiedener Parameterset-Versionen resultieren. Es ist zu klären, welche Auswirkungen dies hat und wie damit umzugehen ist.

Neben der Versionierung der Parameter, der Parametrisierungsbedarfe und der konkreten Parameterwerte, die über die Redaktionssysteme im PVOG eingepflegt und von den Onlinediensten dort ausgelesen werden, ist auch die Änderung der Antragsdatenformate zu betrachten. Eine neue Onlinedienst Version kann ggf. die Antragsdaten in einem geänderten Format an das Fachverfahren übermitteln. Dies kann z.B. notwendig sein, wenn sich rechtliche Rahmenbedingungen geändert haben, wenn zusätzliche Informationen für die Antragsbearbeitung notwendig werden oder Informationsbedarfe der Behörde entfallen. Das Fachverfahren muss dann ebenfalls angepasst werden, wenn eine neue Onlinedienst Version produktiv geschaltet wird, so dass es das neue Antragsdatenformat verarbeiten kann.

Diese Änderungen haben streng genommen nichts mit dem Thema der Parametrisierung zu tun, weil das Antragdatenformat kein Parameter ist, sind aber ebenfalls im Kontext eines Onlinedienst Versionswechsel relevant und die daraus erwachsenden Probleme der Inkompatibilität zwischen Onlinedienst und Fachverfahren können mit ähnlichen Maßnahmen behandelt werden. Der Themenkreis Änderung von Antragsdatenformaten soll daher in diesem Dokument ebenfalls diskutiert werden.

Rahmenbedingungen​

Folgende Rahmenbedingungen gelten für die Umsetzung der EfA-Parametrisierung und müssen berücksichtigt werden:

  • Der EfA-Onlinedienst kann nach dem Prinzip der Software-as-a-Service nicht spezifisch für jede Fachbehörde bzw. Kommune betrieben werden. Jeder Versionswechsel betrifft – ohne besondere Maßnahmen – alle nutzenden Organisationseinheiten und alle angeschlossenen Fachverfahren.
  • Verschiedene Versionen eines EfA-Onlinedienstes können parallel betrieben werden. Dabei steuert die Konfiguration der Zuständigkeit in den Landesportalen, welche Version welchen Onlinedienstes für welche Leistung in welchem Gebiet genutzt werden soll. Diese Zuständigkeits-information steht über das PVOG allen Landesportalen und auch den Onlinediensten selbst zur Verfügung. XZuFi 2.2 bietet für diese Steuerung aber nur einen Mechanismus, der sich auf die URL des Onlinedienstes fokussiert, d.h. explizite Bezeichnungen des Softwareprodukts Onlinedienst oder die Version des Softwareprodukts sind im Standard nicht enthalten. Hinweis: Das Element Versionsinformation innerhalb des Datenobjekts Onlinedienst in XZuFi 2.2 bezieht sich auf das Datenobjekt Onlinedienst, dessen Inhalte das Softwareprodukt Onlinedienst beschreiben und steuern. Eine Änderung der Versionsinformation bedeutet, dass sich die Beschreibung oder Steuerung geändert hat, nicht, dass sich das Softwareprodukt geändert hat. Es ist zu erwarten, dass die Redaktionssysteme diese Versionsinformation automatisch aktualisieren wann immer ein Redakteur eine Änderung der Inhalte des Datenobjekts durchführt. Die Versionsinformation ist damit nicht geeignet, die Version des Softwareprodukts zu beschreiben.
  • Der Hersteller bzw. Betreiber eines EfA-Onlinedienstes gibt über die Versionenfolge vor, welche unterschiedlichen Sets es gibt und kommuniziert an die Betreiber der zuständigen Behörden und Fachverfahren, wann spätestens die neuen Parametersets zu berücksichtigen sind. Dabei müssen angemessene Übergangsfristen gewährt werden.
  • Die Systeme, die zur Pflege und Ermittlung von Parametern verwendet werden wie z.B. die Redaktionssysteme, das PVOG aber auch das DVDV sind in der Lage, eine Vielzahl von Parametern unterschiedlicher Arten zu verwalten. Onlinedienste benötigen davon nur einen Ausschnitt. Eingepflegte Parameterwerte, die von einem betrachteten Onlinedienst nicht benötigt werden, werden von diesem ohne negative Auswirkungen ignoriert. Insbesondere stellt der Onlinedienst keine Fehlersituation fest, wenn ein ihm unbekannter zusätzlicher Parameter (Schlüssel und Wert) gemeldet wird .
  • Das Datenmodell von XZuFi erlaubt es, alle relevanten Datenobjekte und in einigen Fällen auch ihre Teilobjekte mit einer Gültigkeit zu attributieren. Das PVOG als zentrales Auskunftssystem für Onlinedienst Parameter berücksichtigt diese Gültigkeit bei der Beauskunftung oder gibt die Gültigkeitsinformation an den Onlinedienst weiter, so dass dieser sie auswerten und beachten kann. Dieser Mechanismus kann genutzt werden, um mehrere Sets von Parameterwerten im PVOG parallel aufzubauen und zu halten, wobei immer nur ein Set für eine Leistung und ein ARS gültig und damit effektiv wirksam sein darf. Bei geeigneter Konfiguration der Gültigkeits-Attribute kann eine Umschaltung zwischen den Parameter-Sets ohne aktiven Eingriff zum Umschaltzeitpunkt erfolgen.

Anforderungen​

Es sollen Verfahren und Vorgehensweisen definiert werden, die es erlauben, Onlinedienste fachlich und technisch weiterzuentwickeln und produktiv zu setzen, ohne dass alle nutzenden Fachbehörden und Datenredaktionen zeitgleich Ihre Fachverfahren und die von ihnen gepflegten Parameterwerte anpassen müssen.

Diese Verfahren und Vorgehensweisen sollen sich auf die vorhandenen Prozesse und Infrastrukturen wie z.B. die FIM-Redaktionssysteme und das PVOG zusammen mit den zugrunde liegenden Möglichkeiten des XZuFi-Standards abstützen.

Unkritische Änderungsszenarien​

Die Weiterentwicklung des Onlinedienstes kann in vielen Fällen als unkritisch betrachtet werden und erfordert dann keinerlei besondere Vorgehensweisen bei der Produktivsetzung. Diese Fälle sind wie folgt charakterisiert:

  • Der Onlinedienst unterstützt eine neue Steuerungsmöglichkeit, die durch einen neuen Parameter gesteuert wird. Die Konfiguration des Parameterwertes ist optional und der Onlinedienst verwendet eine in allen Fällen sichere Voreinstellung (Default-Wert), falls kein Parameterwert konfiguriert ist.
  • Der Onlinedienst unterstützt eine neue Steuerungsmöglichkeit durch einen erweiterten zulässigen Wertebereich für einen bereits in der Vorversion des Onlinedienstes berücksichtigten Parameter. Ein Beispiel ist die neu hinzugekommene Unterstützung der Schulform Stadtteilschule in einem Dienst zur „Anmeldung an einer weiterführenden Schule“. Die bisher zulässigen Werte Gesamtschule, Realschule und Gymnasium werden unverändert weiterhin vom Onlinedienst verarbeitet.
  • Eine bereits bisher bestehende Steuerungsmöglichkeit, deren Parameter zwingend angegeben werden musste, besteht unverändert weiterhin in der neuen Onlinedienst Version, braucht aber nicht mehr zwingend konfiguriert zu werden, weil der Onlinedienst nun eine Voreinstellung (Default-Wert) berücksichtigt, wenn kein Wert konfiguriert ist. Das heißt der bisher verpflichtende Parameter wird zu einem optionalen Parameter. Hinweis: Die Voreinstellung muss nicht für alle Fälle fachlich sicher sein, da die bisherigen Nutzer des Onlinedienstes ja in der Vergangenheit einen für ihren Fall korrekten Parameterwert konfigurieren mussten.
  • Eine bisher bestehende Steuerungsmöglichkeit entfällt und der bisher dafür ausgewertete Parameter wird durch die neue Version des Onlinedienstes ignoriert. Das neue, nun nicht mehr in diesem Aspekt steuerbare Verhalten des Onlinedienstes ist für alle Nutzer fachlich korrekt. Ein Beispiel für diesen Fall ist der vollständige Entfall einer Frage nach dem Geburtsdatum des Antragstellers, wenn in der alten Version des Onlinedienstes diese Frage regional aktiviert oder ausgeblendet werden konnte und nun aufgrund geänderter rechtlicher Anforderungen diese Frage in keiner Region mehr gestellt werden soll.

Bezüglich des Themenkreises Änderung von Antragsdatenformaten gibt es hingegen nur wenige unkritische Arten von Änderungen, auch weil die Übertragung der Antragsdaten in der Regel in Form von XML-Dokumenten erfolgt, die einem strengen XML-Schema entsprechen müssen :

  • Ein bisher optionales Element in den Antragsdaten wird durch die neue Onlinedienst Version als verpflichtend behandelt, und daher immer gefüllt.
  • Weitere Randfälle von Antragsdatenformatänderungen sind ggf. denkbar, die ebenfalls als unkritisch betrachtet werden können. Diese sind aber nur durch individuelle Analysen des Zusammenspiels zwischen Onlinedienst, Antragsdatenformaten und dem Fachverfahren bzw. der Geschäftslogik des Fachverfahrens zu identifizieren.

Kritische Änderungsszenarien​

Im Gegensatz zu den unkritischen Änderungsszenarien des vorangegangenen Abschnitts erfordern die folgenden Szenarien eine besondere Vorgehensweise bei der Produktivsetzung einer neuen Onlinedienst Version. Wie später diskutiert wird, können aber alle diese Szenarien mit derselben Vorgehensweise bewältigt werden.

  • Der Onlinedienst unterstützt eine neue Steuerungsmöglichkeit, die durch einen neuen Parameter gesteuert wird. Die Konfiguration des Parameterwertes ist verpflichtend.
  • Der Onlinedienst schränkt eine bestehende Steuerungsmöglichkeit ein, indem er den zulässigen Wertebereich für einen bereits in der Vorversion des Onlinedienstes berücksichtigten Parameter einschränkt. Trifft die neue Onlinedienst Version auf einen nun nicht mehr zulässigen Wert, bricht er mit einer Fehlermeldung ab. Ein Beispiel ist die entfallende Unterstützung der Schulform Hauptschule in einem Dienst zur „Anmeldung an einer weiterführenden Schule“, wenn der Onlinedienst die Anmeldung an dieser Schulart nicht mehr unterstützt.
  • Eine bereits bisher bestehende Steuerungsmöglichkeit, deren Parameter optional angegeben werden musste, besteht unverändert weiterhin in der neuen Onlinedienst Version, muss nun aber zwingend konfiguriert werden. Das heißt der bisher optionale Parameter wird zu einem verpflichtenden Parameter.
  • Eine bereits bisher bestehende Steuerungsmöglichkeit ändert ihre Bedeutung auf eine Art und Weise, die nicht für alle Nutzer fachlich sicher ist, d.h. die Wirkung, die die verschiedenen Parameterwerte auf die Geschäftslogik des Onlinedienstes haben, ändert sich. Dabei kann es geschehen, dass die neue Onlinedienst Version sich bei unverändert konfiguriertem Parameter-Wert nun nicht mehr fachlich korrekt verhält. Beispiel: die alte Onlinedienst Version nutzt die parametrisierbare Angabe Bearbeitungsdauer, um dem Antragsteller eine unverbindliche Auskunft über die zu erwartende Bearbeitungsdauer zu geben. Die neue Onlinedienst Version nutzt denselben Parameter, um eine rechtsverbindliche Garantie zur maximalen Bearbeitungsdauer zu geben, deren Überschreitung dem Antragsteller gegenüber der Behörde einen Regressanspruch eröffnet. Die Behörde darf die neue Onlinedienst Version nicht nutzen, ohne das Parameterset (in diesem Fall den Parameter Bearbeitungsdauer) geprüft und ggf. angepasst zu haben. Diese Art der Änderungen sind besonders kritisch, da durch den Onlinedienst nicht ohne weiteres geprüft werden kann, ob das Parameterset geprüft und ggf. angepasst wurde. Sie verlangen daher nach besonderer Sorgfalt bei der Migration von einer Onlinedienst Version zur nächsten.

Wie im Abschnitt zu unkritischen Änderungsszenarien bereits beschrieben muss Im Zweifelsfall davon ausgegangen werden, dass eine Anpassung des Fachverfahrens notwendig ist, wann immer sich das Antragsdatenformat ändert. Das heißt, dass jede Antragsdatenformatänderung ein kritisches Änderungsszenario ist. Die wenigen Ausnahmen sind in Abschnitt zu unkritischen Änderungsszenarien beschrieben.

Ausführungsszenarien für Onlinedienst Versionen​

Aufgrund der in oben dargestellten Rahmenbedingungen ist es notwendig, mehrere Versionen eines Onlinedienstes parallel zu betreiben, falls die neuere Version kkritische Änderungen gegenüber der älteren Version enthält.

Dieser Parallelbetrieb erlaubt es, dass für ein Gebiet A bereits die neue Version des Onlinedienstes produktiv eingesetzt wird, die durch ein aktualisiertes Set von Parameterwerten gesteuert wird und/oder die Antragsdaten in einem neuen Format an das Fachverfahren sendet, das auch bereits für die Verarbeitung dieses neuen Formats ertüchtigt worden ist. Gleichzeitig muss für ein Gebiet B noch die alte Version des Onlinedienstes produktiv eingesetzt werden, weil das Set von Parameterwerten noch nicht aktualisiert werden konnte und/oder das Fachverfahren noch nicht ertüchtigt werden konnte, das neue Format der Antragsdaten zu verarbeiten.

Datenstände in Landesportalen und PVOG für den Parallelbetrieb​

Dieser Parallelbetrieb für die Gebiete A und B wird dadurch operativ gesteuert, indem im Landesportal und damit im PVOG zwei getrennte Datenobjekte vom XZuFi-Typ Onlinedienst angelegt werden. Eines dieser Datenobjekte – nennen wir es „OD-A“ – enthält ein Element zustaendigkeit, das die Zuständigkeit für das Gebiet A signalisiert und ein Element link, das eine URL auf die neue Onlinedienst Version enthält. Das zweite Datenobjekt („OD-B“) enthält entsprechend ein Element zustaendigkeit, das die Zuständigkeit für das Gebiet B signalisiert und ein Element link, das eine URL auf die alte Onlinedienst Version enthält.

OD-A enthält weiterhin Parameter und deren konkrete Werte, die die Parametrisierungsbedarfe der neuen Onlinedienst Version befriedigen. Weiterhin enthalten auch anderer Datenobjekte wie z.B. die relevante Leistungsbeschreibung und die Datenobjekte, die die zuständige Organisationseinheit für Gebiet A beschreiben, alle Parameter und deren Werte, die die Parametrisierungsbedarfe der neuen Onlinedienst Version befriedigen. Informell kann man sagen, dass „das Parameter-Set für die neue Onlinedienst Version in einer dazu passenden Parameter-Set-Version im Landesportal und PVOG für das Gebiet A vorhanden ist“.

Analog enthalten OD-B und die relevanten Datenobjekte der relevanten Leistungsbeschreibung und der zuständigen Organisationseinheit Parameter und deren konkrete Werte, die die Parametrisierungsbedarfe der alten Onlinedienst Version befriedigen.

Im Regelfall wird nun ein Antragsteller das Landesportal oder den Web-Suchdienst des PVOG benutzen, um den für ihn passenden Onlinedienst aufrufen zu können. Sucht er nach dem Onlinedienst für das Gebiet A, so wird das Portal bzw. der Web-Suchdienst des PVOG ihn über die in OD-A hinterlegte URL zur neuen Version des Onlinedienstes weiterleiten. Dabei fügt das Portal bzw. der Web-Suchdienst die Information "Gebiet A" in Form eines dynamischen URL-Parameters hinzu, so dass der neue Onlinedienst „weiß“, dass er den Antragsprozess für Gebiet A durchführen soll. Die neue Version des Onlinedienstes wird das benötigte Set von Parametern aus dem PVOG ermitteln, wobei die Angabe „Gebiet A“ ein Teil des Suchschlüssels ist und somit das passende Parameter-Set liefert.

Analog wird im Regelfall das Portal oder der Web-Suchdienst die alte Version des Onlinedienstes über die URL in OD-B mit der Information „Gebiet B“ aufrufen, wenn der Antragsteller das Gebiet B bei seiner Recherche gewählt hat. Der alte Onlinedienst wird entsprechend das alte Parameter-Set für Gebiet B im PVOG suchen und finden.

Fehlerpotenziale durch veraltete und manipulierte URLs​

Onlinedienste lassen sich nicht nur durch die Landesportale oder den Web-Suchdienst des PVOG finden und aufrufen. Jeder Link, der ggf. in einer alten Mail kommuniziert wurde oder noch auf einer manuell erstellten und schlecht gewarteten Webseite zu finden ist, kann zum Aufruf eines Onlinedienstes führen, ohne dass die betreffende Onlinedienst Version noch für das Gebiet, das als URL-Parameter mit signalisiert wird, zuständig ist. Es ist sogar denkbar, dass durch einfache Manipulation der URL-Parameter eine neue Onlinedienst Version für ein Gebiet aufgerufen wird, für das noch die alte Onlinedienst Version verwendet werden muss, weil das Parameter-Set oder das Fachverfahren noch nicht aktualisiert worden sind. Ohne zusätzliche Maßnahmen würde der Onlinedienst auf eine Fehlersituation laufen, weil z.B. ein neu verpflichtend zu konfigurierender Parameter nicht konfiguriert ist. Im ungünstigsten Fall würden subtile fachliche Fehler auftreten, wenn Parameterwerte falsch interpretiert werden, weil sich ihre Bedeutung geändert hat oder Antragsdaten können nicht durch das Fachverfahren verarbeitet werden, weil die genutzte Onlinedienst Version ein Antragsdatenformat erzeugt, das noch nicht oder nicht mehr vom Fachverfahren in dem gewünschten Gebiet unterstützt wird.

Es sind sogar Fehlerszenarien denkbar, bei denen ein gänzlich anderer Onlinedienst aufgerufen wird: Gesetzt den Fall, dass in einem Bundesland für die Beantragung einer bestimmten Leistung in der Vergangenheit ein Onlinedienst des Herstellers X verwendet wurde, nun aber Kommune für Kommune einen gänzlich anderen Onlinedienst des Herstellers Y verwenden sollen, weil nur dieser neue Anforderungen erfüllen kann. Seien weiterhin die Parametrisierungsanforderungen der beiden Onlinedienst Varianten so unterschiedlich, dass ein Wechsel der produktiven Onlinedienst Variante eine vorherige Änderung des konfigurierten Parameter-Sets notwendig macht. Auch hier kann ein alter Link, der noch auf die Onlinedienst des Herstellers X für ein Gebiet A verweist, zu Fehlern führen, wenn in diesem Gebiet A bereits das Parameter-Set für den Onlinedienst des Herstellers Y konfiguriert wurde. Da die Hersteller X und Y ihre Onlinedienste unabhängig voneinander versionieren, können im ungünstigsten Fall die beiden Onlinedienst Varianten dieselbe Onlinedienst Versionsbezeichnung tragen. Warum dies zunächst ein weiteres Problem darstellt und wie es durch zusätzliche Maßnahmen gelöst werden kann, wird im Folgenden beschrieben.

Maßnahmen zur Fehlererkennung und Mitigation​

Ein Onlinedienst muss aus den oben genannten Gründen überprüfen, ob er in seiner Version für das Gebiet als der produktiv zuständige Onlinedienst vorgesehen ist. Dazu soll zunächst per Konvention ein individueller Parameter mit dem Namens-Schlüssel efa.custom.idOnlinedienstGlobal verwendet werden, solange XZuFi 2.3 noch nicht ausgerollt ist.

info

Weil es ein spezifisches Element für diese Angabe in XZuFi 2.3 geben wird, soll darauf verzichtet werden, den Namens-Schlüssel in die XÖV-Liste urn:xoev-de:fim:codeliste:xzufi.efaparameter aufzunehmen.

Dieser Parameter wird im Folgenden als idOnlinedienstGlobal bezeichnet, auch wenn er in XZuFi 2.2 nicht als Element am Datenobjekt Onlinedienst realisiert ist, sondern als Namens-Schlüssel/Wert-Paar in Form eines individuellen Onlinedienst.parameters.

Mit der Migration zu XZuFi 2.3 wird aus dem per Konvention vereinbarten individuellen Onlinedienst.parameter ein Element Onlinedienst.idOnlinedienstGlobal mit dem Datentyp xzufi:Identifikator. Dieser Identifikator enthält dann neben dem – unveränderten – Wert in Form eines xs:token noch diverse Metadaten zu den Namensschemata etc. Wie diese konkret zu belegen sind, soll hier nicht weiter diskutiert werden.

Der Wert des Parameters idOnlinedienstGlobal besteht aus einer Basis-URN und einer Erweiterung, die die Software-Version angibt. Die BasisURN beginnt immer mit urn: anschließend sollte der sogenannte Namensraum definiert werden, also der Teil der Basis-URN, der definiert, in welchem Kontext die ID eindeutig ist. Der Namensraum sollte von denjenigen definiert werden, die den Onlinedienst bereitstellen. I.d.R. wird dazu eine Domäne verwendet, die dem Bereitsteller des Onlinedienstes eindeutig zugewiesen ist. Wird ein Onlinedienst von einem Bundesland bereitgestellt, bietet es sich an, auf dessen zentrale Domäne zurückzugreifen. Also im Beispiel von Schleswig-Holstein auf schleswig-holstein.de. Eine Basis-URN für einen durch Schleswig-Holstein bereitgestellten Dienst würde folglich mit urn:schleswig-holstein:de: beginnen.

Der darauf folgende Teil muss dann so gewählt werden, dass der Onlinedienst innerhalb aller Onlinedienste des Bereitstellers eindeutig identifiziert werden kann. Dazu sollte i.d.R. die Fachlichkeit vorkommen, bei Bedarf auch der Betreiber, also z. B. urn:schleswig-holstein:de:wohngeld oder urn:schleswig-holstein:de:wohngeld:dataport.

Die Basis-URN identifiziert das Onlinedienst-Produkt, d.h. die Folge von Onlinedienst-Versionen, die durch Weiterentwicklung auseinander hervorgehen und auf die daher eine gemeinschaftliche Versionszählung angewendet wird.

Die Basis-URN soll am Ende durch die Angabe einer Version in der Form :v zu einer URN ergänzt werden, wobei v irgend eine, als Zeichenkette codierte Versionsangabe ist. Die Ergänzung ist optional, d.h. die Basis-URN kann auch ohne Ergänzung als vollständige URN verwendet werden.

Es bestehen nur zwei Anforderungen an die Zeichenkette v:

  • Der Onlinedienst muss die Reihenfolge der Versionen algorithmisch bestimmen können, d.h. er kann erkennen, ob eine vorgefundene Versionangabe kleiner (i.e. älter) oder größer (i.e. jünger) als seine eigene Version ist.
  • v enthält keinen Doppelpunkt („:“), so dass v leicht als das letzte Segment der URN zu isolieren ist.
Best Practice

Die Versionsangabe v sollte sich am Muster des Semantic Versioning orientieren, wobei nur die Angaben major version und minor version getrennt durch einen Punkt (".") geschrieben werden sollten. Beispiel: "2.11"

Im Sinne dieses Versionierungskonzeptes wäre die Angabe der major version bereits ausreichend, da fehlende Rückwärtskompatibilität bezüglich des Parametersets ja bereits zu einer Erhöhung der major version führen sollte. Eine zusätzliche Angabe einer minor version erhöht aber die Robustheit der Lösung.

Idealerweise sollte ein Onlinedienst, wenn er nur eine major version findet für den Vergleich ein ".0" ergänzen. Wenn der Onlinedienst also weiß, dass er ein Parameter-Set für (mindestens) Version "2.0" benötigt und als Versionsangabe nur "2" findet, sollte er fortfahren. Wenn er "1.17" oder nur "1" findet, sollte er den Antragsvorgang abbrechen und als Grund "veraltete Parametrisierung" loggen.

Der Wert der Versionsangabe v identifiziert die Onlinedienst-Version, für die das Parameter-Set in diesem XZuFi-Onlinedienst-Datenobjekt und in allen anderen relevanten Datenobjekten, die der Onlinedienst als Parameterquelle ausliest, angelegt worden ist. Die Versionsangabe bezieht sich damit auch auf Datenobjekte wie Organisationseinheit und Leistung bzw. Leistungsbeschreibung, sofern diese eine Zustaendigkeit haben, die der Zustaendigkeit des Onlinedienst-Datenobjektes entsprechen. Damit ist sichergestellt, dass zwei verschiedene Onlinedienst-Versionen mit identischer Basis-URN immer zwei verschiedene Versionsangaben haben.

Eine höhere (i.e. jüngere) Version eines Onlinedienstes soll in ihrer Geschäftslogik Regeln zur Entscheidung enthalten, ob ein Parameter-Set für eine niedrigere (ältere) Version kompatibel ist. Das ist der Fall, wenn alle Änderungen seit dieser älteren Version unkritische Änderungen sind. Der Parameter idOnlinedienstGlobal wird aus Gründen des Bestandsschutzes als optionaler Parameter betrachtet. Ein Hersteller eines Onlinedienstes kann aber festlegen, dass für sein Onlinedienst-Produkt dieser Parameter stets gefüllt werden muss. Dies vereinfacht die im Folgenden dargestellte Geschäftslogik, mit der jede Onlinedienst-Version diesen Parameter auswerten sollte.

Auswertung des Parameters idOnlinedienstGlobal​

Jeder Onlinedienst erhält in der Regel bereits beim Start über einen URL-Parameter ein Gebiet in Form eines ARS, für das eine Antragstellung ablaufen soll. Falls der ARS nicht beim Aufruf mitgegeben wird, muss der Onlinedienst dem Antragsteller selbst noch eine Ortssuche anbieten, um einen ARS zu bestimmten. In jedem Fall wird der Onlinedienst nach dieser ersten Phase seines Antragsprozesses das Parameter-Set bestimmen, das für seine Leistung und das aktuell gewünschte Gebiet anzuwenden ist.

Das so ermittelte Parameter-Set enthält potenziell den oben genannten Parameter idOnlinedienstGlobal. Der Onlinedienst ermittelt aus dem vorgefundenen Wert des Parameters idOnlinedienstGlobal die Basis-URN und die (optionale1) Versionangabe v.

Falls der Wert des Parameters idOnlinedienstGlobal gesetzt ist, aber die darin enthaltene Basis-URN nicht dem gerade ausgeführten Onlinedienst-Produkt entspricht, muss der Onlinedienst die Antragstellung in der Regel abbrechen, da nicht er selbst zuständig ist, sondern ein anderes Onlinedienst-Produkt. Dies soll der Onlinedienst als Fehlersituation mit dem Hinweis auf einen veralteten Zugangslink als Ursache des Fehlers anzeigen.

Falls der Parameter idOnlinedienstGlobal nicht gesetzt ist, der Hersteller des Onlinedienstes den Parameter aber als verpflichtend zu setzen dokumentiert hat, muss der Onlinedienst ebenfalls den Antragsprozess wie oben beschrieben abbrechen.

Im nächsten Schritt prüft der Onlinedienst die Versionsangabe v. Falls der Wert gesetzt ist, aber höher ist als die eigene Version, muss der Onlinedienst wiederum den Antragsprozess abbrechen, da offensichtlich bereits eine neuere Onlinedienst-Version für den produktiven Betrieb vorgesehen ist. Auch hier soll der Onlinedienst eine Fehlersituation mit dem Hinweis auf einen veralteten Zugangslink als Ursache des Fehlers anzeigen. Dasselbe gilt, falls der Hersteller des Onlinedienstes die Versionsangabe als verpflichtend zu setzen dokumentiert hat, er aber nicht gesetzt ist.

Falls die Versionsangabe v gesetzt ist, aber niedriger ist als die eigene Onlinedienst-Version, muss der Onlinedienst anhand einer fest vom Hersteller vorgegebenen Kompatibilitäts-Prüfung entscheiden, ob das vorhandene Parameter-Set, das für die alte Online_Dienst-Version erstellt worden ist, auch für die eigene Online_Dienst-Version nutzbar ist. Dies ist der Fall, wenn alle Änderungen seit dieser Onlinedienst-Version unkritisch sind. Dieses Vorgehen ermöglicht es, neue Onlinedienst-Versionen, die rückwärtskompatibel zu bestehenden Parameter-Sets sind, in Produktion zu bringen, ohne die Parametrisierung ändern zu müssen. In diesem Fall kann auch auf einen Parallelbetrieb verzichtet werden.

Falls die Versionsangabe v nicht gesetzt ist und der Hersteller das Setzen der Versionsangabe auch nicht zwingend vorschreibt, muss der Onlinedienst annehmen, dass das vorliegende Parameter-Set für die erste produktionsreife Onlinedienst-Version angelegt worden ist. Ist die eigene Version höher, d.h. ist die Onlinedienst-Version bereits ein Nachfolger der ersten produktionsreifen Onlinedienst-Version, muss der Onlinedienst wieder die vom Hersteller vorgegebenen Kompatibilitäts-Prüfung durchführen und auf dieser Basis entweder mit einer Fehlermeldung den Antragsprozess abbrechen oder ihn mit dem ermittelten Parameter-Set durchführen.

In allen Fehlersituationen besteht grundsätzlich die Möglichkeit, dass der Onlinedienst den Parameter Onlinedienst-Links auswertet, dort die URL zum eigentlichen produktiven Onlinedienst entnimmt und den Browser des Antragstellers dorthin weiterleitet. Onlinedienst-Links können jedoch dynamische Parameter definieren, deren Werte der Onlinedienst nicht immer bestimmen kann. Es wird daher empfohlen, diese Komfortfunktion einer Weiterleitung nur dann auszuführen, wenn Onlinedienst-Links.dynamischeParameter leer ist.

Risikobetrachtung​

Das hier vorgestellte Verfahren unter Nutzung des Parameters idOnlinedienstGlobal sichert den Parallelbetrieb von Onlinedienst Versionen mit inkompatiblen Parametrisierungsbedarfen zuverlässig ab, sofern es vollständig umgesetzt wird.

Falls Onlinedienste auf die Auswertung dieses Parameters verzichten, oder falls er nicht gesetzt wird, besteht das Risiko, dass bei Verwendung alter oder manipulierter URLs Onlinedienst-Versionen verwendet werden, deren Parametrisierungsbedarfe mit dem konfigurierten Parameter-Set nicht (korrekt) befriedigt werden können. Im günstigsten Fall wird der Onlinedienst dies im Zuge der Antragserstellung bemerken und kann dann die Antragstellung mit einer Fehlermeldung abbrechen. Unter ungünstigen Bedingungen kann es aber auch zu Fehlersituationen kommen, die erst während der Bearbeitung des Antrags in der Behörde oder gar nicht bemerkt werden, oder der Antrag kann nicht maschinell in das Fachverfahren eingelesen werden und eine aufwendige manuelle Fehlerbearbeitung muss angestoßen werden.

Wie hoch die Eintrittswahrscheinlichkeit und die Schadenshöhe dieser letztgenannten Fehler tatsächlich sind, kann nicht unabhängig von einer Einzelfallbetrachtung abgeschätzt werden. Auch die rechtlichen Konsequenzen können nur von juristischen Experten bewertet werden.

Fazit​

Das Basisverfahren zur Schrittweisen Produktivsetzung neuer Onlinedienst Versionen unter Berücksichtigung sich ändernder Parametrisierungsbedarfe ist naheliegend: Für jedes Gebiet, das die neue Onlinedienst Version nutzen kann und soll, wird das betreffende xZuFi-Onlinedienst-Datenobjekt entsprechend angepasst, so dass der Onlinedienst Link auf die neue, parallel betriebene Onlinedienst Version verweist und die Parameter werden entsprechend den Parametrisierungsbedarfen angepasst. Dies kann auch dadurch geschehen, dass parallel zum existierenden Onlinedienst-Datenobjekt ein weiteres Onlinedienst-Datenobjekt mit identischer Zustaendigkeit angelegt wird, dessen Gueltigkeit aber so eingestellt wird, dass die dadurch ausgelöste Produktivsetzung erst zu einem zukünftigen Stichtag aktiv wird. Zusätzlich wird die Gueltigkeit des bisher genutzten Onlinedienst-Datenobjektes auf den Tag vor diesem Stichtag begrenzt.

All dies ist nur notwendig, wenn es kritische Änderungen zwischen den Onlinedienst-Versionen gibt. Bei ausschließlich unkritischen Änderungen kann ohne Parallelbetrieb einfach die neue Onlinedienst-Version produktiv geschaltet werden. Diese sollte unter derselben URL erreichbar sein, damit keine Parametrisierungen angepasst werden müssen. Besteht aus Gründern der Risikominimierung die Anforderung, Fehlersituationen durch veraltetet oder manipulierte URLs sicher erkennen und behandeln zu können, muss der Onlinedienst einen zusätzlichen Parameter idOnlinedienstGlobal auswerten, der zuvor von den Redakteuren gesetzt werden muss. Er charakterisieren den Versionsstand, für den der vorhandene Parameter-Set intendiert ist. Nur so kann der Onlinedienst prüfen, ob er tatsächlich in seiner Version für ein bestimmtes Gebiet zuständig ist oder ob er aufgrund einer fehlerhaften URL aufgerufen wurde.

Footnotes​

  1. Der Onlinedienst muss dazu prüfen, ob das letzte Segment der URN syntaktisch einer möglichen Versionsangabe für die eigene Versionierungskonvention entspricht. Wenn er das letzte Segment nicht entsprechend parsen kann, ist das letzte Segment Teil der Basis-URN und die Versionsangabe ist nicht vorhanden. ↩