Вопрос: Как сделать, чтобы несколько ботов предоставляли ответы на одно и то же окно чата Команд, которое есть у пользователя с ботом-агрегатором.
Описание:
Несколько разных команд создали ботов, которые могут отвечать на вопросы, связанные с их областями. Представьте себе сервисного бота, бот-каталог и т. Д. Все эти боты обслуживаются их владельцами, имеют свои собственные наборы намерений LUIS и т. Д. Это прекрасно работает, но вы должны знать, где искать вопросы каждого типа. .
Теперь мы хотели бы иметь единого бота для каждого, к которому можно было бы подключиться, чтобы получить ответы на свои вопросы независимо от того, в какую область входит этот вопрос. Идея состоит в том, что этот робот-агрегатор затем направит вопросы соответствующему боту области, который затем предоставит ответ. Сценарий здесь заключается в том, что кто-то, устраняющий проблему, может задавать вопросы, пересекающие несколько областей в одном месте, без необходимости знать о ботах каждой отдельной области.
Боты в настоящее время размещены в командах и являются C #. Пока наше решение имеет такой поток:
- Бот-агрегатор получает вопрос и спрашивает каждого бота (через другую конечную точку, специфичную для этого потока), насколько он уверен, что может ответить на вопрос.
- Агрегатор-бот решает, каким ботам задать вопрос, и отправляет вопрос в обычную конечную точку / api / messages для бота.
- [Сломан] Зональный бот при необходимости выдает ответ / запрос аутентификации / или начало разговора для уточнения возможного ответа.
Мы нашли проект передача сообщений между ботами , но в файле readme.MD написано:
Примечание: основной бот и каждый из суб-ботов имеют один и тот же AppID и
AppPassword. Это позволяет всем ботам вести один и тот же разговор.
ID, Dialog
Stack
,
и Bot State
Данные .
Это невозможно в Azure, поскольку вы не можете создать несколько ботов с одним и тем же идентификатором приложения.
Попробовав взлом на основе этого, мы обнаружили, что если мы изменим конфигурацию бота, чтобы использовать один и тот же MicrosoftAppId и MicrosoftAppPassword в настройках приложения в Azure для всех ботов, то через бот-агрегатора все будет работать нормально. В этот момент вы больше не можете напрямую подключаться к отдельным ботам. Хотя это явно хак, а не решение, оно подразумевает, что проблема основана на аутентификации, а не на чем-то невозможном.
Есть много частей вокруг, которые, кажется, могут помочь, но мы не нашли документацию, которая бы соответствовала им. Это похоже на то, что должно быть распространенным сценарием. В идеале мы могли бы указать какое-то доверие к ботам на более высоком уровне и не обязательно указывать AppId и AppPassword напрямую, хотя мы готовы сделать это в этом случае, поскольку мы все одна и та же компания.
Вещи, которые мы пробовали:
- Использование TrustServiceUrl для доверия боту-агрегатору из каждой области
бот, и все боты области от бота агрегатора. Звонок был
сделано в Application_Start в Global.asax для каждого бота.
- Взлом, описанный выше
- Указание AppId и AppPassword в атрибуте BotAuthentication
Номер 3 фактически решил проблему аутентификации, позволив боту-агрегатору спрашивать каждого бота на его уверенность в ответе на вопрос, когда мы использовали его для обозначения этих функций. Определение AppId и AppPassword для бота-агрегатора в спецификации для этой конечной точки в отдельных ботах области работало отлично. Но это не исправило возможность для отдельного бота области возвращаться к разговору, принадлежащему боту-агрегатору. В этом случае сам агрегатор-бот потребляет ответ, и это ответ, а не поток.
Что мы попробуем отсюда? Есть ли что-то, что мы упустили, или есть что-то принципиально неправильное в подходе, с которого мы начали?