In de 3.01 versie van de StUF standaard hebben we de beschikking over de zogenaamde samengestelde kennisgevingen.
Een manier om een reeks van kennisgevingen door te zenden die in de volgorde waarin ze in het bericht staan moeten worden verwerkt.
Zo kan m.b.v. het 'bgrVSL_Lk03' bericht (Verlenen sloopvergunning) achtereenvolgens een of meerdere keren de combinatie van een 'pndLk01' en een 'ogoLk01' worden verstuurd.
In de 3.02 versie van StUF zullen de samengestelde kennisgevingen deprecated zijn en moet daarvoor gebruik worden gemaakt van een vrijbericht.
Daardoor krijg je iets als:
<bgrVSL_Di01 ...>
<stuurgegevens>
<stuf:berichtcode>Di01</stuf:berichtcode>
<stuf:functie>Verlenen sloopvergunning</stuf:functie>
</stuurgegevens>
<pndLk01 functie="update" bg:entiteittype="PND">
<parameters>
<stuf:mutatieSoort>W</stuf:mutatieSoort>
<stuf:indicatorOvername>V</stuf:indicatorOvername>
</parameters>
<object verwerkingssoort="W" bg:entiteittype="PND">
...
</object>
<object verwerkingssoort="W" bg:entiteittype="PND">
...
</object>
</pndLk01>
<ogok01 functie="update" bg:entiteittype="TGO">
<parameters>
<stuf:mutatieSoort>W</stuf:mutatieSoort>
<stuf:indicatorOvername>V</stuf:indicatorOvername>
</parameters>
<object verwerkingssoort="W" bg:entiteittype="TGO">
...
</object>
<object verwerkingssoort="W" bg:entiteittype="TGO">
...
</object>
</ogoLk01>
</bgrVSL_Di01>
Heel mooi als je voor je kennisgevingsbericht kunt terugvallen op een standaard kennisgevingsbericht.
Echter indien je wensen dermate zijn dat je ook je kennisgevingsbericht al in een vrij bericht moet verpakken heb je geen mogelijkheid om deze weer in een samengesteld vrij bericht op te nemen.
Om dit te kunnen realiseren ben je nl. gebonden aan het gebruik van een vrij bericht met de functie 'entiteit'.
Deze biedt je echter niet de mogelijkheid om een ander bericht op te nemen. Direct na het 'stuurgegevens', 'parameters', 'melding' combinatie mag immers maar 1 element niveau met een vrij te kiezen naam opgenomen worden. Meer elementniveau’s worden weliswaar niet expliciet verboden maar n.m.m. is dat wel de geest van de standaard.
Om een ander vrij bericht op te kunnen nemen zijn echter minimaal 2 vrije niveau's noodzakelijk.
Zo zouden we in het kader van de LV-BAG het volgende vrijebericht willen kunnen opstellen:
<lVBAGPndCombiDi02 ...>
<stuurgegevens>
<stuf:berichtcode>Di02</stuf:berichtcode>
<stuf:functie>...</stuf:functie>
</stuurgegevens>
<lVBAGPndDi02 functie="entiteit" bg:entiteittype="PND">
<stuurgegevens>
<stuf:berichtcode>Di02</stuf:berichtcode>
<stuf:functie>...</stuf:functie>
</stuurgegevens>
<parameters>
<stuf:mutatieSoort>W</stuf:mutatieSoort>
<stuf:indicatorOvername>V</stuf:indicatorOvername>
</parameters>
<toevoeging functie="entiteit" bg:entiteittype="PND">
...
</toevoeging>
<wijziging functie="entiteit" bg:entiteittype="PND">
...
</wijziging>
<wijziging functie="entiteit" bg:entiteittype="PND">
...
</wijziging>
</lVBAGPndDi02>
<lVBAGPndDi02 functie="entiteit" bg:entiteittype="PND">
<stuurgegevens>
<stuf:berichtcode>Di02</stuf:berichtcode>
<stuf:functie>...</stuf:functie>
</stuurgegevens>
<parameters>
<stuf:mutatieSoort>W</stuf:mutatieSoort>
<stuf:indicatorOvername>V</stuf:indicatorOvername>
</parameters>
<toevoeging functie="entiteit" bg:entiteittype="PND">
...
</toevoeging>
<wijziging functie="entiteit" bg:entiteittype="PND">
...
</wijziging>
<wijziging functie="entiteit" bg:entiteittype="PND">
...
</wijziging>
<wijziging functie="entiteit" bg:entiteittype="PND">
...
</wijziging>
<wijziging functie="entiteit" bg:entiteittype="PND">
...
</wijziging>
</lVBAGPndDi02>
</bgrVSL_Di01>
Wij stellen dan ook voor om het mogelijk te maken om in een vrij bericht een ander vrij bericht op te nemen.
Aangezien daarmee in theorie de mogelijkheid ontstaat om meer dan 2 niveau's vrije elementen op te nemen stellen we tevens voor om te verbieden dat een samengesteld vrijbericht in een ander samengesteld vrijbericht mag worden opgenomen.
Dit RFC is opgevoerd in de onderhoudsverzoeken als RFC0496.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Uit het voorstel wordt mij niet duidelijk welke voordelen men nu eigenlijk hoopt te halen met deze werkwijze. Het idee van vrije berichten is toch juist dat men gericht op bepaald doel een scherp bericht definieert, bijvoorbeeld om een gebeurtenis in de werkelijkheid compleet in één bericht te kunnen opnemen. Juist het eenduidig scherp definiëren van die "vrije" berichten is van groot belang.
Met de voorgestelde gelaagdheid van de vrije berichten, wordt die duidelijkheid van het bericht volgens mij bemoeilijkt. Ik ben dan ook heel benieuwd in welke praktijksituaties met echt behoefte heeft aan, geholpen wordt met dit soort gelaagde vrije berichten. Zonder helder beeld van die voordelen, lijkt het mij onwenselijk om dit soort constructies die de berichten nog weer ingewikkelder maken, aan de standaard toe te voegen.
De casus is dat, door specifieke wensen van het Kadaster t.a.v. het wijzigen van een object, het toepassen van een standaard kennisgeving niet mogelijk is. De betreffende wijziging is dus in een vrij bericht vormgegeven. Daarnaast wil het kadaster deze wijzigingsberichten kunnen bundelen in een enveloppe-bericht waarin maximaal 100 van deze wijzigingen worden opgenomen en als één bericht verzonden kunnen worden.
In de huidige situatie kan ik wel 100 kennisgevingen in een vrij bericht bundelen, maar ik kan niet 100 vrije berichten in een bericht bundelen. Met deze wijziging is dat wel mogelijk en kunnen we de wens van het kadaster binnen de standaard invullen. Ik verwacht dat een dergelijke wens ook in andere situaties kan voorkomen waarin je meerdere wijzigingsberichten die als vrij bericht zijn vormgegeven in 1 gebundeld bericht wilt kunnen aanbieden omdat je de set wijzigingen als één transactie wilt (laten) verwerken.
Meer algemeen gaan we in met deze wijziging het hergebruik van vrije berichten meer mogelijk maken. Als (om welke reden dan ook) een wijziging van een object in een vrij bericht is vormgegeven en daarnaast ook de wens bestaat om een combinatie van wijzigingsberichten als één transactie vorm te geven wordt dat met deze wijziging mogelijk.
Als deze wijziging niet wordt doorgevoerd, dan wordt de berichtontwerper verplicht om exact dezelfde functionaliteit meerdere malen te realiseren met als risico dat daar verschillen ontstaan.
Dank voor de poging de casus toe te lichten. Toch ben ik niet direct overtuigd dat dit de juiste weg is om scherpe koppelvlakken te definiëren. StUF heeft een standaard wijze om kennisgevingen te communiceren. Wanneer we dan kennisgevingen definiëren in een koppelvlak, dan komt het mij vreemd over om te kiezen voor een vrij bericht, omdat het Kadaster een van de StUF standaard afwijkende werkwijze wil benutten voor kennisgevingen. We moeten ons dan afvragen of een dergelijk koppelvlak nog wel de naam StUF verdient.
Verder had ik het idee dat StUF al een standaard wijze had om meerderde berichten te combineren tot een samengevoegde set van berichten. Het per koppelvlak voor dat doel weer definiëren van vrije berichten lijkt ook dan weer een afwijking van reeds bestaande standaard StUF oplossingen.
Ruud,
Je zegt:
Verder had ik het idee dat StUF al een standaard wijze had om meerderde berichten te combineren tot een samengevoegde set van berichten. Het per koppelvlak voor dat doel weer definiëren van vrije berichten lijkt ook dan weer een afwijking van reeds bestaande standaard StUF oplossingen.
Waar jij op doelt is het gebruik van samengestelde kennisgevingsberichten (Lk03 en Lk04).
In de nieuwe versie van StUF hebben we deze berichten echter deprecated gemaakt. Ze mogen nog wel toegepast worden als het een nieuwe versie betreft van samengestelde kennisgevingsberichten in de de StUF 3.01 versie van een koppelvlak.
Er mogen echter geen nieuwe samengestelde kennisgevingsberichten meer worden aangeboden in een koppelvlak.
Daarvoor in plaats moet gebruik gemaakt worden van vrije berichten. Het is dus geen afwijking van een reeds bestaande StUF oplossing maar een vervanging daarvan.
Beste Ruud,
We hebben geprobeerd en uitgebreid onderzocht naar mogelijkheden de functionele wensen van het Kadaster voor de LV BAG in te vullen met generieke StUF kennisgevingen. Onze conclusie was dat dit niet mogelijk is, omdat de functionele wensen afwijken van de functionaliteit die is beschreven voor generieke kennisgevingen. De keuze voor het gebruik van vrije berichten is dus niet veroorzaakt door een keuze voor een "afwijkende werkwijze", maar komt voort uit een analyse van de functionele wensen.
Ik ben het niet met je eens dat een koppelvlak niet de naam "StUF" verdient als het vrije berichten gebruikt. Het doel van de standaard moet zijn om gewenste functionaliteit voor koppelingen in te vullen. Het inperken van mogelijke functionaliteit of uitsluiten uit het gebruik van de standaard (en daarmee met verworvenheden binnen de standaard) is m.i. niet de weg die we willen begaan met de standaard.
Veel berichten in belangrijke koppelvlakken zijn vrije berichten, omdat ook daar de gewenste functionaliteit niet kon worden bereikt met generieke berichten. Denk daarbij aan koppelvlakken StUF jeugdzorg (100% vrije berichten), Zaak- Documentservices, Regie- Zaakservices, Documentcreatie services.
Robert,
Is het dan niet meer mogelijk om meerdere berichten gelijk te versturen met:
<StUF:StUF-berichtenSet xmlns:StUF="http://www.egem.nl/StUF/StUF0301"></StUF:StUF-berichtenSet>
<!--definitie van het omhullende element voor uitwisseling via een bestand -->
<element name="StUF-berichtenSet">
<annotation>
<documentation xml:lang="nl">In het schema van de StUF-standaard kan dit element slechts gedefinieerd worden met als types anyType voor de
elementen die voor kunnen komen in een berichtenbestand. De verschillende sectormodellen definieren deze
elementen in meer detail. Een correcte validatie is mogelijk door in het bericht expliciet het sectormodel te specificeren
waartegen het bericht gevalideerd dient te worden.
</documentation>
</annotation>
<complexType>
<choice minOccurs="0" maxOccurs="unbounded">
<any/>
</choice>
</complexType>
</element>
Als ik de toelichting hierbij lees denk ik dat dit alleen bedoeld is voor in een bestand, niet voor berichten in een SOAP bericht. De discussie hier die is gestart door Robert moet ook een oplossing vinden voor gegevensuitwisseling over andere protocolbindingen (zoals SOAP, Digikoppeling).
In het voorstel van Robert (zie post #1) wordt een samengesteld bericht voorgesteld waarin volledige dienstberichten kunnen worden opgenomen inclusief stuurgegevens. Dit geeft onnodig veel overhead (precies de reden waarom het samengestelde kennisgevingsbericht de status deprecated heeft gekregen in StUF 3.02) en is niet in de geest van het dienstbericht (berichtsoort Di/Du) waarin alleen de body van andere berichtsoorten wordt hergebruikt:
Mijn voorstel is om het waardenbereik van het attribute functie uit te breiden met de waarde "dienst":
In het kader van de LVBAG zouden we dan bijvoorbeeld het volgende bericht kunnen opstellen:
<LVBAGPndCombiDi02 ...>
<stuurgegevens>
<stuf:berichtcode>Di02</stuf:berichtcode>
<stuf:functie>LVBAGPndCombi</stuf:functie>
</stuurgegevens>
<LVBAGPndDi02 functie="dienst" bag:entiteittype="PND">
<parameters>
<bag:mutatiesoort>T</stuf:mutatiesoort>
</parameters>
<toevoeging functie="entiteit" bag:entiteittype="PND">
...
</toevoeging>
</LVBAGPndDi02>
<LVBAGPndDi02 functie="dienst" bag:entiteittype="PND">
<parameters>
<bag:mutatiesoort>I</stuf:mutatiesoort>
</parameters>
<toevoeging functie="entiteit" bag:entiteittype="PND">
...
</toevoeging>
<wijziging functie="entiteit" bag:entiteittype="PND">
...
</wijziging>
<wijziging functie="entiteit" bag:entiteittype="PND">
...
</wijziging>
<wijziging functie="entiteit" bag:entiteittype="PND">
...
</wijziging>
<wijziging functie="entiteit" bag:entiteittype="PND">
...
</wijziging>
</LVBAGPndDi02>
< / LVBAGPndCombiDi02>
Let op: het element "bag:mutatiesoort" in de parameters is van de LVBAG en heeft een andere semantiek dan de mutatiesoort van StUF. Bijvoorbeeld de mutatiesoort "I" (Intrekken) is niet bekend in StUF.
Tijdens de StUF Expertgroep van 15 november 2017 is gesteld dat de vraag
"is de wens van de LV-BAG om meervoudige vrije berichten te kunnen gebruiken terecht?"
een andere vraag is dan
"is de wens om meervoudige vrije berichten in de StUF standaard op te nemen terecht?"
De StUF Expertgroep heeft dan ook goedkeuring gegeven aan het uitwerken van deze RFC.
Een eventuele beperking op het recursief in elkaar opnemen van meervoudige vrije berichten zal niet opgenomen worden in de StUf onderlaag. Het bewaken van het gebruik van die mogelijkheid is een verantwoordelijkheid die ligt bij de diverse koppelvlak-werkgroepen.
Bijgaand de uitwerking van RFC0496 ter goedkeuring tijdens de StUF Expertgroep van 21 februari 2018.
Bijlage
Tijdens de StUF Expertgroep van 21 februari 2018 is de uitwerking van dit RFC besproken. De Waarderingskamer gaf aan nog steeds te vinden dat het onnodig complex wordt, zij zijn dus tegen goedkeuring. De rest van de StUF Expertgroep had er geen problemen mee. Henri zei het handig te vinden dat we dit RFC hebben ook als we StUF 3.02 niet gaan gebruiken. Deze RFC is essentieel als de LV-BAG het op hun eigen manier wil gaan doen zegt hij. Hij vindt het een goede RFC.
Frank stelde voor deze RFC nog even open te laten staan. De StUF Expertgroep ging daarmee akkoord.
LVBAG heeft deze RFC mogelijk wel nodig.
Te weten wanneer meerdere kennisgevingen bij elkaar horen en in 1x verwerkt dienen te worden (in 1 transactie). Dat is nodig om te voorkomen dat er tijdelijke functioneel inconsistente situaties ontstaan.
Enerzijds is het maken van inconsistente situaties niet fijn op zichzelf, maar als je dat wel laat ontstaan, dan krijg je te maken met bijvoorbeeld:
Het concept van 'in 1 transactie verwerken' is gebruikelijk in de IT. Dit concept is ook geïmplementeerd in StUF, alleen nog niet bij dienstberichten.
Eens natuurlijk dat het niet onnodig complex moet worden.
Maar ik zie de complexiteit in deze niet echt. Het is X keer iets wat wel al bekend en standaard is.
Zou dit z.s.m. alsnog op de agenda kunnen, zodat dit mogelijk wordt in StUF 3.01?
De vorm, daar is natuurlijk iets waar je keuzes in kan maken. In de huidige XSD's wordt niet het dienstbericht LVBAGNumDi02 zelf * keer opgenomen, maar wordt de body van dit dienstbericht, het element ... NUM-object.Nummeraanduiding-LVBAG-numDi02 ... als herbruikbare component * opgenomen.