Bij het verstuffen van het RGBZ naar het sectormodel Zaken versie 03.10 is veel gediscussieerd over de wijze waarop de relatie tussen een Zaak (ZAK) en een Enkelvoudig document (EDC) gemodelleerd zou moeten worden. Nadat in eerste instantie (eind 2009) de relatie EDC-ZAK in de kennisgeving was opgenomen, is later (en huidige status) alsnog gekozen voor de relatie ZAK-EDC. Heel concrete argumenten voor deze keuze waren er toen niet, maar nu wij het sectormodel Zaken versie 03.10 aan het realiseren zijn, komen wij tot de conclusie dat de gekozen modellering niet de juiste is en stellen daarom als erratum voor om alsnog voor de relatie EDC-ZAK te kiezen.
Huidige situatie
Momenteel is in een kennisgeving van Zaak (ZAK) de relatie met een Enkelvoudig document (ZAK.heeftRelevant.EDC) opgenomen. In het gerelateerde Enkelvoudig document zijn (standaard) alleen de kerngegevens opgenomen. De inhoud en veel andere relevante gegevens om een document op te slaan zijn hierin dus niet opgenomen (de consequentie hiervan lijkt bij het verstuffen destijds onvoldoende onderkend). Voor het toevoegen van een document bij een zaak zijn hierdoor altijd twee kennisgevingen nodig: een ZAK kennisgeving waarin het nieuwe document aan de zaak wordt gerelateerd en een EDC kennisgeving waarin alle gegevens (inclusief de inhoud) van het document worden geleverd. Indien eerst de EDC kennisgeving wordt verstuurd ontstaat er nog een tweede issue namelijk dat dit dan tijdelijk een zaakloos document is. Aangezien document management systemen documenten veelal opslaan binnen mappen die overeenkomen met zaken, zal hierdoor bij het vervolgens relateren van het toegevoegde (zaakloos) document aan een zaak een onnodige verplaatsing van het document moeten plaatsvinden.
Gewenste situatie
Voorgesteld wordt om in de kennisgeving van het Enkelvoudig document (EDC) de relatie met de Zaak (EDC.isRelevantVoor.ZAK) op te nemen (zoals deze ook reeds in het antwoordbericht van een document is opgenomen). Hierdoor is het mogelijk om met één kennisgeving een (zaakgebonden) document toe te voegen en direct te relateren aan de juiste zaak waarbij alle relevante informatie van het document (inclusief de inhoud) in het bericht kan worden opgenomen. Uiteraard is het zo dat hiermee niet in één bericht een nieuwe Zaak en een daaraan gerelateerd document (inclusief inhoud) toegevoegd kan worden. Dit is echter (zoals beschreven) in de huidige situatie ook niet het geval. Daarnaast is het goed om vast te stellen dat het toevoegen van documenten aan een zaak in het overgrote deel van de gevallen gebeurt indien de zaak reeds bestaat.
Overige informatie
In zowel de huidige als de gewenste situatie is en blijft het mogelijk om in een Zaak vraag ook de relatie met het Enkelvoudig document (ZAK.heeftRelevant.EDC) te vragen.
Aan de StUF expertgroep wordt gevraagd om bovenstaande als erratum in de huidige versie van het sectormodel door te voeren en niet als een RFC in de volgende versie van het sectormodel. De reden hiervoor is tweeledig. Enerzijds lijkt het onwaarschijnlijk dat er reeds leveranciers de huidige modellering hebben geïmplementeerd gezien de problemen die dat met zich meebrengt en het feit dat er nog geen meldingen hierover op het forum zijn geplaatst. Anderzijds leidt een aanpassing in een volgende release tot complexe transformaties tussen de betreffende versies van het sectormodel. Met dit laatste aspect zullen we steeds vaker rekening moeten houden indien de intensiteit van het gebruik van StUF toeneemt en het steeds meer ongewenst wordt om de overgang naar een nieuwe versie van een sectormodel voor alle betrokken applicaties op één en hetzelfde moment bij een gemeente te implementeren.
Met vriendelijke groet,
John Rooijakkers
Hallo John,
Ik heb inhoudelijk geen probleem met je voorstel en kan me vinden in je argumentatie, maar wil nog wel even terughalen waarom toentertijd gekozen is voor de voorgestelde modellering.
De zaak werd gezien als de eigenaar van het document en om die reden is ervoor gekozen om de relatie te leggen vanuit het ZAAK, het objecttype dat gezien wordt als eigenaar van de gerelateerde. PinkRoccade heeft voor deze modellering gepleit, omdat die het gemakkelijker maakt om in een gegevensmakelaar mutaties door te geven naar afnemers.
Op het moment dat we al implementerende vaststellen dat dit toch niet het juiste criterium lijkt te zijn, dan kan ik me voorstellen dat we dit via een erratum oplossen. Het lijkt me dan wel goed om even alle relaties onder de loep te nemen, want ook voor andere relaties is bovenstaand criterium toegepast.
Maarten
Hallo Maarten,
Wij hebben vooral bepleit (of in ieder geval getracht dit te doen) dat een relatie altijd slechts één eigenaar entiteit heeft en dus altijd vanuit één kant onderhouden wordt via kennisgevingen.
Wellicht dat hier verwarring bestaat met de discussie over het modelleren van de Zaak-Status(type) relatie, waarbij wij wel nadrukkelijk gepleit hebben om deze vanuit Zaak te onderhouden.
Al met al voldoende reden om het woensdag te bespreken.
Groeten, John.
Beste John en Maarten,
Als ik bovenstaande stukken zo lees dan verbaast mij het een en ander. Volgens mij gaat StUF 03.01 uit van een Diensten Gerichte Architectuur, waarbij applicaties elkaar informeren middels berichten over het ontstaan en wijzigen van entiteiten.
Wanneer het gaat om entiteiten die onafhankelijk van elkaar kunnen ontstaan (bv ZAK en EDC) dan heeft het mijns inziens geen zin te praten over de eigenaar van de twee entiteiten; de twee entiteiten kunnen aangemaakt worden in twee applicaties (bijvoorbeeld een zaken applicatie en een DMS). De opmerking over een zaakloos document lijkt mij een bevestiging van deze redenering.
Als er sprake is van onafhankelijke entiteiten met een wederkerige relatie (bv ZAK.heeftRelevant.EDC en EDC.isRelevantVoor.ZAK) dan heeft het mijns inziens geen zin te praten over de eigenaar van de relatie. Er zijn immers twee relaties.
Los van bovenstaande filosofische redenen, lijkt het me vanuit het oogpunt van verstuffing ook totaal niet nodig te praten over de eigenaar van de relatie. Relaties zijn onderdeel van berichten. De berichten geven aan dat iets is ontstaan of gewijzigd (kennisgevingsberichten) of als zodanig is geregistreerd (vraag en antwoordberichten). De berichten zeggen niets over hoe een en ander in een database moet worden gemodelleerd. Ongeacht of een relatie in één of twee tabellen van één of twee applicaties zit.
Eerste scenario.
Als een zaken applicatie als eerste een ZAK registreert dan kan er nog geen sprake zijn van een relevant EDC. De zaken applicatie zal dus een ZAK bericht versturen zonder relatie ZAKEDC (heeftRelevant) naar een gerelateerde EDC.
Als vervolgens een DMS een EDC opslaat en als de DMS zich geabbonneerd had op de ZAK berichten dan kan de DMS een EDC bericht versturen met daarin opgenomen de relatie EDCZAK (isRelevantVoor).
Omdat de zaken applicatie niet zelf het document heeft opgevoerd (of zelfs kan opvoeren) lijkt het mij verstandig als de zaken applicaties zich abonneert op EDC berichten. Hé verrek. er is een EDC opgevoerd met een relatie naar een ZAK die ik heb opgevoerd. Zal ik de relatie dan ook maar opslaan? Bij een toekomstige bevraging kan de zaken applicatie dan antwoorden dat de ZAK een relevante EDC heeft.
Tweede scenario
Als een DMS applicatie als eerste een EDC registreert dan is dat een zaakloos document. Er is dan nog niet sprake van een ZAK waarvoor dit document relevant is. De DMS zal dus een EDC bericht versturen zonder relatie EDCZAK (isRelevantVoor) naar een gerelateerde ZAK.
Als in tweede instantie in de zaken applicatie een ZAK wordt opgevoerd dan zal allicht de gebruiker de ZAK kunnen onderbouwen met relevante documenten (door op dat moment de DMS te vragen om een lijst van EDCs of doordat de zaken applicatie zich heeft geabonneerd op EDC berichten en dus zelf altijd een up-to-date lijst met EDCs heeft). De zaken applicatie kan dus een ZAK kennisgeving uitsturen met daarin opgenomen de ZAKEDC relatie (heeftRelevant) naar de gerelateerde EDC.
Een DMS applicatie die EDC opslaat die relevant kunnen zijn voor meerdere soorten entiteiten, waaronder ZAK, zal zich allicht abonneren op ZAK berichten, zodat de kennisgeving informatie verschaft over de ZAKEDC relatie. De DMS applicatie kan deze relatie dan opslaan bij zijn EDC. Bij een toekomstige bevraging kan hij dan antwoorden dat met de EDC en een EDCZAK (isRelevantVoor) relatie naar de gerelateerde ZAK.
Conclusie: in deze twee scenarios voeren een zakenapplicatie en een DMS applicatie ieder hun eigen entiteiten op. Als beide applicaties weet hebben van de mogelijke relatie tussen een ZAK en een EDC dan kunnen beide applicaties de relatie ZAKEDC dan wel EDCZAK opvoeren. In het berichten verkeer gaat het hierbij om verschillende relaties. In een database zal het waarschiijnlijk gemodelleerd worden als een enkele relatie die vanuit beide kanten bevraagd kan worden. Met andere woorden, een zaken applicatie kan het hebben over ZAKEDC relaties en een DMS aplicatie kan het hebben over EDCZAK relaties, maar in beide gevallen gaat het over een wederkerige relatie tussen een ZAK en een EDC (of omgekeerd).
Laatste opmerking: de uitspraak "aangezien document management systemen documenten veelal opslaan binnen mappen die overeenkomen met zaken" lijkt me niet doorslaggevend om in deze materie een keuze te maken. Het geeft blijk van een implementatie keuze in een DMS die niet relevant zou moeten zijn voor een zakenapplicatie noch voor het objectmodel van de StUF berichten.
Mijn voorstel is daarom dat in voorkomende gevallen wederkerige relaties niet beperkt worden in het berichtenverkeer (noch bij kennisgevingen, noch bij bevragingen).
Met vriendelijke groeten,
Han Welmer
Hallo Han,
Volgens mij moeten we twee dingen hier uit elkaar halen.
Jij betoogt om in algemeenheid anders met relaties om te gaan. Ik ben hier geen voorstander van, maar deze post lijkt me niet de beste plek om hierop in te gaan. Ik stel voor om jouw voorstel in een seperate RFC te posten.
In de huidige Erratum verzoek stel ik "slechts" voor om de bestaande relatie van ZAK->EDC te corrigeren in EDC-ZAK. Hoe sta je hier tegenover, los van je algemenere voorstel om anders om te gaan met relaties?
Groeten, John
Centric is het eens met het voorstel van John om de relatie ZAK --> EDC te corrigeren in EDC --> ZAK.
Vanuit het RGBZ gezien is er niet direct een voorkeur. Het is een implementatiekeuze hoe te komen van een informatiemodel naar een berichtenmodel.
Aardig in dit verband zijn de keuzes die binnen het RGBZ gemaakt moeten worden bij het 'verUMLen' daarvan. Dat dwingt o.a. af dat een relatie één kant op gelegd wordt. De vraag is welke kant, in dit geval bij de relatie ZAAK - DOCUMENT. Als regel geldt daarbij 'wie heeft kennis van wat? (bij registratie)'. In dit geval geldt m.i. dat 'het document kennis heeft van de zaak(en) waar het bij hoort'. Niet persé omgekeerd. Dat strookt dus met het wijzigingsvoorstel. Dat lijkt me dan ook een goede 'zaak'.
Bovenstaande discussie heeft geleid tot een erratum op sectormodel zkn0310:
ERR0176: De relatie EDCZAK toegevoegd binnen EDC-kennisgeving en de relatie ZAKEDC verwijderd binnen ZAK-kennisgeving.
Het betreft besluitnummer 43 in de besluitenlijst van de expertgroep:
www.kinggemeenten.nl/.../...roep juni 2011.pdf
Ter aanvulling: erratum ERR0176 is verwerkt in file zkn0310.ent.xsd in de patch van april j.l.