Message brokering across different systems, with transactionality and the ability to have fine tuned control over what happens using Java (or other languages), instead of a heavy, proprietary languages. One situation that it doesn't fit very well (as far as I have experienced) is when your workflow requires significant data mapping. While possible when using Java tooling, some other visual data mapping tools in other integration frameworks are easier to work with.
It is perfectly suited if some heavy operation needs to be automated where jobs can be queued up. Scalable app which is required to develop in a lesser time frame. Good for when users should be able to change rules more frequently without any downtime, like promotions. The server is well proven in the market. BizTalk server is the best fit if all other integration adapters are developed using Microsoft applications and if all applications are meant to be processed on a Windows environment.
BizTalk uses Microsoft Visual Studio as the IDE (integrated development environment) tool, and it's very easy to use.
The orchestration engine of BizTalk addresses resource issue very well for long-running business processes by dehydrating and rehydrating orchestration instances.
BizTalk is very easy to integrate if the development is mainly on the Microsoft software family.
Some of the documentation is a little sparse. In particular, its TCP-based routes use an underlying Netty server, and the interactions between Netty's decoder capabilities and Apache Camel's routing/handler capabilities can be a little muddy at times. In general it is clear which routes and endpoints are the more frequently used and which haven't been given as much attention.
BizTalk needs to be better at tracking down errors after the fact. Input files by default get deleted after processing successfully, unless you specifically specify that they don't. This can be an issue where you need to see what the input file contained, since you may have errors showing up in your target platform, in our case this was SAP.
BizTalk logging needs improved. It needs to be able to log the content of the messages it sends and receives. It would be good if the log had a link to the input and output files.
BizTalk needs to allow a simple way to preserve the input and output files for debugging purposes. A master setting on the orchestration would be helpful for this.
Microsoft BizTalk is not an intuitive product. It requires many hours of looking through the settings to achieve what you need. Using 3rd party DLLs is a nightmare as you are forced to register them in the GAC of the server and this process is quite cumbersome just to use a DLL.
BizTalk Server has been supported for more than 15 years. It is well proven in the market. Microsoft has provided excellent support with technical issues.
Apache Camel has been the integration framework of choice, but I was not the person to make the decision to use it. Compared to other competing products like Tibco Business Works, etc., it is free and open source and its licensing policy is acceptable to the management of Cox.
We did look at Jitterbit dataloader from Salesforce.com. Jitterbit seems like a pretty decent solution if you are doing a lot of uploads into Salesforce.com. However, its not nearly as flexible as Microsoft Biztalk is. Biztalk allows you to create any type of custom solution you wish, whereas Jitterbit is much more limited.
Very fast time to market in that so many components are available to use immediately.
Error handling mechanisms and patterns of practice are robust and easy to use which in turn has made our application more robust from the start, so fewer bugs.
However, testing and debugging routes is more challenging than working is standard Java so that takes more time (less time than writing the components from scratch).
Most people don't know Camel coming in and many junior developers find it overwhelming and are not enthusiastic to learn it. So finding people that want to develop/maintain it is a challenge.
