Azure Functions Sink Connector for Confluent Cloud

Note

If you are installing the connector locally for Confluent Platform, see Azure Functions Sink Connector for Confluent Platform.

The Kafka Connect Azure Functions Sink Connector for Confluent Cloud integrates Apache Kafka® with Azure Functions. For more information about creating an Azure function, see Create your first function.

The connector consumes records from Kafka topic(s) and executes an Azure Function. Each request sent to Azure Functions can contain up to the max.batch.size number of records.

Important

If you are still on Confluent Cloud Enterprise, please contact your Confluent Account Executive for more information about using this connector.

Features

The Azure Functions sink connector provides the following features:

  • Results from Azure Functions are stored in the following topics:
    • success-<connector-id>
    • error-<connector-id>
  • Input data formats supported are Bytes, AVRO, JSON_SR (JSON Schema), JSON (Schemaless) and PROTOBUF. If no schema is defined, values are encoded as plain strings. For example, "name": "Kimberley Human" is encoded as name=Kimberley Human.

You can manage your full-service connector using the Confluent Cloud API. For details, see the Confluent Cloud API documentation.

Refer to Cloud connector limitations for additional information.

Quick Start

Use this quick start to get up and running with the Confluent Cloud Azure Functions sink connector. The quick start provides the basics of selecting the connector and configuring it to stream events to a target Azure Function.

Prerequisites
  • Authorized access to a Confluent Cloud cluster on Microsoft Azure.
  • Access to an Azure function. For basic information about functions, see Create your first function.
  • The Confluent Cloud CLI installed and configured for the cluster. See Install the Confluent Cloud CLI.
  • Schema Registry must be enabled to use a Schema Registry-based format (for example, Avro, JSON_SR (JSON Schema), or Protobuf).
  • The target Azure function and the Kafka cluster should be in the same region.

Using the Confluent Cloud GUI

Step 1: Launch your Confluent Cloud cluster.

See the Quick Start for Apache Kafka using Confluent Cloud for installation instructions.

Step 2: Add a connector.

Click Connectors. If you already have connectors in your cluster, click Add connector.

Step 3: Select your connector.

Click the Azure Functions Sink connector icon.

Azure Functions Sink Connector Icon

Step 4: Set up the connection.

Complete the following and click Continue.

Note

  • Make sure you have all your prerequisites completed.
  • An asterisk ( * ) designates a required entry.
  1. Select one or more topics.

  2. Enter a connector Name or choose the default name.

  3. Select an Input message format (data coming from the Kafka topic): AVRO, JSON_SR (JSON Schema), PROTOBUF, or JSON (schemaless). A valid schema must be available in Schema Registry to use a schema-based message format.

    Note

    If no schema is defined, values are encoded as plain strings. For example, "name": "Kimberley Human" is encoded as name=Kimberley Human.

  4. Enter your Kafka Cluster credentials. The credentials are either the API key and secret or the service account API key and secret.

  5. Enter your Function URL. For example: https://myfunctionapp-devtest.azurewebsites.net/api/HttpTrigger1?code=zbdeiflowie.

  6. Enter the Function Details.

    • Max Batch Size: The maximum number of records to combine when invoking a single Azure function. Defaults to 1 (batching disabled). Accepts values from 1 to 1000.

    • Max Pending Requests: The maximum number of pending requests that can be made to Azure functions concurrently.

    • Request Timeout:

      Azure Functions Request Timeout
    • Retry Timeout: The total amount of time, in milliseconds (ms), that the connector will exponentially backoff and retry failed requests (i.e., throttling). Response codes that are retried are HTTP 429 Too Busy and HTTP 502 Bad Gateway. Enter -1 to configure this property for indefinite retries. Defaults to 300000 ms (5 minutes).

  7. Enter the number of tasks to use with the connector.

Configuration properties that use default values do not display in the Confluent Cloud UI. For configuration properties and their default values, see Azure Functions Sink Connector Configuration Properties. definitions.

Step 5: Launch the connector.

Verify the connection details and click Launch.

Step 6: Check the connector status.

The status for the connector should go from Provisioning to Running.

Step 7: Check for records.

Verify that records are being produced.

You can manage your full-service connector using the Confluent Cloud API. For details, see the Confluent Cloud API documentation.

Tip

When you launch a connector, a Dead Letter Queue topic is automatically created. See Dead Letter Queue for details.

For additional information about this connector see Azure Functions Sink Connector for Confluent Platform. Note that not all Confluent Platform connector features are provided in the Confluent Cloud connector.

See also

For an example that shows fully-managed Confluent Cloud connectors in action with Confluent Cloud ksqlDB, see the Cloud ETL Demo. This example also shows how to use Confluent Cloud CLI to manage your resources in Confluent Cloud.

../_images/topology.png

Using the Confluent Cloud CLI

Complete the following steps to set up and run the connector using the Confluent Cloud CLI.

Note

Make sure you have all your prerequisites completed.

Step 1: List the available connectors.

Enter the following command to list available connectors:

ccloud connector-catalog list

Step 2: Show the required connector configuration properties.

Enter the following command to show the required connector properties:

ccloud connector-catalog describe <connector-catalog-name>

For example:

ccloud connector-catalog describe AzureFunctionSink

Example output:

Following are the required configs:
connector.class
name
kafka.api.key
kafka.api.secret
function.url
topics
tasks.max

Configuration properties that are not listed use the default values. See Azure Functions Sink Connector Configuration Properties for default values and property definitions.

Step 3: Create the connector configuration file.

Create a JSON file that contains the connector configuration properties. The following example shows the required connector properties.

{
  "topics":"pageviews",
  "input.data.format": "AVRO",
  "connector.class": "AzureFunctionsSink",
  "name": "AzureFunctionsSinkConnector_0",
  "kafka.api.key": "****************",
  "kafka.api.secret": "****************************************************************",
  "function.url": "https://myfunctionapp-dev.azurewebsites.net/api/HttpTrigger1?code=zjiekiuqowie",
  "tasks.max": "1"
}

Note the following property definitions:

  • "topics": Identifies the topic name or a comma-separated list of topic names.
  • "input.data.format": Sets the input message format. Valid entries are AVRO, JSON_SR, PROTOBUF, JSON, or BYTES. You must have Confluent Cloud Schema Registry configured if using a schema-based message format (for example, Avro, JSON_SR (JSON Schema), or Protobuf).
  • "connector.class": Identifies the connector plugin name.
  • "name": Sets a name for your new connector.
  • "function.url": The URL for your predefined Azure function.

Optional:

  • "max.batch.size": The maximum number of records to combine when invoking a single Azure function. Defaults to 1 (batching disabled). Accepts values from 1 to 1000.
  • "max.pending.requests": The maximum number of pending requests that can be made to Azure functions concurrently. Defaults to 1.
  • "request.timeout": The maximum time in milliseconds that the connector will attempt a request to Azure Functions before timing out (i.e., socket timeout). Defaults to 300000 ms (5 minutes).
  • "retry.timeout": The total amount of time, in milliseconds (ms), that the connector will exponentially backoff and retry failed requests (i.e., throttling). Response codes that are retried are HTTP 429 Too Busy and HTTP 502 Bad Gateway. Defaults to 300000 ms (5 minutes). Enter -1 to configure this property for indefinite retries.

Step 4: Load the properties file and create the connector.

Enter the following command to load the configuration and start the connector:

ccloud connector create --config <file-name>.json

For example:

ccloud connector create --config azure-functions-sink-config.json

Example output:

Created connector AzureFunctionsSinkConnector_0 lcc-ix4dl

Step 5: Check the connector status.

Enter the following command to check the connector status:

ccloud connector list

Example output:

ID          |       Name                    | Status  | Type
+-----------+-------------------------------+---------+------+
lcc-ix4dl   | AzureFunctionsSinkConnector_0 | RUNNING | sink

Step 6: Check for records.

Verify that records are being produced.

You can manage your full-service connector using the Confluent Cloud API. For details, see the Confluent Cloud API documentation.

Tip

When you launch a connector, a Dead Letter Queue topic is automatically created. See Dead Letter Queue for details.

For additional information about this connector see Azure Functions Sink Connector for Confluent Platform. Note that not all Confluent Platform connector features are provided in the Confluent Cloud connector.

Next Steps

See also

For an example that shows fully-managed Confluent Cloud connectors in action with Confluent Cloud ksqlDB, see the Cloud ETL Demo. This example also shows how to use Confluent Cloud CLI to manage your resources in Confluent Cloud.

../_images/topology.png