I have an app using JAIN-SIP. The application will send SIP NOTIFY messages with event type dialog and content-type application/dialog-info+xml.
Is there an API for building the (xml) message body. The javax.sip.message.MessageFactory takes a java.lang.Object for the message body, since the type can vary depending on the request. But are there any libraries to facilitate constructing the format of the body?
Related
I'm sending messages with block elements (buttons) to channel using Slack API. How can I get the username displayed when someone approves or rejects the request? I send the message using chat.postMessage.
You should have interactivity enabled for your app. Since you are using buttons you need to reference how to handle interactive components. Essentially, you need to give your buttons an action_id which is it's unique identifier and will help you determine the source of the action (including the user) when the button is clicked. You will parse the action payload that sent to your app to get the user information you need and use that information in a subsequent call to chat.postMessage.
I was having trouble getting the user with the payload, using body instead worked for me:
In Bolt Python:
#app.action("approve_button")
def approve_request(ack, say, body, payload):
# Acknowledge action request
ack()
user_details = body['user']
username = user_details['name']
.....
I have created the bot in azure services using LUIS, which used as chatbot and can create conversations using dialogs.
At some point, I am trying to push messages to chatbot using Direct Line API 3.0, I'm using Postman to send the messages to bot.
I followed the instructions from this page, 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
I'm able to send message to the conversation as bot, below is the image I sent message from Postman and got successful response.
But my issue is, after the message is sent, the bot tries to analyse even though it's not user message. Bot starts to send message from default message handler like below,
Even after sending the message successfully, my bot triggers the default message handler, which is expected only to happen for user messages but not for bot messages.
Also, I have checked with webchat channel, which it doesn't trigger this default message handler. This is happening only in DirectLine API, can anyone help me on this.
Instead of sending the message as type "message", you should send it as "event".
This way your MessagesController will see it as an ActivityType of Event instead of Message and you can process however you want without spaghettifying your actual message handling
If you want to send different kinds of event to make it even easier, then you can 'name' you event by supplying the 'name' field with a value in your json.
Third, if you need to include data with the message, you would supply a value in the 'value' field of your json.
The github page for the standard webchat client has some great information on sending events. It might shed a bit more light on the json.
You can read more about the 'event' activity type here
You message json would look something more like this:
{
"type": "event",
"from": {
"id": "user1"
},
"name": "theEvent",
"value": "someDataMyBotNeeds"
}
I have set up a HTTP Receive (req-response) adapter and the message appears to be getting to the message box. When I create an orchestration using a direct bound logical port, I am getting the message but everything I have tried to read the message body has failed (using passthrough pipeline, XML pipeline with allow unrecognized files = true) but I get exceptions any time I try to use the incoming message (message assignments, sending the message to a custom module to try to read the part(s)).
Rather than go into details on exceptions, can anyone point to instructions on what the proper way to access/use the body of the HTTP Get messages within an orchestration? To explain what I am trying to do, I want to take the query string (body) and send it verbatim to another orchestration for processing, so I simply want to extract the body (query string) from the message.
For a GET request without a body you need to use the WCF-WebHttp adapter rather than the deprecated BTSHTTPReceive.dll
With the WCF-WebHttp you can use the Variable Mapping to populate message context properties with the URI parameters.
So the answer was to NOT use the HTTP adapter for GET requests. I did not realize the HTTP adapter has effectively been deprecated. For basic GET requests I had to switch to the WCF-WebHTTP adapter and make sure to include the property in the property schema and then make sure to set the schema in the variable mapping as the property schema, not the message type schema of the incoming message. I wish the Microsoft documentation was more clear that the HTTP adapter cannot be used for very basic GET requests in which a body is not provided in the request.
I'm using Logic App to send a message to a service bus on Azure. The logic app starts with a HTTP Request for the trigger which contains a JSON payload in the body. The 'Body' of the request is set as the Content of the Send Message action. Since the payload is JSON when posting I set the Content-Type to application/json. This generates an error on the Send Message action;
{"code":"InvalidTemplate","message":"Unable to process template language expressions in action 'Send_message.' inputs at line '1' and column '1221': 'The template language function 'encodeBase64' expects its parameter to be a string. The provided value is of type 'Object'. Please see https://aka.ms/logicexpressions#encodeBase64 for usage details.'."}
So tried changing the Content-Type to text/plain and it works? Is this a bug or should convert the JSON to a text value somehow before using it in the Send Message action?
Sending a message to service bus requires the message content to be base64 encoded. Since your content is a JSON, you would need to stringify it explicitly prior to encoding, i.e. use #encodeBase64(string(jsonContent))
Changing the content type to text/plain has the same effect, since in that case the content is treated as a string to begin with.
Using ServiceStack 3.9.2x.
Out of the box (and as seen on the metadata page) service stack comes with built-in support for a bunch of content types - xml, json, jsv, etc. What is the best way to tell ServiceStack to limit the set of supported content. For example my service only knows how to speak JSON and I don't want ServiceStack to honor requests that sport "Content-type: application/xml" or "Accept: application/xml" headers. In said case I would like ServiceStack to respond with a 406 (Not Acceptable) response, ideally including in the body the set of supported content (per HTTP 1.1 spec).
Also how does ServiceStack decide what the default type of the content is for requests that do not sport an Accept or Content-Type header (I think I am seeing it render HTML now)? Is there a way to tell ServiceStack to assume a specific content type in these cases?
See this answer to find out how to set the default content type in ServiceStack: ServiceStack default format
You can use a Request Filter to detect the requested content type with:
httpReq.ResponseContentType
In your global request filter you can choose to allow it (do nothing) or write directly to the response, e.g. 406 with list of supported content as you wish.
ServiceStack order of operations
The Implementation architecture diagram shows a visual cue of the order of operations that happens in ServiceStack. Where:
EndointHostConfig.RawHttpHandlers are executed before anything else, i.e. returning any ASP.NET IHttpHandler by-passes ServiceStack completely.
The IAppHost.PreRequestFilters gets executed before the Request DTO is deserialized
Request Filter Attributes with Priority < 0 gets executed
Then any Global Request Filters get executed
Followed by Request Filter Attributes with Priority >= 0
Action Request Filters (New API only)
Then your Service is executed
Action Response Filters (New API only)
Followed by Response Filter Attributes with Priority < 0
Then Global Response Filters
Followed by Response Filter Attributes with Priority >= 0
Any time you close the Response in any of your filters, i.e. httpRes.Close() the processing of the response is short-circuited and no further processing is done on that request.