Package dk.cloudcreate.essentials.components.foundation.messaging.eip.store_and_forward
package dk.cloudcreate.essentials.components.foundation.messaging.eip.store_and_forward
-
ClassDescription
Inboxesvariant that usesDurableQueuesas the underlying implementation.
ONLY in cases where the underlyingDurableQueuesis associated with aUnitOfWorkFactorywill theInboxmessage consumption be performed withinUnitOfWork, otherwise message consumption isn't performed with aUnitOfWorkThe name of anInboxDefines how messages can be consumed by the provided message consumerTheOutboxsupports the transactional Store and Forward pattern from Enterprise Integration Patterns supporting At-Least-Once delivery guarantee.
TheOutboxpattern is used to handle outgoing messages, that are created as a side effect of adding/updating an entity in a database, but where the message infrastructure (such as a Queue, Kafka, EventBus, etc.) that doesn't share the same underlying transactional resource as the database.
Instead, you need to use anOutboxthat can join in the sameUnitOfWork/transactional-resource that the database is using.
The message is added to theOutboxin a transaction/UnitOfWorkand afterwards theUnitOfWorkis committed.
If the transaction fails then both the entity and the message will be rolled back when thenUnitOfWorkrolls back.
After theUnitOfWorkhas been committed, the messages will be asynchronously delivered to the message consumer in a newUnitOfWork.
TheOutboxitself supports Message Redelivery in case the Message consumer experiences failures.
This means that the Message consumer, registered with theOutbox, can and will receive Messages more than once and therefore its message handling has to be idempotent.TheOutboxsupports the transactional Store and Forward pattern from Enterprise Integration Patterns supporting At-Least-Once delivery guarantee.
TheOutboxpattern is used to handle outgoing messages, that are created as a side effect of adding/updating an entity in a database, but where the message infrastructure (such as a Queue, Kafka, EventBus, etc.) that doesn't share the same underlying transactional resource as the database.
Instead, you need to use anOutboxthat can join in the sameUnitOfWork/transactional-resource that the database is using.
IF the message is added to theOutboxin a transaction/UnitOfWorkand theUnitOfWorkis committed together (this is dependent on the underlying implementation - seeOutboxes.DurableQueueBasedOutboxes).
In case adding the message happens in a shared transaction/UnitOfWork, then if the transaction fails then both the entity and the message will be rolled back when thenUnitOfWorkrolls back.Outboxesvariant that usesDurableQueuesas the underlying implementation.
ONLY in cases where the underlyingDurableQueuesis associated with aUnitOfWorkFactorywill theOutboxmessage consumption be performed withinUnitOfWork, otherwise message consumption isn't performed with aUnitOfWorkThe name of anOutboxPattern matching Consumer<Message> for use withInboxes/InboxorOutboxes/Outbox
ThePatternMatchingMessageHandlerwill automatically call methods annotated with the @MessageHandler annotation and where the 1st argument matches the actual Message payload type (contained in theMessage.getPayload()provided to the providedConsumer)