HTTP
This page describes the usage of the Stream Reactor HTTP Sink Connector.
A Kafka Connect sink connector for writing records from Kafka to HTTP endpoints.
Features
Support for Json/Avro/String/Protobuf messages via Kafka Connect (in conjunction with converters for Schema-Registry based data storage).
URL, header and content templating ability give you full control of the HTTP request.
Configurable batching of messages, even allowing you to combine them into a single request selecting which data to send with your HTTP request.
Connector Class
Example
For more examples see the tutorials.
Content Template
The Lenses HTTP sink comes with multiple options for content templating of the HTTP request.
Static Templating
If you do not wish any part of the key, value, headers or other data to form a part of the message, you can use static templating:
Single Message Templating
When you are confident you will be generating a single HTTP request per Kafka message, then you can use the simpler templating.
In your configuration, in the content property of your config, you can define template substitutions like the following example:
(please note the XML is only an example, your template can consist of any text format that can be submitted in a http request)
Multiple Message Templating
To collapse multiple messages into a single HTTP request you can use the multiple messaging template. This is automatic if the template has a messages
tag. See the below example:
Again, this is an XML example but your message body can consist of anything including plain text, json or yaml.
Your connector configuration will look like this:
The final result will be HTTP requests with bodies like this:
Available Keys
When using simple and multiple message templating, the following are available:
URL Templating
URL including protocol (eg. http://lenses.io
). Template variables can be used.
The URL is also a Content Template so can contain substitutions from the message key/value/headers etc. If you are batching multiple kafka messages into a single request, then the first message will be used for the substitution of the URL.
Authentication Options
Currently, the HTTP Sink supports either no authentication, BASIC HTTP authentication and OAuth2 authentication.
No Authentication (Default)
By default, no authentication is set. This can be also done by providing a configuration like this:
BASIC HTTP Authentication
BASIC auth can be configured by providing a configuration like this:
OAuth2 Authentication
OAuth auth can be configured by providing a configuration like this:
Headers List
To customise the headers sent with your HTTP request you can supply a Headers List.
Each header key and value is also a Content Template so can contain substitutions from the message key/value/headers etc. If you are batching multiple kafka messages into a single request, then the first message will be used for the substitution of the headers.
Example:
SSL Configuration
Enabling SSL connections between Kafka Connect and HTTP Endpoint ensures that the communication between these services is secure, protecting sensitive data from being intercepted or tampered with. SSL (or TLS) encrypts data in transit, verifying the identity of both parties and ensuring data integrity. Please check out SSL Configuration Properties section in order to set it up.
Batch Configuration
The connector offers three distinct flush options for data management:
Flush by Count - triggers a file flush after a specified number of records have been written to it.
Flush by Size - initiates a file flush once a predetermined size (in bytes) has been attained.
Flush by Interval - enforces a file flush after a defined time interval (in seconds).
It's worth noting that the interval flush is a continuous process that acts as a fail-safe mechanism, ensuring that files are periodically flushed, even if the other flush options are not configured or haven't reached their thresholds.
Consider a scenario where the flush size is set to 10MB, and only 9.8MB of data has been written to the file, with no new Kafka messages arriving for an extended period of 6 hours. To prevent undue delays, the interval flush guarantees that the file is flushed after the specified time interval has elapsed. This ensures the timely management of data even in situations where other flush conditions are not met.
The flush options are configured using the batchCount
, batchSize
and `timeInterval properties. The settings are optional and if not specified the defaults are:
Configuration Examples
Some configuration examples follow on how to apply this connector to different message types.
These include converters, which are required to instruct Kafka Connect on how to read the source content.
Static string template
In this case the converters are irrelevant as we are not using the message content to populate our message template.
Dynamic string template
The HTTP request body contains the value of the message, which is retained as a string value via the StringConverter.
Dynamic string template containing json message fields
Specific fields from the JSON message are substituted into the HTTP request body alongside some static content.
Dynamic string template containing whole json message
The entirety of the message value is substituted into a placeholder in the message body. The message is treated as a string via the StringConverter.
Dynamic string template containing avro message fields
Fields from the AVRO message are substituted into the message body in the following example:
Error/Success Reporter
Starting from version 8.1 as pilot release we give our customers ability to use functionality called Reporter which (if enabled) writes Success and Error processing reports to specified Kafka topic. Reports don't have key and you can find details about status in the message headers and value.
In order to enable this functionality we have to enable one (or both if we want full reporting) of the properties below:
Then we need to specify other connectivity properties just as we would when configuring Kafka Producer. Full configuration options can be found on Success Reporter Properties and Error Reporter Properties. Below you will be able to find two examples: one with local/plain configuration, other using SASL connection parameter.
Plain Error Reporting
This is most common scenario for on-premises Kafka Clusters used just for monitoring
Error Reporting using SASL
This is more robust scenario when Connecting to external Kafka Cluster
Options
Configuration parameters
This sink connector supports the following options as part of its configuration:
SSL Configuration Properties
Error Reporter Properties
Success Reporter Properties
Last updated