Bij 1 van grootste ziekenhuizen van Nederland heb ik recentelijk een SAP koppeling naar Active Directory opgeleverd met behulp van UMRA van Tools4ever. Het scenario is dat SAP elke x minuten een feed aanleverde in CSV formaat met alle wijzigingen, die vervolgens in Active Directory verwerkt moeten worden. Met behulp van specifieke codes voor bepaalde mutaties (instroom, doorstroom, uitstroom) weet de UMRA engine welke business logica uitgevoerd moet worden.

De uitdaging is echter dat zowel SAP en Active Directory de halve waarheid bevatten en beide niet 100% schoon zijn. SAP kent geen inlognamen en Active Directory kent niet alle personeelsnummers. Als je gaat koppelen is het belangrijk dat er een goede sleutel is tussen het bron-en doelsysteem, in dit geval beschikken we over een halve sleutel die geleidelijk opgeschoond wordt tijdens het traject.

Het gevolg is een koppeling waarbij de business logica binnen UMRA een vertaling maakt van SAP naar Active Directory. Het kan goed voorkomen dat SAP een persoon als instroom aanlevert terwijl hier in de Active Directory reeds een account voor bestaat. UMRA moet dit afvangen, controleren en een dergelijke aanlevering dus anders behandelen dan SAP aangeeft. We hebben gedurende het traject deze vertalingen proefondervindelijk aangebracht, het bleek nagenoeg onmogelijk om dit vooraf in kaart te brengen gezien de onbekende mate van vervuiling in beide systemen.

Het lijkt misschien dat er een te complexe oplossing gekozen is, echter vind ik deze aanpak achteraf gezien uitstekend. Tijdens het bouwen van de koppeling komt de vervuiling direct naar boven en kan deze ook aangepakt worden. Door een soort "agile" manier van ontwikkeling van de koppeling hebben we zeer snel kunnen reageren op elk verschil tussen SAP en AD.

De uiteindelijke doorlooptijd van dit traject met een scope van meer dan 13000 medewerkers is ongeveer 3 maanden geweest met een consultancy inspanning van rond de 15 dagen voor de volledige ontwikkeling van de koppeling.