Beste,
In testscenario SCN 8 - zm2 wordt beschreven hoe vanuit CORV richting de te testen applicatie twee maal een bericht wordt verstuurd met dezelfde vulling. De te testen applicatie moet in de gaten hebben dat het Refnummer al in gebruik is bij het tweede bericht. Bij actie wordt dan in de 4e stap genoemd:
TTA stuurt foutbericht (Fo03) terug naar CORV. Met de melding dat de combinatie van zender en referentienummer niet uniek is (foutcode 'StUF016').
Lastigheid hiermee is dat onze applicatie zich achter een service bus bevindt. Deze stuurt na het ontvangen van een Zorgmelding (of Notificatie), direct een Bv03 terug. Pas hierna wordt het binnenkomende bericht doorgestuurd naar onze applicatie, die de conditie kan checken. De service bus kan onmogelijk weten of een referentienummer al in gebruik is geweest.
Op pagina 49 en verder in de tekstuele beschrijving van de specificaties wordt uitgelegd dat in CORV eigenlijk de Fo01 hiervoor gebruikt kan worden. Wij zouden dan ook willen opteren het testscenario zo aan te passen dat er een Fo01, in plaats van een Fo03 wordt verstuurd in dit scenario.
Vriendelijke groet,
René Bolt
Topicus
Toeval wil dat ik dit vanochtend ook gemeld heb bij KING (Jan Brinkkemper).
Ik heb dit echter (nog) niet eerder gemeld op het forum maar hierbij alsnog.
Aanvullend daarop wil opmerkingen dat wij in het verleden wel eens een situatie hebben gehad waarbij herzending van een CORV bericht een gewenste oplossing was van een incident en dat een verplichte Fo01 een dergelijke oplossing blokkeert.
Ik kan mij voorstellen dat er tijdens de migratie naar CORV 1.0 ook situaties kunnen ontstaan waarop herzenden van een bericht de ontstane situatie kan oplossen en zie dus liever niet dat een fout (Fo01) hier verplicht wordt.
Los hiervan zijn we hier feitelijk CORV aan het testen want die zou niet (spontaan) referentienummers dubbel mogen gebruiken en het lijkt me niet de taak van de Jeugdzorgapplicatie om deze test uit te voeren.
Rene, John,
Ik snap de situatie. Toch ben ik van mening dat de testen nu correct zijn.
Het moet voor de consumer (in dit geval de DKA) niet uitmaken of hij met een GSB of een JZA communiceert. Het zou niet zo moeten zijn dat de consumer in geval het bericht wordt gestuurd naar een JZA er een Fo03 terugkomt terwijl hij een Bv04 ontvangt wanneer precies hetzelfde bericht wordt afgeleverd bij de GSB. In de specificatie worden de GSB/JZA overal als 1 getekend (zie bijvoorbeeld de interactiediagrammen).
De servicebus zou het bericht dus eerst moeten afleveren bij de JZA, het antwoord moeten afwachten en dit antwoord vervolgens doorsturen naar de consumer (DKA).
Ik heb hiermee twee problemen:
1. onze JZA behandelt een dubbel referentienummer momenteel niet als een fout omdat verwerking praktisch veelal gewenst is.
2. als dit een foutsituatie moet worden, zal het leiden tot een functionele asynchrone Fo01 (maar nogmaals, nu nog niet).
De test is gebaseerd op de StUF0301 specificaties:
Het is m.i. dus terecht te verwachten dat de end node (in dit geval de jeugdzorgapplicatie) een Fo03 stuurt. StUF schrijft voor dat in deze situatie een foutbericht Fo03 moet worden gestuurd.
Overigens zit er nu wel een fout in de testset op dit punt, want de berichten zijn identiek, waardoor juist verwacht moet worden dat de jeugdzorgapplicatie een Bv03 stuurt. De testset wordt aangepast, zodat voor beide berichten het referentienummer en zender gelijk zijn, maar de berichtinhoud verschilt. Het verwachtte resultaat, een Fo03 bericht, is dan weer terecht.
Dit is inderdaad een niet realistische situatie. Deze situatie wordt al afgevangen door Digikoppeling en hoeft dus niet getest te worden. Ik heb dit scenario uit de testset verwijderd.