Workflow timed task execution method based on remote call and related device

Abstract

The invention provides a workflow timed task execution method based on remote calling and a related device, and the method comprises the steps: obtaining configuration data, determining a plurality of current remote calling data according to the configuration data, replacing corresponding historical remote calling data in a workflow timed task request code with all the current remote calling data, and executing the workflow timed task according to the historical remote calling data. The updated remote calling request is obtained, the updated remote calling request is sent to execute the workflow timed task, in this way, remote calling of the workflow timed task can be achieved in a configuration driving mode, no JobHandler code needs to be written, remote calling can be achieved through configuration, the development cost is remarkably reduced, and the development efficiency is improved. Zero code development can be achieved, remote calling logic is defined through the configuration file and is easy to modify and maintain, the development efficiency can be effectively improved, when a remote calling requirement needs to be newly added, only configuration needs to be added, codes do not need to be modified, and the system expansibility is improved.

Description

Technical Field

[0001] This application relates to the field of workflow engine technology, and in particular to a method and related apparatus for executing scheduled workflow tasks based on remote invocation. Background Technology

[0002] In workflow engines of related technologies (such as Activiti and Flowable), the execution of timer jobs typically requires the following steps: defining a JobHandler class: writing a dedicated JobHandler implementation class for each timer job; registering the JobHandler: registering the custom JobHandler in the engine configuration; configuring the timer job: configuring the timer event in the BPMN (Business Process Model and Notation) process definition; and deploying and running: deploying the process definition to the engine for execution. Based on the above process, each timer job that requires remote invocation needs to have dedicated JobHandler code written, resulting in high development costs. Summary of the Invention

[0003] This application provides a workflow scheduled task execution method and related apparatus based on remote invocation, in order to solve the technical problem of high development cost of scheduled task execution in related technologies.

[0004] This application provides a method for executing a workflow scheduled task based on remote invocation. The method includes: acquiring configuration data; determining multiple current remote invocation data based on the configuration data; replacing the corresponding historical remote invocation data in the workflow scheduled task request code with all the current remote invocation data to obtain an updated remote invocation request; and sending the updated remote invocation request to execute the workflow scheduled task.

[0005] In one embodiment of this application, before obtaining configuration data, the method includes: if the triggering condition of the workflow timed task is met, triggering the step of obtaining configuration data.

[0006] In one embodiment of this application, the triggering condition includes receiving a timer trigger event.

[0007] In one embodiment of this application, determining multiple current remote call data based on the configuration data includes: parsing the configuration data using a preset parsing method to obtain the current remote call data corresponding to the preset parsing method. The number of preset parsing methods is multiple, and the current remote call data includes at least one of the following: target address, request method, request header, request body, retry strategy, and timeout period.

[0008] In one embodiment of this application, replacing the corresponding historical remote call data in the workflow scheduled task request code with all the current remote call data to obtain an updated remote call request includes: encapsulating multiple current remote call data; uniformly replacing the corresponding historical remote call data in the workflow scheduled task request code with the encapsulated current remote call data; and generating an updated remote call request based on the workflow scheduled task request code with the uniformly replaced variables.

[0009] In one embodiment of this application, after sending the updated remote call request, the method further includes: obtaining the execution result; if the execution result is successful, updating the process status of the workflow scheduled task and logging the execution result; if the execution result is unsuccessful, obtaining the current retry count; if the current retry count is less than or equal to the preset maximum retry count, resending the updated remote call request; if the current retry count is greater than the preset maximum retry count, generating an alarm notification and logging the execution result.

[0010] This application embodiment also provides a workflow scheduled task execution component based on remote invocation. The workflow scheduled task execution component based on remote invocation includes: a main parser class, used to obtain configuration data and determine multiple current remote invocation data according to the configuration data; and an invocation processor, used to replace the corresponding historical remote invocation data in the workflow scheduled task request code with all the current remote invocation data to obtain an updated remote invocation request and send it to execute the workflow scheduled task.

[0011] In one embodiment of this application, the workflow timed task execution component based on remote call further includes: a configuration data class for encapsulating a first type of current remote call data, wherein the first type of current remote call data is data other than retry-related configuration parameters among multiple current remote call data; and a retry strategy class for managing retry-related configuration parameters among multiple current remote call data.

[0012] This application also provides a workflow engine, which includes a workflow scheduled task execution component based on remote invocation as described in any of the above embodiments.

[0013] This application also provides an electronic device, including: a memory storing a computer program thereon; and a processor for executing the computer program in the memory to implement the steps of the method described in any of the above embodiments.

[0014] This invention also provides a computer-readable storage medium having a computer program stored thereon, the computer program being used to cause a computer to perform the method provided in any of the above embodiments.

[0015] The beneficial effects of this application are as follows: This application proposes a workflow scheduled task execution method, component, and workflow engine based on remote invocation. This method obtains configuration data, determines multiple current remote invocation data based on the configuration data, replaces the corresponding historical remote invocation data in the workflow scheduled task request code with all the current remote invocation data, obtains an updated remote invocation request, and sends the updated remote invocation request to execute the workflow scheduled task. Through this method, remote invocation of workflow scheduled tasks can be implemented via configuration-driven approaches, without writing any JobHandler code. Remote invocation can be achieved through configuration, significantly reducing development costs and enabling zero-code development. The remote invocation logic is defined through a configuration file, making it easy to modify and maintain, effectively improving development efficiency. When new remote invocation requirements are needed, only configuration needs to be added, without modifying the code, thus improving system scalability. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0017] In the attached diagram:

[0018] Figure 1 A flowchart illustrating a workflow-based scheduled task execution method based on remote invocation, provided in one embodiment of this application; Figure 2 A schematic diagram of a remote call configuration structure provided in an embodiment of this application; Figure 3 A schematic flowchart illustrating a workflow-based scheduled task execution method based on remote invocation, provided in one embodiment of this application; Figure 4 A schematic diagram of a workflow timed task execution component based on remote call provided in an embodiment of this application; Figure 5 A schematic diagram of a specific structure of a workflow timed task execution component based on remote invocation provided in an embodiment of this application; Figure 6 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0019] The following specific examples illustrate the implementation of this application. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments. Various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. In the absence of conflict, the following embodiments and features in the embodiments can be combined with each other.

[0020] It should be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this application. The drawings only show the components related to this application and are not drawn according to the actual number, shape and size of the components in the actual implementation. In the actual implementation, the shape, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0021] In the following description, numerous details are explored to provide a more thorough explanation of embodiments of the present application. However, it will be apparent to those skilled in the art that embodiments of the present application may be practiced without these specific details. In other embodiments, well-known structures and devices are shown in block diagram form rather than in detail to avoid obscuring embodiments of the present application.

[0022] It should be noted that the collection and processing of data such as users' natural language commands in this application must strictly comply with the requirements of relevant national laws and regulations in actual application, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0023] In workflow engines of related technologies (such as Activiti, Flowable, etc.), the execution of a timer job typically requires the following steps: Define the JobHandler class: Write a dedicated JobHandler implementation class for each scheduled task; Register JobHandler: Register a custom JobHandler in the engine configuration; Configure scheduled tasks: Configure scheduled events in the BPMN process definition; Deployment and execution: Deploy the process definition into the engine for execution.

[0024] The inventors discovered that the solutions in the related technologies have the following problems: High development costs: Each scheduled task that requires remote calls needs to have dedicated JobHandler code written; High coupling: Business logic is tightly coupled with the workflow engine, making it difficult to develop and test independently; Poor scalability: Adding new remote call requirements necessitates modifying the engine code and redeploying. Complex maintenance: The JobHandler code is scattered, making it difficult to manage and maintain in a unified manner; Complex configuration: Scheduled task information needs to be configured in multiple places, which is prone to errors; Poor reusability: Remote call logic for different scenarios cannot be reused, leading to redundant code development; Testing difficulties: Business logic is coupled with the engine, making unit testing and integration testing difficult; Therefore, there is an urgent need for a technical solution that can remotely invoke workflow scheduled tasks without writing JobHandler code, in order to solve the above-mentioned technical problems.

[0025] To address the aforementioned technical issues, this application provides a method for executing a workflow scheduled task based on remote invocation. By acquiring configuration data, multiple current remote invocation data are determined based on the configuration data. All current remote invocation data are used to replace the corresponding historical remote invocation data in the workflow scheduled task request code, resulting in an updated remote invocation request. This updated remote invocation request is then sent to execute the workflow scheduled task. Through this method, remote invocation of workflow scheduled tasks can be implemented via configuration, eliminating the need to write any JobHandler code. Remote invocation can be achieved through configuration, significantly reducing development costs and enabling zero-code development. The remote invocation logic is defined through a configuration file, making it easy to modify and maintain, effectively improving development efficiency. When new remote invocation requirements are needed, only configuration needs to be added, without modifying the code, thus improving system scalability.

[0026] Please see Figure 1 , Figure 1 A flowchart illustrating a workflow-based scheduled task execution method based on remote invocation, as provided in one embodiment of this application, is shown below. Figure 1 As shown, the method includes the following steps: Step S110: Obtain configuration data.

[0027] As an example, the method provided in this embodiment can be applied to scheduled task execution scenarios in workflow engines such as Activiti and Flowable.

[0028] As an example, configuration data can be generated based on data such as the target address of the interface to be accessed. For instance, when the address of the interface to be accessed changes, the workflow engine can be adjusted accordingly by modifying the corresponding content in the configuration data.

[0029] In one embodiment, the configuration data includes, but is not limited to, at least one of the following: target address, request method, request header, request body, retry policy, and timeout.

[0030] Configuration data can be implemented using files such as XML (Extensible Markup Language). For different services, the method provided in this application's embodiments can be used, requiring only corresponding modifications to the configuration data. This eliminates the need to write separate code for each service, significantly improving development efficiency, reducing development costs, and facilitating modification and maintenance. Adjusting requests through configuration data allows for the decoupling of business logic from the workflow engine, enabling independent development and testing.

[0031] Centralized management of remote call configurations facilitates monitoring and debugging, and can further reduce operation and maintenance costs.

[0032] The configuration items in the configuration data can also be added or adjusted according to the needs of those skilled in the art.

[0033] Configuration data can be written or adjusted by those skilled in the art according to preset configuration data format rules, or generated through other methods known to those skilled in the art.

[0034] In one embodiment, before acquiring configuration data, the method includes: if the triggering condition of the workflow scheduled task is met, triggering the step of acquiring configuration data. It can be understood that each time the triggering condition of the workflow scheduled task is met, the step of acquiring configuration data in step S110 is executed first, thus ensuring that each execution is performed according to the latest configuration data.

[0035] Following the above embodiments, the triggering condition includes receiving a timer trigger event. The determination of whether the triggering condition has been met can be made by setting a timer.

[0036] When a new or modified remote call request is received, it can be implemented by adding or modifying configuration data without writing or modifying engine code. For example, a remote call request can be obtained, which includes new configuration data and / or modified configuration data. Based on the new configuration data, the corresponding data is added to the configuration data; based on the modified configuration data, the corresponding data in the configuration data is modified. When the next scheduled task is triggered, the corresponding request can be generated and executed based on the adjusted configuration data.

[0037] Please see Figure 2 , Figure 2 A schematic diagram of a remote call configuration structure provided in an embodiment of this application is shown below. Figure 2As shown, the configuration data includes timer event labels, timer repetition periods, and labels specific to this embodiment, indicating remote calls. The remote call configuration information also includes the remote call address URL (target address); the remote call HTTP method, such as POST or GET; a request header label, which sets the request header content; the header value can also be obtained from the process variable (the currently parsed remote call data) using placeholders; a request body, configuring request parameters, which can also be obtained from the process variable (the currently parsed remote call data) using placeholders; a retry policy label, which sets the maximum number of retries and the retry interval; and a timeout policy, including a connection creation timeout (if a connection is not established within this timeout, a retry will be attempted) and a connection reading timeout (if data is not read within this timeout, a retry will be attempted).

[0038] like Figure 2 As shown, taking the remote call configuration in XML format as an example, it includes two parts: timer configuration and remote call configuration. The timer configuration uses the standard ISO 8601 time format (e.g., PT1H represents 1 hour); the remote call configuration includes elements such as target URL, HTTP method, request headers, request body, retry strategy, and timeout settings, and supports variable substitution and templated configuration.

[0039] Step S120: Determine multiple current remote call data based on the configuration data.

[0040] This can be achieved by parsing the configuration data to obtain the current remote call data corresponding to multiple configuration items.

[0041] In one embodiment, determining multiple current remote call data based on configuration data includes: parsing the configuration data using a preset parsing method to obtain the current remote call data corresponding to the preset parsing method. The number of preset parsing methods is multiple, and the current remote call data includes one or more of the following: target address, request method, request header, request body, retry policy, and timeout period.

[0042] It is understandable that each configuration item (target address, request method, etc.) has a corresponding preset parsing method. Once the configuration data is obtained, each preset parsing method will automatically parse the corresponding configuration item to obtain the current remote call data.

[0043] Each preset parsing method corresponds to only one configuration item. This reduces the impact of modifying one configuration item on other configuration items. If only the preset parsing method corresponding to configuration item A needs to be modified, then only that preset parsing method needs to be changed, without affecting the parsing methods of other configuration items.

[0044] Using the above method, the values ​​of each configuration item in the configuration data can be extracted to obtain the current remote call data.

[0045] Step S130: Replace the corresponding historical remote call data in the workflow scheduled task request code with all the current remote call data to obtain the updated remote call request.

[0046] In one embodiment, replacing the corresponding historical remote call data in the workflow scheduled task request code with all current remote call data to obtain an updated remote call request includes: encapsulating multiple current remote call data; uniformly replacing the corresponding historical remote call data in the workflow scheduled task request code with the encapsulated current remote call data; and generating an updated remote call request based on the workflow scheduled task request code with uniformly replaced variables.

[0047] Sending each remote call data separately can lead to data loss and processing difficulties. By encapsulating all current remote call data into a single object, only one object needs to be passed in subsequent calls, making the code cleaner and easier to manage.

[0048] As an example, variable substitution can be performed using placeholders. The replaced actual variable (current remote call data) is then rendered into a real HTTP request (updated remote call request) based on the template configuration. For instance, by using a pre-built mapping relationship between configuration items and current remote call data values, the actual value (current remote call data value) can replace the historical remote call data. The specific substitution method can also be implemented in ways known to those skilled in the art, and is not limited here.

[0049] Step S140: Send an updated remote call request to execute the workflow scheduled task.

[0050] In one embodiment, after sending the updated remote call request, the method further includes: obtaining the execution result; if the execution result is successful, updating the process status of the workflow scheduled task and logging the execution result; if the execution result is unsuccessful, obtaining the current retry count; if the current retry count is less than or equal to the preset maximum retry count, resending the updated remote call request; if the current retry count is greater than the preset maximum retry count, generating an alarm notification and logging the execution result.

[0051] The execution result can be determined in a manner known to those skilled in the art, such as based on whether a feedback message or expected data was received. If the execution result is successful, the process status of the node corresponding to this request needs to be updated for subsequent processing. If it fails, at least one of the following needs to be logged for later review: the execution result, the request data, or the timestamp.

[0052] Alarm notifications can be generated by combining a pre-defined alarm template with the current updated remote call request and / or execution result. Alarm notifications can also be determined by selecting preset notifications. The generation and warning methods of alarm notifications can also be implemented based on the needs of those skilled in the art.

[0053] Sometimes, a remote call request may fail due to a low-probability event. In such cases, it can be determined whether to continue retrying based on the preset number of retries. If the preset maximum number of retries has not been reached, retries can be used to avoid execution failures caused by occasional network fluctuations.

[0054] The workflow scheduled task execution method based on remote invocation provided in the above embodiments obtains configuration data, determines multiple current remote invocation data based on the configuration data, replaces the corresponding historical remote invocation data in the workflow scheduled task request code with all the current remote invocation data, obtains an updated remote invocation request, and sends the updated remote invocation request to execute the workflow scheduled task. In this way, remote invocation of workflow scheduled tasks can be realized through configuration-driven approach without writing any JobHandler code. Remote invocation can be realized through configuration, significantly reducing development costs and enabling zero-code development. The remote invocation logic is defined through configuration files, which are easy to modify and maintain, effectively improving development efficiency. When a new remote invocation requirement is needed, only the configuration needs to be added, without modifying the code, thus improving system scalability.

[0055] The following provides a specific flow example of a workflow scheduled task execution method based on remote calls. Please refer to [link / reference]. Figure 3 , Figure 3 A specific flowchart illustrating a workflow-based scheduled task execution method based on remote invocation, as provided in one embodiment of this application, is shown below. Figure 3As shown, the method includes the following steps: After starting, a timer triggers the parsing of the acquired configuration data (configuration information) to obtain multiple current remote call data, such as URL (uniform resource locator, i.e., the target address mentioned above), HTTP (Hypertext Transfer Protocol) method (request method), request headers, request body, retry strategy, etc. The parsed configuration items can be added or removed according to the needs of those skilled in the art; the above is only an example. Request parameters are constructed based on the parsed configuration information. During this process, historical remote call data can be replaced with current remote call data through variable substitution, such as using placeholders. The replaced actual variables are then rendered according to the template configuration, resulting in a real HTTP request and an updated remote call request. The remote call is executed, an HTTP request is sent, and a response is awaited. The success of the execution is determined. If it fails, it is determined whether the maximum number of retries (preset maximum number of retries) has been exceeded. If not, the remote call steps are re-executed. If so, a failure log is recorded, and exception information and alarm notifications are generated. As an example, exception information could be the cause of the exception, or the HTTP request and response results could be recorded as exception information. If execution is successful, the success result is processed, such as updating the process status and logging. The above process ends. The scheduled task execution process starts from the timer trigger and sequentially goes through steps such as configuration parsing, request parameter construction, and remote call execution. When the call fails, the system checks the retry count. If the maximum number of retries has not been reached, the call is re-executed after the retry interval; if the maximum number of retries has been reached, a failure log is recorded and the process ends.

[0056] In one embodiment, if no response is received after the timeout period, the process is stopped, and the remote call request is resent until the maximum number of retries is reached, and the above steps are repeated until the maximum number of retries is reached or the execution is successful.

[0057] In one embodiment, the above method can be implemented by pre-configuring the following: Configuration parsing method: The method for parsing remote call information in the scheduled task configuration; Dynamic execution mechanism: A mechanism that dynamically constructs HTTP requests and executes remote calls based on configuration information; Variable substitution mechanism: A mechanism for dynamically obtaining and substituting request parameters from process variables; Configuration format specification: Remote call configuration specification in XML format.

[0058] The workflow scheduled task execution method based on remote call provided in the above embodiments parses the remote call information in the scheduled task configuration, including the target URL, HTTP request method, request header information, request body content, and retry strategy, through configuration parsing. Then, it performs dynamic execution to dynamically construct HTTP request parameters and execute the remote call based on the parsed configuration information. It supports variable substitution and template rendering. Finally, it processes the result to handle the remote call response, updating the workflow status or triggering subsequent operations based on the response status. It also has the following beneficial effects: Zero-code development: No need to write any JobHandler code, remote calls can be achieved through configuration, significantly reducing development costs; Configuration-driven: All remote call logic is defined through configuration files, making it easy to modify and maintain, and improving development efficiency; Unified management: All remote call configurations are centrally managed, facilitating monitoring and debugging and reducing operation and maintenance costs; Easy to extend: Adding new remote call requirements only requires adding configuration, without modifying the code, thus improving system scalability; Reduced maintenance costs: Reduced code dispersion and coupling, improving system maintainability; Supports complex scenarios: Supports multiple HTTP methods, custom request headers, request body templates, and retry strategies to meet complex business needs; Improve system reliability: Enhance the success rate and stability of remote calls through retry mechanisms and timeout control; Enhanced system flexibility: Business logic is decoupled from the workflow engine, facilitating independent development and testing; Reduce system complexity: It simplifies the development and deployment process of scheduled tasks, thereby reducing system complexity; Improve development efficiency: Significantly improve development efficiency and deployment speed through configuration-based methods.

[0059] In one embodiment, a remote call-based workflow scheduled task execution component is provided, which is used to execute the remote call-based workflow scheduled task execution method provided in any of the above embodiments. See also... Figure 4 , Figure 4 A schematic diagram of a workflow timed task execution component based on remote call provided in an embodiment of this application is shown below. Figure 4As shown, the workflow scheduled task execution component 400 based on remote calls includes: a main parser class 410, used to obtain configuration data and determine multiple current remote call data based on the configuration data; and a call processor 440, used to replace the corresponding historical remote call data in the workflow scheduled task request code with all the current remote call data to obtain the updated remote call request and send it to execute the workflow scheduled task.

[0060] In one embodiment, please continue to see Figure 4 The workflow scheduled task execution component based on remote calls also includes: a configuration data class 420, which encapsulates the first type of current remote call data, which is the data in multiple current remote call data excluding retry-related configuration parameters; and a retry strategy class 430, which manages the retry-related configuration parameters in multiple current remote call data.

[0061] In one embodiment, see further. Figure 4 The workflow timed task execution component based on remote call also includes a timer 450, which is used to generate timer trigger events and trigger the main parser class 410 to obtain configuration data through the timer trigger events.

[0062] Please see Figure 5 , Figure 5 A schematic diagram of a specific structure of a workflow scheduled task execution component based on remote invocation provided in an embodiment of this application is shown below. Figure 5 As shown, an object-oriented design is adopted, including the `RemoteCallConfigParser` main parser class, the `RemoteCallConfig` configuration data class, and the `RetryPolicy` retry policy class. `RemoteCallConfigParser` is responsible for parsing the XML configuration and extracting each configuration item (obtaining the current remote call data based on the configuration data). `RemoteCallConfig` encapsulates the parsed configuration data (the first type of current remote call data), and `RetryPolicy` specifically manages retry-related configuration parameters. Based on the parsed remote call configuration, request parameters are constructed through a general remote call handler (call handler), and the remote call is executed through `httpClient` (request client), processing the call result. Specifically: The RemoteCallConfigParser includes a public method `parse(String)`, which is the external interface used to retrieve configuration data. This public method calls internal "helper methods" (predefined parsing methods) to extract different configuration items from the string, obtaining the current remote call data. It then sets all extracted configuration items (URL, method, request headers, etc.) into a new RemoteCallConfig object and returns this assembled object to the caller (call handler). These methods are "specific jobs," each responsible for only one specific extraction task. They are designed to be private, meaning they cannot be directly called externally and can only be used internally through the public `parse` method.

[0063] extractUrl(): Specifically finds and parses the target URL (target address) from the configuration string.

[0064] extractMethod(): Specifically extracts HTTP methods (such as GET and POST).

[0065] extractHeaders(): Specifically parses out all request header information and assembles it into a Map.

[0066] extractPayload(): Specifically parses out the request body data and assembles it into a Map.

[0067] extractRetryPolicy(): Specifically parses out the retry policy and converts it to an Enum type.

[0068] extractTimeout(): Specifically extracts the timeout period and converts it to a Long type.

[0069] Each method performs a single task, ensuring clear functionality and concise code. If the URL parsing logic needs modification, only the `extractUrl()` method needs changing; it won't affect other parts of the parsing process. All parsing logic is concentrated within the `RemoteCallConfigParser` class, isolated from the rest of the program. If the configuration string format needs changing (e.g., from JSON to YAML), only this parser class needs modification, while other code using `RemoteCallConfig` objects remains completely unaffected. The code structure is clear and easy to test. Independent unit tests can be written for each private method to ensure the correctness of each parsing logic. It can be called by any part of the program to parse different configuration strings and generate different configuration objects.

[0070] The RemoteCallConfig class contains all the "tools" or "parameters" needed to make a network request (such as calling an external API).

[0071] url: String, is the target address to be called, which is the API link.

[0072] `method: HttpMethod` defines the type of operation to be performed. This is typically an HTTP method, such as GET (to retrieve data) or POST (to create data).

[0073] headers: Map, request headers used to pass additional information, such as authentication token (Authorization: Bearer ...), content type (Content-Type: application / json), etc. The Map structure allows for flexible storage of multiple key-value pairs.

[0074] payload: Map, the request body. This is where data is placed when sending data using the POST or PUT methods. A Map is used to represent this data, which is typically in key-value pair format.

[0075] `retryPolicy:` Enum, the retry policy. Network requests are not always successful and may fail due to network fluctuations or temporary service unavailability. This field defines what to do after a failure. For example, it can be an enumeration value such as `NO_RETRY` (no retry), `RETRY_THRICE` (retry 3 times), `EXPONENTIAL_BACKOFF` (exponential backoff retries), etc. This greatly enhances the robustness of the program.

[0076] `timeout`: Long, timeout period (unit may be milliseconds). Defines the maximum time to wait for a response from the other party. If no response is received after this time, the program is abandoned and marked as failed to prevent indefinite waiting. This is a key parameter for ensuring system responsiveness and stability.

[0077] By packaging all configuration parameters related to remote calls into a single, self-contained object, the code avoids the need to pass scattered variables such as URL, method, and timeout throughout the code. Instead, a single `RemoteCallConfig` object is passed. This makes the code cleaner and easier to manage. Multiple `RemoteCallConfig` instances with different configurations can be created. For example, one can be used to call the "User Service," and another to call the "Payment Service," each with different URLs, timeouts, and retry policies. This avoids writing repetitive configuration code for each different call. When adding new configuration parameters, only a new field needs to be added to this class, without modifying the signatures of all methods initiating the call, adhering to the "Open / Closed Principle." It clearly defines the minimum information required to initiate a remote call, providing a unified standard for team development and ensuring consistency of configuration information. It embodies the principle of "separation of configuration and behavior," decoupling the code initiating the network request (behavior) from the request parameters (configuration), thus making the code more flexible, robust, and maintainable.

[0078] The RetryPolicy class manages retry policies, including: `maxRetries: int` represents the maximum number of retries; it is an integer. For example, if set to 3, the operation will be retried a maximum of 3 times before giving up.

[0079] `retryInterval: long` represents the retry interval, and is of type long integer. It is typically measured in milliseconds and defines the waiting time between each retry to avoid resource waste caused by frequent retries.

[0080] If the request times out, it can be automatically retried according to the number of retries and the interval set in RetryPolicy.

[0081] By extending the scheduled task configuration of the workflow engine, remote call information can be defined directly in the configuration, enabling remote service calls to be developed with zero code.

[0082] Specific limitations regarding the remote call-based workflow scheduled task execution component can be found in the limitations of the remote call-based workflow scheduled task execution method described above, and will not be repeated here. Each module in the aforementioned remote call-based workflow scheduled task execution component can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in an electronic device, or stored in the memory of an electronic device in software form, so that the processor can invoke and execute the corresponding operations of each module.

[0083] In this embodiment, the workflow scheduled task execution component based on remote call is actually set up with multiple modules to execute the workflow scheduled task execution method based on remote call in any of the above embodiments. The specific functions and technical effects can be referred to in the above embodiments, and will not be repeated here.

[0084] In one embodiment, a workflow engine is also provided, which includes the remote call-based workflow scheduled task execution component provided in any of the above embodiments.

[0085] For specific limitations regarding the workflow engine, please refer to the limitations on the remote call-based workflow scheduled task execution method described above, which will not be repeated here. Each module in the aforementioned workflow engine can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in hardware or independently of the processor in an electronic device, or stored in software within the memory of the electronic device, so that the processor can invoke and execute the corresponding operations of each module.

[0086] In this embodiment, the workflow engine is essentially configured with multiple modules to execute the workflow scheduled task execution method based on remote invocation in any of the above embodiments. The specific functions and technical effects can be referred to in the above embodiments, and will not be repeated here.

[0087] See Figure 6 , Figure 6 A schematic diagram of the structure of an electronic device provided in an embodiment of this application is shown below. Figure 6 As shown, this embodiment of the invention also provides an electronic device 600, including a processor 601, a memory 602, and a communication bus 603; the communication bus 603 is used to connect the processor 601 and the memory 602; the processor 601 is used to execute a computer program stored in the memory 602 to implement the method described in any of the above embodiments.

[0088] This invention also provides a computer-readable storage medium having a computer program stored thereon, the computer program being used to cause a computer to perform the method provided in any of the above embodiments.

[0089] This application also provides a non-volatile readable storage medium storing one or more modules (programs) that, when applied to a device, enable the device to execute the instructions included in the steps provided in this application.

[0090] This application also provides a computer program product, including a computer program that, when executed by a processor, can implement the steps and corresponding content of the aforementioned method embodiments.

[0091] It should be noted that the computer-readable medium described in this disclosure can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this disclosure, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this disclosure, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A computer-readable signal medium can be any computer-readable medium other than a computer-readable storage medium, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wires, optical fibers, RF (radio frequency), etc., or any suitable combination thereof.

[0092] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0093] Computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0094] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0095] It should be understood that the terms "first," "second," etc., used in this application are used to distinguish similar objects and do not necessarily indicate a specific order or sequence. The technical features to which these terms are used can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in a sequence other than that shown in the figures or text.

[0096] It should be understood that although the flowcharts provided in the embodiments of this application indicate the various steps with arrows, the order indicated by the arrows does not necessarily limit the implementation order of these steps. Those skilled in the art can perform these steps in other orders according to different implementation scenarios and requirements.

[0097] The above embodiments are merely illustrative of the principles and effects of this application and are not intended to limit this application. Any person skilled in the art can modify or alter the above embodiments without departing from the spirit and scope of this application. Therefore, all equivalent modifications or alterations made by those skilled in the art without departing from the spirit and technical concept disclosed in this application should still be covered by the claims of this application.

Claims

1. A workflow-based scheduled task execution method based on remote invocation, characterized in that, The method includes: Get configuration data; Multiple current remote call data are determined based on the configuration data; Replace the corresponding historical remote call data in the workflow scheduled task request code with all of the current remote call data to obtain the updated remote call request; Send the updated remote call request to execute the workflow scheduled task.

2. The workflow-based scheduled task execution method based on remote invocation as described in claim 1, characterized in that, Before obtaining configuration data, the method includes: If the triggering conditions of the workflow scheduled task are met, the step of obtaining configuration data is triggered. The triggering conditions include receiving a timer trigger event.

3. The workflow-based scheduled task execution method based on remote invocation as described in claim 1, characterized in that, Based on the configuration data, multiple current remote call data are determined, including: The configuration data is parsed using a preset parsing method to obtain the current remote call data corresponding to the preset parsing method. There are multiple preset parsing methods, and the current remote call data includes at least one of the following: target address, request method, request header, request body, retry policy, and timeout period.

4. The workflow-based scheduled task execution method based on remote invocation as described in claim 1, characterized in that, Replace the corresponding historical remote call data in the workflow scheduled task request code with all of the current remote call data to obtain the updated remote call request, including: Encapsulate multiple sets of current remote call data; The encapsulated current remote call data is used to uniformly replace the corresponding historical remote call data in the workflow scheduled task request code; The updated remote call request is generated based on the workflow scheduled task request code after unified variable replacement.

5. The workflow-based scheduled task execution method based on remote invocation as described in any one of claims 1-4, characterized in that, After sending the updated remote call request, the method further includes: Obtain the execution result; If the execution result is successful, update the process status of the workflow scheduled task and record the execution result in the log; If the execution result is a failure, obtain the current retry count. If the current retry count is less than or equal to the preset maximum retry count, resend the updated remote call request. If the current retry count is greater than the preset maximum retry count, generate an alarm notification and record the execution result in the log.

6. A workflow scheduled task execution component based on remote invocation, characterized in that, The workflow scheduled task execution component based on remote call includes: The main parser class is used to obtain configuration data and determine multiple current remote call data based on the configuration data. The call processor is used to replace the corresponding historical remote call data in the workflow scheduled task request code with all of the current remote call data to obtain the updated remote call request, and send it to execute the workflow scheduled task.

7. The workflow scheduled task execution component based on remote invocation as described in claim 6, characterized in that, The workflow scheduled task execution component based on remote call also includes: The configuration data class is used to encapsulate the current remote call data of the first type. The current remote call data of the first type is the data other than the retry-related configuration parameters among multiple current remote call data. The retry strategy class is used to manage retry-related configuration parameters in multiple current remote call data.

8. A workflow engine, characterized in that, The workflow engine includes the remote call-based workflow scheduled task execution component as described in claim 6 or 7.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method as described in any one of claims 1 to 5.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 5.

Images