Typical scenarios for further processing scheduling parameter return values-DataWorks(DataWorks)-阿里云帮助中心

In scheduled tasks, standard time formats returned by scheduling parameters may not meet complex business requirements, such as obtaining the end of a month, a quarter, or a custom time offset. You can apply engine functions to the return values to produce the required time format. Convert values directly in a computing node or preprocess them in an assignment node.

Business scenarios

In data development and ETL, scheduling often depends on specific time dimensions. Examples include monthly settlement based on a financial period, such as the last day of the previous month, and incremental data synchronization in hourly or minute-level windows. Scheduling parameters return standard time formats by default and cannot directly produce these complex, nonstandard time strings, so their return values require further processing.

Solutions

There are two main ways to further process scheduling parameters: process them directly in a node that supports functions, such as ODPS SQL, or preprocess them in an assignment node and pass the results to downstream nodes. Choose based on whether the destination node can execute function transformations in its code.

Direct processing: In nodes that support functions, such as ODPS SQL, use engine functions directly in the code to convert scheduling parameter return values.
Indirect processing: If the destination node, such as some offline synchronization nodes, cannot execute function transformations in its code, add an upstream assignment node. The assignment node performs the conversion and passes its output as a context parameter to downstream nodes.

Procedure

In the following scenarios, assume that the scheduled time (CYCTIME) of the task instance is 20250727000500.

Scenario 1: Process return values directly in an SQL node

An ODPS SQL node can use MaxCompute SQL functions directly in SQL statements to process scheduling parameters. For other SQL nodes, use functions supported by their respective engines.

Get the last day of the previous month

Get the last day of the previous month in yyyymmdd format. This is commonly used for monthly partitions or settlement.

Parameter configuration: Configure a scheduling parameter to obtain the year and month of the current scheduled task.
last_month=$[yyyy-mm]
Processing logic: In ODPS SQL code, first construct the first day of the current month. Then use DATEADD to subtract one day and obtain the last day of the previous month. Use REPLACE to remove the separators.
```
SELECT REPLACE(DATEADD(date'${last_month}-01',-1,'dd'),'-','');
```
Example: last_month is 2025-07. After processing, the result is 20250630.

Get the current quarter

Calculate the quarter (1, 2, 3, or 4) from the month of the scheduled task.

Parameter configuration: Configure a scheduling parameter to obtain the month.
month=$[mm]
Processing logic: In ODPS SQL code, divide the month by 3 and round up to determine the quarter.
```
SELECT CEIL(CAST('${month}' AS INT)/3);
```
Example: month is 07. After processing, the result is 3.

Get each time component 15 minutes before the scheduled time

For data slicing at a precise time, you can obtain a time with an arbitrary offset from the scheduled time.

Parameter configuration: Use the arithmetic offset -15/24/60 in scheduling parameters to obtain the year, month, day, hour, and minute from 15 minutes earlier.
year=$[yyyy-15/24/60]
month=$[yyyymm-15/24/60]
day=$[yyyymmdd-15/24/60]
hour=$[hh24-15/24/60]
mi=$[mi-15/24/60]
Processing logic: Reference these calculated parameters directly in SQL.
```
select 'year=${year} month=${month} day=${day} hour=${hour} mi=${mi}';
```
Example: After the calculation crosses a day boundary, the result is year=2025 month=202507 day=20250726 hour=23 mi=50.

Scenario 2: Generate a time interval for incremental synchronization

Generate time parameters for an offline synchronization task that requires a specified interval. Assume that the time format is yyyymmddhh24miss, and the interval is open on the left and closed on the right.

Scheduling interval: One day

Get the interval from yesterday at 00:00:00 to today at 00:00:00 at the same time.

Parameter configuration: Obtain the dates for yesterday and today separately.
beginDateTime=$[yyyymmdd-1]
endDateTime=$[yyyymmdd]
Processing logic: Concatenate strings in the WHERE condition of the data filter to add the hour, minute, and second components.
```
event_time >= '${beginDateTime}000000' AND event_time < '${endDateTime}000000'
```
Example: The result starts at 20250726000000 and ends at 20250727000000.

Scheduling interval: One hour

Get the interval from the previous hour at 00:00 to the current hour at 00:00 at the same time.

Parameter configuration: Use arithmetic to obtain the previous hour and the current hour.
beginDateTime=$[yyyymmddhh24-1/24]
endDateTime=$[yyyymmddhh24]
Processing logic: Concatenate strings in the WHERE condition of the data filter to add the minute and second components.
```
event_time >= '${beginDateTime}0000' AND event_time < '${endDateTime}0000'
```
Example: The result starts at 20250726230000 and ends at 20250727000000.

Scenario 3: Preprocess parameters for downstream nodes with an assignment node

If the destination node, such as some offline synchronization nodes, cannot use functions to process scheduling parameters directly, preprocess them in an assignment node. For example, if an offline synchronization task needs a timestamp field for incremental synchronization, follow these steps:

Create an assignment node.
In the assignment node, use an engine function, such as unix_timestamp, to convert a standard scheduling parameter, such as $[yyyymmddhh24miss], to timestamp format.
Use the assignment node's output, the converted timestamp, as the input parameter of the downstream offline synchronization node. For information about input and output parameters, see: Configure node context.