Showing posts with label web service. Show all posts
Showing posts with label web service. Show all posts

Wednesday, January 23, 2013

Orchestrator 2012 Web Service Request Issue

I've started running into an issue w/ external requests to start a runbook via the web service.  I'm interested to see if others are experiencing the same issue.

It seems sporadically that requests coming in (w/ or w/o parameters) will fail and the web service will return a 405 (Method Not Allowed) status code with the response.  Trying the same request again moments later would succeed.

Turning on Failed Request Tracing (FRT) in IIS for the "Microsoft System Center 2012 Orchestrator Web Service" will reveal more details w/ the error. 

From the site highlighted in IIS, you can enable FRT from the Actions pane.  After FRT is enabled, you can create the rule to capture specific status codes (400,404,405,500 in the example below).







After the issue occurs and the request fails w/ a code of 405, a log file will be generated in the following folder if you accepted the default path - C:\inetpub\logs\FailedReqLogFiles\W3SVC2.  Towards the bottom of the log file, you'll find this error information:

<Data Name="Buffer">&lt;?xml version=&quot;1.0&quot; encoding=&quot;utf-8&quot; standalone=&quot;yes&quot;?&gt;
&lt;error xmlns=&quot;http://schemas.microsoft.com/ado/2007/08/dataservices/metadata&quot;&gt;
  &lt;code&gt;&lt;/code&gt;
  &lt;message xml:lang=&quot;en-US&quot;&gt;The requested operation requires Publish permissions on the Runbook&lt;/message&gt;
&lt;/error&gt;</Data>

This appears to be a bogus error since sending the same request again will succeed using the same credentials.

After a little more digging, the error occurring seems to correlate w/ the ClearAuthorizationCache maintenance task in the SQL database.  Since this task computes/populates the folders, runbooks, and permissions....it theoretically make sense that while that task is running, incoming requests would fail since it thinks the user does not have permissions to the runbook (when it does!).  This could technically also affect requests being sent through the Orchestration Console to stop/start jobs.  By default, this task runs every 600 seconds (10 minutes).  I'm not sure of the duration it takes for the ClearAuthorizationCache task to complete, but it would depend on how much data there is to process (# of runbooks, folders, etc. in the environment).


If you have seen or do experience similar issues, I'd appreciate if you left a comment.  I also suggest opening a case w/ Microsoft to determine if this is a general product issue.

Wednesday, November 21, 2012

Run .NET Script: Catching PowerShell Output Into the Current Session

Here is a handy tip for catching PowerShell output into a variable as Published Data.

There are often times you need to execute a cmd within PowerShell that creates output in the cmd's output, but not PowerShell.

I came across a similar issue on the technet forums.
http://social.technet.microsoft.com/Forums/en-US/scogeneral/thread/a9511617-c174-4a5b-a531-3110471c9222

For example....

Running w/ PowerShell in the Run .NET Script activity cannot catch the output of the winrs cmd.  Even w/ adding the $Output = ... and adding the Output variable to published data.

$Output = winrs -r:server_name -u:server_name\administrator -p password net localgroup Administrators Domain\User /ADD

This will result in the Output variable in the published data being empty.

The trick is simply adding "2>&1" (without quotes) at the end of the cmd.  So the complete command would look like this.

 $Output = winrs -r:server_name -u:server_name\administrator -p password net localgroup Administrators Domain\User /ADD 2>&1

This will result in the $Output variable catching the result from winrs into the published data.  Also note, you may have to Flatten the data since the result may end up in multiple lines.




Here is a link that explains different methods for catching output in PowerShell.
http://mctexpert.blogspot.com/2010/11/what-does-2-mean-in-powershell.html

Wednesday, November 14, 2012

Orchestrator Polls

I've added two polls on the sidebar.  I'm interested in seeing the extent that other customers use the product.  Please take a second to fill it out.

Thank you!

Sunday, July 15, 2012

Get Child Runbook Success/Failure via Web Service

As external applications begin to incorporate Orchestrator to automate a subset of tasks in a larger workflow (outside of SCOrch), there may be times that the external app needs to check to see if SCOrch is done processing before continuing on.

In this scenario, the external application would use a POST to invoke the SCOrch workflow and then use two GET calls to poll the runbook's status when it finishes to determine if the SCOrch job was successful or failed.

First the SCOrch parent runbook which is invoked by the POST to the web service.




The key is setting the "Wait for completion" in the Invoke Runbook activity.






The Child Runbook is shown here.



The child runbook utilizes return data so the parent knows if it succeeded or failed.



In this case, if the runbook succeeds it returns Success = true and Success = false if it fails on the copy file or run .Net script.

Now that the Orchestrator runbooks are in order, the external application can invoke it via the web service.

First it would send the http POST payload with parameters.
url:
https://scorch.domain:8443/Orchestrator2012/Orchestrator.svc/Jobs/

payload:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<entry xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices" xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata" xmlns="http://www.w3.org/2005/Atom">
    <content type="application/xml">
        <m:properties>
            <d:Parameters>
                &lt;Data&gt;
                &lt;Parameter&gt;
                    &lt;Name&gt;FileName&lt;/Name&gt;
                    &lt;ID&gt;{3dc82b35-6ec0-45ab-9702-c04499d5a147}&lt;/ID&gt;
                    &lt;Value&gt;MyFile&lt;/Value&gt;
                &lt;/Parameter&gt;
                &lt;/Data&gt;
            </d:Parameters>
            <d:RunbookId m:type="Edm.Guid">71fd19ae-f0fb-499a-8a0b-d66a0e120921</d:RunbookId>
        </m:properties>
    </content>
</entry>

From the POST, the web service sends a response which you need to parse for these lines (specifically the guids):
<d:Id m:type="Edm.Guid">59d84f93-f504-4271-ae11-0a26eedb478c</d:Id>
<d:RunbookId m:type="Edm.Guid">71fd19ae-f0fb-499a-8a0b-d66a0e120921</d:RunbookId>

We need these guids for the first GET call.  This returns the runbook instance id.
url:
https://scorch.domain:8443/Orchestrator2012/Orchestrator.svc/RunbookInstances()?`$filter=RunbookId eq guid'71fd19ae-f0fb-499a-8a0b-d66a0e120921' and JobId eq guid'59d84f93-f504-4271-ae11-0a26eedb478c'&`$select=Id


The response would be parsed to find the guid in this line:
<d:Id m:type="Edm.Guid">c3cf1a99-ac0b-4505-b876-44ae8af9a9d3</d:Id>

The final GET call returns the activity instance data to find the results of the returned data from the child runbook.
https://scorch.domain:8443/Orchestrator2012/Orchestrator.svc/ActivityInstances()?`$expand=Data&`$filter=RunbookInstanceId eq guid'c3cf1a99-ac0b-4505-b876-44ae8af9a9d3'&`$select=Data/Name,Data/Value

This gives a response which we would parse for these lines

<d:Name>Success</d:Name>
<d:Value>true</d:Value>

The value would show whether or not the SCOrch workflow succeeded or failed.