I think it would be beneficial to add dynamic properties to any processor for use further down the flow, not in the processor where the properties are added.
For example, I may have a lot of ŒListSFTP¹ processors that feed into a single FetchSFTP, then a single PutFile. It would be nice to be able to add one or more attributes in ListSFTP to tell PutFile where to write the file or use RouteOnAttribute to send the file to the appropriate processor. I realize that this can be accomplished by adding an UpdateAttribute processor, but that would greatly increase the number of processors in my flow file. >From a cursory scan of the 0.7.0 processors, it looks like UpdateAttribute, RouteOnAttribute, RouteOnContent, RouteText, HashAttribute and RouteHL7 are the only processors that actually allow you to add a property, yet all processors have the "+ New Property² widget on the ³Properties² page. If arbitrary properties can¹t be added, the ³+ New Property² widget should be hidden. - Kirk Tarou On 8/18/16, 5:11 PM, "Matt Burgess" <mattyb...@gmail.com> wrote: >Kirk, > >The processors have to explicitly know about dynamic properties (and >their intent) in order to use them appropriately. For a processor like >ListSFTP, it could be beneficial to have custom attributes (as >parameters to the SFTP session perhaps?) but the domain knowledge on >how they'd be used would have to be coded into the processor itself. >If you have a use case in mind, please feel free to file an >improvement Jira for ListSFTP to use dynamic properties. > >Regards, >Matt > >On Mon, Aug 8, 2016 at 4:50 PM, Tarou, Kirk ><kirk.ta...@verizonwireless.com.invalid> wrote: >> Is there some reason why Processors, like ListSFTP, don¹t allow custom >>attributes to be added? Relatedly, why do these processors allow users >>to add custom attributes & values in the UI even though it always throws >>the error: >> Œ[attribute]¹ validated against Œ[value]¹ is invalid because >>Œ[attribute]¹ is not a supported property >> >> - Kirk Tarou
