Wij zien in de praktijk het volgende gebeuren: een zaaksysteemconsumer stuurt een updateZaak over een betrokkene niet als een 'correctie' maar als twee keer hetzelfde object waarvan een met verwerkingssoort="V" en een met verwerkingssoort="T".
Dus:
<heeftAlsGemachtigde p6:entiteittype="ZAKBTRGMC" p6:verwerkingssoort="T">
(..)
</heeftAlsGemachtigde>
<heeftAlsGemachtigde xsi:nil="true" p6:noValue="geenWaarde" p6:entiteittype="ZAKBTRGMC" p6:verwerkingssoort="V" />
Dit wordt aan ontvangende zijde niet goed verwerkt. Nu vind ik de gebruikte constructie vreemd, er is immers nergens beschreven dat je eerst de 'V' en dan de 'T' moet afhandelen. Dit impliceert een ambiguïteit die niet zou moeten kunnen en dus een invalide bericht? Graag jullie mening hierover!
Bijgaand een completer berichtvoorbeeld.
Aan het gebrek aan reactie te zien had ik deze vraag misschien beter in het StUF-3.01 forum kunnen stellen?
Dag Jan,
Mijn eerste indruk is dat het inderdaad een vreemde constructie is maar die indruk zou ook gewekt kunnen worden doordat ik niet het gehele bericht kan beoordelen. Zou je daarom even het gehele bericht als bijlage kunnen posten?
Ik heb niks gevonden in de StUF specificaties die hier iets over de volgorde voorschrijft, dus moet dat gewoon correct verwerkt worden. Er is natuurlijk wel de eis dat in object[1] en object[2] de relaties in dezelfde volgorde voorkomen.
Correct:
<object>
<heeftAlsGemachtigde xsi:nil="true" p6:noValue="geenWaarde" p6:entiteittype="ZAKBTRGMC" p6:verwerkingssoort="T"/>
<heeftAlsGemachtigde p6:entiteittype="ZAKBTRGMC" p6:verwerkingssoort="V" />...</heeftAlsGemachtigde>
</object>
<object>
<heeftAlsGemachtigde p6:entiteittype="ZAKBTRGMC" p6:verwerkingssoort="T">...</heeftAlsGemachtigde>
<heeftAlsGemachtigde xsi:nil="true" p6:noValue="geenWaarde" p6:entiteittype="ZAKBTRGMC" p6:verwerkingssoort="V" />
</object>
Niet correct:
<object>
<heeftAlsGemachtigde p6:entiteittype="ZAKBTRGMC" p6:verwerkingssoort="V" />...</heeftAlsGemachtigde>
<heeftAlsGemachtigde xsi:nil="true" p6:noValue="geenWaarde" p6:entiteittype="ZAKBTRGMC" p6:verwerkingssoort="T"/>
</object>
<object>
<heeftAlsGemachtigde p6:entiteittype="ZAKBTRGMC" p6:verwerkingssoort="T">...</heeftAlsGemachtigde>
<heeftAlsGemachtigde xsi:nil="true" p6:noValue="geenWaarde" p6:entiteittype="ZAKBTRGMC" p6:verwerkingssoort="V" />
</object>
Maar in dit geval is het m.i. juister om vervangen te gebruiken:
<object>
<heeftAlsGemachtigde p6:entiteittype="ZAKBTRGMC" p6:verwerkingssoort="R" />
...(oude relatie)...
</heeftAlsGemachtigde>
</object>
<object>
<heeftAlsGemachtigde p6:entiteittype="ZAKBTRGMC" p6:verwerkingssoort="R" />
...(nieuwe relatie)...
</heeftAlsGemachtigde>
</object>
Frank,
Zoals jij hier het bericht schetst is al heel anders dan zoals Jan het schetst maar zoals jij het schetst zou het natuurlijk nog steeds niet correct aangezien er elementen ontbreken. Ik kan me echter voorstellen dat je die voor het voorbeeld hier weglaat.
Ik vind echter nog steeds dat het beter is om een voorbeeld van het gehele bericht te beoordelen.
Dank voor de reacties. Ik heb de hele logs er even bijgezocht, het bericht (of soortgelijk) eruit gehaald en de gevoelige gegevens eruit gefilterd. Helaas/gelukkig viel mij bij het opschonen op dat de informatie over twee objecten is verspreid. Dit zal dan waarschijnlijk verwijzen naar 'oud' en 'huidig' en daarmee correct zijn. Waarom dit eerder niet aan het licht is gekomen weet ik niet. Ik heb het volledige bericht wel nog even toegevoegd. Als dit correct is dan zal dus aan verwerkende zijde iets mis gaan, want dat in de communicatie is mis gaat is zeker
Bijlage
Fijn dat je het gehele bericht hebt bijgevoegd dat maakt e.e.a. veel duidelijker.
Je had de conclusie eigenlijk zelf al getrokken maar bij deze nog de bevestiging, het bijgevoegde bericht lijkt mij inderdaad ook correct.
Waarom wordt aan het 'gerelateerde' element overigens xsi:type="BTR-kerngegevensKennisgeving" toegevoegd?
Dag Robert, dank voor de reactie. Wat betreft het xsi:type, ik was het zelf ook nog niet eerder tegengekomen maar dit lijkt een verwijzing naar de schematypedefinitie van 'heeftAlsGemachtigde/gerelateerde' die inderdaad in de schema's van type 'ZKN:BTR-kerngegevensKennisgeving' blijkt te zijn.
https://www.w3.org/TR/xmlschema11-1/#Instance_Document_Constructions
--
Ik ben nu toch een voorbeeld tegengekomen van een verwijdering en invoegen binnen hetzelfde object dus dit gaat blijkbaar niet altijd goed vanuit de ZSC. Zie in de bijlage 'heeftAlsInitiator' vanaf regel 223.
Bijlage
Hoi Jan,
Klopt wat je zegt over het xsi:type maar dat is een overbodige toevoeging. Dat de gerelateerde op die plaats zich moet houden aan dat betreffende complexType wordt immers al door het XML Schema afgedwongen.
Wat betreft je voorbeeld bericht, volgens mij is ook deze correct. De relaties staan in beide objecten in dezelfde volgorde en in het eerste object is de relatie die wordt toegevoegd leeg en in het tweede object de relatie die wordt verwijderd.
Overbodig, maar niet incorrect volgens mij. (Ik heb de berichten niet zelf samengesteld dus ik kan er niet rechtstreeks invloed op uitoefenen anders dan een bug aanmelden bij de softwareleverancier)
Je zegt de relatie is leeg, maar maakt dat uit voor verwijderen? In mijn beleving staat hier: 'voeg toe en verwijder'. Je hebt immers maar 1 initiator op de zaak, en daarmee verwijs je dus met beide 'heeftAlsInitiator' naar hetzelfde object. Met het element <'heeftAlsInitiator' verwerkingssoort="V"/> zeg je eigenlijk: de inhoud van 'heeftAlsInitiator' is zojuist overbodig geworden. Ik heb paragraaf 5.2.5 van StUF-3.01 nog eens doorgeakkerd en het wordt er mij niet duidelijker op :)
<heeftAlsInitiator p6:entiteittype="ZAKBTRINI" p6:verwerkingssoort="T">
<gerelateerde xsi:type="BTR-kerngegevensKennisgeving">
<natuurlijkPersoon xmlns:q9="http://www.egem.nl/StUF/sector/bg/0310" xsi:type="q9:NPS-zkn-kerngegevensKennisgeving" p6:entiteittype="NPS" p6:sleutelVerzendend="1001253" p6:sleutelGegevensbeheer="98094" p6:verwerkingssoort="T">
<q9:geslachtsnaam>Vries</q9:geslachtsnaam>
<q9:voorvoegselGeslachtsnaam>de</q9:voorvoegselGeslachtsnaam>
<q9:voorletters>V.</q9:voorletters>
<q9:voornamen>Valerie</q9:voornamen>
<q9:geslachtsaanduiding>V</q9:geslachtsaanduiding>
<q9:geboortedatum xsi:type="p6:Datum-e">19500101</q9:geboortedatum>
</natuurlijkPersoon>
</gerelateerde>
<code>AANVRAGER</code>
<omschrijving>De aanvrager van de vergunning</omschrijving>
</heeftAlsInitiator>
<heeftAlsInitiator xsi:nil="true" p6:noValue="geenWaarde" p6:entiteittype="ZAKBTRINI" p6:verwerkingssoort="V" />
Het gebruik van xsi:type is zeker niet incorrect, dat klopt. Leek me echter toch goed je er op te wijzen.
Wat betreft het verwijderen en weer toevoegen van relatie is tabel 5.5 van de StUF standaard leidend.
Daar moeten we ons aan houden.
Er speelt hier bij nader inzien echter nog iets anders. Volgens het StUF-ZKN schema mag je binnen het 'object' element nl. slechts 1 keer het element 'heeftAlsInitiator' opnemen. Het bericht dat je als bijlage eerder hebt toegevoegd is dus toch niet correct. Dat hoeft echter helemaal geen probleem te zijn aangezien je het verwijderen en weer toevoegen van een 'heeftAlsInitiator' ook kunt zien als het wijzigen van een 'heeftAlsInitiator'.
Daarmee wordt het bericht volgens mij zoals in de bijlage van deze reactie is geschetst.
Bijlage
Dag Robert,
Dank voor de toelichting en het voorbeeld! Dit is inderdaad zoals ik het ook zie. Ik zal vragen of men het wil aanpassen in de bewuste applicatie.