The ending ID in the parent source this event derived from. If the parent was an RStreams queue, this will
be the event ID. This being set means this event derived from multiple events in the parent queue and
start is the first and end is the last.
Same as end but indicates that the source eid is partial or incomplete. This indicates to the system to NOT checkpoint on this correlation_id
Use either end or partial_end but not both
Same as start but indicates that the source eid is partial or incomplete. This indicates to the system to NOT checkpoint on this correlation_id
Use either start or partial_start but not both
Data that identifies the parent source of this data, often the parent RStreams queue name this event derived from or a table in Mongo or a kinesis stream name, etc.
The starting ID in the parent source this event derived from. If the parent was an RStreams queue, this will
be the event ID. If the parent was a mongo table this would the Mongo tail position, or if from kinesis this
will be the kinesis sequence number, etc. If this event derived from more than one parent event, end will be set.
If this event is derived from multiple parent events, this is how many.
Generated using TypeDoc
This is data stored in an RStreams queue
Eventto understand where this event came from before it got into the queue it is in now, whether that's an external system like Mongo or MS SQL Server or whether this event is a derivative event from an upstream queue.So, let's say that your bot read from Queue A and got event 123 from it. Your bot then transformed event 123 and turned it into some new event that you sent to Queue B as event 789. Your event 789 should keep track of the ancestry of the event, storing here in the correlation information the fact that it came from Queue A, the
source, and event 123 instart.Also note, that sometimes you will have a bot that reads several events from an upstream queue and then writes exactly one aggregate event to a downstream queue. In this case, you want to track the ID of the first upstream event that was aggregated in
startand the last aggregated event inendand set units to the number of total events that got turned into this one event.Developers that don't take the time to add this data to an event. do this will regret it in the future. This information is critical to the trace feature for debugging, both manual tracing to understand where an event came from and botmon's automated visual tracing.