Outbox Quarkus Extension
Overview
This extension is inspired by the Outbox Event Router single message transformation (SMT). As discussed in the blog post Reliable Microservices Data Exchange with the Outbox Pattern, microservices often need to exchange information with one another and an excellent way to deal with that is using the Outbox pattern combined with Debezium’s Outbox Event Router SMT.
The following image shows the overall architecture of this pattern:
The Outbox extension’s goal is to provide a Quarkus application with a reusable, highly configurable component that facilitates the use of the Outbox pattern paired with Debezium’s CDC connector pipeline to reliably and asynchronously share data with any consumer of said data.
Getting Started
In order to start using the Debezium Outbox Quarkus extension, the extension needs to be added as a part of the Quarkus application as follows:
<dependency>
<groupId>io.debezium</groupId>
<artifactId>debezium-quarkus-outbox</artifactId>
<version>2.3.2.Final</version>
</dependency>
The extension provides the application with the io.debezium.outbox.quarkus.ExportedEvent
interface. It’s expected that an application class will implement this interface and that the event will be emitted using the javax.enterprise.event.Event
class.
The |
Example
The following example illustrates an implementation of the ExportedEvent
interface representing an order that has been created:
OrderCreatedEvent.java
public class OrderCreatedEvent implements ExportedEvent<String, JsonNode> {
private static final String TYPE = "Order";
private static final String EVENT_TYPE = "OrderCreated";
private final long orderId;
private final JsonNode jsonNode;
private final Instant timestamp;
public OrderCreatedEvent(Instant createdAt, Order order) {
this.orderId = order.getId();
this.timestamp = createdAt;
this.jsonNode = convertToJson(order);
}
@Override
public String getAggregateId() {
return String.valueOf(orderId);
}
@Override
public String getAggregateType() {
return TYPE;
}
@Override
public JsonNode getPayload() {
return jsonNode;
}
@Override
public String getType() {
return EVENT_TYPE;
}
@Override
public Instant getTimestamp() {
return timestamp;
}
@Override
public Map<String, Object> getAdditionalFieldValues() {
// no additional fields
return Collections.emptyMap();
}
}
The following example illustrates an OrderService
that emits the OrderCreatedEvent
:
OrderService.java
@ApplicationScoped
public class OrderService {
@Inject
OrderRepository orderRepository;
@Inject
Event<ExportedEvent<?, ?>> event;
@Transactional
public Order addOrder(Order order) {
order = orderRepository.save(order);
event.fire(new OrderCreatedEvent(Instant.now(), order));
return order;
}
}
When the application code fires the event by calling Event#fire()
, the Outbox extension will be notified that the event occurred and persists the contents of the event into an outbox event table within the scope of the current transaction. The Debezium CDC connector in conjunction with the Outbox Event Router will be monitoring this table and will be responsible for relaying that data using CDC events.
To see a full end-to-end demo, the Outbox example illustrates two Quarkus microservice applications using the outbox pattern to share data between them when orders are placed or cancelled.
Reactive Variant
If your application uses reactive datasources, or Hibernate Reactive, you must use a slightly different configuration to add the extension to your application.
For example, use the following configuration to import the reactive variant of the extension:
<dependency>
<groupId>io.debezium</groupId>
<artifactId>debezium-quarkus-outbox-reactive</artifactId>
<version>2.3.2.Final</version>
</dependency>
The reactive extension provides the application with the same io.debezium.outbox.quarkus.ExportedEvent
interface as the non-reactive variant, but it also provides the DebeziumOutboxHandler
class. Injecting the DebeziumOutboxHandler
bean into an application provides a method for quickly persisting an ExportedEvent
to the outbox table. The following example shows an invocation that uses the same ExportedEvent
as in the earlier example:
OrderService.java
@ApplicationScoped
public class OrderService {
@Inject
DebeziumOutboxHandler debeziumOutboxHandler;
@Inject
OrderRepository orderRepository;
@Inject
Event<ExportedEvent<?, ?>> event;
@ReactiveTransactional
public Uni<Order> addOrder(Order order) {
return orderRepository.persistAndFlush(order)
.call(debeziumOutboxHandler.persistToOutbox(new OrderCreatedEvent(Instant.now(), order)));
}
}
The |
Additional Field mappings
The Debezium Outbox SMT can be configured to read additional fields and emit those field values either as event headers, or as part of the event value.
In order to pass additional field mappings to be saved by the Quarkus Outbox extension, the configuration property quarkus.debezium-outbox.additional-fields
must be specified in the application.properties
. This configuration property is a comma-separated list of additional field definitions that will be added to the Outbox entity mapping and passed by the application’s implementation of the ExportedEvent
interface.
Each entry in this comma-separated list must follow this format:
<field-name>:<field-java-type>[:<field-column-definition>[:<field-jpa-attribute-converter>]]
The pattern indicates that the field’s name and java-type are required while the column definition and JPA attribute converter are optional. However, please note that if you wish to specify a JPA attribute converter then the column definition must be specified.
The following example shows how to define an additional field called customer_name
that is represented in Java as a String
and which should be stored in the outbox table as a VARCHAR(100)
column. This example also shows a JPA Attribute converter defined that forces the storage of the string to upper-case.
application.properties
quarkus.debezium-outbox.additional-fields=customer_name:string:varchar(100):example.UpperCase
Once the field(s) are configured in the application’s .properties
file, the application’s code needs to provide the corresponding values through its exported events. In order to do this, the application class that extends the ExportedEvent
needs to override the method called getAdditionalFieldValues()
and return a Map
of the additional field names and values.
In the following example, we show how to specify the customer_name
field with a value of Acme Goods
. Using our OrderCreatedEvent
from the example section above, we’ve extended the event:
OrderCreatedEvent.java
public class OrderCreatedEvent implements ExportedEvent<String, JsonNode> {
...
@Override
public Map<String, Object> getAdditionalFieldValues() {
return Collections.singletonMap("customer_name", "Acme Goods");
}
}
Additional field mappings do allow specifying a JPA attribute converter per field. In this example, we defined |
With the configuration in the application’s .properties
file and updating of OrderCreateedEvent
to provide these additional fields and values, the Debezium Outbox SMT now can access these additional field values and place them in the emitted event.
Configuration
The Outbox extension can be configured by setting options in the Quarkus application.properties
file. The extension works out-of-the-box with a default configuration, but this configuration may not be ideal for every situation.
Build time configuration options
Configuration property | Type | Default |
| string | OutboxEvent |
| string |
|
| string |
|
| string |
|
| string |
|
| string | |
| string |
|
| string |
|
| string | |
| string |
|
| string |
|
| string | |
| string |
|
| string |
|
| string | |
| string |
|
| string |
|
| string | |
| string | |
| string |
|
| string |
|
| string |
The build time configuration defaults will work with the Outbox Event Router SMT out of the box. When not using the default values, be sure that the SMT configuration matches. |
Runtime configuration options
Configuration property | Type | Default |
| boolean | true |
Distributed tracing
This feature is currently in incubating state, i.e. exact semantics, configuration options etc. may change in future revisions, based on the feedback we receive. Specifically, Distributed Tracing support will be replaced with support for the Open Telemetry specification in a future release. |
The extension has support for the distributed tracing. See tracing documentation for more details.