Integrate with Azure Event Hubs using Java SDK

This skill builds real-time streaming applications with the Azure Event Hubs SDK for Java (com.azure:azure-messaging-eventhubs, version 5.19.0, plus azure-messaging-eventhubs-checkpointstore-blob for production checkpointing). It builds an EventHubProducerClient or EventHubConsumerClient via EventHubClientBuilder, either from a connection string (with or without an embedded entity path) or a fully-qualified namespace plus DefaultAzureCredential, with async variants (EventHubProducerAsyncClient/EventHubConsumerAsyncClient) also available. Sending covers a single EventData message, building an EventDataBatch and adding events until tryAdd returns false (signaling the batch is full and must be sent before starting a new one), targeting a specific partition or a partition key (for ordering guarantees within a partition) via CreateBatchOptions, and attaching custom properties to an event. Simple receiving reads from one partition with receiveFromPartition given a partition ID, max event count, starting EventPosition (earliest, latest, from a specific offset, sequence number, or enqueued time), and timeout. For production use, EventProcessorClient (built with a BlobCheckpointStore backed by Azure Blob Storage) provides load-balanced, checkpointed consumption across partitions via a processEvent callback (checkpointing per event) or processEventBatch callback (checkpointing per batch, with a configurable max batch size), plus a processError callback receiving the partition ID and throwable - distinguishing transient AmqpExceptions (safe to retry) from other errors. Event Hub and partition metadata (partition IDs, beginning/last sequence numbers, last offset) can be queried directly from the producer client. Resource cleanup is shown via explicit close() in a finally block or try-with-resources. Best practices: use EventProcessorClient in production for load balancing and checkpointing, always batch events for efficiency, use partition keys for ordering, checkpoint after processing to avoid reprocessing on restart, handle transient errors with retries, and always close producer/consumer clients when done.

Use this skill when building a Java application that ingests or processes high-volume event streams on Azure Event Hubs - IoT telemetry, application event streaming, or log/metric ingestion pipelines needing partition-ordered, checkpointed consumption. It is not suited for simple pub/sub with individual message acknowledgment semantics (Event Hubs has no per-message ack/dead-letter - use Azure Service Bus for that) and single-partition simple receiving is not resilient for production - multi-consumer, load-balanced scenarios need EventProcessorClient. The reactive receiveFromPartition(...).subscribe() pattern is for lightweight async consumption, not a substitute for checkpointed production use.

Input is event payloads (with optional properties, partition ID, or partition key) to send, or a starting position and partition/consumer-group scope to receive from, configured via EVENT_HUBS_CONNECTION_STRING/EVENT_HUBS_NAME and, for checkpointing, STORAGE_CONNECTION_STRING. Output is send confirmations, received EventData (body, sequence number, offset), Event Hub/partition metadata, and for EventProcessorClient, periodic checkpoint commits to the blob-backed checkpoint store.

Built on the Azure Event Hubs Java SDK (azure-messaging-eventhubs), authenticated via connection string or DefaultAzureCredential, with Azure Blob Storage (azure-messaging-eventhubs-checkpointstore-blob) for production checkpoint storage.

<dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-messaging-eventhubs</artifactId>
    <version>5.19.0</version>
</dependency>

Java developers building real-time event-streaming or telemetry-ingestion pipelines on Azure Event Hubs who need reliable, checkpointed, partition-ordered consumption at production scale.