After a node is committed to and deployed in the production environment, you can configure time properties for the node, such as the instance generation mode, recurrence and scheduled time, rerun properties, and timeout period for the node. This topic describes how to configure time properties for a node.

Background information

Go to the DataStudio page, double-click a node in the Business Flow section in the left-side navigation pane, and then click the Properties tab in the right-side navigation pane. In the Properties panel, configure time properties for the node in the Schedule section. Configure time propertiesThe following table describes the configuration items required for configuring time properties for a node.
Configuration item Description
Instance generation modes The mode in which instances are generated for the node in the production environment.
Scheduling types The mode in which the node is run in the production environment.
Recurrence The recurrence of the node. The recurrence determines the number of instances to be generated for this node and the time when the instances are run in the production environment.
Timeout period The timeout period for the node. If the period of time for which the node is run exceeds the specified timeout period, the node is automatically terminated.
Rerun properties Specifies whether to rerun the node and the conditions in which the node can be rerun. When you set this parameter, make sure that the data idempotence of the node is not affected.
Validity Period The period of time during which the node is automatically run as scheduled. After the period of time expires, the node is not automatically run.

Instance generation modes

After a node is committed to and deployed in the production environment, auto triggered node instances are automatically generated and scheduled based on the instance generation mode that you specify. Valid values of the Instance Generation Mode parameter:
  • Next Day: generates auto triggered node instances in full mode. After the node is committed and deployed, auto triggered node instances are generated and automatically scheduled on the next day.
  • Immediately After Deployment: generates auto triggered node instances immediately after the node is committed and deployed. The auto triggered node instances are run only if the scheduled time is 10 or more minutes later than the time you commit and deploy the node. If the scheduled time is in the past or less than 10 minutes later than the time when you commit and deploy the node, the auto triggered node instances perform dry runs. For more information, see Configure immediate instance generation for a node.
Note
  1. After an auto triggered node is committed and deployed, you can view the status of the node on the Cycle Task page of Operation Center. The scheduling system generates instances every day for the auto triggered node that is deployed in the production environment. The instance generation mode determines when the auto triggered node instances take effect. For more information about how to view the auto triggered node in Operation Center, see View auto triggered nodes.
  2. If the node is committed and deployed between 23:30 and 00:00, the instance generation mode that you specify does not take effect on the day.
    • 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 between 23:30 and 00:00, instances are generated and take effect the day after the next day.
  3. If you select Immediately After Deployment, instances are generated and run only if the scheduled time of the node is 10 or more minutes later than the time you commit and deploy the node.
  4. If you select Immediately After Deployment, the dependencies of nodes whose recurrence is modified may be affected on this day. Instances that have been run are not deleted, whereas instances whose scheduled time has not arrived are replaced by immediately generated instances. For more information, see Configure immediate instance generation for a node.

Scheduling types

The following table describes the valid values of the Recurrence parameter.
Value Description Scenario
Normal If you set the Recurrence parameter to Normal, the node is run and generates data based on the setting of the Scheduling Cycle parameter.

After the node is run as expected, the descendant nodes are also triggered and run. By default, the Recurrence parameter is set to Normal.

You want a node and the instances that are generated for this node to be run as expected.
Skip Execution If you set the Recurrence parameter to Skip Execution, the node is scheduled based on the recurrence and the scheduled time that you specify. However, the status of the node becomes Freeze and no data is generated for this node.

When this node is scheduled, the status of the node becomes Run failed and the descendant nodes cannot be run.

Note The following icon is displayed next to the name of a node that is suspended for scheduling: Suspended
You want to suspend a node and the instances generated for this node. In this case, the current node and its descendant nodes cannot be run.

You can suspend the root node of a workflow in a period of time based on your business requirements. You can also unfreeze the root node to resume the workflow as needed. For more information, see Node freezing and unfreezing.

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 node performs a dry run and no data is generated.

When the node is scheduled, the scheduling system returns a success response. However, the duration is 0 seconds, and no operational logs are generated. This dry-run node does not affect the execution of its descendant nodes and occupies no resources.

You want to suspend a node in a period of time and require that its descendant nodes be run as expected.

Recurrence

Note Scheduling settings take effect only if you turn on Periodic scheduling on the Scheduling Settings tab. For more information, see Configure scheduling settings.
  • Background information

    The Scheduling Cycle parameter determines the frequency at which the code of a node is run after the node is committed to the production environment. After a node is committed and deployed, the scheduling system generates auto triggered node instances every day from the next day. Then, the auto triggered node instances are run based on the output results of their ancestor instances and the scheduled time specified for this node. If a node is committed and deployed between 23:30 and 00:00, instances are generated and automatically scheduled for the node from the day after the next day.

  • Valid values of the Scheduling Cycle parameter
    • Minute: The node is automatically run once every N minutes within a specific period every day. For more information, see Schedule a node by minute.
    • Hour: The node is automatically run once every N hours within a specific period every day. For more information, see Schedule a node by hour.
    • Day: The node is automatically run once every day. For more information, see Schedule a node by day.
    • Week: The node is automatically run at a specified time on specific days every week. For more information, see Schedule a node by week.
    • Month: The node is automatically run at a specified time on specific days every month. For more information, see Schedule a node by month.
    • Year: The node is automatically run at a specified time on specific days every year. For more information, see Schedule a node by year.
  • Usage notes
    • If a node is committed and deployed between 23:30 and 00:00, the scheduling system generates instances for the node from the day after the next day.
    • The dependencies of an auto triggered node take priority over its time properties. The scheduling system does not immediately run the instances of a node at the scheduled time. The system first checks whether all the ancestor instances of the node are successful.
      Note
      • If not all its ancestor instances are successful, the node instance is in the Pending (Ancestor) state at the scheduled time.
      • If all its ancestor instances are successful, the node instance enters the Pending (Schedule) state before the scheduled time arrives.
      • If all its ancestor instances are successful, the node instance enters the Pending (Resources) state at the scheduled time.

      For information about how to troubleshoot a node that fails to run at the scheduled time, see Why is the auto triggered node not run when the scheduled time arrives?.

    • The time when a node is scheduled may be inconsistent with the scheduled time that you specify for the node due to unexpected issues. For example, the node needs to wait for resources.
    • For a node that is scheduled by week, month, or year, the scheduling system runs the node at the scheduled time every day. On the days that are not specified to run the node, the node performs a dry run and no data is generated for this node. The following examples are effects of a dry run:
      • The scheduling system returns a success response, and the duration is 0 seconds.
      • No operational logs are generated.
      • The execution of descendant nodes is not affected.
      • The dry-run node occupies no resources.
      Note

      If you schedule a node to run every Monday, the node is run and generates data only on Mondays. On the other days of the same week, the node performs a dry run and the scheduling system returns a success response. If you test the node or backfill data for the node, you must set the data timestamp to Sunday. The data timestamp is one day earlier than the scheduled time of the node. This way, the node can be tested or data can be backfilled when the node is run and generates data on Monday.

  • Examples
    • If a node that is scheduled by day is set to depend on a node that is scheduled every Monday, the ancestor node performs a dry run on the days except Monday, and the descendant node is automatically scheduled and generates data every day.
    • If you want the descendant node to be scheduled every Monday, you can configure time properties for the descendant node to be the same as the ancestor node. On the days except Monday, the descendant node also performs a dry run.
  • Scenarios and related configurations
    Scenario Configuration
    Schedule a node to run at 00:00 every day Scheduling by day
    Schedule a node to run at 12:00 every Friday Scheduling by week
    Schedule a node to run on the last day of every month Scheduling by month
    Schedule a node to run on the last day of the first month in every quarter Scheduling by quarter

Timeout period

You can use the Timeout Definition parameter to specify a timeout period for a node. If the period of time for which the node is run exceeds the specified timeout period, the node is automatically terminated. Take note of the following items when you use this parameter:
  • The timeout period applies to auto triggered node instances, data backfill 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 For exclusive resource groups for scheduling that you purchased before January 7, 2021, submit a ticket to contact the technical support staff to update the resource groups. The Timeout Definition parameter is available only after you update the resource groups.

Rerun properties

In the Schedule section, you can configure the conditions, interval, and number of times for rerunning a node.
Note
  • When you configure rerun properties for a node, make sure that the data idempotence of the node is not affected based on your business requirements. This helps prevent data quality issues after a failed node is rerun. For example, when you create and develop an ODPS SQL node, you can replace the INSERT INTO statement with the INSERT OVERWRITE statement.
  • You can go to the Scheduling Settings tab to configure default scheduling settings for nodes to be created. For more information, see Configure scheduling settings.
  • Rerun
    The following table describes the valid values of the Rerun parameter.
    Note You can click Specify Default Value next to the Rerun parameter to go to the Scheduling Settings tab.
    Value Scenario
    Allow Regardless of Running Status If the data idempotence of a node is not affected after the node is rerun multiple times, you can set the Rerun parameter to this value.
    Allow upon Failure Only If the rerun of a failed node does not affect the data idempotence but the rerun of a successful node does, you can set the Rerun parameter to this value.
    Disallow Regardless of Running Status If the data idempotence of a node cannot be ensured after the node is rerun, you can set the Rerun parameter to this value.
    Note
    • If you set the Rerun parameter to Disallow Regardless of Running Status, the system does not automatically rerun the node after the system recovers from an exception.
    • The Auto Rerun upon Error parameter is not displayed if you set the Rerun parameter to Disallow Regardless of Running Status.
  • Auto Rerun upon Error
    The following table describes the parameters you must set if you allow automatic reruns after an error occurs.
    Parameter Description
    Number of Reruns The default number of times that an auto triggered node is rerun after it fails to be run as scheduled.

    Valid values: 1 to 10. A value of 1 indicates that nodes are not rerun after it fails to be run as scheduled. A value of 10 indicates that nodes are rerun nine times after it fails to be run as scheduled. You can set this parameter based on your business requirements.

    Rerun Interval The interval at which a node is rerun after it fails to be run as scheduled. You can set this parameter based on your requirements. Valid values: 1 to 30. Default value: 30. Unit: minutes.
    Note
    • The Auto Rerun upon Error parameter is not displayed if you set the Rerun parameter to Disallow Regardless of Running Status. In this case, the node is not allowed to rerun after it fails to be run as scheduled.
    • You can set the default number of reruns and default rerun interval for the nodes in the workspace on the Scheduling Settings tab. For more information, see Configure scheduling settings.
    • The automatic rerun feature does not take effect if a node is automatically terminated because the timeout period is exceeded.

Validity Period

You can specify a validity period during which a node is automatically run as scheduled. After the period expires, the node is not automatically run. Nodes whose validity period expires are expired nodes. You can view the number of expired nodes on the Overview page of Operation Center and unpublish the nodes based on your requirements. For more information about the Overview page of Operation Center, see View the statistics on the Overview page.