Prosoz: Synchrone Register-Abfrage (DiBastai)
- 2.3.1
- Infrastruktur & Technik
In Grundlegende Festlegungen für die XBau-Datenübermittlung per OSCI-1.2 (XBau Kernmodul IV.C OSCI Transportprofil) wird im Kommunikationsszenario (Punkt 8) vorgegeben, dass jeder Diensteanbieter seinen Dienst im Sinne von OSCI-Transport 2002 als "one-way-active" anzubieten hat. Dies beschreibt einen anynchronen Informationsaustausch, der aber für die Abfrage von Registern nichit ausreicht; hier bedarf es einer synchronen Kommunikation.
Kommentare
Der CR wurde umgesetzt.
Der Anhang OSCI-Transportprofil wurde im Fachmodul Hochbau um eine Regelung ergänzt, die berücksichtigt, dass die Register-Abfrage beim Kammernverzeichnis synchron erfolgen muss.
Änderungen wurden in der Rubrik Kommunikationsszenario gemacht.
Unterstützend wurde im entsprechenden Anhang im Kernmodul die Beschreibung zum Kommunikationsszenario präzisiert.
Status erledigt
18.05.2022 - telefonische Abstimmung Leitstelle / Dataport / DiBastai Entwickler / Prosoz
Dataport:
Die Erweiterung des Standards um die Möglichkeit synchroner Nachrichten ist relativ aufwendig. Es bedarf einer synchronen Rückweisung, WSDL-Dateien müssen überarbeitet werden, ggf. passen Nachrichten nicht mehr. Der Plan, die Abfrage der diBastai-Datenbank zunächst asynchron zu lassen und erst zum Release 2.3.1 zu ändern, ist in Ordnung.
DiBastai Entwickler:
Aktuell nutzt DiBastai eine JSON-API zur Abfrage der Datenbank. Dabei werden XBau-Nachrichten zur Informationsübermittlung genutzt. Die Spezifikation der benutzten Schnittstelle ist dokumentiert. Aber das Registermodernisierungsgesetz fordert die Verwendung von XTA/DVDV, sodass dies als zusätzliche Schnittstelle ergänzt werden muss.
Prosoz:
Eine weitere (JSON-) Schnittstelle für DiBastai wird umgesetzt, falls notwendig. Die Umsetzung synchroner XTA-Kommunikation in XBau wird befürwortet.
QS durch Dataport Clearingstelle am 29.10.2022
Da sind Änderungen an den Entwürfen zwingend erforderlich.
Ein synchrones Szenario ist hier fachlich sicherlich wünschenswert, das wird aber nur Sinn machen wenn das Kammerverzeichnis in der Lage ist den Dienst hochverfügbar im 7*24 Stunden Betrieb anzubieten.
Wenn man das Nachrichtenpaar kammernverzeichnis.anfrage.0930 / kammernverzeichnis.auskunft.0931 synchron anbieten will, dann gibt es nicht mehr wie bei asynchron zwei getrennte asynchrone Dienste, sondern nur noch einen gemeinsamen synchronen Dienst, da dann Request und Response über eine gemeinsame technische Wegstrecke laufen. Der Dienst XBau231-ABK2BAB würde wegfallen, da der synchrone Dienst ja nur von der Kammer angeboten wird. Ich würde sogar dafür plädieren den Dienst eine Zusatz für synchron mitzugeben, damit dies für alle offensichtlich ist. So macht man es bei XAusländer z.B. http://www.osci.de/xauslaender1180/xauslaender1180ABHBAMFsync.wsdl. Daher würde ich den Dienst XBau231-ABK-BAB2AIKsync nennen.
Die Tabelle IV.C.1 nützt keinem was, weil die nur aufzählt welche Möglichkeiten es gibt. Dies ist nicht konkret genug. Anliegend die Tabelle C.3 aus der Spezifikation XAusländer 1.19.0. Wenn man nur ein OSCI-Transportprofil machen möchte, dann muss man aber den Punkt 8 Kommunikationsszenario strikt zwischen asynchron und synchron trennen und genau analog XAusländer beschreiben wie diese aussehen sollen und nicht nur eine Aufzählung der Möglichkeiten machen.
Außerdem braucht man auch eine synchrone Rückweisungsnachricht.
Status -> Umsetzung
CR wurde umgesetzt:
- Die Darstellung im OSCI-Transportprofil wurde redaktionell überarbeitet. Siehe Abschnitte IV.C OSCI-Transportprofil in den Spezifikationsdokumenten Kern- und Fachmodul
- Die synchrone Dienst-Definition XBau231-ABK-BAB2AIKsync wurde erstellt (die beiden inkorrekten Dienste XBau231-ABK-BAB2AIK und XBau231-ABK-AIK2BAB dadurch ersetzt). Außer den Nachrichten 0930 und 0931 ist dem Dienst jetzt auch die RTS-Nachricht 1100 (gehört zum Kernmodul) zugeordnet. Siehe Abschnitt IV.D DVDV-unterstützte Dienste in der Spezifikation XBau 2.3.1
- Die Nachrichtentypen 0710 ff. (Baulastauskunft) wurden in die DVDV-Dienste zum Baulastverfahren integriert
Status erledigt
EG22-02 22.06.2022
Bemerkungen:
Bewertung: