In de StUF standaard worden sommige foutcodes alleen gedefinieerd in relatie tot synchrone kennisgevingen. Bijvoorbeeld StUF068 wordt in tabel 4.1 en 5.8 expliciet genoemd als gekoppeld aan een synchrone kennisgeving. Maar dit zou betekenen dat wanneer dezelfde kennisgeving asynchroon wordt verzonden, deze foutcode niet zou zijn toegestaan. Dat is onwenselijk. Daarom wordt voorgesteld expliciet in de standaard vast te leggen dat alle voor synchrone kennisgevingen benoemde foutcodes ook zijn toegestaan bij asynchrone kennisgevingen.
ma, 7-04-2014 - 19.07u
#1
Foutcodes ten onrechte beperkt tot synchrone kennisgevingen
Dit onderhoudsverzoek is opgevoerd in de onderhoudsverzoeken als ONV0326.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Dit issue is tijdens de StUF Expertgroep van 17 december 2014 besproken.
Er is toen gezegd dat als je naar de standaard kijkt dat je dan zou zeggen dat die dit verbiedt. Inmiddels wordt daar echter anders over gedacht en uiteindelijk is geconcludeerd dat in de zin boven tabel 5.8 het woordje ‘Lk01’ geschrapt moet worden.
Het onderhoudsverzoek is omgezet naar een erratum (ERR0326).
Fijn dat dit als erratum verduidelijkt gaat worden. Dan is tenminste de huidige praktijk van Fo01 foutberichten vanuit de LV WOZ als reactie op asynchrone kennisgevingsberichten in overeenstemming met de bedoeling van de StUF standaard.
Alleen het weghalen van Lk01 boven tabel 5.8 is denk ik niet voldoende om te bereiken dat ook volledig helder is dat asynchrone kennisgevingen (vrije berichten) kunnen leiden tot functionele foutberichten (Fo01).
Wanneer we de eerste zin van paragraaf 5.2.8 lezen, dan staat daar eigenlijk al dat Fo01 berichten als respons op een asynchrone kennisgeving niet verwacht mogen worden. Ik denk dat er iets systematischer gekeken moet worden in de tekst om te zorgen dat de diverse StUF foutberichten ook gewoon gebruikt kunnen worden als respons op asynchrone kennisgevingen.
Mijn interpretatie van het weghalen van Lk01 in de zin boven de tabel zou zijn dat de foutberichten niet toegestaan zijn bij asynchrone kennisgevingen (de berichten zijn specifiek voor Lk02's, dus voor synchrone berichten).
Gezien de oorspronkelijke intentie en de expliciete stelling dat op een asynchroon bericht geen foutmelding wordt verwacht, lijkt me dat ook het meest haalbare als erratum (het is duidelijk een vergissing dat boven de tabel Lk01 genoemd is). Het wijzigen van inzichten waardoor wél foutmeldingen kunnen volgen op asynchrone kennisgevingen is m.i. meer een reden om een RFC in te dienen dan hierven een erratum te maken.
In de StUF Expertgroep van 17 december 2014 was het inzicht dat er voor asynchrone berichten geen foutafhandeling zou gelden. Bij een Lk01 zou je dus niet geïnteresseerd zijn in een evt. fout. Dit was de oorspronkelijke gedachte van Maarten van den Broek. Deze is echter van standpunt veranderd en heeft geen problemen meer met het gebruik van dezelfde foutberichten bij synchrone en asynchrone foutberichten.
Sid Brouwer durfde niet te zeggen wat de Centric systemen doen als asynchrone berichten ineens de betreffende foutmeldingen krijgen. Er is afgesproken dat dit eerst binnen Centric wordt besproken. Sid zal zijn reactie in deze discussie plaatsen. Pas daarna zal KING het erratum uitwerken zodat in een volgende vergadering goedkeuring kan worden gegeven.
Uitgangspunt moet zijn dat de Fo01-berichten niet verplicht zijn en ook niet verplicht ondersteund hoeven te worden door de verzender van de Lk01. Deze is immers niet 'gewend' dergelijke berichten te ontvangen en daar dus wellicht helemaal niet op ingericht.
Liever zien wij dit dus sowieso terug als een RFC en niet als een erratum.
Daarnaast lijkt het ons noodzakelijk om een afnemer die Fo01-berichten verstuurt bij fouten ook te verplichten Bv01-berichten te versturen als verwerking wél goed gaat. Hiermee kan de verzender van de oorspronkelijke Lk01 zijn cache legen. Als je een foutbericht kunt ontvangen, wil je immers het oorspronkelijke bericht bewaren om het foutbericht nog te kunnen interpreteren (anders heb je ook niets aan het foutbericht). Als je geen bevestiging krijgt, weet je nooit of het bericht correct is verwerkt, dan wel of er alsnog een Fo01 op kan volgen. Je kunt dan je berichtenopslag niet schonen voor berichten die goed zijn gegaan.
Volgens mij wordt deze vraag, conform de wens van Sid, inmiddels als RFC besproken in het kader van de vernieuwing van de StUF onderlaag.
Als RFC willen we dan nog steeds graag dat de generieke foutcodes ook gebruikt kunnen worden in Fo01 berichten als respons op asynchrone kennisgevingen.
We zijn benieuwd hoe anderen tegen het verzoek van Sid aankijken om dan ook Bv01 verplicht te stellen. Wij zijn van mening dat die verplichting niet noodzakelijk is, omdat het foutbericht voldoende informatie bevat om een inhoudelijke foutafhandeling op te starten.
Het punt met de bevestigingsberichten is niet dat er niet genoeg informatie in de Fo01 zit.
Als je echter géén Fo01 krijgt én geen Bv01, dan weet je dus nooit zeker of een bericht door de ontvanger goed verwerkt is (als Bv01 niet verplicht is). Zou je dus iets met de antwoorden willen doen en daarvoor de oorspronkelijke berichten willen/moeten bewaren (totdat ze zijn verwerkt), dan kun je zonder Bv01 nooit weten of je die opslag kunt schonen. Als je dus wat met een Fo01 moet doen, dan is het ook wel wenselijk om van verzonden berichten te weten als er geen Fo01 meer komt (en je er dus niets meer mee hoeft te (gaan) doen).
Tijdens de StUF Expertgroep van 16 maart 2016 is gesteld dat Sid m.b.t. de Bv01 berichten een ander aspect aan de discussie heeft toegevoegd. Hierover, werd gesteld, moet echter in een koppelvlak worden beslist.
Daarnaast is bediscussieerd of dit issue als een erratum of als een RFC moet worden behandeld.
Een deel van de StUF Expertgroep gaf aan van mening te zijn dat het om een Erratum gaat en dat het backwards compatible is. Een ander deel gaf aan dit issue niet zonder consequenties a;s een erratum kan worden opgelost. Een Fo01 bericht schept verwachtingen terwijl de zender van het Lk bericht niets met de fout kan. De fout moet bij de ontvanger opgelost worden. Andere leden zijn juist van mening dat de verzender het probleem moet oplossen.
Naar de mening van Sid handelt het om een RFC omdat het om nieuwe functionaliteit gaat. Maarten gaf hierop aan dat er te veel vanuit principes wordt geredeneerd terwijl er meer gereageerd zou moeten worden vanuit de vraag of iets een probleem is.
Tijdens de StUF Expertgroep van 19 april 2017 vraagt Robert de aanwezigen wat er met dit onderhoudsverzoek moet gebeuren. Moet het worden omgezet naar een RFC of niet?
De StUF Expertgroep ziet hier 2 onderhoudsverzoeken in:
Bij deze de voorstellen tot verbetering m.b.t. de errata ERR0326 en ONV0484. De bijlagen bevatten alleen de relevante pagina's. Deze voorstellen zijn ook al opgenomen in pre-patch 27 welke ter goedkeuring op de agenda staat van de StUF Expertgroep van 21 juni 2017.
Bijlage
In de agenda van de StUF Expertgroep op 28-06-2017 staat ONV 0484 opgenomen als Maak Bv01 berichten verplicht in een asynchone context. Maar uit deze discussie begrijp ik dat het de koppelvlakontwerper vrij staat om BV01 berichten in asynchrone context te gebruiken, niet dat het verplicht is om dat te doen.
Interpreteer ik het ONV verkeerd of klopt de agenda niet?
Michiel, de EG is morgen (21 juni) en niet op 28-06-2017 ;-)
De titel "Maak Bv01 berichten verplicht in een asynchone context" van ONV0484 is inderdaad niet correct. Ik weet trouwens niet waar die titel vandaan komt want ik kan het ONV0484 nergens terugvinden op dit forum. Misschien kan Robert ons morgen opheldering geven.
Henri,
Sorry, ik was even in de war met de werkgroep Documentcreatieservices die wel op 28 juni is :-).
ONV0484 komt ook uit deze discussie voort. In post 11 staat dat de EG in deze discussie twee onderhoudsverzoeken ziet. Eén daar is ONV0484 geworden. In post 12 is een zipfile bijgevoegd met daarin de voorgestelde oplossingen voor beide onderhoudsverzoeken (ERR0326 en ONV0484).
Het aanvankelijke voorstel was ook om Bv01-berichten verplicht te stellen, zeker op het moment dat ook Fo01-berichten worden verstuurd. Daarmee is het voor de zender (de ontvanger van de Bv/Fo-berichten) duidelijk dat hij verstuurde berichten niet meer hoeft te bewaren ten behoeve van eventuele foutafhandeling.
Uiteindelijk is (volgens mij) besloten dit niet in de onderlaag verplicht te stellen, maar om het vrij te laten aan de koppelvlakontwerpers om dit al dan niet te doen.
Tijdens de StUF Expertgroep van 21 juni 2017 is het voorstel van reactie 12 besproken. M.b.t. ERR0326 is besloten om de voorlaatste zin (‘Als de verwerking van een asynchrone kennisgeving faalt, dan voorziet de StUF-standaard niet in een geautomatiseerde verwittiging van de zender’) in de eerste alinea van paragraaf 5.2.8 te verwijderen. Verder zal er met dit onderhoudsverzoek in het achterhoofd nog een keer kritisch door de StUF standaard gelezen worden en waar nodig n.a.v. gelijksoortige zinnen aanpassingen aangebracht worden.
Met medeneming daarvan heeft de StUF Expergroep de uitwerking van ERR0326 goedgekeurd. Ook de uitwerking van ONV0484 is goedgekeurd. Dat laatste onderhoudsverzoek mag ook omgezet worden naar een erratum (ERR0484).
Inmiddels is patch 27 gepubliceerd op GEMMA Online met daarin de tijdens de StUF Expertgroep van 21 juni 2017 goedgekeurde wijzigingen. Zoals uit de voorgaande reactie blijkt is beloofd om de StUF standaard nog een keer kritisch tegen het licht te houden. Daarbij zijn nog enkele wijzigingen aangebracht.
Bijgaand vind je dan ook de laatste versie van de StUF standaard met daarin alle aangebrachte wijzigingen m.b.v. renvooi zichtbaar gemaakt.
Bijlage