Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Revised 'User interaction and design' section

...

User interaction and design

For users who have authorization, registries can be viewed/modified by selecting a process group (root or child level) or the controller level and viewing it’s configuration.  A tab for the registry would be available and upon selection the system could list variables with their scope (node or cluster) and their values. Initially node scoped variables could be read only however cluster scope variables would be editable.  Future iterations could allow node scoped variables currently managed in properties files to be created here as well.  To create a variable users could provide key/value information, choose scope (initially cluster), indicate if it is sensitive, and provide description of the variable.

The ability to restart running processors when changes are made could also be available from the variable registry view as well (see Lifecycle Management).  A convenience feature could also be included to support uploading property files via the UI to import new variables.  This can provide a migration option for the existing custom property file support that exists today.  

Users will need a place to access the variable registry in NiFi. The main access point will likely be available as an option from the current global menu accessible via an icon in the top right corner of the application. The registry should also be accessible from other areas of the application, such as from a process group's context menu or configuration dialog, where the registry would present a subset of variables scoped to that specific process group.

From within the variable registry UI, users should be able to manage variables that are being used in the NiFi instance or across instances if in a cluster. The ability to perform certain actions will depend on any access policies that may have been set. Users should be able to:

  • view a list of all variables
  • view the components (by name or ID depending on access policies) that reference each variable
  • view variable metadata like variable name, variable type, variable value, a description of the variable, created on/by, and last updated on/by
  • filter the view to only show variables available or currently referenced by a particular component or components
  • filter the view by other relevant parameters (TBD)
  • create new variables, apply scope from which the variable will be available, and provide associated metadata
  • import other variables from a property file
  • edit and delete existing variables

It will be especially important to effectively communicate with the user when importing, editing, and deleting variables. For example, consider these scenarios: (1.) a variable is imported that has the same name as an existing variable, or (2.) a variable's value referenced by multiple components is changed. NiFi should be able to check for these conditions, present a meaningful summary, and provide guidance and/or follow-on action to resolve the conflict. Additionally, NiFi should provide relevant actions (e.g., restart) for a user when modifying variables that affect components that are currently scheduled to run.

 Current configuration dialogs will need to accomodate new functionality for users to see and choose available variables. Depending on a user's experience level and knowledge of the data flow, a tiered experience for variable selection would be ideal. For example, a clearly labeled, clickable element to see a list of and choose existing variables would help a less experienced user whereas the ability to simply type into a form field with autocomplete assistance would help an experienced user work more efficiently. A way to quickly edit variables from configuration dialogs will likely be desired as well. This way, a user would not need to interrupt their workflow by accessing the full variable registry UI to make only a single changeVariables would need to be referenced within component properties that support expression language statement.  To show users the variables that are within the scope of a particular processor a convenience feature for code completion could be provided to support variable lookup.

Questions

Below is a list of questions to be addressed as a result of this requirements document:

...