WSDL voor intermediaire nodes

Dit is een statische kopie van het eerdere discussie.kinggemeenten.nl.
Nieuwe discussies kunnen in de GitHub repository 'StUF standaarden' als issue worden opgevoerd.

5 reacties / 0 nieuw
Rolf van Deursen
WSDL voor intermediaire nodes

Vanaf StUF3.01 wordt een asynchrone berichtverzending anders afgehandeld als deze via een intermediaire node verloopt. De intermediaire node dient bijvoorbeeld met een Bv04 in plaats van een Bv03 te bevestigen.

In de huidig beschikbare sectormodellen wordt alleen een WSDL verstrekt voor een end node. Mijn voorstel is om ook voor de intermediaire node een correcte WSDL toe te voegen.

Het inzetten van een intermediaire node betekent overigens ook dat de aanbieder van het asynchrone bericht zelf in staat moet zijn om achteraf ook weer asynchroon een foutbericht te ontvangen. Hiervoor is in de huidige WSDL voor ontvangAsynchroon geen operation opgenomen. Dat is mijns inziens niet correct.

Groet,
Rolf

Maarten van den...

Het is de vraag of dit gedefinieerd moet worden in de standaard wsdl's. Het kan ook worden overgelaten aan partijen die hier behoefte aan hebben.De ontvangst van een asynchroon Fo03-bericht kan bijvoorbeeld eenvoudig gedefinieerd worden bg0310.ontvangAsynchroon.wsdl.

Tot nader order wordt niet overgegaan tot het opnemen hiervan in de door EGEM beheerde wsdl's. Mochten er zwaarwegende redenen dit wel te doen, dan graag een nieuwe post op dit forum.

Han Welmer

Mijns inzien beschrijft paragraaf 4.4 van stuf0301.pdf op afdoende wijze hoe intermediaire nodes in het algemeen moeten handelen. Wellicht dat een aantal plaatjes een en ander zou verhelderen, maar het staat er nu al wel.

Indien een intermediaire node niet transparant alle bg0301 berichten kan distribueren, bijvoorbeeld omdat het alleen bepaalde gegevens in een gegevensmagazijn kan opslaan, dan lijkt het mij dat de aanwezige WSDLs voor een end node voldoende aanknopingspunten geven.

Kortom, aanvullende standaardisatie voor intermediaire nodes lijkt me overbodig.

Robert Melskens

Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0105.
De lijst met onderhoudsverzoeken vind je op: 
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten

Robert Melskens

Dit probleem wordt al opgelost d.m.v. RFC0324. In de StUF Expertgroep van 21 september 2016 is dan ook besloten dit RFC af te voeren.