One of the features in Orchestrator is “Variables”. These are globally-available, statically-defined values (hence the running joke that they’re not actually “variables”, they’re “constants”). They provide a good way to define values that you re-use over and over throughout a number of activities and runbooks, such as server names, accounts, and passwords (which can now be set as encrypted in Orchestrator). You can also assign permissions to variables so that only certain users have access to them (to prevent users from accessing things they should have access to, like credentials). These variables, along with Counters (also global, but modifiable) are great, but I often see requests for how to use variables that are contained only within a runbook because the user wants them to be modifiable at runtime, but also thread-safe, where multiple instances of a running runbook won’t collide with the same variable.
This is actually pretty easy to do using the Run .NET Script activity. This activity is actually the only one of the Standard Activities that lets you define your own custom published data properties. You can define the name and value of any number of properties that get published to the databus, and therefore reusable by any following activity in the runbook. Likewise, you can modify the value at any point and re-publish it to the databus. Here is an example of how to do this:
I start by creating a runbook with a couple of Run .NET Script activities (renamed as shown for clarity) along with my usual “bookends”, the Initialize Data activity and the Return Data activity.
I use PowerShell to create one or more simple PowerShell variables, like this:
I then define the published data properties to be output from the activity when it runs:
In the “modify” activity, I simply set the variables again, but use the published data from the first activity to either append a string or increment a counter. The published data page is exactly the same as before.
Now when I run this in the Runbook Tester, I see that my values are added to Published Data by the first activity, and then re-used and modified, then re-published to the databus by the second activity.
I’m sure that I’ll get comments about the fact that it’s not quite the same as a global variable in that it’s not referenced just by the variable name and that you have to make sure you use the value published to the databus by the activity that changed it last (you can’t just link everything to the first activity and get any changed values). But, in a pinch, this is a good substitute for global variables when you just need to save some value to the databus that you can re-use like a variable or counter.
Nice one Robert, I have being using the process recently also, and it works very nicely.
The real challenge that isn't addressed though is sharing that variable value amongst different instances of the runbook that are running concurrently (ie global variables). Granted there are workarounds for this as well (SQL queries) but it really would be a nice thing to see built into the base product.
Thanks! this is great!!