BizTalk Server isn't flexible for Canonical Schema. If there's only one schema sample and it doesn't match the case, the mapping will fail. When something has failed, the message doesn't specify what the problem is.

The deployment could be simplified. For the DLL and schema upgrades, it puts everything into individual folders, which we cannot maintain. We can do the application deployment in one shot. There's no dependency on other applications. If you have any references to other applications and if something goes wrong, the other application will not work.

In the 2007 version of BizTalk, the Orchestration Debugger showed exactly what was failing. If there's a mapping issue, we can't see what it is. It simply mentions that a file has failed because of a certain change. It would be helpful if it showed mapping. 

When we use a web service, we cannot identify exactly where the messages are flowing into the particular server and whether the certificate is expired. The support guide isn't updated properly for certificates. They're updated in the private repository. If this happens, we can't send particular services.

BizTalk Server needs to improve its performance. I'm not sure that we have the right infrastructure for this installation, but my previous experience when we were testing BizTalk and comparing it with web methods demonstrated that a huge flow of small messages actually frustrates BizTalk. 

The solution has to use external memory, which requires effort in the opening and closing of messages and connecting them. The bottleneck is something that is implemented internally, but this bottleneck is showing up when you are transmitting a lot of messages.

BizTalk is in the past, Microsoft is not going to evolve it any further or add any new features. 

The product could be improved in monitoring, managing, and support functionalities. Specifically, enhancements in monitoring and logging capabilities and better support for administrative tasks would be beneficial.

The product's deployment can be quicker 

BizTalk Server is an outdated legacy system that does not support messaging. 

Development is simple. I wish overall implementation and debugging were made simpler.

There is a follow-up version called Logic App which right now runs only in the Microsoft hosted Azure Cloud. We're just using JSON instead of XML which is very simple to administer and configure because it's a platform that's a server. You do not have to install anything. You just say I need some resources and Azure will do the rest for you. It's very easy to use. In Germany, however, there are very few customers using it because no one trusts putting data onto the Cloud. It's hosted by Microsoft, it's not hosted by a private cloud. That's a specific German problem, I know that the French are less restrictive, but in Germany, that's a big problem.

For future releases, I'm guessing Microsoft is trying to build out Logic App, but having another server with the tool which actually rewires the workflow and optimizes the workflow using a simplification operator would be a huge step ahead of all other opposing products, like Oracle, or Talend.

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.

Features which could be improved include sending JavaScript Object Notation (JSON) and receiver ports (which was added later).

• Support for JSON data
• Cross-platform support
• Not being tied down to SQL Server database