BizTalk Server needs improvements, especially because we use it for EDI messaging, and it would be very useful to have enhanced tracking capabilities for message tracking and archiving of messages. There is no built-in functionality for this, and you have to organize it yourself by storing files, storing messages to the file system and maintaining tables for registering the messages that went through. Other systems or vendors are offering special message tracking capabilities. The scalability should be improved as it currently rates at six out of ten.
BizTalk is deployed on-premise. Deployment methodologies are vast in the cloud area. Whereas, if we want to update even a single thing on BizTalk, we need to take the DLL, put it in the system, and restart the host. Updating things in BizTalk is a headache. Sometimes, if we don't refresh and restart the host, the change will not reflect. These are minor loopholes that I've been seeing in the tool.
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.
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.
BizTalk Server needs improvements, especially because we use it for EDI messaging, and it would be very useful to have enhanced tracking capabilities for message tracking and archiving of messages. There is no built-in functionality for this, and you have to organize it yourself by storing files, storing messages to the file system and maintaining tables for registering the messages that went through. Other systems or vendors are offering special message tracking capabilities. The scalability should be improved as it currently rates at six out of ten.
BizTalk is deployed on-premise. Deployment methodologies are vast in the cloud area. Whereas, if we want to update even a single thing on BizTalk, we need to take the DLL, put it in the system, and restart the host. Updating things in BizTalk is a headache. Sometimes, if we don't refresh and restart the host, the change will not reflect. These are minor loopholes that I've been seeing in the tool.
The product's deployment can be quicker
BizTalk Server is an outdated legacy system that does not support messaging.
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.
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.