De StUF functionaliteit voor asynchrone bevraging kan leiden tot grote bestanden met daarin het antwoord. Deze grote omvang kan leiden tot verwerkingsproblemen. Bij antwoordbestanden met een omvang van bijvoorbeeld 4Gb of meer werken standaardvoorzieningen voor zippen en unzippen vaak niet meer adequaat.
Daarom lijkt het wenselijk om toch in de StUF standaard regels op te nemen over het “opknippen” van antwoord bestanden.
Een voorbeeld van een dergelijke regel zou kunnen zijn dat een antwoordbestand nooit meer dan 10.000 antwoordberichten bevat en dat anders het antwoord wordt verdeeld over meerdere bestanden.
Wij zijn benieuwd hoe andere aankijken tegen deze rfc over het opknippen van antwoordbestanden om deze “handelbaar” te houden.
Hoewel aangegeven is dat het hier om een RFC gaat heb ik het issue toch even als een onderhoudsverzoek (ONV) opgenomen.
Ik vraag me nl. af of de wijziging niet evt. ook al in de 3.01 versie van de StUF standaard opgenomen kan worden.
Dit ONV is opgevoerd in de onderhoudsverzoeken als ONV0428.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Het lijkt ons (Centric) een praktische oplosssing om de mogelijkheid te bieden om antwoordbestanden op te kunnen splitsen in meerdere bestanden.
Over of en hoe je dan in de standaard vastlegt wanneer dit moet gebeuren zouden we eens goed na moeten denken. Je zou in de onderlaag de mogelijkheid kunnen bieden om te splitsen en dan in de koppelvlakken kunnen bepalen op welke gronden. Je zou kunnen kiezen voor een maximale bestandsgrootte of voor een maximum aantal berichten, Bij een max aantal berichten moet je natuurlijk altijd nog kijken naar de (max) grootte van de betreffende berichttypes. Van acdLko01-berichten kun je er natuurlijk veel meer kwijt in eenzelfde bestand dan van synchronisatieberichten op natuurlijke personen of woz-objecten.
De standaard verbiedt het opknippen van een grote hoeveelheid berichten over verschillende bestanden niet. Ik vraag me dus af of we in de protocolbinding heel veel moeten veranderen en we dit niet beter aan de praktijk kunnen overlaten. In geval van een asynchroon antwoordbericht biedt de standaard nu ook al voorzieningen waarmee je kunt constateren dat een antwoord nog niet compleet is, omdat deze voorzieningen nodig zijn bij het via een webservice opbouwen van een asynchroon antwoord.
Tijdens de StUF Expertgroep van 18 mei 2016 is door Maarten weerlegt dat hier sprake is van een probleem. Er is nergens gesteld dat alle berichten in 1 bestand moeten zitten. Volgordelijkheid is ook geen probleem aangezien we beschikken over het tijdstipBericht en een sequencenummer. Daarnaast kun je ook in de naam van de bestanden een indicatie van volgorde opnemen. Maarten heeft aangegeven dat er wel iets moet gebeuren maar dat daarvoor de standaard waarschijnlijk niet aangepast hoeft te worden.
De Waarderingskamer moet aanvullende eisen opstellen. Indien die eisen goed zijn dan kunnen deze, indien gewenst, in de standaard opgenomen worden. Dit erratum zetten we on hold totdat de Waarderingskamer met een voorstel is gekomen.
In bijgevoegd bestand hebben we aangegeven hoe wij aankijken tegen het opknippen van grote xml-antwoordbestanden.
Volgens ons kan de specificatie van dit opknippen relatief eenvoudig zijn.
Wij horen het graag als wij zaken over het hoofd hebben gezien.
Bijlage
Hierbij de uitwerking van dit onderhoudsverzoek ter goedkeuring tijdens de StUF Expertgroep van 15 februari 2017.
Bijlage
Mooi dat er nu een concrete uitwerking van ons voorstel is. We hebben nog twee aandachtspunten.
1. is het wenselijk nog expliciet vast te leggen dat ieder deelbestand een zelfstandig verwerkbaar bestand moet zijn (om te voorkomen dat een ontvanger de bestanden eerst moet samenvoegen voordat hij deze kan verwerken)
2. is het wenselijk om het volgnummer nader te specificeren omdat bestandsnamen veelal alfabetisch gesorteerd zullen worden en dan de 11 voor de 2 komt. (bijvoorbeeld volgnummer begint met 001 oid)
Het lijkt niet nodig om expliciet vast te leggen dat ieder deelbestand zelfstandig verwerkbaar moet zijn. In dit verband betekent dit dat elk deelbestand zelfstandig in een berichtenbuffer verwerkt moet kunnen worden en dat is het geval, want het bevat n complete berichten conform de spec.
Zelfstandig verwerkbaar in de zin leidend tot het door de maker van de set deelbestanden bedoelde eindtoestand zijn de deelbestanden. Die eindtoestand is pas bereikt na verwerking van het laatste deelbestand.
Het lijkt me wel een goed idee om te specificeren dat het volgnummer bestaat uit drie cijfers met zo nodig voorloopnullen.
Tijdens de StUF Expertgroep van 15 februari 2017 is de uitwerking van dit ONV goedgekeurd met dien verstande dat het volgnummer binnen de gehele set van bestanden bestaat uit eenzelfde aantal cijfers. Daarmee wordt ingespeeld op een groter aantal bestanden dan 999 wat de beperking zou zijn geweest bij slechts 3 cijfers. Het onderhoudsverzoek kan tevens omgezet worden naar een erratum.