[
https://issues.apache.org/jira/browse/NIFI-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15873666#comment-15873666
]
ASF GitHub Bot commented on NIFI-1767:
--------------------------------------
Github user trixpan commented on the issue:
https://github.com/apache/nifi/pull/1521
**JPercivall**
The more I type out and try to easily distinguish GetAWSIoT/PutAWSIoT and
GetAWSIoTShadow/PutAWSIoTShadow the more I think MQTT should be integrated into
the name and all four of the processors should be Publish/Consume.
The GetAWSIoT and PutAWSIoT don't support all the AWS IoT protocols (don't
support "HTTP") and only support MQTT and MQTT over websockets. The name should
convey that they are specifically MQTT processors.
In NiFi, we have a couple different naming conventions. Get/Put are for
processors that do individual requests to some endpoint. For example GetFile
and PutFile, they don't have any lasting connections and each time get or put a
file. Publish and Consume, in general, are for processors which are
listening/putting to a topic. For example the PublishKafka and ConsumeKafka
processors publish and subscribe to a Kafka topic (it's "consume" instead
"subscribe" because we're actually doing something with the messages and not
just "subscribing" to a topic, there was a whole big thread about it).
> AWS IoT processors
> ------------------
>
> Key: NIFI-1767
> URL: https://issues.apache.org/jira/browse/NIFI-1767
> Project: Apache NiFi
> Issue Type: New Feature
> Components: Extensions
> Reporter: Kay Lerch
> Attachments: 20160413_apache-nifi-aws-iot-pull-request_lerchkay.pdf
>
>
> Four new processors to communicate with Amazon’s managed device gateway
> service AWS IoT.
> h5.Use cases
> * Consume reported states from a fleet of things managed and secured on
> Amazon’s gateway service
> * Propagate desired states to a fleet of things managed and secured on
> Amazon’s gateway service
> * Intercept M2M communication
> * Hybrid IoT solutions: brings together a managed device gateway in the cloud
> and onpremise data-consumers and -providers.
> h4.GetIOTMqtt:
> Opens up a connection to an AWS-account-specific websocket endpoint in order
> to subscribe to any of the MQTT topics belonging to a registered thing in AWS
> IoT.
> h4.PutIOTMqtt
> Opens up a connection to an AWS-account-specific websocket endpoint in order
> to publish messages to any of the MQTT topics belonging to a registered thing
> in AWS IoT.
> h4.GetIOTShadow
> In AWS IoT a physical thing is represented with its last reported state by
> the so-called thing shadow. This processor reads out the current state of a
> shadow (persisted as JSON) by requesting the managed API of AWS IoT.
> h4.PutIOTShadow
> In AWS IoT a physical thing is represented with its last reported state by
> the so-called thing shadow. This processor updates the current state of a
> shadow (persisted as JSON) by requesting the managed API of AWS IoT. An
> update to a shadow lets AWS IoT propagate changes to the MQTT topics of the
> thing.
> h5.Known issues:
> * It was hard for me to write appropriate integration tests since the MQTT
> processors work with durable websocket-connections which are kind of tough to
> test. With your help I would love to do a better job on testing and hand it
> in later on. All of the processors were tested in a live-scenario which ran
> over a longer period of time. Didn’t observe any issue.
> * I got rid of all the properties for the deprecated
> AWSCredentialProviderService and only made use of
> AWSCredentialsProviderControllerService. If both are still necessary for
> backward-compatibilities sake I would add the deprecated feature.
> Refers to Pull Request 349: https://github.com/apache/nifi/pull/349
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
