TL;DR: een mislukte persoonsimport maakt meer kapot dan je lief is. Dit overkwam een organisatie, die met de gebakken peren (en 435 dubbele entries) zat. In drie posts laat ik zien wat er is gebeurd, en wat ik heb gedaan om het te repareren.
In de eerste post van dit drieluik over het repareren van de persoonsimport heb ik het probleem geschetst, en in de tweede post heb ik laten zien hoe je kaarten herkoppelt. In deze laatste stap is het ontdubbelen van de 435 persoonskaarten aan de beurt. Ook het aanpassen van de bestaande persoonsimport komt aan de orde.
Stappenplan
Het is belangrijk om de stappen in de goede volgorde te volgen. Doe je dat niet, dan kunnen er onverwachte zaken gebeuren. Dus:
- Huidige persoonsimport uitschakelen.
- Bij de verkeerd aangemaakte personen: het veld tasloginnaam leegmaken.
- De verkeerd aangemaakte personen archiveren.
- De persoonsimport aanpassen; specifiek de optie “Gearchiveerde kaarten automatisch dearchiveren” inschakelen.
- De persoonsimport weer inschakelen.
Het koppelveld
De optie “Gearchiveerde kaarten automatisch dearchiveren” zorgt ervoor dat de import geen nieuwe persoonskaarten aanmaakt, wanneer er al een gearchiveerde persoonskaart bestaat. De import kijkt daarvoor naar een uniek koppelveld, bijvoorbeeld loginnaam of emailadres, om te beslissen of er een nieuwe kaart moet worden aangemaakt of dat er een bestaande kaart kan worden hergebruikt. Het hebben van unieke koppelvelden in de database is dus een voorwaarde om de import goed te laten werken.
Het koppelveld bij deze organisatie was tasloginnaam (in TOPdesk), en SamAccountName (in AD). Het was dus zaak om bij de 435 verkeerd aangemaakte persoonskaarten het veld tasloginnaam leeg te maken. Als dat is gebeurd, dan zijn de 435 persoonskaarten die al bestonden daadwerkelijk uniek geworden in de database. Dat is ook de bedoeling, want dat zijn nou juist de persoonskaarten waaraan de honderden tickets zijn herkoppeld (zie de vorige blogpost).
Het leegmaken van het veld tasloginnaam kan sinds TOPdesk-versie 5.4 niet meer met httprequests. Daarom heb ik ook hiervoor een aangepaste import gemaakt. Deze import koppelt op de unid van de verkeerd aangemaakte personen, en maakt van die kaarten het veld tasloginnaam leeg. Vervolgens kan ik de kaarten vanaf de webinterface heel eenvoudig allemaal archiveren.
Persoonsimport aanpassen
Nu de persoonskaarten op databaseniveau weer allemaal uniek zijn kunnen we de persoonsimport weer inschakelen. Alleen, als we dat doen, dan is het nog steeds mogelijk dat dezelfde verstoring nogmaals optreedt. Komt er weer een incomplete upload vanuit AD, dan hebben we hetzelfde probleem.
Om dit te voorkomen moeten we de optie “Gearchiveerde kaarten automatisch dearchiveren” inschakelen in de aangepaste import. Zoals eerder omschreven staat nergens gedocumenteerd hoe deze aangepaste imports werken. De optie waar het om gaat is sees_archive, op de volgende regel in de ImportDefinition XML van het importscript:
Deze stond op invisible, waardoor er nieuwe kaarten werden aangemaakt. De waarde retrieve hergebruikt gearchiveerde persoonskaarten, en moet het dus worden.
WIN!
Nu de persoonsimport is aangepast is het tijd om deze opnieuw draaien. Als het goed is, doet de import niets. Dat komt omdat we met de hand in de vorige stap alles al hebben gefixt. Maar op de achtergrond hebben er structurele verbeteringen plaatsgevonden: de persoonsimport is robuuster en fail-proof gemaakt. Tegelijkertijd zijn meldingen en wijzigingen weer goed gekoppeld, zijn de rechten op de SelfServicePortal weer goedgezet, krijgen de juiste personen weer hun ingeplande rapporten toegestuurd, en zijn CMDB-items weer goed gekoppeld. WIN!
Laatste opmerkingen
Zoals blijkt uit dit verslag was het repareren van de mislukte persoonsimport geen sinecure. Testen, testen, en nogmaals testen was absoluut noodzakelijk was om tot een succesvol eindresultaat te komen. Voor de leesbaarheid heb ik dat maar even overgeslagen.
Verder ben ik me ervan bewust dat de gemiddelde TOPdesk-klant de stappen uit deze posts niet kan reproduceren. Dit komt vooral vanwege de security-through-obscurity aangepaste imports van TOPdesk. Deze functionaliteit is noodzakelijk om queries op SAAS te kunnen draaien, maar is niet-standaard, niet gedocumenteerd, en wordt ook niet ondersteund door TOPdesk support.
