Geeks With Blogs
Charlie Mott


Update (10/06/2011): I no longer recommend the approach below.  It is too much of an administrative nightmare to create a wsdl for each possible service method call.  See new advise here:


How do you make it easy for client systems to consume the generic WCF services exposed by the ESB Toolkit using messages that conform to agreed schemas\contracts? 

Usually the developer of a system consuming a web service adds a service reference using a WSDL. However, the WSDL’s for the generic services exposed by the ESB Toolkit use messages with type="xsd:anyType".  Using these do not make it easy for the client system to use the input\output messages that conform to agreed schemas\contracts.


Take a copy of the generic WSDL’s and modify it to use the proper contracts.

This is very easy.  It will work with the generic on ramps so long as the <part>?</part> wrapping is removed from the WCF adapter configuration in the BizTalk receive locations. 

Attempting to create a WSDL where the input and output messages are sent/returned with a <part> wrapper is a nightmare.  I have not managed it. 


I can only see the following consequences of removing the <part> wrapper:

  • ESB Management Portal - unless you intend to modify the MessageResubmitter.cs code and bindings, do not implement the above change to the "OnRamp.Itinerary.WCF" receive location.  This is used by the portal to resubmit messages using WCF.
  • ESB Test Client – I needed to modify the out-of-the-box ESB Test Client source code to make it send non-wrapped messages. 
  • Flat file formatted messages – the endpoint will no longer support flat file message formats.  However, even if you needed to support this integration pattern through WCF, you would most-likely want to create a separate receive location anyway with its’ own independently configured XML disassembler pipeline component.


These steps show how to implement a request-response implementation of this.

WCF Receive Locations

  • In BizTalk, for the WCF receive location for the ESB on-ramp, set the adapter Message settings\bindings to “UseBodyPath”:

    • Inbound BizTalk message body  = Body
    • Outbound WCF message body = Body

Create a WSDL’s for each supported integration use-case

  • Save a copy of the WSDL for the WCF generic receive location above that you intend the client system to use. Give it a name that mirrors the interface agreement (e.g. Esb_SuppliersSearchCommand_wsHttpBinding.wsdl).
  • Add any xsd schemas files imported below to this same folder.
  • Edit the WSDL to import schemas

    For example, this:

<xsd:schema targetNamespace=http://microsoft.practices.esb/Imports />

… would become something like:

<xsd:schema targetNamespace="http://microsoft.practices.esb/Imports">
    <xsd:import schemaLocation="SupplierSearchCommand_V1.xsd" 
    <xsd:import  schemaLocation="SuppliersDocument_V1.xsd" 

  • Modify the Input and Output message

    For example, this:

    <wsdl:message name="ProcessRequestResponse_SubmitRequestResponse_InputMessage">
      <wsdl:part name="part" type="xsd:anyType"/>
    <wsdl:message name="ProcessRequestResponse_SubmitRequestResponse_OutputMessage">
      <wsdl:part name="part" type="xsd:anyType"/>

    … would become something like:

    <wsdl:message name="ProcessRequestResponse_SubmitRequestResponse_InputMessage">
      <wsdl:part name="part"
                          xmlns:ssc="" />
    <wsdl:message name="ProcessRequestResponse_SubmitRequestResponse_OutputMessage">
      <wsdl:part name="part" 

This WSDL can now be added as a service reference in client solutions.

Posted on Monday, December 20, 2010 10:48 AM BizTalk , ESB Toolkit | Back to top

Comments on this post: Creating typed WSDL’s for generic WCF services of the ESB Toolkit

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © charlie.mott | Powered by: