› download › attachments › 154403135... · web view exxellence zaaksysteem - zaak-dmselke...

Exxellence ZaakSysteem - Zaak-DMS

Analyse / MappingA.K. Boerma

16 januari 2019Versie 1.26

VersiebeheerVersie

Datum Auteur Omschrijving reden nieuwe versie

0.1 16-07-2013

Anton Boerma

0.2 04-11-2014

Michiel Koster Toevoeging working assumption voor aanmaak stories

1.3 13-02-2015

Bastiaan Klaij Updaten na review commentaar JNET.

1.4 31-3-2015 Bastiaan Klaij Mapping voor unit en employee toegevoegd aan ‘Geef Zaakdetails’1.5 01-04-

2015Bastiaan Klaij StUF mapping toegevoegd voor

heeftAlsInitiator heeftAlsVerantwoordelijke medewerker organistorischeEenheid natuurlijkPersoon nietNatuurlijkPersoon vestiging

1.6 02-04-2015

Bastiaan Klaij Mapping toegevoegd voor Geef zaakdocument lezen antwoordbericht (edcLa01) Geef zaakdocument bewerken antwoordbericht

(geefZaakdocumentbewerken_Du02) Verwijzing gemaakt van creeer zaak naar zaakdetails

mapping tabel1.7 04-30-

2015Bastiaan Klaij Operatie mapping bijgewerkt voor

Update Zaak Update Zaakdocument

1.8 10-05-2016

Bastiaan klaij Mapping toegevoegd voor ‘heeftBetrekkingOp’ Uitleg toegevoegd gebruik ‘verwerkingssoort’ attribuut voor

updateCaseStuf operatie

1.9 24-05-2016

Bastiaan Klaij Mapping bijgewerkt voor ‘heeftBetrekkingOp’ Mapping toegevoegd voor caseRelations

1.10 6-10-2016 Bastiaan Klaij CaseRelations toegevoegd aan beschrijving verwerkingssoort

Mapping initiatingActor en responsibleActor vereenvoudigd1.13 21-06-

2016Ewald Wittrock

Versie nummer gelijk trekken met alfresco Toevoegen status type aan Geef zaakdetails

antwoordbericht1.14 27-06-

2016Ewald Wittrock

Aanpassingen table 20 heeftAlsOverigeBetrokkene roleTypeCode

1.15 04-07-2016

Ewald Wittrock

Toevoegen mapping voorletters in Tabel 24

1.16 06-07-2016

Bastiaan Klaij Regels toegevoegd voor mapping van 2 <object> elementen bij de update zaak

CaseRelations mapping toegevoegd aan creeer zaak1.17 07-07-

2016Bastiaan Klaij User mapping toegevoegd StUF stuurgegevens

1.18 10-11-2016

Erwin Platenkamp

3 nieuwe extra elementen toegevoegd.- “kanaal” onder het zaakobject.

“emailadres” en “telefoonnummer” onder het “heeftAlsInitiator” object.

1.19 04-03-2017

Bastiaan Klaij ‘code’ veld toegevoegd aan Actualiseer zaakstatus bericht

1.20 11-05-2017

Ivo ten Tije De relatie heeftAlsDeelzaak’ word nu gemapt naar VVZK

1.21 07-06-2017

Ewald Wittrock

Aanpassingen table 20 heeftAlsOverigeBetrokkene roleTypeCode zonder mapping overnemen van code.

1.22 13-11-2017

Ewald Wittrock

Aanpassingen Tabel 45 voor STP compliance- Documentformaat mappen naar format

1.23 21-12-2017

Ewald Wittrock

Toevoegen Zaak-DMS 1.2 optie aan Update Zaakdocument zonder document inhoud procedure.

Toevoegen security header 3.3.1 Exxellence Suite 7.0 en hoger

© Copyright 2019 Exxellence All rights reserved Exxellence ZaakSysteem - Zaak-DMS 2

1.24 07-08-2018

Ewald Wittrock

Mapping heeftBetrekkingOpAndere naar VVZK (was IGA) en heeftAlsDeelzaak naar KVU (was ook KVU) in Tabel 20, Tabel 32, Tabel 33, Tabel 36 en Tabel 37

1.25 20-11-2018

Ewald Wittrock

SD-21549 default contentType toegevoegd in Tabel 48 en Tabel 49

SD-23526 extraElementen voor registratienummer and registratienummercode. Tabel 20 en Tabel 35

SD-23555 add mapping for document status. Tabel 43, Tabel45, Tabel 47 , Tabel 48 and Tabel 49

SD-23528 en SD-23605 toevoegen extraElementen locatie, OloNummer en urgent in Tabel 35

1.26 16-01-2019

Ewald Wittrock

ES-3365 identifier matcher objectType’s and transformations.

WijzigingenoverzichtVersie Wijzigingen

ReviewoverzichtVersie Datum Reviewer(s)


Inhoudsopgave2.1 Ander zaak object...........................................................................................................................92.2 Status...........................................................................................................................................112.3 Statustype....................................................................................................................................162.4 Zaakdocument en document.......................................................................................................222.5 Zaakobject en object....................................................................................................................283.1 Metadatering................................................................................................................................303.2 Services........................................................................................................................................32

3.2.1 Geef Zaakstatus...................................................................................................................323.2.2 Geef Zaakdetails...................................................................................................................333.2.3 Actualiseer Zaakstatus.........................................................................................................423.2.4 Creëer Zaak..........................................................................................................................443.2.5 Update Zaak.........................................................................................................................473.2.5.1 Gebruik verwerkingssoort.................................................................................................483.2.6 Genereer Zaakidentificatie...................................................................................................503.2.7 Geef lijst Zaakdocumenten...................................................................................................523.2.8 Geef Zaakdocument lezen....................................................................................................543.2.9 Geef zaakdocument bewerken.............................................................................................553.2.10 Voeg Zaakdocument toe......................................................................................................563.2.11 Maak Zaakdocument............................................................................................................573.2.12 Update Zaakdocument.........................................................................................................583.2.13 Genereer Documentidentificatie...........................................................................................593.2.14 Cancel CheckOut..................................................................................................................59

3.3 User mapping...............................................................................................................................613.3.1 Security header Exxellence Suite 7.0...................................................................................613.3.1.1 Voorbeeld security header................................................................................................61

3.4 Identifier matcher.........................................................................................................................623.4.1 Object type names...............................................................................................................623.4.2 Transformations....................................................................................................................62


Lijst van figurenFiguur 1 – Zaak, document en status entiteiten...........................................................................................8Figuur 2 – Ander zaakobject datamodel.....................................................................................................10Figuur 3 – Status datamodel.......................................................................................................................12Figuur 4 – Zaaktype – statustype datamodel..............................................................................................18Figuur 5 – Zaaktype – staptype - statustype datamodel.............................................................................19Figuur 6 – Zaaktype – staptype - statustype datamodel.............................................................................21Figuur 7 – Document datamodel.................................................................................................................24Figuur 8 – Zaakdocument datamodel.........................................................................................................26Figuur 9 – Zaken DMS boom.......................................................................................................................27Figuur 10 – Zaakobject - object datamodel (deels).....................................................................................29Figuur 11 – Zaaksysteem met directe toegang tot DMS.............................................................................53

Lijst van tabellenTabel 1 – Attributen ander zaakobject..........................................................................................................9Tabel 2 – Attributen status entiteit.............................................................................................................11Tabel 3 – Relaties status entiteit................................................................................................................13Tabel 4 – Attributen statustype entiteit......................................................................................................17Tabel 5 – Relaties statustype entiteit.........................................................................................................17Tabel 6 – Nummering statustypes..............................................................................................................20Tabel 7 – Attributen document / samengesteld document entiteit.............................................................22Tabel 8 – Attributen enkelvoudig document entiteit...................................................................................23Tabel 9 – Relaties enkelvoudig en samengesteld document entiteit..........................................................24Tabel 10 – Attributen zaakdocument entiteit.............................................................................................25Tabel 11 – Relaties zaakdocument entiteit.................................................................................................25Tabel 12 – Attributen zaakobject entiteit....................................................................................................28Tabel 13 – Attributen zaakobject entiteit....................................................................................................28Tabel 14 – RGBZ object specialisaties........................................................................................................28Tabel 15 – RSGB object specialisaties........................................................................................................29Tabel 16 – RGBZ attributen in het DMS......................................................................................................31Tabel 17 – Geef zaakstatus vraagbericht (zakLv01)...................................................................................32Tabel 18 – Geef zaakstatus antwoordbericht (zakLa01).............................................................................33Tabel 19 – Geef zaakdetails vraagbericht (zakLv01)..................................................................................33Tabel 20 – Geef zaakdetails antwoordbericht (zakLa01)............................................................................35Tabel 21 - StUF heeftAlsBelanghebbende mapping....................................................................................36Tabel 22 – StUF medewerker mapping.......................................................................................................37Tabel 23 - StUF organisatorischeEenheid mapping....................................................................................37Tabel 24 - StUF natuurlijkPersoon mapping...............................................................................................38Tabel 25 - StUF nietNatuurlijkPersoon mapping.........................................................................................38Tabel 26 - StUF vestiging mapping.............................................................................................................39Tabel 27 - StUF verblijfadres mapping........................................................................................................39Tabel 28 - StUF sub.correspondentieAdres mapping 1...............................................................................40Tabel 29 - StUF sub.correspondentieAdres mapping 2...............................................................................40Tabel 30 - StUF sub.correspondentieAdres mapping 3...............................................................................40Tabel 31 - StUF heeftBetrekkingOp mapping.............................................................................................41Tabel 32 - StUF heeftBetrekkingOpAndere mapping..................................................................................41Tabel 33 - StUF heeftAlsDeelzaak mapping................................................................................................41Tabel 34 – Actualiseer zaakstatus kennisgevingsbericht (zakLk01)...........................................................43Tabel 35 – Creëer zaak kennisgevingsbericht (zakLk01)............................................................................46Tabel 36 - StUF heeftBetrekkingOpAndere mapping update......................................................................47Tabel 37 - StUF heeftAlsDeelzaak mapping update....................................................................................48Tabel 38 - verwerkingssoort.......................................................................................................................48Tabel 39 - verwerkingssoort per element...................................................................................................49Tabel 40 - mapping regels StUF zakLk01 bij gebruik 2 <object> elementen.............................................50Tabel 41 – Genereer zaakidnetificatie antwoordbericht (Du02) .................................................................51Tabel 42 – Geef lijst zaakdocumenten vraagbericht (zakLv01)..................................................................52Tabel 43 – Geef lijst zaakdocumenten antwoordbericht (zakLa01)............................................................52Tabel 44 – Geef zaakdocument lezen vraagbericht (edcLv01)...................................................................54Tabel 45 – Geef zaakdocument lezen antwoordbericht (edcLa01).............................................................54Tabel 46 – Geef zaakdocument bewerken vraagbericht (geefZaakdocumentbewerken_Di02)..................55Tabel 47 – Geef zaakdocument bewerken antwoordbericht (geefZaakdocumentbewerken_Du02)............56


Tabel 48 – Voeg zaakdocument toe vraagbericht (edcLk01)......................................................................57Tabel 49 – Maak zaakdocument vraagbericht (edcLk01)............................................................................58Tabel 50 – Genereer documentidentificatie antwoordbericht (genereerDocumentIdentificatie_Du02).59Tabel 51 – Cancel checkout vraagbericht...................................................................................................60Tabel 52: user mapping cases.wsdl en documents.wsdl naar requestProperties.......................................61Tabel 53: user mapping DocumentVaultSynchConnector.wsdl en documents.wsdl naar provider............61Tabel 54: user mapping CasesProxy, DocumentServiceProxy en

DocumentVaultSynchConnectorProxynaar requestProperties...........................................................61Tabel 55: user mapping DocumentVaultSynchConnector.wsdl en documents.wsdl naar provider............61Tabel 56: identifier matcher object types...................................................................................................62Tabel 57: identifier matcher request transformations................................................................................62Tabel 58: identifier matcher response transformations..............................................................................62


1. InleidingHet Exxellence ZaakSysteem 5.2 krijgt een gestandaardiseerde architectuur voor het verwerken van zaken en documenten. In deze architectuur wordt het o.a. mogelijk om per zaaktype een primair DMS in te stellen. Daarnaast dient deze architectuur aansluiting van de KING specificatie voor zaaken documentservices te faciliteren. De zaaken documentservices is een specificatie (zie [D1]) die een standaardkoppelvlak moeten bieden voor applicaties die met zaken en documenten werken.

Eén van de uitgangspunten van elke KING standaard is een maximaal hergebruik van bestaande standaarden, voor de zaaken documentservices is dit voornamelijk het Referentiemodel Gemeentelijke Basisgegevens Zaken (RGBZ) versie 1.0 (zie [D2]). In deze analyse / calculatie wordt beschreven hoe datamodel, metadatering en services aangepast moeten worden om de zaaken documentservices te kunnen realiseren. Per onderdeel wordt aangegeven of het essentieel is voor de realisatie van zaaken documentservices voor het Exxellence ZaakSysteem 5.2 of dat het eventueel doorgeschoven kan worden naar een latere versie.

In hoofdstuk 2 wordt beschreven hoe het datamodel van het Exxellence ZaakSysteem aangepast moet worden om beter te conformeren aan de definities van de entiteiten zoals deze vastgelegd zijn in het RGBZ 1.0 model. Een betere aansluiting op het RGBZ 1.0 model vereenvoudigt uiteindelijk de implementatie van de zaaken documentservices. In hoofdstuk 3 wordt de huidige metadatering in Alfresco beschreven en de wijze waarop deze aangepast kan worden voor de zaaken documentservices. Daarnaast worden in dit hoofdstuk de te implementeren services beschreven alsmede de wijze waarop de bestaande services aangepast moeten worden die hiervoor gebruikt gaan worden.


2. RGBZ 1.0Voor de zaaken documentservices moeten een aantal services gerealiseerd worden waarvan de vraag- en antwoordberichten in hoge mate gebaseerd zijn op de RGBZ 1.0 standaard. In dit hoofdstuk wordt beschreven welke entiteiten in het Exxellence ZaakSysteem aangepast moeten worden om beter te conformeren aan de RGBZ 1.0 standaard zodat de zaaken documentservices eenvoudiger geïmplementeerd kunnen worden. In Figuur 1 zijn deze entiteiten en hun onderlinge relaties schematisch weergegeven.

Zaak

Zaaktype Staptype Statustype

Stap Status

wordt deels afgehandeld via

is overgang tussen twee

is van type is van type

leidt tot

is deels afgehandeld in

is van type

Documenttype

Document

heeft

is toegevoegdin

is van type

heeft documenten van type

kan toegevoegdworden in

Resultaattype

Resultaat

heeft

is van type

Besluit

Besluittype

is van type

vastgelegdin

vastgelegdals

heeft resultatenvan type

heeft besluiten van type

leidt totvastgelegd in

documentvan type

heeft

Figuur 1 – Zaak, document en status entiteiten.

De in dit hoofdstuk beschreven modellering is gebaseerd op RGBZ 1.0 standaard en de bijbehorende StUF Zaken 3.10 interface. Helaas blijken de standaard en de interface op een aantal plaatsen met elkaar in tegenspraak te zijn, in het RGBZ worden meerdere attributen beschreven die niet via de StUF interface op te vragen / te wijzigen zijn. Enig speurwerk in de KING groepen lijkt erop te wijzen dat er voor deze verschillen in de toekomst mogelijkerwijs errata komen. Concreet betekend dit echter wel dat bepaalde gegevens niet via een StUF interface (i.e. StUF Zaken of StUF Zaak-DMS) op te vragen en te wijzigen zijn.

In de volgende secties worden kort de status en statustype entiteiten besproken. Voor deze beschrijving van deze entiteiten wordt gebruik gemaakt van stijl die ook gehanteerd wordt in de diverse landelijke standaarden (zie [D1] en [D2]). In de overzichten van attributen en relaties worden de volgende conventies gehanteerd:

attributen en relaties met een afwijkende definitie zijn vet weergegeven; ontbrekende attributen en relaties zijn in licht grijs weergegeven; toegevoegde attributen en relaties zijn onderstreept weergegeven;

In de beschrijving van de verschillende entiteiten worden per attribuut de naam, definitie, formaat en kardinaliteit (aantal keer dat een attribuut mag voorkomen) weergegeven. Voor het formaat worden de volgende conventies gehanteerd:

ANxxx Alfanumeriek veld met lengte xxxDate Datum (zonder tijd)DateTime Datum (met tijd)Gender Alfanumeriek veld met lengte 1 en domein ‘M’ / ‘V’ / ‘O’.GML Alfanumeriek veld met onbeperkte lengte (Geographical Markup Language)Nxxx Numeriek veld met lengte xxxVersion Alfanumeriek versie nummer met formaat \d{1,2}.\d{1,2}(.\d{1,2})YesNo Alfanumeriek veld met lengte 1 en domein ‘J’ / ‘N’.

Per entiteit worden tevens de verschillen beschreven tussen de huidige en de RGBZ 1.0 modellering en hoe hiermee omgegaan dient te worden. Opgemerkt dient te worden dat formele en materiële historie geen onderdeel van het beschreven datamodel zijn tenzij expliciet vermeld wordt dat dit wel het geval is.


2.1 Ander zaak objectEen ander zaakobject is geen aparte entiteit binnen het RGBZ maar een groepsattribuut van zaak dat nog niet opgenomen is in het Exxellence ZaakSysteem. In het RGBZ is dit groepsattribuut als volgt gedefinieerd: aanduiding van het object (of de objecten) waarop de zaak betrekking heeft indien dat object (of die objecten) niet aangeduid kan worden met de relatie “heeft betrekking op zaakobject”. Zoals deze omschrijving al aangeeft gaat het hier om een meervoudig groepsattribuut, het groepsattribuut als geheel heeft een kardinaliteit van 0-N in het RGBZ 1.0 model. De attributen van het ander zaak object zijn weergegeven in Tabel 1.

Naam Definitie Formaat Kard.

Opmerkingen

Ander zaakobject omschrijving

Een korte omschrijving van de aard van het zaakobject.

AN80 1-1 Voorbeelden: Invalidenparkeerplaats In- of uitritlokatie Lantaarnpaal, Speelplek of -tuig Chemische opslagtank

Ander zaakobject aanduiding

Een identificerende beschrijving van het zaakobject.

AN80 0-1

Ander zaakobject lokatie

De minimaal tweedimensionale geometrische representatie van de ligging of de omtrek van het zaakobject.

GML 0-1 Waardenverzameling: Aanduiding van het type

geometrie (punt, lijn, vlak, multivlak), gevolgd door coördinatenparen binnen de in Nederland gelegen waarden van het RD-stelsel1.

Ander zaakobject registratie

De naam van de registratie waarin gegevens van het ander zaakobject worden beheerd.

AN50 0-1

Tabel 1 – Attributen ander zaakobject.

Voor de “Ander zaakobject aanduiding” en “Ander zaakobject lokatie” attributen geldt de aanvullende restrictie dat, alhoewel beide optioneel zijn, één van beide voorzien moet zijn van een waarde. In theorie is het relatief eenvoudig om ander zaakobject toe te voegen aan het huidige datamodel, ware het niet dat “Ander zaakobject lokatie” GML als datatype heeft. Geography Markup Language (GML) is een door het Open Geospatial Consortium (OGC) opgestelde XML structuur voor de representatie van geografische (ruimtelijke en plaatsgebonden) informatie. Het definieert een XML codering voor het overbrengen en opslaan van geografische informatie, waaronder zowel de geometrie als de eigenschappen van geografische karakteristieken.

Er zijn twee manieren om een attribuut met een GML datatype te modelleren in een database. De eerste optie is om het GML datatype te modelleren als tekst, deze optie is weergegeven in Figuur 2 voor het “Ander zaakobject lokatie” attribuut. De optie is eenvoudig door te voeren maar heeft geen ondersteuning voor complexe zoekvragen op geometrie. De vraag “geef alle zaken met een ander zaakobject met een lokatie dat punt (x, y) omvat” kan met bovenstaand datamodel niet beantwoord worden.

1 Het RijksDriehoeksmeting (RD) stelsel is een geodetisch coördinatensysteem dat voor Europees Nederland op nationaal niveau wordt gebruikt als grondslag voor geografische aanduidingen en bestanden.


Figuur 2 – Ander zaakobject datamodel.

De tweede optie is om het GML datatype te modelleren als geografisch object in de database. Zowel Oracle als Postgres biedt standaard geen ondersteuning voor dit soort objecten, hiervoor dient een aparte module geïnstalleerd te worden (Oracle Spatial danwel PostGIS). Deze modules voegen database ondersteuning toe voor het werken met diverse soorten geometrie inclusief de bijbehorende, geoptimaliseerde, indexeringen om vragen met betrekking tot geometrie snel te kunnen beantwoorden. Bijkomend voordeel is dat zowel Oracle Spatial als PostGIS standaard ondersteuning bieden voor GML. Voor deze optie moeten nog wel een aantal dingen uitgezocht worden:

Uitzoeken gebruiksvoorwaarden van Oracle Spatial en PostGIS. Het gebruik van Oracle Spatial zal ongetwijfeld geld kosten terwijl PostGIS gratis is;

Uitzoeken consequenties gebruik Oracle Spatial en PostGIS. Hierbij moet vooral aan de hardware gedacht worden, op welke wijze moet de huidige standaard configuratie aangepast worden om e.e.a. soepel te laten werken.

Uitzoeken hoe het GML datatype gemodelleerd moet worden in Oracle Spatial en PostGIS. Het lijkt erop dat beide modules hun eigen interne datatypes hanteren en dat er een bibliotheek met functies aanwezig is om het interne datatype naar GML om te zetten en vice versa. Tevens moet uitgezocht worden op Oracle Spatial en PostGIS correct werken met coördinaten die gedefinieerd zijn in het RD stelsel. Worst case moeten alle coördinaten omgerekend worden naar het stelsel dat ondersteund wordt door de gebruikte database. Uitgezocht moet worden wat de gevolgen, qua performance, zijn als dit het geval blijkt te zijn.

Uitzoeken hoe het GML datatype bevraagd moet worden in Oracle Spatial en PostGIS. Hierbij moet vooral gekeken worden naar de bevragingen die mogelijk zijn via StUF en hoe deze omgezet moeten worden naar een query die door Oracle Spatial en PostGIS beantwoord kan worden.

In de StUF specificatie is niet duidelijk beschreven welke zoekmogelijkheden precies ondersteund moeten worden voor GML attributen waardoor lastig in te schatten is welke van de twee beschreven modelleringen de juiste is. Het is dan ook verstandig bovenstaande punten eerst nader uit te zoeken voordat er een definitieve keuze gemaakt wordt. Zeker is de benodigde hoeveelheid tijd voor het realiseren van de tweede optie vele malen groter is dan die voor de eerste optie.


2.2 StatusEen status is in het RGBZ gedefinieerd als: een aanduiding van de stand van zaken van een zaak op basis van betekenisvol behaald resultaat voor de initiator van de zaak. De attributen van de status entiteit zijn weergegeven in Tabel 2. De unieke aanduiding (sleutel) van de status entiteit wordt gevormd door de “unieke aanduiding van de gerelateerde zaak in combinatie met de datum status gezet” attributen.


Opmerkingen

Id Unieke oplopende sleutel. N12 1-1Datum status gezet

De datum waarop de zaak de status heeft verkregen.

DateTime 1-1 Formaat: Datum (JJJJMMDDUUMM)

Waardenverzameling: Alle geldige datums gelegen

op of voor de huidige datum en tijd.

Statustoelichting Een, voor de initiator van de zaak relevante, toelichting op de status van een zaak.

AN992 0-1

Indicatie laatst gezette status

Aanduiding of het de laatst bekende bereikte status betreft.

YesNo 1-1 Dit afleidbaar gegeven is toegevoegd omdat het bepalen van de laatst bekende status anders alleen te doen is op basis van analyse van alle statussen van de zaak.

Datum laatste wijziging

De datum waarop de status voor het laatste gewijzigd is.

Date 1-1 Interne datum voor het bepalen van statuswijzigingen die nog teruggekoppeld moeten worden.

Tabel 2 – Attributen status entiteit.

Bovenstaande modellering wijkt behoorlijk af van de huidige modellering. De volgende attributen moeten verwijdert worden uit het datamodel:

Volgnummer: oplopend nummer per zaak, vormt met zaak-id de sleutel; Extern referentie nummer: referentie nummer van de status in een extern systeem; Externe datum: datum waarop de status gezet is in een extern systeem; Externe omschrijving: omschrijving van de status in een extern systeem.

In het Exxellence ZaakSysteem worden voor entiteiten altijd twee sleutels gemodelleerd; een unieke oplopende sleutel (altijd id geheten) en een alternatieve sleutel (de RGBZ sleutel van de betreffende entiteit). Het eerste voordeel van deze opzet is dat gerelateerde entiteiten gekoppeld kunnen worden via het id attribuut en niet via de RGBZ sleutel. Deze laatste sleutel bestaat voor het gros van de RGBZ entiteiten uit meerdere attributen wat voor relaties als snel leidt tot een wildgroei aan attributen die overgenomen moeten worden. Het tweede voordeel van deze opzet is dat een losse sleutel er voor zorgt dat model wijzigingen minder impact hebben, deze sleutel verandert nooit voor een entiteit en in de relaties met gerelateerde entiteiten. Vooral dit laatste is een voordeel omdat hiermee complexe migratie problemen voorkomen worden.

In Tabel 2 is deze conventie deels gehanteerd, de unieke oplopende sleutel is toegevoegd maar de RGBZ sleutel niet. De resolutie van het “Datum status gezet” attribuut zorgt er namelijk voor dat er voor bepaalde zaak niet meer dan één status gezet kan worden binnen een minuut. Deze restrictie is onwerkbaar omdat in de praktijk regelmatig meerdere status wijzigingen binnen dezelfde seconde ontvangen worden. In het Exxellence ZaakSysteem wordt daarom datum status gezet tot op de milliseconde geregistreerd waarmee afgeweken wordt van het bovenstaande definitie.

Het volgende attribuut moet toegevoegd worden aan het datamodel van de status entiteit:

Indicatie laatst gezette status.Om het opzoeken van de laatste status te versnellen moet dit attribuut op database niveau ondersteund worden met een partiële index waardoor afgedwongen kan worden dat er per zaak slechts één status is met waarde ‘J’. Bijkomend voordeel van deze wijziging is dat een aantal operaties die momenteel de laatste status van een zaak opzoeken via het volgnummer (de status met het hoogste volgnummer wordt momenteel gezien als de laatste) versneld kunnen worden met een sub-selectie op “Indicatie laatst gezette status” die snel uitgevoerd kan worden met behulp van de eerder beschreven index.


Bij elke status toevoeging / wijziging dient bepaald te worden welke status daadwerkelijk de laatste is voor een zaak zodat deze als zodanig gemarkeerd kan worden via het “Indicatie laatst gezette status” attribuut. Bij een gelijke “Datum status gezet” dient de status met het hoogste id gemarkeerd te worden. Normaliter wordt dit op een transparante wijze gerealiseerd middels een database trigger. Voor Oracle is dit echter niet mogelijk omdat het toevoegen van een nieuwe status er namelijk voor zorgt dat één status de waarde ‘J’ krijgt voor de indicatie laatste status en één de waarde ‘N’ (de voorheen laatste status). Deze dubbele update is in Postgres wel maar in Oracle niet toegestaan binnen een trigger. Deze logica kan echter voor beide database geïmplementeerd worden in een stored procedure die door het zaaksysteem op de juiste momenten aangeroepen wordt. Het aangepaste datamodel voor de status entiteit is weergegeven in Figuur 3.

Figuur 3 – Status datamodel.

De minimaal benodigde aanpassing van de status entiteit bestaat uit het verwijderen van volgnummer en het toevoegen van de laatst gezette status indicatie. De attributen die overgenomen worden van een extern systeem kunnen eventueel ook in een latere versie verwijdert worden.

Het enige migratie probleem m.b.t. bovenstaande aanpassingen betreft het vullen van de “Id” en “Indicatie laatst gezette status” attributen. Het voorstel is om de volgorde van de statussen te bepalen door deze te sorteren op de registratie datum van de zaak in combinatie met het volgnummer om vervolgens het “Id” attribuut van de gesorteerde statussen te vullen met een oplopende waarde. Het “Indicatie laatst gezette status” attribuut moet initieel gevuld worden met de waarde ‘N’. Door vervolgens de hierboven beschreven stored procedure aan te roepen voor elke zaak kan de laatste status alsnog met een ‘J’ gemarkeerd worden.

De relaties van de status entiteit zijn weergegeven in Tabel 3. De relatie met zaakdocumenten ontbreekt momenteel in het Exxellence ZaakSysteem maar is minder relevant omdat zaakdocumenten indirect gekoppeld zijn aan statussen via stappen. Eventueel kan uitgezocht worden welke extra restricties toegevoegd moeten worden om deze relatie alsnog toe te kunnen voegen.

Relatienaam DefinitieStatus [0..*]is gezet door betrokkene in zijn/haar rol [1..1]

De betrokkene die in zijn/haar rol in een zaak heeft geregistreerd dat de status in die zaak bereikt is.

Status [0..*]is van zaak [1..1]

De zaak waarin de status bereikt is.

Status [0..*]is van statustype [1..1]

Aanduiding van de aard van de status.

Status [0..1]heeft daarvoor relevante

De bij de desbetreffende zaak behorende zaakdocumenten die relevant zijn (geweest) voor het bereiken van de status en/of de


zaakdocumenten [0..*] communicatie daarover.Tabel 3 – Relaties status entiteit.

De “Status is gezet door …” relatie is wel aanwezig in het Exxellence ZaakSysteem maar moet eigenlijk voorzien worden van een extra restrictie; de medewerker of organisatorische eenheid die de status zet moet in een bepaalde rol aan de zaak waarvoor de status gezet wordt gekoppeld zijn. Logischerwijs kan alleen aan deze restrictie voldaan worden als elke medewerker en organisatorische eenheid die een rol gespeeld heeft tijdens de behandeling gekoppeld wordt aan de zaak. Omdat dit laatste momenteel niet het geval is lijkt het verstandig om deze restrictie pas toe te voegen nadat het Exxellence KlantContactSysteem zodanig aangepast is dat elke medewerker en organisatorische eenheid geregistreerd wordt bij een zaak.A: Het feit dat iemand de status heeft gezet impliceert dat deze persoon/OE kennelijk om dat moment geautoriseerd was om dat te doen. Geen verdere registratie is noodzakelijk.

Overwogen moet worden om gelijk met bovenstaande datamodel wijzigingen de bijbehorende berichten aan te passen. De status berichten bevatten, qua naamgeving e.d., de nodige overblijfselen van voorgaande versies. Omdat de datamodel wijziging toch al leiden tot bericht wijzigingen zou het verstandig zijn deze legacy te verwijderen. Ter illustratie is in onderstaand voorbeeld het status details bericht weergegeven.

<?xml version="1.0" encoding="UTF-8"?><cases:caseStatusDetailsMessage xmlns:cases="http://www.emaxx.org/functional/cases" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.emaxx.org/functional/cases http://www.emaxx.org/functional/cases/caseStatusDetailsMessage.xsd">

<cases:caseStatuses><cases:caseStatus>

<cases:caseId xsi:nil="true"/><cases:sequenceNumber xsi:nil="true"/><cases:statusCode xsi:nil="true"/><cases:statusCodeDescription/><cases:statusRuntime xsi:nil="true"/><cases:statusPublicationIndication xsi:nil="true"/><cases:date xsi:nil="true"/><cases:clarification/><cases:extDate xsi:nil="true"/><cases:extClarification/><cases:setByActor>

<cases:employee><cases:id xsi:nil="true"/><cases:username/><cases:identification/><cases:clarification/><cases:resignationDate xsi:nil="true"/><cases:genderIndication xsi:nil="true"/><cases:initials/><cases:lastNamePrefix/><cases:lastName/><cases:nameOfAddress/><cases:function/><cases:emailAddress/><cases:telephoneNumber/>

</cases:employee></cases:setByActor>

</cases:caseStatus></cases:caseStatuses>

</cases:caseStatusDetailsMessage>

In dit voorbeeld wordt nog gebruik gemaakt van de oude benaming caseStatus terwijl dit status moet zijn (momenteel worden in de berichten de Engelse namen uit het datamodel gebruikt voor elementen). Daarnaast bevat dit bericht een aantal attributen van statusType die in een apart sub-blok horen te staan. Dit is bij de laatste wijziging van het bericht niet gedaan wat tot een uitermate kromme naamgeving heeft geleid (het statusCodeDescription element, bijvoorbeeld, bevat de omschrijving van het statustype van de status).

<?xml version="1.0" encoding="UTF-8"?><cases:statusDetailsMessage xmlns:cases="http://www.emaxx.org/functional/cases" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.emaxx.org/functional/cases http://www.emaxx.org/functional/cases/statusDetailsMessage.xsd">


<cases:statuses><cases:status>

<cases:id xsi:nil="true"/><cases:caseId xsi:nil="true"/><cases:date xsi:nil="true"/><cases:clarification/><cases:statusType>

<cases:sequenceNumber xsi:nil="true"/><cases:description/><cases:runtime xsi:nil="true"/><cases:publicationIndication xsi:nil="true"/>

</cases:statusType><cases:setByActor>

<cases:employee><cases:id xsi:nil="true"/><cases:username/><cases:identification/><cases:clarification/><cases:resignationDate xsi:nil="true"/><cases:genderIndication xsi:nil="true"/><cases:initials/><cases:lastNamePrefix/><cases:lastName/><cases:nameOfAddress/><cases:function/><cases:emailAddress/><cases:telephoneNumber/>


</cases:status></cases:statuses>

</cases:statusDetailsMessage>

Een vergelijkbare aanpassing dient doorgevoerd te worden voor alle overige berichten die status gegevens bevatten. Daarnaast moeten alle statustype berichten aangepast worden alleen al omdat het statusDetailsMessage bericht momenteel gebruikt wordt voor het doorgeven van de details van een statustype (een ander overblijfsel uit voorgaande versies). Kort samengevat betekend dit de volgende aanpassingen in de gebruikte benamingen in de berichten en de bijbehorende operaties:

1) caseStatus status.

2) status statusType.

3) statusType elementen die momenteel opgenomen zijn in een blok met status elementen moeten verplaatst worden naar een eigen statusType sub-blok.

Deze aanpassing betekend wel een aanpassing van de interface. Uitgezocht moet worden welke componenten aangepast moeten worden als gevolg van deze aanpassing.

A: Hiervoor moet een inventarisatie van caseStatus en status worden gemaakt en dan worden omgenoemd in de betrokken berichten en methodes. (ca. 10-20 aanpassingen).


2.3 StatustypeEen statustype is in het RGBZ gedefinieerd als: generieke aanduiding van de aard van een status. De attributen en relaties van de statustype entiteit zijn weergegeven in Tabel 4 en Tabel 5. De unieke aanduiding (sleutel) van de statustype entiteit wordt gevormd door de “unieke aanduiding van het gerelateerde zaaktype in combinatie met het statustypevolgnummer”.


Opmerkingen

Id Unieke oplopende sleutel. N12 1-1Statustype-code Een code van de aard van de

status van zaken van een zaaktype.

AN10 1-1

Statustypevolg nummer

Een volgnummer voor de status binnen een zaak.

N4 1-1 Waardenverzameling: 0001 - 9999

Statustype-omschrijving

Een korte, voor de initiator van de zaak relevante, omschrijving van de aard van de status van zaken van een zaaktype.

AN80 1-1

Statustype-omschrijving generiek

Algemeen gehanteerde omschrijving van de aard van statussen van het statustype.

AN80 0-1

Doorlooptijd status

De door de zaakbehandelende organisatie(s) gestelde norm voor de doorlooptijd voor het bereiken van statussen van dit statustype bij het desbetreffende zaaktype.

N3 0-1 Waardenverzameling: 1 - 999 werkdagen

Publicatie indicatie

Aanduiding of het bereiken van een status van het statustype gepubliceerd moet worden.

YesNo 1-1 Standaard waarde: N

Eind statustype indicatie

Aanduiding of het bereiken van een status van het statustype leidt tot het beëindigen van de zaak.

YesNo 1-1 Standaard waarde: N

Datum begin geldigheid statustype

Met deze datum wordt aangegeven vanaf wanneer het statustype toegepast kan worden.

Date 1-1 Wordt altijd gezet in combinatie met de bijbehorende indicatie onvolledigheid.

Indicatie onvolledigheiddatum begin geldigheid statustype

Indicatie voor dat deel van de datum begin geldigheid statustype dat eventueel onbekend is.

AN1 1-1 Waardenverzameling: D (dag onbekend) M (maand en dag onbekend) J (jaar, maand en dag

onbekend) V (volledig bekend)

Standaard waarde: VDatum einde geldigheid statustype

Met deze datum wordt aangegeven vanaf wanneer het statustype niet meer bestaat en niet meer toegepast kan worden.

Date 0-1 Wordt altijd gezet in combinatie met de bijbehorende indicatie onvolledigheid.

Indicatie onvolledigheiddatum einde geldigheid statustype

Indicatie voor dat deel van de datum begin geldigheid statustype dat eventueel onbekend is.

AN1 0-1 Waardenverzameling: D (dag onbekend) M (maand en dag onbekend) J (jaar, maand en dag

onbekend) V (volledig bekend)

Standaard waarde: VTabel 4 – Attributen statustype entiteit.

Relatienaam Definitie


Statustype [0..*]heeft statussen [1..1]

Verwijzing naar de statussen van dit statustype.

Statustype [1..1]is van zaaktype [0..*]

Het zaaktype van zaken waarin statussen van dit statustype bereikt kunnen worden.

Tabel 5 – Relaties statustype entiteit.

Ondanks het feit dat de RGBZ 1.0 modellering van de statustype entiteit grotendeels overeenkomt met de huidige modellering hebben de benodigde aanpassingen beduidend grotere gevolgen. Ten eerste moeten de volgende attributen aangepast worden:

Datum begin geldigheid statustype; Datum einde geldigheid statustype.

In het Exxellence ZaakSysteem worden onvolledige data sinds de introductie van de zaaktype versionering gemodelleerd met twee attributen; een datum en een indicatie onvolledigheid (één letter waarmee aangegeven wordt wel deel van de datum bekend / onbekend is). Bovenstaande attributen moeten zodanig aangepast worden dat ze alsnog voldoen aan deze conventie. Daarnaast moeten de volgende attributen toegevoegd worden voordat het “Statustype-code” attribuut verwijdert kan worden uit het datamodel:

Id: unieke oplopende sleutel; Statustypevolgnummer: alternatieve sleutel samen met unieke aanduiding zaaktype.

De vervanging van statustype-code als sleutel door de combinatie van de unieke zaaktype aanduiding (i.e. de zaaktype-omschrijving) en een volgnummer is een uiterst ingrijpende wijziging. Binnen het Exxellence ZaakSysteem is het zaaktype geversioneerd, i.e. naar verloop van tijd ontstaan er meerdere versies van een zaaktype aanwezig met elk een aparte (niet overlappende) geldigheidsduur. Een rechtstreekse relatie tussen statustype en de zaaktype-omschrijving is dan ook niet mogelijk, elke versie van een zaaktype heeft een eigen zaaktype-omschrijving (die wel gelijk moet zijn voor alle versies van het zaaktype). Dit kan opgelost worden door het zaaktype-omschrijving attribuut los te trekken van de zaaktype tabel zoals is weergegeven in Figuur 4 (zie volgende bladzijde).

Deze constructie zit momenteel al in het zaaksysteem maar dan met de zaaktype-code in plaats van de zaaktype-omschrijving. De zaaktype-code zal echter op termijn komen te vervallen waardoor bovenstaande constructie sowieso doorgevoerd moet worden. De aparte geldigheidsduren voor zaaktype en statustype bieden een zekere flexibiliteit, tegelijkertijd wordt het er niet overzichtelijker op. Omdat deze geldigheidsduren niet overeen hoeven te komen kan het, bijvoorbeeld, gebeuren dat een statustype ongeldig is terwijl het gerelateerde zaaktype nog wel geldig is.


Figuur 4 – Zaaktype – statustype datamodel.

Een nadeel van geldigheidsduren die gemodelleerd zijn via een start- en einddatum is dat elke selectie voorzien moet worden van een sub-selectie waarin deze data afgezet worden tegen de huidige datum. Deze sub-selectie, die vaak uitgevoerd moet worden, is relatief zwaar omdat deze slechts beperkt te versnellen is met indices op start- en einddatum. In Figuur 4 is dit voor de zaaktype entiteit opgelost door het “Is actueel” attribuut toe te voegen, deze bevat de waarde ‘J’ voor zaaktypes die vandaag geldig zijn. Binnen het zaaksysteem is een scheduler aanwezig die elke nacht de waarde voor dit attribuut opnieuw bepaald voor alle zaaktypes, zaaktypes waarvan de einddatum gepasseerd is krijgen hierdoor automatisch de waarde ‘N’. Voor de statustype entiteit zou een vergelijkbare constructie overwogen moeten worden, het “Is actueel” attribuut is voorzien van een index en kan dus snel uitgevraagd worden.

Er is echter nog een eenvoudigere mogelijkheid. Binnen het Exxellence ZaakSysteem is het zaaktype geversioneerd inclusief de staptypes die het behandelproces van het zaaktype vormen. Feitelijk nemen de staptypes, alsmede de bijbehorende eigenschappen e.d., de geldigheidsduur over van het zaaktype. Oerwogen moet worden deze constructie uit te breiden met de statustypes die gekoppeld zijn aan een zaaktype. Elk statustype heeft hierbij wel een geldigheidsduur, deze wordt vereist door het RGBZ 1.0 model, maar deze wordt per definitie gelijk gesteld aan de geldigheidsduur van de versie van het zaaktype waaraan het gekoppeld is2. Deze opzet is weergegeven in Figuur 5 (zie volgende bladzijde), de restrictie op de geldigheidsduur wordt voor de statustype entiteit met een database trigger afgedwongen.

2 Dit is wel een aandachtspunt mocht het zaaksysteem ooit voorzien worden van een StUF-Zaken interface, deze extra restrictie dient ook dan gehanteerd te worden.


Figuur 5 – Zaaktype – staptype - statustype datamodel.

In de opzet van Figuur 5 krijgen statustypes een uniek volgnummer binnen de versie van het zaaktype waarvan ze onderdeel zijn. De unieke sleutel van de statustype entiteit wordt hierdoor wel anders: “unieke aanduiding van de versie het gerelateerde zaaktype in combinatie met het statustypevolgnummer”.

Wat betreft de migratie moeten de relevante statustypes in een script gekopieerd worden voor alle zaaktypes. Gezien het aantal statustypes in het huidige zaaksysteem is het niet aan te raden alle statustypes te kopiëren voor elk zaaktype aangezien dit zou leiden tot grote hoeveelheden irrelevante statustypes die naderhand weer verwijdert moeten worden. Er zijn twee mogelijke oplossingen voor dit probleem:

1. De te kopiëren statustypes per zaaktype worden vastgelegd in, bijvoorbeeld, een aparte tabel die tijdens de migratie uitgelezen wordt. Voordeel van deze opzet is dat per zaaktype exact vastgelegd kan worden welke statustypes toegestaan zijn. Nadeel van deze opzet is dat deze lijst bepaald moet worden voor alle zaaktypes voordat de migratie uitgevoerd kan worden. De installer dient dit vooraf te verifiëren en moet de update afbreken als niet aan deze voorwaarde voldaan is.

2. De te kopiëren statustypes per zaaktype worden afgeleid van de statussen en stappen die geregistreerd zijn voor zaken van het betreffende zaaktype. De te kopiëren set bestaat uit de statustypes van de geregistreerde statussen gecombineerd met de statustypes die gekoppeld zijn aan de staptypes van de doorlopen stappen. Voordeel van deze opzet is dat deze volledig automatisch uit te voeren is. Nadeel is echter dat niet alle relevante statustypes gegarandeerd gevonden worden, een toegestaan statustype dat nooit gebruikt is in een status wordt, bijvoorbeeld, gemist. Hierdoor is het noodzakelijk om de aangemaakte statustypes naderhand te controleren en deze, daar waar nodig, aan te vullen.

Daarmee is de migratie echter nog niet afgerond, elk gekopieerd statustype moet ook nog voorzien worden van een (oplopend) volgnummer. Normaliter doorloopt een zaak een serie statussen waarvan de volgorde idealiter weergegeven wordt in de volgnummers van de gerelateerde statustypes. Binnen het Exxellence ZaakSysteem begint elke zaak met de status ‘Geregistreerd’. Deze status wordt direct gevolgd door ‘Ontvangen’, tenzij er voor de betreffende zaak betaald moet worden. Het bereiken van deze status


wordt gemeld aan de aanvrager middels een e-mail waarin nogmaals het referentienummer van de zaak vermeldt wordt.

De zaak krijgt de status ‘In behandeling’ zodra een organisatorische eenheid of een medewerker de zaak uit een werkvoorraad haalt en deze in behandeling neemt. De statussen die doorlopen worden na deze status zijn volledig afhankelijk van het zaaktype. Een melding openbare ruimte zaak wordt uiteindelijk afgerond met het bereiken van de ‘Gereed’ status, terwijl een vergunningsaanvraag wordt afgerond met het bereiken van een ‘Verleend’ of ‘Geweigerd’ status. De hiervoor doorlopen statussen kunnen ook nog eens meerdere malen doorlopen worden. Een incomplete aanvraag kan, bijvoorbeeld, meermalen switchen van ‘Onvolledig’ naar ‘In behandeling’ en vice-versa totdat alle benodigde gegevens volledig zijn.

Uitgangspunt voor de migratie van de inhoud van de statustype entiteit is dan ook dat de volgnummers op een logische wijze gevuld moeten worden, dit om zoveel mogelijk te voorkomen dat ze naderhand gecontroleerd en aangepast moeten worden. Voor het vullen van de volgnummers van de statustypes zijn drie mogelijke oplossingen:

1. De volgnummers van de statustypes per zaaktype worden vastgelegd in, bijvoorbeeld, een aparte tabel die tijdens de migratie uitgelezen wordt. Feitelijk is dit een uitbreiding op de hiervoor beschreven oplossing voor het migreren van de statustypes per zaaktype. Deze oplossing heeft tevens hetzelfde nadeel; de lijst met volgnummers moet volledig bepaald worden voordat de migratie uitgevoerd kan worden.

2. De volgnummers van de statustypes worden globaal vastgelegd in, bijvoorbeeld, een aparte tabel. Na het kopiëren van de statustypes voor een zaaktype wordt deze globale volgorde gebruikt als basis voor het bepalen van de volgnummers van de statustypes. Status types die niet in de globale lijst voorkomen krijgen oplopende volgnummere die volgen op het hoogste volgnummer uit de globale lijst.

Ter verduidelijking is in Tabel 6 (zie volgende bladzijde) een voorbeeld weergegeven van de werking van deze oplossing. De eerste twee kolommen bevatten de statustypes met hun globale volgnummers. In de volgende twee kolommen zijn de statustypes weergegeven die daadwerkelijk gebruikt worden voor het “Melding openbare ruimte” zaaktype. Initieel krijgen de statustypes hun globale volgnummer waarna deze relatief eenvoudig hernummerd kunnen worden om ze aansluitend te maken. De laatste twee kolommen demonstreren hetzelfde principe voor het “Evenementen vergunning” zaaktype met andere statustypes.

Voordeel van deze oplossing t.o.v. de voorgaande is dat er minder voorbereiding noodzakelijk is. Het bepalen van een globale volgorde is aanzienlijk minder werk dan het bepalen van een volgorde voor elk zaaktype.

Globaal Melding openbare ruimte Evenementen vergunningVolgnr Statustype Volgnr Statustype Volgnr Statustype1 Geregistreerd 1 Geregistreerd 1 Geregistreerd2 Ontvangen 2 Ontvangen 2 Ontvangen3 In behandeling 3 In behandeling 3 In behandeling4 In uitvoering 4 In uitvoering5 In onderzoek 4 In onderzoek6 Gereed 5 Gereed7 Verleend 5 Verleend8 Geweigerd 6 Geweigerd

Tabel 6 – Nummering statustypes.

3. De volgnummers van de statustypes worden afgeleid van de statussen en stappen die geregistreerd zijn voor zaken van het betreffende zaaktype. Alhoewel dit een fraaie oplossing zou zijn voor dit probleem zal deze in de praktijk uitermate lastig te realiseren zijn. Statussen en stappen worden namelijk niet per definitie voor elke zaak in dezelfde volgorde doorlopen, de volgordelijkheid kan dan ook alleen afgeleid worden uit de datum waarop een status gezet is danwel een stap doorlopen is. Per zaaktype zullen daarom eerste alle geregistreerde volgordes afgeleid moeten worden waarna de meest voorkomende gebruikt wordt om de statustypes te nummeren.

Qua migratie van statustypes zal het afleiden van statustypes met volgnummers die bepaald worden op basis van een globale lijst een bruikbare initiële vulling opleveren. Deze vulling zal echter naderhand echter alsnog gecontroleerd en, daar waar nodig, aangevuld moeten worden. Bij wijze van alternatief zou deze combinatie ook gebruikt kunnen worden om de hoeveelheid werk te verminderen die nodig is voor


een volledig vastgelegde migratie. De gegenereerde vulling wordt hierbij niet doorgevoerd maar geëxporteerd waarna deze, na correctie, gebruikt wordt als invoer voor de werkelijke migratie.

Deze consequenties van de beschreven aanpassingen moeten niet onderschat worden. In het beheer portaal zal hierdoor het zaaktype en statustype beheer volledig aangepast moeten worden. In het klant contact systeem moet op elke plek waar een medewerker een status kan zetten de lijst met statustypes getoond moeten worden van het zaaktype dat voor de betreffende context actief is.

Gelukkig is er een mogelijkheid om deze aanpassing in twee stappen door te voeren. In de eerste stap worden de “Datum begin geldigheid statustype” en “Datum einde geldigheid statustype” aangepast zoals hiervoor is beschreven. Daarnaast worden de volgende attributen toegevoegd aan het datamodel:

Id: unieke oplopende sleutel; Statustypevolgnummer: alternatieve sleutel samen met unieke aanduiding zaaktype.

De statustype entiteit wordt dus eerst voorzien van een zaaktype onafhankelijk volgnummer. Deze opzet is weergegeven in Figuur 6 en volstaat om een eerste versie van de zaak en documentservices te kunnen realiseren. De initiële vulling van deze volgnummers kan, analoog aan de hiervoor beschreven migratie oplossingen, gedaan worden via een globale lijst.

Figuur 6 – Zaaktype – staptype - statustype datamodel.

De opzet van Figuur 6 kan in een tweede stap verandert worden in de opzet van Figuur 5 door de relatie met de versie van een zaaktype toe te voegen. De tweede oplossing voor het migreren van statustypes kan hierbij gebruikt worden om per zaaktype de volgnummers te corrigeren op basis van de al aanwezig globale volgnummers.

2.4 Zaakdocument en documentVanwege de grote overeenkomsten zijn in het Exxellence ZaakSysteem de specialisaties van document (enkelvoudig en samengesteld document) samengevoegd tot één object. Fundamenteel verschil met het RGBZ is dat in de huidige incarnatie van het Exxellence ZaakSysteem elk document aan slechts één zaak gekoppeld kan zijn. Het eerder genoemde document object heeft dan ook een één-op-één relatie met een zaak.


Het RGBZ definieert een viertal entiteiten m.b.t. documenten; document, enkelvoudig document, samengesteld document en zaakdocument. De document entiteit definieert slechts de attributen die onderdeel zijn van zowel enkelvoudig- als samengesteld document, het is niet mogelijk instanties van de document entiteit te registreren. Daarnaast voegt de samengesteld document entiteit in het RGBZ voegt geen verdere attributen toe aan de document entiteit. Beide entiteiten zijn qua definitie dus gelijk, de attributen van deze entiteiten zijn weergegeven in Tabel 7.

Naam Definitie Formaat

Kard.

Opmerkingen

Document identificatie

Een binnen een gegeven context ondubbelzinnige referentie naar hetdocument.

AN40 1-1 Waardenverzameling: Positie 1 t/m 4:

gemeentecode van de gemeente die het document in haar registratie heeft opgenomen;

Posities 5 t/m 40: alle alfanumerieke tekens m.u.v. diacrieten.

Documentcreatiedatum

Een datum of een gebeurtenis in de levenscyclus van het document.

Date 1-1 Waardenverzameling:Alle geldige datums gelegen op of voor de huidige datum en tijd.

Document ontvangstdatum

De datum waarop het document ontvangen is.

Date 0-1 Waardenverzameling:Alle geldige datums gelegen op of voor de huidige datum en tijd.

Documenttitel De naam waaronder het document formeel bekend is.

AN200 1-1

Document beschrijving

Een generieke beschrijving van de inhoud van het document.

AN1000 0-1

Document verzenddatum

De datum waarop het document verzonden is.

Date 0-1 Waardenverzameling: Alle geldige datums gelegen op, voor of na de huidige datum en tijd.

Vertrouwelijk aanduiding

Aanduiding van de mate waarin het document voor de openbaarheid bestemd is.

AN20 1-1 Waardenverzameling: ZEER GEHEIM, GEHEIM,

CONFIDENTIEEL, VERTROUWELIJK, ZAAKVERTROUWELIJK, INTERN, BEPERKT OPENBAAR of OPENBAAR.

Documentauteur De persoon of organisatie die in de eerste plaats verantwoordelijk is voor het creëren van de inhoud van het document.

AN200 1-1

Tabel 7 – Attributen document / samengesteld document entiteit.

In tegenstelling tot de samengesteld document entiteit voegt de enkelvoudig document entiteit een aantal specifieke attributen toe aan die van de document entiteit. De attributen van de samengesteld document entiteit zijn weergegeven in Tabel 8.


Kard.

Opmerkingen

Documentidentificatie…Documentauteur

Zie Tabel 7.

Documentformaat

De digitale manifestatie van het enkelvoudig document.

AN10 0-1 Waardenverzameling: Bestaande bestands-

formaatbenamingenDocumenttaal Een taal van de intellectuele inhoud

van het enkelvoudig document.AN20 1-1 Waardenverzameling:

Zie ISO639.Documentversie

Aanduiding van de bewerkingsfase van het enkelvoudig document.

AN5 0-1

Documentstatus Aanduiding van de stand van zaken AN20 0-1


van een enkelvoudig document.Documentinhoud Datgene wat in een enkelvoudig

document wordt meegedeeld.0-1 Binaire inhoud in DMS (niet

opnemen in database)Documentlink De URL waarmee de documentinhoud

op te vragen is.AN200 0-1 Afleidbaar gegeven.

Bestandsnaam De naam van het fysieke bestand waarin de documentinhoud is vastgelegd.

AN255 1-1

Tabel 8 – Attributen enkelvoudig document entiteit.

Zoals te zien is aan Tabel 8 wijkt de RGBZ definitie van enkelvoudig document voor een beperkt aantal attributen af van de huidige opzet in het Exxellence ZaakSysteem. Ten eerste moeten de volgende attributen aangepast worden:

Documentversie: lengte moet beperkt worden tot 5 tekens; Bestandsnaam: lengte moet verhoogd worden naar 255 tekens.

Het verlengen van het “Bestandsnaam” attribuut kan probleemloos doorgevoerd worden. De inkorting van “Documentversie” naar 5 tekens (is nu 20 tekens) leidt tot een migratie probleem omdat alle opgeslagen waardes die langer zijn dan 5 tekens ingekort moeten worden. Daarnaast moeten de volgende attributen toegevoegd worden:

Documentformaat; Documenttaal; Documentstatus.

Deze attributen kunnen zonder al te veel problemen toegevoegd worden mits voor “Documenttaal” standaard de waarde voor Nederlands ingevuld wordt. Normaliter zou de waardenverzameling van de “Documentformaat” en “Documenttaal” attributen afgedwongen worden middels een domein tabel. Het RGBZ bevat voor deze attributen echter suggesties voor de waardenverzamelingen en geen exacte definities. Voor “Documentformaat” is de suggestie om MIME-types in te vullen, een technische identifier die op het internet gebruikt wordt om aan te geven wat voor soort data een bestand bevat. Het is niet verstandig hiervoor een domein tabel te definiëren omdat elke applicatie eigen MIME-types kan definiëren. Het is dan ook praktisch onmogelijk deze tabel up-to-date te houden met alle toegestane waardes. In het Exxellence KlantContactSysteem kan, overigens, het MIME-type achterwege gelaten worden omdat deze afgeleid kan worden van de bestandsnaam.

Voor het “Documenttaal” attribuut is de situatie iets ingewikkelder omdat in de ISO639 talen gedefinieerd zijn via ietwat cryptische codes. Elke code in de ISO639 bestaat uit een twee- of drieletterige landindicatie (bijvoorbeeld ‘nl’ of ‘en’) gevolgd door een sub indicatie waarmee onderscheidt gemaakt wordt tussen talen die in meerdere landen gesproken worden. Met ‘en-GB’ en ‘en-US’ wordt, bijvoorbeeld, onderscheid gemaakt tussen Engels zoals dit in respectievelijk het Verenigd Koninkrijk en de Verenigde Staten gesproken wordt. Het voorstel is om voor het “Documenttaal” attribuut wel een domein tabel toe te voegen en die eventueel te voorzien is van een gebruiksvriendelijke benaming. In het Exxellence KlantContactSysteem kan via de benaming een taal geselecteerd worden die vervolgens als de code opgeslagen wordt, het datamodel voor deze opzet is weergegeven in Figuur 7.


Figuur 7 – Document datamodel.

De relaties van enkelvoudig en samengesteld document zijn hetzelfde en weergegeven in Tabel 9. Naast deze relaties is er nog een relatie tussen enkelvoudig en samengesteld document ‘is onderdeel van’ die niet is weergegeven in Tabel 9 maar wel is opgenomen in het Exxellence ZaakSysteem.

Relatienaam DefinitieDocument [1..1]is van documenttype [0..N]

Aanduiding van de aard van het document.

Document [0..N]betreft zaakdocumenten [1..1]

De zaken waaraan het document is gerelateerd.

Document [0..N]kan vastlegging zijn van besluiten [0..M]

Aanduiding van het besluit waarvan het document de beschrijving bevat. Niet nu opnemen

Tabel 9 – Relaties enkelvoudig en samengesteld document entiteit.

Zoals te zien is aan Tabel 9 ontbreken er in het Exxellence ZaakSysteem momenteel twee relaties m.b.t. documenten. De “Document kan vastlegging zijn van besluiten” relatie is ontbreekt momenteel maar het is niet ondenkbaar dat deze noodzakelijk is in het kader van de aansluiting op de berichtenbox. Via de berichtenbox kunnen overheidsorganisaties elektronische post versturen naar burgers om hiermee aan hun informatieplicht te voldoen. De documenten die behoren tot een besluit van een zaak zijn een typisch voorbeeld van documenten die een gemeente naar de aanvrager van een zaak zou willen sturen als deze afgerond is. In het Exxellence ZaakSysteem zou dit, bijvoorbeeld, gefaciliteerd kunnen worden middels een actie die de relevante documenten doorzet naar de berichtenbox. Het zou dan ook verstandig zijn deze relatie alsnog toe te voegen.

A: Vastlegging van besluiten wordt niet gefaciliteerd.

Het toevoegen van de “Document betreft zaakdocumenten” relatie heeft een grotere impact. In het RGBZ is deze entiteit als volgt gedefinieerd: een document dat relevant is voor de behandeling van de zaak


en/of gecreëerd is in het kader van de behandeling van de zaak. De sleutel van zaakdocument wordt gevormd door de unieke aanduidingen van de gerelateerde zaak en het gerelateerde document. Tabel 10 en Tabel 11 bevatten een overzicht van de attributen en relaties van de zaakdocument entiteit.


Kard.

Opmerkingen

Zaakdocumenttitel

De naam waaronder het document binnen de zaak bekend is.

AN200 1-1

Zaakdocument beschrijving

Een op de zaak gerichte beschrijving van de inhoud van het document.

AN1000 0-1

Registratiedatum De datum waarop de zaak behandelende organisatie het document heeft geregistreerd bij de zaak.

Date 1-1 Waardenverzameling: Alle geldige datums

gelegen op of voor de huidige datum en tijd.

Tabel 10 – Attributen zaakdocument entiteit.

Relatienaam DefinitieZaakdocument [1..1]betreft zaak [1..N]

De zaak waaraan het zaakdocument het document relateert.

Zaakdocument [1..1]betreft document [1..N]

Het documentdat door het zaakdocument aan de zaak wordt gerelateerd.

Zaakdocument [0..1]is relevant voor status [0..N]

De bij de desbetreffende zaak behorende status waarvoor het zaakdocument relevant is (geweest) met het oog op het bereiken van die status en/of de communicatie daarover.

Tabel 11 – Relaties zaakdocument entiteit.

Zoals in Tabel 11 is te zien vormt de zaakdocument entiteit in het RGBZ een koppeltabel die een N-M relatie tussen zaken en documenten mogelijk maakt. Deze koppeltable wordt gevormd via enerzijds de “Zaakdocument betreft zaak” relatie en anderzijds de “Zaakdocument betreft document” relatie. De datamodel wijzigingen die noodzakelijk zijn om de zaakdocument entiteit te realiseren gecombineerd met deze twee relaties is dan ook relatief eenvoudig, slechts de directe relatie tussen zaak en document (zie Figuur 7) hoeft vervangen te worden door een nieuwe koppeltabel met de attributen uit Tabel 10. Het datamodel van deze aanpassing is weergegeven in Figuur 8 (zie volgende bladzijde).

Functioneel gezien heeft het meervoudig gebruik van documenten binnen meerdere zaken echter grote gevolgen. Oorzaak hiervan is het feit dat binnen het Exxellence ZaakSysteem de enkelvoudig en samengesteld document entiteiten nog niet voorzien zijn van historie. Momenteel is per definitie alleen de laatste versie van een document aan de zaak gekoppeld en is er geen mogelijkheid om voorgaande versies terug te halen. Voor een opzet waarbij een document altijd gerelateerd is aan één zaak is dit geen probleem omdat voor de behandeling van die zaak normaliter alleen deze versie van het document relevant is. Meervoudig gebruikt is in de huidige opzet beperkt mogelijk door het document nogmaals toe te voegen aan een andere zaak. Nadeel van deze opzet is echter dat een wijziging van het document in één van beide zaken niet zichtbaar is bij de andere zaak waardoor nieuwe versies van deze documenten onherroepellijk uit elkaar gaan lopen.

Bij meervoudig gebruik is het echter niet noodzakelijkerwijs de laatste versie van een document de relevante versie; elke afzonderlijke zaak kan gebruik maken van een andere versie. Vanuit het archiverings oogpunt is het ook niet toegestaan om hier van af te wijken, elke afgesloten zaak moet gearchiveerd worden inclusief de versies van de documenten die gekoppeld waren op het moment dat de zaak gesloten werd. Aan deze eis kan alleen voldaan worden als de enkelvoudig en samengesteld document entiteiten voorzien worden van historie waarmee elke nieuwe versie apart geregistreerd wordt. Alleen na deze aanpassing is het mogelijk om elke zaak te relateren aan een ‘eigen’ versie van een document (voorzien van bijbehorende titel en beschrijving).

A: Meervoudig gebruik van documenten wordt niet geïmplementeerd. De bestaande omgangswijze blijft gehandhaafd.


Figuur 8 – Zaakdocument datamodel.

Het toevoegen van de zaakdocument entiteit (inclusief historie) leidt tot een flink aantal vragen van functionele aard. Ten eerste zal uitgewerkt moeten worden hoe in het Exxellence KlantContactSysteem met meerdere versies van een document gewerkt kan worden. Randvoorwaarde hierbij is dat documenten dusdanig in het DMS opgeslagen worden dat de inhoud van elke versie afzonderlijk op te vragen is. Het heeft immers weinig zin om in het zaaksysteem diverse versies te registreren als vervolgens alleen de inhoud van de laatste versie op te vragen is. Om dit te faciliteren moet het Exxellence ZaakSysteem voorzien worden van een operatie waarmee alle beschikbare versies van een document opgevraagd kunnen worden inclusief de informatie die nodig is om de inhoud van elke versie op te kunnen vragen. Op basis van deze lijst moeten, op zijn minst, de volgende handelingen uitgevoerd kunnen worden:

Een eerdere of nieuwere versie van een document selecteren voor gebruik binnen een zaak; De inhoud van een willekeurige versie opvragen; Een nieuwe versie van een document toevoegen op basis van een eerdere versie (om

bijvoorbeeld fouten te herstellen).

Ten tweede moet uitgezocht worden hoe het meervoudig gebruik functioneel moet gaan werken in het gebruikte DMS (Alfresco in het geval van de Exxellence Suite). De zaaken documentservices specificatie schrijft een vierlaagsmodel voor (de ‘Zaken DMS boom’ genaamd) dat is weergegeven in Figuur 9.


Zaken

Zaaktype

Zaakfolder

EDC

Zaaktype Zaaktype

Zaakfolder Zaakfolder Zaakfolder Zaakfolder

EDCEDCEDCEDCNiet

zaakgerelateerdedocumenten

1

2

3 4

Figuur 9 – Zaken DMS boom.

Het zaken object is het rootobject en valt direct onder het rootniveau van het DMS. Aan het zaken object kunnen één of meer zaaktype-objecten hangen (1) die op hun beurt weer één of meer zaakfolders kunnen bevatten (2). Aan het zaakfolder-object hangen alle enkelvoudige documenten (EDC-objecten) die behoren tot dezelfde zaak. Een enkelvoudig document kan onder meerdere zaakfolder-objecten hangen, oftewel tot meerdere zaken behoren (3). In het DMS mogen ook andere documenten vastgelegd worden (4). Alle documenten die geen relatie hebben met een zaak zijn niet-zaakgerelateerde documenten. Een document dat initieel niet tot een zaak behoort, kan gewijzigd worden in een zaakdocument door kenmerken te wijzigen.

Indien grote hoeveelheid zaken vastgelegd moet worden in het DMS kan het nuttig zijn om objecten toe te voegen die ervoor zorgen dat er extra lagen ontstaan binnen de ‘Zaken DMS boom’. De zaaken documentservices specificatie staat toe dat extra objecten gebruikt worden om extra groeperingen aan te brengen zolang aan de volgende voorwaarden wordt voldaan:

Het zaken object (rootobject) blijft direct onder het rootniveau vallen van het DMS;

De beschreven (hoofd)structuur blijft in tact (Een zaakfolder-object kan bijvoorbeeld niet zonder tussenkomst van een zaaktype-object gerelateerd zijn aan het zaken-object);

Enkelvoudige documenten zijn altijd direct gerelateerd aan een zaakfolder-object.

Het is dus toegestaan om, bijvoorbeeld, een extra laag toe te voegen waarmee zaakfolders gegroepeerd worden per maand. Voordeel hiervan is dat performance problemen voorkomen kunnen worden door de zaakfolders verder op te delen. Omdat van veelgebruikte operating systemen bekend is dat er grenzen zijn aan het aantal folders / bestanden dat in een folder aangemaakt / opgeslagen kunnen worden is dit zeker geen overbodige luxe.

De zaaken documentservices specificatie bevat, afgezien van bovenstaande beschrijving van de ‘zaken DMS boom’, geen verdere detaillering van de wijze waarop met meervoudig gebruikte documenten gewerkt moet worden. Op basis van Figuur 9 zou geconcludeerd kunnen worden dat de bij (3) gekoppelde enkelvoudige documenten altijd dezelfde versie hebben. Dit zou impliceren dat beide zaken altijd naar hetzelfde bijbehorende enkelvoudig document record verwijzen in het zaaksysteem, dit wordt echter nergens afgedwongen.

Samenvattend; gezien de geschetste complexiteit dient het meervoudig gebruikt van documenten eerst verder functioneel uitgewerkt te worden. Daarnaast dient de in Figuur 8 weergegeven opzet de zaak – document koppeltabel voorzien te worden van een unieke index op document. Hiermee wordt op database niveau afgedwongen dat een document onderdeel is van één zaak. Daarnaast dient in de zaaken documentservices gecontroleerd te worden of een document dat toegevoegd wordt aan een zaak niet al gekoppeld is aan een andere zaak. In het laatste geval dient er een foutmelding te volgen waarin aangegeven wordt dat meervoudig gebruik niet ondersteund wordt.


2.5 Zaakobject en objectEen zaakobject is een aparte entiteit binnen het RGBZ dat nog niet opgenomen is in het Exxellence ZaakSysteem. In het RGBZ is deze entiteit als volgt gedefinieerd: een object waarop de zaak betrekking heeft. Deze entiteit heeft zelf amper attributen en is meer bedoelt om verschillende relaties tussen zaken en objecten (waarover later meer) mogelijk te maken. De attributen en relaties van de zaakobject entiteit zijn weergegeven in Tabel 12 en Tabel 13. De unieke aanduiding van de zaakobject entiteit is “de unieke aanduiding van de zaak in combinatie met de desbetreffende specialisatie van object”.


Opmerkingen

Relatie-omschrijving

Omschrijving van de betrekking tussen de zaak en het object.

AN80 0-1

Tabel 12 – Attributen zaakobject entiteit.

Relatienaam DefinitieZaakobject [0..N]is onderwerp van zaak [1..1]

De zaak die via het zaakobject betrekking hebben op een object.

Zaakobject [0..N]betreft object [1..1]

Het object waarop een zaak via het zaakobject betrekking heeft.

Tabel 13 – Attributen zaakobject entiteit.

Zoals aan bovenstaande definities te zien is is een zaakobject altijd gerelateerd aan een object. De optionele aard van het “Relatie-omschrijving” attribuut is onverwacht, blijkbaar moeten zaken en objecten op een ongespecificeerde wijze gerelateerd kunnen worden. Om de zaakobject entiteit toe te kunnen voegen aan het zaaksysteem moet dus ook de object entiteit toegevoegd worden. De object entiteit is als volgt gedefinieerd: het object waarop een zaak betrekking kan hebben zijnde één of meer voorkomens van de in het RSGB en het RGBZ onderscheiden objecttypen.

A: Specialisaties worden in 1 tabel generiek als XML opgeslagen.

Het object kent dan bijna evenzovele specialisaties als dat er objecttypen (i.e. entiteiten) in het RSGB en RGBZ opgenomen zijn. Deze specialisaties omvatten alleen objecttypen op het laagste specialisatieniveau d.w.z. geen gegeneraliseerde objecttypen. In Tabel 14 en Tabel 15 zijn de object specialisaties weergegeven die overgenomen zijn uit het respectievelijk het RGBZ en het RSGB.

Besluit Medewerker Samengesteld documentEnkelvoudig document Organisatorische eenheid Status

Tabel 14 – RGBZ object specialisaties.

Ander natuurlijk persoon Kunstwerkdeel TerreindeelAnder buitenlands niet-natuurlijk persoon

Ligplaats Verblijfsobject

Appartementsrecht Maatschappelijke activiteit VestigingBuurt Niet-ingezetene WaterdeelGemeente Nummeraanduiding WegdeelGemeentelijke openbare ruimte Openbare ruimte WijkHuishouden Overige adresseerbaar object

aanduidingWoonplaats

Ingeschreven niet-natuurlijk persoon

Overig gebouwd object WOZ-deelobject

Ingezetene Overig terrein WOZ-objectInrichtingselement Pand WOZ-waardeKadastraal perceel Spoorbaandeel Zakelijk recht

Tabel 15 – RSGB object specialisaties.

Voor elk van bovenstaande object specialisaties is in het RGBZ model een lijst met attributen vastgelegd die ontleend worden aan het originele object. Normaliter gaat het hier om een sub-set van de attributen van het originele RGBZ / RSGB object. De modellering is enigszins verwonderlijk omdat het RGBZ hiermee voorzien wordt van een aantal kopie-entiteiten die niet noodzakelijkerwijs synchroon hoeven te lopen met hun origineel, feitelijk had volstaan kunnen worden met referenties naar de reeds aanwezige entiteiten.


De benodigde datamodel aanpassing is deels weergegeven in Figuur 10. In dit figuur is te zien dat, analoog aan de wijze waarop subjecten gemodelleerd zijn, bestaan uit een object tabel met per record een verwijzing naar één enkel onderliggend specialisatie. In Figuur 10 zijn een drietal specialisaites weergegeven, uiteindelijk moeten dit de 39 specialisatie worden die zijn opgesomd in Tabel 14 en Tabel 15.

Figuur 10 – Zaakobject - object datamodel (deels).

Voor de object entiteit zijn een aantal attributen gedefinieerd die allen afgeleid worden van het onderliggende objecttype. Deze attributen worden niet opgeslagen en zijn bedoelt om objecten op te zoeken op basis van een aantal algemene attributen zonder dat het type van het gezochte object expliciet opgegeven wordt.


3. Zaak- en documentservicesBinnen het Exxellence ZaakSysteem wordt standaard van het Alfresco DMS gebruik gemaakt voor het opslaan van documenten met een beperkte set aan metadata. Het is echter mogelijk om een ander DMS in te stellen (Corsa, Verseon, eDocs, etc.) als vervanging voor Alfresco. Een volledige vervanging is hierbij niet mogelijk, dispositie functionaliteit wordt alleen ondersteund in combinatie met Alfresco. Het ontbreken van een standaard koppelvlak voor DMSen heeft er jarenlang voor gezorgd dat het koppelen met deze DMSen tijdrovend en foutgevoelig maatwerk was.

Met de introductie van de zaaken documentservices specificatie heeft de KING getracht hier een standaard voor te definiëren. In dit hoofdstuk wordt beschreven hoe de metadatering in Alfresco aangepast moet worden om te voldoen aan de lijst die in de zaaken documentservices is vastgelegd (sectie 3.1). Tevens wordt voor elke zaaken documentservice beschreven op welke bestaande service deze aangesloten moet worden en welke aanpassingen noodzakelijk zijn om dit mogelijk te maken (sectie 3.2).

3.1 MetadateringDe zaaken documentservices specificatie streeft ernaar, om, conform GEMMA, informatie slechts op één plek vast te leggen. Omdat het zaaksysteem en DMS normaliter gescheiden omgevingen is een set van vijf gemeenschappelijke gegevenselementen nodig om een relatie te leggen tussen deze systemen. Deze set bestaat uit:

Zaakidentificatie; Zaaktype; Documentidentificatie; Documenttype; Resultaat.

In de praktijk is echter gebleken dat gemeenten behoefte hebben aan een bredere set (meta)gegevenselementen die zowel in het zaaksysteem als het DMS beschikbaar moeten zijn. Naast de bovenstaande (minimale) set is daarom een set gegevenselementen vastgelegd die tussen het zaaksysteem en DMS gesynchroniseerd moet kunnen worden. Deze gegevenselementen zijn overgenomen uit het Referentiemodel Gemeentelijke Basisgegevens Zaken (RGBZ, zie [D2]) en dienen opgenomen te worden in het DMS bij een document.

Per gegevenselement is in Tabel 16 (zie volgende bladzijde) aangegeven welk RGBZ attribuut / entiteit het betreft alsmede of deze verplicht is. Tevens is aangegeven of het betreffende attribuut aanwezig is in het Exxellence ZaakSysteem 5.0 / 5.1 model. Onderstaande tabel geeft aan hoe verplichte en optionele elementen gesynchroniseerd moeten worden tussen zaaksysteem en DMS. Attributen die niet aanwezig zijn in het datamodel van het Exxellence ZaakSysteem zijn in het lichtgrijs weergegeven.

Bepaald zal moeten worden of de metadatering van documenten in Alfresco aangepast moet worden om te conformeren aan bovenstaande tabel. Hierbij dient rekening gehouden te worden met de verplichte attributen die toegevoegd worden, deze zullen gevuld moeten worden op basis van de zaaksysteem database tijdens de migratie naar het Exxellence ZaakSysteem 5.2. Grootste uitdaging hierbij is dat de beschreven migratie volautomatisch uitgevoerd moet kunnen worden door de installer. Omdat deze migratie waarschijnlijk in Java uitgeprogrammeerd moet worden zal de installer ondersteuning moeten gaan bieden voor het uitvoeren van Java code binnen een installatie script. Normaliter wordt hiervoor een specifieke installatie task aangemaakt, uitgezocht moet worden of dat dit volstaat of dat er hiervoor een nieuw (te scripten) mechanisme toegevoegd moet worden.

?: Is dit noodzakelijk? Momenteel wordt alle metadata uit het gekoppelde document uit het zaaksysteem gehaald.

Attribuut Verplicht Aanwezig

Opmerkingen

ZaaktypeZaaktype-omschrijving


Zaaktype code x x Attribuut is niet aanwezig in het RGBZ!

ZaakZaakidentificatie x xStartdatum xEinddatumZaakniveau xDeelzakenindicatie xRegistratiedatum xPublicatiedatumArchiefnominatie xDatum vernietiging dossier Dit is de dispositie datum.Resultaat

Resultaatomschrijving xNatuurlijk persoon Van initiator.

Burgerservicenummer xNummer ander natuurlijk person xVoorvoegsels GeslachtsnaamGeslachtsnaam

Niet-natuurlijk persoon (NNP) Van initiator.NNP-ID xNummer ander buitenlands NNP. x(Statutaire) Naam

Medewerker Van initiator.Medewerkeridentificatie xVoorvoegselAchternaam

Organisatorische eenheid Van initiator.Organisatieidentificatie x

Vestiging Van initiator.Vestigingsnummer xHandelsnaam

Enkelvoudig documentDocumenttitel x xBestandsnaam xDocumentidentificatie x xDocumenttype-omschrijving xDocumentcreatiedatum x xDocumentontvangstdatum xDocumentbeschrijvingDocumentverzenddatum xVertrouwelijkaanduiding xDocumentauteur x xDocumentformaat xDocumenttaal xDocumentversieDocumentstatusDocumentlink

Tabel 16 – RGBZ attributen in het DMS.

3.2 ServicesIn deze sectie worden de zaaken documentservices geanalyseerd die aangesloten moeten worden op het Exxellence ZaakSysteem 5.2. Uitgangspunt hierbij is dat elke zaaken documentservice aangesloten wordt op één enkele operatie van de bestaande services van het zaaksysteem. Deze opzet voorkomt dat er complexe logica gerealiseerd moet worden in OpenTunnel waarmee mogelijke performance problemen worden voorkomen. Per zaaken documentservice wordt de corresponderende Exxellence ZaakSysteem 5.2 operatie alsmede de vraag- en antwoordberichten, in tabelvorm, beschreven. In deze tabellen worden de volgende conventies gehanteerd:

niet ondersteunde elementen, attributen en relaties zijn in licht grijs weergegeven; optionele elementen zijn cursief weergegeven; vast waardes staan tussen enkele aanhalingstekens.


Voor de leesbaarheid zijn de vraag- en antwoordberichten ingesprongen waarbij elk voorgaand niveau een ‘.’ gelezen moet worden. Het gerelateerde.omschrijving element in Tabel 17, bijvoorbeeld, kan dus ook aangeduid worden met scope.object.heeft.gerelateerde.omschrijving.

3.2.1 Geef ZaakstatusDeze service (geefZaakstatus_Lv01) biedt zaakserviceconsumer de mogelijkheid om de meest actuele status van een lopende zaak op te vragen middels een vraag-/antwoordinteractie. Hierbij worden aan het zaaksysteem de volgende eisen gesteld:

1. Het zaaksysteem retourneert alle attributen die gespecificeerd zijn in het antwoordbericht en waarnaar de zaaksysteemconsumer vraagt in het vraagbericht. Eventueel kan het zaaksysteem hierbij gebruik maken van het StUF:noValue attribuut.

In het Exxellence ZaakSysteem biedt de lookUpCases operatie functionaliteit voor het opvragen van zaak statussen die overeenkomt met de hier beschreven service. Het vraagbericht voor deze service is weergegeven in Tabel 17.

StUF Zaken element RGBZ attribuut / waarde Opmerkingengelijk Selectie criteria van de zaak /

status.identificatie Zaakidentificatieheeft

indicatieLaatsteStatus ‘J’ scope.object Scope van het antwoordbericht.

Hiermee kan de consumer aangeven welke elementen hij in het antwoord verwacht.

Zie antwoord.object in Tabel 18.Tabel 17 – Geef zaakstatus vraagbericht (zakLv01).

In deze berichten kunnen andere elementen voorkomen (zolang deze voldoen aan de StUF-Zaken definities), maar verwerking hiervan wordt niet door de specificatie afgedwongen. Bovenstaand vraagbericht bevat slechts een fractie van de totale set van elementen die volgens de schema-definities zijn toegestaan (~800.000). Daarnaast is de restrictie op de toegestane waardes van het indicatieLaatsteStatus element niet expliciet vastgelegd in de schemadefinities. Dit leidt tot de volgende aanvullende eisen m.b.t. het verwerken van het vraagbericht:

1. Alle elementen die toegestaan zijn volgens de StUF-Zaken schemadefinities die niet opgenomen zijn in Tabel 17 dienen genegeerd te worden.

2. Als het indicatieLaatsteStatus element een waarde heeft anders dan ‘J’ dient een foutmelding te volgen.

De invulling van deze eisen dient in OpenTunnel te geschieden. Het bijbehorende antwoordbericht voor deze service is weergegeven in Tabel 18. In de laatste kolom van deze tabel is weergegeven welke elementen uit het lookUpCases antwoordbericht horen bij de StUF Zaken elementen van het antwoordbericht van de geefZaakstatus_Lv01 service. Om dit antwoordbericht correct te kunnen vullen is noodzakelijk dat de in sectie 2.2 beschreven aanpassingen van de status entiteit en de bijbehorende operaties / berichten doorgevoerd worden.

StUF Zaken element RGBZ attribuut / waarde lookUpCases elementantwoord.object cases.case

identificatie Zaakidentificatie referenceNumberheeft statuses.status

gerelateerde.omschrijving Statustype-omschrijving statusType.descriptiongerelateerde.volgnummer Statustype-volgnummer statusType.sequenceNumberdatumStatusGezet Datum status gezet dateindicatieLaatsteStatus ‘J’ ‘J’statustoelichting Statustoelichting clarification

Tabel 18 – Geef zaakstatus antwoordbericht (zakLa01).

De lookUpCases operatie retourneert momenteel alle statussen van een zaak wat zou betekenen dat OpenTunnel een filter moet toepassen om deze set te terug te brengen tot de laatste status. Het is


daarom aan te raden het lookUpCases vraagbericht te voorzien van een nieuwe include (genaamd caseStatusLast o.i.d) die er voor zorgt dat alleen de laatste status geretourneerd wordt. Deze include kan tevens door het Exxellence KlantContactSysteem gebruikt worden om de werkvoorraad sneller op te vragen.

3.2.2 Geef ZaakdetailsDeze service (geefZaakdetails_Lv01) biedt zaakserviceconsumers de mogelijkheid om attributen van een lopende zaak en gerelateerde objecten op te vragen middels een vraag-/antwoordinteractie.

1. Het zaaksysteem retourneert alle attributen waarnaar de zaakserviceconsumer vraagt in het vraagbericht. Eventueel kan het zaaksysteem hierbij gebruik maken van het attribuut StUF:noValue.

Aan deze eis niet volledig voldaan worden omdat niet alle benoemde attributen aanwezig zijn in het zaaksysteem. In het Exxellence ZaakSysteem biedt de lookUpCases operatie functionaliteit voor het opvragen van een zaak die overeenkomt met de hier beschreven service. Het vraagberichten van deze service is weergegeven in Tabel 19.

StUF Zaken element RGBZ attribuut / waarde Opmerkingengelijk Selectie criteria van de zaak.

identificatie Zaakidentificatiescope.object Scope van het antwoordbericht.

Hiermee kan de serviceconsumer aangeven welke elementen hij in het antwoord verwacht.

Zie antwoord.object in Tabel 20Tabel 19 – Geef zaakdetails vraagbericht (zakLv01).

De zaakserviceconsumer mag niet naar andere attributen vragen dan de attributen die gespecificeerd zijn in het antwoordbericht. Dit leidt tot de volgende aanvullende eis m.b.t. het verwerken van het vraagbericht van de geefZaakdetails_Lv01 service:

2. Alle elementen die toegestaan zijn volgens de StUF-Zaken schemadefinities die niet opgenomen zijn in Tabel 19 dienen genegeerd te worden.

Het antwoordberichten van deze service is weergegeven in Tabel 20. De onderstaande beschrijving van het geefZaakdetails antwoordbericht bevat een aantal groepen (bijvoorbeeld kenmerk en opschorting), deze hebben allen een kardinaliteit van 0..N wat er feitelijk voor zorgt dat ze optioneel zijn. Voor alle niet expliciet benoemde child-elementen (aangegeven met <child elementen>) bepalen de onderliggende standaarden RGBZ / StUF-Zaken welke attributen verplicht danwel optioneel zijn.StUF Zaken element RGBZ attribuut lookUpCases elementantwoord.object cases.case

identificatie Zaakidentificatie referenceNumberstartdatum Startdatum startDateeinddatum Einddatum endDateeinddatumGepland Einddatum gepland plannedEndDateregistratiedatum Registratiedatum registrationDatepublicatiedatum Publicatiedatum publicationDateuiterlijkeEinddatum Uiterlijke

einddatum afdoening

completionDate

omschrijving Omschrijving descriptiontoelichting Toelichting clarificationzaakniveau Zaakniveau caseLeveldeelzakenIndicatie Deelzakenindicatie subCaseIndicationextraElementen.stuf:extraElement naam="<code>-registratienummer

caseTarget .referenceNumberCode .referenceNumber

archiefnominatie Archiefnominatie archiveNominationdatumVernietigingDossier Datum vernietiging

dossierdispositionDate

betalingsIndicatie Betalingsindicatie paymentIndication


laatsteBetaaldatum Laatste betaaldatum

lastPaymentDate

kenmerk Kenmerken [0..N]kenmerk Kenmerkbron Kenmerk bron

resultaat Resultaat resultomschrijving Resultaatomschrijv

ingdescription

toelichting Resultaattoelichting

clarification

opschorting Opschorting [0..N] postponementsindicatie Indicatie

opschortingindication

reden Reden opschorting reasonverlenging Verlenging [0..N] extension

duur Duur verlenging lengthreden Reden verlenging Reason

anderZaakObject Ander zaakobject [0..N]

omschrijving Ander zaakobject omschrijving

aanduiding Ander zaakobject aanduiding

lokatie Ander zaakobject lokatie

registratie Ander zaakobject registratie

heeftBetrekkingOp.gerelateerde Heeft betrekking op zaakobjecten [0..N]

caseObject.object

<alle child elementen>heeftBetrekkingOpAndere Heeft betrekking

op andere ZAAKen [0..N]

parentCaseRelations en childCaseRelations (relationType.code=VVZK)

heeftAlsDeelzaak childCaseRelations (relationType.code=KVU)

heeftAlsInitiator.gerelateerde.medewerker initiatingActor.employee

heeftAlsInitiator.gerelateerde.organisatorischeEenheid

initiatingActor.unit

heeftAlsInitiator.gerelateerde.natuurlijkPersoon initiatingSubject.person

heeftAlsInitiator.gerelateerde.nietNatuurlijkPersoon initiatingSubject.organization

heeftAlsInitiator.gerelateerde.vestiging initiatingSubject.office

heeftAlsVerantwoordelijke.gerelateerde.medewerker heeftAlsGemachtigde.employee

heeftAlsVerantwoordelijke.gerelateerde.organisatorischeEenheid

responsibleActor.unit

heeftAlsVerantwoordelijke.gerelateerde.natuurlijkPersoon

party.actor.person (roleTypeCode=VRNTWDLK)

heeftAlsVerantwoordelijke.gerelateerde.nietNatuurlijkPersoon

party.actor.organization (roleTypeCode=VRNTWDLK)

heeftAlsVerantwoordelijke.gerelateerde.vestiging party.actor.office (roleTypeCode=VRNTWDLK)


heeftAlsBelanghebbende Heeft betrokkenen in rollen [0..N]

parties.party (roleTypeCode=BLNGHBBND)

heeftAlsGemachtigde Heeft betrokkenen in rollen [0..N]

parties.party (roleTypeCode=GEM)

heeftAlsUitvoerende Heeft betrokkenen in rollen [0..N]

parties.party (roleTypeCode=UITVOERDER)

heeftAlsOverigeBetrokkene Heeft betrokkenen in rollen [0..N]

parties.party (roleTypeCode = heeftAlsOverigBetrokkene .code)

heeft heeft statussen [0..N]

caseStatuses.caseStatus

gerelateerde STATUSTYPE statusTypevolgnummer Statustypevolgnum

mersequenceNumber

code - codeomschrijving Statustype-

omschrijvingdescription

toelichting Statustoelichting clarificationdatumStatusGezet Datum status

gezetdate

indicatieLaatseStatus Indicatie laatst gezette status

lastStatusIndication

isGezetDoor is gezet door betrokkene in zijn/haar rol

setByActor.employee ofsetByActor.unit (zie onderstaande tabellen voor details)

object.isVan.gerelateerde caseTypecode Zaaktypecode codeomschrijving Zaaktype-

omschrijvingdescription

Tabel 20 – Geef zaakdetails antwoordbericht (zakLa01).

StUF heeftAlsBelanghebbende, heeftAlsGemachtigde, heeftAlsUitvoerende, heeftAlsOverigeBetrokkene element

RGBZ attribuut / waarde

party element

gerelateerde.medewerker actor.employeegerelateerde.organisatorischeEenheid actor.unitgerelateerde.natuurlijkPersoon actor.persongerelateerde.nietNatuurlijkPersoon actor.organizationgerelateerde.vestiging actor.officecodeomschrijvingtoelichtingafwijkendCorrespondentieAdresafwijkendBuitenlandsCorrespondentieAdrestijdvakRelatietijdvakGeldigheidtijdstipRegistratieextraElementenhistorieMaterieelhistorieFormeelhistorieFormeelRelatieheeftAlsAanspreekpunt


Tabel 21 - StUF heeftAlsBelanghebbende mapping

StUF medewerker element RGBZ attribuut / waarde

employee element

identificatie identification - usernameachternaam lastNamevoorletters initialsvoorvoegselAchternaam lastNamePrefixroepnaam -geslachtsaanduiding genderIndicationfunctie functiondatumUitDienst resignationDatetelefoonnummer telephoneNumberemailadres emailAddresstoelichting clarification - nameOfAddresstijdvakGeldigheid -tijdstipRegistratie -extraElementen -historieMaterieel -historieFormeel - hoortBij - isVerantwoordelijkVoor -isContactpersoonVoor -

Tabel 22 – StUF medewerker mapping

StUF organisatorischeEenheid element RGBZ attribuut / waarde

unit element

identificatie identification - codenaam namenaamVerkort shortNameomschrijving descriptiontoelichting clarificationtelefoonnummer telephoneNumberfaxnummer faxNumberemailadres emailAddressingangsdatumObject foundingDateeinddatumObject disbandingDatetijdvakGeldigheid -tijdstipRegistratie -extraElementen -historieMaterieel -historieFormeel -bestaatUit -heeftAlsVerantwoordelijke -heeftAlsContactpersoon -


isGehuisvestIn -Tabel 23 - StUF organisatorischeEenheid mapping

StUF natuurlijkPersoon element RGBZ attribuut / waarde

person element

inp.bsn citizenNumberauthentiek [email protected] numberOtherNaturalPersongeslachtsnaam lastNamevoorvoegselGeslachtsnaam lastNamePrefixvoorletters nameOfAddress.initialsvoornamen firstNamesaanduidingNaamgebruik -geslachtsnaamPartner -voorvoegselGeslachtsnaamPartner -aanhefAanschrijving nameOfAddress.titlevoornamenAanschrijving nameOfAddress.firstNamesgeslachtsnaamAanschrijving nameOfAddress.lastNameadellijkeTitelPredikaat nobleTitlegeslachtsaanduiding genderIndicationgeboortedatum dateOfBirthoverlijdensdatum dateOfDeathverblijfsadres residenceAddresssub.verblijfBuitenland.lnd.landnaam foreignAddress.countryNamesub.verblijfBuitenland.sub.adresBuitenland1 foreignAddress.foreignAddress1sub.verblijfBuitenland.sub.adresBuitenland2 foreignAddress.foreignAddress2sub.verblijfBuitenland.sub.adresBuitenland3 foreignAddress.foreignAddress3sub.correspondentieAdres correspondenceAddress|

postalAddresssub.telefoonnummer telephoneNumbersub.faxnummer faxNumbersub.emailadres emailAddresssub.rekeningnummerBankGiro bankAccountNumberacd.code academicTitle.codeextraElementen -

Tabel 24 - StUF natuurlijkPersoon mapping

StUF nietNatuurlijkPersoon element RGBZ attribuut / waarde

organization element

inn.nnpId nnpIdauthentiek [email protected] numberOtherForeignNNPsub.typering typestatutaireNaam statutoryNameinn.rechtsvorm datumAanvang hisStartDatedatumEinde hisEndDatesub.correspondentieAdres correspondenceAddress|


postalAddressbezoekadres residenceAddresssub.verblijfBuitenland.lnd.landnaam foreignAddress.countryNamesub.verblijfBuitenland.sub.adresBuitenland1 foreignAddress.foreignAddress1sub.verblijfBuitenland.sub.adresBuitenland2 foreignAddress.foreignAddress2sub.verblijfBuitenland.sub.adresBuitenland3 foreignAddress.foreignAddress3sub.telefoonnummer telephoneNumbersub.faxnummer faxNumbersub.emailadres emailAddresssub.rekeningnummerBankGiro bankAccountNumberextraElementen

Tabel 25 - StUF nietNatuurlijkPersoon mapping

StUF vestiging element RGBZ attribuut / waarde

office element

vestigingsNummer officeNumberauthentiek officeNumber@authentichandelsnaam tradeNames.tradeNamedatumAanvang hisStartDatedatumEinde hisEndDateverblijfsadres locationAddresssub.verblijfBuitenland.lnd.landnaam foreignAddress.countryNamesub.verblijfBuitenland.sub.adresBuitenland1 foreignAddress.foreignAddress1sub.verblijfBuitenland.sub.adresBuitenland2 foreignAddress.foreignAddress2sub.verblijfBuitenland.sub.adresBuitenland3 foreignAddress.foreignAddress3sub.correspondentieAdres correspondenceAddress|

postalAddresssub.telefoonnummer telephoneNumbersub.faxnummer faxNumbersub.emailadres emailAddresssub.rekeningnummerBankGiro bankAccountNumberextraElementen

Tabel 26 - StUF vestiging mapping

StUF verblijfadres element RGBZ attribuut / waarde

residenceAddress element

aoa.identificatie -authentiek -wpl.woonplaatsNaam citygor.openbareRuimteNaam namePublicSpacegor.straatnaam streetname - streetnameBOCOaoa.postcode zipCodeaoa.huisnummer houseNumberaoa.huisletter houseLetteraoa.huisnummertoevoeging houseRemarkinp.locatiebeschrijving locationDescription


Tabel 27 - StUF verblijfadres mapping

StUF sub.correspondentieAdres element RGBZ attribuut / waarde

correspondenceAddress element

wpl.woonplaatsNaam citypostcode zipCodeaoa.identificatie authentiek gor.openbareRuimteNaam namePublicSpacegor.straatnaam streetnameaoa.huisnummer houseNumberaoa.huisletter houseLetteraoa.huisnummertoevoeging houseRemarksub.postadresType sub.postadresNummer

Tabel 28 - StUF sub.correspondentieAdres mapping 1


postalAddress element

wpl.woonplaatsNaam citypostcode zipCodeaoa.identificatie authentiek gor.openbareRuimteNaam gor.straatnaam aoa.huisnummer aoa.huisletter aoa.huisnummertoevoeging sub.postadresType postalAddressTypesub.postadresNummer poBoxNumber



postalAddress element

wpl.woonplaatsNaam citypostcode zipCodeaoa.identificatie authentiek gor.openbareRuimteNaam gor.straatnaam aoa.huisnummer aoa.huisletter aoa.huisnummertoevoeging sub.postadresType postalAddressTypesub.postadresNummer poBoxNumber


StUF heeftBetrekkingOp RGBZ attribuut / waarde caseObject element


idcaseidobjectIddescriptionobject.id

heeftBetrekkingOp.gerelateerde.*[1]. entiteittype

object.specializedObjectType (attribuut gemapped naar veld)

heeftBetrekkingOp object.content (heeftBetrekkingOp XML)

Tabel 31 - StUF heeftBetrekkingOp mappingNB: Het veld case.object.content bevat de letterlijke XML uit het StUF element ‘heeftBetrekkingOp’.

StUF heeftBetrekkingOpAndere RGBZ attribuut / waarde childCaseRelation/parentCaseRelation code VVZK

heeftBetrekkingOpAndere.gerelateerde.identificatie

childCaseRelation.relatedCase.referenceNumber

heeftBetrekkingOpAndere.gerelateerde.omschrijving

childCaseRelation.relatedCase.description

heeftBetrekkingOpAndere.gerelateerde.isVan.gerelateerde.omschrijving

childCaseRelation.relatedCase.caseType.description

heeftBetrekkingOpAndere.gerelateerde.isVan.gerelateerde.code

childCaseRelation.relatedCase.caseType.code

heeftBetrekkingOpAndere.gerelateerde.isVan.gerelateerde.ingansdatumObject

Tabel 32 - StUF heeftBetrekkingOpAndere mappingNB: Map childCaseRelation en parentCaseRelation elementen met relationType.code=VVZK (Vervolg Zaak) naar ‘heeftBetrekkingOpAndere’.

StUF heeftAlsDeelzaak RGBZ attribuut / waarde childCaseRelation code KVUheeftAlsDeelzaak.gerelateerde.identificatie

childCaseRelation.relatedCase.referenceNumber

heeftAlsDeelzaak.gerelateerde.omschrijving

childCaseRelation.relatedCase.description

heeftAlsDeelzaak.gerelateerde.isVan.gerelateerde.omschrijving

childCaseRelation.relatedCase.caseType.description

heeftAlsDeelzaak.gerelateerde.isVan.gerelateerde.code

childCaseRelation.relatedCase.caseType.code

heeftAlsDeelzaak.gerelateerde.isVan.gerelateerde.ingansdatumObject

Tabel 33 - StUF heeftAlsDeelzaak mappingNB: Map childCaseRelation elementen met relationType.code=KVU naar ‘komt voort uit’ . Om het volledige antwoordbericht te kunnen retourneren moet het operatie uitgebreid worden met kenmerken, andere zaakobjecten en zaakobjecten. In secties 2.1 en 2.5 is beschreven hoe andere zaakobjecten en zaakobjecten toegevoegd kunnen worden. Gezien de complexiteit van zaakobjecten lijkt het verstandig om eerst alleen andere zaakobjecten toe te voegen.

Kenmerken zijn is een groepsattribuut van zaak dat in het RGBZ gedefinieerd is als: identificatie-gegevens over de zaak in andere administraties. De onderliggende “kenmerk” en “bron” attributen hebben beide een lengte van 40 tekens. Het Exxellence ZaakSysteem bevat een vergelijkbaar groepsattribuut (caseTarget genaamd) die gebruikt wordt om, o.a., informatie over de locatie van documenten van een zaak in een DMS te registreren. Dit groepsattribuut bestaat uit een “referentienummer” en een “bron” attribuut die respectievelijk 70 en 80 tekens lang zijn. Deze grotere lengtes zorgen ervoor dat kenmerken niet opgeslagen kunnen worden als caseTarget, dit omdat (te lange) waardes die momenteel opgeslagen zijn voor dit groepsattribuut niet geretourneerd kunnen worden via StUF.

Om kenmerken te ondersteunen zoals deze beschreven zijn in het RGBZ dient een aparte tabel toegevoegd te worden bestaande uit zaak-id, kenmerk en bron. Gevolg van deze aanpassing is dat het huidige caseTarget groepsattribuut een andere betekenis krijgt om onderscheid te kunnen maken met kenmerken: identificatie-gegevens over de locatie van documenten van een zaak in een DMS. Er dient


hierbij een migratie uitgevoerd te worden van alle waardes die niet voldoen aan deze definitie, deze moeten alsnog aangemaakt worden als kenmerken.

A: Kenmerken worden naast de caseTarget gepositioneerd. Er vindt geen migratie plaats.

3.2.3 Actualiseer ZaakstatusDeze service (actualiseerZaakstatus_Lk01) biedt zaakserviceconsumers de mogelijkheid om een nieuwe status aan een lopende zaak toe te voegen middels een kennisgevingsbericht. Indien de nieuwe status gelijk is aan de eindstatus (zoals vastgelegd in de zaaktypecatalogus van de gemeente) dient het zaaksysteem de betreffende zaak af te sluiten. Hierbij worden aan het zaaksysteem de volgende eisen gesteld:

1. Het zaaksysteem beschikt over de zaakkenmerken die in de zaaktypecatalogus zijn vastgelegd en kan bepalen of de statustype-omschrijving die door de aanroeper wordt ingevuld in de zaaktypecatalogus staat. In geval het statustype niet voorkomt, dan stuurt het zaaksysteem een StUF foutbericht.

2. Het zaaksysteem kan aan de hand van informatie uit de zaaktypecatalogus bepalen of een status een eindstatus van een zaak is en indien een zaak een eindstatus bereikt, het proces in gang te zetten om de zaak af te sluiten.

3. Het zaaksysteem bepaalt of de aangeleverde status de meest recente status van de zaak is en bepaalt de waarde ‘indicatie laatst gezette status’. De Indicatie laatst gezette status is afleidbaar uit de historie van het attribuut Datum status gezet van alle statussen bij de desbetreffende zaak.

Om aan eis 1 te kunnen voldoen moet in het zaaksysteem vastgelegd kunnen worden welke statustypes toegestaan zijn voor een zaaktype, dit is momenteel nog niet mogelijk in het Exxellence ZaakSysteem. De voorgestelde aanpassingen voor de statustype entiteit (zie sectie 2.3) zorgen er feitelijk voor dat elk statustype toegestaan is voor elk zaaktype. Aan een striktere interpretatie van deze eis kan voldaan worden als in een later stadium de relatie tussen de versie van een zaaktype en statustypes toegevoegd wordt.

Aan eis 2 kan voldaan worden, dit gegeven kan afgeleid worden via het statustype. Wel is het zo dat het aanroepen van de addStatus met een eindstatus nog niet leidt tot het uitvoeren van acties die normaliter geassocieerd worden met het afsluiten van een zaak. De reden hiervoor is dat een uitgangspunt voor de huidige implementatie van het Exxellence ZaakSysteem is geweest dat het afsluiten van een zaak gekoppeld is aan het invullen van de einddatum van een zaak en niet het zetten van een status. Hiervoor is gekozen om een medewerker na het bereiken van een eind status de mogelijkheid te geven e.e.a. op te ruimen alvorens de zaak te sluiten. Een mogelijke oplossing voor dit probleem is om de eind datum van een zaak automatisch in te vullen als een eind status bereikt wordt. Wel dient verder uitgezocht te worden welke acties hierna uitgevoerd dienen te worden, deze functionaliteit ontbreekt momenteel volledig.

Aan eis 3 kan in principe voldaan worden als de status entiteit voorzien wordt van een “Indicatie laatst gezette status” attribuut zoals beschreven is in sectie 2.2. Het vraagberichten van deze service is weergegeven in Tabel 34, het antwoordbericht is niet weergegeven in deze sectie omdat deze slechts een bevestiging bevat.

StUF Zaken element RGBZ attribuut / waarde actualizeStatus elementobject

identificatie Zaakidentificatie case.identificationomschrijving Zaak omschrijving case.descriptionheeft statusType

gerelateerde.omschrijving Statustype-omschrijving descriptiongerelateerde.volgnummer Statustype-volgnummer sequenceNumbergerelateerde.code - codedatumStatusGezet Datum Status gezet dateisGezetDoor.gerelateerde setByActor

medewerker oforganisatorischeEenheid

employee of unit

identificatie Medewerkeridentificatie ofOrganisatieidentificatie

…

medewerker oforganisatorischeEenheid

employee of unit


<alle child elementen anders dan identificatie>

…

statustoelichting Statustoelichting clarificationTabel 34 – Actualiseer zaakstatus kennisgevingsbericht (zakLk01).

In het Exxellence ZaakSysteem biedt de addStatus (momenteel nog addCaseStatus geheten) operatie functionaliteit voor het toevoegen van een status aan een zaak. De attributen van bovenstaand vraagbericht zorgen er echter voor dat deze operatie niet te gebruiken is voor de actualiseerZaakstatus service:

De addStatus operatie verwacht een zaak-id en geen zaakidentificatie. Dit is eventueel op te lossen door in het bericht het zaak-id te vervangen door een keuze tussen zaak-id of zaakidentificatie. De zaak kan vervolgens opgezocht worden op basis van het element dat daadwerkelijk in het bericht gespecificeerd is.

Het doel van het “Zaak omschrijving” attribuut is niet expliciet beschreven. Moet de zaak met de gevraagde zaakidentificatie ook de gevraagde omschrijving hebben (als deze is ingevuld)? Of moet, naast het toevoegen van de status, de omschrijving van de zaak aangepast worden? De specificatie zegt hier niets over, de tweede optie lijkt echter de meest voor de hand liggende interpretatie.

De addStatus operatie verwacht geen statustype-omschrijving. Deze element is echter nodig om te kunnen verifiëren of het statustype met de gespecificeerde omschrijving toegestaan is voor het zaaktype van de zaak. Deze controle is in eerste instantie niet noodzakelijk omdat alle statustypes toegestaan zijn voor alle zaaktypes. Indien de status entiteit verder aangepast wordt (zie sectie 2.2) is dit element wel noodzakelijk waardoor het verstandig is deze alvast toe te voegen.

Logischerwijs dient het statustype met de gespecificeerde omschrijving het gespecificeerde volgnummer te hebben. Indien dit niet het geval is dient een foutmelding te volgen.

Het voorstel is om een nieuwe operatie toe te voegen aan het Exxellence ZaakSysteem (actualizeStatus o.i.d, updateStatus bestaat al) met een invoerbericht dat qua inhoud gelijk is aan het bericht uit Tabel 34. Deze nieuwe operatie voegt één enkele status toe aan een zaak waarbij alle bovenstaande controles / restricties geverifieerd worden. Hieronder is een voorbeeld weergegeven van het mogelijke vraagbericht van deze nieuwe operatie.

<?xml version="1.0" encoding="UTF-8"?><cases:statusActualizeMessage xmlns:cases="http://www.emaxx.org/functional/cases" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.emaxx.org/functional/cases http://www.emaxx.org/functional/cases/statusActualizeMessage.xsd">

<cases:date xsi:nil="true"/><cases:clarification/><cases:case>

<cases:identification xsi:nil="true"/><cases:description xsi:nil="true"/>

</cases:case><cases:statusType>

<cases:sequenceNumber xsi:nil="true"/><cases:description/>

</cases:statusType><cases:setByActor>

<cases:employee><cases:identification/>


</cases:statusActualizeMessage>

Opmerking: in bovenstaand voorbeeld wordt de identificatie van de medewerker doorgegeven die de status gezet heeft. In het uiteindelijke bericht dient het mogelijk te zijn om een hier de identificatie van de organisatorische eenheid of een volledige medewerker / organisatorische eenheid te specificeren.A: employee identification is mogelijk identiek aan die uit creeerZaak; als deze niet bestaat volgt een foutmelding.


3.2.4 Creëer ZaakDeze service (creeerZaak_Lk01) biedt zaakserviceconsumers de mogelijkheid om een lopende zaak toe te voegen in het zaaksysteem middels een kennisgevingsbericht. Er dient altijd een geldige zaakidentificatie aangeleverd te worden. De zaakserviceconsumer kan hiervoor zelf een zaakidentificatie genereren of kan gebruik maken van de genereerZaakIdentificatie_Di02 service (zie sectie Error: Reference source not found) om een geldige zaakidentificatie op te vragen. Hierbij worden aan het zaaksysteem de volgende eisen gesteld:

1. Het zaaksysteem verwerkt alle aanwezige RGBZ attributen die via de kennisgeving zijn toegestuurd;

2. Het ontstaan van de zaak wordt gesynchroniseerd met het DMS. Hiervoor voert het zaaksysteem de benodigde CMIS operaties ‘near real time’ uit.

3. Indien een fout optreedt dan vindt er geen verwerking plaats (eventueel reeds uitgevoerde acties worden teruggedraaid). De aanroeper wordt hiervan op de hoogte gesteld middels een StUF foutbericht.

4. Het zaaksysteem controleert of toegestuurde zaakidentificaties uniek zijn en voldoen aan het RGBZ.

Aan eis 1 kan niet voldaan worden omdat niet alle elementen uit de kennisgeving momenteel verwerkt kunnen worden. Aan eisen 2 en 3 kan volledig voldaan worden en aan eis 4 kan deels. De controle op uniciteit van de zaakidentificatie wordt nu al uitgevoerd, de controle op het formaat is echter nog niet mogelijk. Het formaat van de zaak identificatie kan binnen het Exxellence ZaakSysteem ingesteld worden op een formaat anders dan in het RGBZ voorgeschreven wordt. Deze controle kan in een latere versie alsnog toegevoegd worden.

In het Exxellence ZaakSysteem biedt de addDetailedCase operatie functionaliteit voor het aanmaken van een zaak die overeenkomt met de hier beschreven service. Het volledige vraagbericht van deze service is weergegeven in Tabel 35.

StUF Zaken element RGBZ attribuut / waarde addDetailedCase elementobject case

identificatie Zaakidentificatie referenceNumberstartdatum Startdatum startDateeinddatum Einddatum endDateeinddatumGepland Einddatum gepland plannedEndDateregistratiedatum Registratiedatum registrationDatepublicatiedatum Publicatiedatum publicationDateuiterlijkeEinddatum Uiterlijke einddatum

afdoeningcompletionDate

omschrijving omschrijving descriptiontoelichting Toelichting clarificationzaakniveau Zaakniveau caseLeveldeelzakenIndicatie Deelzakenindicatie subCaseIndicationextraElementenextraElement @naam=’kanaal’ channel.codeextraElement @naam=’registratienummer’

caseTarget.referenceNumber

extraElement @naam=’registratienummerCode’

caseTarget.code

extraElement @naam=’OloNummer’ SquitXo OLO nummer (caseTarget.code=OLO)caseTarget.referenceNumber

extraElement @naam=’urgent’ urgencyLeveladdresses.address

extraElement @naam=’lokatieStraatnaam’

streetName

extraElement @naam=’lokatieHuisnummer’

houseNumber

extraElement @naam=’lokatieHuisletter’ houseLetterextraElement @naam=’lokatieHuisnummertoevoeging’

houseRemark


extraElement @naam=’lokatieHuisnummeraanduiding’

houseIndication

extraElement @naam=’lokatieLocatieomschrijving’

neighbourhoodName

extraElement @naam=’lokatiePostcode’ zipCodeextraElement @naam=’lokatieBuurt’ neighbourhoodNameextraElement @naam=’lokatieStad’ cityextraElement @naam=’lokatieGemeente’

municipalityName

extraElement @naam=’lokatieWijk’ districtNameextraElement @naam=’lokatieXcoordinaat’

xCoordinate

extraElement @naam=’lokatieYcoordinaat’

yCoordinate

extraElement @naam=’lokatieZcoordinaat’

zCoordinate

archiefnominatie Archiefnominatie archiveNominationdatumVernietigingDossier Datum vernietiging dossier dispositionDatebetalingsIndicatie Betalingsindicatie paymentIndicationlaatsteBetaaldatum Laatste betaaldatum lastPaymentDatekenmerk Kenmerken [0..N]

kenmerk Kenmerkbron Kenmerk bron

resultaat Resultaat resultomschrijving Resultaatomschrijving descriptiontoelichting Resultaattoelichting clarification

opschorting Opschorting [0..N] postponementsindicatie Indicatie opschorting indicationreden Reden opschorting reason

verlenging Verlenging [0..N] extensionduur Duur verlenging lengthreden Rede verlenging Reason

anderZaakObject Ander zaakobject [0..N]anderZaakomschrijving Ander zaakobject

omschrijvinganderZaakaanduiding Ander zaakobject aanduidinganderZaaklokatie Ander zaakobject lokatieanderZaakregistratie Ander zaakobject registratie

heeftBetrekkingOp.gerelateerde Heeft betrekking op zaakobjecten [0..N]

<alle child elementen>heeftAlsBelanghebbende, heeftAlsGemachtigde, heeftAlsUitvoerende, heeftAlsVerantwoordelijke, heeftAlsOverigBetrokkene

Heeft betrokkenen in rollen [0..N]

In het zaaksysteem allen gemodelleerd als een party met een specifieke rol.

<alle child elementen m.u.v. tijdvakRelatie, tijdvakGeldigheid, tijdstipRegistratie, historieMaterieel, historieFormeel, historieFormeelRelatie>

heeftAlsInitiator.gerelateerde Heeft betrokkenen in rollen [1..1]

Exact één van de volgende sub-elementen moet aanwezig zijn.

medewerkeridentificatie MedewerkeridentificatieAlle andere elementen van medewerker zijn optioneel

organisatorischeEenheididentificatie OrganisatieidentificatieAlle andere elementen van organisatorischeEenheid zijn optioneel

natuurlijkPersooninp.bsn BSN van initiatoranp.identificatie Ander natuurlijk persoon

identificatieinp.bsn of anp.identificatie is


verplicht. Alle andere van natuurlijkPersoon zijn optioneel

nietNatuurlijkPersooninn.nnpld Niet natuurlijk persoon

identificatie (RSIN)ann.identificatie Ander niet natuurlijk persoon

identificatieinn.nnpld of ann.identificatie is verplicht. Alle andere elementen van nietNatuurlijkPersoon zijn optioneel

VestigingvestigingsNummer VestigingsnummerAlle andere elementen van vestiging zijn optioneel

heeftAlsInitiator.extraElementen.extraElement @naam="telefoonnummer"

heeftAlsInitiator.extraElementen.extraElement @naam=”emailadres”

Bij entiteittype “NPS”:Person. telephone_numberBij entiteittype “NNP”:Organization. telephone_numberBij entiteittype “NPS”:Person. email_addressBij entiteittype “NNP”:Organization. email_address

isVan.gerelateerdecode Zaaktypecodeomschrijving Zaaktype-omschrijving

Tabel 35 – Creëer zaak kennisgevingsbericht (zakLk01).

De ontbrekende elementen die toegevoegd worden moet te kunnen voldoen aan deze eis zijn gelukkig grotendeels dezelfde elementen die voor de ‘Geef Zaakdetails’ service noodzakelijk zijn: zie Tabel 20 – Geef zaakdetails antwoordbericht (zakLa01).. Om de betrokken partijen (initiatior, belanghebbende, gemachtigde e.d.) te kunnen verwerken moeten de medewerker, organisatorische eenheid, natuurlijk persoon, niet-natuurlijke persoon en verstiging entiteiten aangepast worden aan de RGBZ definities. Deze aanpassing in op het moment van schrijven al doorgevoerd.

Naast de hierboven beschreven aanpassingen dient de addDetailedCase nog aangepast te worden m.b.t. het verlenging element. In het huidige addDetailedCase vraagbericht kan slechts één verlenging doorgegeven worden terwijl verlenging in Tabel 35 een meervoudige kardinaliteit heeft. Deze laatste restrictie is overgenomen uit het RGBZ, de zaaken documentenservice definitie lijkt hier dus mee in tegenspraak te zijn. Omdat deze functionaliteit slechts beperkt gebruikt wordt kan dit probleem eerst opgelost worden door een foutmelding te geven bij meer dan één verlenging totdat dit wel ondersteund worden.

Het creëer zaak bericht verschilt van de zaak lezen variant voor zaakrelaties. Zaakrelaties (heeftBetrekkingOpAndere en heeftAlsDeelzaak in StUF) dienen gemapped te worden volgens Tabel 36 - StUF heeftBetrekkingOpAndere mapping update en Tabel 37 - StUF heeftAlsDeelzaak mapping update .

3.2.5 Update ZaakDeze service (updateZaak_Lk01) biedt zaaksysteemconsumers de mogelijkheid om attributen van een bestaande lopende zaak en gerelateerde objecten in het zaaksysteem te muteren middels een kennisgeving. Bij ontvangst van de kennisgeving zorgt het zaaksysteem dat alle aangeleverde attributen worden gemuteerd met uitzondering van zaakidentificatie en zaaktype. Deze laatste attributen mogen niet gemuteerd worden. Hierbij worden aan het zaaksysteem de volgende eisen gesteld:

1. Het zaaksysteem verwerkt alle aanwezige RGBZ attributen via de kennisgeving zijn toegestuurd;


Aan eis 1 kan (nog) niet voldaan worden, aan eis 2 wel. De kennisgeving voor deze operatie komt overeen met kennisgeving die beschreven is in Tabel 35 met weglating van de object.heeftInitiator.gerelateerde en isVan.gerelateerde elementen. Zoals eerde is beschreven is het niet toegestaan om bij een mutatie gegevens van de initiator of van het zaaktype aan te passen.


In het Exxellence ZaakSysteem biedt de updateDetailedCase operatie functionaliteit voor het updaten van een zaak. Deze operatie verwacht echter een vraagbericht met daarin de gewenste eindsituatie, waarna het Exxellence ZaakSysteem uitzoekt hoe deze gerealiseerd moet worden. In het StUF vraagbericht van de updateZaak_Lk01 service worden echter diverse objecten gespecificeerd waarvan expliciet aangegeven wordt of deze toegevoegd, aangepast of verwijdert moeten worden. De enige manier om deze delta via de updateDetailedCase door te voeren is door de zaak uit te lezen, de delta toe te passen om vervolgens de updateDetailedCase operatie aan te roepen.

Om de call in 1 keer uit te kunnen voeren is en een nieuwe operatie updateCaseStuf toegevoegd waar de updateZaak_Lk01 naartoe gemapped kan worden. Deze operatie werkt grotendeels met dezelfde elementen als beschreven in Geef Zaakdetails. Daarnaast is het mogelijk om met het optionele attribuut ‘verwerkingssoort’ de verschillende elementen die aan de zaak gekoppeld zijn afzonderlijk toe te voegen, te verwijderen of te bewerken.

De volgende tabellen bevatten mapping voor elementen waarvoor de update afwijkt van de beschrijving in Geef Zaakdetails.StUF heeftBetrekkingOpAndere RGBZ attribuut / waarde caseRelationheeftBetrekkingOpAndere.gerelateerde.identificatie

caseRelation.childCase. referenceNumber

heeftBetrekkingOpAndere.gerelateerde.omschrijvingheeftBetrekkingOpAndere.gerelateerde.isVan.gerelateerde.omschrijvingheeftBetrekkingOpAndere.gerelateerde.isVan.gerelateerde.codeheeftBetrekkingOpAndere.gerelateerde.isVan.gerelateerde.ingansdatumObject

caseRelation.relationType.code=VVZK

Tabel 36 - StUF heeftBetrekkingOpAndere mapping updateNB: Map ‘heeftBetrekkingOpAndere’ naar een caseRelation met relationType.code=VVZK (Vervolg Zaak) en andersom.

StUF heeftAlsDeelzaak RGBZ attribuut / waarde caseRelationheeftAlsDeelzaak.gerelateerde.identificatie

caseRelation.childCase. referenceNumber

heeftAlsDeelzaak.gerelateerde.omschrijvingheeftAlsDeelzaak.gerelateerde.isVan.gerelateerde.omschrijvingheeftAlsDeelzaak.gerelateerde.isVan.gerelateerde.codeheeftAlsDeelzaak.gerelateerde.isVan.gerelateerde.ingansdatumObject

caseRelation.relationType.code=KVU

Tabel 37 - StUF heeftAlsDeelzaak mapping updateNB: Map ‘heeftAlsDeelzaak’ naar een caseRelation met relationType.code=KVU (Komt voort uit) en andersom.

3.2.5.1 Gebruik verwerkingssoortBij het bebruik van de operatie updateCaseStuf kunnen de zaak en objecten die aan de zaak gerelateerd zijn afzonderlijk bijgewerkt worden door gebruik te maken van attribuut verwerkingssoort.

verwerkingssoort betekenis<leeg> Als er geen verwerkingssoort wordt meegeven, wordt het element genegeerd in de

verwerkingT Bij T ‘toevoegen’ wordt het element aan de zaak toegevoegd. W Afhankelijk van het element. Het element wordt gewijzigd of de relatie met de

zaak wordt gewijzigd.


V Bij V ‘verwijderen’ wordt het element verwijderd.Tabel 38 - verwerkingssoort

De volgende elementen ondersteunen het verwerkingssoort attribuut in interface en implementatie: case caseTarget casetype result initiatingActor initiatingSubject responsibleActor party registryObject ordinance extension postponement attributeGroup note otherCaseObject status caseObject characteristic caseRelation

Interface ondersteuning maar nog een implementatie: address registryObject ordinances attributeGroup notes

De onderstaande tabel laat per element het effect zien van de verschillende waardes van het verwerkingssoort attribuut.

T V Wcase niet toegestaan niet toegestaan update velden casecaseTarget Zet een caseTarget voor de

zaak. Er mag nog geen caseTarget aan de zaak gekoppeld zijn.

Verwijder de caseTarget. update velden caseTarget

caseType niet toegestaan niet toegestaan Zet een nieuw zaaktype voor de zaak.

result Zet een nieuw resultaat. Verwijder het resultaat. zet een nieuw resultaatinitiatingActor Zet een initiatingActor voor

de zaak. Er mag nog geen initiatingActor aan de zaak gekoppeld zijn.

Verwijder de initiatingActor van de zaak.

zet een nieuwe initiatingActor voor de zaak

initiatingSubject

Zet een initiatingSubject voor de zaak. Er mag nog geen initiatingSubject aan de zaak gekoppeld zijn.

Verwijder de initiatingSubject van de zaak.

Zet een nieuwe initiatingSubject voor de zaak.

responsibleActor

Zet een responsibleActor voor de zaak. Er mag nog geen responsibleActor aan de zaak gekoppeld zijn.

Verwijder de responsibleActor van de zaak.

zet een nieuwe responsibleActor voor de zaak

party Voeg de party toe aan de zaak of update de party als deze al bestaat

Verwijder de party van de zaak.

Voeg de party toe aan de zaak of update de party als deze al bestaat

extension Zet een nieuwe extension voor de zaak. De bestaande extension wordt vervangen.

Verwijder de extension van de zaak.

Zet een nieuwe extension voor de zaak.

postponement Zet een nieuwe postponement voor de zaak. De bestaande extension wordt vervangen.

Verwijder de postponement van de zaak.

Zet een nieuwe postponement voor de zaak.

otherCaseObject

Voeg een otherCaseObject toe aan de lijst van otherCaseObjects.

Verwijder de otherCaseObject uit de lijst.

Voeg een otherCaseObject toe aan de lijst


caseObject Voeg een caseObject toe aan de lijst.

Verwijder de caseObject uit de lijst.

Voeg een otherCaseObject toe aan de lijst.

characteristic Voeg een characteristic toe aan de zaak.

Verwijder de characteristic. Update de characteristic.

caseRelation Voeg een zaak relatie toe aan de zaak.

Verwijder de zaak relatie. Geen actie.

Tabel 39 - verwerkingssoort per element

De StUF handleiding StUF 03.01: In Gebruik bevat een beschrijving voor het opbouwen van het Lk01 bericht, zie sectie 5.2 Regels voor enkelvoudige kennisgevingberichten (Lk01, Lk02, Lk05 of Lk06). De StUF standaard heeft meer configuratiemogelijkheden voor het bericht dan de Cases interface: zo werkt StUF met mutatieSoort, indicatorOvername en verwerkingssoort elementen en attributen en is het mogelijk om zowel de oude als de nieuwe zaak in 1 bericht mee te sturen. Dit zorgt voor heel veel kruiscombinaties en complexe scenario’s die via logische regels gemapped moeten worden naar de Exxellence Cases interface. Omdat het maken van generieke regels niet voor de hand ligt worden in de onderstaande tabel regels beschreven voor scenarios die in de praktijk in gebruik zijn.

scenario regel voor StUF zakLk01 bericht mapping naar updateCaseStuf

update initiatingActor mutatiesoort=W 2 <object> elementen (oud

en nieuw) nieuw <object> bevat 1

element <heeftAlsInitiator verwerkingssoort="T">

<heeftAlsInitiator> bevat een <medewerker> of <organisatorischeEenheid> element

<heeftAlsInitiator> van 2de <object> mappen naar <initiatingActor verwerkingssoort=’W’>

update initiatingSubject mutatiesoort=W 2 <object> elementen (oud


element <heeftAlsInitiator verwerkingssoort="T">

<heeftAlsInitiator> bevat een <nietNatuurlijkPersoon>, <natuurlijkPersoon> of <vestiging> element

<heeftAlsInitiator> van 2de <object> mappen naar <initiatingSubject verwerkingssoort=’W’>

update responsibleActor mutatiesoort=W 2 <object> elementen (oud


element <heeftAlsVerantwoordelijke verwerkingssoort="T">

< heeftAlsVerantwoordelijke> van 2de <object> mappen naar <responsibleActor verwerkingssoort=’W’>

verwijderen/toevoegen/wijzigenoverige objecten

mutatiesoort=W oud of nieuw <object> bevat

een element anders dan heeftAlsInitiator en heeftAlsVerantwoordelijke met verwerkingssoort=”T”, “V” of “W”

element mapt naar party, extension, postponement, otherCaseObject, caseObject, charactersitic of caseRelation

mappen volgens regels in 3.2.2 van element, zowel uit oud als nieuw <object> en verwerkingssoort overnemen (“T”, “V” of “W”)

Tabel 40 - mapping regels StUF zakLk01 bij gebruik 2 <object> elementen

3.2.6 Genereer ZaakidentificatieDeze service (genereerZaakidentificatie_Di02) biedt zaakserviceconsumers de mogelijkheid om een uniek en geldige zaakidentificatie te ontvangen. De zaakserviceconsumer stuurt hiervoor een vrij genereerZaakIdentificatie_Di02 bericht naar het zaaksysteem en ontvangt synchroon als reactie de


zaakidentificatie in een genereerZaakIdentificatie_Du02 bericht. Hierbij worden aan het zaaksysteem de volgende eisen gesteld:

1. De uitgegeven zaakidentificatie wordt gereserveerd en wordt eenmalig uitgegeven.

2. De uitgegeven zaakidentificatie is uniek binnen de gemeente.

3. Er wordt direct (synchroon) een zaakidentificatie teruggestuurd.

4. Het formaat van de zaakidentificatie voldoet aan het RGBZ (40 alfanumerieke karakters waarvan de eerste vier gevuld zijn met de gemeentecode van de gemeente die verantwoordelijk is voor de behandeling van de zaak).

Aan eis 1 t/m 3 kan voldaan worden zolang we eis 1 interpreteren als synchroon. Omdat het formaat van zaakidentificatie ingesteld kan worden in het Exxellence ZaakSysteem kan noodzakelijkerwijs niet per definitie voldaan worden aan de 4e eis. Alleen als dit formaat ingesteld is op het RGBZ formaat wordt voldaan aan de vierde eis en anders niet.

In het Exxellence ZaakSysteem biedt de getReferenceNumber operatie functionaliteit voor het genereren van een zaakidentificatie. Deze service heeft een leeg vraagbericht, het antwoordbericht van deze service is weergegeven in Tabel 41.

StUF Zaken element RGBZ attribuut / waarde getReferenceNumber elementzaak cases.case

identificatie Zaakidentificatie referenceNumberTabel 41 – Genereer zaakidnetificatie antwoordbericht (Du02) .


3.2.7 Geef lijst ZaakdocumentenDeze service (geefLijstZaakdocumenten_Lv01) biedt zaakserviceconsumers de mogelijkheid om een lijst met referenties op te vragen naar documenten behorende bij een lopende zaak middels een vraag/antwoordinteractie. De zaakserviceconsumer krijgt in deze interactie de hoedanigheid van documentserviceconsumer. In het antwoordbericht staan alle zaakdocumenten (de relatie tussen zaak en document) die bekend zijn bij het zaaksysteem. Hierbij worden aan het zaaksysteem de volgende eisen gesteld:

1. Het zaaksysteem is de authentieke bron voor de relatie zaakdocument.

2. Het zaaksysteem retourneert alle voor hem bekende zaakdocument relaties in het antwoordbericht.

Aan deze beide eisen kan voldaan worden. In het Exxellence ZaakSysteem biedt de listDocuments operatie functionaliteit voor het opvragen van lijsten van een zaakdocumenten. Het vraagbericht van deze service is weergegeven in Tabel 42.

StUF Zaken element RGBZ attribuut / waarde Zaaksyteem elementgelijk.object Selectie criteria van de zaak.

identificatie Zaakidentificatie case.referenceNumberscope.object.heeftRelevant

gerelateerde.identificatie -antwoord.object.heeftRelevant Scope van het antwoordbericht.

(zie Tabel 43)Tabel 42 – Geef lijst zaakdocumenten vraagbericht (zakLv01).

Het is niet geheel duidelijk wat de interpretatie moet zijn van de ‘-’ waarde voor het scope.object.heeftRelevant.gerelateerde.identificatie element. Afgaande op het antwoordbericht (zie Tabel 43) bevat dit element normaliter een documentidentificatie en wordt met ‘-’ aangegeven dat voor dit element in het vraagbericht per definitie geen waarde ingevuld mag worden.

StUF Zaken element RGBZ attribuut / waarde listDocuments elementantwoord.object documents. document

identificatie Zaakidentificatie case.referenceNumberVoor elk gerelateerd documentantwoord.object.heeftRelevant

titel Zaakdocument titelbeschrijving Zaakdocument beschrijvingregistratiedatum Registratiedatumgerelateerde

identificatie Documentidentificatie referenceNumbercreatiedatum Documentcreatiedatum creationDateontvangstdatum Documentontvangstdatum receiptDatetitel Documenttitel titlebeschrijving Documentbeschrijving descriptionverzenddatum Document verzenddatum sendDatevertrouwelijkheidAanduiding Vertrouwelijkaanduiding confidentialityLevelNameauteur Documentauteur authorformaat Documentformaattaal Documenttaalversie Documentversie versionstatus Documentstatus statuslink Documentlink url

Tabel 43 – Geef lijst zaakdocumenten antwoordbericht (zakLa01).

Opmerking: in het zaaken documentservices document staat registratiedatum in het antwoordbericht onder de zaakidentificatie. Dit is een fout, registratiedatum vormt, samen met titel en beschrijving, in het RGBZ de zaakdocument entiteit. In Tabel 43 is dit als zodanig weergegeven.

Om deze operatie te kunnen implementeren moet in het Exxellence ZaakSysteem de document entiteit gelijk getrokken worden met de RGBZ definitie. Daarnaast moet de zaakdocument entiteit toegevoegd worden voorzien van de extra restrictie die beschreven is in sectie 2.4 om te voorkomen dat een document aan meerdere zaken gekoppeld wordt. Omdat document en zaakdocument een aantal


attributen delen (titel en beschrijving) is het geen optie om de ontbrekende attributen van zaakdocument aan document toe te voegen. Zodra de berichten aangepast zijn voor deze berichten kunnen de ontbrekende elementen toegevoegd worden aan Tabel 43.

Bovenstaande opzet gaat er vanuit dat de te retourneren gegevens uit de database van het Exxellence ZaakSysteem gehaald worden. Vanuit een klant is recentelijk de vraag gekomen of dit configurabel gemaakt kan worden waarmee ingesteld kan worden of deze gegevens uit de database of uit het ingestelde DMS gehaald moeten worden. Het doel hiervan is dat een document aan het DMS toegevoegd kan worden buiten het zaaksysteem om die daarna toch zichtbaar wordt in het zaaksysteem (zie Figuur 11).

DMS

Exxe

llenc

e M

idO

ffice Exxellence ZaakSysteem

Exxellence ZakenMagazijn

Exxellence ZaakTypeCatalogus

ZaakSysteem database

ExxellenceKlant Contact Systeem

WerkplekFiguur 11 – Zaaksysteem met directe toegang tot DMS.

Dit is theoretisch mogelijk als aan de volgende voorwaarden kan worden voldaan:

1. Het DMS moet per document de in Tabel 45 beschreven attributen bevatten. De minimale set bestaat hierbij uit de verplichte attributen, de optionele attributen zouden echter ook aanwezig moeten zijn.

2. Het DMS moet per document een link kunnen geven die locatie onafhankelijk is. Het RGBZ bevat, zoals in bovenstaande tabel te zien is, geen attributen om informatie over de structuur waarin documenten zijn opgeslagen in het DMS te retourneren. Om een document te kunnen opvragen via de geefZaakdocumentLezen operatie is het daarom noodzakelijk dat er een locatie onafhankelijk link (in welke vorm dan ook) bepaald kan worden.

3. Het DMS moet de lijst met documenten van een zaak in een enkele aanroep opleveren. Vanuit een perfomance oogpunt is het onwenselijk dat vanuit het zaaksysteem de hele structuur van het DMS uitgelezen moet worden. Omdat documenten buiten het zaaksysteem om toegevoegd kunnen worden is het niet mogelijk deze gegevens te cachen. Dit heeft concreet tot gevolg dat het DMS continu opnieuw uitgelezen moet worden, dit is alleen mogelijk als dit laatste snel gedaan kan worden.

3.2.8 Geef Zaakdocument lezenDeze service (geefZaakdocumentLezen_Lv01) biedt documentserviceconsumers de mogelijkheid om een kopie van een document behorende bij een zaak op te vragen uit het DMS middels een vraag-/antwoordinteractie. Het zaaksysteem benadert het DMS middels CMIS om het gewenste document op te halen en in een StUF antwoordbericht terug te sturen naar de documentserviceconsumer. Hierbij worden aan het zaaksysteem de volgende eisen gesteld:



Aan deze eis kan voldaan worden. In het Exxellence ZaakSysteem biedt de readDocument operatie van de DocumentVaultSynchConnector functionaliteit voor het opvragen van de inhoud van een document inclusief metadata. Het vraagbericht van deze service is weergegeven in Tabel 44.

StUF Zaken element RGBZ attribuut / waarde Zaaksyteem elementgelijk Selectie criteria van de document.

identificatie Documentidentificatiescope.object.heeftRelevant Scope van het antwoordbericht.

gerelateerde.identificatie -antwoord.object.heeftRelevant

(zie Tabel 45)Tabel 44 – Geef zaakdocument lezen vraagbericht (edcLv01).

Analoog aan het geef lijst zaakdocumenten vraagbericht (zie Tabel 42) betekend het ‘-’ voor het scope.object.heeftRelevant.gerelateerde.identificatie dat er geen waarde ingevuld mag worden voor dit element (de zaakidentificatie). Het antwoordbericht van deze service is weergegeven in Tabel 45.

StUF Zaken element RGBZ attribuut / waarde readDocument elementantwoord.object

identificatie Documentidentificatie referenceNumber.gerelateerde case

identificatie Zaakidentificatie referenceNumberdct documentType

omschrijving Documenttype omschrijving descriptioncategorie Documenttype categorie

titel Documenttitel titlecreatiedatum Documentcreatiedatum creationDateontvangstdatum Documentontvangstdatum receiptDatetitel Documenttitel titlebeschrijving Documentbeschrijving descriptionverzenddatum Document verzenddatum sendDatevertrouwelijkAanduiding Vertrouwelijkaanduiding confidentialityLevelNameauteur Documentauteur authorformaat Documentformaat formattaal Documenttaalversie Documentversie versionstatus Documentstatus statusinhoud Documentinhoud document

@xmime:contentType MimeType mimeType@bestandsnaam Bestandsnaam fileName

heeftRelevant.gerelateerde.link Documentlink Tabel 45 – Geef zaakdocument lezen antwoordbericht (edcLa01)

Opmerking: in de zaaken documentservices specificatie wordt voor het antwoordbericht van deze service tweemaal een documenttitel element voorgeschreven (de ene verplicht, de andere optioneel). Hoe dit geïnterpreteerd moet worden is een volkomen raadsel…

In Tabel 45, maar ook in verdere tabellen, verwijzen elementen in het bericht met een @ naar attributen. Met het inhoud@xmime:contentType element wordt dus het xmime:contentType attribuut van het inhoud element bedoelt. Om deze operatie te kunnen realiseren moeten de volgende aanpassingen doorgevoerd worden:

1. De document entiteit zodanig aangepast worden dat deze conform RGBZ is (zie 2.4). Concreet betekend dit dat de formaat, taal en status attributen moeten worden toegevoegd.

2. Het antwoordbericht van de readDocument operatie moet als volgt aangepast worden:

a. Categorie moet toegevoegd worden aan het documenttype blok. Dit element is aanwezig in het datamodel en kan zonder al te grote aanpassingen toegevoegd worden.


b. Vertrouwelijkaanduiding moet aangepast worden, voor de vertrouwelijk aanduiding wordt nu het interne nummer doorgegeven zoals dat wordt opgeslagen bij het document. Hier moet de bijbehorende naam aan bijgevoegd worden, deze bevat de correcte waarde voor het bijbehorende StUF element.

Het datamodel van het Exxellence ZaakSysteem bevat geen attribuut voor het opslaan van de link naar de documentinhoud (het “Documentlink” attribuut uit Tabel 45). Deze link zou door elke medewerker gebruikt moeten kunnen worden om de inhoud van het document op te vragen, echter hierbij wordt geen rekening gehouden met beveiliging. Aangezien dit vanuit een security oogpunt uitermate onwenselijk is worden in het Exxellence ZaakSysteem deze links gegenereerd voor een specifieke medewerker. Bepaald zal moeten worden of het “Documentlink” standaard leeg gelaten wordt of dat deze gevuld gaat worden met een gegenereerde, veilige, URL.

3.2.9 Geef zaakdocument bewerkenDeze service (geefZaakdocumentbewerken_Di02) biedt dezelfde functionaliteit als de ‘Geef Zaakdocument lezen’ service (zie sectie 3.2.8) met het verschil dat het document nu bewerkt mag worden door de documentserviceconsumer. Het document wordt daarbij vergrendeld zodat het niet gewijzigd kan worden door derden tot de documentserviceconsumer via de ‘Update Zaakdocument’ service (zie sectie 3.2.12) wijzigingen heeft doorgevoerd. Er wordt gebruik gemaakt van StUF-Dienstberichten om extra gegevens met betrekking tot locking mee te kunnen geven.

De documentserviceconsumer dient gebruik te maken van de 'Update Zaakdocument' service of de 'cancelCheckOut' service om ervoor te zorgen dat het document weer beschikbaar komt voor anderen om te muteren (ontgrendelen). Hierbij worden aan het zaaksysteem de volgende eisen gesteld:

1. Indien een fout optreedt, vindt er geen verwerking plaats (eventueel reeds uitgevoerde acties worden teruggedraaid). De zaakserviceconsumer wordt hiervan op de hoogte gesteld middels een StUF foutbericht.

Aan deze eis kan voldaan worden. In het Exxellence ZaakSysteem biedt de readDocument operatie van de DocumentVaultSynchConnector functionaliteit voor het opvragen van de inhoud van een document inclusief metadata met een mogelijkheid tot checkout. Het vraagbericht van deze service is weergegeven in Tabel 46.

StUF Zaken element RGBZ attribuut / waarde Zaaksyteem elementgelijk Selectie criteria van de document.

identificatie DocumentidentificatieTabel 46 – Geef zaakdocument bewerken vraagbericht (geefZaakdocumentbewerken_Di02).

Het antwoordbericht van deze service is weergegeven in Tabel 46.

StUF Zaken element RGBZ attribuut / waarde readDocument elementantwoord.object

identificatie Documentidentificatie referenceNumberisRelevantVoor.gerelateerde case

identificatie Zaakidentificatie referenceNumberdct documentType

omschrijving Documenttype omschrijving descriptioncategorie Docmenttype categorie

titel Documenttitel titlecreatiedatum Documentcreatiedatum creationDateontvangstdatum Documentontvangstdatum receiptDatetitel Documenttitel titlebeschrijving Documentbeschrijving descriptionverzenddatum Document verzenddatum sendDatevertrouwelijkAanduiding Vertrouwelijkaanduiding confidentialityLevelNameauteur Documentauteur authorformaat Documentformaattaal Documenttaalversie Documentversie versionstatus Documentstatus statusinhoud Documentinhoud document

@xmime:contentType mimeType mimeType@bestandsnaam fileName fileName


heeftRelevant.gerelateerde.link DocumentlinkcheckedOutId De technische sleutel van de

"Private Working Copy"checkedOutBy Gebruikersnaam van persoon

die document heeft opgevraagd voor bewerking.

checkout.employeeUsername

Tabel 47 – Geef zaakdocument bewerken antwoordbericht (geefZaakdocumentbewerken_Du02).

Om deze service te kunnen realiseren moeten de aanpassingen doorgevoerd worden die bij “Geef Zaakdocument lezen” zijn beschreven (zie sectie 3.2.8). Daarnaast moet uitgezocht worden welke waarde ingevuld moet worden voor het “checkedOutId” attribuut. Idealiter wordt hier binnen het Exxellence ZaakSysteem standaard de string te gebruiken die door Alfresco gebruikt wordt om een uitgechecked document mee aan te geven. Omdat er zit geen lengte restrictie op het “checkedOutId” attribuut kan feitelijk alles ingevuld worden en zou dit moeten passen. Wel dit het readDocument antwoordbericht voorzien te worden van een element waarmee de waarde van dit attribuut doorgegeven kan worden.A: Gebruikt extern referentienummer document in checkedOutId.

3.2.10 Voeg Zaakdocument toeDeze service (voegZaakdocumentToe_Lk01) biedt documentserviceconsumers de mogelijkheid om een nieuw document toe te voegen aan een lopende zaak. Hierbij moet altijd een documentidentificatie aangeleverd worden. De documentserviceconsumer kan zelf een documentidentificatie genereren of gebruik maken van de ‘Genereer Documentidentificatie’ service (zie sectie 3.2.13). Het zaaksysteem controleert altijd of de aangeleverde documentidentificatie uniek en geldig is. Het zaaksysteem maakt gebruik van de CMIS documentservices om de wijzigingen met het DMS te synchroniseren. Hierbij worden aan het zaaksysteem de volgende eisen gesteld:

1. Het zaaksysteem verwerkt berichten asynchroon en direct ("near realtime").

2. Het zaaksysteem controleert of de aangeleverde documentidentificatie uniek en geldig is.


Aan al deze eisen kan voldaan worden zolang we eis 1 interpreteren als synchroon. In het Exxellence ZaakSysteem biedt de addDocument operatie van de DocumentVaultSynchConnector functionaliteit voor het opvragen van de inhoud van een document inclusief metadata. Het vraagbericht van deze service is weergegeven in Tabel 48.

StUF Zaken element RGBZ attribuut / waarde addDocument elementobject


identificatie Zaakidentificatie referenceNumberomschrijving Zaak omschrijving

dct documentTypeomschrijving Documenttype omschrijving description

titel Documenttitel titlecreatiedatum Documentcreatiedatum creationDateontvangstdatum Documentontvangstdatum receiptDatetitel Documenttitel titlebeschrijving Documentbeschrijving descriptionverzenddatum Document verzenddatum sendDatevertrouwelijkAanduiding Vertrouwelijkaanduidingauteur Documentauteur authorformaat Documentformaattaal Documenttaalversie Documentversie Versionstatus Documentstatus statusinhoud Documentinhoud document

@xmime:contentType MimeType mimeType(default: application/octet-stream)

@bestandsnaam Bestandsnaam fileNameTabel 48 – Voeg zaakdocument toe vraagbericht (edcLk01).


Om deze operatie te kunnen realiseren moeten de volgende aanpassingen doorgevoerd worden:

1. De document entiteit zodanig aangepast worden dat deze conform RGBZ is (zie 2.4). Concreet betekend dit dat de formaat, taal en status attributen moeten worden toegevoegd.

2. Het vraagbericht van de addDocument operatie moet als volgt aangepast worden:

a. Omschrijving moet toegevoegd worden aan het vraagbericht. Analoog aan “Actualiseer Zaakstatus” (zie sectie 3.2.3) zou de omschrijving van de zaak aangepast moeten worden als dit element gevuld is.

b. Vertrouwelijkaanduiding moet aangepast worden, voor de vertrouwelijk aanduiding wordt nu het interne nummer doorgegeven zoals dat wordt opgeslagen bij het document. Hier moet de bijbehorende naam aan bijgevoegd worden, deze bevat de correcte waarde voor het bijbehorende StUF element.

Het antwoordbericht van deze service bevat slechts een bevestiging en is daarom niet weergegeven in deze sectie.

3.2.11 Maak ZaakdocumentDeze service (maakZaakdocument_Lk01) biedt documentserviceconsumers de mogelijkheid om een container (of placeholder) aan te maken voor een nieuw document. Het zaaksysteem maakt gebruik van de CMIS documentservices het DMS te synchroniseren. Hierbij worden aan het zaaksysteem de volgende eisen gesteld (zie volgende bladzijde):

1. Het zaaksysteem verwerkt alle berichten asynchroon en direct (‘near realtime’);

2. Het zaaksysteem controleert of de aangeleverde documentidentificatie uniek en geldig is (volgens RGBZ);

3. Indien een fout optreedt, vindt er geen verwerking plaats (eventueel reeds uitgevoerde acties worden teruggedraaid). De documentserviceconsumer wordt hiervan op de hoogte gesteld middels een StUFfoutbericht.

Aan al deze eisen kan voldaan worden zolang we eis 1 interpreteren als synchroon. In het Exxellence ZaakSysteem biedt de addDocument operatie van de DocumentVaultSynchConnector functionaliteit voor het opvragen van de inhoud van een document inclusief metadata. Het vraagbericht van deze service is weergegeven in Tabel 49.

StUF Zaken element RGBZ attribuut / waarde addDocument elementobject


identificatie Zaakidentificatie referenceNumberomschrijving Zaak omschrijving

dct documentTypeomschrijving Documenttype omschrijving description

titel Documenttitel titlecreatiedatum Documentcreatiedatum creationDateontvangstdatum Documentontvangstdatum receiptDatebeschrijving Documentbeschrijving titleverzenddatum Document verzenddatum descriptionvertrouwelijkAanduiding Vertrouwelijkaanduiding sendDateauteur Documentauteurformaat Documentformaat authortaal Documenttaalversie Documentversie versionstatus Documentstatus statusinhoud@xmime:contentType MimeType mimeType

(default: application/octet-stream)inhoud@bestandsnaam Bestandsnaam fileName

Tabel 49 – Maak zaakdocument vraagbericht (edcLk01).


Deze operatie kan eenvoudig gerealiseerd worden door de addDocument operatie aan te roepen zonder inhoud. De noodzakelijk aanpassingen komen dan overeen met de in de voorgaande sectie beschreven aanpassingen.A: Indien geen binaire data wordt meegegeven moet geen aanroep naar het DMS plaatsvinden, omdat een DMS alleen documenten accepteert als er ook binaire data wordt meegestuurd.

3.2.12 Update ZaakdocumentDeze service (updateZaakdocument_Lk01) biedt documentserviceconsumer de mogelijkheid om de fysieke inhoud aan een container toe te voegen (zie sectie ). Daarnaast kunnen ook attributen van een document worden gemuteerd of toegevoegd. Het zaaksysteem maakt gebruik van de CMIS-documentservices om de wijzigingen in het DMS te synchroniseren. Hierbij worden aan het zaaksysteem de volgende eisen gesteld:

1. Het zaaksysteem verwerkt alle berichten asynchroon en direct (‘near realtime’);

2. Indien een fout optreedt, vindt er geen verwerking plaats (eventueel reeds uitgevoerde acties worden teruggedraaid). De documentserviceconsumer wordt hiervan op de hoogte gesteld middels een StUF-foutbericht.

Aan al deze eisen kan voldaan worden zolang we eis 1 interpreteren als synchroon.

Om deze service te kunnen realiseren is een ‘checkIn’ vlag toegevoegd aan de addDocument operatie op de DocumentVaultSynchConnector. In tegenstelling tot de zaaken documentservices werkt het Exxellence ZaakSysteem niet met een expliciet “checkedOutId” en kan volstaan worden met een boolean attribuut (zie ook sectie Tabel 51). Voor de mapping van het bericht, zie Tabel 49 – Maak zaakdocument vraagbericht (edcLk01).

De updateZaakdocument_Di02 object . inhoud is in zaak-DMS 1.1 verplicht maar is in zaak-DMS 1.2 optioneel geworden. Omdat in productie aanlopen tegen implementaties van zaak-DMS 1.2 consumers, willen we voor dit gedeelte compliant zijn aan zaak-DMS versie 1.2.Dit word geïmplementeerd door toe te staan dat het updateZaakdocument_Di02, zonder ns:inhoud toe te staan.Referentie: Standaard Zaak- en Documentservices 1.2 Documentversie 1.2.01, hoofstuk 4.3.6.2 Interactie tussen DSC en ZS.

Implementatie van updateZaakdocument_Di02 zonder inhoud of noValue="waardeOnbekend" word omgezet in een aanroep op de DocumentVaultSynchConnecter AddDocumentRequest met attribuut checkIn="true".Het zaak systeem zal een nieuw versie van het document toevoegen met meta data van de AddDocumentRequest, en de document inhoud word overgenomen van het uitgecheckte document.

3.2.13 Genereer DocumentidentificatieDeze service (genereerDocumentidentificatie_Di02) biedt documentserviceconsumers de mogelijkheid om een uniek en geldige documentidentificatie op te halen. De documentserviceconsumer stuurt hiervoor een vrij bericht naar het zaaksysteem en ontvangt synchroon als reactie een geldige documentidentificatie. Hierbij worden aan het zaaksysteem de volgende eisen gesteld:

1. De uitgegeven documentidentificatie wordt gereserveerd en wordt eenmalig uitgegeven.

2. De uitgegeven documentidentificatie is uniek binnen de gemeente.

3. Er wordt direct (synchroon) een document identificatie teruggestuurd.

Aan eis 1 t/m 3 kan voldaan worden zolang we eis 1 interpreteren als synchroon. In het Exxellence ZaakSysteem is er nog geen getReferenceNumber equivalent voor het genereren van een documentidentificatie, deze zal toegevoegd moeten worden. Het antwoordbericht van deze service is weergegeven in Tabel 50.

StUF Zaken element RGBZ attribuut / waarde Zaaksyteem elementdocument

identificatie DocumentidentificatieTabel 50 – Genereer documentidentificatie antwoordbericht (genereerDocumentIdentificatie_Du02).


3.2.14 Cancel CheckOutDeze service (cancelCheckout_Di02) biedt documentserviceconsumers de mogelijkheid om aan te geven dat er geen bijgewerkte versie komt van een document dat in een eerder stadium is opgevraagd voor bewerking via de 'Geef zaakdocument bewerken' service. Hierbij worden aan het zaaksysteem de volgende eisen gesteld:

1. Het zaaksysteem verwerkt alle berichten asynchroon en direct (“near realtime”);

2. Indien een fout optreedt, vindt er geen verwerking plaats (eventueel reeds uitgevoerde acties worden teruggedraaid). De documentserviceconsumer wordt hiervan op de hoogte gesteld middels een StUF-foutbericht.

Aan al deze eisen kan voldaan worden zolang we eis 1 interpreteren als synchroon. In het Exxellence ZaakSysteem biedt de cancelCheckout operatie van de DocumentVaultSynchConnector functionaliteit voor het annuleren van de checkout van een document. Het vraagbericht van deze service is weergegeven in Tabel 51.

StUF Zaken element RGBZ attribuut / waarde cancelCheckout elementdocument

identificatie Documentidentificatie referenceNumbercheckedOutId De technische sleutel van de

"Private Working Copy"Tabel 51 – Cancel checkout vraagbericht.

Voor het annuleren van de checkout van een document in Alfresco volstaat de documentidentificatie. Het “checkedOutId” attribuut wordt genegeerd in deze service.


3.3 User mappingOmdat meerdere consumer applicaties aangesloten kunnen worden op ZaakDMS is er voor gekozen om een gebruikersmapping toe te voegen tussen de StUF servicelaag en de MidOffice. Hierdoor is het mogelijk om voor iedere ZDMS aansluiting specifieke gebruikers en rechten in te richten binnen de MidOffice .

Alle StUF berichten bevatten een <zender> element binnen het <stuurgegevens> element waarmee een gebruiker meegegeven kan worden. De consumer applicatie vult dit veldt en de OpenTunnel instantie mapt het element naar de MidOffice services. De tabellen hieronder beschrijven de mapping naar de verschillende MidOffice berichten per WSDL. StUF stuurgegevens element requestProperties elementzender.applicatie user

password=<configured password>domain=MidOffice

Tabel 52: user mapping cases.wsdl en documents.wsdl naar requestProperties

StUF stuurgegevens element provider elementzender.applicatie employeeUsername

Tabel 53: user mapping DocumentVaultSynchConnector.wsdl en documents.wsdl naar provider

3.3.1 Security header Exxellence Suite 7.0In Exxellence Suite 7.0 en hoger moet een security header worden meegegeven naar de Exxelence MiddOffice.Reden hiervan is dat in de 7.0 architectuur niet meer direct met de MidOffice word gecommuniceerd, maar dat er een WSO2 ESB in de keten is opgenomen.

StUF stuurgegevens element Security Header elementzender.applicatie user

password=<configured password>domain=MidOffice

Tabel 54: user mapping CasesProxy, DocumentServiceProxy en DocumentVaultSynchConnectorProxynaar requestProperties

StUF stuurgegevens element provider elementzender.applicatie employeeUsername

Tabel 55: user mapping DocumentVaultSynchConnector.wsdl en documents.wsdl naar provider

3.3.1.1 Voorbeeld security header <soapenv:Header> <wsse:Security xmlns:wsse="http://schemas.xmlsoap.org/ws/2003/06/secext"> <wsse:UsernameToken wsu:Id="user@domain" xmlns:wsu="http://schemas.xmlsoap.org/ws/2003/06/utility"> <wsse:Username>user@domain</wsse:Username> <wsse:Password Type="wsse:PasswordText">password</wsse:Password> </wsse:UsernameToken> </wsse:Security> </soapenv:Header>


3.4 Identifier matcher3.4.1 Object type namesDe volgende identifier matcher object types zijn gedefineerd voor de Zaak-DMS brug identifier matching.

objectTypeName StUF ZKN objectMDW medewerker.identificatieOEH organisatorischeEenheid.identificatieZAKZKT isVan.gerelateerde.codeSTT.code heeft.gerelateerde.code (Als de Zaak-DMS

consumer een STT code en volgnummer zet in de request, word de code gebruikt om de STT id te bepalen.

STT.volgnummer heeft.gerelateerde.volgnummerZAKBTROVR heeftAlsOverigBetrokkene.coderesultaat.omschrijving resultaat.omschrijvingDCT dct.omschrijving

Tabel 56: identifier matcher object types

3.4.2 TransformationsIn Zaak-DMS brug (versie ZDS1.1-7.0.3 en hoger) zijn transformaties toegevoegd voor de StUF vraag berichten en voor de Exxellence response berichten. Deze transformaties doen per identifier matcher object een vraag naar de identifier matcher met de te matchen identifiers.

request (Stuf-messages) Identifier matcher object name//ZKN:gerelateerde/ZKN:medewerker/ZKN:identificatie MDW//ZKN:gerelateerde/ZKN:organisatorischeEenheid/ZKN:identificatie

OEH

//ZKN:isVan/ZKN:gerelateerde/ZKN:code ZAKZKT//ZKN:heeft/ZKN:gerelateerde/ZKN:code STT.code//ZKN:heeft/ZKN:gerelateerde/ZKN:volgnummer STT.volgnummer//ZKN:heeftAlsOverigBetrokkene/ZKN:code ZAKBTROVR//ZKN:resultaat/ZKN:omschrijving resultaat.omschrijving//ZKN:dct.omschrijving DCT

Tabel 57: identifier matcher request transformations

responses (Exxellence format) Identifier matcher object namecases:employee/cases:identification MDWcases:unit/cases:identification OEHcases:caseType/cases:code ZAKZKTcases:statusType/cases:code STT.codecases:statusType/cases:sequenceNumber STT.volgnummercases:party/cases:roleTypeCode ZAKBTROVRcases:result/cases:description resultaat.omschrijvingdocument:documentType/document:description(document="http://www.emaxx.org/functional/cases/document")syn:documentType/syn:description(syn="http://www.emaxx.org/functional/documents/synch")

DCT

Tabel 58: identifier matcher response transformations

4. ReferentiesDit hoofdstuk beschrijft kort alle referenties naar documenten en websites die gebruikt zijn in dit document.

Documenten[D1] Standaard Zaak- en Documentservices 1.1, april 2014, Kwaliteits Instituut Nederlandse


Gemeenten.[D2] Referentiemodel Gemeentelijke Basisgegevens Zaken (RGBZ) versie 1.0 (in gebruik), september

2010, Kwaliteits Instituut Nederlandse Gemeenten.

Web[W1]
