Integration Saturday July 18, 2015 – Presentations

A big thanks to Mark and the rest of the crew for making this happen. It’s going to be a really exciting day and I encourage everyone in the Auckland area in the integration space to sign up.

Connected Pawns

The Auckland Systems User group(ACSG) will be holding a one day mini-symposium on Saturday July 18th in Datacom’s cafe. Please see the ACSG site for further details and how to register. This is a free event and will be restricted to the first 70 people who register .

This will be an day jam packed and is aimed at integration developers.

The keynote speaker is Bill Chesnut from Mexia who will start the meeting with the a presentation of the latest trends in integration. He will be followed by local integration experts who will present on  new integration patterns in the cloud, integration with REST, SOA , ESB, CI with BizTalk and Integration tips. For a full list of speakers see this link. A list of the talks can be found below;

1. What’s new on integration – Bill Chesnut  9.00- 9.45

2. Azure App Services – connecting the…

View original post 118 more words

Using RequestBin to troubleshoot SOAP/REST clients

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.

Dynamically setting HTTP headers on a static WCF-WebHttp send port in BizTalk Server 2013+

Ricardo Marques from Codit wrote a fantastic blog post a few years ago about dynamically setting HTTP headers for the WCF-WebHttp adapter using dynamic send ports in BizTalk Server based on the WCF.HttpHeaders context property. At the end of the article he stated that static send ports would not respect this context property, and this statement is the topic of this blog post.

Let me start by saying that I personally dislike dynamic send ports. It’s not that I don’t like the idea behind them, it’s more that I dislike the implementation (I won’t go into my reasons today). Wherever possible I will seek a way to enforce dynamic behavior on a static send port instead, and I have found a way to do this for dynamic HTTP headers.

The trick is super easy. All you need to do is set the BTS.IsDynamicSend context property value to true on the message before it gets processed by your WCF-WebHttp send adapter in order for it to respect the values in your WCF.HttpHeaders context property without losing access to all the other configuration you have set up on the static send port. I’ve extended the example provided in Ricardo’s original post below to illustrate how you set the context properties.

    public Microsoft.BizTalk.Message.Interop.IBaseMessage Execute(IPipelineContext pContext, Microsoft.BizTalk.Message.Interop.IBaseMessage pInMsg)
    {
        // Some non important logic here

        pInMsg.Context.Write("HttpHeaders", "http://schemas.microsoft.com/BizTalk/2006/01/Adapters/WCF-properties", "content-type: application/atom+xml");
        pInMsg.Context.Write("IsDynamicSend", "http://schemas.microsoft.com/BizTalk/2003/system-properties", true);
        return pInMsg;
    }

The inspiration to try this context property came from my colleague James’ blog post. His post was written regarding BizTalk 2009 so it’s good to see that Microsoft have been consistent about the usage of this context property even with the latest adapters. Thanks to both Ricardo and James for your good write-ups 🙂