BizTalk 2004 Web Services

BizTalk 2004 has great Web Service support; you can create an orchestration as usual and then expose it for invocation as a Web Service by using the Biztalk Web Services Publishing Wizard which is located on the Tools Menu inside VS.NET, and you can of course consume Web Services from within an orchestration.

To expose an orchestration as a Web Service you run through the Wizard and select the Port(s) in your orchestration that you want to expose via a Web Service, and the magic happens – Note the “Create BizTalk Receive Locations” option, if you check this it will create the Receive Locations (visible with BizTalk Explorer) for you which is handy.

This works really well in almost all circumstances, if you however have multiple receive ports within your Orchestration you’ll see that they are exposed as separate Web Services (within the same IIS virtual directory), this works just fine but it’s a bit neater (in my view) to perhaps have one Web Service that exposes a method per port, instead of the consumer having to use two or more Web Services endpoints.

The Wizard doesn’t allow you to configure the generated web service to enable this, but it’s pretty straight forward to do:

·         Create the ASP.NET Web Service that you wish to expose to your consumers; this will become the consumers interface to your BizTalk Orchestration(s). 
Create the methods that you require

·         Use the Biztalk Web Services Publishing Wizard tool to publish all of the relevant ports from your Orchestration. Do not check the “Create BizTalk Receive Locations”

The Web Services Publishing Wizard will create a new Virtual Directory in Internet Information Server, and this will contain a new Web Service per Receive port.

·         A Web Service consists of two files: <Name>.asmx and a <Name>.asmx.cs file.  The ASMX file is the Web Service endpoint and the CS file is the C# code relating to it.

·         If you inspect the .asmx.cs files you will see that they all belong to the same namespace, and contain one method each which contains the code to pass the parameters to the Orchestration.

·         To combine the methods you must manually copy of the methods from the ASMX.CS files into one ASMX.CS file.  You can rename this ASMX file to a more suitable name if you wish

·         If you now retrieve the WSDL for the Web Service containing all of the methods you will see that two methods are exposed.


·         The Web Service now exposes all of the ports via individual methods inside one Web Service, you must now configure a BizTalk receive port to accept SOAP messages from this Web Service.  Otherwise BizTalk will reject the messages as the sender is unrecognized.

·         In the BizTalk Explorer, Create a new Receive Port, Select the Port Type as being a Request-Receive port.  Within the Properties for this Receive port select Microsoft.BizTalk.DefaultPipelines.PassThruTransmit as the Receive Pipeline

Expand your newly created Receive port and Add a New Receive Location.  Choose SOAP as the transport type, and open the dialog to set the Address (URI) for this Transport.

Enter the Virtual directory and Web Service name in the textbox provided, e.g. /MyWebService/Service1.asmx. 
Note – This Web Service name will be the ASMX file that we copied the methods into above

·         Within the BizTalk explorer you must now Bind the Receive port we’ve created to the Orchestration, ensure that you bind all of the Receive ports on your Orchestration to the same Receive port.  Give it a whirl!

Comments (4)
  1. Jason says:


    I’ve been doing a fair bit with BTS 04 as well and I’m a big fan of publishing orchestrations as web services. It’s a great way to create a programmatic interface to your business process.

    My only comment would be that the wizard makes the assumption that callers want to pass .NET objects that represent their documents instead of passing the documents directly. Imagine I already have my document in an XmlDocument instance. Sending this document to BizTalk via the web service causes two serializations and two deserializations:

    – One deserialization to create the generated document object (assuming you use the XmlSerializer);

    – One serialization and one deserialization in the SOAP call;

    – One more serialization once the document is passed to BTS (as BTS operates on XML).

    This seems a wee bit inefficient. 🙂 If I could pass my document as either an XmlDocument or a string, I could avoid some of this overhead and eliminate having to maintain the generated code for the object. The wizard doesn’t give the option, though. I’m planning to explore writing my own web service interfaces to Biztalk once the object model is actually documented. 🙂 Until then, I’m staying away from the generated web services in favor of the HTTP receive adapter, at least when I already have a document. The client code is simpler and the communication is more efficient.


  2. BizTalk tips from Darren Jefford (ms)

  3. hung says:

    Inside VS.Net

    I can’t see Biztalk Web Services Publishing Wizard under the Tools menu


    I do have the ability to create Biztalk project in VS.Net, so the template is installed.

    Just the wizard is hidden some where


  4. John says:

    How do I use WS-security with Biztalk 2004.

    Does Biztalk 2004 integrate with SiteMinder?

    Could you give an overview of hwo to expose a SECURED web service using Biztalk


Comments are closed.

Skip to main content