I recently had a request for URLGenie documentation on how to configure a URL instance for a SOAP service with an xml SOAP body. Here’s a quick demonstration.

I found this SOAP service site for testing: http://www.dneonline.com/calculator.asmx

It even comes with a WSDL file which defines the service schema.

In this example I’ll use my Chrome browser. Add the Boomerang extension to Chrome.

Select: Import services from WSDL file:

Provide the path to your WSDL file and add the Service (in this case, “Calculator”):

The service gets added to the nav area:

Open the Add service action in a new tab. Put some numbers for intA and intB elements. These two numbers will get added together by the service and appear in the Response shown in the next step.

Submit the request with the “Send” button. Observe the result on the Response tab.

Make note of the Headers used for the request:

The parts specific to the SOAP service configuration are enclosed in red:

Verb: the default verb is GET. Change this to POST. Technically, according to rumor, GET could possibly be used if your service and/or webserver would allow it but it’s not the right method for a service request.

In the Boomerang screenshot of the Headers, there are two headers shown: Content-Type and SOAPAction. Content-Type is already included in the URL instance properties file but it’s less obvious being named: headercontenttype (on line 19) so ignore Content-Type, it’s already set correctly.
As for the second, SOAPAction, this must be included in one of the three available header properties; the service requires it. By default these header fields contain relatively generic values that are pretty much universally accepted by all web servers. These header properties exist on the URL instance purely for you to use IF needed. In this example we do, in fact, need to use one of them with custom values. In my example I chose header3 to populate the name with “SOAPAction” and the value with “http://tempuri.org/Add”.

Also notice that the contentmatch needs to be the sum of the two integers:

Observer the health status. A response code of 200 is a good thing. The content match is satisfied.

By default, the ResponseBody is not stored in the context data. If you’d like to actually see and record the ResponseBody you can override the Content monitor for the instance.
Note: This will break cookdown for the monitor and cause the health service to spin up an additional probe instance for this monitor. Not a huge deal for a small number of instances.
Parameter: CollectResponseBody – Default: Never (Never, Always, OnContentMatchCriteria)
Override Value: OnContentMatchCriteria (this means that if a ContentMatch value is provided to the probe, then the response body will be collected and saved with the context data.)

Force an error condition by changing the contentmatch to something impossible:

In my lab I have instance discovery set to a very aggressive interval so the change will become discovered and implemented relatively quickly.

We can see the Content match failure as well as the ResponseBody now appears in the context data:

Revert your changes to return to a Healthy status.