De StUF standaard gaat ervan uit dat een applicatie verantwoordelijk is voor het bufferen van aan hem gerichte asynchrone berichten. In de praktijk leidt dit tot het implementeren van meer dan één berichtenbuffer in een gemeente. Elke berichtenbuffer kost geld en resources voor het beheer. Daarom is het wenselijk om het aantal berichtenbuffers in een gemeente te minimaliseren.
Dit kan worden gefaciliteerd door een extra operation te definiëren binnen de set van operations voor een StUF webservice, namelijk verwerkAsynchroonSynchroon. Als alles goed gaat, geeft deze operation een Bv02-bericht als respons en als er in de verwerking een fout optreedt, dan wordt een Fo02-foutbericht teruggegeven met de foutreden. Mogelijke foutredenen dienen nog nader gedefinieerd te worden.
De ontvangAsynchroon operation kan hiervoor niet gebruikt worden, omdat de foutafhandeling zich hier richt op de fouten die kunnen optreden bij het persisteren van het bericht in de berichtenbuffer.
De vraag is of en zo ja wanneer en hoe we deze mogelijkheid willen toevoegen aan de StUF-standaard.
In de StUF expertgroep van 21 december is als alternatief geopperd om de berichtenbuffer asynchrone berichten te laten omzetten naar hun synchrone variant. Dit kan als een sectormodel voor elk asynchroon bericht ook een synchrone variant bevat met dezelfde functionaliteit. Voor de vrije berichten en de kennisgevingberichten kan dit inderdaad.
Voor vraag/antwoord zal de berichtenbuffer moeten zorgen voor het verzamelen van alle asynchrone antwoordberichten op een asynchroon vraagbericht door middel van het stellen van synchrone vragen. Ook dit is zonder problemen te implementeren.
Met deze filosofie is het niet nodig om een extra operation te definiëren voor het synchroon verwerken van asynchrone berichten, maar kan de bestaande functionaliteit gebruikt worden.
De best practices worden uitgebreid. Bij het inrichten van een sectormodel dien je er voortaan voor te zorgen dat je symmetrisch bent. Dus altijd een asynchrone versie voor een synchroon bericht en vice versa (ERR231).
De XML-Schema's worden, waar nodig, vervolgens aangepast aan deze best practice.
In de StUF Expertgroep vergadering van 20 maart 2013 vroeg men zich af of je ook binnen koppelvlakken voor elk asynchroon bericht een synchrone variant moet opnemen. Men was van mening dat dit inderdaad het geval moet zijn. In de best practices moet dus ook worden aangegeven dat dit ook geldt voor koppelvlakken. Overigens geldt niet dat als je synchrone varianten hebt je ook asynchrone berichten moet hebben. Ook die stelling dient opgenomen te worden in de best practices.
De schema's bg0310_msg_bag.xsd en bg0310_msg_stuf_bag.xsd zijn uitgebreid met complexTypes en berichtelementen voor synchrone berichten, tevens is de WSDL bg0310_verwerkSynchroneKennisgeving_bag.wsdl voor de synchrone berichten aangemaakt. Daarnaast zijn er wijzigingen aangebracht in de best practices (ERR232).
Post gesloten.