There are many customers of BizTalk Server that have no plans to migrate to Azure anytime soon or in some cases at all. So, what can these companies do to make the most of their existing BizTalk Servers?
In this blog, we explore five key areas to improve and make the most of your existing BizTalk Server business solutions to ensure we are following best practices and guidelines, and resolving areas of persistent failure. The additional benefit of fixing these key areas is they will simultaneously get the BizTalk Server solution ready for when the time comes to migrate to Azure.
So whether migrating is a distant plan or you never want to migrate to Azure, you can enjoy the benefits to your current BizTalk Server while knowing you are also ensuring any future migration to Azure will be easier, quicker and cheaper.
1. Transformations (Maps)
1. Transformations (Maps)Let’s look at Transformations (also commonly referred to as Maps) which in a lot of systems encapsulate the vast majority of the integration logic. The BizTalk Mapping Tool is an award-winning product in its own right and is very easy to use via the Visual Studio IDE.
However, where it falls down is not being able to document what the maps are doing. This is especially true when it comes to complex maps where you can be faced with a screen full of connecting lines from the source schema to the destination schema interspersed with a plethora of functions.
I recommend an approach I have followed for many years – write XSLT for the transformations. This has the advantage of being able to document each transformation verbosely making it easier to maintain.
Up to BizTalk 2020, we were limited to using XSLT 1.0 but with the arrival of BizTalk 2020, we can take advantage of XSLT 3.0 which has a richer set of functions.
When it comes to migrating to Azure one thing you can do is copy your XSLT files (these can also be generated from BizTalk Maps) to Azure. Then execute them there without having to rewrite them from scratch.
One thing that Azure doesn’t support in XSLT files is in-line scripts. These can be either moved to use XSLT 3.0 or move the logic into extension objects which are supported in Azure.
2. Production Failures
We may see from time-to-time failures in Production which require manual intervention that can consume a lot of Production support staff resources. Investigations into the causes of these failures can be done to see if there is a technical solution that can avoid or reduce the number of failures in Production.
3. BAM (Business Activity Monitoring)
You may already have implemented BAM as part of your BizTalk Server solution to provide information on what has gone through BizTalk so that support staff can more easily answer queries when a potential issue occurs.
If you haven’t or have only partially implemented BAM then this is a good time to implement one, or enhance your existing BAM system.
My approach to BAM is to log all messages that flow through the system, including internal canonical messages and link them. This provides a full audit trail of when a message enters BizTalk to when a final message(s) exit BizTalk with all their internal canonical messages that are generated as well.
All fields in all messages are logged in BAM enabling searching on any field in any message. How long to keep these messages for will depend on your requirements. However, BAM has a ready built-in Archive and Purge feature which just requires configuration to remove old messages from BAM.
4. Exception Handling
Having a common Exception Handling approach is vital to the smooth running of a BizTalk Server. If you already have one, then that’s fine. However, if you don’t, and rely on messages going into the Suspended Queue in BizTalk then you may want to set up an Exception Handling system.
Some clients I have worked for over the past years have a multitude of Exception Handling systems. They’ve usually been implemented over time in different projects involving different BizTalk developers. Each developer usually having implemented a project-specific exception handling system.
However, having multiple exception handling systems with varying degrees of suitability and success takes up Production Support resources. Time is spent having to monitor multiple exception handling systems and maintain them.
The main features of any successful Exception Handling system are to prevent messages from entering the Suspended Queue – where large numbers can slow the BizTalk Server down – and store them in a separate database. There they can be analysed without affecting existing messages flowing through the BizTalk Server.
5. Technical Debt
All systems have a degree of technical debt which can affect the smooth running of a system but are tolerated as Production Support personnel have manual procedures or bespoke scripts to deal with them.
There are some who believe Technical Debt has a negative effect on developers morale in that developers see this as an imperfection in their work. More technical debt equals more dissatisfaction.
There are always periods in-between projects which can be put to good use, and here technical debt can be addressed and your systems made to run smoother. And you’ll make your developers happy at the same time!
Also if you are planning an in-place migration to Azure using the BizTalk Migration tool, which we have discussed before, then you will avoid migrating bad code and functionality to Azure.
Conclusion
Whether you are planning to migrate to Azure now, in the distant future or have no plans to migrate at all then making these improvements are still our top recommendations for making the most of your existing BizTalk Server solutions.
If you’re uncertain about going about this in-house, then why not get in touch with Ballard Chalmers. We are one of a few BizTalk experts in the UK, and our consultants would be happy to lend their expertise.
