Подводные камни больших интеграций

Недавно работала над интеграцией УПП с одной очень крупной транспортной компанией с красно-белым логотипом 😄

Со стороны такие проекты часто выглядят довольно просто: есть API перевозчика, документация, расчёт стоимости доставки, упоавление заказами — значит осталось только подключиться.

На практике саму интеграцию пришлось писать с нуля: расчёт стоимости, оформление заявок, обмен статусами, работа с адресами и различными проверками.

На тестовой базе всё настроила, подключила, проверила. Запустили интеграцию уже в промышленную эксплуатацию — вроде всё работает.

И вот тут начались проблемы с адресами, о которых в самом начале никто даже не подумал.

Оказалось, что разные системы могут по-разному понимать один и тот же адрес.

Например, для пользователя это просто: «г. Пермь, ул. Садовая, 5»

Для государственных классификаторов — тоже Пермь.

Но для транспортной компании часть таких адресов могла относиться уже к отдельным зонам доставки, микрорайонам или населённым пунктам со своими ограничениями.

В результате происходила довольно неприятная ситуация:

1С успешно рассчитывала стоимость доставки. Менеджеры подтверждали заказ клиенту. Заявка улетала через API. А спустя время приходил ответ: «доставка невозможна».

Технически интеграция при этом работала корректно: — запросы проходили, — ответы возвращались, — ошибок не было.

Но бизнес-процесс всё равно ломался, потому что данные в разных системах интерпретировались по-разному.

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

Подводные камни больших интеграций | Сетка — социальная сеть от hh.ru