1.0.0
Onlinedienst Status
| Fachliche Kategorie | Technische Kategorie |
|---|---|
| Onlinedienst-bezogener Standardparameter | XZuFi-basierte Standard-Parameter mit direktem Onlinedienst-Bezug |
Fachliche Bedeutung
Der Status des Onlinedienstes im Lebenszyklus bezogen auf die Leistung und das Gebiet.
Wertemenge
Ein Code aus der Code-Liste urn:xoev-de:fim:codeliste:xzufi.onlinedienststatus
Verortung im Datenmodell
Bis zur Migration nach XZuFi 2.3 wird der Parameter als XZuFi-basierten Individual-Parameter mit direktem Onlinedienst-Bezug verortet, auch wenn dies nicht ganz seiner technischen Kategorie entspricht. Dafür wird per Konvention festgelegt, dass der Namens-Schlüssel efa.custom.onlinedienst.status verwendet wird.
Der Wert in diesem Namens-Schlüssel/Wert-Paar ist dann der jeweilige Code aus der oben genannten Code-Liste, z.B. 30 für "Test".
Codebeispiel XZuFi 2.2
<xzufi:onlinedienst xmlns:p3="http://www.w3.org/2001/XMLSchema-instance"
p3:type="xzufi:OnlinedienstErweitert">
<xzufi:parameter>
<xzufi:parameterName>efa.custom.onlinedienst.status</xzufi:parameterName>
<xzufi:parameterWert>30</xzufi:parameterWert>
</xzufi:parameter>
</xzufi:onlinedienst>
Nach einer vollständigen Migration nach XZuFi 2.3 ist der Parameter im Element Onlinedienst.status verortet.
Dies ist auch der Grund, warum für den Parameter kein standardisierter Namens-Schlüssel in der Code-Liste urn:xoev-de:fim:codeliste:xzufi.efaparameter definiert wird.
Der Namens-Schlüssel wurde bewusst mit dem Präfix efa.custom. festgelegt, damit der Wert über die aktuelle Implementierung der FIT-Connect Routing API ausgelesen werden kann.
Ermittlungsmöglichkeit PVOG API
Siehe Abschnitt Ermittlung von generischen XZuFi-basierten Standard-Parametern mit direktem Onlinedienst-Bezug mit Hilfe der PVOG-API.
Der Namens-Schlüssel ist "efa.custom.onlinedienst.status".
Nach einer vollständigen Migration nach XZuFi 2.3 wird es voraussichtlich eine Möglichkeit geben, den Parameter über die PVOG API zu ermitteln. Diese Möglichkeit muss aber erst noch spezifiziert werden. Vermutlich wird es ein Element status in der Response des Endpunktes /v2/onlineservices/detail geben.
Ermittlungsmöglichkeit FIT-Connect Routing API
Bis zur Migration nach XZuFi 2.3 kann der Parameter wie jeder XZuFi-basierten Individual-Parameter mit direktem Onlinedienst-Bezug über das FIT-Connect Routing-API ausgelesen werden, da er sich an die FIT-Connect Namenskonvention für diese Parameter hält. Der Wert ist in der Response des /routes-Endpunktes im Element customParameters:efa.custom.onlinedienst.status zu finden.
Nach einer vollständigen Migration nach XZuFi 2.3 wird es voraussichtlich eine Möglichkeit geben, den Parameter auch über die FIT-Connect Routing API zu ermitteln. Diese Möglichkeit muss aber erst noch spezifiziert werden.
Ermittlungsmöglichkeit DVDV API
(Der Parameter kann nicht über das DVDV-API ermittelt werden)
Best Practices
Das Onlinedienst IT-System sollte den Parameter auswerten und damit seine eigene Geschäftslogik steuern. So sollte der Onlinedienst bei jedem vorgefundenen Status, der von 40/"Produktion" abweicht, ein deutlich sichtbares Warn-Banner anzeigen, dass er aktuell nicht produktiv nutzbar ist und keine Anträge wirksam verschickt werden können.
Darüber hinaus sollte der Onlinedienst nur dann einen Antrag versenden, wenn er den Status 30/"Test" oder 40/"Produktion" im Onlinedienst-Datenobjekt vorfindet. Der Umgang mit dem Parameter Onlinedienst.status in der Produktivsetzung von Onlinediensten wird vertieft auf der Seite Aktivierung des Onlinedienstes behandelt.
Das testweise Versenden von Daten in einer produktiven Umgebung und an einen produktiven Empfänger birgt immer Risiken und sollte nur dann geschehen, wenn entsprechende Sicherheitsmaßnahmen ergriffen wurden, um die produktive Weiterverarbeitung der Test-Sendungen zu verhindern. Daher sollte mindestens einer der folgenden Punkte gelten:
- Das empfangende Fachverfahren ist so konfiguriert, dass es grundsätzlich alle empfangenen Sendungen nach einer Prüfung verwirft. Eine produktive Weiterverarbeitung findet nicht statt.
- Der Onlinedienst kennzeichnet die Sendungen als Test-Sendungen, wenn der Status 30/Test vorliegt. Der Prozess des Fachverfahrens ist darauf ausgerichtet, so gekennzeichnete Test-Sendungen oder daraus resultierende weitere Artefakte früher oder später zu verwerfen.
- Der Onlinedienst versendet die Sendungen nicht an das produktive Fachverfahren, wenn der Status 30/Test vorliegt. Damit wird jedoch ein Testen des Versandes unmöglich.
- Der Status 30/Test wird nicht verwendet. Tests werden im Status 20/Initialisierung durchgeführt. Es werden keine Test-Sendungen verschickt. Auch dies macht das Testen des Versandes unmöglich.
Wie konkret vorzugehen ist, hängt vom jeweiligen Test-Konzept des Roll-In Teams ab.
Mit der Migration von XZuFi 2.2 nach XZuFi 2.3 wird die Angabe von Onlinedienst.status verpflichtend. Es gibt aber keinen Mechanismus, der eine (obsolete) Angabe eines Individual-Parameters efa.custom.onlinedienst.status verhindert. Ein Redakteur könnte übersehen, dass diese Angabe obsolet ist und versuchen, diese zu benutzen, um einen Status zu setzen. Um jedes Risiko eines fehlerhaften Umgangs mit Status-Parametern auszuschließen, sollte ein Onlinedienst, der bereits auf XZuFi 2.3 umgestellt wurde, prüfen, ob es einen Individual-Parameter mit dem Namens-Schlüssel efa.custom.onlinedienst.status gibt. Wenn dieser Namens-Schlüssel existiert und der zugeordnete Wert vom Wert in Onlinedienst.status abweicht, dann sollte der Onlinedienst eine Fehlkonfiguration melden und den Antragsprozess abbrechen.