Russ I don't think we provide anything particularly helpful here to do this conveniently. You could of course script this external to NiFi to make HTTP calls to shut off such items. Spitballing ideas here but what about giving you the ability to tag components with some label and then be able to do global execution of some task (stop/start/disable/delete/etc..) against components that you're authorized to and which have those labels.
Do you think this would be a typical use case or do you feel this is useful because you're testing right now? Does the above idea make sense or do you have other suggestions? Thanks Joe On Wed, Nov 30, 2016 at 3:14 PM, Russell Bateman <[email protected]> wrote: > I've written a custom processor for some trivial profiling, time-stamping, > time-since, histogram-generating, etc., but would like the ability to turn > all instances completely off without having to visit each instance in the > UI. If it works out, I might consider even leaving some instances in > production- or at least staging-environment flows. > > 1. I know that the NiFi Expression Language has access to various system- or > NiFi properties or settings, but what would someone suggest as best practice > for this? (Don't invade /conf/nifi.properties/, etc.) > > 2. I guess I'd add a property to configure in my processor and check whether > it evaluates true/false/etc. based on the source data (whatever that will > be--see previous paragraph)? > > 3. Last, if this processor is thereby reduced merely to > > session.transfer( flowfile, SUCCESS ); > > there isn't any handling even more minimal or faster than that in the sense > of turning a processor off, right? > > Thanks for any suggestions, > > Russ
