Details
-
Wish
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
The ConsumeAzureEventHub processor can be used to consume Device To Cloud messages from Azure IoT Hub.
The Azure IoT Hub message consists of a body, a predetermined set of system properties, a set of application properties (ref. https://docs.microsoft.com/en-us/azure/iot-hub/iot-hub-devguide-messages-construct).
Currently, the ConsumeAzureEventHub processor intercepts only a sub-set of the available system properties:
| Name | Description |
|---|---|
| eventhub.enqueued.timestamp | The time (in milliseconds since epoch, UTC) at which the message was enqueued in the Azure Event Hub |
| eventhub.offset | The offset into the partition at which the message was stored |
| eventhub.sequence | The Azure Sequence number associated with the message |
| eventhub.name | The name of the Event Hub from which the message was pulled |
| eventhub.partition | The name of the Azure Partition from which the message was pulled |
Applications properties can NOT be intercepted at all.
Producing a new attribute for each system or application property enables new attribute routing scenarios.
I made a "dummy" implementation (just for fun!) by modifying the EventProcessor.putEventHubAttributes() method in ConsumeAzureEventHub.java (look at the code snippet in attachment)
I'd love to propose a PR with a more complete implementation but I have some question about the "approach" (Yes, I already read the Contributor Guide). Is it acceptable for a Nifi processor 1) to produces a set of new attributes with unknown cardinality? 2) to produce new attributes using the naming convention eventhub.app.<ORIGINAL_APPLICATION_PROPERTY_NAME>? In affirmative case, is it acceptable to document the processor behavior with @WritesAttribute(attribute = "eventhub.app.<ORIGINAL_APPLICATION_PROPERTY_NAME>", description = "Event Hub original application property") ? Should a property enable the functionality?