A BPMN engine, meant to be embedded in Go applications with minimal hurdles, and a pleasant developer experience using it. This approach can increase transparency for non-developers.
Marshalling and UnMarshalling should work reliably, and repeatability over multiple iterations of marshall & un-marshall.
Problem
When marshalling, the originActivity got lost, since we don't preserve full history.
It seems the overall approach of keeping track of the origin activity instance, from which the inbound state transfer was made,
is not well suited to keep track in e.g. MessageSubscription struct.
E.g. in the simple case when the origin was a StartEvent, we don't want to marshall that already completed instance information.
Hints
Having a gut feeling, that the commands should rather contain the origin activity information, and we might use some kind of command stack (similar like CPUs work when calling a sub-routine).
Also, the stack approach would help in nesting workflows as well.
Goal
Marshalling and UnMarshalling should work reliably, and repeatability over multiple iterations of marshall & un-marshall.
Problem
When marshalling, the
originActivitygot lost, since we don't preserve full history. It seems the overall approach of keeping track of the origin activity instance, from which the inbound state transfer was made, is not well suited to keep track in e.g. MessageSubscription struct. E.g. in the simple case when the origin was a StartEvent, we don't want to marshall that already completed instance information.Hints
Having a gut feeling, that the commands should rather contain the origin activity information, and we might use some kind of command stack (similar like CPUs work when calling a sub-routine). Also, the stack approach would help in nesting workflows as well.