In de StUF 0301 standaard wordt aangegeven dat als bevestiging op een asynchroon bericht een Bv03 of Bv04 terug kan komen afhankelijk of een bericht obv de stuurgegevens verwerkt kan worden. Dit betekent dat je als service consumer beide berichten moet ondersteunen omdat van tevoren niet duidelijk is hoe het softwarelandschap bij een gemeente waar de software geinstalleerd wordt eruit ziet. (en of daar bijvoorbeeld een servicebus aanwezig is). Dit maakt implementaties onnodig complex door het in feite moeten ondersteunen van 2 service implementaties/wsdl's.
Voorstel is om 1 bevestigingsberichttype (met bijvoorbeeld BvBericht ipv Bv0xBericht als rootelement) te definieren waarbinnen dmv de waarde van een attribuut of element aangegeven kan worden wat voor type bevestiging het betreft. Hierdoor hoeven serviceconsumers slechts 1 bevestiginsbericht te ondersteunen wat implementatie en codegeneratie vereenvoudigt.
Ik ben er voorstander van om de communicatie zo eenduidig mogelijk te maken en (niet hetzelfde) zo eenvoudig mogelijk. Samenvoegen van twee type asynchrone berichten tot 1 is daarom logisch. Om synchrone, asynchrone of historische bericht-typen samen te voegen is daarentegen niet eenduidig, omdat er hiertussen in technisch en/of functioneel opzicht enorme verschillen zitten.
Conform de huidige standaard moet je inderdaad zowel een Bv03 als een Bv04 als een synchrone respons kunnen ondersteunen. Ik snap niet zo goed wat hier het probleem van is of heeft dit te maken met beperkingen die ontstaan als je software genereert? Het voordeel van de door StUF voorgeschreven werkwijze is dat een service scherp is. In zijn wsdl geeft de service aan of hij de stuurgegevens valideert of slechts de verantwoordelijkheid op zich neemt voor het doorsturen van het bericht naar een volgende node. Je kunt je afvragen of deze scherpte op het niveau van de wsdl nodig is. Zo niet, dan kan het opnemen van een parameter binnen het Bv03-bericht ook uitsluitsel geven. Dit lijkt me niet iets wat je even als erratum doorvoert en zal dus moeten wachten op een volgende versie van StUF.
Namens PinkRoccade ben ik in ieder geval voorstander van een eenduidige standaard. De specificaties van de StUF onderlaag en de specificaties van de Zaak-Documentservices zijn nu in strijd met elkaar voor wat betreft intermediaire nodes. Daarnaast ben ik tot nu toe geen enkele applicatie tegengekomen die graag het onderscheid zou willen maken tussen een Bv03 en een Bv04. Applicaties zien een bevestiging als een bevestiging en willen daar (momenteel) geen extra functionaliteit aan koppelen of het bericht direct verwerkt kon worden of dat een intermediaire node een bevestiging heeft teruggegeven. Al hoewel het onderscheid vanuit de theorie gezien terrecht is, is het de vraag of dit onderscheid wel gemaakt moet worden. We hebben hier inmiddels al uren over vergaderd met allerlei partijen aangezien het verwarrend en complexiteitsverhogend is. Dit past niet in de gedachte dat de StUF standaard het ons als leveranciers juist makkelijk moet maken.
Tijdens de StUF Expertgroep van 19 februari 2014 is geconcludeerd dat er in het Zaak- Document services koppelvlak een fout is geslopen. Het is de keuze aan het koppelvlak om ook rekening te houden met intermediairs. Als een koppelvlak intermediairs wil faciliteren dan moet dat ook ergens beschreven staan in het koppelvlak en dan moet het daar ook rekening mee houden. Er dient dus op dat koppelvlak een erratum te worden ingebracht, in de WSDL ‘zkn0310_ontvangAsynchroon_mutatie_zs-dms.wsdl’ van het Zaak- Document services koppelvlak moet het ‘Bv04’ bericht dus worden opgenomen.
Om dit fundamenteel op te lossen in de onderlaag zal een RFC gedefinieerd worden waarin wordt voorgesteld om de bevestigingsberichten Bv03 en Bv04 te vervangen door 1 bevestigingsberichttype waarbinnen d.m.v. de waarde van een attribuut of element aangegeven kan worden wat voor type bevestiging het betreft.
Dit wijzigingsverzoek is opgevoerd in de onderhoudsverzoeken als RFC0324.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Tijdens de StUF Expertgroep van 18 februari 2015 is aangegeven dat hier gewoon een klap op gegeven kan worden. Wel moet goed nagedacht worden of het onderscheid relevant is. Het gaat er om dat je Bv03 en Bv04 in het bericht hebt als element. Daardoor kun je makkelijker met het schema omgaan.
Tijdens de StUF Expertgroep van 18 maart 2015 zijn we het nog niet eens geworden over dit RFC, het moest worden uitgewerkt en in de volgende vergadering weer worden besproken.
Tijdens de StUF Expertgroep van 20-5-2015 is vervolgens besloten dat dit RFC wordt meegenomen in de komende versie van StUF.
Tijdens de StUF Expertgroep van 21 oktober 2015 is dit RFC goedgekeurd.
In het Bv03 element zal het verplichte element 'intermediair' worden toegevoegd dat een boolean waarde (true en false) kan bevatten.
Verder zal in de StUF standaard de specificatie van het Bv03 bericht worden aangepast. O.a. het woord berichtenbuffer zal worden verwijderd.