This small runbook is a demonstration on how to use counters and variables and some basic smart link conditions. It also emphasizes one important difference between Opalis and SC Orchestrator (spoiler: cycles are not allowed! More about this on this cool post: http://www.sc-orchestrator.eu/index.php/scoblog/49-cycles-in-pipleline-mode)

The scenario for this runbook: You want to create a VM but you want the name to be auto-generated following some basic naming convention and you want to make sure that is unique. You also might have users manually creating VMs using the same naming conventions so you need to check this carefully. The runbook will look like this:

 

Global Settings

First we need to define a counter and a variable. You can find both the “Counters” and “Variables” under the “Global Settings”.

I’m defining a counter called “VMName” which starts from the value “300” and a variable “VMNameSeed” with the value “DevVM“. The idea is to keep any hard values here, and when you want to modify the runbook, instead of going through each activity that is using these values, you can just modify them here, once.

Initialize Data

Now let’s create a new Runbook, named (in my case) “UniqueVMName”. We start by dragging the “Initialize Data” activity. You can find it under the “Runbook control”. Let’s define a parameter called “VMNameSeed”, type string.

Get Counter Value

Next, drag the “Get Counter” activity, found under the “Utilities” section. Choose the counter “VMName” defined at the beginning of this post.

VM Name is unique

Now, drag the “Get VM” activity. You need the “SCVMM Integration Pack” for this one. I renamed the activity to “VM Name is unique“.

Using “Published data”, configure the filter like this:

VMName equals {VMNameSeed form "Initialize Data"}{Counter value from "Get Counter Value"}

Red Branch

Time for some smart links. First we want to make sure that, if the resulting VM Name already exists, we increment the counter by 1 (going on the red branch from out runbook above).  So, in order to do this, double click the link between “VM Name is unique” and “Modify Counter”, and configure this condition:

As you might have guessed, we needed to drag the “Modify Counter” activity, connect the same counter, and configure it, in order to increment the current value by 1.

Green Branch

In case that there is no VM with that name, we will return the unique VM Name. We could also put a “Modify Counter” here (I didn’t), so next time when you run this runbook, it will be already incremented, and should be unique.

For the Return activity we just use again the published data: {VMNameSeed form “Initialize Data”}{Counter value from “Get Counter Value”} combo.

So, what if the name really exists, and we were going on the red branch? We incremented it by 1, but we don’t know if the next generated value is unique, and it does not return the existing value from our runbook. You might think that if you connect the “Modify Counter” back to the “VM Name is unique” activity, you can create a loop that will be executed until it generates a unique VM Name. In case you missed the link from above, this is one of the main differences between Opalis and Orchestrator. You could have done that in Opalis, but Orchestrator only allows the pipeline mode, so if you try that, you will get an error message saying that it “detects a cycle in your runbook”.

Invoking our runbook

To get the same result, we need to create another runbook that invokes this one, and to define a looping condition on the “Invoke Runbook” activity.

Let’s focus only on the first activity. We will deal with the rest of them in future posts.

I renamed the “Inkove Runbook” to Get Unique VM Name. Since our runbook does not return any value, unless the VMName is unique, we define our looping condition to exit when the UniqueVMName receives a value, or another way to put it:  invoke this runbook until it actually returns something, and since it returns something only when the VM Name is unique… we just got what we wanted.

Notice how the parameter for the “Invoke Runbook” (renamed to “Get Unique VM Name”) is our variable VMNameSeed.

The result after running this runbook should be “DevVM300”. I will cover creating the VM using this auto-generated unique name in a future post.

> V.