To toss in another instance where this change can act against valid use-cases, consider any instance where you might want to use the Expression Language to cause one of these 'source' processors to not only run on a 'trigger', but also run more dynamically. Previously, you could potentially use ExtractText to set up Flowfile attributes you could then reference in GetFile's Input Directory property, allowing you to specifically target certain sub-directories for example. Without the ability to route attribute-laden Flowfiles to GetFile, however, you're limited to only using Environment variables with the expression language. Still useful in some instances, but certainly not as robust.
I'm just thinking 'out loud' here, but instead of outright disallowing incoming connections to processors that are output only, would it be possible to give some visual indication to the user that the *content* of the Flowfile will be ignored, and most likely overwritten, but still allow them to utilize the connection to trigger the processor to run (and possibly deliver attributes for the Expression Language's use)? On Tue, Dec 22, 2015 at 11:53 AM, Ricky Saltzer <ri...@cloudera.com> wrote: > Aha, that makes sense. Thanks for the explanation! I do agree that it could > be useful to have control over when those types of processors execute. > -- *Ian Moran | **Associate Software Developer** | Saggezza* Email: *ian.mo...@saggezza.com* | Office: 312-267-2929 @saggezza_inc <https://twitter.com/saggezza_inc> | LinkedIn <https://www.linkedin.com/company/saggezza> | www.saggezza.com​
