On this page
Destination configuration
Configure supported Kafka, HTTP, JDBC, and Golden-table destinations for Trazadera Golden export flows.
Destination resources use the sink type prefix. Golden supports Kafka, HTTP,
JDBC, and Golden-table sinks. The current resource model does not define a file
sink.
Kafka destinations
{
"type": "sink-kafka",
"_id": "customer_kafka_sink",
"description": "Mastered customer delivery",
"dataset": "customer_dataset",
"bootstrapServers": "kafka1.example.com:9092",
"topicName": "mastered-customers",
"credentials": "kafka_credentials",
"timeoutMs": 5000,
"properties": [{"key": "acks", "value": "all"}]
}
Use properties only for producer options approved for the deployment. Keep
authentication material in the referenced credentials resource. Properties
are an array of key and value pairs, and their accepted names come from the
Kafka client used by the target deployment.
Each Kafka message has the record’s _id as its key and the record as a plain
JSON object in its value. Consumers should parse the value once as JSON and use
the key to keep versions of one record in the same partition.
HTTP destinations
{
"type": "sink-http",
"_id": "customer_http_sink",
"description": "Mastered customer API",
"dataset": "customer_dataset",
"url": "https://receiver.example.com/customers",
"credentials": "receiver_credentials",
"timeoutMs": 5000,
"method": "POST"
}
The supported methods are POST, PUT, and PATCH. The receiver should use
stable record identity and define how a repeated request is handled because a
timeout can make delivery outcome uncertain.
JDBC destinations
{
"type": "sink-jdbc",
"_id": "customer_warehouse_sink",
"description": "Analytics customer table",
"dataset": "customer_dataset",
"url": "jdbc:postgresql://warehouse.example.com:5432/analytics",
"credentials": "warehouse_credentials",
"table": "public.customers",
"logicalDelete": false,
"writeTimestampFlag": false,
"writeIdFlag": false,
"properties": [{"key": "ssl", "value": "true"}]
}
JDBC sinks can additionally configure an operation column, logical-delete behavior, and columns that receive write identifiers or timestamps. Match those choices to the target table contract and test insert, update, and delete cases.
Golden-table destinations
{
"type": "sink-table",
"_id": "processed_customer_sink",
"description": "Processed customer table",
"table": "processed_customers"
}
A table sink writes to an existing Golden table and uses that table’s dataset. It applies the delivered operation: a changed record updates its row, and a removal deletes it. Test create, update, and removal with the target table.
Verify a destination
- Test the resource without saving it.
- Deliver a controlled record set through an entity configured with this destination. A table file export does not deliver records to a sink.
- Follow the resulting task.
- Verify record identity, field structure, and update behavior at the target.
- Enable recurring work only after the target result is correct.