If I send the Get request /v3/botstate/{channelId}/users/{userId} request to the emulator, it returns JSon. Nothing very useful of course since there aren't any real users in it. (doc referenced for the request https://docs.botframework.com/en-us/restapi/state/#/ and https://docs.botframework.com/en-us/csharp/builder/sdkreference/stateapi.html#getsetproperties)
If I send it to Teams, I get a 500 Server error. No additional information is returned with the error, it just repeats that there was a server error.
When I have gotten a 500 sending to Teams before, it was related to the JSon payload being sent. In this case, there is no payload.
The request is in response to a "message" my bot received, and I am passing along the channelId and from.id from that "message" as my parameters.
I am able to send Post "message" requests back, and the Get request /v3/conversations{conversationId}/members successfully, so my Bot seems to be setup correctly.
Anyone have any ideas?
There was a temporary issue with Teams this week. It has been fixed.
The ServiceUrl is not guaranteed to stay the same. It should be refreshed periodically. Please see: https://docs.botframework.com/en-us/csharp/builder/sdkreference/routing.html#connectorclient
NOTE: Even though ServiceUrl values may seem stable bots should not
rely on that and instead always use the ServiceUrl value
As of today, the Bot Framework is still in preview. The developers do their best to not commit breaking changes. The product is under continuous and active development. Thank you for your patience as the kinks are worked out.
Microsoft Teams does not currently support retrieving user information beyond the ID returned in the members call, or the information received as part of incoming payloads. We should have better support for this coming soon.
Related
Summary
I am using the Bot Framework REST API to create and update Microsoft Teams posts.
I have found that I can only update the last two posts of a conversation, but cannot find documentation that describes this restriction.
It is not possible to identify the failed updates from the API response, as the HTTP response code and body is always the same, regardless of whether the update works or not (200 with the id of the "updated" activity). I would expect the response to indicate the failure, and so this appears to be a Teams bug.
Detail
I can create conversations and create replies to conversations using the Bot Framework REST API without issue (using the create conversation and send to conversation endpoints). My problem arises if I try to update these messages.
Given a conversation that looks like this:
parent_message
|_ child_message_1
|_ child_message_2
|_ child_message_3
If I attempt to use the update activty endpoint to update each one of these messages, I observe that:
I can always update parent_message.
I can update child_message_3 and child_message_2, but not child_message_1. In each case the HTTP response is a successful HTTP response (200 response code, with a JSON body that contains the id of the updated message), regardless of whether the update succeeds or not.
If I add another message, child_message_4, then this will be updatable, but child_message_2 will no longer be updatable. I assume this is because now child_message_2 is no longer one of the last two messages.
I see the same behavior if another user adds messages to the conversation, ie. if a user were to make two posts to the conversation I would no longer be able to update any of my own child messages as they are no longer one of the last two messages.
My questions are:
Does anyone know if this restriction is by design? If so, can you point to some documentation on this?
Is it possible to determine when an update fails? As mentioned, the HTTP response always reports success so I'm unable to find a way to do this. Is this a bug in Teams?
Thanks for reporting this. We are able to repro this at our end and we are tracking it here: MicrosoftDocs/msteams-docs#2011
Please follow this issue for updates/progress/questions.
Updates: This is fixed.
This appears to be a bug, but I think the bug is different from what you think it is. Go ahead and "refresh" the conversation and you should see the updates in effect. If you're using the web app then you can refresh the page, but since you're probably using the desktop or mobile app then you could try switching to another conversation and back, or you might have to sign out and sign in again.
I have tried to send MS Teams bot message request via rest api:
End point: https://smba.trafficmanager.net/ca/apis/v3/conversations/{conversation id}/activities
{"text":"test","type":"message"}
And got empty response:
{}
The message i sent did not appear in the conversation.
Any idea where i could have misconfigured?
It is possible that trustServiceUrl needs to be run before a message is sent, i can't find equivalent rest api to call.
You definitely do need call trustServiceUrl before sending the message. In addition, you need to have additional properties on your activity, like the destination user or tenant id. Please refer to the documents on this, and good starting places are here and here.
I've used Microsoft bot framework SDKv4, and integrated to Teams channel. It is running well, but giving responses twice.
But, I didn't get the same behavior, while I tested it on Emulator and Web Chat in Azure Portal.
However, I can see below issue, while I ping the bot in web chat and get a response.
Further, I can also see, that its always 'sending' as a status although I got a valid response, and the status later changes to "Send Failed. Retry"
Is the issue related to my teams integration for getting message twice? and how, should I fix it!
Are you using webhooks? If so, having multiple webhooks with same ID could be the reason for double messages. Hope this helps
I made my bot working. It was the issue of MS authentication!
I had a call with MS support person and the root cause appeared to be only the MS authentication. Had to reset app secret and then re-deloyment.
Its weird that, although it was not getting authenticated primarily yet it was returning me the response. This, I still haven't got it!
Is the webhook connections broken in Microsoft Teams or how do we solve the following issue?
When applying the Microsoft Teams Get Started documentation we get the following response in Postman.
"System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information."
We have set up a webhook in Teams and use it to post Application Insights messages to a Logic App where one of the actions is the webhook to Teams. Everything went fine until now (7/21 and 7/22, 2019) when we saw in Azure the same exception as a response on status 200. To figure this all out we went back to basic and tried to execute the Get Started documentation. The same exception was thrown.
Code that we used was all from the documentation.
After a day or two the exception wasn't returned anymore after NO modifications to the logic app or payload to the Teams webhook. Everything works fine now.
For future use we added an action to the Logic App to read out the webhook's response to determine futher actions, like sending an e-mail if webhook failed.
On facebook Chatbot or others platform we can send message directly to the user.
So for one question we can send multiple answer.
Now, that i'm developing for Google Home, I need to do the same.
I didn't find this opttion.
Dialogflow HTTP call to my server is the only output available.
So is there anything i missed to send message back to user in case I have a multiple messages answer?
(Or do I have to bufferise very message my hook creates before sending it back?)
Thanks
The conversation model for the Google Assistant is different - you can only send a message to the user in response to the user sending you a message. You can only send a single response, but it may have multiple parts (up to two Simple responses, containing messages, plus other features such as cards and carousels).
If you need to send multiple things back - you may need to rethink how you're doing it or how much you're sending back at a time. The Assistant is primarily for audible responses, and a long audible response is generally not a good UX.