Maarten van den Broek heeft aangegeven dat in de ZDS veelal asynchrone services gebruikt worden waar eigenlijk synchrone services gebruikt zouden moeten worden.
Het argument is dat ZDS gebruikt worden in het kader van een werkproces: een medewerker maakt een zaak aan en wacht op antwoord om verder te kunnen. Dit moet dus synchroon zijn, anders kan de medewerker niet verder.
In eerste instantie is het voorstel de synchrone services toe te voegen maar dat is niet wenselijk: een medewerker moet direct antwoord of een foutmelding krijgen.
Van deze melding is ONV 484537 aangemaakt. Dit onderhoudsverzoek wordt toegevoegd aan de agenda van de teleconferentie op 5 november en voorgesteld wordt om in ZDS 1.2 (maart 2016) de asynchrone services te vervangen door synchrone.
Naar mijn idee zijn de Zaak- en Documentservices niet ontworpen om direct vanuit een user interface te worden aangeroepen. Ze zijn bedoeld om (taakspecifieke) applicaties te koppelen aan een zaaksysteem en een DMS waarbij de interactie met de gebruiker plaats vindt op basis van lokale opslag van gegevens in deze applicaties. In deze context is de keuze voor asynchrone berichten mijns inziens de juiste.
Deze aanpak levert wel de nodige aandachtspunten op. Zo kun je bijvoorbeeld pas een document aan een zaak koppelen als de zaak is aangemaakt maar dat soort issues dient de gekoppelde applicatie op te lossen en daarvoor kent StUF de Bv01- en Fo01-berichten.
Ik kan me voorstellen dat er wel degelijk ook behoefte is aan de mogelijkheid een user interface direct te koppelen aan een zaaksysteem en een DMS. Als we die mogelijkheid willen ondersteunen, dan zouden we moeten overwegen RESTful services te ontwerpen die we naast de reeds bestaande asynchrone SOAP-services positioneren.
Wij (Roxit) zijn voor het gebruik van synchrone berichten om de redenen die Michiel aanhaalt.
Aanvullend: er is geen goed herstelmechanisme in ZS-DMS voor als het asynchrone bericht fout gaat. Dit ontwikkelen is een kostbare zaak.
Nav Roel zijn opmerking lijkt direct vanuit een user interface kunnen aanroepen me nou net wel een van de belangrijkste redenen waarom de Zaak- en Documentservices zijn gemaakt. Mogelijk komt het door de spraakverwarring wat er onder 'een zaaksysteem' wordt verstaan: een applicatie met zaakprovider-services, de (op zaken gerichte) consumerfuncties of allebei?
Mbt het zo snel mogelijk respons krijgen geldt m.i. dat dit theoretisch zowel via a-synchrone als synchrone berichten kan worden gerealiseerd, maar dat synchroon berichtenverkeer hier logisch lijkt (snelheid en bijv. de lastiger foutafhandeling die Johannes noemt).
Ben wel benieuwd of er het definieren van de services een reden was om te kiezen voor a-synchroon of dat het handiger was geweest in plaats daarvan te kiezen voor synchroon.
Ik (PinkRoccade Local Government) ben vóór de mogelijkheid van het gebruik van een synchrone afhandeling echter de Asynchrone verwerking moet als mogelijkheid gehandhaafd blijven. De Asynchrone service vooral daar gebruiken waar een slechte performance een issue kan zijn.
Aandachtspunten:
Gezien het aantal en de aard van de reacties is er niet voldoende draagvlak voor het vervangen van de asynchrone services door synchrone services.
KING heeft daarom besloten de huidige asynchrone services te handhaven. Mocht er in de toekomst voldoende draagvlak zijn voor het gebruik van synchrone in plaats van asynchrone services kan dit verzoek nogmaals bekeken worden.