Gemeente Peel en Maas, Visma Circle en Roxit werken samen om te kijken hoe Rx.Mission middels de ZGW-Api’s kan aansluiten op Djuma. Zodra dat mogelijk is, moet een groot aantal zaaktypes, zaken en documenten vanuit OneGround overgezet worden naar Djuma. Het mooie van de ZGW-Api’s is, dat je vrijwel alles wat je toevoegt aan een registratie met deze API's, ook weer uit de registratie kan halen. Dat maakt een migratie enkel en alleen middels ZGW-API's mogelijk. Dus een zaak die ooit middels de ZRC-API in systeem A is geplaatst, wordt daar middels de ZRC-API opgehaald bij een migratie en vervolgens opnieuw weggeschreven middels de ZRC-API naar systeem B. Er zijn daarbij geen door mensen gemaakte mappings meer nodig. Zodra een aantal toegangsgegevens is ingevoerd, kan de migratie volautomatisch worden voltooid. Althans dat was het idee.

Er waren ook vragen bij dit idee. Kan de historie die is  opgebouwd in systeem A goed gereproduceerd kon worden naar systeem B? Komen verschillende documentversies en zaaktypeversies goed over? Kunnen bepaalde regels in de ZGW-API's wel twee keer werken? Een voorbeeld van zo'n regel is dat het toevoegen van de eindstatus die de einddatum van de zaak bepaalt. Kan die toevoeging wel opnieuw in systeem B? We besloten deze vragen te beproeven  middels een  Postmanproject waarin Circle en Roxit tegelijk konden werken.

Stap 1: consumer app werkt met zaken en documenten in Systeem A middels ZGW-API’s; Stap 2: de migratietool kopieert alle zaken en documenten van Systeem A naar systeem B middels ZGW-API’s; Stap 3: consumer app werkt met zaken en documenten in Systeem B middels ZGW-API’s.

De proef is geslaagd. Het lukte ons een afgesloten zaak, dus met resultaat en eindstatus, over te zetten van OneGround naar Djuma. Ook konden we documenten aan die zaak toevoegen. Dat het zaaktype verlopen was (einddatum in het verleden) was ook geen probleem. Het is dus mogelijk afgesloten zaken met zaaktypeversies uit het verleden te migreren met de ZGW-API's zoals ze nu geïmplementeerd zijn.

Postman zelf bleek minder handig voor deze migratie-test dan we verwachtten. Er zijn te veel cycli in het migratie proces en te veel variabelen om het inzichtelijk te houden. Naast de proef met Postman hebben we nog daarom nog in de Api-specs gekeken of het mogelijk zou moeten zijn alle documentversies middels de Api's over te zetten, alle zaaktypeversies, en alle archiveringsparameters. We zagen geen belemmeringen. Toch zal niet 100% van de data gemigreerd kunnen worden. Voor de audit trails weten we dat de API-methodes om ze aan te maken in het doelsysteem ontbreken. En bepaalde registratiedatums worden door de registraties zelf gezet en zullen daardoor verschillen tussen bron- en doelsysteem. Essentiële datums zoals startdatum , einddatum en ontvangstdatum komen correct over.

Voorbeeld van verwijzing naar hetzelfde zaaktype in Oneground (boven) en Djuma (onder)

Een belangrijke vraag is hoe verwijzingen naar de ZTC het beste kunnen worden overgezet door de migratietool. Iedere zaak, iedere zaakstatus en ieder document bevat een een dergelijke verwijzing  die  bestaat uit een url met een unieke uuid (zie figuur hierboven). De uuids worden  door het systeem zelf bepaald en kunnen niet worden toegevoegd/gemigreerd middels de API’s. Om dit probleem op te lossen zien we drie mogelijkheden:

• de gehele ZTC kan worden gemigreerd middels API-methodes. Tijdens de migratie kan een mappingtabel gevuld worden waarin de bron-url wordt opgeslagen naast de nieuwe doel-url. Dit is de meest voor de hand liggende oplossing.
• De standaard zou kunnen worden aangepast zodat de uuid’s van de ZTC wél kunnen worden meegegeven middels de API's.
• De ZTC zou via een andere manier kunnen worden aangeleverd en ingelezen buiten de ZGW-API-migratietool om.

De conclusie is hoe dan ook dat de ZGW-API-migratietool mogelijk is. Voor het eerst bestaat de mogelijkheid voor de Nederlandse gemeentes dat een omvangrijke zaak- documentmigratie systeemonafhankelijk en volledig geautomatiseerd kan worden ingezet. Het voordeel is drieledig. Bij toekomstige migraties hebben we nog maar één (Open Source) migratietool nodig voor alle Nederlandse Zaak- en Documentapplicaties in plaats van vele maatwerktools bij verschillende leveranciers. Bij de migratie zelf zijn veel minder mensuren nodig. Het dataverlies tenslotte is minimaal. We verwachten ook meerdere toepassingen. Naast het overstappen tussen leveranciers valt te denken aan migraties binnen multi-tenantomgevingen. De tool kan bijvoorbeeld ingezet worden als een aantal gemeentes gaat fuseren of als een samenwerkingscombinatie wordt ontvlochten. Om deze redenen willen we nu gaan werken aan een volgende stap: het voorbereiden van de daadwerkelijke bouw van een ZGW-API-migratietool.

[email protected] en [email protected]