I have been using Fiddler in my BizTalk projects for a while now and thought I would blog about using BizTalk with Fiddler.
To exchange information between Microsoft BizTalk Server and an application by means of the HTTP(S) protocol, in BizTalk we have many adapters like HTTP, SOAP, WCF adapters. When you send a message to the target application using HTTP(S) protocol, it’s always useful to see the content of message that’s being exchanged over the wire.
Fiddler is a free HTTP debugging proxy server application/tool, which captures the HTTP and HTTPS traffic and logs the content for us to view. As the name suggests this tool also allow us to modify/fiddle with the HTTP traffic.
In this post we will see
- How to view the content of the message being exchanged from BizTalk to its target system using HTTP protocol?
- How to modify/fiddle the response from the target system before its being received by BizTalk?
How to view the content of the message being exchanged from BizTalk to its target system using HTTP protocol?
Fiddler can debug from any application which accepts a HTTP proxy. So you have to enable your BizTalk send port to accept the HTTP Proxy. In Send port you have to provide server name where Fiddler is running and its port name. For server name, if you use Fiddler in the same server where BizTalk processing server is configured then the server name would be localhost or 127.0.0.1. As a best practice, I would always use the Fully Qualified Domain Name (FQDN) of the BizTalk server. To get your FQDN, go to Start –> Right Click on Computer — > Properties –> In System properties, find “Full computer name”
Note: In this article, I have used “localhost” (not FQNS) as the server name for the ease of understanding.
With server name and port details we can configure the BizTalk send ports.
In Static Send Port:
In BizTalk’s static send port which has been configured to use HTTP/SOAP/WCF adapter you have to set the proxy setting (Send port, adapter –> Configure –> Proxy). Choose “Use Proxy” and give the proxy details as shown:
In Dynamic Send port:
For dynamic send port, the proxy details are resolved from the context of the outbound message. Hence you have to construct the outbound message context as follows:
For WCF adapter:
msgOrder(WCF.ProxyAddress) = <a href="http://localhost:8888">http://localhost:8888</a>; msgOrder(WCF.ProxyToUse) = "UserSpecified";
For SOAP/HTT adapter (Change SOAP to HTTP based on adapter used):
msgOutboundRequest(SOAP.UseProxy) = true; msgOutboundRequest(SOAP.ProxyAddress) = "locahost"; msgOutboundRequest(SOAP.ProxyPort) = "8888";
You don’t want to execute this code in production, so ensure these codes are executed only in debug mode.
Now with everything configured in BizTalk for fiddlers, you can start the Fiddler to trace the traffic. If you have configured BizTalk to use Fiddler, but if you have not started the Fiddler then your message would suspend with following error.
“Unable to connect to the remote server —> System.Net.Sockets.SocketException: No connection could be made because the target machine actively refused it 127.0.0.1:8888”
So you have to make sure your Fiddler is started when BizTalk (which is configured to use proxy) sends the message.
Now to Fiddler, I am not going to detail about the Fiddler but just going to give overview about some of the sections, we will be using more often.
- As the image shows, Web Session pane is where the details like status, host, URL of the traffic displayed as it is being captured.
- On right, you can see many tabs. For this blog, I am going to use TextView tab. As name suggested it show the text view of the message exchanged.
- At the bottom of the left side, you can see quickexec box where you can run some useful commands which we will see in a moment.
- Another useful section under Inspector tab is the Raw section which displays the message as in its raw mode. Here you can see the details like Content-Type, SOAP Action etc.
How to modify/fiddle the response from the target system before its being received by BizTalk?
Now after familiarising with basic of Fiddler with BizTalk, we can extend a bit deeper. In some of your BizTalk projects, you would have faced some requirements to test your BizTalk process to different responses from web/WCF services. But for many reasons you may not able to trigger the web service to respond as you want. For example, in a BizTalk process, you would send an Order request message to your web service and receive an order status message as response. And rest of your BizTalk process/Orchestration depends upon the “OrderStatus” field of the received response message. You have coded to handle for OrderStatus values as “APPROVED” or “REJECTED”. And you might have an exception handler to handle if OrderStatus is anything different. Now how would you test your exception handler section of your Orchestration? With Fiddler, you can easily modify/fiddle the response of the web service before its being sent to BizTalk’s Send port.
You can modify the response (even request) message by setting a breakpoint to the response message from web service. There are many ways to do, but my preferred way is as follows:
- In the quickexec box (the black box at the bottom) type “bpafter yourpage.svc” (type without quotes)
- Now you should see “ResponseURL breakpoint for yourpage.svc” message in the status bar of the tool.
- If you send the request message as you normally do. When the response is received, Fiddler would hold the process as show in the following image.
Now you can edit the response message in its textview and click “Run to Completion” button to send the modified response to your BizTalk process.
This feature is very useful when you want to test your BizTalk process for different responses with out depending on your web service team/client to produce different cases for you.
To release the breakpoint, just type “bpafter” (type without quotes)- without any parameter.
I have been using Fiddler in all my BizTalk projects where I use HTTP based adapters. An advanced tool but still simple to use. Hope this article is use to you.