If we are posting a message at Yammer using Java and later want to retrieve the same message using its thread id, then how can we get that particular message's thread id?
The thread ID should match the original message ID of your thread starter (the first message in the thread.) You can see this if you post the first message in a thread, reply to it, and then delete the first message (which leaves only your reply.)
Looking at the API response for the thread you'll see that the thread ID matches the original message ID which you deleted. My steps above are more than you actually need to observe the behaviour, but it helps confirm that the thread ID doesn't mutate.
Related
Using the slack_sdk in python, I am attempting to store who reacts to a message sent by the bot, and what what specific message they reacted to. The payload I get from a reaction_added lets me know who sent the message someone reacted to, but not the specific message event_id. Is there some way where I can tell what message someone reacted to?
the Payload received does not seem to carry the data I need. I checked the api docs, but couldn't find how to get more information on the event_id of a message someone reacted to.
The Event IDs for each event are only so useful for correlating activities between events. You won't really find a way to link the actual event describing "what happened" with another event.
However, you can correlate what the events reference together. In reaction_added you receive a bundle of data in item describing what the item_user reacted to. When it's a message, type will be set to message, channel will indicate the ID of the channel where the message belongs and the ts value will point to a specific message ID in that channel.
If you previously received (& persisted) the message that has been reacted to, you'll need to correlate that with the ts and channel values you'll also find in each message.
If you don't have that message and need more data about it and have the appropriate permission scopes, you can use the Web API method conversations.history to fetch a single message as documented here.
I have a bean which is MessageHandler to handle an incoming message. The message handler is of type org.springframework.integration.aws.outbound.S3MessageHandler, which uploads the message to amazon s3. The issue is that, the operations of this message handler is performed in a different thread. How can I ensure that I can track the transaction id is propagated all the way to the thread performing this transaction?
DEBUG [app-name,,] 22540 --- [anager-worker-1]
Also attached to this message handler is a progress listener of type com.amazonaws.services.s3.transfer.internal.S3ProgressListener. The callbacks to this listener are performed within a different thread altogether. I need the trace ids in this listener too.
INFO [app-name,,] 22540 --- [callback-thread]
You may use MDC logging feature and log your trace id and span id.
The key problem that you have several threads for processing that leads to question how to correlate the logs between them.. so,
Put traceid+span+unique message id into MDC of thread that processing request
Put uniq message id into MDC of thread that MessageHelper uses
Modify your appenders to print traceid, span, unique message id into logs
Such fields could be well indexed by ELK (or any similar tool, even grep).
Then, by searching in logs by uniq message id you'll find all logs record + threads names and other details like traceid and spanid
Sleuth can do this for you, you need to check the docs how to use its API: https://docs.spring.io/spring-cloud-sleuth/docs/current/reference/html/using.html#using-creating-and-ending-spans
As you can see there, you can create a Span and you can also create a Scope (in SpanInScope ). The Scope is responsible for the context propagation, e.g.: handling the MDC for you so you don't need to do anything with the MDC.
What you need to do though is properly using this API so the context is propagated. This is usually done by instrumenting the ExuecutorService/CompletionService and/or Runnable/Callable (whichever you use). Here's how to implement such a thing:
Get the current Span in the caller thread (tracer.currentSpan())
Use this span and create a Scope (and a new Span if you need) in the "other" thread (inside of the thread-pool)
You don't need to do this on your own, Sleuth has a TraceRunnable (this is doing exactly what I described above) and a TraceableExecutorService.
Greg Young, author of Event Store, defined a while ago the correlation ID to reference the root cause and the causation ID to reference the direct cause of a message.
Therefore you should be able to find the one message to which another message is a direct response through the other message's causation ID. And you should be able to find all messages within the same conversation by them having the same causation ID.
If this pattern is applied, the second message in a conversation should have both the correlation ID and the causation ID set to the first message.
In Commanded, I would have expected the first event to have both correlation ID and causation ID to point to the command which caused the event to occur (also visually described here).
Confusingly in Commanded's own event store, it seems, that the first event after a command has differing correlation and causation IDs. So it seems Commanded doesn't apply Greg Young's definition.
My question would be, what exactly is the definition for these IDs in Commanded? Was it a conscious decision not to follow Greg Young's definition, and if so, why?
Commanded has implemented correlation and causation ids as described in the guides, copied below.
By default commands will not be persisted, therefore you cannot follow the chain of cause and affect from command > event > command unless you also persist incoming commands. You can use Commanded audit middleware to store dispatched commands to any Ecto supported database. Doing so will allow you to tie commands and their resultant events together. The correlation id can also be used to associated all related messages, assuming you are copying them when dispatching commands. There's an example of doing so given below.
In Greg's Event Store I think the causation id is copied from event to event, ignoring the intermediate command, since his event store is only storing the events.
Correlation and causation ids
To assist with monitoring and debugging your deployed application it is useful to track the causation and correlation ids for your commands and events.
causation_id - the UUID of the command causing an event, or the event causing a command dispatch.
correlation_id - a UUID used to correlate related commands/events.
You can set causation and correlation ids when dispatching a command:
:ok = ExampleRouter.dispatch(command, causation_id: UUID.uuid4(), correlation_id: UUID.uuid4())
When dispatching a command in an event handler, you should copy these values from the event your are processing:
defmodule ExampleHandler do
use Commanded.Event.Handler, name: "ExampleHandler"
def handle(%AnEvent{..}, metadata) do
%{event_id: causation_id, correlation_id: correlation_id} = metadata
ExampleRouter.dispatch(%ExampleCommand{..},
causation_id: causation_id,
correlation_id: correlation_id
)
end
end
Commands dispatched by a process manager will be automatically assigned the appropriate causation and correlation ids from the source domain event.
In my mail app I'm moving messages between folders by using MoveItem operation. When you move messages their ids are changed. In the response I'm receiving the new message ids. But the old ones are missing. And this is a big problem.
I have no idea how to map a new message id to an old one and can't update messages in my database with the new ids. Seems like I don't understand something simple. What's the point of returning new ids if you have no idea what message each one belongs to?
Am I supposed to rely on the order of response messages? If so can you please give me a link to the corresponding piece of EWS documentation?
Or am I supposed to perform synchronization of mailboxes every time I move more than one message?
When you used MoveItems you would have passed in an array of ItemId's and what you get back as a result is an Array of objects.
The order of the items in the Response collection matches the order in your request so element 1 of the response represents the results of the element 1 request. So you can just map them this way.
However your response logic should be more complex to deal with issues where half of your request being executed okay while x% failed because of throttling etc (so check the response status of each request) or getting a 501 mid move where you could get into an unknown state.
We're moving from Mandrill to SparkPost. We figured that SparkPost's transmission is the closest thing to Mandrill's send-template message call.
Mandrill responded to those calls with a list of ids and statuses for each email. On the other hand SparkPost returns a single id and summary statistics (number of emails that were sent and number of emails that failed). Is there some way to get those ids and statuses out of the transmission response or at all?
you can get the message IDs for messages sent using the tranmissions API two ways:
Query the message events API, which allows you to filter by recipients, template IDs, campaign IDs, and other values
Use webhooks - messages are sent to your endpoint in batches, and each object in the batch contains the message ID
Which method you choose really depends on your use case. It's essentially poll (message events) vs. push (webhooks). There is no way to get the IDs when you send the transmission because they are sent asynchronously.
Querying message events API, while a viable option, would needlessly complicate our simple solution. On the other hand we very much want to use Webhooks, but not knowing which message they relate to would be troublesome...
The missing link was putting our own id in rcpt_meta. Most of the webhooks we care about do contain rcpt_meta, so we can substitute message_id with that.
I'm stacked too in this problem..
using rcpt_meta solution would be perfect if substitution would work on rcpt_meta but it's not the case.
So, in case of sending a campaign, I cannot specify all recipients inline but have to make a single API call for every message, wich is bad for - say - 10/100k recipients!
But now, all transmission_id are unique for every SINGLE recipient, so I have the missing key and rcpt_meta is not needed anymore.
so the key to be used when receiving a webhook is composed:
transmission_id **AND** rcpt_to