Почему EDI все еще используется, и как иметь дело с ним?

EDI был вокруг еще до XML. Кроме того, что две стороны могут предварительно согласовать формат EDI, который работает на них обоих, необходимо также рассмотреть часть ФУРГОНА (сеть с дополнительными услугами.)

В некоторых случаях ФУРГОН выполняет проверку сообщения, или даже читает сообщение и выполняет действия с ним, такие как копирование его дополнительным сторонам на основе его содержания.

единственная причина действительно для использования EDI состоит в том, потому что "это - способ, которым это всегда делалось", и поэтому существует много существующей инфраструктуры вокруг для поддержки его. Почему переключатель к XML, когда нет никакой потребности? И как должен сказать привычку XML быть замененным JSON, который будет затем заменен чем-то еще?

Одно решение, хотя это будет стоить Вам, состоит в том, чтобы перейти к компании как ADX, который имеет инструменты, которые можно использовать для преобразования форматов EDI в более приятные форматы как CSV. В зависимости от объема и типа транзакций Вы делаете, это может быть и доступно и намного менее напряжено. Я использовал их продукты в прошлом и в то время как они - немного работы для установки, они действительно работают кавычка хорошо и очень стабильны. Из-за истории EDI Вы могли, вероятно, найти сотни других компаний, которые предлагают подобные услуги.

EDI является плодовитым во многих отраслях промышленности. Было бы непомерно дорого заменить уже рабочую технологию более новой.

Рассматривают это, Walmart использует EDI для общения с его поставщиками, хранилищами, цепочкой распределения, и т.д. Я предполагаю, что они имеют дело с tenss тысяч поставщиков. Каждые из них снизили тысячи долларов в технологию EDI. Если Walmart решил переключиться на XML, это - решение, которое влияет на тысячи компаний, не просто Walmart.

Это верно для любого пользователя EDI. В конце концов, это - стандарт, используемый между торговыми партнерами.

я соглашаюсь, EDI является болью для работы с. Но 'назад в день', это - все, которое мы имели.

Я должен был использовать EDI также, и я соглашаюсь. Мы использовали BizTalk для отображения его, который работал хорошо. Многие система основаны на EDI (задолго до XML).

Поддержка прежней версии

"Если это не, повредился, не фиксируйте его".

большинство этих организаций обрабатывает огромное количество данных с помощью EDI и не собирается измениться на что-то более современное без неопровержимого довода. И создание вещей, легких для сторонних разработчиков, обычно не квалифицирует, печальный сказать.

Поскольку это - официально установленный Стандарт (на самом деле очень большой и исчерпывающий набор стандартов). И это - одно из требуемых преимуществ стандарта - Вы ничего не должны будете изменять в течение долгого времени.

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

форматы EDI имеют намного более высокие отношения сигнал-шум (потому что они были разработаны назад, когда это считали важным.) Кто-то, кто знает и понимает EDI, посмотрит на Ваш XML и скажет, "Где говядина (данные)?"

Очень немного разработчиков пишут свои собственные синтаксические анализаторы. Существует много хороших доступных картопостроителей (и много и корпоративных приложений прежней версии идут с ними, встроил). Таким образом, существует большое облегчение, доступное для Вашей боли (включая по крайней мере одно приложение С открытым исходным кодом на SourceForge).

И переключение на XML дало бы Вам что - немного более легкое для отладки формата строки?

Обычно Вы настраиваете его и оставляете его, нет большого количества потребности играть с необработанным каналом EDI, конечно, недостаточно отказаться от стандарта и запуститься снова.
существует много стандартов, как ФАКС, который мог быть сделан более читаемым, но никакая реальная срочная необходимость изменить их.

Немного информации для всех заинтересованных. EDI является в основном дизайном формата обмена данными комитета, который не только излагал правила в форматирование данных (как XML), но также и изложенный для определения каждого документа, который мог возможно когда-либо отправляться между 2 компаниями. Таким образом для любой части данных, которые могли быть переданы между компаниями, они придумали точное определение того, какой, как предполагалось, был в каждом из этих документов. Конечно, никто не мог предвидеть каждую часть данных, которыми 2 компании захотят обмениваться. Таким образом, Вы заканчиваете с полями использования компаний, которые были определены для 1 вещи, используемой для некоторой другой информации.

то, С чем Вы закончили, является чрезвычайно замысловатым форматом данных, в котором многие люди, использующие его, не следуют стандартам, потому что они должны отправить пользовательскую информацию, которую не составляет стандарт. Таким образом в конце, все еще необходимо говорить с каждой компанией, Вы хотите иметь дело с и узнать все небольшие особенности их реализации, как необходимо было бы сделать, если бы Вы перешли к кому-то с пользовательским интерфейсом XML. За исключением того, что в случае EDI, формат трудно проанализировать и еще тяжелее записать хорошо, таким образом, Вы заканчиваете тем, что делали целый набор работы только для отправки документа, когда выполнение того же отчасти думает с наличием пользовательского решения XML, привел бы к много раз меньшему количеству проблем.

Можно интересоваться следующим проектом:

http://bots.sourceforge.net/en/index.shtml архив кода Google

Одно слово, Инерция. Разработка форматов EDI комитетом между различными компаниями и организациями с различными программами была кошмаром (печальный сказать, что я был там).

Просьба, чтобы они отказались от них с еще одним раундом комитетов, согласовав веб-сервис, который стандарты API собираются взять еще дольше, как Вы продаете идею заменить один электронный формат другим к нетехнической плате? Что делает возможное преимущество busness оно дает им. Первоначально преимущества электронного обмена были ясны, но заменяют один другим, не. Мы говорим действительно крупные компании здесь.

EDI является очень компактным форматом и часто используется для хранения использования пропускной способности в обменах данными как можно меньше. Немецкие таможни, например, используют его в своей системе ATLAS для обмена очень большим объемом данных каждый день.

трудно проанализировать и трудно читать, но если размер получающихся вопросов данных, это может быть хорошим выбором и поддерживается большинством больших бизнес-приложений.

Другая причина в том, что это деловые сообщения, такие как заказ. счета-фактуры, кредитовые авизо и т. д. транзакции имеют большую финансовую ценность, и они должны быть безопасными, но, что, возможно, более важно, они должны иметь сквозную проверку и проверку, а также защиту от отказа.

Например, я отправляю вам заказ если товар стоит 1/2 миллиона евро, вы отправляете мне товар, а затем я «теряю» информацию о заказе и говорю вам, что не плачу. Комбинация стандартов и VANS делает это практически невозможным или, по крайней мере, с таким большим количеством контрольного журнала, что проблемы можно было отследить. Вот почему «О, давайте использовать xml и Интернет вместо EDIFACT и VANS», как правило, терпят неудачу. Как кто-то ответил: «Инерция, но это инерция, основанная на стабильном, эффективном, безопасном, надежная и хорошо изученная система.

Сделать это по дешевке - не всегда вариант.

Если это хоть какое-то утешение, когда я впервые реализовал EDI в 1987 году, практически не было программного обеспечения, поэтому я получил таблицы Interbridge и написал свой собственный парсер для британского стандарта TRADACOMS с использованием программного обеспечения Cognos и HP Mini, и он отлично работал. Предполагая, что вы торгуете с другими партнерами EDI, затраты, вероятно, связаны с необходимостью использования VAN.