[
https://issues.apache.org/jira/browse/NIFI-7986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
George Knaggs updated NIFI-7986:
--------------------------------
Description:
Currently the assigned parameter context for a process group can only happen
from its "Configuration" window. The scope of the parameter context only
applies to processors and service controllers directly within that process
group that it is assigned, excluding any nested process groups, which may have
a different or no parameter context assigned. This is remarkably different
than how scoping worked with variables, which had an inheritance model. The
nature of these differences makes it important for users when making a copy of
a flow or importing a flow from the NiFi Registry, that contains nested process
groups, that the entire flow must be navigated and for each nested process
group open the configure window to check and possibly change the assigned
parameter context. The use of nested process groups had the advantage of
keeping flows easy to read, monitor, and maintain, but now are a disadvantage
if you want to parameterize your flows.
This issue was also highlighted in "Better Support for Parameterizing Flows"
under NiFi Feature Flows confluence blog. Specifically under "Import Flow"
section:
{code:java}
4. If there are nested Process Groups in the flow, the UX will need to provide
a way to specify which Parameter Context should be used for each of those,
since Parameter Contexts are not inherited, and because the intent of the
original flow was to use a separate context as well. This could be done either
by showing a hierarchy of the Process Groups and choosing a Parameter Context
for each, or by showing a listing of Parameter Context Names that are
referenced in the flow pulled from Registry and allowing the user to map each
of those names to a locally defined Parameter Context.
Note that this user experience for importing the flow addresses both of the
key use cases: Migration of flow from dev to test to prod, as well as the need
to create parameterized flows (i.e., import the same flow multiple times into
the same environment, each with different parameters). Each time the user
imports the flow, they can choose a new set of parameters to use.{code}
I propose a change to the configuration window for a processs group, add a
"Parameter Contexts" tab, which shows all nested process groups by name in a
list with a scope/path/breadcrumb to help identify, and also showing its
assigned parameter context. From here the user can check if the correct
parameter context is assigned to the nested process groups. There could then
be a drill in arrow ↘︎ icon for quickly drilling to the Configuration window
for the nested process group so the user can change the assigned parameter
context. It may not be feasible to navigate back to make additional changes, so
alternatively, the UI could allow the change of the assigned parameter context
from the parent process group for any nested process group.
Added bonus, the same concept could be used within the Controller Services tab
to show controllers services assigned to nested process groups, quickly
identifying which controller services are disabled or invalid, which is also a
pain when starting up flows with many nested process groups.
was:
Currently the assigned parameter context for a process group can only happen
from its "Configuration" window. The scope of the parameter context only
applies to processors and service controllers directly within that process
group that it is assigned, excluding any nested process groups, which may have
a different or no parameter context assigned. This is remarkably different
than how scoping worked with variables, which had an inheritance model. The
nature of these differences makes it important for users when making a copy of
a flow or importing a flow from the NiFi Registry, that contains nested process
groups, that the entire flow must be navigated and for each nested process
group open the configure window to check and possibly change the assigned
parameter context. The use of nested process groups had the advantage of
keeping flows easy to read, monitor, and maintain, but now are a disadvantage
if you want to parameterize your flows.
This issue was also highlighted in "Better Support for Parameterizing Flows"
under NiFi Feature Flows confluence blog. Specifically under "Import Flow"
section:
{noformat}
4. If there are nested Process Groups in the flow, the UX will need to provide
a way to specify which Parameter Context should be used for each of those,
since Parameter Contexts are not inherited, and because the intent of the
original flow was to use a separate context as well. This could be done either
by showing a hierarchy of the Process Groups and choosing a Parameter Context
for each, or by showing a listing of Parameter Context Names that are
referenced in the flow pulled from Registry and allowing the user to map each
of those names to a locally defined Parameter Context.
Note that this user experience for importing the flow addresses both of the key
use cases: Migration of flow from dev to test to prod, as well as the need to
create parameterized flows (i.e., import the same flow multiple times into the
same environment, each with different parameters). Each time the user imports
the flow, they can choose a new set of parameters to use.
{noformat}
I propose a change to the configuration window for a processs group, add a
"Parameter Contexts" tab, which shows all nested process groups by name in a
list with a scope/path/breadcrumb to help identify, and also showing its
assigned parameter context. From here the user can check if the correct
parameter context is assigned to the nested process groups. There could then
be a drill in arrow ↘︎ icon for quickly drilling to the Configuration window
for the nested process group so the user can change the assigned parameter
context. It may not be feasible to navigate back to make additional changes, so
alternatively, the UI could allow the change of the assigned parameter context
from the parent process group for any nested process group.
Added bonus, the same concept could be used within the Controller Services tab
to show controllers services assigned to nested process groups, quickly
identifying which controller services are disabled or invalid, which is also a
pain when starting up flows with many nested process groups.
> Add UI to view and update assigned parameter context for each nested process
> group.
> -----------------------------------------------------------------------------------
>
> Key: NIFI-7986
> URL: https://issues.apache.org/jira/browse/NIFI-7986
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core UI
> Affects Versions: 1.10.0, 1.12.0, 1.11.4, 1.12.1
> Reporter: George Knaggs
> Priority: Minor
>
> Currently the assigned parameter context for a process group can only happen
> from its "Configuration" window. The scope of the parameter context only
> applies to processors and service controllers directly within that process
> group that it is assigned, excluding any nested process groups, which may
> have a different or no parameter context assigned. This is remarkably
> different than how scoping worked with variables, which had an inheritance
> model. The nature of these differences makes it important for users when
> making a copy of a flow or importing a flow from the NiFi Registry, that
> contains nested process groups, that the entire flow must be navigated and
> for each nested process group open the configure window to check and possibly
> change the assigned parameter context. The use of nested process groups had
> the advantage of keeping flows easy to read, monitor, and maintain, but now
> are a disadvantage if you want to parameterize your flows.
> This issue was also highlighted in "Better Support for Parameterizing Flows"
> under NiFi Feature Flows confluence blog. Specifically under "Import Flow"
> section:
> {code:java}
> 4. If there are nested Process Groups in the flow, the UX will need to
> provide a way to specify which Parameter Context should be used for each of
> those, since Parameter Contexts are not inherited, and because the intent of
> the original flow was to use a separate context as well. This could be done
> either by showing a hierarchy of the Process Groups and choosing a Parameter
> Context for each, or by showing a listing of Parameter Context Names that are
> referenced in the flow pulled from Registry and allowing the user to map each
> of those names to a locally defined Parameter Context.
> Note that this user experience for importing the flow addresses both of the
> key use cases: Migration of flow from dev to test to prod, as well as the
> need to create parameterized flows (i.e., import the same flow multiple times
> into the same environment, each with different parameters). Each time the
> user imports the flow, they can choose a new set of parameters to use.{code}
> I propose a change to the configuration window for a processs group, add a
> "Parameter Contexts" tab, which shows all nested process groups by name in a
> list with a scope/path/breadcrumb to help identify, and also showing its
> assigned parameter context. From here the user can check if the correct
> parameter context is assigned to the nested process groups. There could then
> be a drill in arrow ↘︎ icon for quickly drilling to the Configuration window
> for the nested process group so the user can change the assigned parameter
> context. It may not be feasible to navigate back to make additional changes,
> so alternatively, the UI could allow the change of the assigned parameter
> context from the parent process group for any nested process group.
> Added bonus, the same concept could be used within the Controller Services
> tab to show controllers services assigned to nested process groups, quickly
> identifying which controller services are disabled or invalid, which is also
> a pain when starting up flows with many nested process groups.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
