Built-in Parameter

Version Description

Application Scenario

FineDataLink provides built-in parameters that do not need to be defined and can be called directly.

Function Description

The following figure shows the currently available built-in parameters.

Parameter Value Logic Description

• If the instance is triggered and generated by Task Schedule, the value of ${cyctime} is the time when each scheduled task starts.

• If the instance is triggered and generated by the user manually or by Event Schedule, or the service date is not specified during retry, the value of ${cyctime} is the start time of instance generation.

• If the instance is triggered and generated by the user's retry operation with the service date specified, the value of ${cyctime} is the time specified by the user.

The format of ${cyctime} is yyyy-mm-dd hh:mm:ss, and the actual output value format is 2021-09-09 20:45:50 (accurate to the second).

Example

Example: The instance is triggered and generated by Task Schedule.

With the built-in parameter ${cyctime}, you can synchronize only the data of 31 days before the running time point each time the task runs.

1. Create a scheduled task and drag the Data Synchronization node onto the page.

2. Set the data source for the node as shown in the following figure. The SQL statement is used to retrieve the data of the previous 31 days from the Stock-out Temporary Table.

The SQL statement is as follows:

SELECT * FROM `demo1`.`Stock-out Temporary Table` where Stock-out Date>DATE_SUB('${cyctime}',interval 31 day)

Click Data Preview, the retrieved data is from the 31 days before the current system time.

Note:

When you click Data Preview, the default value of cyctime is the current system time. However, when the task is running, the value of cyctime is the execution time of the scheduled task. Therefore, the data in the data preview may be inconsistent with the data written into the database during actual execution.

3. You can set Data Destination and Execution Frequency in the following steps according to the actual situation. 

The built-in parameter ${workname.opresult} is usually used to set the judgement condition for the conditional branch nodes.

Example: Task CC is executed after the scheduled task Data Duplication and Splitting is executed successfully. 

Note:

In V4.0.30 and later versions, this scenario can be implemented through Event Schedule.

1. Task CC contains a Data Synchronization node, which implements cross-database synchronization, as shown in the following figure. 

2. To make Task CC to be executed after the scheduled task Data Duplication and Splitting is successfully executed, you can use the built-in parameter ${workname.opresult}.

Drag the Conditional Branch node in front of the Data Synchronization node, and set the judgment condition in the Conditional Branch node as: ${Data Duplication and Splitting.opresult} is success.

Note:

In V4.1.0 and later versions, you need to select the task when using this parameter in the Conditional Branch node, as shown in the following figure. 

In versions earlier than V4.1.0, when using this parameter in the Conditional Branch node, you can directly input Data Duplication and Splitting.opresult in the parameter column and press the Enter Key, and input success in the text box on the right.

Note:

The parameter format is ${Upstream Node Name.opresult}.

1. Modify the message content of the Notification node to ${Data Synchronization.opresult}, as shown in the following figure.

2. After the Data Synchronization node is executed successfully, you will receive a success message.

1. Modify the message content of the Notification node to ${prepose.successInfo}, as shown in the following figure.

2. After the task is executed, you will receive a message with all names of the successfully executed upstream nodes of the Notification node.

1. Modify the message content of the Notification node to ${prepose.failedInfo} by referring to the "${prepose.successInfo} — Names of the Successfully Executed Nodes in the Upstream" section in this document. 

2. After the task is executed, you will receive a message with all names of the upstream nodes of the Notification node that fail to be executed.

This parameter takes effect within the loop container, which refers to the current loop times in the loop container, whose value is 1 for the first time and increases by 1 for each subsequent loop.

1. Drag the Notification node into the Loop Container node. The following figure shows the setting page.

2. After the task is executed, you will receive the current loop times.

The value of this parameter is the name of the current task.

Example: Use this parameter in the Notification node to notify users that the task is successfully executed.

1. The Built-in Parameter Test Task contains a Data Synchronization node and a Notification node.

2. The following figure shows the setting page of the Notification node.

3. After the task is successfully executed, you will receive the execution result of the task.

The parameter refers to the latest running result of the specified node in the specified task (non-current task). For example, ${Task 1.Data Synchronization.opresult}.

Note:

If you want to obtain the node in the current task, you are advised to use ${jobname.opresult}.

Example: The Data Synchronization node in the 01 Data Synchronization task is executed successfully before the Data Synchronization node in Task 2 is executed.

1. Task 2 contains a Data Synchronization node, which implements cross-database synchronization, as shown in the following figure.

2. To make the Data Synchronization node in the 01 Data Synchronization task to be executed successfully before the Data Synchronization node in Task 2 is executed, you need to drag the Conditional Branch node in front of the Data Synchronization node, and set the judgment condition in the Conditional Branch node as shown in the following figure.