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 vorige post heb ik het probleem van de mislukte persoonsimport uitgelegd. In deze post ga ik dieper in op het herkoppelen van honderden tickets. Die stonden namelijk gekoppeld aan de verkeerde personen.
Mapping maken
De eerste stap is het maken van een mapping, een Excelsheet met daarin per “echte” persoon de unid van de originele persoonskaart, en de unid van de verkeerd aangemaakte nieuwe persoonskaart. Met de CSV export wizard kun je de tabel persoon uitlezen, en inlezen in Excel. Je kunt de “oude” en de “nieuwe” persoonskaarten herkennen aan de datum/tijd van aanmaak, veld dataanmk. De nieuwe (verkeerde) zijn tenslotte allemaal op hetzelfde tijdstip aangemaakt, en de oude (goede) allemaal voor die tijd. Andere belangrijke velden die je meeneemt in de CSV export zijn dus unid en tasloginnaam. Met Excel kun je vervolgens duplicaten markeren, filteren, en verplaatsen, etc. Dat is een beetje een gedoetje, maar het kan wel. Het uiteindelijke doel is een lijst met nieuwe unids (de verkeerd aangemaakte persoonskaarten) en oude unids (de gearchiveerde oorspronkelijke persoonskaarten) naast elkaar.
Deze mapping is de sleutel voor het herkoppelen van de tickets, en moet dus absoluut kloppen.
Verkeerde tickets exporteren
De tickethistorie die was opgebouwd na de mislukte persoonsimport was al opgelopen tot ongeveer 900, zowel meldingen als wijzigingen. Dat zijn dus alle tickets die herkoppeld moeten worden. Met de juiste selectiecriteria kun je die meldingen naar boven halen:
- Selecteer alle meldingen die een aanmelder hebben met een datum/tijd van aanmaak $dag-van-de-verstoring
- Selecteer alle wijzigingen die een aanmelder hebben met een datum/tijd van aanmaak $dag-van-de-verstoring
Met de CSV export wizard exporteer je deze selecties uit de tabellen incident en change. Belangrijke velden zijn persoonid (de unid van de aanmelder), naam (meldingsnummer), en number (wijzigingsnummer). Het resultaat is een lijst zoals in de screenshot, met alle tickets die verkeerd zijn en die dus herkoppeld moeten worden.
Persoonid overschrijven
Het veld persoonid_unid in de screenshot hierboven komt overeen met de unid van de verkeerd aangemaakte persoonskaart, per melding of wijziging. De verstoring kun je dus terugdraaien door de verkeerde waarde van het veld persoonid te overschrijven met de goede waarde. Hiervoor gebruiken we de eerder gemaakte mapping.
Voorbeeldje: in de screenshot zien we bij melding M18120024 een aanmelder met de unid 5ebd982b6bfa4942ae355d438f7f6e89. In de mapping vinden we deze unid terug, namelijk als unid_nieuw van gebruiker jantje. Door het veld persoonid van de melding te overschrijven met de waarde van unid_oud kunnen we de melding dus herkoppelen aan de juiste persoonskaart. Met andere woorden, we veranderen het veld persoonid bij melding M18120024 van 5ebd982b6bfa4942ae355d438f7f6e89 naar e91f0cf80907402984552c4e97c4862f. Hiervoor gebruik je de optie Verticaal zoeken in Excel.
Doe hetzelfde bij alle andere tickets, en je hebt dan excellijsten waarbij je per ticket de unid van de juiste persoonskaart hebt (de gearchiveerde oorspronkelijke persoonskaart). Deze excellijsten zijn de input voor de volgende stap.
Importscripts
Met de excellijsten in de hand is het tijd voor de volgende hobbel: het wegschrijven van de nieuwe waardes in de TOPdesk-database. Dit is absoluut niet eenvoudig, omdat dit gebeurt met aangepaste imports. Dit is ongedocumenteerde en niet-standaard functionaliteit van TOPdesk. Je kunt ermee alle tabellen en velden in batch bewerken, en je kunt dus ook de mislukte persoonsimport helemaal terugdraaien. Laansloot IT genereert deze importscripts met behulp van zelfgeschreven software. Het gaat te ver om alle details van deze importscripts hier te bespreken.
Om de wijziging gecontroleerd en zorgvuldig uit te voeren heb ik de tickets in vijf losse imports verwerkt: eerstelijns meldingen, tweedelijns meldingen, wijzigingsaanvragen, eenvoudige wijzigingen, en uitgebreide wijzigingen. In de importlogs kun je zien wat een import precies heeft gedaan. Onderstaande screenshot laat het resultaat zien van 1 van de 5 imports. De import heeft hier 627 incidenten en 202 personen bewerkt. Het kleine verschil tussen records in source en modified komt overigens vanwege eerdere testruns op losse kaarten.
Het gekke is dat je na de import eigenlijk niet ziet dat de tickets zijn gekoppeld aan een andere persoon. Dat is omdat de verkeerde aangemaakte nieuwe persoon en de gearchiveerde oorspronkelijke persoon op het oog identiek zijn. Alle informatie is namelijk uit Active Directory uitgelezen. Op de SelfServicePortal is er wel een verschil. Daar zijn alleen tickets te zien die onderwater aan de correcte ingelogde gebruiker zijn gekoppeld.
* Volgende keer deel drie over het repareren van een mislukte persoonsimport: het ontdubbelen van de persoonskaarten.
