Looping in Orchestrator with Service Manager 2012 Service Requests

Author by Nathan Lasnoski

Orchestrator allows us to do some pretty awesome things in the pipeline.  Let's say that you wanted to deploy several applications and Service Manager had associated those applications to the Service Request.  Orchestrator is smart enough to look at the Service Request object, know that you've associated multiple software items to the request, and run the following SCCM integration multiple times.  I'd say that is pretty beautiful.   Let's say however that you wanted to have the process run several times through an automation based on an integer value stored in the Service Request.  For instance, let's say you wanted to create a process that submits an internal order to your purchasing system using a self service request.  In the order, you wanted to have the process run several times based on a value you indicated, such as wanting to order several copies of a particular piece of software, several keyboards, or several workstations.  In this example we'd need to do some trickery in Orchestrator to make it possible easily.   In my case I started off with a runbook split into two parts.   In the first section I started with the standard Service Manager integration group.  I retrieve the runbook ID, retrieve the Service Request, and my Service Request Extensions.     I then set an initial counter to a value equal to the integer quantity I've set in extInteger01, which is a value I stored from my Service Request that equals a quantity I'm planning on ordering.  In this case I'm using a counter, which is a global variable.  A better practice would be to use something a bit more flexible, such as a database, or to have an individual counter for the runbook, but we can start with this.   At this point my runbook is only setting a variable and will only run through the process once.  I however want it to run more than once, so I'm going to right click on the linked runbook and select "looping".  I then launch a following runbook, which is set to loop a quantity of times.   I set the loop to a quantity which is greater than the maximum number of times I need it to run.  Alternatively I could have it loop and end when I pass a value back from the sub-runbook.  This would be a great way to avoid the inefficiency or looping too many times.   Inside the next runbook we have an initial step which decrements the order count to indicate where we are in the process.  This will take the global counter and reduce it on every execution of the runbook.  Note that we set that counter to the value of the orders, so we're decrementing in order to ensure we only order the correct amount.   The next step is to filter what continues in the process based on the order count.  At this point, we've only cycled through the process at a quantity equal to the number of orders we are performing.   The final step is to configure the entire runbook to execute once concurrently.  This is because we used a counter, which is global.  If we used a more flexible technique we could potentially have concurrent orders.   I hope this helps everyone out.  If you have any thoughts on how to make this better, let me know… ;)   Nathan Lasnoski

Author

Nathan Lasnoski

Chief Technology Officer