[id="registry-cloud-events_{context}"]
= Configuring {registry} event sourcing

ifdef::apicurio-registry[]
IMPORTANT: This is a Technology Preview feature only, which might evolve in future releases. Before using this feature in production, make sure to test that your deployment works as expected. Review the Release Notes in future releases for updates on this feature.
endif::[]

ifdef::service-registry[]
[IMPORTANT]
====
This is a Technology Preview feature only.
Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete.
Red Hat does not recommend using them in production. 

These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview.
====
endif::[]

You can configure {registry} to send events when changes are made to registry content. For example, {registry} can trigger events when schema or API artifacts, groups, or content rules are created, updated, deleted, and so on. You can configure {registry} to send events to your applications and to third-party integrations for these kind of changes.

There are different protocols available for transporting events. The currently implemented protocols are HTTP and Apache Kafka. However, regardless of the protocol, the events are sent by using the CNCF CloudEvents specification. You can configure {registry} event sourcing by using Java system properties or the equivalent environment variables.

[discrete]
== {registry} event types
All of the event types are defined in `io.apicurio.registry.events.dto.RegistryEventType`. For example, these include the following event types:

* `io.apicurio.registry.artifact-created`
* `io.apicurio.registry.artifact-updated`
* `io.apicurio.registry.artifact-state-changed`
* `io.apicurio.registry.artifact-rule-created`
* `io.apicurio.registry.global-rule-created`
* `io.apicurio.registry.group-created`


.Prerequisites

* You must have an application that you want to send {registry} cloud events to. For example, this can be a custom application or a third-party application.

[discrete]
== Configuring {registry} event sourcing by using HTTP

The example in this section shows a custom application running on `\http://my-app-host:8888/events`. 

.Procedure

. When using the HTTP protocol, set your {registry} configuration to send events to a your application as follows:

** `registry.events.sink.my-custom-consumer=http://my-app-host:8888/events`

. If required, you can configure multiple event consumers as follows:
** `registry.events.sink.my-custom-consumer=http://my-app-host:8888/events`
** `registry.events.sink.other-consumer=http://my-consumer.com/events`


[discrete]
== Configuring {registry} event sourcing by using Apache Kafka

The example in this section shows a Kafka topic named `my-registry-events` running on `my-kafka-host:9092`. 

.Procedure

. When using the Kafka protocol, set your Kafka topic as follows:
** `registry.events.kafka.topic=my-registry-events`

. You can set the configuration for the Kafka producer by using the `KAFKA_BOOTSTRAP_SERVERS` environment variable:
** `KAFKA_BOOTSTRAP_SERVERS=my-kafka-host:9092`
+
Alternatively, you can set the properties for the kafka producer by using the `registry.events.kafka.config` prefix, for example:
`registry.events.kafka.config.bootstrap.servers=my-kafka-host:9092`

. If required, you can also set the Kafka topic partition to use to produce events:
** `registry.events.kafka.topic-partition=1`

[role="_additional-resources"]
.Additional resources
* For more details, see the link:https://cloudevents.io/[CNCF CloudEvents specification].
