We have recently completed Phase 1 of a “greenfields” BizTalk 2013 R2 implementation for a client and I wanted to jot down here some of my thoughts and technical learnings.
My role on the project was Technical Lead: I gathered requirements, generated the technical specifications, set up the BizTalk solutions, kicked off the initial development and provided supervision and guidance to the team.
Before starting on the project about 15 months ago, I had previously spent quite a bit of time working with a large BizTalk 2009 installation so I knew for my next assignment, that I would be playing with some new technologies in Azure and also using the new(ish) REST adapter. When I look back now, SOAP+WSDL+XML now seems something from a different age!
Here is a list of some key features of this hybrid integration platform:
- BizTalk sits on-premises and exposes RESTful APIs using the WCF-WebHttp adapter. These APIs provide a standard interface into previously siloed systems on-premises, a big one being the company wide ERP.
- Azure Service Bus relays using SAS authentication provide a means of exposing data held on-premises, to applications in the cloud. This proved very effective but a downside is having to ping the endpoints, to ensure that the relay connection established from BizTalk doesn’t shut down, resulting in the relay appearing unavailable.
- Service Bus queue allows the syncing of data from CRM in the cloud to ERP on-premises. We used the SB-Messaging adapter. Don’t forget to check for messages in the dead letter queue and have a process around managing this.
- A mixture of asynchronous and synchronous processing. With asynchronous processing, we used orchestrations but synchronous processing (where a person or system is waiting for a reponse), these were messaging only (context based routing only).
- We used the BRE pipeline component to provide the features of a “mini” ESB, almost as a replacement for the ESB Toolkit.
In a nutshell, BizTalk is the bridge between on-premises systems and the cloud, while also providing services for the more traditional systems on the ground. I believe this will be a common story for most established companies for many years but eventually, many companies will run all their systems in the cloud.
I expected a few challenges with the WCF-WebHttp adapter, after stories from my colleagues who had used this adapter before me. My main concern was handling non HTTP 200 responses which triggered the adapter to throw an exception that was impossible to handle in BizTalk (I know 500 errors will be returned by the adapter now, with a fix in CU5). So from the start of the project, I requested that the APIs exposed from the ERP system always returned HTTP 200 but would include an error JSON message that we could interrogate.
We also had to treat the JSON encoder and decoder pipeline components with kid gloves, with issues serializing messages if our XSD schemas contained referenced data types (e.g. from a common schema). We had to greatly simplify our schemas to work with these components.
Also lack of support for Swagger (consumption via a wizard and exposing Swagger endpoints) is a glaring omission. I manually created Swagger definition files using Restlet Studio which I found to be a great tool for documenting APIs, which was recommended to me by Mark Brimble.