CRM, ERP и API · 19 минут
Как проектировать интеграции CRM, ERP и внешних API, чтобы система не рассыпалась
Практический разбор интеграционных проектов: источник истины, контракты данных, статусы, повторные запросы, ошибки, безопасность и порядок запуска.
Карта обмена
Интеграция — это движение данных между владельцами
Сначала определите, какая система отвечает за каждый объект. Только потом выбирайте способ обмена.
Риск интеграции
Сложность растёт не от количества URL
Один endpoint может быть критичнее десятка простых вызовов, если через него проходят деньги или заказы.
Начните с владельца данных
Для каждого объекта назначьте источник истины: клиент, договор, заказ, остаток, платёж или документ. Если два сервиса считают себя владельцами одного поля, система неизбежно начнёт показывать разные версии состояния.
Нарисуйте не список интеграций, а карту объектов и переходов. Такой артефакт полезен бизнесу, аналитикам и разработчикам: он показывает, где возникает действие и где хранится результат.
Контракт данных важнее названия API
Контракт фиксирует поля, обязательность, форматы дат, идентификаторы, допустимые статусы и правила удаления. Уточните, что произойдёт, если новое поле не пришло, значение изменилось или запись появилась дважды.
Документация провайдера редко описывает все бизнес-ограничения. Нужны sandbox, примеры реальных ответов и контакт ответственного человека с другой стороны.
Спроектируйте отказ до счастливого пути
Внешний сервис может не ответить, вернуть неполные данные или прислать событие позже другого события. Нужны таймаут, повторная попытка, ограничение частоты, журнал и понятный статус «требует проверки».
Для платежей, заказов и списаний обязательна защита от повторной операции. Иначе повторное уведомление превратится в два списания или два заказа.
Не превращайте систему в цепочку прямых вызовов
Когда один запрос синхронно вызывает CRM, склад, оплату и доставку, любая задержка блокирует весь пользовательский путь. Критические действия лучше отделять от вторичных обновлений и явно фиксировать промежуточное состояние.
Это не означает, что каждому проекту нужна сложная шина сообщений. Сначала определите требования к скорости, порядку, повторяемости и восстановлению, а потом выбирайте API, события или очередь.
Безопасность — часть интеграционного контракта
Опишите, какие данные передаются, где находятся персональные сведения, как выдаются ключи, как отзывается доступ и какие действия попадают в аудит. Секреты нельзя хранить рядом с кодом или передавать в журналы.
Отдельно договоритесь о версиях API и обратной совместимости. Обновление внешнего сервиса не должно неожиданно ломать оформление заказа или выдачу документа.
Запускайте критический путь первым
В первой версии закройте один путь от начала до результата: например, заявка → CRM → уведомление менеджеру или заказ → оплата → резерв на складе. После этого добавляйте второстепенные обмены.
Приёмка должна проверять не только успешные ответы, но и недоступность, дубликаты, задержки и ручное восстановление. Такой сценарий даёт реальное понимание готовности системы.