Я разработал бота, который помогает пользователю забронировать комнату для собраний и доступен только в канале Команды для разговоров 1: 1. Я разработал диалоговые окна водопада для сбора данных (предпочтительная комната, этаж, количество участников, дата, время и т. Д.). Работает отлично. Но теперь я хочу добавить новую функцию, которая заключается в том, чтобы заблаговременно уведомлять пользователя, когда определенная комната для собраний свободна (скажем, этого не было раньше, когда пользователь делал резервирование). Я добавил вторую конечную точку «api / notify» (в соответствии с официальным примером проактивного бота), которая получает веб-крючок, и я использую соединитель для отправки проактивного сообщения пользователю, например: «Конференц-зал 1 свободен, теперь вы хотите отредактировать свой оригинал». место встречи? ». Здесь у меня есть несколько вопросов о дизайне и дальнейшей разработке:
Как только пользователь получает предупреждающее уведомление и отвечает «да», я хотел бы вызвать новый водопад, чтобы позволить пользователю изменитьпредварительный заказ. Я не уверен, что здесь правильный подход и как «вызвать» диалоговое окно EditReservationWaterfall, так как простое «да» не похоже на правильный триггер, который нужно поймать как прерывание. Должен ли я хранить информацию о проактивном сообщении, отправляемом в контейнере Cosmos DB / Blob, и объединить его как условие вместе с прерыванием «да» (и, возможно, проверить, есть ли какой-либо активный диалог в качестве третьего условия). Или есть способ вызвать водопад прямо из конечной точки «api / notify»? Может быть, есть способ как-нибудь передать запрос «api / notify» основному боту .cs? Или любая другая идея?
Как обрабатывать сценарии, когда пользователи делают новое резервирование и в ходе этого процесса «api / notify» получает запрос на публикацию. Как сделать так, чтобы код «api / notify» не прерывал текущий водопад? Могу ли я каким-то образом проверить, существует ли какой-либо активный диалог с конечной точки «api / notify», и, возможно, ответить неудачным кодом состояния на webhook, чтобы webhook через некоторое время снова отправил запрос. Или есть какой-то другой умный подход?
Просто обратите внимание, что логика webhook здесь отдельная и будет настроена в соответствии с требованиями.