[ACCEPTED]-What are some viable alternatives to BizTalk Server?-biztalk

BizTalk Server's key benefit is that it 42 provides a lot of 'plumbing' around deployment, management, performance, and 41 scalability. Through Visual Studio, it also 40 provides a comprehensive framework for developing 39 solutions, often with relatively little 38 code.

The frustration and steep learning 37 curve that others mention often comes from 36 using BizTalk for the wrong purpose and 35 from a misunderstanding about how to work 34 with BizTalk and message-oriented systems 33 in general. The learning curve is not as 32 steep as most people suggest - the essential 31 part of the underlying learning actually 30 focuses on changing thinking from a procedural 29 approach to a stateless message-based approach.

A 28 drawback people often cite is cost. The 27 sticker price can seem to be quite high; however, this 26 is cheap in comparison to the amount you'd 25 spend on developing and supporting features 24 on your own.

Before you consider alternatives, or 23 even consider BizTalk server, you should 22 consider your organization's approach to 21 integration and it's long term goals. BizTalk 20 Server is great in cases where you want 19 to integrate systems using a hub and spoke 18 model where BizTalk orchestrates the activities 17 of many applications.

There are other integration 16 models too - one of the more popular ones 15 is a distributed bus (don't confuse this 14 with the term "Enterprise Service Bus" or 13 ESB). You can also get BizTalk to work as 12 a distributed bus and there are alternative 11 solutions that provide more direct support. One 10 of the alternate solutions is an open source 9 solution called nServiceBus.

When considering 8 whether to use a commercial product like 7 BizTalk, verses something else (open source 6 or developed in house), also consider maintenance 5 and enhancements and the availability of 4 the necessary skill-set in the marketplace.

I 3 wrote some articles that go into more detail 2 about the points I discussed here - here 1 are the links:

• Why BizTalk?
• Top 10 BizTalk Mistakes
• Extensibility Features in BizTalk Server
• Open Source Integration with nServiceBus

My experience with BizTalk was basically 10 a frustrating waste of time.

There are so 9 many edge cases and weird little business 8 logic tweaks you have to make when you are 7 doing B2B data integration (which is probably 6 the hardest part of any enterprise application) that 5 you just need to roll your own solution.

How 4 hard is it to parse data files and convert 3 them to a different format? Not that hard. Unless 2 you're trying to inject a bloated middleware 1 system like Biztalk into the middle of it.

As a BizTalk consultant I have to agree 9 at least partly with Eric Z Beard, there 8 are a lot of edge cases that take up alot 7 of time. But quite a few scenarios are handled 6 extremly smooth as well, so it all depends 5 IMO. But when you (Eric) call BizTalk bloated 4 I have to disagree! We've found that the 3 performance and reliability is excellent, it's 2 flexible and comes with a lot of good adapters 1 out of the box.

BizTalk needs to be used correctly, I am 22 a BizTalk developer and my experience with 21 BizTalk is quite good. Its reliable, performant, scalable, contains 20 a lot of built in architectural patterns 19 and build in components to make integration 18 easy and fast, you get security, retries, secondary 17 transports, validation, transformation etc... and 16 what ever you dont have build in with BizTalk 15 you can easily customized with .NET code, its 14 basically a hard earned integration system 13 and you get all this in one box. BUT you 12 need to know how to implement BizTalk correctly, not 11 once I came across solutions that where 10 implemented and often also architected incorrectly.

but 9 the real benefit of BizTalk is that you 8 can implement small solutions and scale 7 up whilst most other integration systems 6 from big vendors will only sell a whole 5 integration pack which can cost much more.

BizTalk 4 is considered the most complicated server 3 from the house of Microsoft.

So any body 2 saying BizTalk is not good dosent know BizTalk 1 period.

We evaluated BizTalk at our company and 30 were really disappointed.

We are using IBM 29 WebSphere Transformation Extender (which 28 has lots of (other) problems, too) and the 27 mapping tool of BizTalk is a joke in comparison 26 to WTX.

The graphical tool is not really 25 usable for complex mappings (we have schemas 24 with a few hundred fields in repeating groups) and 23 if you do more than the usual "concat first 22 name and last name to name" mappings, you 21 will be tired of the graphical approach 20 (for example the arguments of the functoids 19 in the graphical mapper are not labeled 18 and the order in which you connect fields 17 to these arguments is important).

The XSLT-Mapper 16 was usable but not really convincing, and 15 even the microsoft rep told us to use a 14 tool like XMLSpy for XSLT and load the resulting 13 XSL file into BizTalk.

A third approach to 12 mapping is to use C#-Code for the mapping, which 11 was not acceptable for us as a general approach 10 (we don't want to teach everyone C#).

In 9 addition to the mapping tool we did not 8 like the deployment in BizTalk. In order 7 to deploy your process, you need to make 6 lots of settings in different tools and 5 places. We had hoped to find a mechanism 4 like a WAR file for Java Web Applications 3 in BizTalk, so that you can give one archive 2 for your whole process solution to your 1 administrator and he can deploy it.

We've been using BizTalk since version 2004, and 40 now have a mix of versions 2006 R2 and 2004 39 running. I found that the learning curve 38 was quite severe, and development time for 37 solutions is not always quick. Those are 36 definitely shortcomings. Where BizTalk 35 really excels is in its fault tolerance, gauranteed 34 delivery, and performance. You can rest 33 assured that data will not get lost. Retry 32 functionality and fault tolerance robustness 31 is baked in so generally speaking if systems 30 are down BizTalk will handle that and successful 29 delivery will occur once systems come back 28 on line. All these issues such as downtime, etc 27 that are important in an integration scenario 26 are handled by BizTalk.
Further, generally 25 speaking when developing solutions BizTalk 24 abstracts the communication protocols and 23 data formats of the native systems by dealing 22 with everything as xml, so when developing 21 solutions, you typically don't have to wrote 20 code specific to those systems, you use 19 the BizTalk xml framework.

In the last year, we've 18 implemented a java open source engine called 17 Mirth for our HL7 routing. I found that for 16 HL7 purposes, the HL7 adaptor for BizTalk 15 is a challange to work with. Management 14 dicated that we use Mirth for HL7 routing. Where 13 BizTalk falls down in terms of learning 12 curve, Mirth makes up. It is far easier 11 to develop a solution. The problem with 10 mirth is that it doesn't really have any 9 gauranteed delivery. Most of the adaptors 8 (except for hl7) have no retry functionality 7 so if you wanted that you'd have to write 6 your own. Second, Mirth can lose date if 5 it goes down. I would call it very easy 4 to use (although there is no documentation) but 3 I'd be hard pressed to call it an enterprise 2 solution. I'm going to check out jitterbit which 1 was mentioned by someone else.

We used BizTalk for a couple of years, but 2 gave it up for our own custom framework 1 that allowed more flexibility.

There is always Sun's (now Oracle) OpenESB framework. Its 4 generally speaking a smaller, lighter version 3 of Biztalk but with roughly all the same 2 features.

You do get to write more code 1 with it, though.

Its Open Source as well.

In the OSS space (though I've never used 8 them as a BizTalk replacement personally 7 - this is anecdotal) you can use one of 6 the Java/J2EE Messaging engines such as 5 OpenMQ (which is the Sun enterprise one rebadged 4 and without support). If you need Orchestration 3 / Choreography (i.e. SOA/ESB pieces) on 2 top of this, you could look into something 1 like Apache Mule

My experience with BizTalk and doing B2B 14 integrations is that most organizations 13 do not truly do schema first design or fully 12 understand xml standards for that matter. Most 11 tend to weave objects and hope they materialize 10 into meaninful schemas. In an enterprise 9 environment, this is backwards.

BizTalk does 8 have a learning curve, but once you get 7 it you are rewarded with durability, performance, true 6 scalability, and extensibility. Like most 5 have said though, it best to make sure it 4 meets your needs and contort your needs 3 to BizTalk.

In the past I have worked with 2 BizTalk 2004 through 2009, and another product 1 called webMethods.

I have no direct experience with JitterBit, but 1 I have heard very good things from coworkers.

I came across Apatar (unable to post url, but 6 Google finds it) while looking for a solution 5 cheaper than BizTalk. I have yet to try 4 this out.

My last company had many problems 3 with BizTalk being too complex and ridged, but 2 I can’t help but think this was mainly down 1 to the implementation the consultant did.