Prosoz: Synchrone Register-Abfrage (DiBastai)

XBAU-234
  • 2.3.1
Geprüft
Di., 11.07.2023 - 13:23
Fertig
Mi., 18.05.2022 - 15:32
priority-icon Medium
  • 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

EG22-02 22.06.2022

Bemerkungen:  

  • Zitat (pdf Kernmodul): "Kommunikationsszenario: Jeder Diensteanbieter muss alle hier relevanten Operationen eines Dienstes one-way-active im Sinne von [OSCI–Transport 2002] anbieten"
  • ist zu korrigieren in pdf und ggf. in der entsprechenden WSDL
  • Hinweis. in den XTA-Metadaten zu XBau-Nachrichten, die über den XTA-Server COM Despina verteilt werden, ist i.d.R. der Profil-Eintrag xauslaender enthalten. Das ist zu überprüfen. 

Bewertung:

  • Korrektur
  • Meinungsbild EG: allgemein akzeptiert 
  • Aufwand für EG: niedrig
  • Aufwand Umsetzung im Standard: mittel 

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