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>
<Data>
<Parameter>
<Name>FileName</Name>
<ID>{3dc82b35-6ec0-45ab-9702-c04499d5a147}</ID>
<Value>MyFile</Value>
</Parameter>
</Data>
</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.
What command returns the response data?
ReplyDeleteHi,
DeleteIf you go back to a couple of my first posts from this blog (June archive), you can see the entire requests around the payload. The "Output" variable would contain the response from the web service.
Let me know if you have any questions on that.
Jon
This is very helpful, although after looking through all the posts, I'm still not sure how to get data out of the runbook. If the last activity in the runbook is "Return Data" with 2 variables, how do you get that from the web service? Also, what if the runbook runs the last activity more than once per job?
ReplyDeleteHi Omatsei,
DeleteIf the Return Data activity has more than one property set, there would be another tag in the XML response in addition to the "Success" property in my example. You could parse each of the tags since the name is predefined to get the returned results.
Success
Property2
In reality, it's probably easier and more flexible on the external application to get the results if they were written to a database table (rather than sending multiple POST requests to parse for guids....). This just shows that it is possible to get the results from the web service if that is the only method that can be used.
Let me know if you have any other questions.
Jon