Over the last few months I was constantly asked how does BizTalk Services (formerly known as Windows Azure Integration Services) compares to BizTalk and whether one can use one instead of the other…
Whilst, generally speaking, I like the fact that this had been renamed to BizTalk Services (even if it means that searching information online about it will be somewhat difficult, due to the raft of publications on BizTalk out there), I suspect that this will only add to the confusion.
In any case – my answer has been, and will be for the foreseeable future – BizTalk Services, for the most part, is a great complimentary component to BizTalk. Sure – in some cases it can be a component in a solution that does not involve BizTalk, but it is very far from doing everything that BizTalk does, and – as far as I know – there are no plans to make it so.
So – if the two are so complimentary – how does one integrate BizTalk and BizTalk services?
Going in one direction – BizTalk Services to BizTalk Server – is very easy – one can publish a web service on BizTalk and consume that from BizTalk Services, maybe leveraging the Relay Service, part of the Windows Azure Service Bus to traverse the firewall. In some case one might want to publish the message from BizTalk Services to a Queue or a Topic on the Windows Azure Service Bus and read that from BizTalk using the built in capability. There are plenty of options to choose from.
Going in the other direction, though, is less flexible. At the time of writing BizTalk Services only support 3 way to deliver messages to it – HTTP, FTP (ok – including FTP/S, so maybe 4) and SFTP. To my surprise there is no built in capability to reading messages from the Windows Azure Service Bus or the ability to publish a web service.
Considering all these potions, I suspected that the HTTP route is the best one for integrating with BizTalk Server, so I decided to give it a go. here’s how it went –
The first step was to use the MessageSender sample to confirm that my bridge is working correctly (baby steps are important!)
Next, I wanted to make sure BizTalk is working (and I still remember how to configure it!) so I created a simple, messaging only, scenario – I started with a simple File Receive Location to File Send Port.
Procrastination over it was time to get serious, so I went on to add a second send port, this time using the WCF-WebHttp adapter configured to my bridge’s address, which is easily found in it’s properties –
It is important to use HTTPs and not HTTP, I found (trying to be lazy). Using the latter, Iwill result in the following error –
<Error><Code>400</Code><Detail>Transport security is required to protect the security token.</Detail></Error>
BizTalk Services protects me from myself and prevents me from exchanging security tokens without ssl. good or bad – you decide…
At this point my port configuration looked like this –
– and I figured it’s time to give it a go. As I haven’t integrated ACS yet I don’t expect to get through to the bridge but it’s a useful experiment on its own right – firstly to see that indeed authentication is required (no real doubt there) but also to see the end-to-end behaviour
Sure enough dropping a message for the File receive adapter I quickly receive a suspended instance, with the following error –
Which, unsurprisingly, looks very much like what I get in a browser –
<Detail>Manage claim is required for this operation..TrackingId:b44aa846-7105-4869-beb5-d7830eaeb2df_G0,TimeStamp:6/12/2013 9:02:58 PM</Detail>
Good – so I’m failing consistently, that’s progress 🙂 now all I needed to do is add the required bits to obtain the ACS token and add it to the outgoing request…..easy 😦
To do this I needed a solution that will allow me to obtain the ACS’ token for this request and inject it as an HTTP header to the outgoing request.
At this point I was sure I’m going to need to implement a custom WCF behaviour that will get the ACS’ token for the request and manipulate the outgoing message’s http headers to include the token but then it hit me – BizTalk already knows how to do that, because it has built in support for Windows Azure Service bus integration, which uses exactly the same mechanism.
A quick look at the WCF-WebHttp adapter configuration revealed a little tick box and some properties behind it –
Awesome – a big chunk of work I expected to have to do – create and configure a custom behaviour to call ACS and obtain a token and add it to every outgoing message – was all done for me!
At this point I had to try again, and it looked promising, alas I did get another error – this time about not being able to establish trust relationship for the SSL/TSL secure channel.
This makes sense, it is exactly the issue I had with deployment of my BizTalk Service project initially and of course it is because I’m using a self-signed certificate so I promptly added the certificate to the Trusted Root Certificate Authorities store on my BizTalk server and tried again.
Well – nearly – it looks like I did get to BizTalk services, as I’m getting back a tracking id, although I didn’t quite manage to see anything in the BizTalk Services tracking page. Unfortunately – the tracking id came with an error message –
The incoming request is not recognised as a namespace policy put request: Unsupported or missing Content-Type
Ah! –BizTalk to the rescue again – at this point I was happy with hardcoding everything, I just wanted to get this to work! 🙂 and it turns out the WCF-WebHttp Binding lets you set static Http headers you wish to add to the outgoing message –
That done and I’m ready for another attempt – message into BizTalk and……..nothing. No suspended instance….did it actually work? a quick check in the BizTalk Services Tracking reveals that it has! BizTalk had really made this easier than I expected and now I can integrate my on-premises BizTalk environment with BizTalk Services and through that…..the world! 🙂
Check what happens on failure on the BizTalk services side – do we still get an error on the BizTalk side? (so that we don’t lose the message)
Cross posted on the Solidsoft Blog