Skip to main content
Scope. This guide covers process-instance indexing only — the process_instance-* indices written by process-engine. Audit logs (audit-logs index, written directly by audit-core over HTTPS) and search workloads (data-search, read-only) do not flow through this pipeline.

Before you start

  • Read the prerequisites: Review the Intro to Elasticsearch section first
  • Choose your strategy: Decide between Kafka (recommended for production) or HTTP indexing based on your infrastructure
  • Check permissions: Ensure you have access to modify process-engine configurations

Quick decision: Kafka vs HTTP

Why Kafka is recommended: The Kafka strategy allows for fire-and-forget communication, eliminating the need for the process engine to wait for indexing requests to complete. This significantly improves performance in high-throughput scenarios.
Critical difference: Only the Kafka strategy provides out-of-the-box support for time-based partitioning through the transforms.routeTS.timestamp.format configuration (see later in this guide). The HTTP strategy does not support time-based partitioning as a built-in feature.

Configuration overview

All indexing is controlled by these core settings:

Global indexing control

FLOWX_INDEXING_ENABLED defaults to true. Only set this variable if you want to disable indexing by setting it to false.

Strategy selection

Performance considerations (FlowX defaults)

Default configuration:
  • Monthly indices: yyyyMM format for time-based partitioning (Kafka only)
  • 2 shards + 0 replicas (code default): bump replicas based on your high-availability requirements
  • Primary shards per year: 24 (2 primary × 12 monthly indices) — well under Elasticsearch’s 1000 shard default limit; each replica adds another 24
Scaling guidelines:
  • If indexing becomes slow: Check physical resources and shard size
  • If monthly indices become too large: Switch to weekly indices (yyyyww)
  • For high parallel indexing load: Add more primary shards
  • High availability: Set FLOWX_ELASTICSEARCH_INDEXSETTINGS_REPLICAS to at least 1 in production for resilience to a single node loss
Important: Each replica is applied per shard, so monitor resource usage when increasing replicas.

HTTP-only setting


Step 1: Configure the process engine

Add these environment variables to your process-engine configuration:
process-engine still needs HTTPS connectivity to Elasticsearch in Kafka mode. Even with FLOWX_INDEXING_TYPE=kafka, process-engine creates the process_instance_template index template directly against Elasticsearch at startup. If process-engine cannot reach Elasticsearch, the template silently fails to apply and indices fall back to default mappings — search and aggregations break in non-obvious ways.

Step 2: Deploy Kafka Connect

Compatibility matrix

Multiple sink connector implementations also work, as long as they are compatible with both the deployed Kafka and Elasticsearch version deployed. This guide uses the Confluent kafka-connect-elasticsearch plugin as the reference path.
Prerequisites:
  • Kafka cluster (installed with Strimzi operator)
  • Elasticsearch cluster (installed with eck-operator)
  • Convert ES certificates to JKS format (see commands below)
Certificate conversion commands:
Deploy KafkaConnect:
FlowX does not publish a Kafka Connect image. You build and host the container image yourself. Strimzi’s spec.build block below downloads the connector plugin, bakes it into a new image, and pushes it to your registry. Use an immutable tag that ties the image to the plugin version so upgrades are auditable.

Step 3: Configure the Elasticsearch Sink Connector

Indices are partitioned by process start month, not update month. The TimestampRouter uses the Kafka record timestamp, which process-engine populates with the process instance’s dateStarted. Late updates to old process instances land in the original start-month index, not the index for the current month. Plan archiving alignment accordingly, and use the body field indexLastUpdatedTime (not the index name) for “activity in last X days” queries.
The source topic must be pre-declared. topic.creation.enable: true on the KafkaConnect cluster only creates Kafka Connect’s internal offsets/configs/status topics — it does not create the source topic the connector consumes. Add ai.flowx.<env>.core.index.process.v1 to your Strimzi KafkaTopic resources before the connector starts.
Key settings explained:
  • transforms.routeTS.timestamp.format: Controls index partitioning (monthly=yyyyMM, daily=yyyyMMdd)
  • transforms.routeTS.topic.format: Must start with your configured index name
  • batch.size: Adjust based on throughput needs (1000 is good default)
Process instance data archiving integration: If you’re using FlowX’s process instance data archiving feature, ensure your Elasticsearch partitioning configuration aligns with your database partitioning strategy. This is essential because:
  • When archiving process instances, data must be deleted from both the database and Elasticsearch
  • The partitioning intervals should be similar between database and Elasticsearch for consistent data lifecycle management
  • Elasticsearch indexing strategy must be enabled when partitioning is configured

Step 4: Verify the setup

Check Kafka Connect status:
Check connector status:
Verify indices are being created:

Setup: HTTP indexing (simple)

Configure the process engine

For HTTP indexing, update your process-engine configuration:

Kafka topics

The process engine publishes indexing records to a topic whose name is composed from the standard FlowX Kafka naming triple:
Each segment is set independently via environment variables on the process-engine deployment: Worked examples: Important: The topics: value in your KafkaConnector configuration must match the composed topic for your environment. You must also declare that topic explicitly via your Strimzi KafkaTopic resources — see the warning under Step 3.

Index management

Automatic template creation

The process engine automatically creates Elasticsearch index templates during startup:
  • HTTP strategy: Creates the index directly with configured shards/replicas
  • Kafka strategy: Creates an index template that applies to dynamically created indices

Time-based partitioning (Kafka only)

Choose your partitioning strategy based on data volume and retention needs:

Efficient data deletion

Best practice: Delete entire indices rather than individual documents for better performance. With time-based partitioning, you can:

Troubleshooting

Common issues

Indexing not working:
  1. Check if indexing is disabled (only if you explicitly set FLOWX_INDEXING_ENABLED=false)
  2. Verify Elasticsearch connectivity
  3. Check process-engine logs for errors
Kafka Connect issues:
Certificate issues:
Performance issues:
  • Increase batch.size in connector config
  • Adjust number of shards based on cluster size
  • Monitor Elasticsearch cluster health

Verification queries

Check index pattern:
Query across time-based indices:
Last modified on May 26, 2026