Интеграции сайта с внешними системами в Москве

Автоматизация отвечает на вопрос «как должен идти процесс внутри компании»: кто согласует, какой статус следующий, когда уходит напоминание. Интеграция отвечает на другой вопрос — как двум системам обмениваться данными без человека посередине. Часто их делают вместе, но объём работ разный, и путать их дорого: можно построить красивый процесс поверх данных, которые не сходятся.

Смету задают четыре величины: сколько систем связывается, есть ли у каждой готовый API, сколько сущностей передаётся (только заявки или ещё товары, остатки, оплаты, документы) и нужна ли двусторонняя передача. Двусторонний обмен всегда дороже одностороннего, потому что требует правил разрешения конфликтов. Пришлите список систем. Вернём расчёт по этим пунктам.

Чаще всего да, но другим способом. Если система умеет выгружать и принимать файлы, обмен строится на них по расписанию. Если у неё есть база, к которой открыт доступ, обмен идёт через промежуточный слой. Полностью закрытая система без API, файлов и базы — единственный случай, когда честный ответ «нет». тогда обсуждаем замену системы, а не интеграцию.

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

Обновления действительно ломают обмен — чаще всего при смене версии API или структуры справочников. Поэтому обмен строится через отдельный слой, а не вшивается в шаблон сайта: при смене одной стороны правится один участок, а не весь сайт. Регулярные проверки удобно вести в рамках технической поддержки.

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

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

Срок задаёт не сайт, а вторая сторона: готовность её API, качество документации и скорость ответов её администратора. Быстрее всего идут связки с сервисами, у которых публичный документированный API. Дольше всего. Обмен с доработанной под компанию учётной системой, где сначала приходится разбирать, как она устроена сейчас.

Для штатной работы. Нет: обмен идёт сам, а ошибки видны в журнале. Разработчик нужен, когда меняется процесс: добавляется поле, новая площадка, новый способ оплаты. Такие правки удобно вести пакетами, а не по одной.

С одного процесса, который болит каждый день. Чаще всего это путь заявки от формы до сделки — он короткий, эффект виден за неделю, и на нём проверяется вся схема обмена. Остальные системы подключаются следующими этапами, уже по работающей карте полей.

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