Корпоративные системы и интеграции
Подключение ERP к API третьих сторон
ERP и третьи стороны: CRM, логистика, налоги и идентификация
Подключения REST, SOAP, вебхуков и iPaaS между вашей ERP и окружающими её сервисами, с повторами и оповещениями.
Схема
Прокрутите вбок, чтобы увидеть весь чертёж.
От ERP к третьим сторонам: одна платформа, много партнёров
Бизнес-события выходят из ERP один раз, и интеграционная платформа доставляет их каждому партнёру в нужном ему формате. Обратные вызовы возвращаются тем же путём. Сообщение, которое не удалось отправить после повторов, попадает в очередь недоставленных сообщений и вызывает оповещение с приложенными данными.
- Основной поток
- Асинхронный
- Сценарий исключения
Поток из 9 шагов
Поток шаг за шагом
- От ERP к Интеграционная платформа: Бизнес-события, по REST · OData · webhook (основной поток).
- От Интеграционная платформа к CRM: Клиенты и заказы, по REST/JSON (основной поток).
- От Интеграционная платформа к Логистика и перевозчики: Забронированные отправления, по REST/JSON (основной поток).
- От Логистика и перевозчики к Интеграционная платформа: События отслеживания, по webhook (асинхронный).
- От Интеграционная платформа к Платформа электронных счетов-фактур и налогов: Счета для подтверждения, по SOAP/XML · REST (основной поток).
- От Интеграционная платформа к Поставщик KYC и идентификации: Проверки личности, по REST/JSON (основной поток).
- От Поставщик KYC и идентификации к Интеграционная платформа: Результаты проверок, по webhook (асинхронный).
- От Интеграционная платформа к Очередь недоставленных сообщений и оповещения: Сбой после повторов — в очередь недоставленных сообщений (сценарий исключения).
- От Очередь недоставленных сообщений и оповещения к Команда поддержки: Оповещение с данными и ошибкой (сценарий исключения).
Обзор
Это поток между вашей ERP и окружающими её сервисами: CRM, перевозчиками и логистическими провайдерами, платформами электронных счетов и налогов, поставщиками идентификации и KYC. У каждого партнёра свой API, свой формат и свои сбои, и обычно каждый из них становится отдельным проектом.
Эталонная схема публикует бизнес-события из ERP один раз — в интеграционную платформу, которая доставляет их каждому партнёру в ожидаемом формате: по REST, SOAP, через вебхуки или EDI поверх AS2 там, где этого требуют торговые партнёры. Обратные вызовы, например события отслеживания или результаты проверок, возвращаются через ту же платформу.
Недоступность партнёра — штатное событие, а не аварийное. Временные сбои повторяются. Сообщение, которое не проходит и после повторов, попадает в очередь недоставленных сообщений, а команда поддержки получает оповещение с полезной нагрузкой и ошибкой, чтобы его можно было исправить и воспроизвести заново.
Как устроен поток
ERP публикует событие
Когда меняются клиент, заказ или счёт, ERP публикует одно бизнес-событие в интеграционную платформу — через свой API, сервисы OData или вебхуки.
CRM остаётся актуальной
Платформа обновляет счета, контакты и заказы в CRM, чтобы отделы продаж и сервиса видели то, что знает ERP.
Отправления оформляются
Заказы, готовые к отгрузке, оформляются у перевозчика или логистического провайдера через его API, а обратно приходят этикетки и ссылки.
Возвращается отслеживание
Перевозчик присылает события отслеживания и подтверждения доставки через вебхук, и платформа обновляет заказ в ERP.
Счета регистрируются
Счета отправляются на платформу электронных счетов или налоговую платформу в требуемом органами формате, а статус регистрации сохраняется вместе со счётом.
Идентичность проверяется
Новые клиенты или поставщики отправляются поставщику KYC или идентификации, а результат возвращается через вебхук до активации учётной записи.
Когда что-то идёт не так
Партнёр временно недоступен
Вызов повторяется с увеличивающимися задержками. Ключ идемпотентности при каждой записи означает, что повтор никогда не создаёт второе отправление или второй счёт.
Сообщение не проходит и после повторов
Оно попадает в очередь недоставленных сообщений вместе с полезной нагрузкой и ошибкой партнёра, а команда поддержки получает оповещение. После исправления сообщение воспроизводится из очереди.
Партнёр меняет свой API
Контрактные тесты выполняются против тестовой среды каждого партнёра и выявляют изменение. Анонсированные изменения планируются и тестируются до срока, установленного партнёром.
Данные отклонены
Партнёр, отказавший в данных по деловой причине, например из-за отсутствующего налогового номера, возвращает ошибку к записи в ERP, где владелец может её исправить.
Стандарты и системы
- Интеграция
- REST
- SOAP
- Webhooks
- OpenAPI
- EDI (EDIFACT, ANSI X12)
- AS2
- MuleSoft
- Boomi
- Azure Logic Apps
- Идентификация и доступ
- OAuth 2.0
Вопросы и ответы
Какие сервисы третьих сторон вы можете подключить?
Любой сервис с документированным API или файловым интерфейсом. Типичные примеры: CRM-платформы, перевозчики и логистические провайдеры, маркетплейсы, платформы электронных счетов и налогов, расчёт зарплаты, поставщики KYC и идентификации, а также торговые партнёры, обменивающиеся документами EDI поверх AS2. Перед обязательством по плану мы изучаем API, лимиты и тестовую среду каждого партнёра.
Нужна ли для этого интеграционная платформа?
Когда к одной ERP подключено несколько партнёров, платформа вроде MuleSoft, Boomi или Azure Logic Apps либо набор собственных сервисов на базе очереди сообщений держит маппинг, повторы и мониторинг в одном месте. При одном-двух партнёрах может хватить прямых подключений. Мы изложим компромиссы, включая стоимость лицензий, для вашего случая.
Можете ли вы подключить нас к платформам электронных счетов и налоговой регистрации?
Да. Многие страны теперь требуют выставлять или регистрировать счета через государственную или аккредитованную платформу в определённом формате. Мы интегрируем ERP с платформой, требуемой в вашей стране, или с аккредитованным провайдером, сохраняем статус регистрации и идентификаторы вместе с каждым счётом и обрабатываем отказы. Применимые к вам правила подтверждают ваши налоговые консультанты.
Как вы защищаете входящие вебхуки?
Каждый входящий вебхук проверяется до обработки: по подписи там, где партнёр подписывает сообщения, и по токену, источнику и отметке времени там, где нет. Полезные нагрузки проверяются по контракту, а события обрабатываются один раз, даже если партнёр присылает их повторно.
Что происходит при сбое у партнёра?
Остальные потоки продолжают работать. Сообщения для этого партнёра повторяются, а затем ставятся в очередь, команда поддержки получает оповещение, и ничего не теряется. Когда партнёр восстанавливается, сообщения из очереди воспроизводятся по порядку. На дашборде видно, какой партнёр затронут и сколько сообщений ожидает.
Кому принадлежат созданные вами коннекторы?
Интеллектуальная собственность на работу, которую мы создаём для вас, принадлежит вам с первого коммита — без отдельного этапа передачи в конце. Коннекторы поставляются с исходным кодом, тестами и документацией, чтобы ваша команда или другой поставщик могли их поддерживать. Любые инструменты XSIS, существовавшие ранее, остаются нашими и лицензируются вам. API партнёров и лицензии интеграционных платформ остаются на условиях соответствующих поставщиков.
Начните с разговора, а не с договора.
Расскажите, что нужно создать, подключить или защитить. Архитектор разберёт это с вами и порекомендует, с чего начать.
Что происходит дальше
Согласование времени
Наша команда напишет вам, чтобы согласовать время сессии.
Предконсультационная сессия
бесплатная 30-минутная онлайн-сессия предварительного консультирования: мы разбираем ваши цели, системы и ограничения.
Оценка готовности
В рамках бесплатная 48-часовая оценка готовности ведущий архитектор проверяет ваш проект по шести критериям определения готовности и рекомендует подходящий трек.
Выбор трека
Проекты с готовым объёмом работ получают обязывающее предложение в течение 3–5 рабочих дней. Проекты на стадии концепции начинаются в Blueprint Studio. Действующая система, которая сбоит, не документирована или требует интеграции, начинается с диагностики 1–2 недели. У Blueprint Studio и диагностики фиксированная плата, указанная в предложении.