2019-23 Erweiterung der Nachrichtenköpfe

XBau-EG am: 2019-11-05

Der vorliegende CR bewegt sich im Rahmen des folgenden Anwendungsfalls:

• Dem Portal (Kollaborationsplattform) wird eine XBau-Nachricht durch eine Bauaufsichtsbehörde (BAB) übermittelt.
• Diese Nachricht soll dem Projektraum bestimmte Informationen zur Verfügung stellen (Daten oder Primärdokumente).

Zweck der Daten, um die der Nachrichtenkopf erweitert werden soll:

• Es handelt sich um die (zusätzliche) Absicherung der Authentizität auf Ebene der Fachnachricht (Sicherstellung der Identität der absendenden Fachbehörde).
• Dies ist relevant im Rahmen der Zugriffskontrolle auf den Projektraum.

Thema ist relevant und sollte behandelt werden.

Status erfasst

XBau-EG am: 2020-09-08

Rückfrage: Was wird durch ein Paar (Username; Passwort) separiert?

• 1 die Projekträume einer BAB (Mandant BAB)
• 2 Projektraum eines BG-Vorgangs (Antragsteller)

Antwort: No 1 ist gemeint. Kommunale Portale (z.B. Essen) haben diese Notwendigkeit also nicht unbedingt.

Ziel: Auf diese Weise werden die Informationen in der Plattform mandantenorientiert isoliert.

Fragen, die noch zu klären sind:

• Passwort im Klartext in der Fachnachricht enthalten? Was wäre hier der passende Mechanismus, der auch unter Aspekten der IT-Sicherheit angemessen ist
• Wie sieht Best Practice zu dieser Anforderung aus mit Blick auf andere XÖV-Standards im Zuge der OZG-Umsetzung (mandantenorientierte OZG-Portale in den Ländern; Auswirkung auf die Inhalte der Fachnachrichten)

Status in Arbeit

EG21-01 16.03.2021

Es soll diese zusätzliche Absicherung des Bereichs der BAB in der Plattform umgesetzt werden.

Im Rahmen der Umsetzung ist zu prüfen, an welcher Stelle die Lösung in die Struktur der Nachrichten passt.

Betroffen sind die Nachrichten, die von der BAB an zentrale Plattformen geschickt werden. 

DVDV-Zertifikate betreffen nicht diese mandantenorientierte Lösung.

Denkbar ist eine Lösung über einen API-Key Mechanismus. Dieser Key (Format: UUID) wird zusätzlich zur vorhandenen UUID, die sich auf den Antrag bezieht) in der XBau-Nachricht versendet. 

Der CR kann jetzt in die Umsetzung gehen.

Anmerkung ITEBO

Im Lösungsvorschlag ging es ja darum, daß neben Logindaten (API-Key Mechanismus) auch noch weitere Information mitgegeben werden können. Im Rahmen der Einbindung mandantenfähiger Plattformen könnte dazu als ein Beispiel auch die Übergabe sogenannter Templates dienen, so dass individuelle Strukturen innerhalb von Plattformen genutzt werden können.

In dem Zusammenhang hatte cit auf ein Beispiel aus Xjustiz hingewiesen, wie man dies für den CR umsetzen könnte. Das Beispiel, wie so etwas z.B. dort umgesetzt ist finden sie in der Spezifikation (https://xjustiz.justiz.de/system/pdf/Spezifikation_XJustiz_3_2_1.pdf) auf Seite 74.

Die Nachricht hat hier sogenannte Feldgruppen, die für die Übermittlung weiterer Informationen genutzt werden können. Das könnte man für den CR 2019-23 ggf. analog übernehmen.

Die Anregung, eine anwendungsspezifische Erweiterung einzuführen, soll bewertet werden. Das Original dazu ist im XÖV-Standard xdomea (im XRepository) zu finden. 

Das kann eine Lösung sein. Sie ist verlockend, weil es einen guten Teil des Themas "Sonderbedarf der Kollaborationsplattformen" versorgt. Hat aber auch Risiken (kann Eigenleben am Standard vorbei entfalten).

Folgendes Vorgehen wird als zielführend gesehen:

• Mögliche Risiken sollen geprüft und im EG bewertet werden (Meinungsbild)
• Die Erfahrungen, die in xdomea mit dieser Erweiterung in der Praxis gemacht worden sind, sollen recherchiert (Vorbereitung zum EG) und dabei berücksichtigt werden. 

Wäre sinnvoll, dass so ein CR an so einer Stelle (Recherche und Diskussion von Umsetzungsalternativen) wieder auf "in Arbeit" gesetzt werden kann.

Ggf. sollte der Jira-Workflow angepasst werden.

EG21-03 06.09.2021

• Architektur der Kollaborationsplattformen ist komplexer als diejenige der Antragsplattformen, daher hier spezielle Anforderung
• Element apikey ist wie vorgestellt gut plaziert (als Element im Datentyp Bezug)

^{Unable to render embedded object: File (image-2021-09-14-16-47-19-926.png) not found.}

• Objekt Anwendungsspezfische Erweiterung wird ebenfalls benötigt, es ist in der Umsetzung zu prüfen, ob dafür der Nachrichtenkopf, Datentyp Bezug oder Prozessmerkmale passend ist. 

Stichwort Risiken:

• Wie lassen sich Risiken kontrollieren?
• In der Dokumentation sollte eingeschränkt werden, wofür der xdomea:Datentyp verwendet werden darf.
• Vorschlag: Der Datentyp soll für die technische Integration notwendiger Informationen genutzt werden, die nicht durch andere XBau-Strukturen definiert werden und deren Auswertung nicht allgemein verfplichtend ist (keine Kannibalisierung existierender XBau-Strukturen). 
• Temporär kann die Struktur verwendet werden für Funktionaltiät, die nicht in XBau abgebildet ist (Beispiel Referenz auf das Nutzerkonto des Antragstellers). Es ist wünschenswert, dass in vielen Fällen solche Funktionen im zweiten Schritt in die Defintion der XBau-Datentypen integriert wird.  

Kann damit in die Umsetzung gehen. 

Plan in der Umsetzung: 

• Datentyp xbau:Bezug: Der Typ wird von der Bauaufsichtsbehörde verwendet, um auf einen Vorgang oder Antrag Bezug zu nehmen und bündelt entsprechende Metadaten. Daher eignet sich dieser Typ für die Einbindung des neuen Objekts Anwendungsspezifische Erweiterung.

Für die Einbindung eines Objekts anwendungsspezifische Erweiterung bietet xdomea neuerdings auch den folgenden Datentyp an, der das xs:any-Konstrukt verwendet und die Verwendung von eigenen ergänzenden XSD-Datentypen (vom Hersteller definierter Namespace) beim XBau-Datenaustausch gestattet.

Diese Variante ist aus XBau-Sicht eine technisch saubere Lösung und soll im Entwurf erprobt werden. 

Der CR wurde wiefolgt umgesetzt:

Es wurde ein neuer Datentyp "BezugErweitert" geschaffen, der die beiden Elemente "apiKey" (Format: UUID) und "anwendungsspezifischeErweirterung" beinhaltet.

Für die anwendungsspezifische Erweiterung wurde gemäß Entscheidung das xs:any-Konstrukt , analog zu xdomea, eingebunden.

Status: Erledigt

komm.One am 15.11. per E-Mail an hale:

ich habe mich schon mal mit dem neuen Nachrichtenkopf XBAU-41 Geprüft 2019-23 Erweiterung der Nachrichtenköpfe beschäftigt.

Im CR steht:

"BezugErweitert" geschaffen, der die beiden Elemente "apiKey" (Format: UUID) und "anwendungsspezifischeErweiterung" beinhaltet. Für die anwendungsspezifische Erweiterung wurde gemäß Entscheidung das xs:any-Konstrukt eingebunden.

Verstehe ich das richtig, dass im Element "anwendungsspezifischeErweiterung" alles Mögliche untergebracht werden kann? Zum Beispiel auch die Servicekonto-ID von service-bw.de

QS durch XLeitstelle:

CR wurde gemäß den Kommentaren vom 07.10. / 17.10. umgesetzt.

Ansonsten kein Befund -> Status = geprüft