• State Not Answered
  • Replies 6 replies
  • Subscribers 94 subscribers
  • Views 1388 views
  • Users 0 members are here
Options
Related

Powershell-connector

henrik a johansson
over 1 year ago

So I've created my first Powershell-connector and added some logging to a file so see what is happening when I browse, synk and provision users to the target system.

I have cmdlets for Get-Users, Get-User, and Update-User.

Get-Users returns an array of objects containing all the attributes that Iäm interested in inserting in UNSAccountB. Get-User only returns one object, but the same number of attributes.

When I try to get all users in Postman, it takes around 20-30 seconds. When I try to get all users with the cmdlet, it takes the same amount of time.

What I'm trying to understand is the logic behind the synchronisation. When I run the synchronisation to get all the users, I see in the log that it runs the cmdlet for Get-Users (takes about the same time as the other) and then it starts to run Get-User on each individual user. This means that a action of getting all users takes about 1,5 hrs.

Can anyone explain if this is how the logic SHOULD work, then I'm interested in trying to understand the resoning. If this is NOT how it's suppose to be, what am I doing wrong and how can I fix it.

/Henrik

Parents Reply Children
  • 0 over 1 year ago in reply to Markus Weiss-Ehlers

    Both Get-Users and Get-User returns 11 properties. I've now increased the threshold to 12.

    But is this the excpected behaviour, fetching all users and then fetching them one by one? Seems stupid to me..

  • 0 over 1 year ago in reply to henrik a johansson

    The Get-Users cmdlet should only retrieve the key, revision, and display properties. The Get-User retrieves all properties. In your case where the slim list retrieval returns all properties it makes sense to cache the list if memory availability allows. The Get-User cmdlet will index into the cached list taking away the network calls and bad performance. If you do not have enough memory to cache the list you should only retrieve the slim list and depend on the revision counter to reduce the synchronization duration when the revision counters are fully built. 

  • 0 over 1 year ago in reply to henrik a johansson

    As Rodney has hinted, the slim list, which gets all objects in a target system, could grow huge if you include all properties by default. That's why the sync engine (not the connector) separates the calls of a list of objects and the call to fetch a single object including all properties. Another reason is, that not all target systems allow you to bring all properties in list calls or these calls are very expensive.

    For your use case, where the list call is cheap,  you could either try my suggestion or, if that is not helping, implement the approach from Rodney.

  • 0 over 1 year ago in reply to rrosenda

    Any suggestion how to make Get-User index into the cached list?

  • 0 over 1 year ago in reply to henrik a johansson 

    function Get-Accounts() {
	if (-not $Global:Accounts) {
    		$Global:Accounts = Invoke-Restmethod https://app1/getusers
	}
	$Global:Accounts
}

function Get-Account($id) {
	if ($Global:Accounts) {
        $account = New-Object PSCustomObject -Property $global:Accounts[$id]
    else {
        $account = Invoke-Restmethod https://app1/getusers/$id
    }
    $account
}

 <ReadConfiguration>
                <ListingCommand Command="Get-Accounts"/>
                <CommandSequence>
                    <Item Command="Get-Account" Order="1"/>
                </CommandSequence>
</ReadConfiguration>