Showing posts with label WCF. Show all posts
Showing posts with label WCF. Show all posts

Monday, January 13, 2014

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.
 
 

Monday, April 22, 2013

WCF ServiceModelReg Error on Windows 8

If you try to activate WCF model on Windows 8 environment by running ServiceModelReg -r -y command on C:\Windows\Microsoft.Net\Framework64\v4.0.30319, then you will following error:


[Error]This tool is not supported on this version of Windows. Administrators should instead install/uninstall Windows Communication Foundation features using the 'Turn Windows Features On/Off' dialog, or the dism command line tool.

Once you go to Program and Features and Turn Windows Features On/Off, then Expand .NET Framework 4.5 Advanced Services ->WCF Services and select Http Activation as shown below:


This will register WCF service model with .Net Framework 4.5
 

Monday, October 1, 2012

WCF Service Exception Handling Best Practice

I was working on a WCF service and I needed a way to handle uncaught exception raised during any service operation in a controlled way e.g. I wanted to log or email unhandled exception and send a valid response to client with information required to trace the problem.

One way was to have a try catch in each method and return the fault from there. This approach is simple and works however in case of lots of service operations or lots of services it become very tedious to repeat the same code block everywhere.

So I searched and finally implemented a new common error handler for my service based on WCF interface IErrorHandler. This interface provides two methods HandleError and ProvideFault which you can override to implement your own logic. Once hooked into your service, for any uncaught exception HandleError and ProvideFault methods are invoked. HandleError is the method where you log the errors, and ProvideFault creates a new fault message which becomes your service response.

There are two ways you can hook this handler to your service:
1) using Service Behavior attributes by implementing IServiceBehavior interface and inheriting from Attribute class. and then use the attribute on your service class similar to any other attribute

2) Use service behavior extension by inheriting from BehaviorExtensionElement, which allows to configure common error handler via service web.config file

I have attached here the complete code of this common handler. In order to use this either use method 1 or 2. A sample on how to use is given in ErrorBehaviorAttribute and ErrorBehaviorExtension classes as well.


Please note, this sample code also gives you a common ServiceException class which you need to use as faultContract type in your service contract e.g.
[FaultContract(typeof(ServiceException), Name = "serviceFault")]

If you decide to use this Common Error Handler, The same ServiceException should be used to return your business exceptions. You can always change implementation of these anytime you want, this code only gives you an idea on how to implement these.

Also last but not least, in order to upload the sample to make it available to all of you, I made some changes e.g. namespace and all you may want to change them as per your need.

Happy coding :-)









Monday, May 7, 2012

Convert ASMX web services to WCF


WCF provided much more features and functionality than asmx service out of the box e.g. it implements standards like WS Security, WS Addressing, WS Transaction etc. Performance wise its better than asmx services. See following links for WCF benefits:

http://msdn.microsoft.com/en-us/library/ff648122.aspx

http://msdn.microsoft.com/en-us/library/bb310550.aspx

http://msdn.microsoft.com/en-us/library/aa480190.aspx

For converting an asmx service to WCF we need to take following steps, This approach will choose appropriate serializer depending on the types defined in your asmx service.
  • Create a .wsdl file from current asmx service, you can do this by typing the service url?wsdl in IE and then save the file as .wsdl extension
  • Go to Visual Studio Command Prompt
  • Go to the directory where you saved wsdl file and run svcutil.exe with wsdl file name as argument e.g. svcutil.exe Queue.wsdl
  • The svcutil will generate two files .cs file and .config file. The .cs file will contain your service contract.



  • Create a new WCF Service Application in your solution, This template creates a service1.svc in your project, remove all files associated with Service1
  • Add a new WCF Service by using add item and name it as your own service e.g. Queue
  • Delete the interface file created in above step.
  • Copy your .cs file generated by svcutil to your WCF service application folder and include it in your project. Change the file name to indicate it as an interface e.g. IQueue.cs. You need to change the class name also and its references in the class.
  • In your generated interface file, remove , ReplyAction = “*” string for each operation, see the screen shot:




  • Implement the above interface in your implementation class
  • Build your project, and you should be good to go. 
  • You can now implement your methods by copying your old code to new one or by writing it new.
  • In order test, browse your service in browser or add a service reference to a test project, and it should generate similar interface at your end.