Common Ground: wie beheert de zaaktypecatalogus?

Geschreven door Johannes Battjes, Application Owner

 


Wat is de stand van zaken?

​​​​​​​​​​​​​​In deze serie blogs bespreken we Common Ground en de toepassing ervan binnen Visma Roxit.
Er is een belangrijke mijlpaal bereikt. Afgelopen juli is Rx.Mission in onze preproductie-omgeving opgeleverd voor enkele tientallen klanten. Rx.Mission is voor wat betreft zaken, documenten en ZTC (zaaktypecatalogus) volledig op zeven ZGW (zaakgericht werken)-componenten van Common Ground gebaseerd. Daarmee ondersteunt Visma Roxit een belangrijk onderdeel van de voorgeschreven architectuur en standaarden. Een volgende stap is het delen van informatie met andere applicaties op basis van de ZGW-componenten. Dat kan twee kanten op gaan: andere applicaties sluiten aan op ZGW-API’s (onderdeel van de ZGW-componenten) van Visma Roxit of Rx.Mission sluit aan op de ZGW-API’s van anderen. Om deze integraties te testen zijn we pilots gestart met onze collega-software leveranciers.
​​​​​​​

Welke bevindingen hebben we in de pilots opgedaan?

Met ongeveer tien andere partijen zijn gesprekken gevoerd over aansluiten middels de ZGW-API’s. De meeste gesprekken zijn samen met onze wederzijdse klanten gedaan. Tot nu toe zijn we twee partijen tegengekomen die de ZGW-API’s volledig ondersteunen, beide met Open Zaak. De meeste andere partijen waren in verschillende stadia van ideevorming en ontwikkeling. Met een aantal zijn daadwerkelijke pilots gestart. Het meest ver zijn we nu met Digeplan dat aansluit op de Visma Roxit ZGW-API’s, en met Decos waarbij Rx.Mission aansluit op de ZGW-API’s van Decos. Het feit dat niet alle leveranciers alle zeven ZGW-componenten van versie 1.0 ondersteunen, leidt tot lastige vragen die we nog niet beantwoord hebben. Is het mogelijk om bijvoorbeeld op slechts twee componenten van een andere leverancier aan te sluiten?

Een daadwerkelijke test begint met het uitwisselen van connectiviteitsgegevens (URL, identificatiegegevens, etc.) tussen medewerkers van de twee leveranciers. Het is opvallend dat vrijwel geen partij gebruik maakt van NLX of daar gebruik van wil maken. NLX is het door Common Ground gepromote hulpmiddel voor connectiviteit. In plaats daarvan lijken Client ID’s en secrets, al dan niet extra beveiligd met two-way SSL, voldoende bevonden te worden door de meeste leveranciers. Ondanks dat deze middelen bekend zijn, duurt het toch vaak lang voordat het eerste bericht succesvol over het lijntje gaat. Dit komt doordat de details van de aansluiting vaak net even iets verschillen tussen leveranciers. Zou een standaardisatie van deze manier van aansluiten als alternatief voor NLX kunnen helpen?

vth​​​​​​​

Problemen met URL's

De ZGW-registraties hebben een opmerkelijke manier van identificaties opslaan. Iedere identificatie (en verwijzing daarnaar) bestaat uit een URL. Een zaak in onze testomgeving heeft bijvoorbeeld deze identificatie: https://zaken-mega1.mega.local/api/v1/zaken/db6ea625-c34d-453f-9950-06baf45458ab
Hetzelfde geldt voor documenten, zaaktypes, betrokkenen, etc. Er zijn dus zeer veel URL’s in Common Ground. Hoewel die URL’s heel precies aangeven waar het om gaat, zijn ze voor mensen en andere systemen lastiger te begrijpen dan je zou verwachten. Aan niets in bovenstaande URL kun je bijvoorbeeld zien dat het om een zaak in de testomgeving van Visma Roxit gaat. Om hier wat aan te doen, ‘vertalen’ onze applicaties alle URL’s voordat ze naar buiten gaan zodat het externe systeem een bereikbare URL krijgt. Maar niet alle systemen doen dat. Een recente test met Open Zaak ging  al meteen mis omdat Open Zaak zijn interne URL’s aanbiedt die vanuit Rx.Mission niet bereikbaar zijn.

Een andere vraag is wat te doen met URL’s naar gegevens die nog niet in een ZGW- registratiecomponent staan zoals persoons- en objectgegevens. De URL naar deze gegevens die Rx.Mission plaatst, is betekenisloos voor een ander systeem dat deze gegevens opvraagt. Met andere woorden: het andere systeem kan niet zien wie de betrokkene is die een verzoek heeft gedaan of over welke inrichting het gaat.

Wie beheert de zaaktypecatalogus?

Terwijl bovenstaande bevindingen wel enigszins te voorzien waren, hadden we ook een verrassende discussie. Rx.Mission kent ook zaaktypebeheer. Voor ons vanzelfsprekend want al meer dan tien jaar beheren tientallen applicatiebeheerders hun zaaktypes in Squit XO. Maar met de komst van ZGW-API’s is er nog maar één plek waar zaaktypes worden opgeslagen. En “het centrale zaaksysteem” gaat er vanuit dat het centrale zaaksysteem de ZTC beheert. Toen wij aangaven dat Rx.Mission wijzigrechten moet hebben op de VTH-ZTC, was de reactie bij één organisatie: “dat kan toch niet, een leverancier mag toch niet de zaaktypes bepalen”. Dat was ook niet onze opzet, want niet de leverancier Visma Roxit wijzigt de zaaktypes maar de applicatiebeheerder die medewerker is van dezelfde organisatie. Blijkbaar was hier niet duidelijk dat in Squit XO al heel lang – tot ieders tevredenheid – zaaktypes worden beheerd. Bij een andere pilot bleek dat de wijzigfuncties op de ZTC in het geheel niet geïmplementeerd waren omdat men ervan uit gaat dat geen enkele applicatie de zaaktypes mag wijzigen. Over de ZTC is het laatste woord dus nog niet gezegd.

Al met al gaat de integratie op basis van ZGW-componenten langzaam. Tegelijk worden ook de potentiële voordelen van deze architectuur steeds duidelijker. Hierover meer in een volgende blog.
Heeft u een vraag of discussiepunt? Mail vooral naar johannes.battjes@roxit.nl

 

Heeft u een vraag?

Johannes Battjes
johannes.battjes@roxit.nl