Stefano Giacco created NIFI-6066:
------------------------------------

             Summary: Application properties support for ConsumeAzureEventHub 
processor
                 Key: NIFI-6066
                 URL: https://issues.apache.org/jira/browse/NIFI-6066
             Project: Apache NiFi
          Issue Type: Wish
          Components: Extensions
            Reporter: Stefano Giacco
         Attachments: code_snippet.txt

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|https://cwiki.apache.org/confluence/display/NIFI/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?

 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Reply via email to