Я работаю над разработкой системы EDI для двух компаний: компании A и компании B. Компания A уже существует как небольшое производственное предприятие, а компания B - это новая компания, созданная вокруг определенного продукта с участием владельца компании A. . Компания А будет иметь исключительные права на производство продукции для компании Б.

Я отвечаю за все ИТ и развитие в обеих этих компаниях. Мне нужно разработать систему EDI для передачи заказов и другой информации от компании B компании A и наоборот (для подтверждений, обновлений статуса и т. Д.).

Этот тип вещей является для меня довольно новым, поэтому я просто ищу совета о том, как отправить новый заказ из компании B в компанию A и гарантировать, что он будет там, сохранен и не будет отправлен более одного раза. .

Я думаю, что, вероятно, сделаю это с помощью веб-сервисов. Должен ли я изучить службы WCF или придерживаться веб-служб ASP.Net?

Я предполагаю, что я отправлю уникальный идентификатор с каждым заказом, чтобы система компании A распознала, чтобы не сохранять его дважды, если есть путаница, но как я могу точно узнать, что компания A получила информацию?

Любые другие советы или рекомендации более чем приветствуются.

2
Max Schmeling 4 Авг 2009 в 00:17

2 ответа

Лучший ответ

См. Microsoft: веб-службы ASMX являются «устаревшей технологией» чтобы узнать, почему бы не использовать веб-службы ASMX.

Разве заказы уже не имеют какой-то уникальной идентификации?

В любом случае служба в компании A захочет обеспечить безопасную регистрацию заказа (возможно, в базе данных), и только после этого операция «Отправить заказ» будет завершена.


В компании А я бы создал службу обработки заказов. Пока что нужен только один метод: AcceptOrder. При этом будет принята вся информация, необходимая для обработки заказа. Эта операция сначала сохранит заказ в базу данных, а после того, как данные будут безопасно сохранены, вернет какой-то код подтверждения.

Попытка отправить тот же заказ снова не удастся, потому что вы сохраните уникальный ключ над уникальным идентификатором заказа от компании B.

Мы собираемся доверять нашей базе данных, поэтому, как только мы узнаем, что данные были зафиксированы, можно было безопасно ответить «мы получили!»

Также могут быть использованы другие технологии. Очередь транзакций, например, с использованием MSMQ. Он будет иметь такое же преимущество, как если бы он сказал, что у него есть данные, вы можете доверять тому, что у него есть данные.

2
John Saunders 4 Авг 2009 в 00:39
Я понимаю, но как мне сказать, что он завершен? Могу ли я просто вернуть код подтверждения, чтобы он знал, что он сохранен, и прекратить его действие?
 – 
Max Schmeling
4 Авг 2009 в 00:30
Я просто не хочу, чтобы была какая-либо возможность того, что компания B попытается отправить заказ, думая, что он был отправлен и сохранен, но компания A на самом деле не получает его записи.
 – 
Max Schmeling
4 Авг 2009 в 00:31
Я бы вернул какой-то код подтверждения, когда метод вернется. Но я не вернусь, пока строка не будет зафиксирована в базе данных.
 – 
John Saunders
4 Авг 2009 в 00:35
Ладно, я думаю, я просто пытался сделать это слишком сложным ... на самом деле нет причин делать что-то более сложное, чем это ... спасибо
 – 
Max Schmeling
4 Авг 2009 в 00:38
1
@quillbreaker: вы не можете быть серьезным, иначе вы не заметили различий между ASMX и WCF. И это не новость. Написание было на стене с тех пор, как WCF был представлен как очевидная замена ASMX, WSE и .NET Remoting. И не забывайте, что ASMX был с нами со времен .NET 1.0. Это довольно "наследие", как "наследие".
 – 
John Saunders
4 Авг 2009 в 01:19

Отправьте уникальный идентификатор с вызовом веб-службы, и веб-служба вернет уникальный код подтверждения и статус заказа. Это должно вас в значительной степени покрыть. Если вы хотите, вы можете добавить метод статуса запроса в веб-службы, чтобы вы могли видеть, был ли заказ отправлен ранее.

1
Jeffrey Hines 4 Авг 2009 в 00:37