I have just got through a rather difficult project that involved BizTalk calling on a mixture of SOAP/REST services, and also exposing multiple RESTFul services as well. The project had a very short time frame and we had many technical hurdles to cross. One of the toughest challenges was communicating appropriate details when we were having problems calling one of our target services from BizTalk, or getting appropriate details from the consumers of services exposed by BizTalk when they were having trouble calling said services.
With relatively simple services this is typically no big deal… You just ask the service consumer to share the message body with you so you can see whether it is properly formed or not. If the service in question is being hosted by BizTalk and the message has got to the receive pipeline (i.e. it hasn’t failed on the adapter layer) then you could even take advantage of tracked message events and view the message body and associated context (which would also include custom SOAP/HTTP header values found in the tracked context properties). You could always look at using tools like Fiddler to inspect HTTP requests as well.
On our project we decided to use RequestBin because the REST services we were exposing from BizTalk required a fair few custom HTTP headers, and were in fact exposed using Azure Service Bus Relays thus required an Authorization header containing a SAS signature as well (note that Service Bus would strip off this header before it gets to BizTalk so you will never see it in tracked message events). Moreover, we were calling on the TripIt API which is a RESTFul web service that makes use of OAUTH for authentication/authorization. Once again the outbound HTTP headers had to be just right or we would encounter errors. In cases of HTTP Posts, the XML request also had to be URL encoded and made into a request body parameter, further complicating matters. In some tricky scenarios when we encountered problems we needed to contact TripIt for help and provide them with the appropriate details.
RequestBin helped solve a lot of problems for us. At its core RequestBin is a service that tracks your entire HTTP request, including the HTTP headers and body. RequestBin will always reply to your requests with an HTTP 200 and a message body saying “ok”.
You start by browsing to the RequestBin website and choosing to create a RequestBin.
You will then be presented with a bin URL.
This is the URL the service consumer should be directing their requests to instead of the actual target service when they want their requests to be tracked. If you append a ?inspect to the end of the URL and browse to this amalgamated URL in your web browser then you can view a history of all requests made to the RequestBin.
Having all parties that were consuming services get accustomed to providing RequestBin captures to the service providers made communication between different parties much more streamlined. This was especially important given that some of the parties were in different countries and time zones, and every time a query resulted in more questions rather than an answer meant another day wasted for the project. I don’t think I will ever work on a project involving external web services providers or consumers without using RequestBin again.
Of note is that your RequestBin will only be valid for 48 hours and will only keep track of your last 20 requests. If you want a more durable service then you might want to look into the RunScope Traffic Inspector, however note that this is a paid product (albeit with a free trial). This product goes well beyond the scope of RequestBin and appears to be comparable (at least in some sense) to Azure API Management or Sentinet. I would think that if your requirements are similar to mine then RequestBin is the ideal solution given how lightweight and easy it is to use, and chances are the limits are not going to bother you.
A final suggestion I’ll leave you with is to use RequestBin to inspect HTTP requests for SOAP services based on different bindings (obviously this is limited to the HTTP based bindings). Doing so will give you a much deeper appreciation of how the request formats differ based on bindings. A very simple example of this is how the SOAP Action is contained in HTTP headers for the basicHttpBinding but in SOAP headers for the wsHttpBinding. You can of course use WCF tracing for this as well, but RequestBin is so easy to use that it’s a pretty good alternative.