Bij het servicecentrum MER wordt een Zaak- Documentservices koppelvlak gerealiseerd tussen het zaaksysteem van Decos (JOIN Zaak&Document) en GWS4all van Centric. In zowel JOIN Zaak & Document als GWS4all wordt er gewerkt met zaken voor 3 verschillende gemeenten (Maasgouw, Echt-Susteren en Roerdalen).
Om in een StUF bericht te duiden om welke gemeente het gaat maakt JOIN Zaak & Document gebruik van het stuurgegeven 'Administratie'. Het stuurgegeven 'Organisatie' vullen we met een identificerend gegeven van de MER.
GWS4all maakt gebruik van het stuurgegeven 'Organisatie' voor dit doeleinde om te duiden om welke gemeente het gaat. De node 'Administratie' wordt momenteel niet door GWS4all gebruikt.
De documentatie van StUF 3.01 beschrijft het volgende:
4.2 Adressering zender en ontvanger
Net zoals in een brief kunnen in een bericht de geadresseerde (ontvanger) en de afzender (de zender) worden
opgenomen. Hiertoe zijn de stuurgegevens zender en ontvanger gedefinieerd. De stuurgegevens zender en ontvanger zijn verplicht in asynchrone berichten. Deze twee stuurgegevens maken gebruik van een gemeenschappelijke adrestype-definitie. Hieronder worden de verschillende onderdelen van het adrestype gespecificeerd. StUF-berichten worden uitgewisseld tussen geautomatiseerde systemen. Zo’n geautomatiseerd systeem wordt beheerd door een organisatie. Het hoogste niveau in de adrestype is daarom de organisatie. Een organisatie heeft over het algemeen een groot aantal verschillende applicaties en het komt regelmatig voor dat een applicatie verschillende gegevensverzamelingen beheert. Kleine sociale diensten laten bijvoorbeeld hun uitkeringenadministratie uitvoeren door een grotere gemeente in de regio. Deze grotere gemeente gebruikt dan haar eigen sociale dienst applicatie voor het beheren van twee verschillende gegevensverzamelingen: haar eigen gegevensverzameling en de gegevensverzameling van de kleine gemeente die het werk heeft uitbesteed. Ook is het mogelijk dat een gemeente voor een applicatie zowel een productie- als een testomgeving inricht. Omdat een systeem een applicatie is die een eigen gegevensverzameling beheert, is er in StUF voor gekozen om een systeem te identificeren met behulp van twee stuurgegevens: de applicatie en de administratie. Met het stuurgegeven administratie kan onderscheid worden gemaakt tussen de verschillende gegevensverzamelingen die een applicatie beheert.
De stelling van ons (Decos) is:
De tekst beschrijft dat de organisatie die de applicatie beheerd, de organisatie is die in het veld ‘organisatie’ gevoerd zou moeten worden. Daarnaast geeft het een voorbeeld die vergelijkbaar is met de situatie van de MER; die van een grote gemeente die verschillende gegevensverzamelingen beheert waaronder de gegevensverzameling van de andere kleinere gemeente. Het geeft aan dat een gegevensverzameling geduid zou moeten worden in het stuurgegeven ‘administratie’. Ik maak hier dus uit op dat we het hier hebben over de organisatie MER die één applicatie JOIN Zaak&Document beheerd met daarin verschillende gegevensverzamelingen (administraties) van gemeenten Maasgouw, Echt-Susteren en Roerdalen.
De stelling van Centric is:
Naar mijn mening dient deze werkwijze alleen gevolgd te worden als er sprake is van aparte implementaties van dezelfde applicatie. En als dat niet het geval is, zoals bij de GWS implementatie bij de MER gemeenten, dan is het volgens mij meer gebruikelijk om de gemeentecode op te nemen als organisatie in de stuurgegevens.
Wij (Decos en Centric) zouden graag zien dat KING aangeeft wat de juiste implementatie van deze stuurgegevens is.
Ter info: PinkRoccade gebruikt de organisatiecode (met daarin als waarde de gemeentecode) om aan te geven door of voor welke gemeente binnen een samenwerkingsverband de berichten worden verzonden respectievelijk ontvangen. Deze werkwijze komt overigens overeen met de formele afspraken binnen CORV waar echter geen gemeentecode maar het OIN van de betreffende gemeente in de organisatiecode wordt opgenomen. Hoewel de definitie in de standaard niet eenduidig lijkt, dringen wij erop aan om rekening te houden met bestaande implementaties en de wijze waarop dit momenteel wordt gebruikt.
@John, bedankt voor je reactie. Uiteraard ben ik het er mee eens om rekening te houden met bestaande implementaties. Echter hebben wij (Decos) ook bestaande implementaties die inmiddels gebruik maken van het 'Administratie' stuurgegeven. Zo hebben wij bijvoorbeeld een aansluiting met Squit XO van Roxit. Bij ons voorbeeld bij de MER gemeenten koppelen wij aan beide applicaties (Squit XO én GWS4all). Wanneer beide applicaties hier een andere methode voor gebruiken levert dit een probleem op.
KING kan hierover naar mijn mening geen uitspraak doen. Het staat een organisatie vrij om de aanduidingen voor applicaties zelf te kiezen en zowel de aanpak van Decos als die van Centric en Pink zijn valide.
StUF eist wel dat geen enkele partij voorwaarden mag stellen aan de wijze waarop een applicatie zich identificeert in de stuurgegevens, tenzij die zijn beschreven in het betreffende koppelvlak. Centric en Pink zullen dus moeten kunnen werken met de identificatie zoals Decos die hanteert voor JOIN Zaak & Document en Decos zal moeten kunnen werken met de identificatie zoals Centric die hanteert voor GWS4All. Centric zal in mijn ogen sowieso in GWS4All ondersteuning moeten bieden voor het gevuld zijn van het element administratie in berichten van anderen.
Bedankt voor de reactie. Jammer dat KING hier geen stelling in wil nemen. Onze gezamenlijke klanten verwachten van KING juist een eenduidige stelling zodat leveranciers niet zelf een praktische invulling gaan geven aan de standaarden. Deze discussie is wat mij betreft een geweldig voorbeeld waarbij KING als mediator tussen leveranciers kan optreden. Ik zou op zijn minst een advies willen over hoe wij deze situatie zouden moeten oplossen waarbij wij ons zaaksysteem (Decos) moeten koppelen met twee verschillende applicaties (Centric en Roxit) die allebei een andere interpretatie hebben van deze stuurgegevens.
Daarnaast wordt in de documentatie van StUF 3.0.1 wel degelijk beschreven hoe de verschillende stuurgegevens zoals applicatie, organisatie en administratie gebruikt dienen te worden. De beschrijving is echter alleen niet duidelijk genoeg. De stelling dat StUF geen voorwaarden stelt aan de invulling van deze stuurgegevens gaat dus niet op.
KING (zover ik in mijn eentje voor KING mag spreken) doet in de bovenstaande post weldegelijk een uitspraak. De stelling is namelijk dat elke partij zelf mag bepalen hoe de applicatie zich identificeert. Voor het definiëren van de identificatie van een applicatie, oftewel het “endpoint” van de verzender of ontvanger, biedt StUF vier velden (organisatie, applicatie, administratie en gebruiker). Elke partij mag hier haar eigen invulling aan geven zolang de identificatie maar uniek is. De structurering is slechts een hulpmiddel om een leesbare identificatie vorm te geven van de diverse “endpoints” binnen je eigen organisatie. Elke partij moet de identificatie, oftewel de vulling van de bovengenoemde vier velden, van de andere applicatie respecteren.
StUF (en dus ook KING) eist dat geen enkele partij voorwaarden mag stellen aan de wijze waarop een applicatie zich identificeert in de stuurgegevens, tenzij die zijn beschreven in het betreffende koppelvlak.
Dus elke applicatie die niet aan de bovenstaande voorwaarde voldoet, voldoet niet aan StUF en dus ook niet aan de eisen van KING. Uit de eerdere posts krijg ik het gevoel dat zowel Decos als Centric niet voldoen aan deze voorwaarde en dus in dat geval zullen beide partijen hun software moeten aanpassen.
Misschien kan één van de koppelende partijen (Decos of Centric) met weinig moeite een aanpassing doorvoeren in de software waardoor de koppeling snel werkend kan worden gemaakt zonder dat beide partijen tegelijk helemaal moeten voldoen aan StUF. In dat geval zou de opdrachtgevende gemeente of samenwerkingsverband (zoals MER) ervoor kunnen zorgen dat de kosten eerlijk worden verdeeld tussen de koppelende partijen.
De vraag is of het bovenstaande probleem het enige issue is dat speelt. Mogelijk worden de stuurgegevens onterecht gebruikt om te bepalen op welke gemeente (GEM) een zaak (ZAK) betrekking heeft. In dat geval wordt er ook niet voldaan aan StUF. Deze link dient namelijk gelegd te worden in de body van het zaakbericht, bijvoorbeeld met de relatie heeftBetrekkingOp (ZAKOBJ) waarbij het gerelateerde object (OBJ) de gemeente (GEM) is, en niet door middel van de stuurgegevens.
Ik ben het niet geheel eens met de stelling dat StUF geen eisen stelt. In paragraaf 4.2 van de standaard wordt de semantiek van de verschillende onderdelen van de stuurgegevens beschreven en het lijkt me zinvol om die dan ook toe te passen.
Daarnaast is het mijns inziens de bedoeling (of tenminste efficiënt) dat systemen zoals een ESB op basis van de stuurgegevens kunnen bepalen waar een bericht moet worden afgeleverd. De body van een bericht is primair bedoeld om objecten te beschrijven en niet om de routering te bepalen. Dit zou op basis van de stuurgegevens moeten gebeuren.
Los van dit alles vind ik het jammer als KING zich distantieert van de rol om eenduidige afspraken te maken over de toepassing van de StUF stuurgegevens bij het correct adresseren en routeren van berichten.
Zoals John Rooijakkers terecht aangeeft, beschrijft paragraaf 4.2 van de StUF specificatie wel degelijk het gebruik van de 4 verschillende stuurgegevens. De interpretatie er van verschilt echter per leverancier. Vandaar nogmaals het verzoek om verduidelijking. De stelling dat elke leverancier geheel vrij is om er invulling aan te geven spreekt zelfs de huidige specificatie in paragraaf 4.2 tegen.
Het is daarnaast echter simpelweg onpraktisch als er geen richtlijn is die verschillende leveranciers kunnen aanhouden voor de invulling van stuurgegevens. Ik begrijp de theorie erg goed, de praktijk is echter anders. Hier voorkomt gewoonweg problemen en verwarring als elke StUF applicatie binnen een architectuur een vergelijkbare methode hanteert.
Het voorstel voor het gebruik van heeftBetrekkingOp (ZAKOBJ) om de verantwoordelijke gemeente vast te leggen vind ik overigens een prima aanvullend voorstel voor de Zaak- en Documentservices. Dit ontneemt KING echter niet van de verantwoordelijkheid om de gevraagde verduidelijking te verstrekken inzake de stuurgegevens waar Centric, PinkRoccade en Decos om vragen.
Om te beginnen vind ook ik het erg jammer dat er niet wordt gekozen voor duidelijkheid. Alle mogelijkheden open moeten houden is een keuze waarbij niemand gebaat is (behalve degene wie om duidelijheid wordt gevraagd). Zeker in een periode waarin duidelijk is dat de StUF-standaard eenduidiger, eenvoudiger en daardoor beter toepasbaar moet worden, verbaas ik me zeer over deze stellingname.
Ik zou er dus voor willen pleiten dat er meer duidelijkheid komt over de invulling en het gebruik van deze stuurgegevens, waarbij zeker moet worden gekeken naar de verschillende soorten samenwerkingen/configuraties die er momenteel zijn. Ook lijkt het me goed daarbij te kijken of aangesloten kan worden bij afspraken die her en der mogelijk wel al zijn gemaakt (zoals bij CORV).
Met de laatste alinea van de reactie van Henri op 15-1 ben ik het overigens helemaal niet eens. Naast het feit dat de genoemde relatie helemaal niet bedoeld is voor het koppelen van zaken aan gemeenten (dat zou je kunnen/moeten doen met rollen organisatorische eenheden), ben ik het volledig met John eens dat je niet diep in de berichten moet gaan zoeken voor het routeren van berichten. Daarvoor zijn nu juist de stuurgegevens bedoeld.
Volgens mij zijn de stuurgegevens voldoende duidelijk beschreven in par. 4.2. van de StUF 3.01 standaard. Het is helder dat je in het <organisatie>-element geen applicatie invult, maar een organisatie, en dat je in het <applicatie>-element geen gebruiker ingevuld, maar een applicatie, etc. Naar mijn mening is het een terechte bewuste keuze geweest om geen diepere invulling te geven aan deze stuurgegevens. Bijv. met het begrip <organisatie> beland je al snel in een moeras van interpretaties.
Welke organisatie is de beheerder van de applicatie?
En hoe duiden we de beherende organisatie aan?
Naar mijn mening moet je dit soort begrippen flexibel houden in de StUF-onderlaag en de partij zelf, of het koppelvlak (zoals al gedaan is bij CORV) of de keten zelf laten bepalen hoe dit wordt ingevuld. Dus flexibiliteit in de onderlaag en standaardisatie in de eindproducten. Misschien hoort deze discussie meer thuis in het Zaak-Documentservices koppelvlak…
Dit is volgens mij ook meer een organisatorische c.q. semantisch vraagstuk dat niet in de technische StUF-onderlaag thuis hoort. Als er toch goede redenen blijken te zijn om een informatiemodel te ontwikkelen voor het precies definiëren van begrippen zoals Organisatie, Applicatie, Administratie en Gebruiker, denk ik dat KING best wel resources beschikbaar wil stellen, maar ik vrees dat we niet van vandaag op morgen een breed gedragen model gereed hebben. De business-case is voor mij in ieder geval nu nog niet helder.
Bovendien denk ik dat Decos en de MER-gemeenten eerder geholpen willen worden (ik hoorde zelfs via de wandelgangen voor a.s. woensdag!)
Om het eerlijk te zeggen begrijp nog steeds niet wat feitelijke het probleem is! Als ik Ernst Jan Visser goed begrijp dan moet je op de volgende wijze een (zaak)bericht met betrekking tot bijv. de gemeente Maasgouw naar het JOIN Zaak&Document systeem van Decos sturen:
<StUF:ontvanger>
<StUF:organisatie>MER</StUF:organisatie>
<StUF:applicatie>JOIN Zaak&Document</StUF:applicatie>
<StUF:administratie>Maasgouw</StUF:administratie>
</StUF:ontvanger>
En als ik het goed begrepen heb moet je als volgt een (zaak)bericht m.b.t. gemeente Maasgouw naar GWS4all van Centric sturen:
<StUF:ontvanger>
<StUF:organisatie>Maasgouw</StUF:organisatie>
<StUF:applicatie>GWS4all</StUF:applicatie>
</StUF:ontvanger>
Beide adresseringsconventies zijn volgens StUF 3.01 valide en als beide partijen (Centric en Decos) elkaars adressen respecteren is er niks aan de hand en heb je werkende koppeling. Wat is nu precies het probleem? Kan iemand mij dat met een concreet voorbeeldscenario uitleggen?
Trouwens zoals je weet zijn er serieuze plannen om de stuurgegevens in de volgende versie van StUF op te heffen en uit te besteden aan internationale standaarden zoals WS-Addressing. Deze standaarden bieden voor de TO (ontvanger) en FROM (verzender) geen gestructureerd semantisch content-model zoals StUF (organisatie, applicatie, registratie, gebruiker) . De TO en FROM velden zijn dan in beginsel betekenisloze “platte” URI’s (of tegenwoordig IRI’s). Blijkbaar geven de internationale standaarden ook hun voorkeur aan flexibiliteit als het gaat om het adressering van berichten.
Tijdens de StUF Expertgroep van 20 januari 2016 is aangegeven dat leveranciers elkaars adressen dienen te respecteren en geen enkele partij aanvullende voorwaarden mag stellen aan de wijze waarop een andere partij haar applicaties identificeert in de stuurgegevens (binnen de eisen van StUF), tenzij er aanvullende voorwaarden zijn beschreven in het koppelvlak (bijv. zoals bij CORV). Deze interpretatie zal verduidelijkt worden in de StUF 3.01 documentatie en gepubliceerd worden in de volgende patch.
Hiertoe is onderhoudsverzoek ERR0425 is opgevoerd in de onderhoudsverzoeken.
De lijst met onderhoudsverzoeken vind je op:
gemmaonline.nl/index.php/StUF-Expertgroep#Documenten
Henri en Robert, bedankt voor jullie reactie. Ook al had ik (en de overige leveranciers met mij) liever een ander standpunt of een richtlijn gezien is het nu duidelijk dat elke leverancier in staat dient te zijn elkaars stuurgegevens, hoe verschillend in gebruik ook, te respecteren.
Omdat er binnen de koppelvlak-specificatie 'Zaak- en documentservices' geen aanvullende afspraken op dit vlak gemaakt zijn, zullen wij er voor zorgen dat we het stuurgegevens-gebruik van zowel Centric als Roxit tegelijkertijd kunnen ondersteunen.
Daarnaast verwachten we van Centric dat zij ons stuurgegevens-gebruik kunnen ondersteunen.
Samenvattend moet JOIN Zaak & Document van Decos dus om kunnen gaan met verschillende waarden in de 'Organisatie' node in de communicatie van en naar Centric Key2Vergunningen waarmee Centric de gemeentelijke gegevensverzameling aanduid. Daarnaast moet Centric Key2vergunningen de 'Administratie' node kunnen interpreteren waarmee JOIN Zaak & Document de gemeentelijke geversverzameling duidt.
Bovenstaande discussie gaat over het uitwisselen van STUF berichten op basis van de 3.01 standaard. Hoe zit dit
voor STUF berichten op basis van de 02.04 standaard?
Roger,
Ik zie geen reden om aan te nemen dat dit voor StUF 2.04 anders ligt. Feitelijk is er op dit punt niet zo veel verandert tussen StUF 2.04 en StUF 3.01.
Zoals beloofd in de laatste StUF Expertgroep heb ik de interpretatie in paragraaf 4.2 van de standaard verduidelijkt (zie daarvoor de bijgaande PDF met de pagina's 45 en 46 van de StUF standaard.
Deze aanpassing zal na goedkeuring worden meegenomen in patch 24. Indien gewenst zal ik dezelfde toevoeging ook aanbrengen in de StUF 2.04 standaard.
Bijlage
Hoi Robert,
Mijn interpretatie van de discussie in de expertgroep was dat (als er geen nadere afspraken zijn gemaakt) de ontvanger van het bericht mag bepalen welke gegevens er in het element <ontvanger> zijn gevuld en met welke waarde. De verzender van het bericht bepaalt zijn eigen adres en dus ook de gegevens in het <zender>-element. Dit zijn immers de gegevens die in een antwoord weer als <ontvanger> moeten worden ingevuld (lijkt mij).
Klopt dit met jouw interpretatie? Ik lees het zelf (impliciet) terug in de zin "Partijen dienen elkaars adressen dan ook te respecteren en geen enkele partij mag aanvullende voorwaarden stellen aan de wijze waarop een andere partij haar applicaties identificeert in de stuurgegevens...".
Misschien is het toch goed dit expliciet te benoemen (tenzij ik het verkeerd begrepen heb, natuurlijk). Ik heb gemerkt dat dit anders toch wel tot wat verwarring kan leiden.
Groet,
Sid.
Hoi Sid,
Volgens mij moet het inderdaad op de door jou geschetste wijze geïnterpreteerd worden. Lijkt me een hele goede toevoeging die ik dan ook al in het hernieuwde voorstel heb verwerkt.
Bijlage
Na de expertgroep van 16-3 heb ik nog een keer gekeken naar de bezwaren die ik in het overleg heb benoemd, maar niet voldoende kon duiden. De bezwaren slaan op de zin: "Partijen dienen elkaars adressen dan ook te respecteren en geen enkele partij mag aanvullende voorwaarden stellen aan de wijze waarop een andere partij haar applicaties identificeert in de stuurgegevens (binnen de eisen van StUF), tenzij er aanvullende voorwaarden zijn beschreven in een koppelvlak."
Een punt waar onduidelijkheid over zou kunnen ontstaan is de vraag waar het hierboven schuin- en vetgedrukte ‘haar’ naar verwijst. Je kunt hem daardoor op twee manieren lezen:
Ik denk dat je deze zin heel goed zou kunnen combineren met de alinea eronder en (meteen ook) met de aanvulling over het uniek moeten zijn van de adressen die is genoemd tijdens het overleg. Ik had zelf dan het volgende voorstel in gedachten (dus met weghalen van de zin die ik hierboven heb geciteerd):
Ik heb hierin ook bewust de term applicatielandschap weggelaten, omdat applicaties in verschillende landschappen opereren. Mocht je dan stellen dat die landschappen één landschap worden, dan is al snel heel de Nederlandse overheid één applicatielandschap. De essentie is dat een ontvanger de verschillende verzenders van berichten (die het ontvangt) eenduidig moet kunnen identificeren aan de hand van de <zender>-gegevens.
Tijdens de StUF Expertgroep van 16 maart 2016 is de oplossing goedgekeurd onder voorbehoud dat er een fragment aan de nieuwe tekst wordt toegevoegd waarin wordt gesteld dat een adres uniek moet zijn binnen elk applicatie landschap. Sid Brouwer heeft echter na de betreffende StUF Expertgroepbijeenkomst in de bovenstaande reactie een aangepaste tekst voorgesteld. Indien deze door de StUF Expertgroepleden wordt goedgekeurd dan zal de voorgestelde oplossing nog worden meegenomen in patch 24, zo niet dan wordt het erratum aangehouden.
De tekst van Sid lijkt me heel goed te verwoorden wat we willen. Dank daarvoor.
Ik kan mij ook goed vinden in het voorstel van Sid.
Met de ervaring van het CORV koppelvlak 0.94 in gedachten zou ik graag willen toevoegen dat de waarden in de zender(s) ook moeten afwijken van de waarden in de ontvanger(s). Bij CORV worden bepaalde notificatieDi01 berichten van applicatie="applicatie" verzonden naar applicatie="applicatie". Met name bij het verzenden van retour berichten leverde dit problemen op bij het correct afleveren van deze berichten door een intermediaire node (ESB).
Daarnaast is mijn aanname dat een intermediaire node zoals een ESB, ook als een applicatie gezien moet worden en dat hierbij de zelfde eisen gelden. Ik zie dat in het voorstel niet terug maar wellicht kan hierover ook iets opgenomen worden.
Groeten, John.
Het lijkt me goed om expliciet te maken dat een zender altijd een ander combinatie van organisatie, applicatie en administratie moet hebben als een ontvanger en dat deze eis geldt voor alle zenders/ontvangers waarmee een partij te maken heeft.
Het al dan niet aanwezig zijn van een intermediaire nodes is niet relevant voor de naamgeving van de applicaties, omdat in de stuurgegevens de zender moet staan die het bericht als eerste verzendt en als ontvanger het systeem dat een Bv03-bevestiging verstuurt. De intermediaire nodes zijn voor StUF in zekere zin onzichtbaar, omdat StUF de end-to-end werkt.
Aangezien er toch nog wat discussie is over de exacte inhoud van de op te nemen tekst is besloten dit erratum niet mee te nemen in patch 24.
Bij deze n.a.v. de reacties van John en Maarten een nieuw voorstel. Natuurlijk op basis van de eerder door Sid voorgestelde tekst.
Bijlage
Tijdens de StUF Expertgroep van 20 april 2016 is het voorstel goedgekeurd.