Bij het versturen van StUF-berichten naar de CORV-voorziening (knooppunt Justitie) is gebleken dat de StUF-protocolbindingen ten aanzien van ebMS iets te strak zijn afgesteld. Er wordt namelijk geëist dat de StUF-stuurgegevens in alle gevallen overeen moeten komen met de CPA. Hierdoor kunnen we in geval van intermediaire nodes (in het bijzonder de CORV-voorziening) vitale informatie verliezen zoals de originele afzender (start node) of de uiteindelijke ontvanger (end node) van het bericht.
Het onderliggende probleem lijkt te liggen op niveau van Digikoppeling en in het bijzonder ebMS. Door de StUF-protocolbinding te versoepelen kunnen we dit probleem snel en eenvoudig oplossen. Dit voorstel zal de aankomende StUF Expertgroep vergadering op de agenda staan als erratumverzoek. Zie de bijlagen hieronder voor de gedetailleerde uitwerking van dit erratum.
Bij deze de eerste bijlage (de beknopte versie van de aanpassing)
Bijlage
Bij deze de tweede bijlage: het volledige protocolbindingendocument met de aanpassing
Bijlage
Dit Erratum is opgevoerd in de onderhoudsverzoeken als ERR319.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Doordat de tekst uitgaat van de situatie dat de waarde van het element niet overeenkomt met partyId, is er sprake van een uitzondering ("postfix") op een uitzondering (niet sprake van intermediaire nodes). Ik stel voor de leesbaarheid te vergroten door uit te gaan van de situatie dat de waarde van het element wel overeenkomt met partyId, waarop vervolgens 2 uitzonderingen van toepassing zijn: - postfix - intermediaire nodes Daarnaast lijkt het mij zinvol een voorbeeld toe tevoegen over het opslitsen van partyId met postfix in elementen organisatie en administratie.
Ik denk dat de opmerkingen van Han afdoende zijn. Het valt op dat veel implementaties nog steeds werken met tekst ipv de OIN in de afzender. @Henri: Ik heb echter ook een functionele vraag aan Henri. Is er altijd maar 1 afnemer van een StUF CORV bericht? Worden deze niet doorgestuurd naar meerdere afnemers? In dat geval weet de zender de uiteidelijke ontvanger niet (net als in Digilevering en dat is op zich prima)
@Han: Goede feedback, ik zal de tekst aanpassen om de leesbaarheid te verbeteren en een voorbeeld toevoegen @Karl: CORV vertaalt het van de gemeente ontvangen StUF bericht naar een EBV-bericht (berichtformaat van Justitie) en stuurt het door naar de Raad van Kinderbscherming. Dus er is voor dit bericht maar één afnemer achter de voordeur van CORV.
Bijgaand (zie bijlage) de verbeterde versie naar aanleiding van de opmerkingen van Han.
Bijlage
Bijgaand (zie bijlage) hetzelfde document maar dan zonder revisies voor de leesbaarheid.
Bijlage
Ik vind dat de vraag van Karl de Boer toch even wat meer aandacht nodig heeft. Wij passen de bindings aan zodat CORV hier ook mee kan werken. Maar denken wij ook aan andere systemen die van deze binding gebruik maken waarbij de afnemer misschien niet exact 1 afnemer is? Ik kan mij goed voorstellen dat het zendende systeem niet eens wil weten wie de afnemer is als er een intermediare node bestaat die de routering naar een (of meer) afnemers verzorgt.
Mijns inziens stuurt een zender zijn bericht altijd naar precies één ontvanger. Dit kan een systeem zijn dat binnenkomende berichten vermenigvuldigd en dat zie je dan ook in de stuurgegevens. Een systeem dat berichten vermenigvuldigd is daarmee in mijn ogen geen intermediaire node, maar een end node die het bericht oppakt en vervolgens omzet in andere berichten voor de diverse afnemers. Zo'n vermenigvuldiger kan voor de ontvanger transparant zijn, want in de zender kan nog steeds de originele zender van het bericht staan. Dit lijkt mij geen probleem. Wat mij betreft kan het erratum worden doorgevoerd.
Dit erratum is doorgevoerd in patch 19 (28 maart 2014).
In paragraaf 5.2.1. ebMS 1.1 van versie 3.02 van de StUF protocolbindingen zijn de regels met betrekking tot het element 'organisatie' binnen de stuurgegevens van een StUF bericht verduidelijkt en versoepeld.
Discussie gesloten.