CODEWITHSUNDEEP
integrationbiztalk
Eric Maibach
Eric Maibach

Reputation: 328

Is BizTalk The Correct Solution?

We have about about six systems (they are all internal systems) that we need to send data between. Currently we do not have a consistent way of doing this. We use SSIS, SQL Server linked servers to directly update databases, ODBC connections to directly update databases, text files, etc..

Our goals are:

1) Have a consistent way of connecting applications.
2) Have a central way of monitoring and logging the connections between applications.
3) For the applications that offer web services we would like to start using them instead of connectiong directly with the database.

Whatever we use will need to be able to connect to web services, databases, flat files, and should also be able to accept data via a tcp connection.

Is Biztalk a good solution for this, or is it is overkill?

Upvotes: 0

Views: 1377

Answers (3)

Saravana Kumar
Saravana Kumar

Reputation: 596

You problem is a typical enterprise problem. Companies start of building isolated applications like HR, Web, Supply Chain, Inventory, Client management etc over number of years and once they reach a point these application cannot be living alone and they need to talk to each other, typically they start some hacked solution like data migration at database level.

But very soon they realize the problems like no clear visibility, poor management, no standards etc and they create a real spaghetti. The biggest threat is applications will become dependant on one another and you lose your agility to change anything. Any change to system will require heavy testing and long release cycle.

This is the kind of problem a middleware platform like BizTalk Server will solve for you. Lot of replies in the thread focused on cost of BizTalk server (some of the cost mentioned are not correct BTW). It's not a cheap product, but if you look at the role it play in your organisation as a central middleware platform connecting all the applications together and number of non-functional benefits you get out of the box like adapters to most of the third party products like SAP, Oracle, FTP, FILE, Web Services, etc, ability to scale your platform easily, performance, long running work flows, durability, compensation logic for long running workflows, throttling your environment etc., soon the cost factor will diminish.

My recommendation will be take a look at BizTalk, if you are new then engage with local Microsoft office. Either they can help or recommend a parter who can come and analyse your situation.

Upvotes: 1

StuartLC
StuartLC

Reputation: 107317

From what you've described (6 systems), it is definitely a good time to investigate a more formalized approach to integration, as you've no doubt found that in a point to point / direct integration approach will result in a large number of permutations / spaghetti as each new system is added.

BizTalk supports both hub and spoke, and bus type topologies (with the ESB toolkit), either of which will reduce the number of interconnects between your systems.

To add to oɔɯǝɹ:

  1. Yes - ultimately BizTalk converts everything to XML internally and you will use either visual maps or xslt to transform between message types.
  2. Yes. Out of the box there are a lot of WMI and Perfmon counters you can use, plus BizTalk has a SCOM management pack to monitor BizTalk's Health. For you apps, BAM (either TPE for simple monitoring, but more advanced stuff can be done with the BAM API).
  3. Yes - BizTalk supports all the common WCF binding types, and basic SOAP web services. BizTalk's messagebox can be used as a pub / sub engine which can allow you to 'hook' other processes into messages at a later stage.

Some caveats:

. BizTalk should be used for messages (e.g. Electronic Documents across the organisation), but not for bulk data synchronisation. SSIS is a better bet for really large data transfers / data migration / data synchronisation patterns.

. As David points out, there is a steep learning curve to BizTalk and the tool itself isn't free (requiring SQL and BizTalk licenses, and usually you will want to use a monitoring tool like SCOM as well.). To fast track this, you would need to send devs on BizTalk training, or bring in a BizTalk consultant.

. Microsoft seem to be focusing on Azure Service Bus, and there is speculation that BizTalk is going merged into Azure Service Bus at some point in future. If your enterprise strategy isn't entirely Microsoft, you might also want to consider products like NServiceBus and FUSE for an ESB.

Upvotes: 1

oɔɯǝɹ
oɔɯǝɹ

Reputation: 7625

It really depends. For the architecture you're describing, it would seem a good fit. However, you will need to validate wether biztalk can communicate whith the systems you are trying to integrate. For example; when these systems use webservices, message queues or file based communication, that may be a good fit.

When you start with biztalk, you have to be willing to invest in hardware, software, en most of all in learning to use it.

regarding your points: 1) yes, if you make sure to encapsulate the system connectors correctly 2) yes, biztalk supports this with BAM 3) yes, that would match perfectly

Upvotes: 2

Related Questions