Biztalk vs API for databroker layer

Question

My company is about to undergo a large project in which our client wants a large customer portal with a cms, crm implementing. This will require interaction with data from multiple sources across our customers business, these sources include XML office backend systems, sql datbases, webservices etc.

Our proposed solution would be to write an API in c# to provide a common interface with all these systems. This would be scalable for future and concurrent projects within the company.

Our client expressed an interest in using Biztalk rather than a custom API for this integration, as they feel it is an enterprise solution that any of their suppliers could pick up and use, and it will be better supported.

We feel that the configuration work using Biztalk would be rather heavy for all their custom business rules which are required and an interface for the new application to get data to and from Biztalk would still need to be written.

Are we right to prefer a custom API solution above Biztalk? Would Biztalk be suitable as a databroker layer to provide an interface for the new Customer portal we are writing. We have not experience with using Biztalk before so any input would be appreciated.

Answer 1

Reading your requirements, i would say you would want to focus on the business core parts. I.e. how to use the above mentioned services together. The topic where you want to spent as little as possible is 'the plumbing' of this.

BizTalk server will take away a large part of this plumbing for you. Instead of dealing with "how to guarentee consistency if normalization goes wrong" you will be dealing with "how to normalize the data".

BizTalk is also very 'future proof' in the sense that you can always add/remove/change systems in a BizTalk enviroment without the need to 'take it down for a change'. (within limits of course and if implemented correctly).

I would advise to reevaluate the "do it yourself" aprroach and see how much effort is needed if you would go the "do it yourself" way. Take a close look at the amount of "plumbing code" versus "core compentency code". Remember, after writting it, you have to maintain/bugfix it. BizTalk is a proven technology for hosting these kind of requirements.

From above description i would say; "BizTalk is likely the better option to choose".

Hope this helps,

Answer 2

When looking at the interface of BizTalk there is one major truth to realise;

'There is no interface'

BizTalk does not specify specific interfaces. It allows you to set up a "named message exchange pattern" (like Request-Response, OneWay, etc).

The incoming message is "Published" into BizTalk (by what we call a 'Receive Port'+'Receive location' combination). You can have an Orchestration (piece of business logic) or a SendPort (connection to external system->out) 'subscribe' to messages. This subscription can be based on context information or content information (although the later requires the information to be uplifted from the message content to the message context).

BizTalk therefore allows you to hook in any system at any given point of time by becoming a "Publisher" or "Subscriber" to messages. This can even be done when the system is fully up and running in production.

Any BizTalk project can still utilize the full .Net API on many locations, giving you the full power to write 'anything you could in plain .Net' also inside of BizTalk.

I would like to advise one thing though; "Please make sure at least one or two persons in your project team will get a BizTalk ramp-up/course". BizTalk is like a concealed gun; Extremely powerfull but dangerous in the wrong hands.