Подводные камни больших интеграций
Недавно работала над интеграцией УПП с одной очень крупной транспортной компанией с красно-белым логотипом 😄
Со стороны такие проекты часто выглядят довольно просто: есть API перевозчика, документация, расчёт стоимости доставки, упоавление заказами — значит осталось только подключиться.
На практике саму интеграцию пришлось писать с нуля: расчёт стоимости, оформление заявок, обмен статусами, работа с адресами и различными проверками.
На тестовой базе всё настроила, подключила, проверила. Запустили интеграцию уже в промышленную эксплуатацию — вроде всё работает.
И вот тут начались проблемы с адресами, о которых в самом начале никто даже не подумал.
Оказалось, что разные системы могут по-разному понимать один и тот же адрес.
Например, для пользователя это просто: «г. Пермь, ул. Садовая, 5»
Для государственных классификаторов — тоже Пермь.
Но для транспортной компании часть таких адресов могла относиться уже к отдельным зонам доставки, микрорайонам или населённым пунктам со своими ограничениями.
В результате происходила довольно неприятная ситуация:
1С успешно рассчитывала стоимость доставки. Менеджеры подтверждали заказ клиенту. Заявка улетала через API. А спустя время приходил ответ: «доставка невозможна».
Технически интеграция при этом работала корректно: — запросы проходили, — ответы возвращались, — ошибок не было.
Но бизнес-процесс всё равно ломался, потому что данные в разных системах интерпретировались по-разному.
После таких проектов особенно хорошо понимаешь, что в больших интеграциях проблемы часто начинаются не в коде, а в несовпадении данных и бизнес-логики между системами.