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 Properties in the right-side navigation pane. In the Properties panel, configure time properties for the node in the Schedule section. 调度配置The following table describes the parameters required for configuring time properties for a node.
Parameter Description
Instance generation mode The instance generation mode of the node.
Scheduling type The status of the node when it is scheduled.
Recurrence The recurrence of the node, which determines the scheduled time of the node and the number of instances to be generated for this node.
Timeout period The timeout period for the node. If the period of time for which the node is running 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. Also, you must ensure that the idempotence of data is not affected.
Validity period The period of time during which the node is automatically scheduled based on your configurations.

Instance generation mode

After a node is committed to and deployed in the production environment, the recurring instances of the node 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 recurring instances in full mode. After the node is committed and deployed, recurring instances are generated and automatically scheduled on the next day.
  • Immediately After Deployment: generates recurring instances immediately after the node is committed and deployed. The recurring instances are run for the node 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 after you commit and deploy the node, the recurring 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 recurring instances every day for the auto triggered node that is deployed in the production environment. The instance generation mode determines when the recurring 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 specified does not take effect and no data is generated for the node.
    • 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.

Scheduling type

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 specified. 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:暂停
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.

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 running 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

  • 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 recurring instances every day from the next day. Then, the recurring 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, the recurring 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 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 Schedule a node by hour.
    • Day: The node is automatically run once every day. For more information, see Schedule a node by day 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 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 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 Schedule a node by year.
  • Usage notes
    • If a node is committed and deployed between 23:30 and 00:00, the scheduling system generates recurring 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 successfully run.
      Note
      • If not all its ancestor instances are successfully run, the node instance is in the Pending (Ancestor) state at the scheduled time.
      • If all its ancestor instances are successfully run, the node instance enters the Pending (Schedule) state before the scheduled time arrives.
      • If all its ancestor instances are successfully run, 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 the 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 scheduling system returns a success response, and the duration is 0 seconds. In addition, no operational logs are generated, and the running 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 generate retroactive data for the node, you must set the data timestamp to Sunday, which is one day earlier than the scheduled time of the node. This way, the node can be tested or retroactive data can be generated when the node is run and generates data on Monday.

  • Examples
    • If a node that is scheduled by the 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 the day
    Schedule a node to run at 12:00 every Friday Scheduling by the week
    Schedule a node to run on the last day of every month Scheduling by the month
    Schedule a node to run on the last day of every quarter Scheduling by the 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 running 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, retroactive data generation 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, you must ensure the data idempotence of the node 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.
  • Rerun

    The following table describes the valid values of the Rerun parameter.

    Value Description
    Allow Regardless of Running Status If the data idempotence of a node is not affected after the node is rerun multiple times, you can specify this value for the Rerun parameter.
    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 specify this value for the Rerun parameter.
    Disallow Regardless of Running Status If the data idempotence of a node cannot be ensured after the node is rerun, you can specify this value for the Rerun parameter.
    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 select Disallow Regardless of Running Status for the Rerun parameter.
  • 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 number of times for which a node is rerun after an error occurs. If you set the Number of Reruns parameter to n, the node is rerun n - 1 times.
    • The default value of the Number of Reruns parameter is 3. The minimum value is 1, and the maximum value is 10. A value of 1 indicates that the node is not rerun after an error occurs. A value of 10 indicates that the node is rerun nine times after an error occurs. You can change the value of this parameter based on your business requirements.
    Rerun Interval The interval at which a node is rerun after an error occurs. 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 select Disallow Regardless of Running Status for the Rerun parameter. In this case, the node is not allowed to rerun after an error occurs.
    • You can set the default number of reruns and default rerun interval for the nodes in the workspace on the Workspace Management page.
    • 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 based on the configured scheduling properties. After the period expires, the node is not automatically run.

If the validity period is exceeded, you can view the node on the Cycle Task page of Operation Center, but the scheduling system does not generate instances for this node.