{"id":3142,"date":"2012-10-16T21:56:49","date_gmt":"2012-10-16T19:56:49","guid":{"rendered":"http:\/\/contoso.se\/blog\/?p=3142"},"modified":"2012-10-16T21:56:49","modified_gmt":"2012-10-16T19:56:49","slug":"pass-information-between-runbook-activity","status":"publish","type":"post","link":"http:\/\/contoso.se\/blog\/?p=3142","title":{"rendered":"Pass information between runbook activity"},"content":{"rendered":"

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\u00c2\u00a0blogged\u00c2\u00a0a 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\u00c2\u00a0individual\u00c2\u00a0activities in the service request template. \u00c2\u00a0I 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.<\/p>\n

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”.<\/p>\n

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.<\/p>\n

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.<\/p>\n

\"\"<\/a><\/p>\n

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.<\/p>\n

\"\"<\/a><\/p>\n

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 \ud83d\ude42<\/p>\n