chat-altchatcrossloginquestion-circlesearchsmileystarthumbup-downwarning
Vlaanderen
Contacteer ons
    Terug naar overzicht Stuur een e-mail

    Stuur een e-mail naar 1700, de informatiedienst voor al uw vragen aan de overheid.
    U ontvangt een kopie van uw bericht.

    Terug naar overzicht Chat met ons
    Uw chatgesprek wordt automatisch gestart zodra er een medewerker beschikbaar is.
    Even geduld, uw positie in de wachtrij wordt bepaald.

    Gebruikersbeheer Vlaamse overheid – oplossingen bij mogelijk trage verwerking bij aanpassingen

    donderdag, 1 februari 2018

    De migratie naar het nieuwe Gebruikersbeheer van de Vlaamse overheid heeft veel voordelen. Het Gebruikersbeheer zou bijna real-time moeten werken, hoogstens met een vertraging van maximaal enkele minuten.
    Af en toe ervaren lokale beheerders echter dat aanpassingen in Gebruikersbeheer slechts traag tot zeer traag doorstromen naar andere toepassingen.

    De voornaamste redenen daarvoor zijn:

    1. De doeltoepassing verwerkt aanpassingen niet in realtime (denk aan het HB-plus portaal, Facilipunt, …). Verwerking in real-time is niet altijd mogelijk of wenselijk.
    2. Het verwerken van de aanpassing is mislukt waardoor er in Gebruikersbeheer melding wordt gemaakt van een provisioneringsprobleem.
    3. Bij een grote massa aanpassingen kan de component in het Gebruikersbeheer (OpenIDM), die instaat voor het verwerken en doorsturen naar andere toepassingen, de hoge belasting niet aan. 

    Oplossingen

    Voor elk van bovenstaande situaties, is er een oplossing mogelijk.

    Doeltoepassing verwerkt aanpassingen niet in realtime

    Het ACM/IDM-team van Het Facilitair Bedrijf probeert samen met de toepassingen naar een oplossing te werken die doorstroom in real-time wel mogelijk maakt. Voor Facilipunt staat de oplossing bijvoorbeeld bijna op punt. Ook voor de andere toepassingen worden de koppen bij elkaar gestoken.

    Het verwerken van de aanpassing is mislukt

    De individuele gebruiker moet een keertje opnieuw “geprovisioneerd” worden. Dat betekent dat alle informatie voor die gebruiker een keer opnieuw wordt weggeschreven naar alle andere toepassingen. Als er sprake is van een provisioneringsprobleem voor een specifieke gebruiker dan geeft Gebruikersbeheer daar een melding van. Er staat dan ook bij vermeld wat de lokale beheerder moet doen.  

    OpenIDM kan de hoge belasting niet aan

    Een oplossing voor de derde reden vergt wat meer inspanning. Hier speelt de populariteit van Gebruikersbeheer niet volledig in het voordeel. Op korte tijd is het aantal toepassingen dat gekoppeld is op Gebruikersbeheer sterk gegroeid. Daarnaast worden een aantal van deze toepassingen door heel veel mensen gebruikt. Om die reden is er veel meer informatie uitwisseling tussen Gebruikersbeheer en andere toepassingen dan in het verleden.

    Uitdagingen voor de “OpenIDM” component

    • Wijzigingen vanuit Gebruikersbeheer komen in een wachtrij samen met alle andere wijzigingen die via bulkacties worden doorgegeven. Wanneer heel veel wijzigingen samen komen, kan de wachttijd voor wijzigingen die werden gedaan via het online Gebruikersbeheer zeer lang oplopen. Bij de opstart van grote toepassingen is het geen uitzondering dat we tot 200.000 wijzigingen te verwerken hebben, om maar een voorbeeld te geven.  
    • Het geheugengebruik van de OpenIDM component loopt onder zware belasting problematisch toe door de combinatie van het verwerken van de grote aantallen gebruikers naar het grote aantal verschillende doelsystemen. Het ACM/IDM-team moet daardoor bij een zware belasting geregeld de OpenIDM component herstarten. Wat tot extra vertraging leidt.  
    • Een zware belasting van het Gebruikersbeheer is de laatste tijd geen uitzondering. De laatste maanden werden verschillende keren zeer grote aantallen gebruikers opgeladen in het kader van nieuwe toepassingen die we koppelen op het Gebruikers- en Toegangsbeheer. Tegelijk was dit eveneens noodzakelijk in het kader van nieuwe entiteiten die instappen in centrale diensten die gebruik maken van het Gebruikers- en Toegangsbeheer, zoals Vlimpers of Facilipunt. Ook het in beheer nemen van de e-mailadressen in Gebruikersbeheer heeft een zware belasting van de OpenIDM component veroorzaakt.

    Een oplossing ten gronde is niet onmiddellijk realiseerbaar. Vandaag probeert het ACM/IDM-team de hinder te beperken door grote overdrachten op te splitsen in kleine bestanden zodat de OpenIDM component zijn wachtrij kan verwerken en kan “inhalen”. Op die manier probeert Het Facilitair Bedrijf de wachttijd voor wijzigingen vanuit het online Gebruikersbeheer te beperken tot maximum twee uur. Op korte termijn wilt ze de wachtrij in de OpenIDM component significant verkorten door verder finetunen van deze component. Acties die dit moeten realiseren, krijgen in de eerstvolgende release dan ook maximale voorrang op alle andere ontwikkelingen aan Gebruikersbeheer. Op middellange termijn zal Het Facilitair Bedrijf meerdere instanties van de OpenIDM component naast elkaar laten draaien om de belasting op die manier te kunnen verdelen.