This topic describes how to configure time properties for a node, including the instance generation mode, rerun properties, and scheduling cycle.

Go to the Properties tab

  1. Log on to the DataWorks console.
  2. In the left-side navigation pane, click Workspaces.
  3. After you select the region in which the workspace that you want to manage resides, find the workspace and click Data Analytics in the Actions column.
  4. On the Scheduled Workflow tab of the DataStudio page, double-click a node in the left-side navigation pane.
  5. Click the Properties tab in the right-side navigation pane. On the Properties tab, configure time properties for the node in the Schedule section.
    Schedule

Configure the instance generation mode

You can use the Instance Generation Mode parameter to configure the instance generation mode of a node. This parameter has the following values:
  • Next Day: If you select this option, instances are generated in full mode.
    • If the node is committed and deployed before 23:30, instances are generated and take effect on the next day.
    • If the node is committed and deployed after 23:30, instances are generated and take effect on the day after the next day.
  • Immediately After Deployment: If you select this option, instances are immediately generated after the node is committed and deployed. For more information, see Configure time properties for a node to immediately generate an instance.

Configure the parameters related to the node status

  • Normal: If you set the Recurrence parameter to Normal, the node is run based on the setting of the Scheduling Cycle parameter. By default, the Recurrence parameter is set to Normal.
  • Dry Run: If you set the Recurrence parameter to Dry Run, the node is run based on the setting of the Scheduling Cycle parameter. However, the scheduling system does not actually run the node but directly returns a success response.
  • Rerun: Select a rule for rerunning the node based on your business requirements. Valid values: Allow Regardless of Running Status, Allow upon Failure Only, and Disallow Regardless of Running Status.
    Note
  • Auto Rerun upon Error: specifies whether to automatically rerun the node after an error occurs. This parameter is displayed only if the Rerun parameter is set to Allow Regardless of Running Status or Allow upon Failure Only. If you select this check box, you can specify the maximum number of automatic reruns and a rerun interval.
    • Auto Rerun Times upon Error: If you set the Auto Rerun Times upon Error parameter to n, the node is rerun n - 1 times. The default value of the Auto Rerun Times upon Error parameter is 3. The minimum value is 1, and the maximum value is 10. The value 1 indicates that the node is not rerun after an error occurs. The value 10 indicates that the node is rerun nine times after an error occurs. You can change the parameter value based on your business requirements.
    • Auto Rerun Interval upon Error: specifies the interval at which automatic reruns are performed after an error occurs. You can set this parameter based on your requirements. Valid values: 1 to 30. Default value: 30. Unit: minutes.

    This parameter is not displayed if you set the Rerun parameter to Disallow Regardless of Running Status. In this case, the node is not rerun after an error occurs.

  • Validity Period: specifies the period during which the node is automatically run. After the specified period ends, the node is not automatically run.
  • Skip Execution: If you set the Recurrence parameter to Skip Execution, the node is run based on the setting of the Scheduling Cycle parameter. However, the scheduling system does not actually run the node but directly returns a failure response. If you want to suspend the node for a period of time, set the Recurrence parameter to Skip Execution.

Configure a scheduling cycle

After a node is committed and deployed, the scheduling system generates instances every day from the next day based on the time properties of the node. Then, the scheduling system runs the instances based on the running results and time of their ancestor instances. If a node is committed and deployed after 23:30, the scheduling system generates instances for the node from the day after the next day.

If you schedule a node to run every Monday, the node is run only on Mondays. On the other days in the same week, the scheduling system does not actually run the node but directly returns success responses. If you test a node that is run by week or backfill data for the node, you must set the data timestamp to the time that is one day earlier than the scheduled time of the node.

The dependencies of an auto triggered node take priority over its time properties. The scheduling system does not immediately run a node instance at the scheduled time. The system first checks whether all its ancestor instances are successfully run.
Note
  • If not all its ancestor instances are successfully run at the scheduled time, the node instance is in the Not Running state.
  • If all its ancestor instances are successfully run before the scheduled time arrives, the node instance enters the Pending (Schedule) state.
  • If all its ancestor instances are successfully run at the scheduled time, the node instance enters the Pending (Resources) state.

For more information about how to configure cross-cycle dependencies for a node, see Scenario 2: Configure scheduling dependencies for a node that depends on last-cycle instances.

You can set the Scheduling Cycle parameter to Minute, Hour, Day, Week, Month, or Year.
Note The scheduling cycle of the FTP Check node affects its stop policy.
  • If the FTP Check node is scheduled by minute or hour, the Check stop policy parameter can be set only to Number of Check stops for the node. For more information, see Configure a detection policy for an FTP Check node.
  • If you want to change the scheduling cycle of the FTP Check node for which Check stop policy is set to Check stop time from day to minute or hour, the Check stop time policy becomes invalid. In this case, you must set Check stop policy to Number of Check stops. Otherwise, the FTP Check node cannot be committed.
  • Minute: The node is automatically run once every N minutes within a specific period every day.
    In the example shown in the following figure, the node is run once every 30 minutes during the period from 00:00 to 23:59 every day. Scheduling by minute

    The minimum interval is 5 minutes. The time expression is automatically generated based on the time you select and cannot be modified.

  • Hour: The node is automatically run once every N hours within a specific period every day. For example, a node is run once every hour from 00:00 to 03:00 every day.
    Note
    • The period is a left-closed, right-closed interval. For example, if a node is scheduled to run once every hour during the period from 00:00 to 03:00, the scheduling system generates four instances for the node every day, and the four instances are run at 00:00, 01:00, 02:00, and 03:00 in sequence.
    • You can schedule a node to run only on the hour during a period. For example, you cannot schedule a node to run once every hour during the period from 00:05 to 23:59.
    • The specified period and interval are the scheduled period and interval. The specific time at which a node is actually run may be different from the scheduled time due to some reasons, such as insufficient resources.
    Scheduling by hour
    In the example shown in the preceding figure, the node is automatically run every 6 hours during the period from 00:00 to 23:59 every day. In this case, the scheduling system automatically generates and runs instances for the node, as shown in the following figure. Generate and run instances
  • Day: The node is automatically run once every day. If you create an auto triggered node, the node is configured to run at 00:00 every day by default. You can set the time based on your business requirements. In the example shown in the following figure, the time is set to 13:00. Scheduling by day
    • If you specify the Run At parameter, the node is run at the specified time every day. The time format is HH:MM.
      Note An auto triggered node can be run only when all its ancestor instances are successfully run and the scheduled time has arrived. Both prerequisites are indispensable and have no specific chronological order.
    • If you do not specify the Run At parameter, the scheduled time of the node is randomly set by default. The time is in the range of 00:00 to 00:30.

    For example, you create an import node, an analytics node, and an export node, and they are all scheduled to run at 13:00 every day. The analytics node depends on the import node, and the export node depends on the analytics node.

    The scheduling system automatically generates and runs instances for the nodes based on the time properties of the nodes. Generate and run instances
  • Week: The node is automatically run at a specified time on specific days every week. On the other days in the same week, the scheduling system still generates instances to ensure that descendant instances normally run. The scheduling system does not actually run the node or consume resources but directly returns success responses. Scheduling by week

    In the example shown in the preceding figure, the scheduling system runs the instances generated on Mondays and Fridays. It returns success responses without running the instances generated on Tuesdays, Wednesdays, Thursdays, Saturdays, and Sundays.

    The scheduling system automatically generates and runs instances for the node based on the time properties of the node. Generate and run instances
  • Month: The node is automatically run at a specified time on specific days every month. On the other days in the same month, the scheduling system still generates instances to ensure that descendant instances normally run. The scheduling system does not actually run the node or consume resources but directly returns success responses.
    Note You can set the Run Every parameter to Last Day of the Month. In this case, the node is run on the last day of every month.
    Last Day of the Month

    In the example shown in the preceding figure, the scheduling system runs the instances generated on the last day of every month. It returns success responses without running the instances generated on the other days in the same month.

    The scheduling system automatically generates and runs instances for the node based on the time properties of the node. Scheduling by month
  • Year: The node is automatically run at a specified time on specific days every year. On the other days in the same year, the scheduling system still generates instances to ensure that descendant instances normally run. The scheduling system does not actually run the node or consume resources but directly returns success responses. Scheduling by year

    In the example shown in the preceding figure, the scheduling system runs the instances generated on the first and last days of January, April, July, and October of every year. It returns success responses without running the instances generated on the other days in the same year.

    The scheduling system automatically generates and runs instances for the node based on the time properties of the node. Scheduling by year
The following table describes the typical periodic scheduling scenarios and the related configurations.
Scenario Configuration
Schedule to run at 00:00 every day Scheduling by day
Schedule to run at 12:00 every Friday Scheduling by week
Schedule to run on the last day of every month Scheduling by month
Schedule to run on the last day of every quarter Scheduling by quarter

Configure a timeout period

You can use the Timeout Period parameter to specify a timeout period. If the running time of a node exceeds the specified timeout period, the node is automatically terminated. Timeout period
  • The timeout period applies only to auto triggered node instances, data backfill node instances, and test node instances.
  • The default timeout period ranges from 72 hours to 168 hours. The system automatically adjusts the default timeout period for a node based on system loads. You can customize a timeout period, but it cannot exceed 168 hours.
Note