Open gerardnienhuis opened 2 years ago
Dat mechanisme zit in de provider maar dat principe van naar de volgende XML gaan geldt dan alleen voor situaties waar de XML wel te snappen is maar er iets mist in de XML. Dus voor situatie 1 en 2 zal het dan inderdaad stuk gaan. De derde situatie zou de provider nu al mee om moeten gaan. Mogelijk mist er iets wat noodzakelijk is in de publisher en wordt daar dan niet goed mee omgegaan.
We kunnen daar inderdaad naar kijken hoe we de provider robuuster kunnen maken door met meer situaties rekening te houden.
Fouten worden op dit moment vooral veroorzaakt door niet utf-8 tekens. Is het misschien een goed idee om tijdens het harvesten de betrokken xml's te controleren en als er een niet-utf8 teken in zit, niet een crash te laten uitvoeren. Misschien is het zelf mogelijk om in de logging te vermelden dat er een bestand is "overgeslagen" omdat er in een bepaalde regel een niet utf8-teken in aanwezig is? Of is het zelf mogelijk om de regel te vermelden? Het mooiste zou zijn als dit ook in het dashboard van het Geoportaal weer zichtbaar zou kunnen worden gemaakt.
Het komt heel soms voor dat een xml die verkeerde vulling heeft, toch aan de publisher provider wordt aangeboden.
Wens is dat de publisher provider dan niet geheel stopt, maar deze xml overslaat en gewoon verder gaat met de volgende xml die verwerkt moet worden. Nu crasht de publisher provider en moet de foute xml handmatig worden verwijderd of verbeterd. Dat levert veel vertraging op. Wens is wel dat de melding in het logboek wordt weggeschreven: xml fout. xml is overgeslagen, filenaam is ...
zie ook: https://github.com/IDgis/geoportaal-test/issues/732
Fouten betreffen onder meer die situaties:
1) type bestand niet als utf8-codering weggeschreven met fme 2) xml bevat geen data (0 kb) 3) xml bevat niet alle (voor publisher provider benodigde) velden (dus bevat deel data, maar deel ontbreekt)