Как делается двусторонняя интеграция сервисов на вебхуках?
Ребят, подскажите новичку:
Есть сервис А, в котором при изменении Сделки отправляется вебхук сервису Б и тоже самое происходит на сервисе Б в обратную сторону. Двусторонняя интеграция. Между ними собственно сервис который занимается получением, преобразованием, отправкой.
Встал такой вопрос: если сервисы друг друга уведомляют при изменении сделки и меняют данные, то получается зацикливание процесса. Как такое решается? Должно быть так: Сервис А отправил серверу вебхук — Сервер преобразовала данные и отправил сервису Б — Сервис Б изменил в себе данные и НЕ СТАЛ отправлять вебхук об изменении серверу (и, соответственно, сервису А)
Тут что-то не так с архитектурной точки зрения. Вообще такие циклические зависимости - очень сильный признак что что-то не так на уровне проектирования. "Источником правды" должен быть какой-то один сервис. Поэтому, я бы в первую очередь подумал не как реализовать такую структуру, а как перепроектировать её, чтобы избавиться от такой зависимости.
Не умею доступа к разработке сервисов, думаю важно это уточнить. Первый сервис AmCRM, а второй аналог YClients. Один сервис помогает продавать клиентам и вести маркетинг, а вторая для записи клиентов на услуги, формирования графика мастеров и прочего. Записи и там и там нужны а одинаковом виде. Один сервис для мастеров, второй для продавцов, грубо говоря.
Александр Кудрявцев, тогда тут такой вопрос: сервис будет вызывать вебхук даже если запись не изменилась?
Сервис А - изменили запись.
Он вызвал сервис Б - изменил данные там
Сервис Б вызывал сервис А - но данные в сервисе А и так уже актуальны
Будет ли сервис А вызывать вебхук, если данные не изменились?
Если будет - то придумывать что-нибудь на уровне сервиса-посредника. Например, чтобы он отслеживал-запоминал (сохранял в свою БД) какие хуки с какими данными пробежали и в случае такой ситуации (обновление данных совпадающее с тем, которое уже было. в пределах вот только что, нескольких минут) просто игнорировал вебхук, не пробрасывая его дальше.
Простой
Средний
