Соединяю B2B-системы, ERP и сервисы без «родного» коннектора: маппинг данных, очереди, обработка ошибок и контроль целостности при обменах. Когда vendor API нестабилен или документация устарела — строю надёжный адаптер, а не жду обновления от поставщика.
С чем обычно приходят
Типичные ситуации, когда стандартные решения уже не справляются.
- Два ERP не синхронизируются: заказы дублируются, остатки расходятся, бухгалтерия сводит вручную раз в неделю.
- API партнёра меняется без предупреждения — интеграция падает, бизнес узнаёт от клиента, а не от мониторинга.
- Подрядчик написал интеграцию «как получилось» — нет логов, нет retry, при ошибке данные теряются молча.
- Нужно подключить legacy-систему без API — только CSV по SFTP раз в сутки, а бизнес хочет near-real-time.
Как я работаю
Пошаговый процесс — от диагностики до передачи в эксплуатацию.
- 01
Аудит систем и форматов обмена
Изучаю API, документацию и реальное поведение систем. Фиксирую сущности, частоту синхронизации, конфликты данных и текущие точки отказа.
- 02
Проектирование адаптера
Проектирую маппинг полей, трансформации, idempotency keys и стратегию разрешения конфликтов. Определяю, что синхронизируется в реальном времени, а что — batch.
- 03
Разработка и тестирование
Пишу адаптер на n8n или код, настраиваю очереди, retry с exponential backoff, dead letter. Прогоняю на тестовых данных, проверяю edge cases.
- 04
Запуск и мониторинг
Переключаю на продакшен с shadow mode или canary. Настраиваю алерты, дашборд расхождений и runbook для типовых инцидентов.
Что вы получаете
- Регламентные обмены автоматизируются, а ручная сверка остаётся для исключений и спорных записей
- Сценарии сбоев API проверяются тестами: сообщения проходят retry и при необходимости попадают в DLQ
- Расхождения попадают в дашборд и алерты по настроенным порогам и срокам реакции
- Новые поля и сущности подключаются через версионируемый маппинг; объём доработки оценивается по изменениям API
Что входит в проект
- Рабочий адаптер между системами с маппингом данных
- Очереди, retry-политики и обработка ошибок
- Логирование каждого обмена с возможностью replay
- Дашборд: статус синхронизации, расхождения, ошибки
- Документация маппинга и бизнес-правил
- Runbook для инцидентов и ручной сверки
Почему мне доверяют такие задачи
Михаил Клименко интегрировал ERP, CRM и внешние B2B-платформы в коммерческих продуктах ESM-CRM и Lidora-CRM. Знаю, как API ведут себя в продакшене — не по документации, а по логам реальных обменов.
Частые вопросы
n8n или custom code для B2B-интеграции?
n8n — для стандартных REST/webhook обменов с умеренной логикой. Custom code — когда нужна сложная трансформация, высокий throughput или специфичный протокол. Часто комбинирую: n8n для оркестрации, код для тяжёлых трансформаций.
Как решать конфликты при двусторонней синхронизации?
Определяю master-систему для каждой сущности, timestamp-based merge или business rules. На проектировании фиксируем все edge cases — «кто главный» для заказов, клиентов, остатков.
API партнёра нестабилен — что делать?
Retry с backoff, circuit breaker, кэширование последнего успешного состояния. Алерт при N последовательных ошибках. Если API совсем ненадёжен — рассматриваем SFTP/batch как fallback.
Можно ли интегрировать legacy без API?
Да. CSV/SFTP, ODBC, парсинг email-уведомлений, RPA как крайний случай. Цель — надёжный поток данных, а не идеальный протокол.
