Parameter contexts appear to be a powerful feature with many uses. For example, anaging environment-dependent global variables that must change as flows are promoted from development, to integration, to production. Also, preserving or managing parameters that are sensitive - such as settings for passwords. Those both seem to be reasonable uses for parameters that are, well, context dependent.
>From the few opportunities I've had to use them so far they also seem to be for parameters that transcend Process Group boundaries. You want to use parameter contexts for things that are global. You should avoid creating parameter contexts for each and every Process Group. I mention this because I notice a recent tendency on my current team to park flow-specific attribute settings in parameter context maps associated with each Process Group flow. I'm not quite yet experienced enough with parameter contexts to offer any argument against this other than it may tend to lead to many contexts that each become very large, maybe even redundant over time. Are there drawbacks to employing parameter contexts for each and every individual Process Group? Performance-related, configuration management, other...? Anyone work through this on their teams and determine reasonable best practices for using parameter contexts vs. Nifi variables vs. flow attributes? Thank you for any insights.
