Hoe bepaalt DCA of synchroon of asynchroon gewenst is

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

4 reacties / 0 nieuw
Anoniem
Hoe bepaalt DCA of synchroon of asynchroon gewenst is

Er is in de werkgroep gevraagd in welke gevallen een document synchroon of asynchroon teruggegeven moet worden. Conclusie is dat de DCA dit zelf bepaalt.

We willen bepalen op welke manier de DCV aan de DCA als wens kan meegegeven of synchroon of asynchroon gewenst is. Doel is dat hiermee een DCV zijn synschrone of asynchrone creatie voorkeur kenbaar kan maken als onderdeel van de creatieopdracht. Het niet in staat zijn om aan de wens te voldoen leidt tot een foutbericht. 

Hiervoor graag mening/input van geïnteresseerden. Eens/oneens? Wat is de beste manier om het kenbaar te maken?

Mijn voorstel is een parameter 'synchroonGewenst' met als waardes ja/nee. 

  • geen parameter = geen voorkeur
  • synchroonGewenst = ja == foutbericht als alleen asynchroon mogelijk is.
  • synchroonGewenst = nee == foutbericht als alleen asynchroon mogelijk is.
Wouter Wigman

Vooralsnog lijkt dit voorstel werkbaar. Dit zou wat Roxit betreft in een volgende versie van het berichten verkeer opgenomen kunnen worden.

Christian Peeters

Wij regelen het nu via de sjabloon. Van bepaalde sjablonen weet je vooraf dat deze bijvoorbeeld veel tijd zullen kosten wanneer er documenten van gegenereerd worden. Of dat een bepaald sjabloon alleen gebruikt wordt in situaties dat er geen directe response nodig is (bulk, schedule, o.i.d.) In de sjabloon wordt dan een eignenschap opgenomen die bepaalt dat het document async verwerkt wordt. Het voorstel zou daar een mooie aanvulling opzijn

Michiel Verhoef

Tijdens de bijeenkomst van 11 november 2014 is dit besproken en hoewel niemand echt tegen was bleek de use case niet echt duidelijk. Afgesproken is de use case verder uit te werken. Hiervoor graag input van de use cases waar dit gaat spelen. Bijvoorbeeld de use case: ‘synchroonGewenst = ja’ voor partijen die geen resultaatService bieden. Enkele opmerkingen uit de discussie:

  • criteria om synchroon/asynchroon te sturen, zijn er niet.
  • bij koppelingen zorgen gedeelde verantwoordelijkheden voor problemen.
  • DCA kan zelf bepalen wat hij doet. En indien endpoint voor resultaat ontbreekt, wordt het altijd synchroon