Kirk, As Matt points out dynamic properties of processors have meaning specific to those processors. So, we need to be careful to avoid complicating that.
You raise two other points there though that I'd like to further discuss: 1) Processors that don't really support dynamic properties should not have the + icon present (or it should be disabled) - I agree. Can you please raise a JIRA. 2) You'd like to be able to add a set of attributes to flow files that exit a given processor and would like to be able to do this without adding extra processors. - I can see how this would be helpful and cleaner in some cases. I envision that not as processor properties but rather a tab on processor configuration that lets you tag flow file attributes on flow files and which supports expression language. We should be really clear where in the flow file lifecycle that tagging occurs such as on session commit for example (so you know all other things in that processor are done). Please raise a JIRA if this is consistent with your idea. Thanks Joe On Fri, Aug 19, 2016 at 12:14 PM, Tarou, Kirk <[email protected]> wrote: > 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" <[email protected]> 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 >><[email protected]> 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 >
