Performance tuning bij koppelingen

Bij veel klanten leveren we actieve koppelingen tussen HR-bron systemen en bijvoorbeeld een Active Directory. Een dergelijke koppeling bevat in de praktijk altijd een drietal scenario’s:

• Medewerker nieuw in dienst: aanmaken
• Medewerker verandert van functie/afdeling: update met mogelijke wijzigingen in groepen
• Medewerker gaat uit dienst: inactief maken, mogelijk na een aantal dagen/maanden definitief verwijderen

Bij een aantal van de bovenstaande scenario’s is het denkbaar dat extra informatie nodig is uit het HR-systeem, en dat deze informatie meervoudig per werknemer is. Denk bijvoorbeeld aan locaties, afdelingen, functies en kostenplaatsen. Een medewerker kan best aan meerdere van deze elementen gekoppeld zijn. De basisopzet van een koppeling is echter om met genormaliseerde gegevens te werken, dus 1 record met 1 waarde per werknemer.

Zodra in een koppeling gebruik wordt gemaakt van een groepssynchronisatie op basis van meerdere elementen per werknemer zie je vaak dat het HR-systeem nogmaals wordt geraadpleegd, wat resulteert in een extra query voor elke werknemer. Deze extra query’s zorgen niet alleen voor vertraging van de koppeling, maar ook voor extra netwerkbelasting en belasting van het HR-systeem.

De oplossing: werken met sessie variabelen.
In UMRA is er sinds versie 10 de mogelijkheid om variabelen in een sessie op te slaan. Een groot voordeel hiervan is dat je eenvoudig aan het begin van een koppeling een grote repository kunt opbouwen van alle gegevens die nodig zijn, en deze later kunt raadplegen uit memory in plaats van een extra query nodig te hebben.

Voorbeeld:
Stel je werkt met een HR-systeem met 5500 medewerkers. Elke medewerker heeft 1 of meer functies bij 1 of meer afdelingen. De koppeling loopt over een bron met 5500 records met genormaliseerde gegevens, dus 1 functie en 1 afdeling. Voordat de iteratie over de 5500 recors begint, wordt er eerst een grote gegevensset uit het HR systeem geladen met alle personeelsnummers, functies en afdelingen. Deze gegevensset wordt in de sessie opgeslagen.

Per iteratie voor de 5500 records kun je nu de gegevensset uit de sessie raadplegen, zoeken in de tabel in memory naar het personeelsnummer en zo alle functies en afdelingen ophalen per werknemer. Aangezien dit allemaal in memory plaatsvindt is de performance uitstekend en zijn subquery’s naar externe systemen niet nodig.

• active directory
• umra
• hr
• performance tuning