PLAINTEXT://host.name:port
            

    SSL://host.name:port
            

    SASL_PLAINTEXT://host.name:port
            

    java.arg.16=-Djava.security.auth.login.config=/path/to/kafka_client_jaas.conf
            

    KafkaClient {
        com.sun.security.auth.module.Krb5LoginModule required
        useKeyTab=true
        storeKey=true
        keyTab="/path/to/nifi.keytab"
        serviceName="kafka"
        principal="nifi@YOURREALM.COM";
    };
            

    KafkaClient {
      org.apache.kafka.common.security.plain.PlainLoginModule required
      username="nifi"
      password="nifi-password";
    };
            

    KafkaClient {
      org.apache.kafka.common.security.scram.ScramLoginModule
      username="nifi"
      password="nifi-password";
    };
            

    SASL_SSL://host.name:port
            

This processor includes optional properties that control how a Kafka Record's key and headers are determined:

• 'Publish Strategy'
• 'Record Key Writer'

'Publish Strategy' controls the mode used to convert the FlowFile record into a Kafka record.

• 'Use Content as Record Value' (the default) - the content of the FlowFile Record becomes the content of the Kafka record. The Kafka record's key is determined by the 'Message Key Field' property, and the Kafka record's headers are determined by the 'Attributes to Send as Headers (Regex)' property.
• 'Use Wrapper' - the content of the FlowFile record is a wrapper consisting of the Kafka record's key, value, headers, and metadata (topic and partition).

If Publish Strategy is set to 'Use Wrapper', two additional processor configuration properties are made available: 'Record Key Writer' and 'Record Metadata Strategy'.

The 'Record Key Writer' property determines the Record Writer that should be used to serialize the Kafka record's key. This may be used to emit the key as JSON, Avro, XML, or some other data format. If this property is not set, and the NiFi Record indicates that the key itself is a Record, the FlowFile will be routed to the 'failure' relationship. If this property is not set and the NiFi Record has a Byte Array or a String (encoded in UTF-8 format), the Kafka record's key will still be set accordingly.

The 'Record Metadata Strategy' specifies whether the Kafka Topic and partition should come from the configured 'Topic Name' property and 'Partition' / 'Partitioner class' properties, or if they should come from the Record's optional metadata field. If the value is set to 'Metadata From Record', the incoming FlowFile record is expected to have a field named 'metadata'. That field is expected to be a Record with a 'topic' and a 'partition' field. If these fields are missing or invalid, the processor's 'Topic Name' and 'Partition' / 'Partitioner class' properties will still be used.

Using the metadata field to convey the topic and partition has two advantages. Firstly, it pairs well with the ConsumeKafkaRecord_* processor, which produces this same schema. This means that if data is consumed from one topic and pushed to another topic (or Kafka cluster), the data can be easily pinned to the same partition and topic name. If the data should be pushed to a different topic, it can be easily updated using an UpdateRecord processor, for instance.

Additionally, because a single FlowFile can be sent as a single Kafka transaction, this allows sending records to multiple Kafka topics in a single transaction.

Examples

The below examples illustrate what will be sent to Kafka, given different configurations and FlowFile contents. These examples all assume that JsonRecordSetWriter and JsonTreeReader will be used for the Record Readers and Writers.

Publish Strategy = 'Use Content as Record Value'

Given the processor configuration:

Processor Property	Configured Value
Message Key Field	account
Attributes to Send as Headers (Regex)	attribute.*

And a FlowFile with the content:

                {"address":"1234 First Street","zip":"12345","account":{"name":"Acme","number":"AC1234"}}
            

And attributes:

Attribute Name	Attribute Value
attributeA	valueA
attributeB	valueB
otherAttribute	otherValue

The record that is produced to Kafka will have the following characteristics:

Record Key	{"name":"Acme","number":"AC1234"}
Record Value	{"address":"1234 First Street","zip":"12345","account":{"name":"Acme","number":"AC1234"}}
Record Headers	Header Name Header Value attributeA valueA attributeB valueB

Publish Strategy = 'Use Wrapper'

When the Publish Strategy is configured to 'Use Wrapper', each FlowFile Record is expected to adhere to a specific schema. The Record must have three fields: key, value, and headers. There is a fourth, optional field named metadata. The key may be a String, a byte array, or a Record. The value can be any Record. The headers is a Map where the values are Strings. The metadata field is a Record that has two fields of interest: topic and partition. If these fields are specified, they will take precedence over the configured 'Topic Name' and 'Partition' and 'Partitioner class' processor properties.

Example 1 - Key as String

Given a FlowFile with the content:

{
    "key": "Acme Holdings",
    "value": {
        "address": "1234 First Street",
        "zip": "12345",
        "account": {
            "name": "Acme",
            "number":"AC1234"
        }
    },
    "headers": {
        "accountType": "enterprise",
        "test": "true"
    }
}
            

The record that is produced to Kafka will have the following characteristics:

Record Key	Acme Holdings
Record Value	{"address":"1234 First Street","zip":"12345","account":{"name":"Acme","number":"AC1234"}}
Record Headers	Header Name Header Value accountType enterprise test true

Note that in this case, the headers and key come directly from the Record, not from FlowFile attributes. If there is a desire to include some FlowFile attributes in the headers, this should be accomplished by using a Processor upstream in order to inject those values into the headers field. For example, an UpdateRecord processor could be used to easily add new fields to the headers Map.

Example 2 - Key as Record

Additionally, we may choose to use a more complex value for the record key. The key itself may be a record. This is sometimes used to write the record key either as JSON or as Avro. In this example, we assume that the 'Record Key Writer' property is set to a JsonRecordSetWriter.

Given a FlowFile with the content:

{
    "key": {
        "accountName": "Acme Holdings",
        "accountHolder": "John Doe",
        "accountId": "280182830-A009"
    },
    "value": {
        "address": "1234 First Street",
        "zip": "12345",
        "account": {
            "name": "Acme",
            "number":"AC1234"
        }
    }
}
            

The record that is produced to Kafka will have the following characteristics:

Record Key	{"accountName":"Acme Holdings","accountHolder":"John Doe","accountId":"280182830-A009"}
Record Value	{"address":"1234 First Street","zip":"12345","account":{"name":"Acme","number":"AC1234"}}
Record Headers

Note here that the Record Key is JSON, as the 'Record Key Writer' property is configured to write JSON. it could just as easily be Avro.

Also note that if the 'Record Key Writer' had not been set, the FlowFile would have been routed to the 'failure' relationship because the key is a Record.

Finally, note here that the headers field is missing. This is acceptable and no headers will be added to the Kafka record.

Example 3 - Key as Byte Array

We can also have a Record whose key field is an array of bytes. In this case, the 'Record Key Writer' property is not used.

Given a FlowFile with the content:

{
    "key": [65, 27, 10, 20, 11, 57, 88, 19, 65],
    "value": {
        "address": "1234 First Street",
        "zip": "12345",
        "account": {
            "name": "Acme",
            "number":"AC1234"
        }
    },
    "otherField": {
        "a": "b"
    }
}
            

The record that is produced to Kafka will have the following characteristics:

Record Key	0x411b0a140b39581341
Record Value	{"address":"1234 First Street","zip":"12345","account":{"name":"Acme","number":"AC1234"}}
Record Headers

In this case, the byte array that is specified for the key is provided to the Kafka Record as a byte array without changes (in the table, it is simply represented as Hex).

Finally, note here that the headers field is missing and an extraneous field, otherField is present. This is acceptable and no headers will be added to the Kafka record. The otherField is simply ignored.

Example 4 - No Key

We can also have a Record whose key field is null or missing. In this case, the 'Record Key Writer' property is not used.

Given a FlowFile with the content:

{
    "value": {
        "address": "1234 First Street",
        "zip": "12345",
        "account": {
            "name": "Acme",
            "number":"AC1234"
        }
    },
    "headers": {
        "a": "b",
        "c": {
            "d": "e"
        }
    }
}
            

The record that is produced to Kafka will have the following characteristics:

Record Key
Record Value	{"address":"1234 First Street","zip":"12345","account":{"name":"Acme","number":"AC1234"}}
Record Headers	Header Name Header Value a b c MapRecord[{d=e}]

In this case, the key is not present, so the Kafka record that is produced has no key associated with it.

Note also that the headers field has the expected value for the a header but the c header has an expected value of MapRecord[{d=e}]. This is because the headers field is expected always to be a Map with String values. By providing a Record for the c element, we have violated the contract. NiFi attempts to compensate for this by creating a String representation of the Record, even if it is unlikely to be the representation that the user expects.

Example 5 - Topic provided in Record

If the Metadata field is provided in the FlowFile's Record, it will be used to determine the Topic and the Partition that the Records are written to.

Given a FlowFile with the content:

{
    "value": {
        "address": "1234 First Street",
        "zip": "12345",
        "account": {
            "name": "Acme",
            "number":"AC1234"
        }
    },
    "headers": {
        "a": "b"
    },
    "metadata": {
        "topic": "topic1"
    }
}
            

And considering that the processor properties are configured as:

Property Name	Property Value
Topic Name	My Topic
Partition	2
Record Metadata Strategy	Metadata From Record

The record that is produced to Kafka will have the following characteristics:

Kafka Topic	topic1
Topic Partition	2
Record Key
Record Value	{"address":"1234 First Street","zip":"12345","account":{"name":"Acme","number":"AC1234"}}
Record Headers	Header Name Header Value a b

Note that the topic name comes directly from the FlowFile record, and the configured topic name ("My Topic") is ignored. However, if either the "metadata" field or its "topic" sub-field were missing, the configured topic name ("My Topic") would be used.

Example 6 - Partition provided in Record

Given a FlowFile with the content:

{
    "value": {
        "address": "1234 First Street",
        "zip": "12345",
        "account": {
            "name": "Acme",
            "number":"AC1234"
        }
    },
    "headers": {
        "a": "b"
    },
    "metadata": {
        "partition": 6
    }
}
            

And considering that the processor properties are configured as:

Property Name	Property Value
Topic Name	My Topic
Partition	2
Record Metadata Strategy	Metadata From Record

The record that is produced to Kafka will have the following characteristics:

Kafka Topic	My Topic
Topic Partition	6
Record Key
Record Value	{"address":"1234 First Street","zip":"12345","account":{"name":"Acme","number":"AC1234"}}
Record Headers	Header Name Header Value a b

Example 7 - Topic and Partition provided in Record

If the Metadata field is provided in the FlowFile's Record, it will be used to determine the Topic and the Partition that the Records are written to.

Given a FlowFile with the content:

{
    "value": {
        "address": "1234 First Street",
        "zip": "12345",
        "account": {
            "name": "Acme",
            "number":"AC1234"
        }
    },
    "headers": {
        "a": "b"
    },
    "metadata": {
        "topic": "topic1",
        "partition": 0
    }
}
            

And considering that the processor properties are configured as:

Property Name	Property Value
Topic Name	My Topic
Partition	2
Record Metadata Strategy	Metadata From Record

The record that is produced to Kafka will have the following characteristics:

Kafka Topic	topic1
Topic Partition	0
Record Key
Record Value	{"address":"1234 First Street","zip":"12345","account":{"name":"Acme","number":"AC1234"}}
Record Headers	Header Name Header Value a b

In this case, both the topic name and the partition are explicitly defined within the incoming Record, and those will be used.

Example 8 - Invalid metadata provided in Record

Given a FlowFile with the content:

{
    "value": {
        "address": "1234 First Street",
        "zip": "12345",
        "account": {
            "name": "Acme",
            "number":"AC1234"
        }
    },
    "headers": {
        "a": "b"
    },
    "metadata": "hello"
}
            

And considering that the processor properties are configured as:

Property Name	Property Value
Topic Name	My Topic
Partition	2
Record Metadata Strategy	Metadata From Record

The record that is produced to Kafka will have the following characteristics:

Kafka Topic	My Topic
Topic Partition	2
Record Key
Record Value	{"address":"1234 First Street","zip":"12345","account":{"name":"Acme","number":"AC1234"}}
Record Headers	Header Name Header Value a b

In this case, the "metadata" field in the Record is ignored because it is not itself a Record.

Example 9 - Use Configured Values for Metadata

Given a FlowFile with the content:

{
    "value": {
        "address": "1234 First Street",
        "zip": "12345",
        "account": {
            "name": "Acme",
            "number":"AC1234"
        }
    },
    "headers": {
        "a": "b"
    },
    "metadata": {
        "topic": "topic1",
        "partition": 6
    }
}
            

And considering that the processor properties are configured as:

Property Name	Property Value
Topic Name	My Topic
Partition	2
Record Metadata Strategy	Use Configured Values

The record that is produced to Kafka will have the following characteristics:

Kafka Topic	My Topic
Topic Partition	2
Record Key
Record Value	{"address":"1234 First Street","zip":"12345","account":{"name":"Acme","number":"AC1234"}}
Record Headers	Header Name Header Value a b

In this case, the "metadata" field specifies both the topic and the partition. However, it is ignored in favor of the processor properties 'Topic' and 'Partition' because the property 'Record Metadata Strategy' is set to 'Use Configured Values'.