Functionality
You can define variable resolvers to help you resolve expressions in the following format:
#{name:key:element}-
name: The name of the metadata element to use to resolve the variable -
key: The key or path to use to retrieve the value. -
element: In case the value retrieved is in JSON form, we can pick one of the values out of it (OPTIONAL)
| An error in resolving a variable does not lead to a failure on the level of a pipeline or workflow. |
| Because of usability reasons, errors are not immediately shown in the user interface. It would become impossible to type in any expression because of it. Check the log in the Hop GUI execution pane to see any errors thrown back by the resolvers. |
| If you find that typing in variable expressions in a table view (table grid) is too slow, uncheck the option to resolve variables in tooltips in the configuration perspective. |
Nested resolving
Suppose you have a variable with its value being a resolve expression. In that case you’ll notice that when you ask for the value of the variable, the variable resolver also is being used.
For example, you can have a PASSWORD variable pointing to value p@55w0rd in a development environment, and to a secrets vault in production by setting PASSWORD to a resolver expression like:
#{vault:secret/data/database:password}When executing a pipeline or workflow, the value of variable PASSWORD will then first be resolved to the expression and then, using the variable resolver called vault, the password is retrieved from the secrets vault.
| For now, the variable resolver is not doing any more nested resolving to avoid complications like infinite loops. |