Questions: Use of a reply channel; Send commands when the Process Manager state is persisted

[mariobittencourt]

Hi, first of all thank you for sharing this package. It is really interesting.

While looking at the examples and available documentation I had a couple of questions:
a) Do you support the concept of reply channel?
In most references I found, such as the Enterprise Integration Patterns, I see process managers/sagas that work with orchestration to specify a reply channel where those commands sent to remote systems.
This way they can provide the response form the execution of the commands they receive.
Right now it seems the response is in the form of event(s) being published as the result of the execution.

b) Have you considered to send commands only when the state is persisted?
In the examples you provided I noticed we call the bus.send and then return from the workflow, which is what I understand will trigger the workflow data (the process manager current state) to be persisted.
Since any of those can fail, I wonder if you considered actually wrapping them to have a better control of. So in the workflow you simply say .addCommand and then when you persist the sate of the workflow you actually attempt to send the commands.
It allows you to have a 'transactional' boundary - even if controlled by the code that is abstracted from the user. And it allows the workflow to not depend directly on the bus as it does not actually send anything.

[adenhertog]

Hi @mariobittencourt, great questions!

a) Reply channels isn't something that's implemented, but it's been thought about a lot. I really like the idea which needs a type of ephemeral queue that the originator creates and attaches to the message attributes as part of the send. Any messages produced by the handler would be routable back to the originating queue like what you're suggesting. I don't have any plans to build this out in the near future, but I can certainly add a ticket and PRs are always welcome :)

b) This is one I've been wanting to do for a while leveraging outboxing, that also kills another bird with the same stone. As you pointed out, the current implementation is risky without that transactional boundary so it's definitely a priority. I might not be able to do anything with this immediately but it'd be the next thing that does get done

[mariobittencourt]

Hi @adenhertog thanks for answering.

I will close this as it seems both items are, in some way known to you.

I have to gather more knowledge about your package to be able to contribute code-wise to either initiative, but feel free to ping me if you get something or wants to discuss ideas about them.