Uit de inventarisatie van wensen voor de nieuwe versie van het Jeugdzorg-koppelvlak ('StUF-CORV') is onder andere de behoefte voortgekomen voor verbetering van de toepassing en inhoud van foutberichten. Hiertoe zijn twee wijzigingsvoorstellen ingediend, zie de bijlagen.
Het ene voorstel betreft duidelijkheid over het toepassen van Fo01- en Fo03-berichten. Ons inziens is met de toevoeging van sequentiediagrammen per bericht aan de koppelvlakbeschrijving voldoende duidelijk gemaakt welk type foutbericht wanneer verzonden dient te worden. Graag vernemen we of er desondanks toch nog onduidelijkheid is, wat die onduidelijkheid dan is en hoe we dat kunnen verbeteren.
Het andere voorstel betreft meer duiding van de geconstateerde fout bij het verzenden van een foutmelding. Graag vernemen we praktijkcases over foutsituaties (bij het ontvangen van een VTO en een terugkoppelingZorgmelding cq. de ontvangst van een daarop volgend foutbericht) en voorstellen voor inhoudelijke duiding van foutsituaties die in het foutbericht meegegeven kunnen worden t.b.v. een beter begrip van de opgetreden fout door de verzender van het oorspronkelijke bericht.
Nb. De nieuwe versie (1.1) staat gepland voor november 2016.
Duidelijkere foutmeldingen zijn een zeer gewenste wijziging wat Solviteers betreft.
Hierbij een greep uit de foutmeldingen die wij verzameld hebben. Meestal een 902 server-fout waarbij de validatie faalt. Sommige fouten geven een duidelijke zoekrichting aan, bij andere is het volstrekt onduidelijk wat het probleem is. Voor het gemak heb ik alleen de Fo01bericht.body.details gekopieerd:
No SCH validation done
XSD validation details:
<string>:1:0:ERROR:SCHEMASV:SCHEMAV_ELEMENT_CONTENT: Element {http://www.egem.nl/StUF/sector/zkn/0310}heeftRelevant: This element is not expected.
No SCH validation done
Hartelijke groet,
Jarich Ypma
Dag Jarich,
Zou jij de bij de bovenstaande meldingen behorende foutberichten (de xml berichten dus) in een zip file willen plaatsen en deze aan deze discussie willen toevoegen? De exacte locatie van de tekstuele content in het foutbericht kan net even iets meer informatie opleveren.
Dag Robert,
Hierbij 3 van de vier meldingen. De vierde heb ik vanmiddag net opgeschoond in de log.
Bijlage
Om debuggen makkelijker te maken zou dit wel een toevoeging kunnen zijn. Dit heeft voor ons geen prioriteit omdat fouten eerder uitzondering zijn dan regel.
Duidelijkere foutmeldingen zijn uiteraard welkom. Dit maakt het opzoeken van de fout een stuk makkelijker. Als ik het wijzigingsformulier goed lees dan is het met name de bedoeling om ook fouten (die in RvdK of politie systeem voorkomen) goed door te geven. Wat ons betreft prima om door te voeren in de nieuwe release.
Duidelijker foutmeldingen zijn bijna altijd een verbetering.
Hierbij indien mogelijk onderscheid maken tussen:
1) foutmeldingen gericht aan gebruikers organisatie (gemeente, VT, etc) en die duiden op (tijdelijke) fouten bij aflevering of fouten in het gebruik van het koppelvlak die niet veroorzaakt worden door een onjuiste interpretatie van het CORV koppelvlak
2) foutmeldingen voor de software leverancier die te maken hebben met een onjuiste interpretatie van het CORV koppelvlak
Bij foutmeldingen zoveel mogelijk aansluiten bij de standaard StUF foutcodes.
De toegevoegde waarde voor onze eindgebruikers voor dit type foutmeldingen is minimaal, hooguit dat het de oplostijd wat versnelt. Ik zie geen hele dringende reden om dit NU op te lossen
Den Haag is nu bezig met implementatie en wij lopen nu ook tegen sommige foutmeldingen aan. Wij begrijpen dat de oorzaak voor fout
Communicatie: Missing child element(s). Expected is ( {http://data.justid.nl/jk/dictionary-1}Waarde ).
kan liggen in het gebruik van lege velden.