Event Queues#2608
Conversation
|
@renejeglinsky @smahati fyi: @dimamost to check for missing java content, then we can merge |
| messaging: | ||
| services: | ||
| - name: messaging-name | ||
| inbox: | ||
| enabled: true |
There was a problem hiding this comment.
The inbox is disabled by default and must be explicitly enabled, as shown in the example. It may also be worth explaining that the inbox uses the default ordered outbox by default. This clarifies how inbound messages are processed and ensures that message handling semantics are understood.
In addition, users can override the default outbox by specifying a custom outbox via the cds.messaging.services..inbox.name configuration property.
There was a problem hiding this comment.
please add to java guide (maybe as part of "Default Outbox Services"?), preferably via follow-up.
Co-authored-by: René Jeglinsky <rene.jeglinsky@sap.com>
Co-authored-by: Dietrich Mostowoj <34100436+dimamost@users.noreply.github.com>
Co-authored-by: Dietrich Mostowoj <34100436+dimamost@users.noreply.github.com>
|
@dimamost please address #2608 (comment) via follow-up @renejeglinsky @smahati ready to merge from my side |
| The two patterns complement each other: when the dispatch target *is* a message broker, the event queue is the transactional bridge that makes pub/sub safe across the local commit. The [Inbox](#inbox) does the mirror image on the receiving side. | ||
|
|
||
| > [!note] Related patterns | ||
| > [*Event Sourcing*](https://microservices.io/patterns/data/event-sourcing.html) solves the same atomic-state-change-and-publish problem by making an append-only event log the source of truth. Event queues persist messages only until processed and then delete them — they're a transactional bridge to remote systems, not the system of record. |
There was a problem hiding this comment.
I stumbled here and gave it a try to rephrase
| > [*Event Sourcing*](https://microservices.io/patterns/data/event-sourcing.html) solves the same atomic-state-change-and-publish problem by making an append-only event log the source of truth. Event queues persist messages only until processed and then delete them — they're a transactional bridge to remote systems, not the system of record. | |
| > [*Event Sourcing*](https://microservices.io/patterns/data/event-sourcing.html) solves the same atomic-state-change-and-publish problem by establishing a source of truth through an append-only event log. Event queues persist messages only until processed and then delete them — they're a transactional bridge to remote systems, not the system of record. |
| > [!tip] `await` is still needed | ||
| > Even though processing is asynchronous, you still need to `await` because the message is written to the database within the current transaction. | ||
|
|
||
| In Java, you can also wrap a service at runtime through the service catalog rather than wiring through Spring: | ||
|
|
||
| ```java | ||
| OutboxService outbox = runtime.getServiceCatalog() | ||
| .getService(OutboxService.class, "XFlightsOutbox"); | ||
| TravelService xflights = runtime.getServiceCatalog() | ||
| .getService(TravelService.class, "xflights"); | ||
|
|
||
| xflights = outbox.outboxed(xflights); | ||
| xflights.bookingCreated(...); | ||
| ``` |
There was a problem hiding this comment.
Are these two things the only runtime-specific things in this section? Everything else is valid for Java and Node.js?
There was a problem hiding this comment.
We could also add the snippet to the code group above with the "header": Java w/o Spring
WDYT?
No description provided.