Gebruik Fo01 en Bv01 bij kennisgevingen

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
Jan Timmerman
Gebruik Fo01 en Bv01 bij kennisgevingen

Even een vraagje over het gebruik van fout- en bevestigingsberichten op kennisgevingen. In v1.1.02 van het document 'Specificatie Zaak- en Documentservices' wordt gesuggereerd dat een Fo01 noodzakelijk is op de 'creëer zaak' kennisgeving, er staat namelijk: 'Indien een fout optreedt, vindt er geen verwerking plaats (eventueel reeds uitgevoerde acties worden teruggedraaid). De ZSC wordt hiervan op de hoogte gesteld middels een StUF foutbericht'. (paragraaf 4.1.4.1)

Omdat 'indien er een fout optreedt' een stuk breder is dan passend bij de technische foutmelding 'Fo03' had ik hieruit gedestilleerd dat er nog een asynchrone Fo01 moet volgen na verwerking.

Ik zie echter dat de bewuste regel is verwijderd uit v1.2 van het Specificatie Zaak- en Documentservices document, dus bovenstaande argumentatie gaat niet meer op. Het wordt nu een beetje in het midden gelaten en ik vermoed dat de meeste leveranciers toch al voor de 'alleen Bv03/Fo03' route hebben gekozen (?) maar graag zou ik een definitieve uitspraak zien over het al dan niet nodig zijn van Fo01/Bv01.

Alvast dank,

Jan Timmerman

Roel de Bruin

In het algemeen wordt een Bv03 of Fo03 gestuurd als technische response op de ontvangst van het (asynchrone) bericht. Na verwerking van het bericht kan een Bv01 worden gestuurd ter bevestiging van de verwerking en als er tijdens de verwerking een fout optreedt dan kan een Fo01 bericht worden gestuurd.

Ik zeg in beide gevallen 'kan' want de serviceprovider kan dat alleen als er een endpoint bekend is waar deze berichten heen kunnen worden gestuurd en onze ervaring is dat de meeste consumers deze niet ondersteunen. En bovendien staat er nergens dat de serviceprovider ook verplicht is dit bericht te versturen als de consumers dit wel ondersteunt.

In het wsdl-bestand van versie 1.1 zijn beide berichten wel opgenomen, maar in versie 1.2 staat alleen nog het Fo01 bericht. Dat betekent dat de provider wel een bericht kan sturen om aan te geven dat er een fout in de verwerking is opgetreden, maar dat er geen bevestiging meer kan worden gestuurd om aan te geven dat de verwerking heeft plaatsgevonden. 

 

Jan Timmerman

Dag Roel, dank voor je reactie.

Het klopt dat 'Specificatie Zaak- en Documentservices' geen uitspraken doet over het al dan niet nodig zijn van Bv01 en Fo01 maar dat betekent volgens mij niet dat het vrij wordt gelaten want 'voor zover deze specificatie bepaalde eisen en regels niet beschrijft geldt de betreffende achterliggende standaard' (in dit geval StUF-0301) Het hangt er dus vanaf hoe je dat document interpreteert of een Fo01 al dan niet verplicht is. Ik heb er nog even op zitten puzzelen en zie het nu zo: 

- StUF 0301 schrijft voor dat de Bv03 en Fo03 alleen betrekking heeft op het correct zijn van de stuurgegevens.
- Als er aanvullende validatie nodig is moet een eventuele fout dus asynchroon worden teruggekoppeld met een Fo01
- Zaak- en Documentserviceszegt: 'Wanneer zich bij de verwerking fouten voordoen, vindt geen verwerking plaats. Reeds uitgevoerde acties worden teruggedraaid, de afzender wordt op de hoogte gebracht middels een StUF foutbericht'.

Hieruit concludeer ik dat het gebruik van de Fo01 dus verplicht is, want bovenstaande fout kun je niet teruggeven met een Fo03. Tegelijkertijd vind ik het vreemd dat je een heel retourpad moet optuigen voor een Fo01 die eens in het jaar voorkomt (en waarvan je moet hopen dat de route nog operationeel is, deze wordt immers nooit gebruikt)

Overigens kan ik de afwezigheid van de Bv01 verklaren ahv: https://vng-realisatie.github.io/StUF-Standaarden/discussie/gemma/stuf-zkn-310/zkn-func...
In mijn optiek is het enorm 'bad-practice' om alleen fouten terug te geven, maar dat is een andere discussie..

Michiel Verhoef

Wat mij betreft is dit een prima input voor de doorontwikkeling van de Zaak- Documentservices.