Home » Orchestrator » Pass information between runbook activity

Pass information between runbook activity

In Service Manager 2012 we can use runbooks from Orchestrator as activity in for example a service request template. This brings a lot of cool possibilities for automation in your data center. I have blogged a number of examples around this that you can find here on the blog. But in most of the examples I use only one runbook activity, and if I need to use multiple runbooks they are all started from one “master” runbook, not as individual activities in the service request template.  I came across a scenario where we needed to use multiple runbook activities in the same service request template and we needed to pass information between the runbook activities. One benefit with splitting multiple runbooks into multiple runbook activities is that it is easier to track the result in Service Manager, when each step in a complex workflow is its own runbook activity. This also gives the benefit that a Service Manager operator can re-start/re-run a step if needed.

In this blog I will show how you can use two runbook activities in a service request and pass information from runbook activity one to runbook activity two. We will also see how the result from both runbook activities can be published in the service request and self-service portal. In my demo example the first runbook generates an “account name” and the second runbook generates a “phone number”.

Each instance of a runbook activity have a number of “generic/blank” fields that we will use to store the result, they are for example named TEXT1 to TEXT10. Why not store the result in the Service Request? Even if the service request have some fields I could use I don’t want to do that as it would be difficult to remember what result I store in which property. An alternative would be to extend the service request class, but that would result that all kind of service requests would get those new properties, as they use the same service request class.

The first runbook, in this example named 12.1, has one input parameter which is the runbook activity ID. The runbook then generates an account (random 4 characters) and returns account name back to Service Manager.

In Service Manager I have configured that OUT from this runbook should be written to the TEXT1 field of the runbook activity instance. This is done in the service request template, on the runbook activity.

The second runbook, in this example named 12.2, have one input parameter which is the runbook activity ID. The runbook then generates a phone number (random numbers). Then it gets a bit more complicated 🙂

  • Get Related Service Request. This activity use the input parameter, the runbook activity instance ID, to get the related Service Request.
  • Get Service Request. This activity gets the Service Request that the previous activity found
  • Get Related Runbook Activities. This activity finds all related runbook activities to the service request. We need to do this as we need to find the first runbook activity and read the TEXT1 field.
  • Get Runbook Activities. The “Get Related Runbook Activities” will return all related runbook activities, in this example there are two runbook activities in the service request. The link after the “Get Runbook Activities” activity is configured with a filter to only continue with the runbook activity that that a specific title. This title is the title you configure in the service request template.
  • Update Imp Result. This activity update the service request with both a implementation result and an new description. Implementation result and description are both visible in the Service Manager console. The description field is also visible in the self-service portal.

 

 


4 Comments

  1. Hi, but is it not difficult to use the GUID as it will be different each time, if you use the runbook automation activity instance GUID it will change for each run. The title will not.

  2. Hi Anders,

    I have a quick question regarding this post. As some of our service requests contain multiples RB activities (mainly for adding data to the SR description, adding a reviewer to a RA, etc…),

    I would like to know if it’s possible to return the value of the Runbook SCObjectGuid, then use it in as a filter in a Get-Object Activity, rather than using a filter on the title?

    Thanks,
    Simon

    p.s. thanks for sharing all this information, your blog is so useful

  3. I dont think you can do a direct mapping, instead you need to read the “out” info of the previous activity in you runbook. Each runbook is them total independed of each other, and stores all output to Service Manager workitem. Next runbook then reads the data.

  4. I thought this might be what I needed, but I don’t know. First, I would need to know how to make an (Out) String for a mapped parameter. I can see no way to go with them but (In).

    I have a runbook that creates a new user account based on information submitted through the Self Service Portal. This runbook is part of a Service Request that has numerous activities one of which is to assign a phone number.I have firgured out a way to get all the needed information out of the other Manual and runbook activities, but I need a way to get the newly created user name out of the runbook that creates the account, so I can update the phone number into the AD account and send a welcome email. If I could just get the first name and last name out of the Text1 and Longtext3 attributes, that would be enough for me. Many thanks.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.