copy Active Directory Usersnames to local SMO

D

The oob Active Directory service is useful, however there's no way to retrieve data fast enough to use certain controls,

so I made a workflow that was supposed to grab all the AD users and write to a local smartobject a couple attributes, just username, display name, and email.

My thought process was, if it's a local smartobject with way less attributes/properties than the real AD and without having to query AD I could perhaps use autocomplete and some of the other neat controls that help in making users enter less data manually.

However when I ran it, it was extremely slow, writing one user every minute or so, it's gonna take a while to write 10k+ users that way. Does anyone have a better method or something similar they have done?

3 replies

Z
Badge +9

Why not use the UMUser smartobject to retrieve those user data (i.e. username, display name, email) instead? it already acts as a cache of sorts.

D

Oh I didn't know UMUser acted as a cache, but I tried it in a form and it still does not seem speedy enough. It seems like any method which reaches out is not as fast as SQL (or local smartobject in K2 terms). UMUser still takes a good 15 seconds to show any options with autocomplete.

B
Badge +15

UMUser is kind of special in a sense that it has certain methods that will query your identity cache, while the other methods will sort of query your AD as well.


 


Whenever your users log into K2, K2 will cache those user's information into its own identity cache. The identity cache is located in Identity.Identity table in your K2 database.


 


Each identity cache has an expiry date, so once it has expire, K2 will refresh the cache (by querying the AD again) the next time the user logs in, or something triggers the refresh.


 


UMUser's Get User Details method will query your identity cache. If the identity record has not expired, it will just retrieve the user's information from the identity table. If the identity record has expired, this will trigger a sync with AD, then update the identity record, then the results will be displayed.


 


However, UMUser's Get Users method should directly query your AD to retrieve the user list. Performance wise I think it should be the same as calling the ADUser SmartObject. With the AutoComplete control, you will need to configure a SmartObject with get list method into it. Regardless of using the UMUser or ADUser SmartObject, your performance will definitely be slow as K2 will first need to query your AD to retrieve the entire list, then compare it with whatever that was typed into your AutoComplete control.


 


The only way I can think of that can improve the performance for AutoComplete is to further stop your SmartObject from querying your AD for the entire user list. Find a way to filter it down so that only a subset of the users will be retrieved.


 


Your idea may also work, that is to create another database table that can cache all the user's information, then create a SmartObjec that just query that table alone. The easiest way to do this is to write a SQL script to copy the values you want from the Identity.Identity table, then insert it into your own database table. The downside to this is that you will have to schedule this copy operation regularly. If not, any new users added to your AD will not appear in the list. I have never tried this before, so I will recommend you try this on a non-production environment first.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings