Orchestrator 2012 SP1: Clear the Cache for Invoke Web Services

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:

image

Testing to make sure Orchestrator could use the service:

image

image

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.

[WebMethod]
public String GetString(String A)
{
return 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:

image

I then head over to Orchestrator and verify the new method works:

image

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.

image

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:

image

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:

Look here:

image

And in the newer file:

image

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:

image

 

 

 

 

 

 

 

Old data as expected.  I close out of the Runbook Designer, delete those newly created DLLs, reopen Designer and:

image

The new method shows up on the original port and a new DLL has been created.

Leave a Reply