Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.
Sign upAdd sequence to Events emitted by Runtime Bundle #2142
Comments
salaboy
added this to the Beta3 milestone
Nov 9, 2018
salaboy
added this to Open
in Activiti 7.x
via automation
Nov 9, 2018
salaboy
modified the milestones:
Beta3,
Beta4
Nov 9, 2018
salaboy
added
the
api-events
label
Nov 12, 2018
salaboy
modified the milestones:
Beta4,
Beta5
Nov 25, 2018
miguelruizdev
self-assigned this
Dec 10, 2018
salaboy
modified the milestones:
Beta5,
RC1
Dec 14, 2018
salaboy
added
the
risk
label
Jan 7, 2019
salaboy
modified the milestones:
RC1,
RC2
Jan 8, 2019
This comment has been minimized.
This comment has been minimized.
We need to clearly define the usage and presence of this new field. @salaboy is the scope of the field
We get this:
The intention behind this issue is to have a field in each of the events that establishes a sequence number based on chronological order, but without relying in the timestamp, right? |
This comment has been minimized.
This comment has been minimized.
@salaboy A different approach would be populating that field once is persisted in the database on the consumer end, without the need for establishing in the runtime bundle. |
This comment has been minimized.
This comment has been minimized.
@miguelruizdev we need to generate from the producer side.. in the same way that we do with the timestamp. |
This comment has been minimized.
This comment has been minimized.
@salaboy we set the timestamp at the moment of instantiation in every event: The value of sequenceNumber will depend on the existence of other events, so that place needs to have that information. Also, the lifespan of this sequence should be bound to the execution of a process, right? |
This comment has been minimized.
This comment has been minimized.
Regarding the transaction unique identifier, do we have model for transactions? |
This comment has been minimized.
This comment has been minimized.
@miguelruizdev after discussing this with @erdemedeiros and @ryandawsonuk I think that we agreed that we should:
I would start with that basic approach first.. then we can see if we need to change Query as well. |
This comment has been minimized.
This comment has been minimized.
Then, I guess that the place where to start in RB is the MessageProducerCommandContextCloseListener. Regarding the changes in the api layer, I think that the addition of a method in CloudRuntimeEvent and its implementation will suffice. |
This comment has been minimized.
This comment has been minimized.
@miguelruizdev you need to start in query.. both of my points were in query service. No need to touch RB |
This comment has been minimized.
This comment has been minimized.
@salaboy @erdemedeiros @ryandawsonuk regarding the value of the Header the message carries, will it be enough to have a UUID or do we need a specific value already present? Will it be a value we extract from the execution itself? |
This comment has been minimized.
This comment has been minimized.
Regarding the id of the batch of events processed by audit, the logical place for those changes to take place seems to be AuditConsumerChannelHandlerImpl. But then, one question arises: Audit is a dumb consumer since we don't process the data we get from the outside world, we just store it. Is this right from a design point of view? |
This comment has been minimized.
This comment has been minimized.
@miguelruizdev it is totally right as soon as we decorate the data that we are getting. So it is ok to do it there. |
Jan 23, 2019
This was referenced
This comment has been minimized.
This comment has been minimized.
merged |
salaboy commentedNov 9, 2018
Each event sent by the Runtime Bundle should include a sequence number which helps to identify the order of the event inside the transaction. Each event is providing a timestamp, but this is not enough to understand which event happened first from the consumer side (ie audit, query).