Can't Access Saved Object Properties from Script / Counter Returns Empty

Hi,

We're trying to create a workflow that counts every time a user enables or disables another user every day (workflow trigger is the modifivation of edsaAccountIsDisabled). (the counter resets every day.) If the counter reaches 20, the action requires approval.

We tried to store the counter in a virtual attribute like so:

function addOne ($Request) {
$aidcounter = $workflow.savedobjectproperties("Save object properties").get("edsva-aidcounter")
$aidcounternew = $aidcounter+1
return $aidcounternew
}

We must use saved objct properties here because we are trying to access the original initiator's properties.

Now, this method simply didn't work. We weren't able to call the saved properties via script. We got the following error: 

Exception calling "SavedObjectProperties" with "1" argument(s): "The given key was not present in the dictionary."

As a workaround, we tried to first copy the edsva-aidCounter of the initiator into another VA called TEMP-int of the TARGET, and then we called it via script like so:

function addOneTemp ($Request) {

$user = $request.dn

$counter = get-qaduser -proxy -identity $user -includeallproperties | Select-Object -expandproperty TEMP-int

$counternew = $counter+1

return $counternew

}

 

When testing this script outside of the AR workflow, (replacing $request.DN with the DN of a test user), this worked perfectly.

However, for some reason, when this workflow is triggered, $counter always returns an empty value, and so $counternew is always 1.

Obviously, the ideal solution is for "saved object properties" to work correctly when called from the PS script (I have not yet seen a functioning example of this, in forums usually an alternative solution is suggested where they end up not using saved object properties at all in the final script), but if that doesn't work, we'd still like to understand why our workaround doesn't work. ($counter always returns empty)

We used a nearly identical script as a counter before for different attributes, worked fine. 

We'd appreciate any help!

Thanks

Parents
  • Hi  

    It doesn't answer your question/concern about Saved Object Properties, hower the $Request.DN attribute would be for the user you'd be making the changed to, I've added $Request.WhoAmI, which will retrieve the the samAccountName and DN of the initiator

    function addOne ($Request)
    {
        try
        {
            $aidcounter = $workflow.SavedObjectProperties("Save object properties").get('edsva-aidcounter')
            $eventlog.ReportEvent($Constants.EDS_EVENTLOG_INFORMATION_TYPE, "AIDCounter $aidcounter")
        }
        catch
        {
            $samAccountName = ""
            $DN = ""
            $Request.whoami([ref]$SamAccountName,[ref]$DN)    
            
            $aidcounter = (Get-QADUser -Identity $DN -Proxy -DontUseDefaultIncludedProperties -IncludedProperties 'edsva-aidcounter').'edsva-aidcounter'
        }
        
        #Check if the user has a value set for AidCounter or if null
        if([string]::IsNullOrEmpty($AidCounter)) {$aidcounter = 0}
        
        $aidcounternew = $aidcounter+1
        
        return $aidcounternew
    }

    My interpretation of your workflow is as below:

    Where onPre you've saving the users properties into the "Save object properties" workflow step (all the other properties are there two, just filtered to show the specific one we're interested in)

    Then checking if the Initiators edsva-AidCounter value is >= some number (5 in my lab, but 20 in yours), where if they've enabled or disabled 5 or 20 times in a day, it would require the approval of the initiators manager

    Then once the object is enabled/disabled, onPost I've updating the initiators edsva-AidCounter VA by one.

    However, although I've included the SavedObjectProperties step, in the way you wanted to do this, it is always entering the catch (not able to review the property in this context)

    If however, I call the above script via a Script workflow activity below the SavedObjectProperties, rather than via an Update activity step, which users the script, the try block completes successfully, so it might be that the information from the Saved Object Properties activity step is not available to the script, when it called in that context. (NB: The number is increasingbecause of my lookup via the catch block)

    However, let me discuss with a couple of people, and see what their thoughts are.

    Kind regards

    Stu

  • Hi Stu, 

    Many thanks for the detailed response! We will try this and update the post.

Reply Children
No Data