Replies: 3 comments 3 replies
-
You can achieve that, just like in Synapse, by evaluating your correlations at the time events are consumed, thus allowing you to select the event's data or attributes, or even the current state data. Note that this implies the runtime must support expression based correlation attribute values, which is an opiniated implementation, as the spec does not define that specific feature. Furthermore, for complex correlation use cases that imply more than a single correlation key, we would need to define a new key property in the spec at the correlation attribute level, allowing coexistence of different keys (the spec only supports a single one as of now) |
Beta Was this translation helpful? Give feedback.
-
Thank you so much for the answer, using an expression as the correlation key makes sense, do you know if there are any plans to have more than one correlation key in the spec in the future? |
Beta Was this translation helpful? Give feedback.
-
I'm closing the discussion as it applies to a discontinued version of the spec. @bakjos @brampurnot I invite you to take a look at the brand new listen task, which allows what was discussed here and much more! Please feel free to open a new discussion/issue if you have any question! |
Beta Was this translation helpful? Give feedback.
-
I have the following use case and am not sure how it can be handled: I’m using a callback state to wait for a human task, the action will create the task and return the task Id and it will wait for an event with the same event type and source, and the task id can be part of the context attributes, but it will wait for any event, not for the one matching the specific task id
Beta Was this translation helpful? Give feedback.
All reactions