Added output handler to handle external processing in workflows - #319
Merged
Conversation
…tputs That also simplifies handling of getting workflow id etc.
…ix to command metadata definition
oskardudycz
force-pushed
the
workflow_router
branch
from
March 10, 2026 11:57
faccef4 to
ee36a33
Compare
oskardudycz
force-pushed
the
workflow_router
branch
from
March 10, 2026 12:10
ee36a33 to
9e093b1
Compare
oskardudycz
force-pushed
the
workflow_router
branch
from
March 10, 2026 12:31
029226f to
f74a54b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This wraps up the last missing piece: how to call external services based on the workflow output (e.g. external Web API, queuing system, etc).
In the article @yreynhout showed the handle method that was just calling external APIs without returning anything. I think that's fine, but I wanted to make it a bit more accessible for people coming from non-EDA background.
I had two options:
decidecould be returning Promise),For now, I went with the former, and added possibly to pass
outputHandlersettings containinghandlemethod that can return: nothing, single input, array of input.I chose the second option instead of async workflow as the problem with async
decidewould create confusion. Currently,decidein a conceptually clear space. It takes state + input, returns outputs. The moment it can call an external API, it becomes an infrastructure function disguised as business logic. You lose the ability to unit-test it without mocking, replay it safely, or reason about it deterministically. Having separated output handler makes it clear that:The fact that the output handler handle method can return a message is helpful for observability (we see the result of the external call and have some sort of double-entry bookkeeping), and it also streamlines workflow processing. We don't need to provide an additional reactor to just handle external API routing. We can set it up here and return the input that will trigger the next step eventually.
If the output handler is set up in processor settings, then its handle method will be called separately from the regular decision logic, it'll be appended, and then processed once the consumer polls it.
The workflow
sequenceDiagram participant S as Event Store Stream participant P as Processor participant W as Workflow (decide) participant R as Output Handler (handle) participant E as External API S->>P: GuestCheckedOut<br/>(input type) P->>W: dispatch — it's an input W-->>S: append ReleaseRoomInPms<br/>(output, no input flag) S->>P: ReleaseRoomInPms<br/>(output type) P->>R: dispatch — not an input R->>E: POST /rooms/release E-->>R: 200 OK R-->>S: append PmsRoomReleased<br/>(input flag = true) S->>P: PmsRoomReleased<br/>(input flag = true) P->>W: dispatch — input flag set W-->>S: append nothing<br/>(workflow done)Example: