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:

Outbox 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:

  1. <dependency>
  2. <groupId>io.debezium</groupId>
  3. <artifactId>debezium-quarkus-outbox</artifactId>
  4. <version>2.1.4.Final</version>
  5. </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 ExportedEvent interface is parameterized to allow the application to designate the Java types used by several attributes emitted by the event. It’s important that for a given Quarkus application, all implementations of the ExportedEvent interface must use the same parameter types or a build failure will be thrown since all events will use the same underlying database table.

Example

The following example illustrates an implementation of the ExportedEvent interface representing an order that has been created:

OrderCreatedEvent.java

  1. public class OrderCreatedEvent implements ExportedEvent<String, JsonNode> {
  2. private static final String TYPE = "Order";
  3. private static final String EVENT_TYPE = "OrderCreated";
  4. private final long orderId;
  5. private final JsonNode jsonNode;
  6. private final Instant timestamp;
  7. public OrderCreatedEvent(Instant createdAt, Order order) {
  8. this.orderId = order.getId();
  9. this.timestamp = createdAt;
  10. this.jsonNode = convertToJson(order);
  11. }
  12. @Override
  13. public String getAggregateId() {
  14. return String.valueOf(orderId);
  15. }
  16. @Override
  17. public String getAggregateType() {
  18. return TYPE;
  19. }
  20. @Override
  21. public JsonNode getPayload() {
  22. return jsonNode;
  23. }
  24. @Override
  25. public String getType() {
  26. return EVENT_TYPE;
  27. }
  28. @Override
  29. public Instant getTimestamp() {
  30. return timestamp;
  31. }
  32. @Override
  33. public Map<String, Object> getAdditionalFieldValues() {
  34. // no additional fields
  35. return Collections.emptyMap();
  36. }
  37. }

The following example illustrates an OrderService that emits the OrderCreatedEvent:

OrderService.java

  1. @ApplicationScoped
  2. public class OrderService {
  3. @Inject
  4. OrderRepository orderRepository;
  5. @Inject
  6. Event<ExportedEvent<?, ?>> event;
  7. @Transactional
  8. public Order addOrder(Order order) {
  9. order = orderRepository.save(order);
  10. event.fire(new OrderCreatedEvent(Instant.now(), order));
  11. return order;
  12. }
  13. }

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.

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:

  1. <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

  1. 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

  1. public class OrderCreatedEvent implements ExportedEvent<String, JsonNode> {
  2. ...
  3. @Override
  4. public Map<String, Object> getAdditionalFieldValues() {
  5. return Collections.singletonMap("customer_name", "Acme Goods");
  6. }
  7. }

Additional field mappings do allow specifying a JPA attribute converter per field.

In this example, we defined example.UpperCase that will convert any supplied string-value to upper-case prior to insertion. A JPA attribute converter allows decoupling this type of behavior from the call site, allowing reuse of a common behavior.

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

id

string

UUID NOT NULL

string

aggregateid

string

VARCHAR(255) NOT NULL

string

string

aggregatetype

string

VARCHAR(255) NOT NULL

string

string

type

string

VARCHAR(255) NOT NULL

string

string

timestamp

string

TIMESTAMP NOT NULL

string

string

payload

string

VARCHAR(8000)

string

string

string

tracingspancontext

string

VARCHAR(256)

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

    quarkus.debezium-outbox.remove-after-insert

    Whether the outbox entry is removed after having been inserted.

    The removal of the entry does not impact the Debezium connector from being able to emit CDC events. This is used as a way to keep the table’s underlying storage from growing over time.

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.