Create a scheduling task

更新时间:
复制 MD 格式

After you publish an application, you can create scheduling tasks for it.

Procedure

  1. Log on to the Task Scheduling console.

  2. In the navigation pane on the left, click Task Configuration.

  3. Click Add Task > Simple Job and configure the following parameters:

    Parameter

    Description

    Task Name

    The name of the task. This name is used to identify the task.

    Application Name

    Enter or select the name of the target application.

    The name can contain English letters, digits, underscores (_), and hyphens (-). The name must be 50 characters or less. The name must match the value of `spring.application.name` in the `application.properties` file of the project.

    Scheduling Type

    The scheduling type of the task. Valid values:

    • Cron expression trigger: A CRON expression is required to trigger this type of task at a scheduled time.

    • Event trigger: This type of task is triggered by an external event.

    • One-time trigger: A CRON expression is required to trigger this type of task. The task runs only once.

    Cron expression

    The CRON expression used to trigger the task at a scheduled time. For more information, see CRON expressions.

    This parameter is required only when Scheduling Type is set to Cron expression trigger.

    Task Group (Optional)

    Select or create a task group to organize and manage tasks.

    Executor Name

    The name must be the same as the task processor name in your code. This is the executor name that is returned by the `getName` method in the implementation class.

    Enable Sharding

    Specifies whether to enable sharding for the task:

    • If you disable sharding, the task is scheduled to run on only one client server.

    • If you enable sharding and set the number of shards to N, the task is triggered to run concurrently on N client servers.

      If you enable sharding, you must also implement task sharding in your local project. For sample code, see the Task sharding sample code section below.

    Custom Parameters (Optional)

    Custom parameters that are passed from the console to the task. Parameters can also be passed between tasks. The format is `key=value`.

    The parameters are described as follows:

    • Parameter Name: The name of the custom parameter.

      The name can contain uppercase and lowercase English letters, digits, and underscores (_). The name cannot exceed 128 characters in length.

    • Type and Parameter Value: The available types and how to configure their values are described below.

      • STRING: A general-purpose string.

      • LIST: An array of strings, such as `["aaa","bbb"]`.

      • BOOLEAN: `true` or `false`.

      • PLACEHOLDER: A placeholder for parameter substitution. The following variables are supported:

        • ${sharding}: Replaced with the current shard value. This is used with simple jobs.

        • ${shardingCount}: Replaced with the number of shards configured for the simple job.

        • ${triggerTime}: Replaced with the expected trigger time.

    Note

    You can also get and overwrite custom parameters on the client using the context object. The object must implement Serializable. For sample code, see the Get and overwrite custom parameters sample code section below.

    Routing Policy

    The routing policy for task execution. Valid values:

    • Random: The task is randomly distributed to a client server for each execution.

    • Directed: The task is distributed to the same client server for each execution.

      Specifying a client server by IP address is not supported.

    • Polling: The task is distributed to each client server in turn for each execution.

    Communication Mode

    The communication mode of the task. Valid values:

    • ONEWAY: A one-way operation with no return value. The console does not record trigger history. Timeouts and retries are not supported.

      This mode is recommended for high-frequency, non-critical tasks.

    • CALLBACK: A bidirectional operation with a return value. You can view trigger history, set a timeout period, and configure retries in the console.

      This mode is recommended for critical tasks. The trigger interval must be at least 5 minutes.

    Task Mutual Exclusion

    Specifies whether to enable mutual exclusion mode for the task. If this mode is enabled, a task that is in the "Running" or "Paused" state cannot be triggered again, even if its next scheduled trigger time is reached. The status of the missed schedule is marked as "Skipped". By default, this mode is disabled.

    This parameter is available only when Communication Mode is set to CALLBACK.

    Missed Trigger Policy

    The policy to apply when a scheduled trigger is missed. Valid values:

    • Ignore: No compensatory action is taken.

    • Trigger Immediately: The task is triggered again immediately.

    • Trigger When Time is Sufficient: A compensatory trigger depends on whether there is enough time before the next scheduled trigger. If `Current Time + Timeout Period < Next Trigger Time`, a compensatory trigger occurs and is inserted into the trigger history. Otherwise, the task is not triggered. If multiple triggers are missed, only one compensatory trigger is performed during recovery.

    This parameter is available only when Communication Mode is set to CALLBACK and Scheduling Type is set to Cron expression trigger.

    Timeout Policy

    The policy to apply when a task execution times out. Valid values:

    • Do Nothing: The statuses of both the trigger record and the execution record are marked as "Failed".

    • Retry Based on Failure Policy: The status of the current schedule record is marked as "Failed", and a retry is attempted based on the Failure Policy. After the retry, the schedule record is reset to the retry result.

    • Stop Subsequent Triggers: The execution record status is "Failed", the trigger record status is "Timeout", and the task cannot be triggered again. This option is available only if task mutual exclusion mode is enabled.

    This parameter is available only when Communication Mode is set to CALLBACK.

    Timeout Period

    The timeout period for task execution. If the task does not send a callback within this period, the execution is considered failed. The unit can be minutes or hours.

    This parameter is available only when Communication Mode is set to CALLBACK.

    Failure Policy

    The policy to apply when a task execution fails. Valid values:

    • Do Not Retry: No retry is attempted after a failure.

    • Retry up to 3 Times: A retry is attempted immediately after a failure, up to a maximum of three times.

    • Retry Until Next Trigger: Retries are attempted immediately after a failure and continue until the next scheduled trigger time.

    Priority

    Indicates the importance of the task. This setting has no other effect.

    The default value is Medium.

    Description (Optional)

    The description of the task, such as its business purpose or scope of impact. The description can be up to 1024 characters in length.

    Task sharding sample code

    public class ShardingSchedule implements ISimpleJobHandler {
    
        private final Logger LOGGER = LoggerFactory.getLogger(ShardingSchedule.class);
    
        private ThreadPoolExecutor threadPool;
    
        @Override
        public String getName() {
            return "SHARDING_SCHEDULE";
        }
    
        @Override
        public ClientCommonResult handle(JobExecuteContext jobExecuteContext) throws Exception {
            int sharding = jobExecuteContext.getSharding();
    
            // The number of shards obtained by the current machine
            LOGGER.info("current machine sharding is " + sharding);
            // The total number of shards
            System.out.println("total sharding num is " + jobExecuteContext.getShardingCount());
    
            System.out.println("activity sharding is" + jobExecuteContext.getActivitySharding());
    
            return ClientCommonResult.buildSuccessResult();
        }
    
    @Override
        public ThreadPoolExecutor getThreadPool() {
            return threadPool;
        }
    
        /**
         * Setter method for property threadPool.
         *
         * @param threadPool value to be assigned to property threadPool
         */
        public void setThreadPool(ThreadPoolExecutor threadPool) {
            this.threadPool = threadPool;
        }
    
    }

    Retrieve and overwrite custom parameters sample code

    public class SimpleTaskDemo implements ISimpleJobHandler {
    
        @Override
        public ClientCommonResult handle(JobExecuteContext context) {
           // Get obj by key
            Object obj = context.getCustomParam("intObj");
    
            // Get custom parameters
            Map<String, Object> paramsMap = context.getCustomParams();
            context.putCustomParams("num", 2);
            List<String> listparam = newArrayList <>();
            listparam.add("aaaaaa");
            listparam.add("111111");
            context.putCustomParams("intparam", 111);
            context.putCustomParams("stringparam", "dfadsfad1243");
            context.putCustomParams("listparam", listparam);
            // Note: The object must implement Serializable.
            context.putCustomParams("objectParam", newObject());
            return ClientCommonResult.buildSuccessResult();
        }
    
    ....
    }
  4. Click Submit.

  5. In the task list, turn on the Enable switch for the target task.

    If a client is online, it is automatically registered for the new task. When a task is disabled, you can also click Trigger in the Actions column to manually trigger the task once.image.png