Simon, One idea that's been thrown around is adding a 'variable registry' [1] where you could define variables at a group level that could be referenced by the encapsulated components. Additionally, this would help with the portability of templates when needing to define different values for different environments.
Matt [1] https://cwiki.apache.org/confluence/display/NIFI/Variable+Registry On Wed, Jan 27, 2016 at 4:30 AM, Simon Ball <[email protected]> wrote: > Other thoughts: > > This will have implications for broadcasting OnPropertyChanged events, and > potentially locking processors around the changes in properties held by the > service. I’d love to hear if anyone can think of any other significant land > mines, or has had any thoughts on anything similar. > > Simon > > On 27 Jan 2016, at 09:26, Simon Ball <[email protected]<mailto: > [email protected]>> wrote: > > One of the problems with complex flows is repetition of common > configuration. Many people also want to be able to configure things like > connection strings into an environment specific location outside of the > Flow, and parameterise the flow. Things like the Kerberos|SSL|etc Context > service help in part with this, but the problem could be generalised. > > What do people think of the idea of a configuration provider controller > service, providing essentially the same concept as environment variables, > which holds essentially a key value store which processors can refer to? A > simple way to refer to contents could be an extension on expression > language providing a config(‘key’) function. > > What are your thoughts on this? Worth knocking up a quick prototype > implementation (I’m happy to do so if there is community interest)? > > Simon > >
