How should I go about guaranteeing that a "message" is sent and stored once and only once?

Question

I'm working on designing an EDI system for two companies: Company A and Company B. Company A already exists as a small manufacturing business, and Company B is a new company formed around a specific product with the involvement of the owner of Company A. Company A will have exclusive rights to produce the product for Company B.

I'm responsible for all things IT and development with both of these companies. I need to design an EDI system for communicating orders and other information from Company B to Company A, and vice-versa (for confirmations and status updates, etc).

This type of stuff is fairly new to me, so I'm just looking for advice on how to send a new order from Company B to Company A and guarantee that it gets there, is stored, and doesn't get sent more than once.

I'm thinking I'll probably do this with web services. Should I look into WCF services or stick with ASP.Net web services?

I assume I'll send a unique ID with each order so Company A's system will recognize not to save it twice if there is a mix up, but how do i know for sure that company A got the information?

Any other tips or advice is more than welcome.

Answer 1

See Microsoft: ASMX Web Services are a “Legacy Technology” to learn why not to stick with ASMX web services.

Don't the orders already have some unique identification?

At any rate, the service at Company A will want to ensure the order is securely recorded (perhaps in a database), and only then will the "Send an Order" operation complete.

---

At Company A, I'd create an order processing service. So far, it would only need one method: AcceptOrder. This would accept all of the information necessary to process an order. This operation would first save the order into a database, and once the data are safely stored, would return some sort of confirmation code.

An attempt to send the same order again would fail, because you'll keep a unique key over the unique order identifier from Company B.

We're going to trust our database, so that once we know the data have been committed, it's safe to respond "we've got it!"

Other technologies could also be used. A transactional queue, for instance, using MSMQ. It would have the same benefit that, once it says it has the data, you can trust that it has the data.

Answer 2

Send a unique ID with the web service call and have the web service return an unique confirmation code and order status. That should pretty much cover you. If you want you could add an query order status method in the web services to allow you to see whether an order has been previously sent.