Is there a way to get all messages belonging to a thread?
We know from https://developers.google.com/hangouts/chat/reference/rest/v1/spaces.messages#Message that a Message belongs to a Thread, is there an API to fetch all messages for a given thread?
I believe that is not possible to get all the messages in a thread, by security design. A bot only receives an event when it is directly mentioned in a message and is only granted access to the text of that message.
The event object received by the bot includes a message object with details of the message, including a reference to the thread.
I wrote a simple Apps Script bot whose onMessage function returns the event object as JSON. The message part of the event provides very limited information about the thread:
"thread": {
"retentionSettings": {
"state": "PERMANENT"
},
"name": "spaces/sKkv0fAAAAE/threads/F6qY-rYiwr0"
},
This behaviour is the same for rooms and DMs.
Human users can scan rooms for threads and threads for messages but bots cannot.
Related
I have a bot running well receiving messages through the Facebook message webhook event. Everything works well when the user sends messages through the messenger app.
But When a user replies to the page story, it generates an incoming message as if it was a standard one and it's not possible to handle this context which is completely different form a user initiated conversation.
Any idea how to receive to differentiate a "standard" message from a "reply to page story" one ? Thx
There is no way to differentiate between these two entry points/sources. Both will trigger a regular message event with no specific attributes added that would allow you to differentiate the source/entry point.
I'm trying to write a small coffeescript for hubot that gets the first message in a thread and posts it to an external script.
I can get the flow id and user id info from the msg object but can't seem to find any object that contains the thread info (messages inside & thread id).
How can I get that?
Thanks.
Chat messages and messages that are created through the messages API have a thread_id and the thread's messages can be retrieved from /flows/:organization/:flow/threads/:thread_id/messages
However Flowdock has older type of messages, that are still created by integrations using the deprecated push API. These messages don't have a thread specified. Instead the comments to those messages are retrieved by finding messages with the tag influx:{message_id} e.g. /flows/:organization/:flow/messages?tags=influx:123456
However this older type of threading will not be supported in the future and all messages will have a thread_id.
I am currently looking to buildout a messaging service where users can send and receive messages privately between each other. I may have a need for multi-user chat, but for the most part, I only want single recipients to be able to read messages sent to them.
With looking at RabbitMQ, does it make sense to use one exchange, and create a queue for each user when they login and destroy each queue on logout? Are there major performance issues with creating a queue for each user or are there better alternatives?
I am building a REST API and plan on having users send messages to others through an endpoint (/send) and subscribe to their own message streams via websockets or something similar. I will probably store messages in MongoDB as well, so users can access all of their previous messages. Any suggestions on structure are appreciated.
I think your approach is correct. You event don't need an exchange if you will use the default exchange (AMQP Default). And during login create a new queue and keep queue name same as user name. (Just need to make sure user names are unique) And if you publish message to the default exchange with username (ie: queue name) as routing key, RbbitMQ will route that message to that queue only. And on logout if you delete the queue then user is going to miss the messages when he is not online. If it is OK then create queue after login and use the configuration exclusive which says queue gets deleted when there is no consumer. But if you want to keep offline messages then you need to create queue permanently during user signup.
I need to get the Id of a msmq message inside of my handler so I can write that Id to a log.
When a message is sent to the error queue an email is sent informing us of a failed message. Once the error that caused the message is resolved we need to use the 'ReturnToSourceQueue' NServiceBus tool to try that message again. Without logging that Id, it would be difficult to track down which message is which when looking through the message queues.
Every where I've looked suggests that Bus.CurrentMessageContext.Id will give me the same Id that's in the Message ID column when looking at the queues in ComputerManagement->Services and Applications->Message Queuing->[Some Queue]->Queue messages. However, those ids don't seem to be the same.
What am I missing?
The reason that the message ID that you see in MMC plugin or Queue Explorer is different is that when the message is "moved" to the error queue, what actually happens is that a new MSMQ message is created with the same body and headers and that is sent to the error queue.
Also, when the processing a message fails, NServiceBus already logs this for you and includes the ID of the message, so that's already done for you.
If you take the ID that was logged and pass that to the ReturnToSourceQueue tool, everything will just work.
The last piece of the puzzle for you is sending an email when a message fails. Now, I'm not sure that that is the wisest idea as you may end up spamming your ops team when a database goes offline or a 3rd party webservice becomes unresponsive. Still, if that's what you want to do, then I'd suggest using an email appender for when errors are logged.
Finally, let me say that we're in the process of building this kind of notification functionality into the Particular Service Platform around NServiceBus. We've got a UI showing errors and allowing messages to be reprocessed coming as a beta in November '13 and the notification functionality will probably be ready towards the end of the year.
It's really a question of whether you want to wait or to build this yourself.
Just create an instance of your bus in your handler:
public IBus Bus { get; set; }
Then use that to get the message id:
this.Bus.CurrentMessageContext.Id
The Bus instance will be injected when the handler is called.
EDIT
Now that I have actually read the question...
The CurrentMessageContext.Id returns what's in the message header under the CorrId field. This can be seen in the Label column in Server Management.
The Message ID displayed in the MessagId column is the message ID as it existed on the sending computer. I am not sure how to access this value from CurrentMessageContext but you should not need to do this to find a local message.
Reading up on CQRS there is a lot of talk of email notification - i'm wondering where to get the data from. Imagine a senario where one user invites other users to an event. To inform a user that he has been invited to an event, he is sent an email.
The concrete steps might go like this:
A CreateEvent command with an associated collection of users to invite, is received by the server.
A new Meeting aggregate is created and a method InviteUser is called for each user that is to be invited.
Each time a user is invited to an event, a domain event UserWasInvitedToEvent is raised.
An email notification sender picks up the domain event and sends out the notification email.
Now my question is this: Where do I go for information to include in the email?
Say I want to include a description of the event as well as the user's name. Since this is CQRS I can't get it thru my domain model; All the properties of the domain objects are private! Should I then query the read side? Or maybe move email notification to a different service entirely?
In CQRS, you're separating the command from the query side. You will always want to go to the query side in order to get data for a given event handler. The write database is going to be a separate database that contains the data necessary for building up your domain objects and will not be optimized for reads, but for writes.
The domain should register and send an EventCreated event to the event handlers / processors. This could be raised from the constructor of the Meeting aggregate.
The event processing component would pick up the EventCreated event, and update the query database with the data contained in the event (ie, the Id of the event and its name).
The domain could register and send a UserWasInvitedToEvent event to the event processors.
The event processors would pick up the UserWasInvitedToEvent and update the query store with any reporting data necessary.
Another event processing component would also pick up the UserWasInvitedToEvent event. This process could have access to the query database and pull back all of the data necessary for sending the email.
The query database is nothing more than a reporting database, so you could even have a specific table that stores all of the data required for the email in one place.
In order to orchestrate several different events into a single handler (assuming the events might be processed in a different order at different times), you could utilize the concept of a Saga in your messaging bus. NServiceBus is an example of a messaging bus that supports Saga's. See this StackOverflow question as well: NServiceBus Delayed Message Processing.