In het VTO-bericht kunnen door de gemeente of de door haar gemandateerde organisatie documenten meegeleverd worden tot een maximale gezamenlijke omvang van 8 Mb. Dit blijkt in de praktijk soms te beperkt te zijn waardoor gemeenten relevante documenten niet kunnen leveren of deze alsnog onbeveiligd per mail nasturen. Beide situaties zijn ongewenst.
Het meest voor de hand liggend lijkt de beperking van 8MB op te heffen of te vergroten. Dit stuit evenwel op technische onmogelijkheden in de CORV en bij de RvdK.
Een andere oplossing is een nieuw bericht waarmee aanvullend op een eerder ingediend VTO documenten aan de RvdK verstrekt kunnen worden. Dit zou kunnen voorzien in twee behoeften:
- indien bij het indienen van een VTO documenten meegeleverd moeten worden met een omvang groter dan 8Mb, dan worden in het VTO-bericht documenten tot een maximum van 8Mb geleverd en in één of meerdere vervolgberichten de overige documenten.
- indien na het indienen van een VTO blijkt dat er meer, dan de ingedende, voor de RvdK relevante documenten zijn, dan kunnen deze 'nagezonden' worden.
Is dit een realistische oplossing voor de gesignaleerde behoefte?
Ik ben voorstander van het verhogen van de maximale grootte.
Het alternatief heeft trekjes van een "kanon en mug".
Daarnaast kan het verhogen van de maximale grootte zonder xsd schema aanpassingen.
Met John eens, maximale grootte verhogen. Het probleem zit hem ook niet altijd in meerdere documenten die opgeteld over de 8MB heengaan. Er zijn ook gevallen dat het gaat om 1 PDF die groter is dan 8MB. Dan moeten gebruikers deze documenten gaan opknippen, dat is ook onwenselijk.
Wat ons betreft ook de grens van 8MB verhogen. Dit heeft de voorkeur boven een nieuw bericht te introduceren.
Neemt niet weg dat ik deze wens nauwelijks van onze klanten hoor. Als er al problemen met de bestandsgrootte zijn, komt dit in veel gevallen door organisatielogo's van 3MB of meer in een pdf of Word-document.
Ik herken de beperking in het gebruik bij VT niet. Als er wel zoals Arjan schrijft 'soms' een probleem mee is, heeft de verhoging van de limiet de voorkeur wat mij betreft.
Een update bericht zou niet omwille van dit probleem geïntroduceerd moeten worden. Uiteraard geldt wel dat als er om andere redenen met voldoende toegevoegde waarde een VTO update bericht komt, dit dan ook gebruikt kan worden om aanvullende bijlage(n) te versturen neem ik aan.
Wij herkennen zeer zeker de beperkingen van de bijlagen zowel bij onze VT organisaties als onze Gemeentelijke klanten.
Ook mijn voorkeur gaat uit naar het significant verhogen van de toegestane omvang, eerder richting 100mb, alsmede het aantal.
Als ik het goed heb is de inperking van de omvang ook zonder formele release gedaan dus ik neem aan dat we per 1 augustus wel weer op 20MB kunnen zitten.
Nee, dat laatste heb je niet goed. Die inperking betreft wijziging 453382 in versie 1.0.0. Zie het document ' StUF-koppelvlak Jeugdzorg - Wijzigingen in versie 1.0.0 20150831' op de koppelvlak-documenten-pagina in GEMMA Online. Is dus zeerzekers over nagedacht (o.v.v. Justid) en formeel doorgevoerd met versie 1.0.0.
De VenJ knooppunten die gebruikt worden bij het routeren van CORV berichten parsen alle XML berichten. Op dit moment hebben wij een fysieke grens staan van 35MB op de omvang van een XML bericht.
Binnen ebMS wordt echter meestal gebruik gemaakt van bijlagen die als aparte payloads in een multipart sessie buiten de XML delen meegeleverd worden. Op die manier kunnen wij berichten met een totale omvang to 2GB verwerken.
Je krijgt dan dus een multipart die uit drie delen bestaat:
Alle volgende delen zijn de verschillende bijlagen die vanuit de stuf gerefereerd worden.
@Patrick, dus de feitelijk 8MB grens ligt ergens anders in keten?
Ik vind je idee voor het benutten van de multi-part messages slim. Het lijkt me dat we deze oplossingsrichting moeten verkennen zodat het mee kan voor November.