A Piece of Advice for today's BizTalk Developers

Recently, Microsoft announced that the schemas used with BizTalk server are now open source code. Released last year, BizTalk 2016 turns out to be an enterprise integration server for orchestrating various applications and services. In fact, all the schemas used with the product, representing 3539 files are now housed in this GitHub open source repository. Anyone can access them. The company is now accepting open source code contributions and not just for schemas. Due to which developers can also contribute code for BizTalk servers "Samples, Adapters, pipeline components or anything else you feel the community can take advantage of," – explained by Microsoft

BizTalk administration and development are some of the most overlapping areas for any BizTalk development company. But at the same time, the two are competent enough when it comes to disciplines. Unfortunately, most consultants focus on one area creating unsatisfactory solutions while a very few master in both disciplines. For this, having a brilliant professional is not worth much especially if the operation side is neglected or vice versa.

Having done some development myself, but mainly administrations and operations for more than a decade now, here I would like to offer you a small piece of advice that will help you throughout your development career.

Consider the performance of your solution- In any BizTalk development project, performance aspect is often forgotten. The solution may run on a dev box during development, but will often run for years in production. One bad solution can affect the performance and stability of others. Hence, it is very important to consider the performance of your solution. To be very precise, try keeping the number of persistence points to a minimum, reduce hops to the MessageBox, use XPath only when necessary, use streaming when applicable, use PassThru pipelines if possible, and don't rely on extensive use of tracking. Basically, do not choose easy solutions that will negatively affect runtime performance.

For example- One solution was deployed to production, and it started being consumed in large amounts. As a result, the entire environment went down. It had to be stopped, and later completely redesigned.

Use the features provided by BizTalk- Are you a code monkey? If not, then this tip is not for you. BizTalk comes with a vast collection of features, use them. There are developers who love to write code and overuse expression shapes, code libraries, etc. During such situation, the built-in features of BizTalk will perform and scale better than custom code.

Apart from this, there are several other interesting features which are rarely used such as Backup Transport and Compensation. So when creating error handling, use routing for Failed Messages and don’t forget to include BAM so your business users can track messages. On the flipside of this tip, there are certain features which must be avoided, for instance, deprecated features (SOAP adapter, old SQL adapter etc.). And as always, do not spam the eventlog!

For example- One C# developer included all the functionality of a workflow in one or more expression shapes. The expression shapes were initially used to call various code libraries.

Make use of BizTalk administrator- A dedicated and experienced BizTalk administrator knows very well regarding topics like integration, architecture, servers, performance tuning and more. Make use of that! Now, there are times when your solution will have some specific requirements that differ from others.

For example- While developing synchronous solutions with such requirements, it may be beneficial to create a dedicated host (and host instances) for this purpose. Use your BizTalk administrator to identify other bottlenecks and possible solutions. Ask him what is required and to what detail. This will help ensure a smooth deployment to environments where developers do not have access.

Perform peer reviews- Developers, in general, are required to have reviews of their own. So, that possible problem can be corrected before proceeding. At a minimum, a review must be performed before deployment to Production. I recommend having the following review intervals:

• Solution Design Approval
• Pre-QA
• Pre-Prod

Don’t forget to include sections for BizTalk administrations in such reviews. However, several checklist items can be automated, and should not take very long. This time is a useful and necessary investment to reduce issues and errors.

For example- One client had maintenance hours late in the evening when very few people were at work. Now all the deployments had to be done in the evenings. As a result, instructions weren’t adequate, binding files were not updated, port passwords not available. BizTalk developers will be called to solve these issues which ultimately caused delays and added man-hours.

Security aspect- One of the most important point is to increase security. Unfortunately, there are professionals who believe increasing security often increases the development time, cost and complexity. So they try avoiding this while others do not care about a solution after it is deployed. Moreover, business users often do not understand this aspect and do not want to pay for it. Therefore, it is considered as an area where BizTalk administrators are required to have a strict regime. But here is my opinion on when to encrypt data: When it can't be published on the front page in the paper.

Nishtha Singh works as a Presales Manager with a software development company named TatvaSoft UK. She relishes writing about various technology trends, management and much more.