Ok so there has been a little talk at the London BizTalk Summit about 2016 being the next expected release for BizTalk Server.
If I could choose 5 things id like to see in it they would be:
- No limit on no. Apps in BizTalk Standard Edition
- Ability to consume Swagger
- Support on Azure IaaS
- AMQP Adapter
- API App Addins
- Proper Azure BizTalk Developer Machine
No limit on no. Apps in BizTalk Standard Edition
This one really bugs me! There is a rule in BizTalk Standard Edition that I can only have 5 applications.
The result of this means that when a customer uses BizTalk Standard Edition they have to build their code bases and application deployments differently to how they would build them if you had BizTalk Enterprise Edition. This means if you start with BizTalk Standard and want to migrate to Enterprise Edition then the way you have set up your solutions needs to change or you will find the management and maintenance experience to be poor.
I believe a much better way to restrict the usage of BizTalk Standard Edition would be to limit the number of BizTalk Host processes you can have, or better yet you can only deploy it to a single server anyway so there isnt really a need to further restrict anything. I would hope this would be a very simple restriction to remove.
The value of this means customers can easily upgrade to BizTalk Enterprise and know they have build their stuff to best practices which will just migrate easily, or alternatively downgrade if required and know they wont need to refactor any code.
Ability to consume Swagger (or expose)
The new latest and greatest integration stuff is about API’s that expose Swagger. This provides a contract which should make it possible a BizTalk developer to add a reference to a Swagger service in a similar way to what we would do for a WSDL based SOAP interface.
It would also be cool to expose Swagger on any REST services we expose from BizTalk.
I believe this would be a significant statement of support for newer styles and make it much easier to integrate BizTalk with API Apps and Azure API Management.
Support on Azure IaaS
One of the biggest challenges for BizTalk customers is how to create a reliable infrastructure which matches best practices. This can be a difficult task to get right and getting it wrong can be expensive and something you dont notice until later. This is one of the key reasons why BizTalk is perceived to be difficult to implement.
If we had support for fully H/A BizTalk set ups on Azure IaaS then it would be possible to create a scriptable BizTalk / SQL environment which could be built in a similar way to how a Sharepoint Farm can be created in Azure. Lets be real about this, some customers need a super high performing environment tuned like an F1 racing car, but many customers could use a BizTalk setup which was build on Azure which met the performance characteristics Azure could achieve and it would be absolutely fine and could use a VPN to come on premise. This could make the implementation of BizTalk for 80% of customers a commodity task rather than a specialist task.
The biggest blocker to this is still the clustering support for SQL.
If Microsoft were able to solve this or to offer official support for customers to use Data Keeper then it would be possible to create this out of the box BizTalk setup which would significantly lower one of the biggest barriers for customers implementing BizTalk but it would also simplify support because many customers would be using the same base environment.
AMQP Adapter
I think the integration story between BizTalk Server and Service Bus (on premise and cloud) is fundemental to future BizTalk implementations. Combining BizTalk with an external queue gives a great way to create decoupled and flexible BizTalk solutions.
An AMQP adapter would give us a protocol adapter support for Service Bus which removes the dependancy on the service bus dll which BizTalk struggles to keep up with the pace of change. Moving this to a protocol adapter would remove this dependency and allow BizTalk to connect to service bus messaging and service bus event hubs at protocol level.
An AMQP adapter would also provide support for integration with customers using different message broker vendors who also support AMQP 1.0.
API App Addins
Many of the new features in the integration stack are being created in the API App and Logic app space. If we had widgets in BizTalk which we could easily configure to work with Azure integration assets then this would give us the ability to combine BizTalk on premise with BizTalk in Azure. Some examples of how we might do this include:
1. Azure API App Mapping Pipeline Component
We can add a BizTalk pipeline component which would allow us to configure it to call out to an API App and allow us to host a map in the cloud which is called from BizTalk
2. Azure API Rule App shape in Orchestration
A shape in the orchestration designer which can be configured to easily call out to a rule app in Azure or perhaps a widget in the BizTalk Server rules designer which allows us to delegate the rule call to an API app so its easier for the rule to change in isolation
I think this could be potentially delivered as a hybrid cloud accelerator or something where addons are installed to BizTalk to make it easier to deliver solutions which combine the use of BizTalk and Azure.
Proper Azure BizTalk Developer Machine
Setting up new environments for a customer is a pain and one of those time consuming tasks which means customers are doing stuff that they dont perceives adds value. The BizTalk Developer image in Azure is something where a customer should be able to easily spin up machines for development purposes. The problems I have with the images are:
1. They seem to regularly expire
2. They seem to have the SQL evaluation image
3. They are always released ages after a new product release
4. They are sometimes only available on a MSDN azure subscription
My assumption in the past was that Microsoft was cautious customers might use them for non development purposes.
The problem here is that a customer often has a team of developers with MSDN who want to work as a team so work on a shared non-MSDN (usually an ent agreement) subscription so the team development effort can work together and eat out of a corporate agreement. A customer should be able to easily spin up a number of BizTalk servers for development which can be relied up on to work for the long term to support the team. Not having to install these from scratch is a big cost saver and would mean the entire development environment can be easily scripted. This would significantly reduce those barriers to entry for new customers or a migration project.
Anyway theres a few thoughts of things id like to see, its about things which lower customers barriers to entry and things which add features of strategic value to BizTalk Server.
Would love to hear what others think are key
I agree with all of these points! Especially “Support on Azure IaaS” It is always a mammoth task to get clients to set up a Biztalk environment “correctly”. Hopefully Microsoft will be actioning the cluster limitations sooner rather than later.
Your wish list pretty much echoes mine, but there is something extra I would like to see:
XSLT 2.0 support! This has been requested for several versions and from what I can see, it is still not there.
I think that the BizTalk IaaS simply will not happen. Partly based on what it is for but also that Guru said so. However, as ever the MSDTC is the problem and is also one of the reasons why it will not happen. BizTalk on Hyper V in a datacenter is good though.
For me personally I agree to the add on stuff like swagger and AMQP. However there are still too many issues that comes down to the fact that they say that they are supporting BizTalk OnPrem but then it does not SHOW. Like the friggin FILE adapter that has not been updated for years no name but one of the many issues.
i hope with some of the suggestions above (eg: swagger and amqp) will be able to be delivered as kind of a feature pack which mean they could come out earlier or later than a full release.
The key think is a commitment to deliver things above just platform upgrade but without it requiring a massive effort which takes too much resource away from the azure features.
BizTalk Task Schedular Adapter ,which is currently CodePlex should be included in the BizTalk core , as well as some inbuilt session management/caching mechanism.
I dont see the point in including scheduled task adapter in the core product. IMO it means more code to maintain in the core product which means more time and money to test and ship new versions of BTS Server without any real value because its a pretty solid open source offering anyway
What would be better is a market place to make it easy for me to acquire these open source or MS approved 3rd party add ons
Thanks Mike , All your points makes better sense ,but when it comes to open source tools such as this , there is a hesitation /concern when it comes to using this on Production environment though it looks stable ,hence it should be tied up with BizTalk/Microsoft in some way ,as you suggested a better market place may be ,Cheers.
Thanks for this article. I administrate a small solution (Biztalk 2009) and have reached the max 5 apps. I am also appaled by the adapters that comes with the product. The features of these are a joke. We have purchased nSoftware and these adapters work as you would expect from a Microsoft product. I believe we will not upgrade as new versions licensing is a bit steep for our simple usage. We’ll go for BlueIntegrator which is easy to setup and manage and even has a buildt-in sftp adapter!