I have an application that will provide async response when asked a question like "How are you?"
My application will say "I am good" after some time.
I can provide the URL in my initial question which can be used to reach JMeter. But how do I get JMeter to accept the response?
Here is what my request look like:
"conversation": {
"id": "111" // unique id for each conversation
},
"serviceUrl": "http://localhost:54673" // the callback url for response
"text": "How are you?"
Here is where the response will be posted to:
Response URL: http://localhost:50643/v3/conversations/111/activities
And here is the content:
{
"type": "message",
"conversation": {
"id": "111"
},
"text": "I am good"
}
This response is async so it's a new connection. How do I setup JMeter to do this? And what would be the Response URL for me to send msg to?
If you plan to use JMeter the only way I can think of is querying the Response URL in a loop using While Controller until you get a response or timeout occurs.
However from request and response types it appears you're trying to test a Microsoft Bot Framework based application so it would make more sense to consider Visual Studio Load Testing tools for this. Check out BOT Testing with VSTS sampler project for more details. You can also find MockChannel example useful.
Related
I am developing a Smart Home Action for Google Home, and I am trying to use the Test Suite to test the handling of EXECUTE intents sent to my fulfilment URI in the backend. I have successfully linked a test account and can populate the test cases with devices and traits (actions.devices.SHOWER devices)
However, when testing the StartStop trait, the Test Suite does not ever send an EXECUTE intent to the fulfilment URI to attempt to Start/Stop the device. The QUERY intent that is triggered after this test case fails is received correctly by my backend: see the test case screen
I have verified that the test case passes if I manually perform the necessary device state update and trigger a report state via Google Homegraph API while this "Start the Office" command is running. But I can see from my Http request logs that I never receive an EXECUTE intent, nor are there any entries in the Cloud Console logs showing an attempt to call the backend.
I have attempted re-linking my account, and using multiple test accounts but this behaviour does not change. The response I am sending to the SYNC is
{
"requestId": "9346220314501836318",
"payload": {
"devices": [
{
"id": "1002",
"type": "action.devices.types.SHOWER",
"traits": [
"action.devices.traits.StartStop",
"action.devices.traits.TemperatureControl"
],
"name": {
"name": "Office"
},
"attributes": {
"temperatureRange": {
"minTemperatureCelcius": 0,
"maxTemperatureCelcius": 60
},
"temperatureUnitForUX": "C",
"commandOnlyTemperatureControl": true,
"temperatureStepCelcius": 1,
"pausable": false
},
"willReportState": true,
"deviceInfo": {
"manufacturer": "REMOVED",
"model": "TestModel",
"hwVersion": null,
"swVersion": null
}
}
],
"agentUserId": "1000"
}
}
Are there any configuration errors that might cause the Test Suite to fail to send the EXECUTE intent? Or is this a bug?
I am not able to control these devices from Google Assistant directly (from my phone) - I get the error "this device has not been set up yet" but see no options to add it as a controllable device from the Home Control screen in the Assistant app settings.
Thank you for highlighting the issue. I can reproduce it on my side. Can you please open a bug in Public issue tracker for further debugging and share the same information there.
I’m going to follow up with the team and update you through the issue tracker.
I'm working on implementing opsgenie for the first time, with a new airflow instance. I have been unable to receive alerts so far, even though everything seems to be correctly set up.
I already have my account/team and integrations (slack and api) set. I already configured the opsgenie conection in airflow (using the slack api key as password). An I already added the opsgenie hook to my code.
It all seems to work ok. According to the airflow logs, the opsgenie genie request is correctly sent. I even get responses like this:
Sending 'POST' to url: https://api.opsgenie.com/v2/alerts
<Response [202]>
{'result': 'Request will be processed', 'took': 0.007, 'requestId': '65f2a665-40ea-4173-967e-xxxxxxxxxx'}
If I search for the request id, I get this response:
{
"data": {
"success": true,
"action": "Create",
"processedAt": "2023-01-03T16:40:03.08Z",
"integrationId": "xxx",
"isSuccess": true,
"status": "Created alert",
"alertId": "xxx",
"alias": "ECO_OPSGENIE_ALERTS-send_opsgenie_alerts-20230103"
},
"took": 0.004,
"requestId": "65f2a665-40ea-4173-967e-xxxxxxxxxx"
}
However, NO alerts are ever sent, and I can't see them anywhere in the opsgenie alerts section. And of course I also get bothing on slack or on the opsgenie app.
If I create a "manual" alert using the opsgenie app, I do get slack and app alerts... but nothing using the API.
I also tried directly from postman, but same thing: no alerts are sent, even though the response says they were correctly created.
Any idea what could be causing this and how to solve it?
Not sure if anyone will need this, but I solved it. I had to add this parameter to the request's body:
"responders": [
{
"name": team_name,
"type": "team"
}
]
team_name is the name of my configured team in opsgenie. That's it. Now it's all working.
We are trying to create an approval workflow using Teams, Flow, and Assembla and are running into a bit of trouble.
We have a few of the pieces successfully setup however we are unable to initiate a POST action from a card in Teams.
In teams we can successfully create a card using the incoming webhook connector with this result.
This is created with the following JSON body from a POST action in Flow
{
"##type": "MessageCard",
"##context": "http://schema.org/extensions",
"summary": "This is the summary property",
"themeColor": "f46b42",
"sections": [
{
"startGroup": true,
"title": "**Pending Review**",
"activityTitle": "Ticket Title",
"activitySubtitle": "Requested by: ",
"facts": [
{ "name": "Date submitted:", "value": "06/27/2017, 2:44 PM" },
{ "name": "Details:",
"value": "This ticket is ready for review." }
]
},
{
"potentialAction": [
{
"##type": "HttpPOST",
"name": "Approve",
"target": "ANOTHER-POST-URL-IS-HERE"
},
{
"##type": "HttpPOST",
"name": "Deny",
"target": "ANOTHER-POST-URL-IS-HERE"
}
]
}
]
}
We have another Flow url as the target for both buttons on the card. To test this url we are able to successfully post via POSTMAN and continue the approval workflow.
When clicking the button on the Team card the Flow at the post url is in no way notified at all. No run on Flow is triggered. In teams a very generic "There was a problem submitting your changes. Try again in a minute." error is displayed.
After researching I ran across the connectors.md file on the Microsoft Teams github page and noticed this lovely part of the documentation
It seems odd to me that right below them mentioning that POST actions may not be supported the documentation goes on in length to show examples of using POST and ActionCard actions in a card on teams.
So my question is this, is there any way to get an HttpPOST action to work from a custom card in Teams to a Microsoft Flow POST URL?
Thanks!
Update:
Upon further testing we have determined that HttpPOST actions
work with just about any post url we can come up with except
Microsoft Flow Request URLs. They are exceptionally long urls so maybe
that has something to do with it?
Here's an example Flow request url.
https://prod-43.westus.logic.azure.com:443/workflows/f86b928acd3d4ecab849f677974f7816/triggers/manual/paths/invoke?api-version=2016-06-01&sp=%2Ftriggers%2Fmanual%2Frun&sv=1.0&sig=ZBxr5GFKQhMp4JXWGmec_L6aqgcaqvCOKUWOf2li-xQ
When running teams in a web browser we are able to see the request
first posts to a api.teams.skype.com url and returns a generic
"ProviderError". Other non-flow urls also do the same but return
success.
This was a head-scratcher for us - as you surmised, this should have worked. The Teams, Flow, and Outlook teams troubleshooted this today and found out what was going on.
The URL you are posting to, https://prod-43.westus.logic.azure.com[...] has an embedded bearer token (the value of the sig parameter in the URL). When you POST to that URL via CURL, Fiddler, Postman, etc. it works because that token is present.
However, when you click on a HttpPOST button in an actionable message, Outlook adds its own JWT token in the HTTP header, meaning that the HTTP POST has both a sig= bearer token in the URL and a JWT token in the HTTP header. Flow detects this and rejects the HTTP POST as invalid (while we don't currently support JWT tokens, we plan to, and treat this case as invalid to maintain forward compatibility).
This use case will work in the future. In the meantime, one workaround to try would be to have the actionable message buttons POST to your endpoints, e.g. https://yoursite.com/accept and https://yoursite.com/deny (validating the JWT as much as you like) and have these endpoints POST to Flow directly without the JWT.
Please let us know if that works.
BTW, the text you found is a documentation bug that has since been fixed:
Sorry for the confusion.
I'm building a client which will interact with an existing bot built using the Microsoft Bot Framework. The bot works fine when I test with the existing channels. I can also successfully start a conversation when using the Direct Line API. However when I try to send a message to the bot using Direct Line API I get a 500 error with content "ServiceError".
I am sending an http Post request using Fiddler to https://directline.botframework.com/v3/directline/conversations/[MyConversationID]/activities with the following header:
Authorization: Bearer <My Secret>
Host: directline.botframework.com
Content-Length: 97
And Body
{
"type": "message",
"from": {
"id": "user1"
},
"text": "hello"
}
I am fairly certain the issue is not in my bot code as no breakpoint is hit. Has anyone had a similar issue? Or have any advice on how to go about debugging it?
My bot based on the bot framework works pretty good. But when I first interact with the bot after a period of inactivity (let's say a day), then the bot seems to take very long time (about 10-45 seconds) to send back its first reply. After that reply the response time is pretty good again.
To me it seems the back-end service goes to some kind of sleep mode and the 1st request wakes it up.
Is there any way to influence this behavior? I concerned about the long initial response time for my users.
Thanks for your help.
If using Azure website, see "Always On Support"
https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-configure
Always On. By default, web apps are unloaded if they are idle for some period of time. This lets the system conserve resources. In Basic or Standard mode, you can enable Always On to keep the app loaded all the time. If your app runs continuous web jobs, you should enable Always On, or the web jobs may not run reliably.
I'm keeping the bot awake by periodically (every 15min) opening a conversation and sending a first message (activity) to the bot.
First, I start a conversation:
POST https://directline.botframework.com/v3/directline/conversations
Authorization: Bearer SECRET_OR_TOKEN
I got the SECRET_OR_TOKEN from the Azure resource: Azure Bot -> channels -> Web Chat -> e.g. Default Site -> Secret Keys
That's what a sample response from the docs looks like:
HTTP/1.1 201 Created
{
"conversationId": "abc123",
"token": "RCurR_XV9ZA.cwA.BKA.iaJrC8xpy8qbOF5xnR2vtCX7CZj0LdjAPGfiCpg4Fv0y8qbOF5xPGfiCpg4Fv0y8qqbOF5x8qbOF5xn",
"expires_in": 1800,
"streamUrl": "https://directline.botframework.com/v3/directline/conversations/abc123/stream?t=RCurR_XV9ZA.cwA..."
}
link to docs about creating a new conversation: https://learn.microsoft.com/en-us/azure/bot-service/rest-api/bot-framework-rest-direct-line-3-0-start-conversation?view=azure-bot-service-4.0#open-a-new-conversation
Then, I send a simple messsage (activity) as part of the conversation I just started:
POST https://directline.botframework.com/v3/directline/conversations/{conversation-id-received-from-create-conversation-request}/activities
Authorization: Bearer {token-received-from-create-conversation-request}
Content-Type: application/json
[other headers]
{
"locale": "en-EN",
"type": "message",
"from": {
"id": "user1"
},
"text": "hello"
}
You will have to replace the token and conversation Id in the request above. They are both returned in the start a conversation request.
here is a link to the docs about sending an activity to a conversation: https://learn.microsoft.com/en-us/azure/bot-service/rest-api/bot-framework-rest-direct-line-3-0-send-activity?view=azure-bot-service-4.0#send-an-activity