Is BizTalk the "correct" technology for this problem?

Question

I'm currently working on a solution that involves the following work flow:

1. System sends out an email which includes some kind of identifier/sessionID.
2. User replies to email.
3. System receives reply, and parses email for sender, identifier, and user response.
4. System queries a sql database to retrieve some information based on the user response and then inserts some data.
5. System then performs a http post to a web page that belongs to another system.

So my question is, is BizTalk the correct technology for all or part of this solution? Why or why not? If not, what would be the appropriate technology be?

In this case the business has already decided on the use BizTalk, so I would need to justify a negative answer. We have other BizTalk solutions already in place, so the product and time cost of configuring an initial BizTalk server setup does not factor here.

Thanks.

Edit: It would be fair to say that the use of BizTalk is open to discussion, more so than my question makes it seem. I'm more interested in knowing if it's an appropriate use of technology or a kludge just based on your gut feeling given the problem domain.

Answer 1

I'd say you've answered your own question. Yes, Biztalk can be made to work. Whether it's best or not has already been determined by your management. To truly evaluate the complexity and scope of implementing this, we'd need a lot more info about your infostructure, business process, anticipated volumes, variety of email sources and servers, etc.

Answer 2

As you have stated in your question itself, the scenario is of a workflow solution.

You could either use WF or BizTalk depending on how you want to implement and manage it but

BizTalk offers the following advantages over WF

• BizTalk has extensive line of adapters and pipeline components that are often a must-have for cross-platform Enterprise Application Integration (EAI).

• BizTalk provides tools for working with trading partners such as Business Activity Services (BAS), accelerators for industry standards (RosettaNet, SWIFT
  etc.). These features make BizTalk
  more suitable for B2B scenarios.

• Other features that BizTalk has but
  WF doesn't or has to be implemented
  by developer)

• Tracking: natively integrated
  wtih the Business Activity
  Monitoring (BAM) Transaction:
  supports both atomic transaction and long-running transaction
  Extensive set of tools for admin,
  management, migration and scaling (However, all this changes with Dublin!!!)

Having read your requirements once again, I think that your application doesn't fall into either the B2B or EAI categories, so BizTalk is probably an overkill. But you have also mentioned that your business already has other BizTalk solutions in place, so just using BizTalk for workflow might be one way to stay away from addding more layers to the technology stack.

Answer 3

I build applications like that all the time. All you need to do is create a Windows Service that performs those actions. For the run-down.

• System sends out an email which includes some kind of identifier/sessionID.

.NET's built-in SMTP client

• User replies to email.

You need some sort of email server, doesn't matter what kind.

• System receives reply, and parses email for sender, identifier, and user response.

Use IndySockets to read the email account.

http://www.indyproject.org/Sockets/index.EN.aspx

• System queries a sql database to retrieve some information based on the user response and then inserts some data.

System.Data or your favorite ORM.

• System then performs a http post to a web page that belongs to another system.

System.NET has methods for making an HTTP post.

From that list I can say with absolute certainty that everything you are doing will be easier without BizTalk (not to mention cheaper in terms of money, memory, and CPU utilitization).

Answer 4

Biztalk is never the best choice if you ask me.

You will need a lot more development time. You will need special developer skills. It will be harder to change your application down the road. You can't be agile. Deployment is awful. And on top of all that it's ridiculously slow at what it does.

But it looks good on the architecture powerpoint..