After you commit and deploy a node to the scheduling system, the system automatically generates an instance for the node and runs the node. You can set the Instance Generation Mode to Next Day or Immediately After Deployment when you configure scheduling properties for a node. If you set the Instance Generation Mode to Immediately After Deployment, the system immediately generates an instance for your node after the node is deployed. Then, you can view the status of the instance in Operation Center. This topic describes the rules for immediate instance generation and how to configure the immediate instance generation feature.
Rules for immediate instance generation
- If you commit and deploy a node before 23:30, the system immediately generates an
instance for the node. During the period from 23:30 to 24:00, the immediate instance
generation feature does not take effect.
- If the scheduled time for running your node is 10 or more minutes later than the time you commit and deploy your node, the system generates an instance for the node and runs the node. Then, you can view the instance in the instance list. For example, you commit and deploy your node at 18:00, and your node is scheduled to run at 18:30. In this case, the preceding situation occurs.
- If the scheduled time for running your node is less than 10 minutes from the time
you commit and deploy your node, the system generates an instance whose running is
complete for the node. The instance is an expired instance that is generated in real time. For example, you commit and deploy your node at 18:00, and your node is scheduled
to run at 18:05. In this case, the preceding situation occurs. The expired instance
is not actually run.
- If you commit and deploy a node after 23:30, the immediate instance generation feature does not take effect. In this case, you cannot find the instance generated for the node in the instance list. You can find the instance two days after the node is committed and deployed.
- If a node is an isolated node, no instances can be generated for the node. An isolated
node is a node that has no dependent ancestor nodes.
For example, you set the Instance Generation Mode parameter to Next Day for Node A and Immediately After Deployment for Node B. Node B is a descendant node of Node A. Then, the system immediately generates an instance for Node B but does not immediately generate an instance for Node A. In this case, Node B cannot find the instance of Node A based on the dependencies between Node A and Node B. As a result, Node B becomes an isolated node and cannot be scheduled to run.
- If you change the instance generation mode of a node from Next Day to Immediately After Deployment, instance generation for the node on the current day is affected.
- If the node is scheduled to run 10 or more minutes after you change the time to deploy the node, instances generated for the node are deleted and replaced with the instances that are immediately generated.
- If the node is scheduled to run within 10 minutes after you change the time to deploy the node, instances generated for the node are retained.
- You cannot set the instance generation modes of node groups to Immediately After Deployment because node groups do not support the immediate instance generation feature. Node groups include PAI nodes, do-while nodes, and for-each nodes that contain inner nodes.
Instance generation mode
- Next Day
If the node is committed and deployed before 23:30, instances are generated the next day. If the node is committed and deployed between 23:30 and 00:00, instances are generated the day after tomorrow.
- Immediately After DeploymentInstances are immediately generated after the node is committed and deployed. To generate instances for the node, the node must meet the rules for immediate instance generation. For more information, see Rules for immediate instance generation.Note A node that is scheduled to run only 10 or more minutes after it is deployed can be actually run and generate data.
Scenario: The instance generation mode of Node A is Next Day, whereas that of the descendant nodes of Node A is Immediately After Deployment.

Situation | Impact on the scheduling of the descendant nodes | Summary |
---|---|---|
Both Node A and its descendant nodes are newly created on the current day.
Instances are not generated for Node A when the descendant nodes are committed and deployed. |
|
We recommend that you change the instance generation mode of Node A to Immediately After Deployment. This way, the system can automatically generate an instance for Node A after Node A is committed and deployed, and the descendant node of Node A can be scheduled to run. |
An instance is generated for Node A, and a descendant node that uses the immediate
instance generation mode is created on the current day.
An instance has been generated for Node A when the descendant node is committed and deployed. |
|
To run a node that is configured to depend on its previous-cycle instances, you must make sure that the instances of the node are normally run on the previous day. |
Scenario: The instance generation mode of a node is changed from Next Day to Immediately After Deployment, and the scheduling cycle of the node is changed from hour to day.

Instances are generated and run for Node A and its descendant nodes the next day. After the instances are run for a period of time, the scheduling cycle of shili_2 is changed from hour to day, and the instance generation mode of shili_2 is changed to Immediately After Deployment at the T1 time point. The following figure shows the changes.

- After you change the instance generation mode and scheduling cycle of shili_2 at T1 and commit shili_2, the instances that are generated for shili_2 before T1 and used to run shili_2 after T1 are deleted. In addition, a new instance is generated for shili_2 whose scheduling cycle is changed to day.
- After shili_2 is committed and deployed at T1, shili_3, the descendant node of shili_2, depends on shili_2 whose scheduling cycle is changed to day.
- If Previous Cycle is selected and Depend On is set to Instances of Current Node for shili_2, the first instance generated after the change depends on the instances generated for shili_2 whose scheduling cycle is hour in the previous cycle.