Почему EDI все еще используется и как с этим бороться?

Ответ 1

EDI не так сложно понять, как только вы познакомитесь с разделителями, которые он использует. Вы также можете спросить себя, почему кто-то все еще будет использовать CSV или данные с разделителями табуляции.

Вероятно, ответ заключается в том, что эти форматы являются "специфическими для домена языками", определенными комитетом и стандартизованными в определенной отрасли, и что много денег уже было инвестировано в поддержку этих форматов. Где бизнес-кейс снова выкинет все это?

Ответ 2

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

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

Ответ 3

Вам может быть интересен следующий проект:

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

Ответ 4

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

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

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

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

Ответ 5

И переход на XML даст вам что - немного проще отладить формат строки?

Как правило, вы настраиваете его и оставляете, нет необходимости играть с исходным фидом EDI, чего, конечно, недостаточно, чтобы отказаться от стандарта и начать снова.
Существует множество стандартов, таких как FAX, которые могут быть более читабельными, но без реальной необходимости их изменять.

Ответ 6

"Если он не сломался, не исправляйте".

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

Ответ 7

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

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

Ответ 8

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

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

Ответ 9

ИМХО существует несколько проблем с ЭДИФАКТ.

• Нелегко разобрать или сгенерировать объектную модель. Вероятно, это уже не большая проблема, так как теперь есть хорошая система, которая делает это для вас, например. smooks.org
• Это непросто читать. Вы привыкли, но XML намного легче читать.
• Проверка не так проста (сравните это с проверкой XML)
• Существует слишком много разных версий и вариантов, D95B, D96B, D00A, D00B и т.д.
• Но я думаю, что самая большая проблема заключается в том, что все используют стандарты по-разному. Они используют один и тот же "формат", но поля определяются по-разному. Мы используем ЭДИФАКТ для отправки и получения сообщений от Контейнерных терминалов, и все они имеют небольшие отличия. Они будут, например, все используют D95B CODECO, но для некоторых терминалов определенный сегмент является обязательным, а для другого он необязателен или даже не разрешен. Затем у вас есть сегменты, которые используются одинаково, но содержимое в нем отличается.

Итак, резюмируем это: это боль в шее.

Ответ 10

Поддержка Legacy

Ответ 11

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

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

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

Я согласен, EDI - это боль для работы. Но "назад в тот день", все, что у нас было.

Ответ 12

Edifact - один из лучших стандартов, когда дело доходит до обмена документами. Большинство проблем исходит от торговых партнеров, отправляющих нестандартные документы.

Да, это немного странный формат и утомительно работать, если вы не знаете входы и выходы, но также и для XML.

Вам действительно нужен XML над Edifact? Посмотрите на раздутые, трудно читаемые стандарты XML peppol (общеевропейские публичные закупки в Интернете), над которыми работает.

Да, он работает красиво и денди, если у вас нет ошибок в системах, устранение неполадок edifacts намного проще, если вы привыкнете к формату, чем устраняете ошибки в документах UBL.

Вы говорите, что у вас есть $0.00 для использования в проекте? Вы действительно должны изучить объем ручной работы, выполняемой в вашей компании, и затраты, которые EDI может предложить, может быть очень полезным.

Ответ 13

Какие типы информации могут быть обменены через EDI?

В EDI доступны различные типы обмена деловой информацией:

- • Информация для бронирования

- • Информация о коносаменте

- • Фактурирование

- • Электронный перевод средств

- • Информация об уведомлении о прибытии

- • Информация о состоянии отправки

Как выбрать EDI для моей компании? - • Он упрощает процесс связи между вами и APL

- • Это исключает необходимость повторной передачи данных, устраняя при этом ошибки и необходимость перепроверять информацию

- • Это исключает обработку бумаги и необходимость хранения документов

- • Улучшает время поворота и точность ваших данных.

- • Это устраняет необходимость отправки факсов

Ответ 14

EDI существует уже до XML. Помимо того факта, что две стороны могут предварительно согласовать формат EDI, который работает для них, вы также должны рассмотреть часть VAN (сеть с добавленной стоимостью).

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

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

Ответ 15

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

Ответ 16

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

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

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

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

Ответ 17

Я использовал EDI (ANSI X12 и EDIFACT) в двух проектах о морской транспортной логистике и нашел, что они очень полезны, поскольку большинство перевозчиков Ocean и торговых партнеров принимают их в качестве стандартного способа связи между их различными системами.

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

Ответ 18

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