System Center Orchestrator 2012 – Error Handling and Using Data in the Data Bus BETWEEN Runbooks

I will re-iterate a statement I’ve made before.  I don’t believe in re-inventing the wheel.  Before I found “Designing Orchestrator Runbooks“, I found that doing error handling using the brief bit of info I learned from the class and the other books I purchased was, frankly, a big pain.  I dropped everything I was testing with to go with the examples starting on page 36 of the book.

It takes quite a bit of thinking and experimentation with Orchestrator before you really get into how to use the tool and leverage it well.  The error handling examples are no different and they give you quite a bit of flexibility and value with your runbooks.  The examples also help clearly illustrate how to pass data between runbooks using the data bus.

I invite you to download a free copy of Designing Orchestrator Runbooks, turn to page 36 and start experimenting!

To expand on their information and also illustrate how the data bus is used, let me give you an example.  Recall that in my last blog post, from earlier this morning, I was invoking a runbook to run a report and email it.  This was done through an initiation runbook which generated a random server from a PowerShell script and used that generated server name with the invoke runbook activity.  I will show you that runbook and then an error handling runbook.

NOTE:  It is important to sit down, read through the information in Designing Orchestrator Runbooks, decide what works for you in your environment and then PLAN IT OUT and DOCUMENT it.  If you are going DNRY (Do Not Repeat Yourself) you are establishing some standards here that will be used consistently and repeatedly in all your runbook error handling.  Make sure you have everything the way you want it.  You must create your error handling runbook FIRST.  It should be present before you add an invoke runbook activity.  You have to have a road built before you can drive on it…

Runbook 1 – Error Handling

ss11

When you create your error handling runbook, you are setting the foundation for any and all data you think you would like to see in order to record errors and help indicate what problems might exist to assist in troubleshooting.

Create your variables and set their types:

ss14

Now, what do you want to do with it?  I’m emailing my data to a distribution list and writing them to the event log (event log example shown below):

ss15

That’s pretty much it for the error handling.  Now let’s get on with how to use it.

Runbook 2 – generate report and email it.  In our second runbook, we don’t care much about anything except our links and the invoke runbook activities

ss10

I have two links.  One links to an email activity, that link is utilized if my script runs ok.  If there’s an error with the script, then that link is followed.  Below is the properties of the “error” link

ss12

Notice I have two invoke runbook activites.  Both invoke runbook activities have a link with the same filters (as shown in the previous screen shot).

Both of these invoke runbook activities link to the same “Error Handling” runbook.

Now, here is where things get a bit interesting.  In your invoke runbook activity, I want to create multiple parameters.

ss16

A bit of explanation here.  I am adding parameters with names that MATCH the initialize data strings I set up in my error handling runbook.  The VALUES for these parameters are as follows:

RunbookName – subscribe to data, the runbook name from the previous activity, “Run PowerShell Script”.  What I want here is, if the script error-ed, what is the name of the runbook where this error was generated from?

ErrorMesage – subscribe to data, the error summary text from the previous activity, “Run PowerShell Script”.   What I want here is, if the script error-ed, what was the text of the error, the error message?  (if you read on in the book, they explain further how to include PowerShell error handling to the data bus as well.  So, if there’s an error WITHIN the script, you can subscribe to that too if you desire.  This only subscribes to an error message generated by the ACTIVITY, not an error in the script).

EmailAddress – subscribe to data, the global variable for my distribution list or email address of where the error should g0

Trace – I’m error handling within my script, that data is written to a temp file, so that information is being passed back via the variable “ErrorFile”.  This will become an attachment in my email or passed to the event log

Runbook – subscribe to data, the runbook name from the previous activity, “Run PowerShell Script”.  What I want here is, if the script error-ed, what server did it error out on?

ActivityName – subscribe to data, the name of the activity from the , “Run PowerShell Script”.  What I want here is, if the script error-ed, which activity did the error originate?

ActivityStatus – subscribe to data, the status of the activity from the , “Run PowerShell Script”.  What I want here is the status of the activity (failed, warning, etc).

 

Now, rinse and repeat for subsequent activities.  So, example, if my “Send Email” activity succeeds, well, that’s it.  It succeeds do nothing more.  If my “Send Email” activity fails, then invoke the “Error Handling” runbook and pass all that data to that runbook so it can use it to send an email about what my activity failed and also write to the event log on the server.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: