[jira] [Commented] (NIFI-6066) Application properties support for ConsumeAzureEventHub processor

["Sivaprasanna Sethuraman (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/NIFI-6066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16817997#comment-16817997 ] 

Sivaprasanna Sethuraman commented on NIFI-6066:
-----------------------------------------------

[~s.giacco]

Please go ahead, and raise a pull request. Whoever reviews the code would comment where the code can be changed. 

> 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
>            Priority: Major
>         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)