Publish REST Service from BizTalk Server

Publish REST Service from BizTalk Server 2013 WCF-WebHttp Adapter

BizTalk Server 2013 provides REST Services support and it makes it easy to consume and publish REST services. I saw many example of consuming REST Services in BizTalk, however could not find anything for publishing REST Services on BizTalk. In this article I am going to detail on steps of publishing REST services.

 

For this article I referred to Steve-Jan Wiggers sample which can be found at following location http://code.msdn.microsoft.com/BizTalk-Server-2013-WCF-e3e4a4f9 

This sample talks about consuming a REST service to get airport status. In order to test the sample Steve has a Windows Form based application which invokes a WCF service exposed by BizTalk.

 

I further extended the sample to expose REST service using WCF-WebHttp Adapter and tested the whole scenario with Fiddler and IE. The details steps are as follows:

 

By this time, I assume you have run the above mentioned code sample

 

• Run WCF Publishing Wizard from Visual Studio Tools Menu:

 

 

• From the WCF Publishing Wizard, Select WCF-WebHttp Adapter on Service endpoint option and click Next

 

• Choose default option on AppFabric Connect, as we are not concentrating on ServiceBus right now and click Next
• Choose Create a Request-Response Receive Port and click Next

• Choose IIS publish location and select allow Anonymous access and click next
• The wizard will now display the summary page of the selection
• Click Create to publish the REST Service:

Few points to note after service is published:

• The WCF service wizard does not ask for any BizTalk Orchestration and Schema details Or Service Operation details as it does in other WCF service publishing. At first I thought there is something wrong, however then I realized that for REST services you do not need metadata information so there is no need to define the service operation.
• Service is published in IIS using default app pool of the IIS web site selected on the Wizard, if the app pool of the site does not have required BizTalk access, please change app pool.
• The name of the service is created as Service1.svc, for this sample to work you do not need to change the name.
• Make sure your service app pool does not have any other service running under it, e.g. if in the original sample, you published as WCF service and that service is running under the same account as REST service is running, you will start getting the following error:

"Registering multiple adapter types within the same process is not a supported configuration. For e.g. HTTP and SOAP receive adapters cannot co-exist in the same process"

You can now check the service by running the Service1.svc URL in IE and see if you are getting the service page successfully.

Now check out the BizTalk Receive Location which was created by WCF Service Publishing Wizard. You now need to configure the BizTalk operation you want your REST Service to support. The default operation configuration is not correct and should be changed as shown in below steps:

• Open the Receive Location Transport Type (Adapter) Configuration:

 

• Check out the HTTP Method and URL mapping box, its not what we want here, so we changed it to a GET operation with a URL /status/{airportcode}, where airportcode is a variable which will be mapped with a message context as shown below:

 
• The mapping of variable {airportcode} with message context properties allows BizTalk adapter to write the context property to incoming request and also allows mapped message context property to be used as a replacement while sending the request to a REST service.
• This configuration now allows One REST operation 'GET' with URL http://localhost/.../Service1.svc/status/BNA where BNA is the airportcode

 

If you now browse this URL in IE, then you should see a response similar to the response of http://services.faa.gov/airport/status/SEA?format=xml. Because in BizTalk we are just forwarding the request to faa.gov REST service.

 

You can also use Fiddler to create an REST request as shown below

 

Fiddler Request

 

 

 

In case of GET operation, there is no message body required, which can be ignored completely. However in some operation like POST, you need the message body. In such cases body can be supplied with appropriate content-type in the HTTP header.

 

I hope it helps you.

 

 

BizTalk ESB Toolkit Custom AdapterProvider and Endpoint Configuration

In my current project assignment, I needed MSMQ AdapterProvider for BizTalk ESB Toolkit and as usual before implementing myself I first searched it on bing and found the link of ESB extension which contains not only MSMQ adapter provider but also others adapter providers. The ESB extension is available on codeplex for ESB 2.0. I started browing the source code of the MSMQ adapter provider and realized that due to some issue MSMQ adapter endpoint configuration are not set if we use BaseAdapterProvider implementation and as a result certain methods were re-implemented in MSMQ provider. In order to find the root cause I started writing a new adapter provider for MSMQ. I thought of documenting this here. Following are the steps you need to follow to create the adapter provider, the amount of code you write is nothing, its all implemented in BaseAdapterProvider. Its all about configuration.

1. Create a new C# project and add a reference to Microsoft.Practices.ESB.Adapter assembly which you can find in Microsoft ESB ToolKit 2.1\bin folder.
2. Created a new class AdapterProvider and extended it from BaseAdapterProvider. BaseAdapterProvider class is abstract implementation of IAdapterProvider interface and provides all basic functionality.
3. Override property AdapterName and return adapter name from it e.g. MSMQ
4. Sign and Build your project and install the assembly in GAC
5. Register your new adapter provider in ESB.Config file as follows:  adapterProvider name="MSMQ" type="ESB.Adapter.MSMQ.AdapterProvider, ESB.Adapter.MSMQ, Version=1.0.0.0, Culture=neutral, PublicKeyToken=8c284297668e995a" moniker="MSMQ"
6. At first you think that's it and now you can see your adapter provider in your resolver under the TransportName.
7. If you just need the default basic properties on your adapter provider e.g. Transport Name, Transport Location then you do not need anything else. However if you click now on Endpoint Configuration option then you get an error as shown below:
   

BizTalk Server ESB Toolkit Service ESB.ItineraryServices.Generic.Response.WCF Fails to browse

If you browse this service after installing and configuring ESB toolkit then you receive one of the error depending on if you are using BizTalk 2010 or BizTalk 2013:

BizTalk 2010

Error 855000: Could not find schema file for SOAP header 'ItineraryDescription' at path C:\Program Files (x86)\Microsoft BizTalk ESB Toolkit 2.1\Web\ESB.ItineraryServices.Generic.Response.WCF\App_Data\ItineraryDescription.xsd

BizTalk 2013

An ExceptionDetail, likely created by IncludeExceptionDetailInFaults=true, whose value is:
System.ArgumentException: The value could not be added to the collection, as the collection already contains an item of the same type: 'Microsoft.Practices.ESB.ServiceModel.Helpers.SoapHeaderMetadataBehavior'. This collection only supports one instance of each type.

Cause

By definition, Generic On-Ramp services are meant for not passing the itinerary details with the message and so they don't need to have ItineraryDescription. This is how One Way On-Ramp service also works. However this ESB.ItineraryServices.Generic.Response.WCF On-Ramp service expects to have soap header with Itinerary description as per its configuration but from a deployment perspective there is no ItineraryDescription.xsd in the folder and as a result this error is returned.

Solution

The solution to this problem is to disable soapHeaderMetadata in Web.Config file so that WCF does not try to load the SoapHeader information. So within the serviceBehaviors node change soapHeaderMetadata node attribute enabled=false as follows and recycle the IIS application pool:

soapHeaderMetadata enabled="false"