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

  • Hi, ditzhaki.

    Saved object properties are saved in the workflow data context. That context is destroyed the moment the workflow completes. If I'm understanding your question, it sounds like you're trying to use Saved object properties as persistent storage, which it was never meant to do (as I understand it: I do not speak on behalf of or with the authority of the development team). It should be treated as ephemeral storage that exists only for the lifetime of the workflow.

    Regarding the rest of your description, it's unclear to me if you're attempting to track:

    1. How many times any particular object is disabled, no matter by whom (e.g., Fred has already been disabled 10 times today by various people, therefore you may not disable him any further)
    2. How many times a particular individual disables any object, no matter the object (e.g., you have already disabled 10 different people today, therefore you may not disable any more)
    3. How many times a particular individual disables a specific object (e.g., you have personally already disabled Fred 10 times today, therefore you may not disable Fred any more - but you may disable someone else)

    For option #1, you would store the data on the affected object. Option #2, you would store it on the initiator. For #3, however, this is much more difficult, because now you're basically talking about having to query and/or track your own Change History.

  • 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.