[
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)
