Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Removed extra space

...

User interaction and design

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 change.

Questions

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

...