• State Not Answered
  • Replies 11 replies
  • Subscribers 65 subscribers
  • Views 2532 views
  • Users 0 members are here
Options
Related

Workflows with if-then, PowerShell scripts, and $work.SavedObjectProperies

todd harrison
over 1 year ago

Hi,

I am working on a workflow to do some automation on our computer objects, and I am running into a weird issue that I am struggling to wrap my head around.

The error I am receive:

Executing the 'Run script: DEV New Computer Object Tag Location on Search Results' activity  
 
7/11/2023 12:33:21 PM (UTC) 

•Activity 'Run script: DEV New Computer Object Tag Location on Search Results' encountered an error.  Details <<< 
An item with the same key has already been added.

ARS Version: 7.4.3

The workflow is setup in the following way

  • The workflow will run on a schedule
  • There is a managed unit that the workflow uses to search for objects
  • The properties of the found objects are saved.
    • Currently I am saving the DistinguishedName
  • There is then an If-then statement that evaluates the DistinguishedName and will update a virtual attribute based on what is found. There are 5+ conditions being evaluated.

NOTE - Up until this point, everything works as expected

  • I then have a PowerShell script that will connect to a 3rd party service
    • Important - This is WITHIN the If-then statement and takes place immediately after the virtual attribute is updated 
    • This has not yet been tested because I am struggling with another piece. I am just included this for reference.
  • I then have a PowerShell script that will essentially check if the previous steps were successful, and if not, the script will update some virtual attributes to allow us to be alerted and cause the machine to be re-evaluated the next time the workflow runs.
    • Important - This is NOT WITHIN the if-then statement. It is set to run AFTER. 
    • This is where I receive the error above.

In the PowerShell script that triggers the error above I have managed to narrow down the exact line that is causing it.

$computers = $workflow.SavedObjectProperties("Save object properties").get("distinguishedName")

My intent with this line of code is to loop through all the objects that were originally found, and then check their attributes to see if the previous steps were successful.

What seems to be happening though is that the "$workflow.SavedObjectProperties("Save object properies")" is being changed by the If-then statement.

After the if-then statement is run, it seems only 1 computer object is returned by the above command. Even though there are two objects.

If I re-order things, and I run the PowerShell script that triggers the error BEFORE the workflow if-then statement, the PowerShell script will work and process each object found.

But this is out of order and not what I want.

Is there some way of having the PowerShell script use the object that is running through the If-then statement?

Or am I doing something else wrong? I can't figure out why the if-then statement appears to be impacting the "$computers = $workflow.SavedOjectProperies.." in the PowerShell script.

I have a few other examples where this is actually working.

It is important to note that if only 1 computer object is returned by the search operation of the workflow, then everything things to run as expected.

Not sure if any of what I just described made any sense, I hope so.

I am sure I am doing something stupid, any suggestions would be greatly appreciated.

Regards,

Todd

  • 0 over 1 year ago in reply to todd harrison
    todd harrison said:
    The revelation that that the workflow runs any defined steps against returned search objects is huge.

    This is the nature of Automation Workflows - the workflow itself has to fetch the objects to work on from somewhere.  A Search is one way to do this.  I always think of a Search and the contents of its workspace as (in programming terms) a loop - i.e. do whatever is in my workspace to each object I find.  You don't have to use a Search but then you need another way to identify which objects to process.

    In contrast, Change Workflows react to a transaction being processed by the Admin Service (a.k.a. a $Request object) that is changing (or creating) a specific object.  In this case, the in-process object is known so your workflow and / or its activities can refer to it by its distinguishedname ($Request.DN), Object GUID ($Request.guid - very handy in some cases) or even its name ($Request.Name) - though I tend to use the first two most often.