Интеграции систем и API

Интеграция — это не «соединить два API». Реальная задача начинается там, где две системы по-разному понимают одни и те же данные, имеют разные справочники, ограничения, скорости обновления и правила обработки ошибок.

SoftTech проектирует интеграции как отдельный программный контур: какие системы связываются → какие данные являются источником истины → когда они передаются → как обрабатываются ошибки → как контролируется работа обмена после запуска.

Когда нужна отдельная интеграция

Типовые сценарии:

• ERP должна обмениваться данными с WMS;
• CRM получает заявки с сайта, телефонии или внешних сервисов;
• кассовая/POS-система должна передавать события в другой контур;
• собственное программное решение должно работать с учётной системой заказчика;
• оборудование или терминал должен обмениваться данными с backend;
• существующая система имеет API, но готового коннектора нет;
• несколько приложений используют разные справочники и форматы;
• ручной перенос данных создаёт задержки и ошибки;
• старый point-to-point обмен стал трудно сопровождать;
• необходимо документировать и контролировать критичные интеграции.

Сначала данные и ответственность, потом код

Перед разработкой необходимо определить:

1. какие системы участвуют в обмене;
2. кто является владельцем каждого типа данных;
3. какие сущности и поля синхронизируются;
4. направление обмена — одностороннее или двустороннее;
5. допустимую задержку;
6. правила создания, изменения и удаления записей;
7. обработку конфликтов;
8. поведение при недоступности одной из систем;
9. требования к журналированию;
10. кто поддерживает интеграцию после запуска.

Без этих решений API быстро превращается в набор трудно объяснимых скриптов.

API или готовый коннектор

Не каждая задача требует заказной разработки.

Сначала проверяется:

• существует ли штатная интеграция;
• поддерживает ли она нужные версии систем;
• покрывает ли требуемые данные и сценарии;
• допускает ли расширение;
• как обновляется и поддерживается;
• кто отвечает за неё при изменении одной из систем.

Если стандартный механизм решает задачу — писать новый код ради самого кода не нужно.

Заказная интеграция оправдана, когда штатного решения нет, оно не покрывает бизнес-логику или требуется отдельный контролируемый интеграционный слой.

Архитектура обмена

В зависимости от требований интеграция может использовать:

• REST API;
• webhooks;
• очереди сообщений;
• файловый обмен;
• ETL-процессы;
• промежуточный интеграционный сервис;
• события от оборудования и устройств;
• комбинацию нескольких механизмов.

Конкретная архитектура определяется доступными интерфейсами систем и требованиями к надёжности, скорости и сопровождению.

Источник истины

Одна из самых важных договорённостей — какая система владеет данными.

Например, если товар создаётся в ERP, а используется в WMS и внешнем приложении, необходимо определить:

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

Иначе две системы начинают синхронно портить друг другу данные с впечатляющей автоматизацией.

Надёжность обмена

Интеграция должна корректно работать не только тогда, когда всё доступно.

Для критичных сценариев рассматриваются:

• повторная отправка после временной ошибки;
• защита от повторной обработки одного события;
• очереди и буферизация;
• таймауты;
• контроль последовательности событий;
• журнал ошибок;
• ручной или автоматический повтор проблемных операций;
• уведомления о сбоях;
• мониторинг задержек и накопившихся очередей.

Точный набор механизмов зависит от критичности процесса.

Синхронный и асинхронный обмен

Не все данные должны передаваться мгновенно.

Синхронный сценарий

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

Асинхронный сценарий

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

Пакетный обмен

Может быть достаточен для данных, которые обновляются по расписанию и не требуют real-time обработки.

Выбор механизма делается по бизнес-требованию, а не по моде на технологию.

Интеграция с 1С, ERP, WMS и CRM

SoftTech Development работает со сложными интеграционными сценариями, включая ERP, WMS, SCADA, СКУД, ANPR, API, шины данных и ETL.

Название класса системы — ERP, WMS, CRM — ещё не задаёт конкретный продукт и версию.

Для конкретной интеграции проверяются:

• точный продукт и версия;
• доступные API/SDK/форматы;
• ограничения лицензии;
• документация;
• существующие доработки;
• тестовый контур;
• ответственные специалисты со стороны заказчика или производителя.

Интеграции с оборудованием

В проектах SoftTech программный слой часто должен взаимодействовать не только с корпоративным ПО, но и с физическими устройствами.

Это актуально для:

• ST Point;
• систем контроля доступа;
• ANPR;
• периферийных устройств;
• RFID;
• сканеров;
• собственных CTRL-продуктов;
• других устройств при наличии документированных интерфейсов.

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

Безопасность интеграции

Безопасность определяется не словом API, а конкретной архитектурой.

В проекте могут учитываться:

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

Конкретные требования согласуются с заказчиком и владельцами интегрируемых систем.

Тестовый контур

Критичную интеграцию опасно впервые проверять на боевых данных.

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

• структура данных;
• основные бизнес-сценарии;
• ошибочные данные;
• недоступность одной из сторон;
• повторная обработка;
• нагрузка;
• миграция/первичная синхронизация;
• процедура отката.

Возможность полноценного тестового контура зависит от систем заказчика.

Документация

После запуска должны быть понятны:

• системы-участники;
• endpoints или другие интерфейсы;
• модель данных;
• направления обмена;
• расписание/триггеры;
• правила авторизации;
• коды и типы ошибок;
• порядок повторной обработки;
• мониторинг;
• границы ответственности.

Без документации работающая сегодня интеграция завтра становится археологической экспедицией.

Наблюдаемость и сопровождение

Сам факт успешного запуска не означает, что интеграция будет вечной.

Меняются:

• API;
• версии ERP/CRM/WMS;
• бизнес-правила;
• справочники;
• инфраструктура;
• объёмы данных.

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

Подтверждённый опыт

Burger King Belarus

В действующем проекте SoftTech выполнял интеграционные задачи и специализированную автоматизацию в распределённой инфраструктуре. Детали клиентской логики закрыты NDA.

Открыть кейс →

MOSTRA-GROUP

В проекте SoftTech выполнял интеграционные задачи и небольшую специализированную разработку внутри полного инфраструктурного цикла. Детали закрыты NDA.

Открыть кейс →

Собственные продукты SoftTech

CTRL и ST Point дают группе практический опыт, где программа должна взаимодействовать с устройствами, инфраструктурой и внешними системами. Состав интеграций каждого продукта описан на его странице.

Границы услуги

• Интеграция — обмен данными и вызов функций между существующими системами.
• Заказная разработка — создание самостоятельного приложения или значительного нового функционального контура. См. заказную разработку ПО.
• Автоматизация процесса — правила, статусы и маршруты, где обмен может быть только одним слоем. См. автоматизацию бизнес-процессов.
• Системная интеграция — более широкий проект, где программный обмен может быть лишь одним слоем вместе с инфраструктурой и оборудованием. См. системную интеграцию.
• Готовый коннектор — стандартный механизм производителя или партнёра, который не следует переписывать без причины.

Один проект может включать несколько этих уровней.

От чего зависит интеграция

До оценки проверяют исходные условия обмена:

• есть ли штатный коннектор для конкретного продукта и версии ERP, WMS или CRM;
• доступен ли технический интерфейс; если его нет, первым шагом будет исследование, а не разработка;
• нужна ли передача сразу или достаточно обмена по расписанию;
• как фиксируются и обрабатываются ошибки сторонней системы;
• какие требования к производительности и сопровождению нужно согласовать отдельно.

Что подготовить для оценки

Для первичного разбора полезно передать:

• какие системы необходимо связать;
• точные названия и версии;
• документацию API/SDK, если она есть;
• какие данные должны передаваться;
• направление обмена;
• примерный объём операций;
• допустимую задержку;
• критичность процесса;
• наличие тестового контура;
• существующие интеграции и ограничения;
• ответственных специалистов со стороны владельцев систем.

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

Обсудить интеграцию →

Специализированная разработка группы также представлена на SoftTech Development.