A scheduling method and system for docking execution method sequences

Abstract

This invention belongs to the field of software system integration, and particularly relates to a scheduling method and system for an integration execution sequence. This method is applied to the adaptation layer between a procurement system and a third-party system, and is executed by the execution scheduling module within it. It obtains the configuration parsing result defining the execution sequence, which includes step identifiers, functional modules, order, and configuration parameters; determines the current step to be executed based on the sequence and scheduling status, and loads its configuration parameters; initiates a call to the interface adaptation module or data conversion module based on the parameters to execute the operation; receives the execution result and records the status; and judges based on the result and exception rules. If an exception condition is met, the execution order of the remaining steps is adjusted according to the rules; otherwise, the next step to be executed is scheduled in sequence until the sequence is complete. This invention realizes the configurability and dynamic scheduling of the integration process, improving the system's flexibility and maintainability.

Description

Technical Field

[0001] This invention belongs to the field of software system integration, and particularly relates to a scheduling method and system for an integration execution method sequence. Background Technology

[0002] When university procurement systems interact with various third-party systems, a series of connection methods and steps are usually executed in a specific order, such as data reading, format conversion, request sending, response parsing, and result storage. These steps together constitute a complete sequence of connection execution methods. The effectiveness of the scheduling and control of this sequence directly affects the accuracy of data interaction and the smoothness of the process.

[0003] Currently, these types of integration execution method sequences are usually hard-coded into the core business modules of the procurement system, with scheduling logic highly coupled with specific business implementation. Due to differences in communication protocols, data formats, and execution logic among different third-party systems, the system often needs to write separate scheduling code for each integration scenario, resulting in scattered scheduling logic, repetitive development, and difficulty in unified management. Especially when it is necessary to support complex scheduling requirements such as asynchronous execution, pagination, exception retries, and conditional branches, the existing methods lack a flexible process orchestration mechanism and cannot dynamically adjust execution steps or monitor the status of each step in real time.

[0004] Furthermore, with the increasing number of interconnected systems and frequent changes in business rules, the interconnection sequence often needs to dynamically adjust the order of steps, add verification steps, or modify exception handling strategies. Hard-coded scheduling methods are difficult to adapt to these changes without modifying the code and redeploying, resulting in high system maintenance costs, slow response, and the potential for new errors to be introduced due to modifications. At the same time, due to the lack of a unified execution status tracking and logging mechanism, when multiple tasks are executed in parallel, the system has difficulty monitoring the execution progress, time consumption, and intermediate results of each step in real time, making fault location difficult and seriously affecting the overall reliability and maintainability of the system.

[0005] Specifically, existing technologies have the following prominent problems in scheduling execution method sequences: scheduling logic is usually tightly bound to specific business modules, and different business sequences cannot reuse the same scheduling mechanism; for complex execution processes that include asynchronous operations, pagination, and conditional judgments, there is a lack of unified orchestration and step control capabilities, making it difficult to dynamically adjust the execution order and triggering conditions through configuration; the system lacks a centralized state tracking and persistent recording mechanism, making it impossible to effectively monitor the execution progress and intermediate results of each step in a multi-task parallel environment, resulting in difficulty in quickly locating faults; in addition, exception handling strategies are scattered throughout the code, making it impossible to configure unified retry rules and failure handling logic according to task type or error category, resulting in insufficient fault tolerance and maintainability of the system.

[0006] Therefore, how to achieve flexible orchestration, monitorable execution, and controllable anomaly recovery for the execution sequences of various docking tasks through configuration has become a key issue in improving system scheduling reliability and reducing operational complexity. Summary of the Invention

[0007] To address the shortcomings of existing technologies, this invention proposes a scheduling method and system for interfacing execution sequence. This method is applied to the adaptation layer between a procurement system and a third-party system, and is executed by the execution scheduling module within it. It obtains the configuration parsing result defining the execution sequence, which includes step identifiers, functional modules, order, and configuration parameters; determines the current step to be executed based on the sequence and scheduling status, and loads its configuration parameters; initiates a call to the interface adaptation module or data conversion module based on the parameters to execute the operation; receives the execution result and records the status; and judges the result against exception rules. If an exception condition is met, the execution order of the remaining steps is adjusted according to the rules; otherwise, the next step to be executed is scheduled in sequence until the sequence is complete. This invention achieves configurability and dynamic scheduling of the interfacing process, improving the system's flexibility and maintainability.

[0008] To achieve the above objectives, the present invention provides the following technical solution:

[0009] A scheduling method for interfacing execution method sequences includes: an adaptation layer applied between a procurement system and a third-party system, the adaptation layer including an interface adaptation module, a data conversion module, and an execution scheduling module, wherein the method is executed by the execution scheduling module, and the steps include:

[0010] Obtain the configuration parsing result; the configuration parsing result defines the execution sequence of M docking tasks, and the execution sequence includes the identifiers of multiple steps, the functional modules called by each step, the execution order, and the configuration parameters of each step;

[0011] Based on the execution sequence and scheduling status, determine the current step to be executed and load the configuration parameters corresponding to the step to be executed. The configuration parameters include data source information, operation instructions and exception handling rules.

[0012] Based on the configuration parameters, a call is made to the interface adaptation module or the data conversion module to perform the data interaction or conversion operation of the current step;

[0013] Receive the execution result returned by the functional module and record the execution status of the step to be executed;

[0014] The execution result is compared with the preset conditions in the exception handling rules. If the exception conditions are met, the remaining unexecuted steps in the execution sequence and their execution order are adjusted according to the retry threshold or alternative step identifier defined in the exception handling rules. If the conditions are not met, the next step to be executed is determined according to the order or conditional branch of the execution sequence of the docking task and scheduling continues until all steps in the execution sequence are scheduled.

[0015] Specifically, determining the steps to be executed includes:

[0016] Obtain the current scheduling context; the current scheduling context is defined by a preset scheduling state data structure, which includes the current step index, the result set of executed steps, and the branch condition identifier and loop control parameters to be processed;

[0017] Based on the current step index, the unique identifier of the current step to be executed is queried and determined from the predefined execution sequence of docking tasks;

[0018] Based on the unique identifier of the current step to be executed, the corresponding step configuration raw data is retrieved from the configuration storage; the step configuration raw data includes the data source connection string, structured query language statement or application interface call template, and exception handling rules;

[0019] The original data configured in the above steps is parsed to identify the variable placeholders in the data source connection string and data operation instructions;

[0020] Replace the variable placeholders with the corresponding parameter values ​​obtained from the set of environment variables or the set of results of the executed steps to generate instantiated configuration parameters.

[0021] Specifically, determining the steps to be executed now also includes:

[0022] Perform compliance checks on the instantiated configuration parameters, and obtain the verified instantiated configuration parameters after the checks pass; the compliance checks include verifying the format of the data source connection information, verifying the syntax structure of the data operation instructions, and verifying the validity of the retry threshold in the exception handling rules;

[0023] Based on the branch condition identifier, determine whether a branch jump is needed; if a branch jump is needed, evaluate the condition expression corresponding to the branch condition identifier. The input parameters of the condition expression come from the result set of the executed steps. Based on the evaluation result, determine a new current step identifier to be executed from the execution sequence of the docking task.

[0024] Based on the loop control parameters, determine whether the system is in a loop execution state; if it is in a loop execution state, check whether the loop execution state meets the termination condition; if the termination condition is met, exit the loop execution state and update the current step index based on the execution sequence of the docking task; if the termination condition is not met, keep the current step identifier unchanged and update the loop control parameters.

[0025] When there is no branch jump and the execution is not in a loop or the loop continuation condition is met, the verified instantiated configuration parameters are loaded into the execution scheduling module.

[0026] The updated current step index, the branch condition identifier, and the loop control parameters are persistently saved.

[0027] Specifically, initiating a call to the interface adaptation module or the data conversion module includes:

[0028] S301. Based on the verified instantiated configuration parameters corresponding to the current step to be executed, obtain the operation type identifier and parameter mapping table;

[0029] S302. Based on the operation type identifier, obtain the corresponding executor instance from the pre-registered executor factory; the executor factory is used to provide the corresponding executor instance according to the operation type identifier; wherein, the executor factory internally pre-sets and maintains an executor registry, which is used to establish a mapping relationship between the operation type identifier string and the specific class implementing the unified executor interface; based on the operation type identifier, querying the executor registry can obtain and instantiate the corresponding specific class, and obtain an executor instance that can execute the corresponding operation matching the operation type identifier;

[0030] S303. Based on the parameter mapping table and the global execution context, construct a unified execution context object; the global execution context includes a set of environment variables and a set of results of executed steps.

[0031] Specifically, initiating a call to the interface adaptation module or the data conversion module further includes:

[0032] S304. Based on the obtained executor instance and the unified execution context object, initiate a call request and receive the execution result object;

[0033] S305. Based on the success status flag in the execution result object, determine whether the current step was successful. If the success status flag is true, proceed to S306; if the success status flag is false, proceed to S307.

[0034] S306. Process successful execution results, including:

[0035] Extract the main business data from the execution result object;

[0036] Associate the business data subject with the current step identifier to form a step output key-value pair;

[0037] Add the key-value pairs output by the step to the result set of the executed steps for reference in subsequent steps;

[0038] S307. Handling failed execution results, including:

[0039] Extract the result code string from the execution result object;

[0040] Record the current step identifier, result code string, and failure timestamp to the exception log;

[0041] Trigger the exception handling process; the exception handling process determines whether to retry or jump to the backup step based on the exception handling rules in the instantiation configuration parameters.

[0042] Specifically, the exception handling process determines whether to retry or jump to a backup step based on the exception handling rules in the instantiation configuration parameters, including:

[0043] S3071. Based on the instantiation configuration parameters, obtain exception handling rules; the exception handling rules include optional exception retry configuration and optional backup step configuration; the exception retry configuration includes a maximum retry threshold, and the backup step configuration includes a backup step identifier.

[0044] S3072. Based on the current step failure status record maintained by the execution scheduling module, obtain the current number of retries; the current step failure status record uses the current step identifier as the key to associate and store the number of times the step has been retried.

[0045] Specifically, the exception handling process, based on the exception handling rules in the instantiation configuration parameters, determines whether to retry or jump to a backup step, and also includes:

[0046] S3073. Based on the exception handling rules, the current number of retries, and the result code string extracted from the execution result object, determine the exception handling action to be executed; specifically including:

[0047] S3073a. Based on the result code string, query a predefined exception classification mapping table to determine the exception category corresponding to the current failure; the exception classification mapping table defines the mapping relationship between different result code strings and exception category strings, and the exception categories include retryable exceptions and non-retryable exceptions.

[0048] S3073b: Determine whether the exception category is a retryable exception and whether the exception handling rule defines an exception retry configuration; if both are yes, continue to execute S3073c; otherwise, decide to jump to the backup step.

[0049] S3073c: Obtain the maximum retry count threshold from the abnormal retry configuration, compare the current number of retries with the maximum retry count threshold, if the current number of retries is less than the maximum retry count threshold, then decide to perform a retry; otherwise, decide to jump to the backup step.

[0050] Specifically, the exception handling process, based on the exception handling rules in the instantiation configuration parameters, determines whether to retry or jump to a backup step, and also includes:

[0051] S3074. If the decision is to retry, then execute the retry processing logic, including:

[0052] S3074a. Based on the retry interval policy defined in the abnormal retry configuration, calculate the waiting time for this retry; the retry interval policy adopts the exponential backoff algorithm, the base interval time is read from the configuration, and the backoff index is the current number of retries plus one.

[0053] S3074b: Pause the current scheduling process and wait for the specified waiting time;

[0054] S3074c, Increment the number of retries associated with the current step identifier in the current step failure status record by one, and persist the update;

[0055] S3074d: Return the retry decision result, instructing the execution scheduling module to reschedule the step corresponding to the current step identifier.

[0056] Specifically, the exception handling process, based on the exception handling rules in the instantiation configuration parameters, determines whether to retry or jump to a backup step, and also includes:

[0057] S3075. If the decision is to jump to the alternative step, then execute the jump processing logic, including:

[0058] S3075a. Determine whether a backup step configuration is defined in the exception handling rule; if it is defined, obtain the backup step identifier from the backup step configuration; if it is not defined, obtain the default backup step identifier from the system global configuration.

[0059] S3075b: Based on the backup step identifier, query the corresponding step index from the predefined execution sequence of docking tasks;

[0060] S3075c: Update the current step index maintained by the execution scheduling module to the queried step index;

[0061] S3075d: Clear the number of retries associated with the current step identifier in the current step failure status record;

[0062] S3075e: Return the jump decision result, instructing the execution scheduling module to continue scheduling from the updated current step index;

[0063] S3076. Based on the retry decision result or jump decision result, update the scheduling status data of the execution scheduling module.

[0064] A scheduling system for interfacing with execution method sequences, comprising:

[0065] The acquisition module obtains the configuration parsing results; the configuration parsing results define the execution sequence of M docking tasks, and the execution sequence includes the identifiers of multiple steps, the functional modules called by each step, the execution order, and the configuration parameters of each step;

[0066] The loading module determines the current step to be executed based on the execution sequence and scheduling status, and loads the configuration parameters corresponding to the step to be executed. The configuration parameters include data source information, operation instructions and exception handling rules.

[0067] The execution module, based on the configuration parameters, initiates a call to the interface adaptation module or the data conversion module to perform the data interaction or conversion operation of the current step;

[0068] The feedback recording module receives the execution results returned by the functional module and records the execution status of the step to be executed;

[0069] The exception handling execution module judges the execution result against the preset conditions in the exception handling rules. If the exception conditions are met, the module adjusts the remaining unexecuted steps and their execution order in the execution sequence according to the retry threshold or alternative step identifier defined in the exception handling rules. If the conditions are not met, the module determines the next step to be executed according to the order or conditional branch of the execution sequence of the docking task and continues scheduling until all steps in the execution sequence are scheduled.

[0070] Compared with the prior art, the beneficial effects of the present invention are:

[0071] This invention addresses the shortcomings of existing technologies by defining reusable execution sequences containing steps, order, and parameters through configuration files. This decouples scheduling logic from core business logic, enabling unified and flexible orchestration of different interfacing tasks and improving the versatility and scalability of the scheduling mechanism. Secondly, the execution scheduling module performs sequential scheduling based on configuration and continuously records the status of each step, achieving centralized control and end-to-end visual monitoring of complex processes, significantly improving fault location and operational efficiency. Finally, by configuring preset exception handling rules, the system can automatically and uniformly respond to execution exceptions and dynamically adjust subsequent processes, significantly enhancing the system's fault tolerance, automation level, and overall maintainability, thereby reducing the development and operational complexity of system integration. Attached Figure Description

[0072] Figure 1 This is a flowchart of a scheduling method for a docking execution method sequence according to Embodiment 1 of the present invention;

[0073] Figure 2 This is a block diagram of a scheduling system for a docking execution method sequence according to Embodiment 2 of the present invention; Detailed Implementation

[0074] Example 1

[0075] Please see Figure 1 This invention provides an embodiment of a scheduling method for interfacing execution method sequences, applied to an adaptation layer between a procurement system and a third-party system. The adaptation layer includes an interface adaptation module, a data conversion module, and an execution scheduling module. The method is executed by the execution scheduling module, and the steps include:

[0076] S1. Obtain the configuration parsing result; the configuration parsing result defines the execution sequence of M docking tasks, and the execution sequence includes the identifiers of multiple steps, the functional modules called by each step, the execution order, and the configuration parameters of each step;

[0077] S2. Based on the execution sequence and scheduling status, determine the current step to be executed, and load the configuration parameters corresponding to the step to be executed. The configuration parameters include data source information, operation instructions, and exception handling rules.

[0078] S3. Based on the configuration parameters, initiate a call to the interface adaptation module or the data conversion module to perform the data interaction or conversion operation of the current step;

[0079] S4. Receive the execution result returned by the functional module and record the execution status of the step to be executed; it should be further noted that, in this embodiment, recording the execution status of the step to be executed specifically includes:

[0080] The status parameters associated with the step to be executed include: a unique identifier for the current step, an execution start timestamp, an execution end timestamp, and an execution result status enumeration value; wherein, the execution result status enumeration value includes success and failure; if the execution result status enumeration value is failure, the result code string and error description information extracted from the execution result object are additionally recorded; at the same time, the structured record containing all the above status parameters is written to the system status storage medium by calling the persistence service interface to form a queryable step execution history.

[0081] S5. Make a judgment based on the execution result and the preset conditions in the exception handling rules; if the exception conditions are met, adjust the remaining unexecuted steps in the execution sequence and their execution order according to the retry number threshold or alternative step identifier defined in the exception handling rules; if not met, determine the next step to be executed according to the order or conditional branch of the execution sequence of the docking task and continue scheduling until all steps in the execution sequence are scheduled.

[0082] It should be further explained that the exception handling rule in this embodiment is a composite strategy that includes multi-level judgment and dynamic routing. Its specific execution process is as follows: When a step fails, firstly, the result code string is extracted from the execution result and classified as a retryable exception or a non-retryable exception based on a predefined exception classification mapping table; then, a decision is made in conjunction with the exception handling rule obtained from the instantiated configuration parameters. That is, if the current failure belongs to the retryable category and the rule defines an exception retry configuration, then the current number of retries is further compared with the maximum retry threshold in the configuration: if it does not exceed... If the threshold is exceeded, the waiting time is calculated according to the configured retry interval strategy (such as the exponential backoff algorithm) and a retry is performed. At the same time, the number of retries is updated and persisted. If the threshold is exceeded, or the failure belongs to the non-retry category, or no retry configuration is defined in the rule, the decision is to execute a jump. That is, the alternative step identifier is obtained from the rule, or the system's global default alternative step identifier is used. The corresponding step index is queried and the current step index of the execution scheduling module is updated. The number of retries for the current step is cleared, thereby realizing the dynamic adjustment of the remaining unexecuted steps in the execution sequence and their execution order. For example, when synchronizing funding data between a university's procurement system and its financial system, assuming the "download funding details" step fails due to a network connection timeout, the execution scheduling module first extracts the result code string "NETWORK_TIMEOUT" from the returned execution result object and classifies it as a retryable exception based on a predefined exception classification mapping table (which maps "NETWORK_TIMEOUT" to "retryable exception" and "AUTH_FAILED" to "non-retryable exception"). Subsequently, it makes a decision based on the exception handling rules obtained from the instantiation configuration parameters of this step—the rules explicitly configure a maximum retry threshold of 3, an exponential backoff algorithm for the retry interval (basic interval of 1 second), and an alternative step identifier of "STEP_READ_LOCAL_CACHE". Since the current failure is a retryable exception and the rule defines an exception retry configuration, the execution scheduling module further reads the number of retries (1) from the current step failure status record and compares it with the maximum retry threshold of 3: 1 is less than 3, therefore the decision is to retry. According to the exponential backoff algorithm, the waiting time for this attempt is... After a 4-second pause, the scheduling process updates the retry count of the current step to 2 and persists it to the state storage. Then, the "Download Funding Details" step is rescheduled. If this step fails again and the cumulative retry count reaches 3 (equal to the threshold), or the failure is due to a non-retryable exception (such as authentication failure), or no retry configuration is defined in the rules, the decision is to jump to another step: The execution scheduling module first obtains the alternative step identifier "STEP_READ_LOCAL_CACHE" from the rules. If no alternative step is defined in the rules, the system's global default alternative step is used. Then, based on this identifier, the module queries the corresponding step index from the execution sequence of the docking task, updates the current step index maintained by the execution scheduling module to this index, and clears the retry count record of the current step. This allows for dynamic adjustment of the remaining unexecuted steps and their execution order, skipping failed remote download steps and instead executing alternative steps that read data from the local cache, ensuring the entire docking process can continue without interruption. Through this multi-layered exception handling mechanism, the system can automatically decide whether to retry the current step or jump to an alternative path based on the failure type, number of retries, and preset strategies, and ensure the recoverability of the decision with persistent state, thereby significantly improving the fault tolerance and reliability of the docking process.

[0083] It should be further explained that the interface adaptation module in this embodiment is used to define and provide a standardized unified calling interface to the procurement and bidding system, and at the same time to encapsulate the heterogeneous interfaces of third-party systems, so as to realize bidirectional format conversion of request and response data between the procurement and bidding system and third-party systems.

[0084] It should be further explained that the adaptation layer also includes a configuration parsing module. In this embodiment, the configuration parsing module is used to parse the configuration file defined in XML format, extract the docking parameters and support the modular import and dynamic parameter replacement of the configuration file, and output the parsing results to the execution scheduling module and the data conversion module.

[0085] It should be further explained that the data conversion module in this embodiment is used to perform data format conversion, field mapping and data cleaning operations between the procurement system and the third-party system according to the rules defined in the configuration file, and to adapt to data acquisition through configured SQL statements or API parameters;

[0086] It should be further explained that the execution scheduling module in this embodiment is used to schedule the interface adaptation module and the data conversion module to perform corresponding operations according to the execution sequence of the docking tasks defined in the configuration file, process asynchronous tasks, and record the execution status and exception retries.

[0087] In the context of university procurement systems interfacing with diverse third-party systems, the core challenge of existing hard-coded scheduling methods lies in their inability to provide a purely technical scheduling mechanism separated from specific business semantics. This leads to three progressively deeper technical obstacles: First, the scheduler lacks a standardized state machine model composed of step indexes, result sets, branch identifiers, and loop parameters. This prevents it from detaching itself from business concepts such as "fund synchronization" and "personnel download," relying solely on the objective execution progress of the process to accurately locate the currently pending step, thus hindering true decoupling and cross-scenario reuse of scheduling logic. Second, the loading process of configuration parameters is essentially a crucial step in transforming static rules into executable instructions. Existing methods cannot dynamically replace variable placeholders in the configuration based on runtime environment variables and upstream step results. Furthermore, they struggle to ensure accurate binding of highly structured parameter sets for different operation types, such as API calls and database operations, and to complete necessary type validation and compliance checks at this stage, making it easy for configuration errors to propagate to the execution phase. Finally, facing complex conditional judgments and pagination loops in actual integration, existing scheduling mechanisms lack a built-in, configurable, lightweight expression evaluation engine to drive branch jumps, and also lack persistent support for loop indexes and intermediate states. This results in the inability to reliably implement non-linear process orchestration and resume execution from accurate breakpoints after system interruption, severely restricting the automation and reliability of handling complex heterogeneous processes. Therefore, how to construct a state-driven scheduling core decoupled from business logic, a parameter loader supporting dynamic context binding, and a persistent process controller capable of managing branch loops constitute the specific technical challenges that need to be overcome to achieve flexible configurability. To this end, this embodiment provides the following specific process for determining the currently executed step:

[0088] S201. Obtain the current scheduling context; the current scheduling context is defined by a preset scheduling state data structure, including the current step index, the result set of executed steps, and the branch condition identifier and loop control parameters to be processed; for example, in the scenario of synchronizing funding information between a university procurement system and a third-party system, the scheduling context is specifically manifested as follows: the current step index points to the step identifier "batch download funding data from the financial system intermediate database"; the result set of executed steps includes the "verification passed" status returned by the previous step "initialization parameter verification"; the branch condition identifier to be processed is associated with the conditional expression "if the number of downloaded records is zero, jump to the end process" defined in the configuration; the loop control parameters record the page number index of the current page download and the loop termination condition of the total number of pages calculated based on the total number of records.

[0089] S202. Based on the current step index, query and determine the unique identifier of the current step to be executed from the predefined execution sequence of the docking task. For example, this embodiment is based on the docking scenario of synchronizing funding information between the university procurement system and the financial system. For example, the value of the current step index is 2, and the unique identifier of the corresponding step in the predefined execution sequence of the docking task is "funding batch download step". The configuration associated with this identifier points to the operation of reading data page by page from the intermediate database of the financial system. At the same time, the scheduling process needs to refer to the result set of the executed steps, such as the institution code and date range returned by step 1 "parameter initialization", and determine whether the condition of "skip if no data" is met based on the branch condition identifier to be processed. The loop control parameter records that the current execution has reached page 3 and the total number of pages is 10, which is used to control the continuation or termination of the pagination loop.

[0090] S203. Based on the unique identifier of the current step to be executed, obtain the corresponding step configuration raw data from the configuration storage; the step configuration raw data includes a data source connection string, a structured query language statement or an application interface call template, and exception handling rules; for example, in this embodiment, when the execution scheduling module obtains the step configuration raw data from the configuration storage based on the unique identifier of the current step to be executed, for example in the scenario of synchronizing the financial information of a university's financial system, the raw data specifically includes: the data source connection string is a JDBC connection information pointing to the university's Oracle financial middleware database, the structured query language statement is a SELECT statement for querying the details of project funding for a specified year, and the exception handling rule definition explicitly sets the number of retries to 3 and the interval between each retry when the network is interrupted or the query times out.

[0091] S204. Parse the raw data configured in the above steps, and identify variable placeholders in the data source connection string and data operation instructions. Specifically, this embodiment provides a method for identifying and extracting variable placeholders from configuration text, including:

[0092] S2041: Based on the configuration parsing process output, configure the original data and obtain the configuration text string to be parsed; the configuration text string comes from a specific field defined in the original data, including a data source connection string or a data operation instruction string.

[0093] S2042: Based on a predefined placeholder regular expression pattern, the regular expression engine is invoked to perform a global match on the configuration text string; the placeholder regular expression pattern is used to identify variable declaration structures that begin and end with a specific character sequence.

[0094] S2043: Based on each successful match of the regular expression engine, perform the following operations:

[0095] Extract the content of the captured group from the matching results and use it as a placeholder identifier string;

[0096] Obtain the starting character position index and ending character position index of the match in the configuration text string from the matching results;

[0097] The extracted placeholder identifier, start index, and end index are used to construct a triplet data unit.

[0098] S2044: Based on the set of triplet data units obtained after traversing all matches, construct and output an ordered list of placeholder information according to the order of appearance represented by the starting index value in each unit.

[0099] For example, in the "batch download of funds" step of the university procurement system and financial system integration in this embodiment, the text string to be parsed obtained from the configuration is:

[0100] "SELECT*FROM projects WHERE year = ${FISCAL_YEAR} AND dept_id=${DEPT_ID}"

[0101] The predefined placeholder regular expression pattern is \$\{([^}]+)\}, which is used to match structures of the form ${variable name}.

[0102] After the method is executed, the regular expression engine will successfully match two instances:

[0103] The first match is ${FISCAL_YEAR}. Extract the identifier "FISCAL_YEAR" and record the starting index 38 and ending index 52.

[0104] The second match is ${DEPT_ID}. Extract the identifier "DEPT_ID", record the starting index 68 and the ending index 79.

[0105] The final generated list of placeholder information is: [(“FISCAL_YEAR”,38,52),(“DEPT_ID”,68,79)]. This list records the core information of all placeholders in the text in an orderly manner, providing accurate input for subsequent dynamic parameter replacement.

[0106] S205. Replace the variable placeholders with the corresponding parameter values ​​obtained from the set of environment variables or the result set of the executed steps to generate instantiated configuration parameters.

[0107] It should be further noted that the corresponding parameter values ​​obtained from the set of environment variables or the set of results of the executed steps in this embodiment include:

[0108] S2051. Based on the step configuration of the original data containing variable placeholders, obtain the set of variable placeholders to be replaced;

[0109] S2052. Based on the preset environment variable storage area, obtain the environment variable set, which contains system-level operating parameters stored in key-value pairs; wherein the system-level operating parameters in this embodiment are the original data defined in S2052 and stored in the "preset environment variable storage area", which are "data ontologies" existing in key-value pairs, such as configuration parameters that the system depends on, such as {DB_HOST: 192.168.1.100, TIMEOUT: 3000}.

[0110] S2053. Based on the result set of executed steps maintained by the execution scheduling module, obtain the step output parameter set, wherein the step output parameter set contains business data returned by the executed steps and organized in key-value pairs.

[0111] S2054. Based on each variable placeholder in the variable placeholder set, perform the following replacement operations sequentially:

[0112] First, determine whether the identifier of the current variable placeholder exists in the key name list of the environment variable set;

[0113] If it exists, the running parameter value corresponding to the identifier is extracted from the set of environment variables, and the current variable placeholder in the original data of the step configuration is replaced by the running parameter value. The running parameter value is the specific value extracted from the "set of environment variables" according to the identifier (key name) of the variable placeholder. For example, for the placeholder ${DB_HOST}, the extracted 192.168.1.100 is the corresponding running parameter value.

[0114] If it does not exist, then further determine whether the identifier of the current variable placeholder exists in the key name list of the output parameter set of the step;

[0115] If it exists, extract the step output parameter value corresponding to the identifier from the set of step output parameters, and use the step output parameter value to replace the current variable placeholder in the original step configuration data;

[0116] If it does not exist, mark the variable placeholder as an unresolved identifier and retain it in the original step configuration data;

[0117] Furthermore, this embodiment proposes a method for parsing and replacing variable placeholders in configuration text based on priority order. This includes sequentially searching and replacing placeholders using a preset priority mapping table sequence to generate directly executable instantiated configuration text, and identifying unparsed variable identifiers. Specifically:

[0118] A1: Based on the original configuration text string containing variable placeholders, and the list of placeholder information extracted from the text, obtain the basic input data required for processing; each element in the list of placeholder information records the identifier of the placeholder and its start and end character position index in the original text.

[0119] A2: Based on a preset priority order definition, an ordered priority mapping table sequence is obtained; each mapping table in the sequence is a set of key-value pairs, and the priority is arranged from high to low; in a typical embodiment, the sequence includes an environment variable mapping table and a step result mapping table. For example, the ordered priority mapping table sequence in this embodiment is: [environment variable mapping table, step result mapping table]; wherein, the environment variable mapping table (high priority) is {"DB_HOST":"192.168.1.100", "TIMEOUT":"3000", "ENV_TYPE":"prod"}, and the step result mapping table (low priority) is {"USER_ID":"10086", "ORDER_NO":"P20260209001", "AMOUNT":"99.00"}. In this sequence, the environment variable mapping table has a higher priority than the step result mapping table, and key-value pairs in the environment variable mapping table will be matched first during parameter replacement.

[0120] A3: Based on the original configuration text string, initialize a variable string builder whose initial content is the original text.

[0121] A4: Based on the end index value of each element record in the placeholder information list, the list is traversed in reverse order from largest to smallest; this order is intended to ensure that the replacement operation does not change the position index of the placeholders that have not yet been processed in the text.

[0122] A5: Based on the currently traversed placeholder information element, perform the following parsing and replacement sub-steps:

[0123] Based on the placeholder identifier contained in the element, the key with the same name as the identifier is searched in each mapping table in the order of the priority mapping table sequence.

[0124] Based on the search results, if a corresponding key is found in a mapping table, the parameter value associated with that key is retrieved.

[0125] Based on the obtained parameter value and the start and end indices of the current placeholder, the characters in the corresponding index range in the string builder are replaced with the string representation of the parameter value, and the replacement is recorded as successful.

[0126] If the corresponding key is not found after traversing the entire priority mapping table sequence, the placeholder identifier is recorded in a list of unresolved identifiers, and the placeholder is preserved as is in the text.

[0127] A6: After completing the traversal of all placeholder information, obtain the instantiated configuration text based on the final content of the string builder.

[0128] A7: Output the instantiation configuration text and the list of unresolved identifiers.

[0129] S2055. After traversing the set of variable placeholders and performing the above replacement operation, an instantiated configuration parameter is generated. The instantiated configuration parameter is the step configuration data text after all resolvable variable placeholders have been replaced.

[0130] For example, in the scenario of synchronizing funding between a university's procurement system and financial system, the configuration parsing module obtains raw configuration data containing variable placeholders. For instance, the data source connection string is jdbc:mysql: / / ${DB_HOST}:3306 / finance, and the SQL statement is SELECT amount FROM budget WHERE year=${FISCAL_YEAR} AND dept=${DEPT_ID}; the environment variable set stores DB_HOST:'10.0.1.20', while the step output parameter set contains FISCAL_YEAR:'2024' and DEPT_ID:'A1003'. The replacement process proceeds sequentially: first, DB_HOST is replaced with 10.0.1.20, then FISCAL_YEAR and DEPT_ID are replaced with 2024 and A1003 respectively. After the replacement is complete, instantiated configuration parameters are generated: the data source connection string becomes jdbc:mysql: / / 10.0.1.20:3306 / finance, and the SQL statement becomes SELECT amount FROM budget WHERE year='2024'AND dept='A1003'. These instantiated parameters can be directly used for subsequent data query operations.

[0131] S206. Perform compliance verification on the instantiated configuration parameters, and obtain the verified instantiated configuration parameters after the verification is passed; the compliance verification includes verifying the format of the data source connection information, verifying the syntax structure of the data operation instructions, and verifying the validity of the retry number threshold in the exception handling rules;

[0132] It should be further noted that this embodiment performs compliance verification on the instantiated configuration parameters, including:

[0133] S2061. Verify whether the format of the data source connection information conforms to the predefined connection string pattern. If it does, mark it as valid. If it does not, generate a format error message.

[0134] S2062. Verify the syntax structure of the data operation instruction. If the data operation instruction is a Structured Query Language statement, check whether its syntax conforms to the syntax specification of the corresponding database. If the data operation instruction is an application programming interface (API) call template, check whether its request method, header definition, and request body structure conform to the interface convention. If the syntax check passes, mark it as valid. If it fails, generate a syntax error message.

[0135] It should be further explained that the method provided in this embodiment for verifying the syntactic compliance and security of Structured Query Language statements before execution includes: ensuring that data operation instructions are compatible with the target database environment and comply with security specifications by integrating lexical analysis, structural verification and placeholder checking.

[0136] Specifically, the method includes the following steps:

[0137] B1: Based on the instantiation configuration parameters, obtain the structured query language statement string to be verified and the associated database dialect identifier.

[0138] B2: Based on the dialect identifier in the database, obtain the corresponding pre-validation rule set from the predefined rule base; the rule set includes a keyword whitelist, a syntax template library, and a list of disabled modes.

[0139] B3: Based on the string of statements to be verified, perform lexical analysis and basic compliance checks, including:

[0140] The statement is split into a token sequence based on spaces and specific delimiters.

[0141] Based on the keyword whitelist, check whether the token sequence contains any unauthorized word units.

[0142] Based on the regular expressions in the list of prohibited patterns, the original statement string is scanned and matched to check whether it contains prohibited operation patterns.

[0143] Based on the above inspection results, if a violation is found, an error message containing a specific description of the violation will be generated, and subsequent verification will be suspended.

[0144] B4: Based on the aforementioned syntax template library, perform structural integrity checks on statements that pass basic compliance checks, including:

[0145] Based on the statement type (such as SELECT, INSERT, UPDATE), the corresponding legal clause structure and sequence template are obtained from the syntax template library.

[0146] Based on the template, verify whether the statement to be verified has the necessary clauses, and whether the clauses appear in a valid order.

[0147] B5: If the statement to be verified is identified as a precompiled statement containing dynamic parameter placeholders, then a placeholder consistency check is performed, including:

[0148] Based on the statement string, count the number of placeholders for specific parameters.

[0149] Get the number of parameters based on the parameter binding list defined in the configuration.

[0150] Compare whether the two quantities mentioned above are consistent.

[0151] B6: Based on the verification results of steps B3, B4, and B5, make a comprehensive judgment and output the final verification status and related information.

[0152] S2063. Verify the validity of the retry count threshold in the exception handling rule, and determine whether the retry count threshold is an integer greater than zero and does not exceed the preset maximum retry count. If so, mark the threshold as valid; otherwise, generate a threshold error message.

[0153] S2064. If the format validity, syntax validity, and threshold validity are all satisfied, then the compliance verification is determined to be passed, and the instantiation configuration parameter is marked as a verified instantiation configuration parameter.

[0154] For example, in the embodiment of data integration between a university's procurement system and financial system, when the instantiated configuration parameters include data source connection information jdbc:mysql: / / 192.168.1.100:3306 / finance, the system verifies that it conforms to the predefined JDBC connection string pattern and marks it as valid. For the Structured Query Language statement SELECT project_id, amount FROM budget WHERE fiscal_year=2023 in the data operation instructions, the system checks that its syntax conforms to the MySQL specification and marks it as valid. Simultaneously, for the retry threshold of 3 defined in the exception handling rules, the system determines that it is a positive integer and does not exceed the preset maximum value of 5, and marks it as valid. Since the format, syntax, and threshold are all satisfied, the system determines that the compliance check is passed and marks this set of configuration parameters as valid instantiated configuration parameters, allowing it to proceed to the subsequent execution stage. If any verification fails, such as an incorrect connection string format, an undefined table name in the SQL syntax, or a retry threshold set to -1, the system will generate a corresponding error message and block the process.

[0155] S207. Based on the branch condition identifier, determine whether a branch jump is required; if a branch jump is required, evaluate the condition expression corresponding to the branch condition identifier, wherein the input parameters of the condition expression come from the result set of the executed steps, and determine a new current step identifier to be executed from the execution sequence of the docking task based on the evaluation result.

[0156] It should be further explained that the identification of the new currently pending step in this embodiment includes:

[0157] Based on the branch condition identifier, obtain the corresponding condition expression text;

[0158] Based on the conditional expression text, obtain the set of input variable names contained therein;

[0159] Based on the set of input variable names, extract the corresponding input parameter values ​​from the result set of the executed steps;

[0160] Based on the obtained input parameter values, the Boolean expression evaluation engine is invoked to perform logical evaluation on the conditional expression text to obtain a Boolean result of true or false;

[0161] Based on a predefined conditional branch mapping table, obtain the path definition corresponding to the branch condition identifier;

[0162] Based on whether the Boolean result is true or false, the corresponding target path identifier is selected from the path definition;

[0163] Based on the target path identifier, query the entry step identifier of the path from the execution sequence of the docking task;

[0164] Update the entry step identifier obtained from the query to the new current step identifier to be executed.

[0165] For example, in the embodiment of the docking of departmental information synchronization between the university recruitment system and the personnel system, when the execution scheduling module determines that the branch condition identifier "CHECK_DATA_EXIST" is not empty, a branch jump is required. The conditional expression text corresponding to this identifier is "data_count>0". The module parses the set of input variable names from this expression, which includes "data_count". Subsequently, the module extracts the input parameter value "0" corresponding to the key "data_count" from the result set of the executed step "query the amount of data in the personnel system". The Boolean expression evaluation engine is called to evaluate the expression "0>0", and the obtained Boolean result is false. The predefined conditional branch mapping table indicates that the path corresponding to the branch condition identifier "CHECK_DATA_EXIST" is defined as follows: when the result is true, the target path identifier is "PATH_A"; when the result is false, the target path identifier is "PATH_B". According to the Boolean result being false, the module selects the target path identifier "PATH_B". According to the execution sequence query of the docking task, the entry step identifier of the path "PATH_B" is "STEP_SKIP_SYNC". Finally, the execution scheduling module updates "STEP_SKIP_SYNC" to the new identifier of the current step to be executed, thereby realizing the branch jump logic of skipping subsequent synchronization steps based on the data volume result.

[0166] It should be further explained that this embodiment also provides a method for dynamically determining the execution path based on conditional expressions in configurable process scheduling. This method involves parsing the conditional expressions, binding context variables for evaluation, and deciding on the next execution step based on predefined mapping relationships.

[0167] Specifically, it includes the following steps:

[0168] C1: Based on the branch condition identifier to be processed during the scheduling process, obtain the corresponding condition expression string.

[0169] C2: Based on the result set of the executed steps, construct a variable value binding context; the context is a key-value pair mapping, where the key is a variable name string and the value is a data object extracted from the step results that can be used for logical comparison.

[0170] C3: Based on the conditional expression string, call the expression parser to convert it into an abstract syntax tree; the nodes of the syntax tree include operand leaf nodes representing variables or constants, and intermediate nodes representing comparison operators or logical operators.

[0171] C4: Based on the variable value binding context, perform variable substitution and logical evaluation on the abstract syntax tree, including:

[0172] The syntax tree is traversed in depth-first order.

[0173] For each leaf node encountered, determine whether it is a variable name; if so, obtain the value corresponding to the variable name from the variable value binding context and replace the leaf node with the value.

[0174] After completing the subtree traversal, the evaluation is performed from bottom to top: for comparison operator nodes, the comparison result of the values ​​of their left and right child nodes is calculated; for logical operator nodes, the logical operation result of the Boolean values ​​of their left and right child nodes is calculated.

[0175] C5: Based on the final Boolean result obtained from the evaluation calculation and the predefined branch condition mapping relationship, determine the identifier of the next step to be executed; the mapping relationship defines the target step identifier to which the current branch condition should jump under different Boolean results.

[0176] For example, in this instance, when the university procurement system synchronizes departmental information with the human resources system, it needs to determine subsequent process branches based on business data. The conditional expression string defined in the configuration is "total data is greater than 100 and status is equal to 'active'". The system first obtains the variable value binding context from the results of the executed "data statistics" step, which includes "total data" being 150 and "status" being "active". The expression parser converts this string into an abstract syntax tree, with the root node being the logical operator "AND", the left subtree being the comparison operation "total data is greater than 100", and the right subtree being the comparison operation "status is equal to 'active'". Subsequently, the system performs a depth-first traversal of the syntax tree and replaces the variable values, replacing "total data" in the left subtree with 150 and "status" in the right subtree with 'active'. Then, it performs bottom-up evaluation: first, it calculates "150 is greater than 100" in the left subtree, which is true; then it calculates "'active' is equal to 'active'" in the right subtree, which is also true; finally, it calculates "true and true" in the root node, obtaining the final Boolean value as true. Based on this result, the system queries a predefined branch condition mapping table. This table defines a step identifier for this condition identifier, which, when the result is true, will redirect to "Step_Processing Large-Scale Active Data". Therefore, the system determines the next step to be executed as "Step_Processing Large-Scale Active Data", thus completing the decision-making process of dynamically selecting the execution path based on real-time business data.

[0177] S208. Based on the loop control parameters, determine whether the loop is in a loop execution state; if it is in a loop execution state, check whether the loop execution state meets the termination condition; if the termination condition is met, exit the loop execution state and update the current step index based on the execution sequence of the docking task; if the termination condition is not met, keep the current step identifier unchanged and update the loop control parameters.

[0178] It should be further explained that this embodiment checks whether the loop execution state meets the termination condition, including:

[0179] Based on the loop control parameters, obtain the loop execution status identifier;

[0180] Based on the loop control parameters, obtain the current iteration index and the loop termination condition;

[0181] Based on the current iteration index and the loop termination condition, determine whether the termination condition is met;

[0182] If the termination condition is met, the loop execution status flag is updated to invalid.

[0183] Based on the execution sequence of the docking task, obtain the index of the subsequent steps corresponding to the current loop body;

[0184] Update the current step index to the obtained subsequent step index;

[0185] If the termination condition is not met, the identifier of the current step to be executed remains unchanged;

[0186] Based on the current iteration index, a new iteration index is calculated by incrementing the value of the current iteration index by one.

[0187] Update the current iteration index in the loop control parameters to the new iteration index;

[0188] Based on the updated loop control parameters, execute the current step;

[0189] After executing the current step, the loop control parameters, which include the loop execution status identifier and the updated current iteration index, are persistently stored.

[0190] For example, in the embodiment of synchronizing paginated data between a university procurement system and a financial system, the loop control parameters include: a loop execution status identifier of "in progress", a current iteration index of "3", and a loop termination condition of "total number of pages 5". Based on the current iteration index "3" and the loop termination condition "5", the system determines that "3 is less than 5" is true, and the termination condition is not met. Therefore, the system keeps the current step identifier "pagination query step" unchanged and updates the current iteration index to "4". Based on the updated loop control parameters, the system executes the current pagination query step. After execution, the system persistently stores the loop control parameters containing the "in progress" status identifier and the current iteration index "4" in the database. If the current iteration index is "5" and the termination condition is "5", the system determines that "5 is less than 5" is false, and the termination condition is met. Then, the loop execution status identifier is updated to "completed", and the current step index is updated to the "result processing step" index after the loop body according to the execution sequence of the docking task, thereby exiting the loop execution state.

[0191] It should be further noted that this embodiment also provides a persistence method for controlling loop execution, managing iteration state, and implementing breakpoint resumption in configurable process scheduling. This includes: ensuring that tasks containing loop structures can be executed reliably and recoverably through precise management of the loop context, atomic updates of the iteration state, and real-time snapshot saving of the global scheduling state. Specifically, the persistence method includes the following steps:

[0192] D1: Based on the loop control parameters maintained by the execution scheduling module, obtain the current loop context; the context is a structured data object containing a unique loop identifier string, an integer value of the current iteration count, a loop termination condition value, and a step identifier string to be repeatedly executed within the loop body.

[0193] D2: Based on the current iteration count and the loop termination condition value in the current loop context, perform a termination condition judgment; if the current iteration count is greater than or equal to the loop termination condition value, determine that the loop should terminate and generate a loop action instruction to exit the loop; otherwise, determine that the loop should continue and generate a loop action instruction to continue the loop.

[0194] D3: Update the global scheduling state based on the loop action instruction:

[0195] If the instruction is to continue the loop, the integer value of the current iteration count in the current loop context is incremented by one, and the step identifier string in the loop body is kept as the identifier of the next step to be executed. The updated loop context is then written back to the global scheduling state.

[0196] If the instruction is to exit the loop, the current step index in the global scheduling state is updated to the predefined index of the subsequent step after the loop body, and the current loop context is marked as completed.

[0197] D4: Generate a state snapshot based on the updated global scheduling state; this process includes serializing the global scheduling state into a standard format string and generating a unique state snapshot storage key based on the scheduling task identifier, the loop unique identifier, and the current iteration number.

[0198] D5: Based on the generated state snapshot string and its corresponding storage key, call the persistence service interface to save the snapshot to the external storage system to achieve the persistence of the scheduling state.

[0199] S209. When there is no branch jump and the execution is not in a loop or the loop continuation condition is met, the verified instantiated configuration parameters are loaded into the execution scheduling module.

[0200] S210. Persistently save the updated current step index, the branch condition identifier, and the loop control parameters.

[0201] For example, in this embodiment of synchronizing paginated data between a university's procurement system and its financial system, it is assumed that the current step is "downloading page N of the expense details," and the instantiated configuration parameters have passed compliance verification. At this time, the branch condition identifier is empty, indicating that no branch jump is involved; the loop control parameters show the loop execution status as "in progress," the current page number is 2, and the total number of pages is 5, thus satisfying the loop continuation condition of "the current page number is less than the total number of pages." When both of the above conditions are met, the execution scheduling module loads the verified instantiated configuration parameters (e.g., containing the connection string and the page 2 query statement) into its memory workspace, ready for execution. Simultaneously, the module serializes the updated current step index (still pointing to "downloading page N of the expense details"), the empty branch condition identifier, and the updated loop control parameters (where the current page number increments to 3), and persistently saves them to the system state database, thereby ensuring the recoverability and consistency of the scheduling state.

[0202] This method first defines a standardized scheduling context that includes step indexes, result sets, branch identifiers, and loop parameters, eliminating reliance on specific business concepts such as "fund synchronization" and "personnel download." When determining the step to be executed, the system matches a unique identifier from the predefined execution sequence of the docking tasks based solely on the step index, rather than binding business logic through hard coding. Simultaneously, the result sets, branch condition identifiers, loop parameters, and other status information of the executed steps are stored and transmitted in a structured, business-independent format. This design allows the scheduler to locate the step to be executed solely based on the process execution progress, rather than relying on business semantic judgments, completely breaking down the barrier between scheduling logic and specific business scenarios under hard coding. For example, in the fund synchronization scenario, step index "2" only points to the standardized identifier "batch fund download step," rather than directly encoding the business logic of "downloading fund data from the financial system." When switching to the personnel system department information synchronization scenario, only the configuration of the docking task's execution sequence needs to be replaced; the core scheduling logic remains unchanged, achieving cross-scenario reuse of scheduling capabilities.

[0203] To address the issue of statically loading configuration parameters in hard-coded configurations and their inability to adapt to the runtime environment, this method designs a full-chain dynamic parameter processing mechanism: First, it accurately identifies variable placeholders in the configuration text using regular expressions, extracts core information such as placeholder identifiers and start / end indices, and generates an ordered list; then, following a priority order of "environment variables first, step results second," it retrieves parameter values ​​from the runtime environment variable set or the result set of executed steps, and performs dynamic replacement by traversing the placeholder list in reverse, avoiding changes to the position index of unprocessed placeholders during the replacement operation; finally, it performs multi-dimensional compliance checks on the instantiated configuration parameters, including data source connection string format verification, SQL statement / API template syntax and security verification, and validity verification of the number of retries in exception handling rules. This series of technical measures intercepts configuration errors before execution: precise matching of regular expressions ensures that no placeholders are missed, the priority replacement mechanism adapts to the dynamic parameter requirements from different sources, and multi-dimensional compliance checks cover the full-dimensional correctness of the configuration from format to syntax to business rules. For example, in the scenario of fund synchronization, ${DB_HOST} is replaced from an environment variable to a specific IP address, and ${FISCAL_YEAR} is replaced from a step result to 2024. The replaced SQL statement is verified to ensure it conforms to MySQL syntax specifications, thus avoiding environment compatibility issues caused by hard-coded parameters and system anomalies caused by configuration errors spreading to the execution stage.

[0204] To address the issues of unreliable handling of branching and looping by hard-coding, and the difficulty of breakpoint recovery after interruption, this method constructs a built-in lightweight expression evaluation engine and a loop state persistence system: In the branching jump stage, the system extracts conditional expressions based on branch condition identifiers, binds variable contexts from the result set of executed steps, converts the expressions into abstract syntax trees, performs depth-first traversal evaluation, and then determines the target step identifier based on a predefined branch mapping table, realizing dynamic path decision-making based on real-time business data; In the loop control stage, the system maintains loop control parameters including loop identifier, current iteration index, and termination condition, and judges the loop termination state in real time. If the termination condition is not met, the current step identifier is maintained and the iteration index is updated; if the condition is met, the system jumps to the subsequent steps of the loop. After each loop state update, the global scheduling state is serialized into a snapshot, and a unique storage key is generated by combining the task identifier, loop identifier, and iteration count, and persisted to an external storage system. These technical methods solve the problems of fixed branching and looping logic and lack of state persistence in hard-coded code: the expression evaluation engine is freed from the fixed branching logic of hard-coded code and supports arbitrary configurable Boolean expression decisions; atomic updates and snapshot persistence of loop states ensure that execution can resume from the exact breakpoint after a system interruption, rather than retrying from the beginning. For example, when downloading funding data in pages, the loop parameters record the current page number 3 and the total number of pages 10. After the system determines that the termination condition is not met, it updates the page number to 4 and persists the state. Even if the system is interrupted, it can directly continue downloading from page 4 after restarting, instead of re-downloading the first 3 pages; in the data synchronization scenario of the personnel system, when the expression "data_count>0" evaluates to false, the system automatically jumps to the step of skipping synchronization, adapting to the business rule of "terminating if there is no data" without modifying the code.

[0205] In this embodiment of the configurable scheduling method, the core challenge when the execution scheduling module needs to call a specific functional module lies in building a truly universal call executor. This executor must thoroughly solve three interrelated problems: First, it needs to dynamically locate and call the correct module at runtime based on a simple configuration identifier, rather than relying on hard-coded selection logic, thereby achieving complete decoupling between the scheduling core and the specific module implementation. Second, it must design a unified calling contract that can automatically and accurately adapt the general parameter context provided by the scheduler to the heterogeneous input parameters required by different modules (such as network interface adapters and data converters). Finally, it also needs to encapsulate the complex execution processes and differentiated results of each module, transforming them into unified success / failure states and standardized output data for consistent subsequent process control by the scheduler. If these problems cannot be solved holistically, the scheduling layer will inevitably recouple from the execution layer, rendering all previous decoupling designs and configurability efforts ineffective.

[0206] It should be further noted that, in this embodiment, the invocation to the interface adaptation module or the data conversion module includes:

[0207] S301. Based on the verified instantiation configuration parameters corresponding to the current step to be executed, obtain the operation type identifier and parameter mapping table; however, in this embodiment, the operation type identifier obtained from the instantiation configuration parameters may be empty or not exist in the registry; the parameter mapping table may have a complex structure, containing nested objects or empty values, and direct use may lead to errors in subsequent steps; therefore, in this embodiment, when obtaining the operation type identifier and parameter mapping table, the following steps are performed:

[0208] S3011. Based on the verified instantiation configuration parameters, obtain the original operation type identifier string and the original parameter mapping table.

[0209] S3012. Based on the original operation type identifier string, perform identifier validity verification and default value injection, and output a valid operation type identifier string; specifically including:

[0210] Determine whether the original operation type identifier string is an empty string or consists only of whitespace characters.

[0211] If the judgment result is yes, then retrieve the default operation type identifier string associated with the current docking task type from the predefined global default configuration, and output the default operation type identifier string as a valid operation type identifier string.

[0212] If the judgment result is negative, the original operation type identifier string will be directly output as a valid operation type identifier string.

[0213] S3013. Based on the original parameter mapping table, the predefined list of required parameter key names, and the global execution context, perform parameter null value checking and default value injection, and output the parameter mapping table after injection; specifically including:

[0214] Create an empty parameter mapping table for the injected data.

[0215] Iterate through each key-value pair in the original parameter mapping table, and perform the following operations for the currently iterated key-value pair:

[0216] (1) Get the current key name and the current parameter value.

[0217] (2) Determine whether the current parameter value is empty.

[0218] (3) If the current parameter value is not empty, the current key name and the current parameter value are directly stored in the parameter mapping table after the injection is completed.

[0219] (4) If the current parameter value is empty, perform necessary parameter validation and default value parsing:

[0220] (a) Based on the list of required parameter key names, determine whether the current key name is a required parameter.

[0221] (b) If the current key name is not a required parameter, then store the current key name and a specific placeholder value indicating that the parameter is empty in the parameter mapping table after the injection is completed.

[0222] (c) If the current key name is a required parameter, then based on the current key name, query the global execution context to see if there is a corresponding default parameter value.

[0223] (d) If the query is successful, the default parameter value obtained is used as the current parameter value, and the current key name and the default parameter value are stored in the parameter mapping table after the injection is completed.

[0224] (e) If the query fails, a parameter missing exception is generated and thrown, which contains the current key name.

[0225] S3014. Output the parsing and injection results, which include the valid operation type identifier string and the parameter mapping table of the completed injection.

[0226] S302. Based on the operation type identifier, obtain the corresponding executor instance from the pre-registered executor factory; the executor factory is used to provide the corresponding executor instance according to the operation type identifier; wherein, the executor factory internally pre-sets and maintains an executor registry, the executor registry is used to establish the mapping relationship between the operation type identifier string and the specific class implementing the unified executor interface; based on the operation type identifier, querying the executor registry can obtain and instantiate the corresponding specific class, and obtain an executor instance that can execute the corresponding operation matching the operation type identifier;

[0227] However, in this embodiment, the executor factory may not be able to find the implementation class corresponding to a given identifier, or the instantiation process may fail due to class path, dependency, or other issues; at the same time, frequent creation and destruction of executor instances may affect performance; therefore, this embodiment provides a secure method for obtaining and caching executors, specifically including:

[0228] S3021. Based on the external call request, receive the operation type identifier string to be processed.

[0229] S3022. Based on the operation type identifier string to be processed, query the instantiated executor cache mapping to obtain the first query result; the instantiated executor cache mapping is a key-value pair storage structure, where the key is the operation type identifier string and the value is the created executor instance object.

[0230] S3023. Based on the first query result, determine whether there is a cached executor instance; specifically including:

[0231] If the first query result returns a non-empty executor instance object, it is determined to be a cache hit, the executor instance object is directly output as the final result, and subsequent steps are terminated.

[0232] If the first query result returns an empty value, it is determined that the cache was not hit, and S3024 continues to be executed.

[0233] S3024. Based on the operation type identifier string to be processed, query the executor registry to obtain a second query result; the executor registry is a persistent key-value pair storage structure, where the key is the operation type identifier string and the value is the fully qualified name string of the corresponding executor implementation class.

[0234] S3025. Based on the second query result, determine whether the operation type identifier to be processed has been registered; specifically including:

[0235] If the second query result returns an empty value, it is determined that it is not registered, and an unknown operation type exception is generated and thrown. The exception information contains the operation type identifier string to be processed.

[0236] If the second query result returns a non-empty fully qualified name string, it is determined that it has been registered, and execution continues to S3026.

[0237] S3026. Based on the fully qualified name string, attempt to instantiate the executor object using reflection and obtain the instantiation result; specifically including:

[0238] S30261. Use the class loader to load the corresponding class definition based on the fully qualified name string.

[0239] S30262. Call the parameterless constructor defined in the class to create a new instance of the class.

[0240] S30263. Force the newly created instance to a uniform executor interface type.

[0241] S30264. If any step from S30261 to S30263 throws an exception, it is determined that the instantiation failed. The exception is captured, and an executor initialization exception is generated and thrown. The exception information includes the operation type identifier string to be processed and the detailed information of the captured original exception.

[0242] S3027. Based on the successfully instantiated executor instance object, update the instantiated executor cache mapping and output the instance; specifically including:

[0243] Using the operation type identifier string to be processed as the key and the successfully instantiated executor instance object as the value, store or update it in the instantiated executor cache mapping.

[0244] The successfully instantiated executor instance object is output as the final result.

[0245] S303. Based on the parameter mapping table and the global execution context, construct a unified execution context object. The global execution context includes a set of environment variables and a set of results from executed steps; the unified execution context object is a container used to aggregate all input data required for the current step invocation.

[0246] In this step, simply merging the parameter mapping table with the global context can easily lead to key name conflicts. Furthermore, because a deep copy operation is not performed on the data, subsequent modifications to the merged context will contaminate the original global context data. Therefore, this embodiment proposes a hierarchical construction and data cloning method for the context, specifically including:

[0247] S3031. Based on the input parameter mapping table and the global execution context, initialize a blank unified execution context object; the unified execution context object is a mutable key-value pair storage container.

[0248] S3032. Based on the global execution context, perform the first round of key-value pair merging; specifically including:

[0249] Iterate through each key-value pair in the global execution context, and perform the following operation on the first key-value pair encountered:

[0250] (1) Get the current first key name and the current first value object.

[0251] (2) Perform a deep copy operation on the current first value object to generate a first value copy; the deep copy operation is implemented through object serialization and deserialization mechanism, or through a customized copy method for a specific complex object type, so as to ensure that a new object with the same data content as the original object but independent in memory is generated.

[0252] (3) Store the current first key name and the first value copy as a new key-value pair in the unified execution context object.

[0253] S3033. Based on the parameter mapping table, perform a second round of key-value pair merging and handle key name conflicts; specifically including:

[0254] Iterate through each key-value pair in the parameter mapping table, and perform the following operation for the second key-value pair currently encountered:

[0255] (1) Get the current second key name and the current second value object.

[0256] (2) Perform a deep copy operation on the current second value object to generate a second value copy; the implementation of the deep copy operation is the same as S3032.

[0257] (3) Determine whether the current second key name already exists in the unified execution context object.

[0258] (4) If it already exists, the second value copy is used to overwrite the existing value associated with the current second key name in the unified execution context object.

[0259] (5) If it does not exist, the current second key name and the copy of the second value are stored as a new key-value pair in the unified execution context object.

[0260] S3034. Output the completed unified execution context object.

[0261] S304. Based on the obtained executor instance and the unified execution context object, initiate a call request and receive the execution result object; this process further includes:

[0262] S3041. Pass the unified execution context object to the execution method of the executor instance.

[0263] S3042. The executor instance internally calls its bound dedicated parameter parser; the dedicated parameter parser extracts and converts the specific parameter object required by the executor instance from the unified execution context object according to the type of the executor instance.

[0264] S3043. The executor instance uses the transformed specific parameter object to execute the encapsulated data interaction or transformation logic.

[0265] S3044. The executor instance encapsulates the native execution output into a standardized execution result object and returns it; the execution result object is a structured data entity that must contain a success status flag, a result code string, a business data body, and an optional auxiliary information mapping table.

[0266] S305. Based on the success status flag in the execution result object, determine whether the current step was successful. If the success status flag is true, proceed to S306; if the success status flag is false, proceed to S307.

[0267] In the S304 and S305 processes of this embodiment, there may be problems such as parser execution failure or incompatible parameters, and the inability to monitor the execution time and resource usage of the executor. Furthermore, the execution may freeze due to timeout or resource exhaustion. Therefore, this embodiment provides the following two stages, specifically:

[0268] Phase 1: Parameter Security Analysis and Verification

[0269] S3051. Obtain a dedicated parameter resolver bound to its type based on a pre-defined reference within the executor instance.

[0270] S3052. Based on the unified execution context object, call the parsing method of the dedicated parameter parser and capture the parsing process output; specifically including:

[0271] S3052a, Invoke the anomaly analysis algorithm constructed by the random forest, and pass the unified execution context object as the input parameter.

[0272] S3052b: Capture any exceptions thrown during the call.

[0273] S3052c. If an exception is captured, a first failed execution result object is created with the flag indicating failure. In this object, the success status flag is set to false, the result code string is set to "parameter parsing failed", the business data body is set to empty, and the captured exception details are recorded in the auxiliary information mapping table. The first failed execution result object is output, and this stage and subsequent execution are terminated.

[0274] S3052d: If no exception is caught, the specific parameter object returned by the parsing method is received as the output of the parsing process.

[0275] S3053. Based on the specific parameter object of the parsed output, perform a parameter validity assertion check; specifically including:

[0276] S3053a, Obtain the set of predefined parameter validation rules associated with the current actuator type.

[0277] S3053b. According to the set of verification rules, perform assertion checks on specified fields in the specific parameter object; the checks include non-empty checks, numerical range checks, and string format checks.

[0278] S3053c: If any assertion check fails, a second failed execution result object is created with the flag indicating failure. In this object, the success status flag is set to false, the result code string is set to "invalid parameter", the business data body is set to empty, and the failed check item information is recorded in the auxiliary information mapping table. The second failed execution result object is output, and this stage and subsequent execution are terminated.

[0279] S3053d. If all assertion checks pass, the specific parameter object is output as a parameter that has passed the verification, and the process proceeds to the second stage.

[0280] Phase Two: Execution of Business Logic with Timeout and Monitoring

[0281] S305B1. Based on the parameters that have passed the verification, initiate the execution monitoring and package the core business logic; specifically including:

[0282] S305B1a: Obtain the current system timestamp and record it as the execution start timestamp.

[0283] S305B1b: Create a callable task object containing the parameters that have passed the verification; this task object encapsulates the core business logic of the executor instance, and its call method returns the native business output.

[0284] S305B1c, Obtain Timeout Threshold: First, attempt to read the timeout in milliseconds from the timeout configuration item defined in the instantiation configuration parameters; if not defined, use the system-predefined default timeout threshold.

[0285] S305B1d: Submit the callable task object to a pre-initialized thread pool execution framework with a timeout control mechanism.

[0286] S305B2. Based on the timeout threshold, execute the task and wait for the result; specifically including:

[0287] S305B2a: Instruct the thread pool execution framework to execute the task and set the waiting time to the timeout threshold.

[0288] S305B2b: Wait for the task to complete within the timeout threshold.

[0289] S305B2c: If the task is completed normally within the timeout threshold, its returned native business output is obtained as the task success output.

[0290] S305B2d. If the task execution time exceeds the timeout threshold, the thread pool execution framework actively interrupts the task thread and generates a timeout exception; at this time, it is determined that the task execution has timed out.

[0291] S305B3. Based on the task execution results, generate standardized execution result objects; specifically including:

[0292] S305B3a: Obtain the current system timestamp and record it as the execution end timestamp; calculate the execution time, which is the difference between the execution end timestamp and the execution start timestamp.

[0293] S305B3b: If the task is successfully completed, an execution result object marked as successful is created; in this object, the success status flag is set to true, the result code string is set to "success", the business data subject is set to the original business output, and the execution time is recorded in the auxiliary information mapping table as the calculated difference.

[0294] S305B3c: If the task execution times out, a third failed execution result object is created with the flag indicating failure. In this object, the success status flag is set to false, the result code string is set to "execution timeout", the business data body is set to empty, and the execution time is recorded in the auxiliary information mapping table as the calculated difference and the timeout threshold.

[0295] S305B3d If the task is completed within the timeout threshold but throws a business exception (not a timeout exception), a fourth failed execution result object marked as failed is created. In this object, the success status flag is set to false, the result code string is set to "business execution exception", the business data body is set to empty, and the execution time is recorded in the attached information mapping table as the difference calculated above and the detailed information of the captured business exception.

[0296] S305B4. Output the final generated execution result object.

[0297] S306. Process successful execution results, including:

[0298] Extract the main business data from the execution result object.

[0299] The business data subject is associated with the current step identifier to form a step output key-value pair.

[0300] The key-value pairs output by the steps are added to the result set of the executed steps for reference in subsequent steps.

[0301] S307. Handling failed execution results, including:

[0302] Extract the result code string from the execution result object.

[0303] Record the current step identifier, result code string, and failure timestamp to the exception log.

[0304] Trigger the exception handling process; the exception handling process determines whether to retry or jump to the backup step based on the exception handling rules in the instantiation configuration parameters.

[0305] For example, in the task of synchronizing the current year's project funding details from the financial system to the university procurement system, when the system executes the "funding data download" step, it first finds that the operation type identifier is empty in the configuration, so it automatically selects the default "SQL_QUERY" identifier from the global configuration. At the same time, the port parameter of the target database in the configuration is empty. After determining that it is a required parameter, the system successfully finds and injects the default port "3306" from the global context. The system then finds no existing instance in the internal cache based on the "SQL_QUERY" identifier, so it queries the registry and dynamically creates a database query executor instance through reflection and caches it. Next, the system merges the runtime parameters containing the year "2024" and the department number "A1003" into a unified execution context through deep copying, avoiding data pollution. After the executor safely parses the parameters and verifies the SQL syntax, it packages the query logic into a task with a 5-second timeout monitoring and submits it for execution. After successfully retrieving the data, it encapsulates it into a standard object containing a "success" status and a result set and returns it. The scheduler records the success status and stores the result set in the history. If a network interruption occurs at this time, causing the query to fail, the system will record the error code "NET WORK_ERROR". According to the rules, it will be identified as a retryable exception. If the maximum of 3 retries is not exceeded, the system will wait for 2 seconds and then automatically re-execute the step. In this way, the entire process from intelligent parameter completion, dynamic component loading, safe execution and automatic exception recovery is completed without human intervention.

[0306] This generic call executor construction method addresses core issues such as coupling between the scheduling core and execution layer, difficulties in adapting heterogeneous parameters, and inconsistent execution results through a series of technical means including identifier validation and injection, executor cache reflection instantiation, hierarchical context construction, and phased secure execution and monitoring. It achieves generic, secure, and efficient executor calls, ensuring the implementation of the decoupled design of configuration-based scheduling. In particular, by validating and injecting default values ​​for operation type identifiers, performing necessary parameter null checks on the parameter mapping table, and completing global context default values, it directly solves the call failure problem caused by missing identifiers, null or missing parameters, laying a solid foundation for subsequent executor matching and parameter passing. The executor factory instantiates executors by first checking the cache and then the registry, combined with reflection. This avoids hard-coded module binding, achieving complete decoupling between scheduling and execution. It also solves the performance loss from frequent creation and destruction by caching and reusing instances, and improves call reliability by accurately locating issues such as unregistered instances and instantiation failures through exception throwing. A hierarchical context construction based on deep copy first merges the global execution context and then overwrites the parameter mapping table. This solves the key name conflict problem and avoids subsequent modifications from polluting the original context through deep copying. It achieves precise adaptation of heterogeneous input parameters to a unified execution context, meeting the parameter requirements of different modules. Phased parameter security parsing and verification, along with business execution with timeout monitoring, first uses a dedicated parser to parse and verify parameters according to rules, intercepting parameter parsing failures and invalid parameters. Then, a thread pool implements timeout control, combined with execution timestamp recording to complete time consumption monitoring and exception capture. This solves problems such as parameter incompatibility, execution freezes, and unmonitored resources. Simultaneously, all execution results are encapsulated into standardized objects containing state, code, and data, allowing the scheduler to perform consistent subsequent process control. Finally, logging of failure results and exception rule triggering enable traceability and automated exception handling after execution failure, preventing single-step failures from causing overall process interruption and ensuring the stable progress of the configurable scheduling process.

[0307] In the decision-making stage of the exception handling process, the existing rule mechanism based on simple static configuration has significant limitations. The core problem is that the rule configuration itself is fixed and singular, unable to dynamically perceive and understand the specific differences in failure scenarios. For example, it cannot distinguish between different error types such as momentary network interruption and permanent failure of a third-party system, potentially leading to invalid retries or erroneous jumps. Furthermore, when multiple rule conditions are triggered simultaneously, the system lacks a clear mechanism for arbitrating rule conflicts and determining execution priorities. In addition, both retries and step jumps involve complex state management and context switching, and existing rules struggle to define and drive necessary accompanying operations such as state rollback, data cleanup, and parameter adaptation. Particularly during process jumps, static configuration cannot precisely specify which data in the original execution context should be transformed and passed to the backup step, causing the backup step to fail to execute due to missing context or data format mismatches. These shortcomings collectively restrict the dynamic adaptability, decision-making accuracy, and execution reliability of the anomaly recovery strategy, affecting the overall fault tolerance and process continuity of the system. Therefore, the anomaly handling process in this embodiment determines whether to retry or jump to a backup step based on the anomaly handling rules in the instantiation configuration parameters, including:

[0308] S3071. Based on the instantiation configuration parameters, obtain exception handling rules; the exception handling rules include optional exception retry configuration and optional backup step configuration; the exception retry configuration includes a maximum retry threshold, and the backup step configuration includes a backup step identifier.

[0309] S3072. Based on the current step failure status record maintained by the execution scheduling module, obtain the current number of retries; the current step failure status record uses the current step identifier as the key to associate and store the number of times the step has been retried.

[0310] S3073. Based on the exception handling rules, the current number of retries, and the result code string extracted from the execution result object, determine the exception handling action to be executed; specifically including:

[0311] S3073a. Based on the result code string, query a predefined exception classification mapping table to determine the exception category corresponding to the current failure; the exception classification mapping table defines the mapping relationship between different result code strings and exception category strings, and the exception categories include retryable exceptions and non-retryable exceptions.

[0312] S3073b: Determine whether the exception category is a retryable exception and whether the exception handling rule defines an exception retry configuration; if both are yes, continue to execute S3073c; otherwise, decide to jump to the backup step.

[0313] S3073c: Obtain the maximum retry count threshold from the abnormal retry configuration, compare the current number of retries with the maximum retry count threshold, if the current number of retries is less than the maximum retry count threshold, then decide to perform a retry; otherwise, decide to jump to the backup step.

[0314] S3074. If the decision is to retry, then execute the retry processing logic, including:

[0315] S3074a. Based on the retry interval policy defined in the abnormal retry configuration, calculate the waiting time for this retry; the retry interval policy adopts the exponential backoff algorithm, the base interval time is read from the configuration, and the backoff index is the current number of retries plus one.

[0316] S3074b: Pause the current scheduling process and wait for the specified waiting time;

[0317] S3074c, Increment the number of retries associated with the current step identifier in the current step failure status record by one, and persist the update;

[0318] S3074d: Return the retry decision result, instructing the execution scheduling module to reschedule the step corresponding to the current step identifier;

[0319] S3075. If the decision is to jump to the alternative step, then execute the jump processing logic, including:

[0320] S3075a. Determine whether a backup step configuration is defined in the exception handling rule; if it is defined, obtain the backup step identifier from the backup step configuration; if it is not defined, obtain the default backup step identifier from the system global configuration.

[0321] S3075b: Based on the backup step identifier, query the corresponding step index from the predefined execution sequence of docking tasks;

[0322] S3075c: Update the current step index maintained by the execution scheduling module to the queried step index;

[0323] S3075d: Clear the number of retries associated with the current step identifier in the current step failure status record;

[0324] S3075e: Return the jump decision result, instructing the execution scheduling module to continue scheduling from the updated current step index;

[0325] S3076. Based on the retry decision result or jump decision result, update the scheduling status data of the execution scheduling module.

[0326] For example, in the process of synchronizing funding data between a university's procurement system and financial system, a certain step returns the result code "NET WORK_TIMEOUT". The system obtains the exception handling rules for this step from the instantiation configuration parameters, which include a retry configuration with a maximum retry threshold of 3 and a backup step identifier "STEP_LOCAL_DATA_READ". It also reads from the failure status record that the current retry count for this step is 1. The system matches the result code "NETWORK_TIMEOUT" to the retryable exception category in the exception classification mapping table. Combining this with the existing retry configuration in the rules, and considering that the current retry count of 1 is less than the maximum retry threshold of 3, the system decides to execute a retry operation. Using the exponential backoff algorithm, with a configured base interval of 1 second and a backoff index of 2, the system calculates the retry waiting time to be 2 seconds. After pausing the scheduling process for 2 seconds, the system updates the retry count for this step to 2 and persists it. Then, it instructs the scheduling module to re-execute the funding data synchronization step. If this step fails again and the number of retries reaches 3, the system decides to jump to the backup step. It retrieves the backup step identifier "STEP_LOCAL_DATA_READ" from the rules, updates the current step index of the scheduling module after matching the corresponding step index, clears the record of the number of retries for this step, instructs the scheduling module to continue execution from this backup step, reads the funding data from the local cache to complete the synchronization process, and finally updates the decision result of this jump to the global scheduling status data.

[0327] This exception handling process decision-making method fundamentally solves the core problems of static configuration rules failing to distinguish failure scenarios, lack of rule priority arbitration, and missing state and context management by using exception classification mapping, multi-condition decision logic, exponential backoff retry mechanism, and standardized backup step jump management. It significantly improves the dynamic adaptability, decision accuracy, and execution reliability of exception recovery strategies, strengthening system fault tolerance and process continuity. Specifically, its effects are derived as follows: By matching the result code string with a predefined exception classification mapping table, it accurately distinguishes between retryable and non-retryable exceptions, solving the problem that static rules cannot perceive differences in failure scenarios. This provides a judgment basis that fits the actual fault type for subsequent decisions, avoiding invalid retries for permanent faults. Furthermore, it combines the retry configuration in the exception handling rules with the current number of retries for a two-layer judgment: first, it determines whether the exception is retryable and configures the retry rule; then, it compares the number of retries with the maximum retry threshold, forming a clear rule priority arbitration mechanism. This gives the decision logic a hierarchical structure, solves the conflict problem when multiple rules are triggered, and ensures the accuracy of retry and jump decisions. For retry operations, an exponential backoff algorithm is used to calculate the waiting time based on the current number of retries, avoiding frequent retries in a short period that could exacerbate system load. Simultaneously, the retry count is persistently updated to achieve precise management of the retry status and ensure that the number of retries does not exceed the limit. For jump operations, a backup step identifier is first obtained from the rule configuration; if no configuration exists, a global default value is called. Then, the corresponding step index is matched and the scheduler's current index is updated, while the retry count for the current step is simultaneously cleared. This achieves standardized state cleanup and context adaptation during jumps, solving the shortcomings of static configurations in accurately conveying context and backup steps failing to execute due to data or state issues. The entire process, through structured decision steps and standardized state updates, ensures that exception handling actions are highly matched to actual fault scenarios. This achieves dynamic adaptation for exception recovery while ensuring the standardization of retry and jump execution, effectively avoiding process interruptions caused by invalid operations, and allowing the system to maintain process continuity and stability even in fault scenarios.

[0328] This embodiment faces three interrelated technical challenges in determining the next execution step and continuing scheduling. First, it addresses how to design an unambiguous state machine adjudication algorithm to comprehensively handle multiple control flow states such as sequence, branch, and loop, ensuring a unique and correct selection of the next execution path under any circumstances. Second, it addresses how to establish an effective step reference resolution and loop detection mechanism during dynamic step transitions to verify the validity of the calculated target step identifier in the sequence definition and prevent process deadlocks due to incorrect transition logic. Therefore, it addresses how to use a rigorous adjudication state machine to make a unique and correct path selection among multi-dimensional control flow elements; how to securely parse and verify dynamically calculated step targets to prevent invalid references and logical deadlocks; and how to atomically update the global scheduling state in a transactional manner to ensure the eventual consistency of process progress under fault scenarios. To this end, it should be further explained that this embodiment determines the next execution step and continues scheduling based on the sequence or conditional branches of the execution sequence of the docking task, including:

[0329] S501. Based on the current scheduling status data maintained by the execution scheduling module, obtain the current step index, loop control parameters, and branch condition identifier to be processed.

[0330] Based on the loop control parameters, obtain the loop execution status identifier and the current iteration index.

[0331] Determine whether the loop execution status flag indicates an active state.

[0332] If the loop execution status indicator indicates an active state, then the current iteration index is further compared with the loop termination condition value obtained from the loop control parameters.

[0333] If the current iteration index is less than the loop termination condition value, the generated control flow decision result is "continue loop".

[0334] If the current iteration index is not less than the loop termination condition value, then the generated control flow decision result is "loop terminated".

[0335] If the loop execution status indicator indicates an inactive state, or a "loop terminated" decision result has been generated, then it is further determined whether the branch condition indicator to be processed is an empty string.

[0336] If the branch condition identifier to be processed is not empty, the generated control flow decision result is "evaluate branch".

[0337] If the branch condition identifier to be processed is empty, the generated control flow decision result is "sequential execution".

[0338] S502. Based on the control flow decision result, execute the corresponding target step identifier calculation logic, specifically:

[0339] If the control flow decision is "continue loop", then the target step identifier is set to the step identifier corresponding to the current step index.

[0340] If the control flow decision is "evaluate branch", then:

[0341] Based on the branch condition identifier, the corresponding condition expression string is obtained from the predefined branch configuration.

[0342] Based on the result set of the executed steps, the Boolean expression evaluation engine is invoked to evaluate the conditional expression string and obtain the Boolean truth value result.

[0343] Based on a predefined conditional branch mapping table, the corresponding target step identifier is queried and obtained according to the branch condition identifier and the Boolean truth value result.

[0344] If the control flow decision result is "sequential execution" or "loop termination", then:

[0345] Based on the execution sequence of the docking task, query the identifier of the next sequential step adjacent to the current step index.

[0346] If a next sequential step exists, the queried step identifier will be used as the target step identifier.

[0347] If there is no next sequential step, the target step identifier is set to null, indicating the end of the execution sequence.

[0348] S503. Determine whether the target step identifier is null; if it is null, terminate the scheduling process.

[0349] If the target step identifier is not empty, then search the execution sequence of the docking task to see if there is a step definition that matches the identifier.

[0350] If no matching step definition is found, an invalid step exception is generated and scheduling is aborted.

[0351] If a matching step definition is found, then perform loop detection:

[0352] Retrieves the current step's jump history, which is a queue that stores step identifiers in chronological order.

[0353] The jump relationship of this step is stored in the queue, and the jump relationship includes the source step identifier and the target step identifier.

[0354] Based on the jump relationships stored in the queue, a directed graph model is constructed, where nodes are step identifiers and edges are jump directions;

[0355] The directed graph model is traversed using a depth-first search algorithm to check whether there is a cycle that starts from the target step identifier node and returns to the node itself.

[0356] If a loop is detected, a loop anomaly is generated and scheduling is aborted.

[0357] It should be further explained that the directed graph model construction and loop detection method in this embodiment includes:

[0358] 1. Based on the step jump history queue maintained by the execution scheduling module, obtain all jump relationship data stored in the queue; the step jump history queue is an ordered queue that stores jump relationships in chronological order, and each jump relationship data includes a source step identifier, a target step identifier, a control flow type identifier, an execution timestamp, and a condition context string; the source step identifier and the target step identifier are unique character identifiers with a fixed length of 32 bits; the control flow type identifier is an enumerated data, and its values ​​include loop, branch, sequence, and exception jump; the execution timestamp is a millisecond-level timestamp value; the condition context string is a JSON-formatted key-value pair string, containing the name and value of the condition parameter that triggered the jump; the output is a structured jump relationship dataset, the dataset format is a list, and each element in the list is a dictionary structure containing the above fields.

[0359] 2. Based on the acquired jump relationship dataset, initialize the node set and edge set of the directed graph model; the node set is an unordered set, initially empty; the edge set is an ordered list, initially empty; the elements of the node set are step identifier strings, and the elements of the edge set are dictionary structures containing source node identifier, target node identifier, control flow type identifier, execution timestamp, condition context string, and iteration count value; the iteration count value is initially 0 and is only updated when the control flow type identifier is loop; the output is an initialized empty directed graph model, containing an empty node set and an empty edge set.

[0360] 3. Based on the initialized directed graph model and jump relationship dataset, traverse each jump relationship data in the dataset and perform node and edge addition operations;

[0361] 3.1 For the source step identifier in the jump relationship data of the current traversal, determine whether it exists in the node set; if it does not exist, add the source step identifier to the node set; if it exists, do not perform the operation.

[0362] 3.2 For the target step identifier in the jump relationship data of the current traversal, determine whether it exists in the node set; if it does not exist, add the target step identifier to the node set; if it exists, do not perform the operation.

[0363] 3.3 Based on the jump relationship data of the current traversal, construct directed edge data; if the control flow type is identified as cyclic, parse the iteration count value from the condition context string of the jump relationship data and assign it to the iteration count field of the edge data; if the control flow type is identified as non-cyclic, the iteration count value remains 0; encapsulate the source step identifier, target step identifier, control flow type identifier, execution timestamp, condition context string, and iteration count value into directed edge data;

[0364] 3.4 Determine whether the currently constructed directed edge data already exists in the edge set; the determination rule is that if the source node identifier, target node identifier, control flow type identifier, and iteration number are completely identical, it is determined to exist; if it does not exist, the directed edge data is added to the edge set; if it exists, no operation is performed.

[0365] 3.5 After the traversal is complete, the output is a directed graph model containing a complete set of nodes and a set of edges; the set of nodes contains all the step identifiers that have appeared, and the set of edges contains all the directed edge data after deduplication.

[0366] 4. Based on the constructed directed graph model and the identifier of the target step to be detected, perform loop detection preprocessing;

[0367] 4.1 Based on the target step identifier, select the target node from the node set of the directed graph model; if the target step identifier is not in the node set, output an invalid step exception directly; if it exists, obtain all outgoing edge data corresponding to the target node; the outgoing edge data is all edge data in the edge set whose source node identifier is equal to the target step identifier.

[0368] 4.2 Based on the filtered outgoing edge data, it is classified and processed according to the control flow type identifier; for outgoing edge data with the control flow type identifier of loop, edge data with the iteration number value less than the preset maximum iteration threshold is further filtered out, and the preset maximum iteration threshold is 100; for outgoing edge data with the control flow type identifier of branch, sequence, and abnormal jump, edge data with the execution timestamp in the most recent scheduling cycle is retained, and the most recent scheduling cycle is the current system timestamp pushed back 3600000 milliseconds;

[0369] 4.3 Based on the outgoing edge data after classification, construct a list of valid outgoing edges for the target node; output the list of valid outgoing edges, which contains only outgoing edge data that meets the control flow type and time / iteration threshold.

[0370] 5. Based on the list of valid outgoing edges of the target node, perform cycle detection using a depth-first search algorithm;

[0371] 5.1 Initialize the parameters of the depth-first search, including the set of visited nodes, the recursive depth counter, and the loop detection result identifier; the set of visited nodes is initially empty, the recursive depth counter is initially 0, and the loop detection result identifier is initially False; the maximum threshold of the recursive depth counter is set to 50, and if it exceeds this threshold, it is identified as a potential loop;

[0372] 5.2 Starting from the target node, traverse each edge in its list of valid outgoing edges, performing a recursive traversal:

[0373] 5.2.1 Add the current node to the set of visited nodes;

[0374] 5.2.2 Obtain the target node identifier of the current edge data, and determine whether the target node identifier exists in the set of visited nodes; if it exists, update the loop detection result identifier to True and terminate the recursion; if it does not exist, determine whether the recursion depth counter has reached the maximum threshold; if it has, update the loop detection result identifier to True and terminate the recursion; if it has not reached the maximum threshold, increment the recursion depth counter by 1, use the target node identifier as the new current node, and repeat step 5.2.

[0375] 5.2.3 After the recursive traversal is completed, clear the set of visited nodes and reset the recursion depth counter;

[0376] 5.3 Output the detection result based on the loop detection result identifier; if the identifier is True, output the loop anomaly information, including the node path that triggered the loop and the control flow type; if the identifier is False, output the verification result of no loop.

[0377] 5.4 The specific execution logic of the depth-first search algorithm is as follows: Starting from the target node, traverse all reachable nodes layer by layer along the direction of the directed edge, record the visited nodes, and if the traversal returns to a visited node or the traversal depth exceeds the threshold, it is determined that a cycle exists; the time complexity of the algorithm is O(V+E), where V is the number of nodes and E is the number of valid outgoing edges.

[0378] 6. Based on the loop detection results, update the directed graph model and output the final detection conclusion;

[0379] 6.1 If the detection result indicates the existence of a loop, extract the edge data that triggers the loop, mark it as an invalid edge and remove it from the edge set, and output a loop anomaly containing invalid edge information;

[0380] 6.2 If the detection result is no loop, the output will show a successful verification conclusion, including the target step identifier and the node / edge statistics of the directed graph model; the node / edge statistics include the total number of nodes, the total number of valid edges, and the number of edges of each control flow type.

[0381] 6.3 The final detection result output is structured data, including detection status (pass / abnormal), abnormality type (none / invalid step / loop), abnormality details (empty / step identifier / invalid edge information), and statistical information (total number of nodes, total number of valid edges).

[0382] S504. Based on the target step identifier that has passed verification and has no loops, update the scheduling status data, specifically as follows:

[0383] The current step index in the current scheduling status data is updated to the index value corresponding to the target step identifier in the execution sequence of the docking task.

[0384] If the control flow decision is "continue loop", then the current iteration index value in the loop control parameters is incremented by one.

[0385] If the control flow decision result is "evaluate branch" or "loop terminate", then the pending branch condition identifier is reset to an empty string.

[0386] The transactional persistence service is invoked to write the complete scheduling state data, including the updated current step index, loop control parameters, and branch condition identifiers, into persistent storage as an atomic transaction.

[0387] S505. Based on the current step index after successful persistence, trigger the execution scheduling module to execute a new round of scheduling loop.

[0388] For example, in the scheduling process of synchronizing paginated funding data between a university procurement system and a financial system, the system obtains the following from the current scheduling status data: the current step index is 5, the loop control parameters show the execution status as active, the current iteration index is 2, the loop termination condition is the total number of pages 10, and the pending branch condition identifier is empty. The system first determines that the loop is active and that the iteration index 2 is less than the termination condition 10, generating a control flow decision result of "continue looping". Then, it sets the target step identifier to the "funding data pagination query" identifier corresponding to step 5. The system verifies that this identifier exists in the execution sequence of the task being connected, and then constructs a directed graph to detect loops through the jump history. After finding no loop problem, the current step index is kept at 5, the loop iteration index is updated to 3, and since there is no branch condition identifier, it does not need to be reset. Subsequently, the updated scheduling status is atomically persisted through a transactional service. Finally, based on the updated step index, the execution scheduling module is triggered to re-execute the "funding data pagination query" step, starting a new round of scheduling loop. If the iteration index gradually increases to 10 after this step is completed, the system will determine that the termination condition is met and generate a "loop termination" decision result. The target step identifier will be set to the "funding data summary" identifier of step 6 in the sequence. After verifying its validity and completing the loop detection, the step index will be updated to 6, the branch condition identifier will be reset, and the state will be persisted. Then, the execution scheduling module will be triggered to execute step 6 and continue to advance the subsequent process of funding synchronization.

[0389] This step-by-step scheduling and decision-making method, through a hierarchical control flow state machine decision-making algorithm, standardized target step calculation logic, multi-dimensional step verification mechanism, and transactional state update strategy, fundamentally solves the core problems of path selection ambiguity, invalid references and infinite loops in dynamic jumps, and lack of consistency guarantees in state updates under multiple control flow states. It achieves unified coordination and precise scheduling of sequential, branching, and looping control flows, ensuring the uniqueness, security, and eventual consistency of process advancement. Specifically, its effect is derived as follows: by first determining the loop execution state, then generating a decision to continue the loop or terminate the loop based on the iteration index and termination condition; in the inactive loop state, it further determines whether the branch condition identifier is empty to generate an evaluation branch or sequential execution decision. This constructs a hierarchical state machine decision-making logic, comprehensively processing multiple control flow states with a priority order of loop first, branch second, and sequential last, resolving the ambiguity of path selection when multiple control flows coexist, and ensuring that the execution path can be uniquely determined in any scenario. Based on the ruling result, the corresponding target step is calculated. The current step identifier is reused repeatedly, the evaluation branch matches the target step through expression evaluation, and the next sequential step is called sequentially after execution and loop termination. This ensures precise matching between the target step calculation and the control flow type, guaranteeing the correctness of path selection. The calculated target step is first verified for validity in the execution sequence of the task being connected. Then, a directed graph is constructed using jump history, and a depth-first search algorithm is used to detect loops. This solves the problem of invalid step references in dynamic jumps and effectively avoids process deadlocks caused by erroneous jumps, blocking invalid scheduling and logical deadlocks at the source. Finally, the scheduling state is updated based on the verified target step. The step index, iteration index, and branch condition identifier are updated specifically according to the control flow type. The entire scheduling state is then atomically written to storage through a transactional persistence service, ensuring the atomicity and integrity of the state update. This solves the problem of inconsistent state updates in fault scenarios, and even if the system is interrupted, scheduling can be accurately restored based on the persistent state after restart. Through rigorous adjudication, precise calculation, comprehensive verification, and atomic updates, the entire process achieves unified scheduling and management of multiple control flows, significantly improving the accuracy, security, and reliability of process scheduling, and ensuring the stable and continuous progress of the scheduling process.

[0390] Example 2

[0391] Please see Figure 2 Another embodiment of the present invention provides: a scheduling system for docking execution method sequences, comprising:

[0392] The acquisition module obtains the configuration parsing results; the configuration parsing results define the execution sequence of M docking tasks, and the execution sequence includes the identifiers of multiple steps, the functional modules called by each step, the execution order, and the configuration parameters of each step;

[0393] The loading module determines the current step to be executed based on the execution sequence and scheduling status, and loads the configuration parameters corresponding to the step to be executed. The configuration parameters include data source information, operation instructions and exception handling rules.

[0394] The execution module, based on the configuration parameters, initiates a call to the interface adaptation module or the data conversion module to perform the data interaction or conversion operation of the current step;

[0395] The feedback recording module receives the execution results returned by the functional module and records the execution status of the step to be executed;

[0396] The exception handling execution module judges the execution result against the preset conditions in the exception handling rules. If the exception conditions are met, the module adjusts the remaining unexecuted steps and their execution order in the execution sequence according to the retry threshold or alternative step identifier defined in the exception handling rules. If the conditions are not met, the module determines the next step to be executed according to the order or conditional branch of the execution sequence of the docking task and continues scheduling until all steps in the execution sequence are scheduled.

[0397] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments under the guidance of the present invention without departing from the spirit and scope of the present invention. All of these variations are within the protection scope of the present invention.

[0398] If the technical solution disclosed herein involves personal information, the product using this technical solution has clearly informed the user of the personal information processing rules and obtained the user's voluntary consent before processing the personal information. If the technical solution disclosed herein involves sensitive personal information, the product using this technical solution has obtained the user's separate consent before processing the sensitive personal information, and also meets the requirement of "express consent". For example, at personal information collection devices such as cameras, clear and prominent signs are set up to inform users that they have entered the scope of personal information collection and that personal information will be collected. If an individual voluntarily enters the collection scope, it is deemed that they have agreed to the collection of their personal information; or on the personal information processing device, with clear signs / information informing users of the personal information processing rules, authorization is obtained from the individual through pop-up information or by asking the individual to upload their personal information; wherein, the personal information processing rules may include information such as the personal information processor, the purpose of personal information processing, the processing method, and the types of personal information processed.

Claims

1. A scheduling method for interfacing with a sequence of execution methods, characterized in that, An adaptation layer is applied between the procurement and bidding system and third-party systems. The adaptation layer includes an interface adaptation module, a data conversion module, and an execution scheduling module. The method is executed by the execution scheduling module, and the steps include: Obtain the configuration parsing result; the configuration parsing result defines the execution sequence of M docking tasks, and the execution sequence includes the identifiers of multiple steps, the functional modules called by each step, the execution order, and the configuration parameters of each step; Based on the execution sequence and scheduling status, determine the current step to be executed and load the configuration parameters corresponding to the step to be executed. The configuration parameters include data source information, operation instructions and exception handling rules. Based on the configuration parameters, a call is made to the interface adaptation module or the data conversion module to perform the data interaction or conversion operation of the current step; Receive the execution result returned by the functional module and record the execution status of the step to be executed; The execution result is compared with the preset conditions in the exception handling rules. If the exception conditions are met, the remaining unexecuted steps in the execution sequence and their execution order are adjusted according to the retry threshold or alternative step identifier defined in the exception handling rules. If the conditions are not met, the next step to be executed is determined according to the order or conditional branch of the execution sequence of the docking task and scheduling continues until all steps in the execution sequence are scheduled. The step of determining the current action to be performed includes: Obtain the current scheduling context; the current scheduling context is defined by a preset scheduling state data structure, which includes the current step index, the result set of executed steps, and the branch condition identifier and loop control parameters to be processed; Based on the current step index, the unique identifier of the current step to be executed is queried and determined from the predefined execution sequence of docking tasks; Based on the unique identifier of the current step to be executed, the corresponding step configuration raw data is retrieved from the configuration storage; the step configuration raw data includes the data source connection string, structured query language statement or application interface call template, and exception handling rules; The original data configured in the above steps is parsed to identify the variable placeholders in the data source connection string and data operation instructions; Replace the variable placeholders with the corresponding parameter values ​​obtained from the set of environment variables or the set of results of the executed steps to generate instantiated configuration parameters; Perform compliance checks on the instantiated configuration parameters, and obtain the verified instantiated configuration parameters after the checks pass; the compliance checks include verifying the format of the data source connection information, verifying the syntax structure of the data operation instructions, and verifying the validity of the retry threshold in the exception handling rules; Based on the branch condition identifier, determine whether a branch jump is needed; if a branch jump is needed, evaluate the condition expression corresponding to the branch condition identifier. The input parameters of the condition expression come from the result set of the executed steps. Based on the evaluation result, determine a new current step identifier to be executed from the execution sequence of the docking task. Based on the loop control parameters, determine whether the system is in a loop execution state; if it is in a loop execution state, check whether the loop execution state meets the termination condition; if the termination condition is met, exit the loop execution state and update the current step index based on the execution sequence of the docking task; if the termination condition is not met, keep the current step identifier unchanged and update the loop control parameters. When there is no branch jump and the execution is not in a loop or the loop continuation condition is met, the verified instantiated configuration parameters are loaded into the execution scheduling module. The updated current step index, the branch condition identifier, and the loop control parameters are persistently saved.

2. The scheduling method for a docking execution method sequence as described in claim 1, characterized in that, Initiating a call to the interface adaptation module or the data conversion module includes: S301. Based on the verified instantiated configuration parameters corresponding to the current step to be executed, obtain the operation type identifier and parameter mapping table; S302. Based on the operation type identifier, obtain the corresponding executor instance from the pre-registered executor factory; the executor factory is used to provide the corresponding executor instance according to the operation type identifier; wherein, the executor factory internally pre-sets and maintains an executor registry, the executor registry is used to establish the mapping relationship between the operation type identifier string and the specific class implementing the unified executor interface; based on the operation type identifier, querying the executor registry can obtain and instantiate the corresponding specific class, and obtain an executor instance that can execute the corresponding operation matching the operation type identifier; S303. Based on the parameter mapping table and the global execution context, construct a unified execution context object; the global execution context includes a set of environment variables and a set of results of executed steps.

3. The scheduling method for a docking execution method sequence as described in claim 2, characterized in that, Initiating a call to the interface adaptation module or the data conversion module further includes: S304. Based on the obtained executor instance and the unified execution context object, initiate a call request and receive the execution result object; S305. Based on the success status flag in the execution result object, determine whether the current step was executed successfully; if the success status flag is true, then execute S306; if the success status flag is false, then execute S307. S306. Process successful execution results, including: Extract the main business data from the execution result object; Associate the business data subject with the current step identifier to form a step output key-value pair; Add the key-value pairs output by the step to the result set of the executed steps for reference in subsequent steps; S307. Handling failed execution results, including: Extract the result code string from the execution result object; Record the current step identifier, result code string, and failure timestamp to the exception log; Trigger the exception handling process; the exception handling process determines whether to retry or jump to the backup step based on the exception handling rules in the instantiation configuration parameters.

4. The scheduling method for a docking execution method sequence as described in claim 3, characterized in that, The exception handling process determines whether to retry or jump to a backup step based on the exception handling rules in the instantiation configuration parameters, including: S3071. Based on the instantiation configuration parameters, obtain exception handling rules; the exception handling rules include optional exception retry configuration and optional backup step configuration; the exception retry configuration includes a maximum retry threshold, and the backup step configuration includes a backup step identifier. S3072. Based on the current step failure status record maintained by the execution scheduling module, obtain the current number of retries; the current step failure status record uses the current step identifier as the key to associate and store the number of times the step has been retried.

5. The scheduling method for a docking execution method sequence as described in claim 4, characterized in that, The exception handling process, based on the exception handling rules in the instantiation configuration parameters, determines whether to retry or jump to a backup step, and further includes: S3073. Based on the exception handling rules, the current number of retries, and the result code string extracted from the execution result object, determine the exception handling action to be executed; specifically including: S3073a. Based on the result code string, query a predefined exception classification mapping table to determine the exception category corresponding to the current failure; the exception classification mapping table defines the mapping relationship between different result code strings and exception category strings, and the exception categories include retryable exceptions and non-retryable exceptions. S3073b: Determine whether the exception category is a retryable exception and whether the exception handling rule defines an exception retry configuration; if both are yes, continue to execute S3073c; otherwise, decide to jump to the backup step. S3073c: Obtain the maximum retry count threshold from the abnormal retry configuration, compare the current number of retries with the maximum retry count threshold, if the current number of retries is less than the maximum retry count threshold, then decide to perform a retry; otherwise, decide to jump to the backup step.

6. The scheduling method for a docking execution method sequence as described in claim 5, characterized in that, The exception handling process, based on the exception handling rules in the instantiation configuration parameters, determines whether to retry or jump to a backup step, and further includes: S3074. If the decision is to retry, then execute the retry processing logic, including: S3074a. Based on the retry interval policy defined in the abnormal retry configuration, calculate the waiting time for this retry; the retry interval policy adopts the exponential backoff algorithm, the base interval time is read from the configuration, and the backoff index is the current number of retries plus one. S3074b: Pause the current scheduling process and wait for the specified waiting time; S3074c, Increment the number of retries associated with the current step identifier in the current step failure status record by one, and persist the update; S3074d: Return the retry decision result, instructing the execution scheduling module to reschedule the step corresponding to the current step identifier.

7. The scheduling method for a docking execution method sequence as described in claim 6, characterized in that, The exception handling process, based on the exception handling rules in the instantiation configuration parameters, determines whether to retry or jump to a backup step, and further includes: S3075. If the decision is to jump to the alternative step, then execute the jump processing logic, including: S3075a. Determine whether a backup step configuration is defined in the exception handling rule; if it is defined, obtain the backup step identifier from the backup step configuration; if it is not defined, obtain the default backup step identifier from the system global configuration. S3075b: Based on the backup step identifier, query the corresponding step index from the predefined execution sequence of docking tasks; S3075c: Update the current step index maintained by the execution scheduling module to the queried step index; S3075d: Clear the number of retries associated with the current step identifier in the current step failure status record; S3075e: Return the jump decision result, instructing the execution scheduling module to continue scheduling from the updated current step index; S3076. Based on the retry decision result or jump decision result, update the scheduling status data of the execution scheduling module.

8. A scheduling system for a sequence of docking execution methods, implemented based on a scheduling method for a sequence of docking execution methods according to any one of claims 1-7, characterized in that, include: The acquisition module obtains the configuration parsing results; the configuration parsing results define the execution sequence of M docking tasks, and the execution sequence includes the identifiers of multiple steps, the functional modules called by each step, the execution order, and the configuration parameters of each step; The loading module determines the current step to be executed based on the execution sequence and scheduling status, and loads the configuration parameters corresponding to the step to be executed. The configuration parameters include data source information, operation instructions and exception handling rules. The execution module, based on the configuration parameters, initiates a call to the interface adaptation module or the data conversion module to perform the data interaction or conversion operation of the current step; The feedback recording module receives the execution results returned by the functional module and records the execution status of the step to be executed; The exception handling execution module judges the execution result against the preset conditions in the exception handling rules. If the exception conditions are met, the module adjusts the remaining unexecuted steps and their execution order in the execution sequence according to the retry threshold or alternative step identifier defined in the exception handling rules. If the conditions are not met, the module determines the next step to be executed according to the order or conditional branch of the execution sequence of the docking task and continues scheduling until all steps in the execution sequence are scheduled.

Images