I ran into a scenario where I needed to stand up SOAP web service up in order to test why a particular payload was not being accepted by the Orchestrator activity Invoke Web Services.
Using the code from this KB, I was able to stand a simple service up and access the WSDL through IE:
Testing to make sure Orchestrator could use the service:
Result of 6. Perfect.
Thinking that maybe just one or more fields in the payload were not being handled correctly by Orchestrator, I thought by running the data provided through a method I might be able to identify the problem. However, most of the data that needed to be ran through such a method were strings, and all of these math functions take and return numbers. No problem, I will just toss in a new function that simple takes a string as input and returns the same string.
public String GetString(String A)
I compile the new service, update the code sitting inside of IIS, restart the site and I see my new method returned in IE:
I then head over to Orchestrator and verify the new method works:
The new method is not there. Orchestrator is caching the data returned by the WSDL somewhere.
This is where the fun began. Searching hi and low, including the registry, the directories inside of the user profile, the directories inside of the install directory and then just flat the entire drive yielded no results. I ended up using ProcMon to watch the runbookdesigner.exe process to see if I could figure out where the data was being retrieved from. Initially, it was a no go. I ended up moving the port the service was running on from 81 to 82. This created a new URL that needed to be hit.
There’s my function. Now, did ProcMon show where the new data would be cached? Not in the trace (or I missed it as there is a ton to go through).
I decided to pop open the process to see if it had a file handle somewhere that was not necessarily showing in the trace, and I find a two that catch my eye because they start with GUIDs. The are stored in the following folder:
Looking at the timestamps, they roughly coincide with when I originally connected the web service on the different ports. I see that they are DLLs but I try and open one with notepad for the fun of it:
And in the newer file:
This one has my new function. It appears the Invoke Web Services activity is taking the data from the initial call to the service and caching it in these newly created DLLs. Since I don’t want my web service running on the wrong port, I go back over to IIS and reset the bindings to 81. Post doing that I point my activity back to the correct URL:
Old data as expected. I close out of the Runbook Designer, delete those newly created DLLs, reopen Designer and:
The new method shows up on the original port and a new DLL has been created.