Wijzigingsvoorstel foutmeldingen (#487342/#487344)

9 reacties / 0 nieuw
Arjan Kloosterboer
Wijzigingsvoorstel foutmeldingen (#487342/#487344)

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.

Jarich Ypma

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:

  1. PE_VALID_1_2_1: Element {http://www.egem.nl/StUF/sector/bg/0310}aoa.postcode: 1234 AB is not a valid value of the atomic type {http://www.egem.nl/StUF/sector/bg/0310}Postcode.
    No SCH validation done
  2. alse
    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
  3. Communicatie: Missing child element(s). Expected is ( {http://data.justid.nl/jk/dictionary-1}Waarde ). 
  4. KindPartij: Missing child element(s). Expected is one of ( {http://data.justid.nl/jk/dictionary-1}BeschrijvendeIdentificatie, {http://data.justid.nl/jk/dictionary-1}Communicatie, {http://data.justid.nl/jk/dictionary-1}GezaghebbendeOfOuderPartij ).

Hartelijke groet,

Jarich Ypma

Robert Melskens

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.

Jarich Ypma

Dag Robert,

Hierbij 3 van de vier meldingen. De vierde heb ik vanmiddag net opgeschoond in de log.

Bijlage

Fo01_verzameling.zip
Erwin Ilgun

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.

Gerrit Duizer

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.

John Rooijakkers

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.

René Schrieken

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 

André van den N...

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.