Supplant a BizTalk WCF service

Question

I have a WCF service based on BizTalk, I'm not sure how it was deployed or generated but as far as I know it was made using the BizTalk wizard for publishing WCF services. The problem is the BizTalk server installation was removed and now the service still here but it doesn't work, when i invoke the URL the service responses an exception: The BizTalk receive location may be disabled. I need to generate a WCF service in order to replace that service. I have one example request and response and the folder with the service, with a lot of stuff, XML, definitions, etc but there are no DLLs. The SVC markup has a reference to a BizTalk logic.

<%@ ServiceHost Language="c#" Factory="Microsoft.BizTalk.Adapter.Wcf.Runtime.WSHttpWebServiceHostFactory, Microsoft.BizTalk.Adapter.Wcf.Runtime, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" %>

So here goes my question, does anybody know how to generate a service based on request or response to supplant the service.

To clarify - you want to re-create the service but without using bizTalk? Do you expect existing service consumers to be able to continue calling the service? — tom redfern

tom redfern tom redfern · Accepted Answer · 2015-02-27T12:56:36

If you only have the request and response xml then it's a bit tricky. Even if you manage to recreate the service there is no guarantee that existing service consumers will be able to continue to call the service without any change. However, if you want to have a go, this rough guide will help:

Extract the operation signature from the soap request and response

This should be simple. Just look at the part of the request xml which defines the SOAP body. As an example:

<soap:Body xmlns:m="http://www.bookshop.com/prices"> 
  <m:GetBookPrice> 
    <param1 xsi:type="xs:string">Metro 2033</param1>
  </m:GetBookPrice> 
</soap:Body>

This shows that the operation name was called GetBookPrice, and that it takes a string as an argument. Now look at the soap body for the response, for example:

<soap:Body xmlns:m="http://www.bookshop.com/prices"> 
  <m:GetBookPriceResponse> 
    <return xsi:type="xs:decimal">5.99</return>
  </m:GetBookPriceResponse> 
</soap:Body>

This tells us that the return type of the operation was decimal:

public decimal GetBookPrice(string bookName);

So now you can recreate the service operation in a vanilla WCF service.

It's possible that the service definition included complex types rather than primitives, in which case you need to infer the types from the request/response xml. If the types are too large, you can try to automatically infer them by:

Infer XSD from XML - you'll need to extract just the request and response types from the request/response files, then run them through xsd.exe, which will try to generate the XSD schemas for your request/response types.
Infer CS from XSD - once you have the XSD files, again use xsd.exe to infer the classes for these files. You can then annotate these classes with the DataContract and DataMember attributes and then you can use them in your service definition.

In conclusion, it's not a task I envy you for - even if you manage to faithfully reconstruct the service and type definitions, you may still find that existing clients cannot call the service based on having missed some optional data which was not present in the request/response files you have.

Supplant a BizTalk WCF service

4 Answers