Orchestrator keeps a log of activities for previous Runbook executions.
The log history view in the Runbook Designer is one of the most heavily used functions in my Orchestrator environment. It's very useful in determining what is happening when an activity fails. I have been looking for a quick and easy way to export this data when troubleshooting remote environments that I don't have access to.
It is possible to get this deep information from Orchestrator via COM as the Product Group explains here.
However, I opted to take a SQL approach and here's the script:
SELECT POL.Name as PolicyName, obj.Name as ActivityName, OI.ObjectStatus, OID.[Key] as PublishedData, OID.Value as PublishDataValue, OI.StartTime, OI.EndTime
FROM OBJECTINSTANCEDATA OID, dbo.OBJECTINSTANCES OI
innerjoinOBJECTS OBJ on OI.ObjectID=obj.UniqueID
innerjoin POLICIES POL on OBJ.ParentID = POL.UniqueID
WHERE (OI.UniqueID = OID.ObjectInstanceID)
--AND POL.Name = 'RunbookName'
--AND OID.[Key] = 'ErrorSummary.Text'
orderby EndTime desc
The script will return Log History including Policy Name, Activity Name, Activity Status, PublishedData (which is the type of data returned), PublishDataValue (e.g. the error, or the PID) and a start and end time.
From the output I can see my activity to CreateLogView failed with a message that the object already exists. I can also see the PID number which can be useful in other scenarios.
The output is consistent with the log history view in the designer:
The ErrorSummaryText from Published Data is the usually the best indication of where a problem exists.
If I want to see only the ErrorSummaryText for a given Runbook, I can remove the comments in the script above to scope the query for me.
There we have it. An easily exportable log history of a given Runbook, scoped to error text only! Once we have this, we could wrap this into an error handling runbook, to export this history out after a failed execution. Or use the data to parse start and end times to look for performance improvements to our activities and Runbooks.
Thanks to my colleague Anders Bengtsson for sharing his knowledge of the database. Anders has also blogged about how log history is cleaned up, you can find it here.