Parameter Context

    The premise of local tasks referencing global parameters is that you have already defined Global Parameter. The usage is similar to the usage in , but the value of the parameter needs to be configured as the key in the global parameter

    As shown in the figure above, and are examples of local parameters referencing global parameters. Observe the last line of the above figure, local_param_bizdate uses ${global_bizdate} to refer to the global parameter. In the shell script, you can use ${local_param_bizdate} to refer to the value of the global variable global_bizdate, or set the value of local_param_bizdate directly through JDBC. In the same way, local_param refers to the global parameters defined in the previous section through ${local_param}. ​Biz_date, biz_curdate, system.datetime are all user-defined parameters, which are assigned via ${global parameters}.

    Pass parameter from upstream task to downstream

    DolphinScheduler Parameter transfer between tasks is allowed, and the current transfer direction only supports one-way transfer from upstream to downstream. The task types currently supporting this feature are：

    When defining an upstream node, if there is a need to transmit the result of that node to a downstream node that has a dependency. You need to set a parameter whose direction is OUT in [Custom Parameters] of [Current Node Settings]. At present, we mainly focus on the function of SQL and SHELL nodes that can input parameters.

    prop is user-specified; the direction is selected as OUT, and will be defined as parameter output only when the direction is OUT. The data type can be chosen from different data structures as needed; the value part is not required.

    If the result of the SQL node has only one row, one or more fields, the name of the prop needs to be the same as the field name. The data type can be chosen to be something other than LIST. The parameter will select the value corresponding to the column with the same name as this parameter in the column name in the SQL query result.

    Let’s take another example of the process that contains the SQL node in the above picture:

    The [createParam1] node in the above figure is defined as follows:

    png05

    [createParam2] node is defined as follows:

    You can find the value of the variable in the [Workflow Instance] page to find the corresponding node instance.

    Node instance [createparam1] is as follows:

    Here, the value of “id” is equal to 12.

    Let’s see the case of the node instance [createparam2].

    png08

    There is only the value of “id”. Although the user-defined sql looks up the fields “id” and “database_name”, only one parameter is set because only one parameter “id” is defined for out. For display reasons, the length of the list is already checked for you here as 10.

    prop is user-specified. The direction is selected as OUT. The output is defined as a parameter only when the direction is OUT. Data type can choose different data structures as needed; the value part is not required to be filled. The user needs to pass the parameter, and when defining the shell script, the output format of ${setValue(key=value)} statement is required, key is the prop of the corresponding parameter, and value is the value of the parameter.

    For example, , set “trans” to “Hello trans”, and the variable trans can be used in downstream tasks:

    use-parameter-shell