Workflow can be the most powerful (and frustrating) tool in your war chest of tools to manage your environment. Setting up automated jobs, web forms and other workflows is cool and all. But just imagine what you would do for image automation (and anything else you can cook up in that twisted mind of yours) if you could run a script and have a symphony of actions take place. Automating your deploys with almost magical results and in the process making you look like a genius to your boss, co-workers and your users. Interested? Here is how it works.
Most web services allow you to do an HTTP GET (encode all your variables in the URL) to call the web service, but when you deploy a Workflow, they don't enable that option by default. You have to use SOAP Post actions (send up an XML file) to access the service or modify the web.config in the project to enable HTTP GET.
Setting this set up in your inputs and outputs in your workflow is easy. First things first, create your WF project. To set up a web service, just create a "Decision Only" project. There you will set up all your normal WF objects and decision making as you always do. Sure calling a web service is cool and all, but what’s almost as important is input and output. You pass up the computer name, PC GUID, or other data, and it gives you feedback based on that data as well as kicking off tasks and such (if that’s what you need). To set up that input/output, go to the model your web call will access (most likely your Primary Model). If you want to make additional publick web service actions, go to your other model in the Project view, right click and "Set Model as Invocation Target".
Input:
Output:
Now that you have your WF completed including input/output of your web service, time to figure out what the service will need to run. Go to the URL of your deployed service and click the service part you want to call. All the information shown there will be what you will need to set up the script so it can do its thing.
The top non-xml part will be your post header, and the bottom part will be the XML string you will construct in the script. I'll provide a full example attached to this article. But, first things first. Build your XML string. Copy and paste the XML into your editor of choice (I like Scite), and set up your variables and all the other information into a scrip friendly format like so:
<!--Update
I hit a different snag with this process and my work around might be a little cheating... but it works. I know there are methods of converting special non-xml friendly string into acceptible ones that SHOULD translate over properly... but IIS/WF for some reason wasn't catching one < or > properly... I I just put it in CData tags. 8-)
---Update>
Note the use of "chr(34)". Better use in my mind instead of quad quotes to create a single quote in your string. Obviously you would build this string after you set up all those variables. But see how it matches to what is expected in the SOAP definition above?
When your script is ready to send off the post, you call the post function (full example in attachment):
Again, see how the header setup matches the SOAP definition above? Well, short of the "Man" part, but that’s required.
If you don't define any output in your WF, you will get a string return of "". I always like to define at least one return so I know it did its job. Even if it’s some static return. The return will come back as an XML string and you can manipulate and read it like anything else using XMLDOM. At the very least, set up something so you know you got an exception or something like this:
...That’s the minimum in my book.
Now to HTTP GET. To enable this option Go to Resources tab in project and edit web.config file. Right above </system.web> near end of file add this:
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
Once you do this and deploy it, you will see the GET option enabled:
Then you can call the service in this format:
http://localhost/MyProject/MyService.asmx/WebMethodName?param1=value¶m2=value
To set up your URL String, its actually a bit simpler to use (as seen in the attach example):
...And again, the HTTPGet method is in the example, but you get the idea. I would also strongly encourage you to use this URLEncodeVar function in the GET example for encoding your variables in the XML Post example as well. In the code had lying around I didn't have a need for it there, but in this logging example it was necessary.
Well, that’s kinda the gist of it. Take a look at the example and for more detail and don't hesitate to post questions. And just to cite my work, many thanks to Nick Abt and David Parks for doing a lot of this leg work. I'm just using it like crazy and found a few things I like to do, and don't like to do when I'm using this method and wanted to share with my WF Peeps!
Do me a flavor and thumbs up if you like!