What is a Hop variable?

You don’t want to hardcode your solutions. It’s simply bad form to hardcode host names, user names, passwords, directories and so on. Variables allow your solutions to adapt to a changing environment. If for example the database server is different when developing than it is when running in production, you set it as a variable.

Fields, parameters, and variables implicitly are available downstream if in scope. You can pass them again any number of levels, but the "get parameters/variables" button only retrieves from one level above.


Fields are columns in data row(s) and are viewable in some transform field textboxes and columns and you can see the fields in scope and its value when looking at transform row results after executing a workflow/pipeline (click the little grid icon on the bottom-right of a transform to see a preview of the cached results). Field values can be passed upstream for example if you use a pipeline executor and fill in the Result rows tab and use it in conjunction with a “copy rows to result” transform in the child pipeline.


Think of parameters as function arguments, which turn into variables with the same name. When adding parameters you are basically creating MyPipeline(parameter1, parameter2,..). Parameters (e.g. in pipeline or workflow properties) need to be declared at least once in every pipeline or workflow.

For example, if you set parameters on a pipeline executor, the pipeline that is being called must declare the same parameter names in its pipeline properties (set to NULL if you want to inherit values). Parameters can not be “sent” upstream, but you can use a Set variables transform, but they become variables in the scope they are defined in.

Explicit vs Implicit: If you set a parameter to a default value, it becomes explicit (e.g. when editing a pipeline in pipeline properties), and it will take precedence over the same named implicit variable (a passed-in variable), but not take precedence over the same named explicit parameter. So whenever you see a transform with a column title “Parameters/Variables” that means an explicit parameter is sent to a function that will then set a variable name overriding any previous set parameter with the same name (useful if wanting to override an explicitly set param/variable in the child).

To change implicit parameter behaviour to explicit, you can also disable “pass all parameters” on the pipeline action. Parameters are simply variables which are explicitly defined in a workflow or pipeline to make them recognizable from outside those objects. They can also have a description and a default value.

You cannot combine implicit variable inheritance with explicit parameter definitions. So, if you add parameters to the pipeline definition (or to a pipeline executor) and you want it set, you must add it to the parameters tab of the child pipeline action/transform even if the same variable already exists.

Advanced: there are multiple layers in hop where you can set variables that do or do not get overwritten downstream (Java → hop environment → project → run configuration → workflow → pipeline).


Variables are more global and the scope can be targeted (entire Java VM, grandparent workflow, etc.) whereas fields are the data flowing between the transforms. Local variables can be set in a pipeline but should not be used in the same pipeline as they are not thread-safe and can inherit a previous value. It is better to send or return variables to another pipeline/workflow before using them. Variables can be passed upstream if the variable was set to a larger scope. E.g.: if a variable was set in a parent with "valid in the current workflow".

Think of variables in 2 scopes: runtime variables and environment/workflow variables:

  • Runtime variables – Runtime variables depend on pipeline information to generate, so they cannot be set beforehand, you need to declare those differently to be able to use them.

  • Environment/workflow variables or parameters – Environment variables/parameters are set once and used when needed in any downstream workflow/pipeline and there is no need to use Get Variables , you can refer to them directly like $${myVariable$} unless you need it in a field/data stream.

    • E.g.: Define a parameter only once, even just in the Pipeline Executor (no need to define in receiving pipeline)

A pipeline needs to start to get new variables. A running or nested pipeline can’t fetch new variable values. A pipeline is considered started when a pipeline starts for every row in a pipeline executor. An alternative is to use parameters.

How do I use a variable?

In the Hop user interface all places where you can enter a variable have a '$' symbol to the right of the input field:

The variable indicatorm

You can specify a variable by referencing it between an opening ${ and a closing }.


Please note that in the case of a textvar (a text field that supports variables), you don’t have to specify a variable in these places. You can enter hard-coded values (although we advise to use variables where possible).

Combinations of a variable with other free-form text are also possible, like in the example below:

You can see a list of defined variables by using CTRL-SPACE (CMD-SPACE on OSX) in the input field. This helper will insert a selected variable into the input field. Only environment variables and variables with the JVM scope are shown here. Variables that are created in pipeline or workflow with a parent, grant parent or root workflow job need to be entered manually

Hexadecimal values

In rare cases you might have a need to enter non-character values as separators in 'binary' text files with for example a zero byte as a separator. In those scenarios you can use a special 'variable' format:

$[<hexadecimal value>]

A few examples:

Value Meaning


A single byte with decimal value 0


Two bytes with decimal value 65535


The 2 bytes representing UTF-8 character Σ


The 3 bytes representing UTF-8 character ⌨


The 4 bytes representing UTF-8 character 𝄞

How can I define variables?

Variables can be defined and set in all the places where it makes sense:

  • in hop-config.json when it applies to the installation

  • in an environment configuration file when it concerns a specific lifecycle environment

  • In a project

  • In a pipeline run configuration

  • As a default parameter value in a pipeline or workflow

  • Using the Set Variables transform in a pipeline

  • Using the Set Variables action in a workflow

  • When executing with Hop run


Variables are local to the place where they are defined.

This means that setting them in a certain place means that it’s going to be inherited from that place on.

This also means that’s important to know where variables can be set and used and the hierarchy behind it.


Table 1. Variables Hierarchy
Place Inheritance

System properties

Inherited by the JVM and all other places in Hop


Inherited by run configurations

Run Configurations

Pipeline run configurations are inherited by the environment


Inherited by the pipeline run configuration


Inherited by the workflow run configuration

Metadata objects

Inherited by the place where it is loaded


Pipeline and workflows can (optionally) accept parameters.

Workflow and pipeline parameters are similar, and are a special type of variable that is only available within the current workflow or pipeline.

Workflow and pipeline parameters can have a default value and a description, and can be passed on from workflows and pipelines to other workflows and pipelines through a variety of workflow actions and pipeline transforms.

System properties

All system properties are variables that are available in all of your currently running Apache Hop instance. System properties are available as variables as well as all Java system properties.

System properties get set in the Java Virtual Machine that runs your Apache Hop instance. This means that you should limit yourself to only those variables which are really system specific.

You can define new system properties in the Hop GUI using the system properties editor (using the menu bar or the Hop icon menu):

The system properties menu in Hop GUI

These variables will be written to the hop-config.json file in your hop installation’s config folder or in your ${HOP_CONFIG_FOLDER} location.

  "systemProperties" : {
    "MY_SYSTEM_PROPERTY" : "SomeValue"
even though you can manually change the hop-config.json or any of the other configuration files, you’ll rarely, if ever, need to. Only change hop-config.json manually if you know what you’re doing.

You can also use the hop-config command line tool to define system properties:


Environment Variables

You can specify variables in project lifecycle environments as well.

This helps you configure folders and other things which are environment specific, and lets you keep a clean separation between code (your project) and configuration (your environment).

You can set those in the environment settings dialog or using the command line:

sh -e MyEnvironment -em -ev VARIABLE1=value1

Run Configurations

You can specify variables in pipeline run configurations and workflow run configurations to make a pipeline or workflow run in an engine agnostic way.

For example, you can have the same pipeline run on Hadoop with Spark and specify an input directory using hdfs:// and on Google DataFlow using gs://


You can define variables in a workflow either with the Set Variables, JavaScript actions or by using parameters.


You can define variables in a pipeline either with the Set Variables, JavaScript transforms or by defining parameters.

IMPORTANT As mentioned in the Set Variables documentation page, you can’t set and use variables in the same pipeline, since all transforms in a pipeline run in parallel.

Available global variables

The following variables are available in Hop through the configuration perspective. If you have the menu toolbar enabled in the configuration perspective’s General tab, these variables are also available through Tools → Edit config variables.

Variable name Default Value Description



Set this variable to Y to return 0 when all values within an aggregate are NULL. Otherwise by default a NULL is returned when all values are NULL.



Set this variable to Y to set the minimum to NULL if NULL is within an aggregate. Otherwise by default NULL is ignored by the MIN aggregate and MIN is set to the minimum value that is not NULL. See also the variable HOP_AGGREGATION_ALL_NULLS_ARE_ZERO.



Set this variable to Y to allow your pipeline to pass 'null' fields and/or empty types.



Set this variable to 'Y' if you want to test a more efficient batching row set.


The name of the variable containing an alternative default bignumber format



This is the default polling frequency for the transforms input buffer (in ms)


The name of the variable containing an alternative default date format


The name of the variable containing an alternative default integer format


The name of the variable containing an alternative default number format


Defines the default encoding for servlets, leave it empty to use Java default encoding


The name of the variable containing an alternative default timestamp format



Set this variable to Y to disable standard Hop logging to the console. (stdout)



NULL vs Empty String. If this setting is set to Y, an empty string and null are different. Otherwise they are not.



This project variable is used by the Text File Output transform. It defines the max number of simultaneously open files within the transform. The transform will close/reopen files as necessary to insure the max is not exceeded



This project variable is used by the Text File Output transform. It defines the max number of milliseconds between flushes of files opened by the transform.



Set this variable to N to preserve global log variables defined in pipeline / workflow Properties → Log panel. Changing it to true will clear it when export pipeline / workflow.



Name of te variable to set so that Nulls are considered while parsing JSON files. If HOP_JSON_INPUT_INCLUDE_NULLS is "Y" then nulls will be included otherwise they will not be included (default behavior)



System wide flag to allow lenient string to number conversion for backward compatibility. If this setting is set to "Y", an string starting with digits will be converted successfully into a number. (example: will be converted into 192 or 192.168 or 192168 depending on the decimal and grouping symbol). The default (N) will be to throw an error if non-numeric symbols are found in the string.



This is the name of the variable which when set should contains the path to a file which will be included in the serialization of pipelines and workflows



Set this variable to 'Y' to precede transform/action name in log lines with the complete path to the transform/action. Useful to perfectly identify where a problem happened in our process.



The log size limit for all pipelines and workflows that don’t have the "log size limit" property set in their respective properties.



The hop log tab refresh delay.



The hop log tab refresh period.



The maximum number of action results kept in memory for logging purposes.



The maximum number of logging registry entries kept in memory for logging purposes.



The maximum number of log lines that are kept internally by Hop. Set to 0 to keep all rows (default)



The maximum age (in minutes) of a log line while being kept internally by Hop. Set to 0 to keep all rows indefinitely (default)



A variable to configure Tab size



The maximum number of workflow trackers kept in memory



Specifies the password encoder plugin to use by ID (Hop is the default).



Name of the environment variable that contains the size of the pipeline rowset size. This overwrites values that you set pipeline settings


A comma delimited list of classes to scan for plugin annotations



The name of the variable that optionally contains an alternative rowset get timeout (in ms). This only makes a difference for extremely short lived pipelines.



The name of the variable that optionally contains an alternative rowset put timeout (in ms). This only makes a difference for extremely short lived pipelines.



The default part size for multi-part uploads of new files to S3 (added and used by by the AWS S3 VFS plugin)



The name of the variable that defines the timer used for detecting server nodes


A variable to configure jetty option: acceptors for Carte


A variable to configure jetty option: acceptQueueSize for Carte


A variable to configure jetty option: lowResourcesMaxIdleTime for Carte



This project variable will set a time-out after which waiting, completed or stopped pipelines and workflows will be automatically cleaned up. The default value is 1440 (one day).



A variable to configure refresh for Hop server workflow/pipeline status page



Set this variable to N to preserve enclosure symbol after splitting the string in the Split fields transform. Changing it to true will remove first and last enclosure symbol from the resulting string chunks.


You can use this variable to speed up hostname lookup. Hostname lookup is performed by Hop so that it is capable of logging the server on which a workflow or pipeline is executed.



The maximum number of transform performance snapshots to keep in memory. Set to 0 to keep all snapshots indefinitely (default)



Set this value to Y if you want to use the system file open/save dialog when browsing files




A variable to configure the maximum number of characters of text that are extracted before an exception is thrown during extracting text from documents





A variable to configure the minimum allowed ratio between de- and inflated bytes to detect a zipbomb




Set this variable to the name of an existing Neo4j connection to enable execution logging to a Neo4j database.

Environment variables

Set the environment variables listed below in your operating system to configure Hop’s startup behavior:


Set this variable to a valid path on your machine to store Hop’s audit information. This information includes last opened files per project, zoom size and lots more.


Hop stores your configuration in the config folder by default. Set this environment variable to point to a folder outside of your Hop installation to keep your configuration, projects and environment list etc, no matter which Hop version or installation you use.

copy the contents of an existing hop/conf folder to the path set in HOP_CONFIG_FOLDER to move the configuration from one of your Hop installations to your new central location.

Set this variable to point Hop to a comma separated list of folders where you want Hop to look for additional plugins.

When using this variable it will also unset your default plugins folder, make sure to add the default plugin folder to the comma separated list. This can be a relative path to the installation eg. export HOP_PLUGIN_BASE_FOLDERS=./plugins,/additional/plugin/folder.
The ./plugins will point to the plugins in the base installation folder

This is a comma separated list of folder containing JDBC drivers, default value is lib/jdbc. If you still need the default jdbc drivers when changing this you need to include the default folder path.

Additionally, the following environment variables can help you to add even more fine-grained configuration for your Apache Hop installation:

Variable Default Description



Set this variable to 'Y' to automatically create config file when it’s missing.



The system environment variable pointing to the alternative location for the Hop metadata folder



Set this variable to Y to redirect stderr to Hop logging.



Set this variable to Y to redirect stdout to Hop logging.



System wide flag to log stack traces in a simpler, more human-readable format