Hello Can you talk a bit about why you'd want ListenTCP processors tied to a given sensor? You should be able to have many sensors to a single ListenTCP. Each stream will be between a source/sensor and nifi so data won't be getting intermingled there. If we're not providing enough session/stream metadata on the flow files to make demux of the streams easy using something like RouteOnAttribute or whatnot we definitely should.
Now, that said, you could certainly programmatically deploy (via the REST API) instances of these processors along the lines of what your endpoint registry tells you. It just seems on the surface like doing so would be avoidable at least for the listening of data. Typically such a registry would be useful to do additional tagging/enrichment of the data and would occur once it is in the flow. Thanks Joe On Wed, Sep 28, 2016 at 3:39 PM, Davy De Waele <[email protected]> wrote: > We have a large number of sensors that send out data via TCP. The idea is to > use a ListenTCP processor in Nifi to capture the data, do some filtering / > basic transformation before sending it upstream into our stack. > > We can configure individual ListenTCP processors for each sensor, and that > works fine when the number of sensors is small, but once you hit a larger > number if becomes cumbersome and difficult to manage. > > We have an inventory of those sensors (exposed via a REST service endpoint), > containing the sensor tcp information like ip and port) > > Is there an easy way to create these ListenTCP processors on the fly based > on a REST endpoint or some other external configuration ? How would that > work ? > > Thx.
