找不到 BotFramework 对话
BotFramework conversation not found
我一直在尝试测试一个函数应用程序,它向一个有现有对话的机器人发送 activity,但为了简化这个 post,我会用发送的方式来说话通过 post 人。我一直在解决一个没有找到 conversationId 的问题,尽管事先确认它确实存在,但我不完全确定我做错了什么。
我登录到 Azure 门户,然后转到我的机器人以在网络聊天中进行测试。我对机器人进行身份验证,对话开始。
在这里,我通过检查 Chrome 调试工具中的对话调用响应来检查 conversationId 是否正是我所期望的,在本例中它是 1GJ0N9UYKGyELu3LqpDF6b-a
这是准确的对话回复...
conversationId: "1GJ0N9UYKGyELu3LqpDF6b-a"
expires_in: 3600
referenceGrammarId: "fcab5fbf-67c7-bf55-934a-274e525c78a9"
streamUrl: "wss://webchat.botframework.com/v3/directline/conversations/1GJ0N9UYKGyELu3LqpDF6b-a/stream?watermark=-&t=ew0KICAi...."
token: "ew0KICA..."
所以从这里开始,在我看来我应该能够在 postman
中执行以下操作
POST https://webchat.botframework.com/v3/directline/conversations/1GJ0N9UYKGyELu3LqpDF6b-a/activities
Content-Type: application/json
Authorization: Bearer {My webchats channels secret code}
Body:
{
"type": "message",
"from": {
"name": "foo"
},
"text": "bar"
}
我希望 200OK 和消息 'bar' 出现在我来自 'foo' 的网络聊天测试中,但它没有。相反,我在 postman 中收到一条错误消息:
{
"error": {
"code": "BadArgument",
"message": "Conversation not found"
}
}
这到底是怎么回事?如果我刚刚创建了那个对话并且可以证明 conversationId 正在使用中,为什么 post 消息说找不到它?我是否错误地使用了频道?或者在这里做一些非常明显的事情?
长话短说,回答我自己的问题。看起来 Microsoft 文档中提供的示例 activity 并没有完全正确。还有 其他 是必需的,尽管我没有时间缩小范围。
由于我 运行 时间不够,我采取的解决方案是编写一种方法将 activity 保存到 cosmosDb 作为身份验证流程的一部分。通过这种方式,我有一个铁定的 activity,我知道它至少在对话的调用阶段有效,而且我知道对话参考是正确且存在的。我从那里拉出 activity 并更改了其中的 4 个字段。
activity.Type = "message",
activity.From = new From { Id = "{BotId}", Name = "Gilbert Bottfried", Role = "bot },
activity.Text = "{My message}",
activity.Subject = "{my message subject}"
从那里开始,本质上就是创建一个连接器客户端并启动这个重新调整用途的 activity。
AppCredentials.TrustServiceUrl(serviceUrl, DateTime.MaxValue);
ConnectorClient client = new ConnectorClient(
new Uri(serviceUrl),
MicrosoftAppId,
MicrosoftAppPassword);
await client.Conversations.SendToConversationAsync(activity.Conversation.Id, activity);
这似乎足以让它正常工作,并且它为以后的消息提供了一个很好的可参考对话 ID。虽然我发现了使用 WebChat 的其他问题,因为我怀疑通过 websockets 发送消息和抛出消息并不是完全稳定的。在 msteams 上的测试体验更加稳定,它似乎可以像冠军一样处理我的测试消息。
这本质上是一种暴力破解方法,因为我正在存储和发送大量不必要的数据,但它确实有效。我可能会将此答案附加到 trim 中,我认为将来有必要,但这需要测试。
我一直在尝试测试一个函数应用程序,它向一个有现有对话的机器人发送 activity,但为了简化这个 post,我会用发送的方式来说话通过 post 人。我一直在解决一个没有找到 conversationId 的问题,尽管事先确认它确实存在,但我不完全确定我做错了什么。
我登录到 Azure 门户,然后转到我的机器人以在网络聊天中进行测试。我对机器人进行身份验证,对话开始。
在这里,我通过检查 Chrome 调试工具中的对话调用响应来检查 conversationId 是否正是我所期望的,在本例中它是 1GJ0N9UYKGyELu3LqpDF6b-a
这是准确的对话回复...
conversationId: "1GJ0N9UYKGyELu3LqpDF6b-a"
expires_in: 3600
referenceGrammarId: "fcab5fbf-67c7-bf55-934a-274e525c78a9"
streamUrl: "wss://webchat.botframework.com/v3/directline/conversations/1GJ0N9UYKGyELu3LqpDF6b-a/stream?watermark=-&t=ew0KICAi...."
token: "ew0KICA..."
所以从这里开始,在我看来我应该能够在 postman
中执行以下操作POST https://webchat.botframework.com/v3/directline/conversations/1GJ0N9UYKGyELu3LqpDF6b-a/activities
Content-Type: application/json
Authorization: Bearer {My webchats channels secret code}
Body:
{
"type": "message",
"from": {
"name": "foo"
},
"text": "bar"
}
我希望 200OK 和消息 'bar' 出现在我来自 'foo' 的网络聊天测试中,但它没有。相反,我在 postman 中收到一条错误消息:
{
"error": {
"code": "BadArgument",
"message": "Conversation not found"
}
}
这到底是怎么回事?如果我刚刚创建了那个对话并且可以证明 conversationId 正在使用中,为什么 post 消息说找不到它?我是否错误地使用了频道?或者在这里做一些非常明显的事情?
长话短说,回答我自己的问题。看起来 Microsoft 文档中提供的示例 activity 并没有完全正确。还有 其他 是必需的,尽管我没有时间缩小范围。
由于我 运行 时间不够,我采取的解决方案是编写一种方法将 activity 保存到 cosmosDb 作为身份验证流程的一部分。通过这种方式,我有一个铁定的 activity,我知道它至少在对话的调用阶段有效,而且我知道对话参考是正确且存在的。我从那里拉出 activity 并更改了其中的 4 个字段。
activity.Type = "message",
activity.From = new From { Id = "{BotId}", Name = "Gilbert Bottfried", Role = "bot },
activity.Text = "{My message}",
activity.Subject = "{my message subject}"
从那里开始,本质上就是创建一个连接器客户端并启动这个重新调整用途的 activity。
AppCredentials.TrustServiceUrl(serviceUrl, DateTime.MaxValue);
ConnectorClient client = new ConnectorClient(
new Uri(serviceUrl),
MicrosoftAppId,
MicrosoftAppPassword);
await client.Conversations.SendToConversationAsync(activity.Conversation.Id, activity);
这似乎足以让它正常工作,并且它为以后的消息提供了一个很好的可参考对话 ID。虽然我发现了使用 WebChat 的其他问题,因为我怀疑通过 websockets 发送消息和抛出消息并不是完全稳定的。在 msteams 上的测试体验更加稳定,它似乎可以像冠军一样处理我的测试消息。
这本质上是一种暴力破解方法,因为我正在存储和发送大量不必要的数据,但它确实有效。我可能会将此答案附加到 trim 中,我认为将来有必要,但这需要测试。