• State Not Answered
  • Replies 7 replies
  • Subscribers 62 subscribers
  • Views 2194 views
  • Users 0 members are here
Options
Related

How to limit virtual attributes retrieval?

sebastien.grossetti-gfk.com
over 2 years ago

Hi Community,

I recently added a lot of virtual attributes to my user class, and got them populated 'on the fly' (no DB storage of their values) by an "OnPostGet" trigger in a script module.

As the retrieval of each value takes a little time, it runs for approx. 1 second to retrieve them all.

Unfortunately, when 1 more second to get user's "properties" window to pop-up remains acceptable, the tool becomes absolutely unusable when I try to display the content of an OU with several users, in there. The OU can take minutes to just display its content !! And same goes for a generic "Get-QADUser" command...

It appears that the script populates values for every user even if they just get listed :-(

So now my concern is about how I can control when these specific attributes get populated or not...

I would need to find a way to makes these not populated unless these are really expected, like when displaying the "Advanced Properties" tab, or if these are explicitly listed in the "-IncludedProperties" parameter of a Get-QADUser cmdlet.

Any idea would highly help!

Thanks to all in advance :)

Parents
  • 0 over 2 years ago

    You can use grab client information and only load the Virtual Attributes when needed, or use a custom Control, as per this resource:

    Title: HOW TO: Determine which Active Roles client is performing a modification using a custom script module
    Solution: 284750
    URL: https://support.oneidentity.com/kb/284750 

  • 0 over 2 years ago in reply to Terrance.Crombie

    Thanks, this is a very interesting post.

    That's nevertheless not enough for what I am trying to achieve, though, as I need to display these in all 3 clients (MMC, WI and PS).
    The criteria I'm looking for would rather be something like "only when needed"...

    Isn't there a way to detect if a given attribute will actually be displayed (or was explicitly requested)?

  • 0 over 2 years ago in reply to sebastien.grossetti-gfk.com

    You can define your own Control associated with a web ui properties page or Wizard - I did this for one customer.  We decided to call the control "WebUIFormID". 

    Your OnPostGet handler can check $Request.GetInControl("WebUIFormID" to see if the UI needs to do the manipulation of the attributes based on whether this Control is present and/or based on its value.

    <*>  <*>  <*>

    Another thought:

    I know that this is different than your current architecture / approach,

    Create a Sync Service job that would update stored versions of your "friendly" virtual attributes with information from your M365 tenant.  I see it working something like this:

    Sync service job (runs daily(?) - or however often you want):

    UserAttribute1 (from Cloud) ---> VATempUserAttribute1 (not stored)

    Workflow detects change to VATempUserAttribute1, processes its contents and stores the "friendly" version in VAFriendlyAttribute1 (stored attribute)

    That way you always have VAFriendlyAttribute1 on hand for the UI to read quickly.

Reply
  • 0 over 2 years ago in reply to sebastien.grossetti-gfk.com

    You can define your own Control associated with a web ui properties page or Wizard - I did this for one customer.  We decided to call the control "WebUIFormID". 

    Your OnPostGet handler can check $Request.GetInControl("WebUIFormID" to see if the UI needs to do the manipulation of the attributes based on whether this Control is present and/or based on its value.

    <*>  <*>  <*>

    Another thought:

    I know that this is different than your current architecture / approach,

    Create a Sync Service job that would update stored versions of your "friendly" virtual attributes with information from your M365 tenant.  I see it working something like this:

    Sync service job (runs daily(?) - or however often you want):

    UserAttribute1 (from Cloud) ---> VATempUserAttribute1 (not stored)

    Workflow detects change to VATempUserAttribute1, processes its contents and stores the "friendly" version in VAFriendlyAttribute1 (stored attribute)

    That way you always have VAFriendlyAttribute1 on hand for the UI to read quickly.

Children
No Data