Performance tuning bij koppelingen

Performance tuning bij koppelingen

Door: Arnout van der Vorst

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.

Arnout van der Vorst

Geschreven door:
Arnout van der Vorst

Maak kennis met Arnout van der Vorst, de inspirerende Identity Management Architect bij Tools4ever sinds het jaar 2000. Na zijn studie Hogere Informatica aan de Hogeschool van Utrecht is hij begonnen als Supportmedewerker bij Tools4ever. Daarna heeft Arnout zich opgewerkt tot een sleutelfiguur in het bedrijf.  Zijn bijdragen strekken zich uit van klantondersteuning tot strategische pre-sales activiteiten, en hij deelt zijn kennis via webinars en artikelen.

Anderen bekeken ook

SAP koppeling met Active Directory

SAP koppeling met Active Directory

06 september 2012

User- en toegangsbeheer in cloud applicaties: een uitdaging

User- en toegangsbeheer in cloud applicaties: een uitdaging

04 september 2012

De vooroordelen van Single Sign On

De vooroordelen van Single Sign On

29 november 2011

RBAC: sleutelrol, beheer en evolutie

RBAC: sleutelrol, beheer en evolutie

15 maart 2011

Single Sign On met terminal emulatie (VAX64, AS/400, Linux, SSH)

Single Sign On met terminal emulatie (VAX64, AS/400, Linux, SSH)

14 oktober 2010