First of all, it’s the concept of orchestrations which extends the tool from simply being responsible for “fire-and-forget” messaging pattern to a more powerful one allowing you to implement some sophisticated business processes. It may even use long running transactions. Apart from that, as a useful feature there can be pointed out, is a concept of various adapters. These adapters operate independently from orchestrations and mappings between initially created source and target schemas and it prevents from extra effort when modifications in data structure are required.
The product stood out as a really helpful solution when we came upon a problem of increasing the number of relationships between corporate systems, naturally causing an increase in expenses required to maintain the existing infrastructure. This is extremely important if any new system is introduced to corporate infrastructure. It only requires a BizTalk connection instead of solving connectivity problems with a bunch of other systems.
Regarding some areas which can be potentially revised or improved, it should be said about debugging process, especially for class libraries, as it is not so user-friendly or easy to set-up. Also, the default receive and send pipelines perform well, but it would be great if these pipelines can treat XML by default irrespective of namespaces. In this case, no additional settings (like “Qualified”) should be required in order to prevent data losses when transmitting the data from source scheme to target scheme within BizTalk. But, these items are not so critical when compared with some performance issues which can take place within projects of really significant functional volume. In such cases even the possibility to perform load balancing by introducing additional host instances and assigning applications to it may not appear to be a relief.
