Ik lees op pagina 45 van StuF 03.01 (versie 11):
"Bevestigingsberichten kunnen in StUF ook op functioneel niveau gebruikt worden als respons: de bevestigings-berichten met de berichtcodes Bv01 en Bv02. .....
Bij een asynchroon vrij bericht kan een Bv01-bevestigingsbericht gebruikt worden om aan te geven dat de verwerking geslaagd is.
Wanneer een Bv01-bevestigingsbericht functioneel de respons is op een asynchroon bericht wordt eerst synchroon een Bv03-bevestigingsbericht verstuurd om aan te geven dat het bericht in goede orde ontvangen is en vervolgens asynchroon een Bv01-bevestigingsbericht om aan te geven dat de verwerking van het bericht functioneel geslaagd is."
Is het de bedoeling dat het Bv01 alleen voor vrije berichten wordt gebruikt? De operation Bv01 zie ik ook nergens terug in de schema's...
Is er bewust voor gekozen geen Bv01 te gebruiken als functionele asynchrone respons op de berichten uit het sectormodel?
Daar is inderdaad bewust voor gekozen: Voor kennisgevingen etc is er geen functionele en voor vragen en vraagOmSynchronisatie is de functionele respons gewoon gedefinieerd in het schema. De Bv01 zal inderdaad alleen bebruikt worden in vrije berichten.
Het is mij niet helemaal duidelijk waarom er bij Asynchrone berichten voor gekozen is geen functionele bevestiging te versturen.
Wij zitten met de situatie dat een kennisgeving (zakLk01) wordt ontvangen van een zaaksysteem, wij sturen eerst een Bv03 als technische bevestiging.
Het zaaksysteem kent de status "wacht op bevestiging" en verwacht dus nog een antwoord dat de kennisgeving goed is verwerkt door de ontvangende partij. Deze komt echter nooit.
Alleen als er wat fout gaat tijdens de verwerking wordt een fout bericht worden verstuurd en kan het zaaksysteem het bericht opnieuw versturen.
Waarom is er geen rekening gehouden met deze situatie en is er bewust voor gekozen geen functionele bevestings berichten te versturen?
Hoe kunnen we dit oplossen?
Er is hiervoor gekozen, omdat StUF als semantiek voor een kennisgeving heeft gedefinieerd dat de zender de ontvanger in kennis stelt van een verandering in de werkelijkheid. Wat de ontvanger daar precies mee doet wordt beschouwt als irrelevant voor de zender. Eventuele foutsituaties dienen out-of-band (en niet via een of ander StUF foutbericht) gecommuniceerd te worden. Als er geen fout gemeld wordt, dan mag de zender er na verloop van tijd van uitgaan dat het bericht door de ontvanger correct verwerkt is. Het is niet nuttig geoordeeld om voor elke kennisgeving de zender te berichten op welk moment deze correct verwerkt is.
Het zaaksysteem dat op een Bv01-bevestiging staat te wachten heeft de StUF-standaard niet correct geimplementeerd en zal aangepast dienen te worden.
Ok, helder.
Toch nog een vraag.
Wij zijn bezig met een proef implementatie van de Standaard Services voor het ontsluiten en koppelen van ZS en DMS.
Is hier ook bewust gekozen voor asynchrone kennisgevingen waar geen functionele bevestiging op terug komt?
Als Service Consumer (SC) is het wel wenselijk om te weten of en wanneer de kennisgevingen goed verwerkt zijn omdat de SC niet de eigenaar is van de zaak- en documentgegevens.
Ik ben niet betrokken geweest bij het ontwikkelen de services voor het koppelen van ZS en DMS, die niet op StUF gebaseerd zijn. Voor de StUF-berichten geldt dat terugkoppeling naar de SC van de verwerking niet gedefinieerd is en dus binnen het kader van StUF niet mogelijk is. Mocht je dit belangrijk vinden, dan is een RFC noodzakelijk en kan het in een volgende versie mogelijk verholpen worden. Ik ben hier overigens geen voorstander van: Geen bericht is goed bericht, want wat doe je als je de bevestiging niet (tijdig) krijgt.
Daarnaast kan je hiervoor natuurlijk ook buiten StUF om functionaliteit voor definiëren, maar dat is in mijn ogen ook niet aan te raden.
Motiveer nog eens beter waarom je als SC moet weten dat een kennisgeving goed verwerkt is en wat je met die kennis of het ontbreken ervan wilt doen.