To enhance datacenter automation options, Orchestrator 2012 exposes a REST OData web service. The web service enables programmatic access to Orchestrator runtime resources like Runbooks, Jobs, and Events, and also enables a user to start Runbooks and stop Jobs.
One goal of the web service it to enable easy automation of the Orchestrator runtime from any application. To this end, the Orchestration console that is part of Orchestrator 2012 uses the web service to connect with Orchestrator.
OData is a web protocol designed for clients to query and update data on data services. OData is REST-based, that is it uses standard HTTP syntax and methods (e.g., GET, POST) to enable CRUD operations on data. Data queries are defined with standard URL syntax, and response data is transferred in standard AtomPub or JSON formats.
An OData service represents data as resources and relationships between resources. For Orchestrator, the resources exposed are those listed in Figure 1 below. For a given resource the relationships to other resources are also exposed; this means that a resource like a Runbook will have metadata (URLs) that represent the relationships to other resources like Jobs and Activities (see Figure 3 for examples).
The base URL to the Orchestrator web service is this:
In response to this HTTP GET request the web service will return by default AtomPub-format XML that contains the references to all of the Orchestrator resources exposed by the service (Figure 1).
Figure 1: The Orchestrator resource collections (AtomPub format) |
|
NOTE : With Internet Explorer, to view the web service response as XML rather than as a feed do the following:
One of the key uses of the Orchestrator web service is for automation via PowerShell scripts. Connecting with the web service is straightforward. Here is bare-bones script (Figure 2) that connects with the web service and retrieves the list of collections seen above (Figure 1):
Figure 2. PowerShell script for connecting with the Orchestrator web service and getting response xml |
|
To get the records for a specific resource the URL has this form:
where, COLLECTION-HREF can be found in the Collections xml (Figure 1) like this:
Thus, to retrieve the runbook resources use this URL:
Figure 3: Runbook resources returned by the web service (AtomPub format) |
|
Each <entry> node contains the information for one resource. Using PowerShell it is straightforward to parse this xml into custom objects that can be easily used by other script.
For performance reasons the Orchestrator web service has a limit on the number of resources returned per page - at installation that limit is configured to 50 resources per page. To learn the total count of a particular resource and to get the resources page by page use the following construct in the query of the URL:
For example,
To illustrate the use of PowerShell to get resources from the Orchestrator web service I created a PowerShell module with functions that enable all of the examples in this post and more. Scenarios illustrated include these:
You can download the module and test files from http://orchestrator.codeplex.com/releases/view/82959 .
The functionality discussed in this post and implemented in the module are only a sample of what can be done. For example, there is a whole range of resource filtering that is possible. A good way to learn how to communicate via REST with the web service is to open the Orchestration console, start Fiddler, and see how various actions in the console are communicated between the console and the web service.
The Orchestrator web service exposes all of the key runtime resources. In this post, I have illustrated the key concepts for getting these resources using HTTP GET. In a related post , I show how to start runbooks and stop jobs using HTTP POST; these are actions that provide another level of programmatic interaction with Orchestrator.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.