All Products
Search

This Product

    DataWorks:Scheduling parameters

    Document Center

    DataWorks:Scheduling parameters

    Last Updated:Jun 20, 2026

    This topic answers frequently asked questions about scheduling parameters.

    How do I handle cross-day parameter substitution when getting data from the previous hour?

    • Problem description

      The table partition format is day=yyyymmdd,hour=hh24. During execution, the hour retrieves data from the previous hour. The parameters $[yyyymmdd] $[hh24-1/24] can meet this requirement, but at midnight (00:00), the hour becomes 23:00 of the current day. How do I handle this?

    • Solution

      You can modify the calculation formula of the parameter by setting datetime to $[yyyymmdd-1/24]. The calculation formula for hour remains $[hh24-1/24].

      Configuration description

      • In the code, set day=datetime, hour={hour},

      • Assign scheduling parameters for the node: datetime=[yyyymmdd-1/24],hour=[hh24-1/24]

      Example

      • If the scheduled time of an instance is 2021-7-21 00:00:00, subtracting 1 hour goes to the previous day. In this case, $[yyyymmdd-1/24] evaluates to 20210720, and $[hh24-1/24] evaluates to 23.

      • If the scheduled time of an instance is 2021-7-21 01:00:00, subtracting 1 hour still falls on the current day. In this case, $[yyyymmdd-1/24] evaluates to 20210721, and $[hh24-1/24] evaluates to 00.

    How do I handle a table partition format that contains a space, such as pt=yyyy-mm-dd hh24:mi:ss?

    Important

    Scheduling parameter assignment does not support spaces.

    You can use two custom variables for assignment as follows:

    • Date: parameter datetime=$[yyyy-mm-dd]

    • Time: parameter hour=$[hh24:mi:ss]

    After obtaining the date and time separately, concatenate them with a space in the code as pt=${datetime} ${hour}. For example, use select * from xc_demo_partition where dt='${key1} ${key2}'; in the SQL code, and configure key1=$[yyyymmdd] key2=$[hh24miss] in Schedule Settings > Parameters on the right side.

    A node is scheduled to run at 20:00, and its parameters reference the scheduled time ($cyctime or $[yyyymmddhh24miss]). If an upstream failure causes the node to actually run at 00:00 the next day, which time is used for its scheduling parameters?

    The scheduled time of an instance can be understood as the expected run time. The scheduled time may differ from the actual run time because the task may be delayed due to reasons such as waiting for resources. The scheduled time of an instance is absolute and does not change with the actual run time.

    Scheduling parameters use the scheduled time of the instance. The substitution values of scheduling parameters are determined when the instance is generated and do not change with the actual run time. Therefore, you do not need to worry about whether the scheduling parameter values will change. In the Operation Center > Scheduled Instances page, the Scheduled Time field in the Properties panel shows the expected run time of the instance (such as 2021-07-13 00:00:00), which you can compare with the Start Time (such as 00:00:27) for verification. On the Data Studio page, configure var1=$bizdate var2=$cyctime var3=$[yyyymmdd] var4=$[yyyymmddhh24miss] in Schedule Settings > Parameters. Set Schedule to Day and Scheduled Time to 00:00. Use select '${var1}' '${var2}'; in the code to verify the business date and scheduled time values respectively.

    How do I configure time parameters for an ODPS Spark node?

    When you create an ODPS Spark node, you must configure the parameters on the editing page. The system executes the parameters in the configured order.

    After configuring variables in the code, click Schedule Settings on the right side of the editing page and assign values to the variables in the parameters panel. For more information about scheduling parameters, see Configure scheduling parameters. For example, enter $(var) in the Parameters field of the ODPS Spark node, add a row in the parameter table with the parameter name var and the parameter value $bizdate, and then click Preview Parameters to verify the substitution result.

    How can I use a scheduling parameter with a node that cannot process it directly?

    Some nodes, such as batch synchronization nodes, cannot directly use the return values of scheduling parameters after the parameters are configured. For these nodes, you can configure an assignment node as the upstream node of the target node. The assignment node references the scheduling parameters, processes and transforms the return values, and then passes the final parameter values to the downstream target node through the node context feature.

    Key concepts

    • When you directly use a MaxCompute date function to get a time value, the return value is the time displayed on the machine that executes the compute task. When the same instance is executed at different times, the returned time changes.

    • When you use a scheduling parameter to get a time value, the return value is calculated based on the scheduled time. Regardless of when the same instance is executed, the returned time does not change.

    How do I test scheduling parameters in Data Studio?

    Because scheduling parameters are automatically substituted only by the scheduling system, if you want to test scheduling parameter substitution in Data Studio, you can use Perform Smoke Testing in Development Environment.

    Note

    Because Data Integration tasks do not support testing in the development environment, if you want to test scheduling parameter substitution for such tasks, we recommend that you create an SQL node, use smoke testing in the development environment to test the scheduling parameters separately, and then use the parameters in the Data Integration node after confirming the results meet expectations.

    FAILED: ODPS-0130161:[1,84] Parse exception - invalid token '$' error

    Cause: The scheduling parameter has not been assigned a value, or the assignment is invalid.

    Solution:

    1. Check whether the scheduling parameter has been assigned a value.

    2. Check whether the configured scheduling parameter meets the requirements. For more information, see Configure scheduling parameters.

    Important

    After modifying the parameter configuration, you must submit and deploy the changes. After deployment, check the properties panel of the scheduled task in the production Operation Center to verify that the parameters reflect the latest configuration.

    params format error，please check your params（key=values）

    Solution:

    1. Check whether the variables have been assigned values.

    2. Check whether there are extra spaces in the scheduling parameters.

    3. In the node name, a period (.) and Chinese characters cannot be used together.

    Example: time①=②$[yyyymmdd③hh24:mi:ss]time1=$[yyyymmdd]④time2=$[hh24:mi:ss] (①②③④ indicate the positions of spaces).

    • No spaces are allowed on either side of the equal sign (=) in a scheduling parameter. This applies to positions ① and ② in the example.

    • Spaces are not supported in scheduling parameter values. This applies to position ③ in the example.

    • Two scheduling parameters must be separated by a single space. This applies to position ④ in the example.

    Key concept

    Operation

    Description

    Run

    After the first run, you must manually assign a constant value to the variable. The first assignment is recorded. If you modify the code, the variable still uses the value assigned during the first run.

    Run with Parameters

    When you use Run with Parameters, you must manually assign constant values to the variables in the current code. If you modify the variables in the code, use Run with Parameters to reassign constant values.

    Note

    If you want to change the resource group for task execution, use Run with Parameters.

    Perform Smoke Testing in Development Environment

    This mode simulates the automatic scheduling scenario by manually selecting a business date to obtain the substitution values of scheduling parameters for the specified business date.

    In the code editor on the Data Studio page, you can use built-in system variables (such as ${bdp.system.cyctime}) or custom variables (such as ${var1}). Assign values to variables in the Schedule Settings > Parameters panel on the right side (such as var1=$bizdate). The system automatically substitutes the values when you run or use Run with Parameters. When you use Perform Smoke Testing in Development Environment, select a business date from the top toolbar to simulate the scheduling scenario.

    How do I check parameter substitution in the production environment?

    If you modified the scheduling parameters in Data Studio and submitted and deployed the changes, check the properties panel of the scheduled task in the production Operation Center to verify whether the scheduling parameters meet expectations. If they do not, check the task deployment page and the deployment package to verify whether the deployment was successful. Check the properties panel of the scheduled instance to view the scheduling parameter substitution for a specific instance.

    Important

    Regardless of whether an individual instance has been run, the execution parameters of the instance are updated in real time to reflect the latest parameter configuration of the production scheduled task.

    Example:

    • The scheduling parameter time1 of the current-day scheduled instance A1 of node A is set to $bizdate. The instance has been successfully run, and the parameter value in the code is the bizdate business date (specific value).

    • At a certain point during the day, the scheduling parameter time1 is changed from $bizdate to $cyctime. The execution parameter of the current-day instance then displays the cyctime scheduled time (specific value).

    • If you rerun the current instance, the latest parameter configuration is used: time1=$cyctime.

    • To view the scheduling parameter substitution used by an instance before the scheduling parameter was changed, check the logs. For more information, see the FAQ: How do I check parameter substitution for a running instance using logs?

    On the Operation Center > Scheduled Instances page, select an instance and view the actual substitution values of the scheduling parameters in the Execution Parameters field of the Properties panel at the bottom (such as var1=20210708233000 var2=20210709000000) to confirm whether the parameters are updated as expected.

    How do I check parameter substitution for a running instance using logs?

    In the code, look for the SKYNET_PARAVALUE keyword.

    07-09 00:00:19  INFO SKYNET_RERUN_MODE=1:
07-09 00:00:19  INFO SKYNET_FLOW_PARAVALUE=:
07-09 00:00:19  INFO SKYNET_ONDUTY=xxx:
07-09 00:00:19  INFO SKYNET_SYSTEMID=:
07-09 00:00:19  INFO CALC_ENGINE_IDENTIFIER=xxx:
07-09 00:00:19  INFO SKYNET_SOURCEID=xxx:
07-09 00:00:19  INFO SKYNET_PARAVALUE=var1=20210708233000 var2=20210709000000:
07-09 00:00:19  INFO SKYNET_TASKID=xxx:
07-09 00:00:19  INFO SKYNET_TENANT_ID=283789484710656:
07-09 00:00:19  INFO SKYNET_ID=700003341088:
07-09 00:00:19  INFO SKYNET_JOBID=700200619122:
07-09 00:00:19  INFO SKYNET_NODENAME=xc_partition_copy:
07-09 00:00:19  INFO SKYNET_CYCTYPE=0:
07-09 00:00:19  INFO SKYNET_DSC_JOB_VERSION=1:
07-09 00:00:19  INFO SKYNET_TASK_INPUT={}:
07-09 00:00:19  INFO SKYNET_FLOWNAME=ATCLOUD_FLOW:
07-09 00:00:19  INFO FILE_ID=700003341088:

    How do I define the time zone for scheduling parameters?

    Daylight Saving Time (DST) is supported for instance generation and parameter partition calculation, ensuring correct execution on the days when DST starts and ends. The following uses US Pacific Time as an example:

    • On the day DST starts, 23 instances are generated. Shifting 10 minutes before 03:00 on that day results in 01:50. Tasks scheduled at 02:00 on the day DST starts are dry-run.

    • On the day DST ends, 24 instances are generated. Shifting 10 minutes before 03:00 on that day results in 02:50.

    For daily, weekly, and monthly scheduled nodes on the day DST starts, if the configured run time falls within the skipped time period, the run time of the instance generated for that day is set to 00:00 of that day.

    The scheduling parameters of a node have been configured, submitted, and deployed, but the return values remain unchanged

    Check whether the scheduling parameters are overridden by workflow parameters with the same name. For more information about troubleshooting, see Check workflow parameters.

    If a workflow parameter with the same name exists and is not needed, delete it. If you need to keep the workflow parameter, rename the node scheduling parameter.