Если вы поставляете товары крупному ритейлеру или автомобильному концерну в Европе, вы работаете через EDI. Не потому, что кто-то обожает синтаксис EDIFACT, а потому, что формат выбирает сторона с более крупным отделом закупок, а её формат был стандартизирован в 1988 году. Ждать, пока они предложат REST API, - не стратегия.
Как на самом деле выглядит современная настройка EDI
Хитрость в том, чтобы рассматривать EDI как диалект транспортного уровня, а не как архитектуру. Внутри интеграции всё представлено простым, строго типизированным объектом заказа/отгрузки/счёта; EDIFACT и X12 существуют только на самом краю - в трансляторах, которые просты, версионированы и тщательно покрыты тестами на реальных примерах файлов.
Это разделение окупается тремя способами:
- Подключение нового торгового партнёра означает новый профиль транслятора - версию сообщения, особенности сегментов, их творческое использование текстовых полей, - а не новую бизнес-логику.
- Тестирование воспроизводимо. Каждый когда-либо полученный файл партнёра становится тестовым примером. Когда транслятор меняется, мы прогоняем через него пять лет трафика и сравниваем результат.
- 20-летняя ERP и совершенно новый интернет-магазин видят один и тот же объект заказа, поэтому заказы из EDI и из API проходят через один конвейер по одним и тем же правилам.
Непримечательные детали, которые имеют значение
Подтверждения - это половина протокола. Партнёр, не получивший сообщение CONTRL в отведённое окно, решит, что заказ пропал, и позвонит вашему отделу продаж. Отслеживайте задержку подтверждений так же, как отслеживаете аптайм, - это метрика, которую реально ощущает менеджер по закупкам вашего клиента.
EDI - это не технический долг. Это инфраструктура - как ширина железнодорожной колеи. От неё не избавляются в ходе модернизации; вместо этого строят чистые адаптеры и позволяют ей и дальше надёжно делать то, что она делает уже четыре десятилетия.