Workflow recovery method and device

Abstract

The invention discloses a workflow recovery method and device, and relates to the technical field of big data. A specific embodiment of the method comprises the steps of obtaining a historical event corresponding to a workflow from a historical storage based on a received pause request of the workflow; replaying the historical event according to a pre-configured historical replaying mechanism to obtain an interrupt node corresponding to the workflow; and when the workflow is monitored to meet the recovery condition, returning to the interrupt node to continue to process the workflow. According to the embodiment, the historical event is obtained from the historical storage when the workflow is paused, replaying is performed based on the historical event, the workflow is driven to continue to be executed from the interrupt node, automatic and rapid recovery can be achieved after the workflow is interrupted, and reentrancy of unexpected faults of the workflow is achieved.

Description

Technical Field

[0001] The present invention relates to the field of big data technology, and in particular to a workflow recovery method and device. Background Art

[0002] With the rapid development of science and technology, robots are increasingly used in modern society. When robots perform complex tasks, they usually use workflow as a solution. Workflow is a broad concept, including the intelligent interaction process of robots, container orchestration, etc. At present, during the execution of workflows, it is common to encounter situations such as excessive memory interruption of the current task, network communication failure, and execution timeout. After the workflow is interrupted, it cannot be automatically and quickly restored. Summary of the invention

[0003] In view of this, an embodiment of the present invention provides a workflow recovery method and device, which obtains historical events from historical storage when the workflow is paused, replays based on the historical events, drives the workflow to continue executing from the interrupted node, and can automatically and quickly recover after the workflow is interrupted, thereby achieving reentrancy of unexpected workflow failures.

[0004] To achieve the above object, according to one aspect of an embodiment of the present invention, a workflow recovery method is provided, comprising: Based on the received workflow pause request, obtain the historical events corresponding to the workflow from the historical storage; Replay historical events according to the pre-configured historical replay mechanism to obtain the interruption node corresponding to the workflow; When the workflow meets the recovery conditions, it returns to the interrupted node to continue processing the workflow.

[0005] Optionally, before obtaining the historical events corresponding to the workflow from the historical storage based on the received pause request of the workflow, the method further includes: In response to receiving a pause request for a workflow, a workflow execution thread corresponding to the workflow is suspended to release system resources occupied by the workflow.

[0006] Optionally, in response to receiving a workflow pause request, the method further includes: A timer event is created according to a pause request of the workflow; wherein the timer event includes a current pause time and an expected wake-up time.

[0007] Persist timer events in history storage.

[0008] Optionally, monitoring that the workflow meets the recovery conditions includes: In response to the current time reaching the expected wake-up time, a wake-up event is generated, so as to return to the interruption node to continue processing the workflow based on the wake-up event.

[0009] Optionally, the method further comprises: In response to a system failure occurring before the current time reaches the expected wake-up time, a new execution mechanism is determined to replay the historical event according to a preconfigured history replay mechanism based on the new execution mechanism.

[0010] Optionally, the method further comprises: In response to a change in the code corresponding to the workflow, a version management interface is called to obtain code version information corresponding to the interrupted node; Continue processing the workflow based on the code version information corresponding to the interrupted node.

[0011] According to a second aspect of an embodiment of the present invention, there is provided a workflow recovery device, comprising: An acquisition module, used for acquiring historical events corresponding to the workflow from the historical storage based on the received pause request of the workflow; A replay module is used to replay historical events according to a pre-configured historical replay mechanism to obtain the interruption node corresponding to the workflow; The recovery module is used to monitor that the workflow meets the recovery conditions and return to the interrupted node to continue processing the workflow.

[0012] According to a third aspect of an embodiment of the present invention, there is provided an electronic device, including: one or more processors; a memory for storing one or more programs, When one or more programs are executed by one or more processors, the one or more processors are enabled to implement the method of any of the above embodiments.

[0013] According to a fourth aspect of an embodiment of the present invention, a computer-readable medium is provided, on which a computer program is stored, and when the program is executed by a processor, the method of any of the above embodiments is implemented.

[0014] According to a fifth aspect of an embodiment of the present invention, there is provided a computer program product, including a computer program, which implements the method of any of the above embodiments when the computer program is executed by a processor.

[0015] One embodiment of the above invention has the following advantages or beneficial effects: by obtaining the historical events corresponding to the workflow from the historical storage based on the received workflow pause request; replaying the historical events according to the pre-configured historical replay mechanism to obtain the interruption node corresponding to the workflow; monitoring that the workflow meets the recovery conditions, returning to the interruption node to continue processing the workflow. This embodiment obtains historical events from the historical storage when the workflow is paused, replays based on the historical events, drives the workflow to continue execution from the interruption node, and can automatically and quickly recover after the workflow is interrupted, thereby achieving reentrancy of unexpected workflow failures.

[0016] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with the specific implementation manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] The accompanying drawings are used to better understand the present invention and do not constitute an improper limitation of the present invention. Figure 1 is a schematic diagram of the main process of the workflow recovery method according to an embodiment of the present invention; Figure 2 is a schematic diagram of the main process of a workflow recovery method according to a preferred embodiment of the present invention; Figure 3 A schematic diagram of main modules of a workflow recovery device according to an embodiment of the present invention; Figure 4 is an exemplary system architecture diagram to which embodiments of the present invention may be applied; Figure 5 It is a schematic diagram of the structure of a computer system of a terminal device or a server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION

[0018] The following is a description of exemplary embodiments of the present invention in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0019] It should be noted that the acquisition, storage and application of personal information etc. involved in the embodiments of the present invention are in compliance with the provisions of relevant laws and regulations and do not violate public order and good morals.

[0020] With the rapid development of science and technology, robots are increasingly used in modern society. When robots perform complex tasks, they usually use workflow as a solution. Workflow is a broad concept, including the intelligent interaction process of robots, container orchestration, etc. At present, during the execution of workflows, it is common to encounter situations such as excessive memory interruption of the current task, network communication failure, and execution timeout. After the workflow is interrupted, it cannot be automatically and quickly restored.

[0021] In view of this, according to one aspect of an embodiment of the present invention, a workflow recovery method is provided.

[0022] Figure 1 FIG. 1 is a schematic diagram of the main flow of the task processing method according to an embodiment of the present invention. Figure 1 As shown, the task processing method according to the embodiment of the present invention includes the following steps S101 to S103.

[0023] Step S101: based on the received workflow pause request, obtain the historical events corresponding to the workflow from the history storage.

[0024] Workflow is a process framework for automating business logic. It can manage task execution, dependencies, and resource allocation in a series of predefined steps. It can generally be used in complex business scenarios, such as approval processes, data processing, and task coordination. During the execution of a workflow, a pause request is an execution control instruction used to temporarily suspend the workflow. The pause request includes the workflow's business ID and instance ID to identify the specific workflow instance that needs to be paused. History storage is used to record all events and states that occur during the execution of a workflow, providing a reliable way to persistently store the execution history of a workflow, including task status, timer events, branch paths, and other information. The design of history storage needs to have high performance and high reliability to support the efficient operation and fault recovery of large-scale workflow systems. The history events corresponding to a workflow refer to the event records related to its logic generated during the execution of the workflow. These events include task start, task completion, conditional branch selection, timer triggering, etc. Each history event can contain a timestamp, event type, and related data, etc., which are used to describe the state and behavior of the workflow at a specific moment.

[0025] Specifically, a direct query can be performed based on the event index to obtain the historical events corresponding to the workflow. After receiving the pause request, all events related to the workflow instance in the historical storage are queried based on the key information such as the business identifier and instance identifier in the pause request. This method relies on the index mechanism of the historical storage and can quickly retrieve the target event, which is suitable for the pause and resume scenarios of a single workflow. In addition, queries can also be performed based on time range and condition filtering. When the amount of data recorded in the historical storage is large, the relevant historical events can be filtered out by combining the time range of the workflow (such as the last execution time) and specific conditions (such as the event type is a task or timer event). This method can be used for batch operations or complex query scenarios, for example, pausing multiple workflow instances at the same time. When obtaining the historical events corresponding to the workflow from the historical storage in the above manner, it is necessary to ensure the integrity and consistency of the data so that the subsequent event replay or state recovery can accurately restore the execution process of the workflow and achieve high availability and fault tolerance of the system.

[0026] Step S102: replay the historical events according to the pre-configured historical replay mechanism to obtain the interruption node corresponding to the workflow.

[0027] The historical replay mechanism is a technical strategy for restoring the state of a workflow. It re-executes the historical events of the workflow and rebuilds its state machine so that the workflow can continue to run from the interruption node. This mechanism can accurately simulate the execution process of the workflow, including reproducing the order of task execution, the selection of conditional branches, and the triggering of timers. When configuring the historical replay mechanism, the configuration content includes the type classification of events, the priority strategy of replay, and the error handling rules. For example, you can specify to replay key events first, or configure custom recovery logic for specific types of events. The interruption node corresponding to the workflow refers to the location where the workflow stops running due to an interruption (such as a pause request or system failure) during the execution process. The interruption node marks the pause state of the workflow and the starting point of the unfinished task. In historical replay, by rebuilding the workflow state, you can determine and restore to the interruption node, so as to continue to execute the unfinished part.

[0028] According to the pre-configured historical replay mechanism, historical events are replayed to determine the interruption node. Based on step-by-step event playback, historical events can be executed one by one in the chronological order of events to simulate the execution path of the workflow. When replaying to the interruption event, the workflow engine can detect the unfinished task and mark it as an interruption node. This method is highly accurate. In addition, it is also possible to replay based on key event jumps. By pre-classifying and filtering historical events, only key events directly related to the interruption status, such as timer trigger events or task completion events, are replayed. This method can significantly improve the replay efficiency. During the replay process, it is also necessary to deal with possible inconsistencies between historical events and the current code version, and adapt different logical paths through the version control mechanism to ensure the reliability and correctness of workflow recovery.

[0029] Step S103: monitoring that the workflow meets the recovery condition, and returning to the interruption node to continue processing the workflow.

[0030] Recovery conditions are conditions that trigger the workflow to continue executing from the interrupted node under specific circumstances. These conditions can be defined according to business needs, such as timer expiration, external event triggering, receipt of manual recovery instructions, etc. The setting of recovery conditions needs to balance the real-time nature of the workflow and resource utilization, ensuring that the interrupted workflow can be restored in time without affecting system performance.

[0031] Monitoring whether a workflow meets the recovery conditions can be based on an active polling mechanism to periodically query the state and related conditions of the workflow, such as checking whether the timer has expired or whether the external event has been completed. Monitoring can also be based on an event-driven mechanism. For example, when the timer expires or the external event is completed, a notification is actively triggered to add the workflow that meets the conditions to the recovery queue. This method responds more promptly and uses resources more efficiently. When the workflow meets the recovery conditions, the state machine of the workflow can be directly rebuilt through the historical replay mechanism, and the historical events related to the interrupted node can be replayed one by one from the historical storage; after the replay is completed, the workflow state is pushed to the interrupted node so that it can continue to execute from where it was paused. In addition, in the scenario where the state of the interrupted node is recorded as a snapshot, a jump recovery method can also be used, that is, for a workflow with an interrupted node clearly marked, the snapshot information of the interrupted node can be directly loaded without replaying the complete historical events, which can significantly improve the recovery efficiency.

[0032] The embodiment of the present invention obtains historical events corresponding to the workflow from historical storage based on a received pause request for the workflow; replays the historical events according to a pre-configured historical replay mechanism to obtain the interruption node corresponding to the workflow; monitors that the workflow meets the recovery conditions and returns to the interruption node to continue processing the workflow; this embodiment obtains historical events from historical storage when the workflow is paused, replays based on the historical events, drives the workflow to continue execution from the interruption node, and can automatically and quickly recover after the workflow is interrupted, thereby achieving reentrancy of unexpected workflow failures.

[0033] Optionally, before obtaining historical events corresponding to the workflow from the history storage based on the received workflow pause request, the method further includes: suspending the workflow execution thread corresponding to the workflow in response to receiving the workflow pause request to release system resources occupied by the workflow.

[0034] In this embodiment, the pause request can be captured and parsed through an event monitoring mechanism or an API interface (application programming interface) to determine the specific workflow instance that is paused and its running context information. The workflow engine pauses the currently running workflow thread. Specifically, it can directly call the thread suspension method of the operating system to switch the relevant thread state to the "suspended" state; it can also remove the workflow thread from the current task queue and mark it as suspended through the task scheduler of the workflow engine. At the same time, the current execution state and context information are persisted to the historical storage so that the thread execution state can be correctly rebuilt during the subsequent recovery process. After the suspension operation is completed, the released resources will be allocated by the scheduler to other active workflows or tasks to improve the overall resource utilization of the system. Through this mechanism, the interruption of the workflow and the allocation of resources can be effectively managed, so that efficient operation can be achieved in complex workflow scenarios.

[0035] Optionally, in response to receiving a pause request of the workflow, the method further includes: creating a timer event according to the pause request of the workflow, wherein the timer event includes a current pause time and an expected wake-up time, and persistently storing the timer event in a history storage.

[0036] After receiving a pause request for a workflow, the context data related to the workflow can be parsed from the pause request, including the identification information of the workflow, the execution status when paused, and the specified wake-up conditions (such as time or event triggers). The current system time is obtained as the current pause time, and the expected wake-up time is calculated according to the preset wake-up duration or condition, and this information is combined into a timer event. The structure of the timer event includes the current pause time, the expected wake-up time, the unique identifier of the associated workflow, and other auxiliary information, such as the reason for the pause or priority. After the creation is completed, the timer event can be persisted to the historical storage so that even if the system fails during the pause period, the timer event can still be reloaded and executed after recovery. In addition to this time-based timer event creation method, a distributed timer can also be used to synchronize the timer event to multiple nodes or replicas to ensure that other nodes can take over the timer task when a node fails, thereby improving the fault tolerance and stability of the system.

[0037] Optionally, monitoring that the workflow meets the recovery condition includes: generating a wake-up event in response to the current time reaching the expected wake-up time, so as to return to the interruption node to continue processing the workflow based on the wake-up event.

[0038] When the system runs to the current time and detects that it is consistent with the expected wake-up time in the timer event, the wake-up logic is triggered to generate a wake-up event. First, the status of the timer event is continuously checked through the scheduled task or event listener, and the current time is compared with the expected wake-up time. If the current time is equal to or exceeds the expected wake-up time, the timer event is immediately marked as "expired". The wake-up event is generated based on the information associated with the workflow, including the workflow identifier, wake-up time, context data of the interrupt node, etc. The generated wake-up event can be passed to the workflow engine. After receiving the wake-up event, the workflow engine can load the execution status of the interrupt node from the historical storage, restore the execution pointer to the interrupt node, and continue to process the workflow logic after the interrupt node to improve the integrity and consistency of the business process.

[0039] In addition to the time-based wake-up event generation method, you can also trigger recovery conditions based on external input events, such as relying on the results returned by an external service or notifications of other workflow completion. When these conditions are detected, the corresponding wake-up event is generated and the workflow is restored. You can also use a state monitoring method to continuously monitor the workflow's operating environment or resource status, for example, check whether the task queue has enough resources or whether the waiting external data is ready. Once the conditions are met, a wake-up event is generated and the interrupted workflow is restored.

[0040] Optionally, the method further includes: in response to a system failure occurring before the current time reaches the expected wake-up time, determining a new execution mechanism to replay the historical event according to a preconfigured history replay mechanism based on the new execution mechanism.

[0041] When the system fails before the current time reaches the expected wake-up time, in order to ensure the continuity and data consistency of the workflow, a new execution mechanism needs to be enabled to handle fault recovery. First, the recovery process is triggered after fault detection to determine the new execution mechanism, for example, switching to a redundant execution node or starting a backup workflow engine. The new execution mechanism enables the workflow to continue to execute on different hardware environments or logical instances without affecting the integrity of the process. The new execution mechanism can extract all historical events related to the workflow before the failure from the historical storage. These historical events contain the context data, execution steps, and timer status of the workflow. Based on the pre-configured historical replay mechanism, the new execution mechanism simulates and processes these historical events one by one. During the replay process, when replaying to the time point related to the timer event, if the current time has exceeded the expected wake-up time, the corresponding wake-up event is triggered to advance the execution of the workflow to the logical node after the timer. In this way, the new execution mechanism can not only cope with system failures, but also make the workflow seamless during the replay process and recover to the correct execution state.

[0042] Optionally, the method further includes: in response to a change in the code corresponding to the workflow, calling a version management interface to obtain code version information corresponding to the interrupted node; and continuing to process the workflow based on the code version information corresponding to the interrupted node.

[0043] When the code corresponding to the workflow changes, in order to make the execution logic of the workflow consistent with the changed code version, the version management interface can be called to obtain the code version information corresponding to the interrupt node. The code change event is monitored, and the currently executed workflow instance and the location of the interrupt node are identified in combination with the context information of the workflow. By calling the version management interface (such as fetch Version API), the code version required by the interrupt node can be queried, including the specific code path, version number, and associated dependency information. After obtaining the code version information corresponding to the interrupt node, the processing logic of the workflow is adapted according to the version information. For example, the code module of the corresponding version can be dynamically loaded so that the code behavior matches the current logic requirements. In addition, if the code version contains new parameters or function configurations, these changes can also be parsed to adjust the execution strategy of the workflow. Based on the obtained version information, the workflow continues to be processed from the interrupt node to ensure the accuracy and consistency of workflow execution in the environment after the code change. This dynamic version management mechanism can effectively support the smooth transition of workflows during code iteration, while reducing the operation risks caused by version conflicts.

[0044] According to a preferred embodiment of the present invention, RWS (Robot Workflow Server) can be regarded as a long-running process running on a distributed operating system. The state and scheduling of the process are managed by RWS, and the worker node provides CPU / memory resources to execute the code of the process. In most cases, the workflow instance is run and managed by a worker node and runs like in other ordinary operating systems. But because this is a distributed operating system, the ownership of the workflow can be transferred to other worker nodes and continue to run from the previous state. During the transfer of workflow ownership, non-determinism may occur. The RWS design adopts event tracing design, which means that it persists each change of the workflow state as a historical event instead of the entire workflow state machine. After switching to another worker node, the workflow state machine must be rebuilt. The process of rebuilding the state machine can be called historical replay, and the failure that occurs during the historical replay process is called non-deterministic error.

[0045] Specifically, the RWS history protocol is a history replay process that follows some basic rules / concepts. Close is used to describe the opposite state of open. For activities / transitions, close includes completion, timeout, failure, etc. For workflows, close means completion / timeout / failure / termination / cancellation / new creation, etc.

[0046] The transition is the key to history replay, it drives the progress of the workflow. The three transition forms of the transition state machine are: Scheduled -> Started -> Closed. The first task transition is triggered by the service, and from then on, the rest of the task transitions are triggered by some events in the workflow itself. The following events represent something that the workflow may be waiting for, such as Signaled events, ActivityClose events, SubworkflowClose events, TimerFired events, etc. But ActivityStartedEvent events will not trigger new task transitions. When a task transition starts (internally called in flight), no other events can be written to the history before the task transition is closed. These events will be put into the local buffer until the task transition is closed and the flush buffer will write the event to the history. In execution mode, the task transition will try to complete some entities: scheduled activities / timers / subworkflows, etc. In historical replay mode, the task flow uses all of the above to rebuild the stack. Activities / Timers / Subworkflows will not be re-executed during historical playback, ensuring the efficiency and correctness of the playback.

[0047] The three flow forms of the agreed activity state machine are: Scheduled -> Started -> Closed. The activity is scheduled by Transition Completed. The activity is started by a working node. Usually, ActivityStartedEvent can be placed anywhere in the history, except between TransitionStarted and TransitionClose. But activities with retry policies are a special case, and RWS will only write Started events when the activity is finally closed. The activity is completed / failed by the working node, or timed out by the server, which are all considered activity closures, and if there is no ongoing task flow, it will trigger a new task flow. As above, the ActivityClose event can trigger a task flow.

[0048] The three states of the time agreement state machine are: Scheduled -> Fired / Canceled. The timer is the underlying implementation of sleep and newTimer. It is scheduled by TransitionCompleted and triggered by the server, which can trigger a new task flow. The timer cancellation is controlled by the working node (such as when the workflow is canceled).

[0049] The sub-workflow state machine is Initiated -> Started -> Closed. The sub-workflow is started by TransitionCompleted, which is started by the server (returning the execution instance ID), and may trigger a new task flow. The sub-workflow closing event can be "cancel / failure / completion", which may also trigger a new task flow.

[0050] The external signal / request cancellation state machine is Initiated -> Closed, which are all started by TransitionCompleted. Service close (completion / failure) may trigger a new task flow.

[0051] Locally cache events, when a task flow is in progress, if something like a signal comes in, RWS puts it into the buffer. This is because for the next task flow, the SDK (Software Development Kit) always processes unprocessed events from the completion of the last task flow. No other events can be recorded between the task flow start and close events.

[0052] In the periodic inspection, timed reminder, weekly report and other workflows, a large number of waiting operations with different time granularities will be applied. For this purpose, a lightweight sleep(duration) function is implemented, which is a function used to pause execution for a period of time in the workflow. It can request the workflow engine to pause execution until the specified time interval has passed. The core implementation relies on the event recording and replay mechanism of RWS, so that the workflow can correctly handle failures and recovery during the pause period. The detailed implementation process is as follows: first, initiate a request to RWS to pause the current workflow, and send content including workflowID, runID, etc.; after receiving the sleep event, the RWS service creates a timer event, which records the current time and the expected wake-up time (that is, the current time plus duration); execute the persistent timer event, and the timer event is persisted to the event storage of RWS, so that even if a failure occurs during the workflow execution, the timer event can be reloaded when it is restarted; RWS initiates the suspension of the workflow execution corresponding to the workflowID, the workflow thread is suspended, and the execution resources are released so that other workflows or activities can use these resources; RWS background management previously created timers will initiate wake-up events only when the time point arrives; when the time arrives, the workflow execution is resumed, and RWS resumes the execution of the workflow according to the timer trigger event, and the workflow resumes from sleep(duration) The code after the call continues to execute; if a failure occurs before the timer expires, RWS will check the unfinished timer events when restarting and try to restart the workflow; to restart the workflow, historical events need to be replayed, and all recorded events, including timer events, need to be processed one by one. During replay, the workflow engine simulates the execution of the workflow until the current time is reached. During the replay process, when RWS detects that a timer has expired (that is, the current time exceeds the timer's trigger time), it generates a timer trigger event; the timer trigger event advances the workflow to the execution step after the timer; and the workflow continues to execute.

[0053] Another scenario for interrupted recovery is when new code is launched, which will bring unpredictable situations to the workflow. Some code changes will bring changes to the workflow process, such as the historical events of the currently executed tasks are out of sync with the new code, and the historical replay will fail. To solve this problem, a historical replay mechanism with version control can be used. Specifically, when the workflow code changes, developers can use the fetchVersion API to manage different versions of code paths; fetchVersion provides the default version and the current version, and developers can ensure that during the workflow replay process, the old workflow instance still uses the old version of the logic, while the new workflow instance uses the new version of the logic; fetchVersion will record a version event in the event history, so that when replaying the history, RWS knows which version of the code should be executed.

[0054] Figure 2 FIG. 1 is a schematic diagram of the main process of a workflow recovery method according to a preferred embodiment of the present invention. Figure 2 As shown in the figure, in the workflow system, a timer is used to pause and resume the workflow execution process. In the Worker code, the workflow.sleep(duration) method is called to request to pause the workflow. At this time, the Worker reports the status information to the RWS and requests to create a timer. After receiving the request, the RWS first records the timer event in the event storage (DB), which includes the current pause time and the set wake-up time (that is, the current time plus the duration). After that, the RWS will suspend the current task and release the running resources so that other workflows or activities can use these resources. When the timer expires, the RWS will check the timer event and trigger the wake-up operation to resume the execution of the paused workflow. During the recovery process, the RWS reloads the event through the history replay mechanism, so that the running state of the workflow can be correctly restored when a fault occurs. According to the timer event trigger point, the RWS advances the workflow to the logic after the pause position to continue execution, thereby completing the interruption and recovery of the timer task. Through this mechanism, efficient management and execution scheduling of the workflow are achieved, while ensuring reliable recovery capabilities in the event of faults or interruptions.

[0055] The embodiment of the present invention has distributed fault compatibility and can effectively eliminate the complexity in building scalable distributed applications. By writing workflow code, the maintenance of the system is simplified, and programmers can easily implement the entire workflow process, improve logical integrity and keep the code concise. In addition, the state and history of the workflow are securely stored in the database, and the system can be quickly restored even if a failure occurs. It has good scalability and can seamlessly adapt to the needs of high concurrency and large-scale data processing, improving the stability and efficient operation of the system.

[0056] According to a second aspect of an embodiment of the present invention, a workflow recovery device is provided.

[0057] Figure 3 FIG. 1 is a schematic diagram of the main modules of the workflow recovery device according to an embodiment of the present invention. Figure 3 As shown, the workflow recovery device 300 includes: The acquisition module 301 is used to acquire the historical events corresponding to the workflow from the historical storage based on the received workflow pause request; A replay module 302 is used to replay historical events according to a pre-configured historical replay mechanism to obtain an interruption node corresponding to the workflow; The recovery module 303 is used to monitor that the workflow meets the recovery condition and return to the interruption node to continue processing the workflow.

[0058] Optionally, the recovery device 300 further includes a release module, and the release module is used to: In response to receiving a pause request for a workflow, a workflow execution thread corresponding to the workflow is suspended to release system resources occupied by the workflow.

[0059] Optionally, the recovery device 300 further includes a creation module, and the creation module is used to: A timer event is created according to a pause request of the workflow; wherein the timer event includes a current pause time and an expected wake-up time.

[0060] Persist timer events in history storage.

[0061] Optionally, the recovery module 303 is further used for: In response to the current time reaching the expected wake-up time, a wake-up event is generated, so as to return to the interruption node to continue processing the workflow based on the wake-up event.

[0062] Optionally, the recovery device 300 further includes an update module, and the update module is used to: In response to a system failure occurring before the current time reaches the expected wake-up time, a new execution mechanism is determined to replay the historical event according to a preconfigured history replay mechanism based on the new execution mechanism.

[0063] Optionally, the recovery device 300 further includes a change module, and the change module is used to: In response to a change in the code corresponding to the workflow, a version management interface is called to obtain code version information corresponding to the interrupted node; Continue processing the workflow based on the code version information corresponding to the interrupted node.

[0064] It should be noted that the specific implementation content of the code workflow recovery device of the present invention has been described in detail in the above workflow recovery method, so the repeated content will not be described again here.

[0065] According to a third aspect of an embodiment of the present invention, there is provided an electronic device, comprising: one or more processors; a storage device for storing one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors implement the method provided by the first aspect of the embodiment of the present invention.

[0066] According to a fourth aspect of an embodiment of the present invention, a computer-readable medium is provided, on which a computer program is stored, and when the program is executed by a processor, the method provided by the first aspect of the embodiment of the present invention is implemented.

[0067] According to a fifth aspect of an embodiment of the present invention, a computer program product is provided, including a computer program, and when the computer program is executed by a processor, the method provided by the first aspect of the embodiment of the present invention is implemented.

[0068] Figure 4 An exemplary system architecture 400 is shown to which the workflow recovery method or workflow recovery apparatus according to the embodiment of the present invention can be applied.

[0069] like Figure 4 As shown, system architecture 400 may include terminal devices 401, 402, 403, network 404 and server 405. Network 404 is used to provide a medium for communication links between terminal devices 401, 402, 403 and server 405. Network 404 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc.

[0070] Users can use terminal devices 401, 402, 403 to interact with server 405 through network 404 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 401, 402, 403, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social platform software, etc. (only for example).

[0071] The terminal devices 401 , 402 , and 403 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop computers, and desktop computers.

[0072] The server 405 may be a server that provides various services, such as a backend management server (only an example) that provides support for shopping websites browsed by users using the terminal devices 401, 402, and 403. The backend management server may analyze and process the received data such as the workflow pause request, and feed back the processing result (such as the processing result - only an example) to the terminal device.

[0073] It should be noted that the workflow recovery method provided in the embodiment of the present invention is generally executed by the server 405 , and accordingly, the workflow recovery device is generally disposed in the server 405 .

[0074] It should be understood that Figure 4 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0075] Reference below Figure 5 , which shows a schematic diagram of the structure of a computer system 500 of a terminal device suitable for implementing an embodiment of the present invention. Figure 5 The terminal device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0076] like Figure 5 As shown, the computer system 500 includes a central processing unit (CPU) 501, which can execute various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a storage part 508 into a random access memory (RAM) 503. In the RAM 503, various programs and data required for the operation of the system 500 are also stored. The CPU 501, the ROM 502, and the RAM 503 are connected to each other through a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0077] The following components are connected to the I / O interface 505: an input section 506 including a keyboard, a mouse, etc.; an output section 507 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 508 including a hard disk, etc.; and a communication section 509 including a network interface card such as a LAN card, a modem, etc. The communication section 509 runs a communication process via a network such as the Internet. A drive 510 is also connected to the I / O interface 505 as needed. A removable medium 511, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 510 as needed, so that a computer program read therefrom is installed into the storage section 508 as needed.

[0078] In particular, according to the embodiments disclosed in the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present invention include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program contains program code for running the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 509, and / or installed from the removable medium 511. When the computer program is executed by the central processing unit (CPU) 501, the above-mentioned functions defined in the system of the present invention are executed.

[0079] It should be noted that the computer-readable medium shown in the present invention may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present invention, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. The computer-readable signal medium may also be any computer-readable medium other than a computer-readable storage medium, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0080] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, functions and operations of the system, method and computer program product according to various embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually run basically in parallel, and they can sometimes run in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that runs the specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0081] The modules involved in the embodiments of the present invention may be implemented in software or hardware. The modules described may also be set in a processor, for example, it may be described as: a processor includes an acquisition module, a replay module and a recovery module. The names of these modules do not constitute a limitation on the modules themselves in some cases, for example, the acquisition module may also be described as "a module for acquiring historical events corresponding to a workflow from a historical storage based on a received pause request of the workflow".

[0082] As another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiment; or may exist independently without being assembled into the device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by a device, the device includes: based on the received workflow pause request, obtaining the historical events corresponding to the workflow from the historical storage; replaying the historical events according to the pre-configured historical replay mechanism to obtain the interruption node corresponding to the workflow; monitoring that the workflow meets the recovery condition, returning to the interruption node to continue processing the workflow.

[0083] The computer program product provided by the embodiment of the present invention includes a computer program. When the computer program is executed by a processor, the workflow recovery method in the embodiment of the present invention is implemented.

[0084] The technical solution according to the embodiment of the present invention has the following advantages or beneficial effects: by obtaining the historical events corresponding to the workflow from the historical storage based on the received workflow pause request; replaying the historical events according to the pre-configured historical replay mechanism to obtain the interruption node corresponding to the workflow; monitoring that the workflow meets the recovery conditions, returning to the interruption node to continue processing the workflow. This embodiment obtains historical events from the historical storage when the workflow is paused, replays based on the historical events, drives the workflow to continue execution from the interruption node, and can automatically and quickly recover after the workflow is interrupted, thereby achieving the reentrancy of unexpected workflow failures.

[0085] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

[0086] It should be noted that the acquisition, storage and application of user personal information involved in the technical solution of the present disclosure are in compliance with the provisions of relevant laws and regulations and do not violate public order and good morals.

Claims

1. A workflow recovery method, characterized in that: include: Based on the received workflow pause request, acquiring historical events corresponding to the workflow from the historical storage; Replay the historical events according to a pre-configured historical replay mechanism to obtain an interruption node corresponding to the workflow; It is monitored that the workflow meets the recovery condition, and the process returns to the interruption node to continue processing the workflow.

2. The method according to claim 1, characterized in that Before obtaining the historical events corresponding to the workflow from the historical storage based on the received pause request of the workflow, the method further includes: In response to receiving a pause request for a workflow, a workflow execution thread corresponding to the workflow is suspended to release system resources occupied by the workflow.

3. The method according to claim 2, characterized in that After receiving a request to suspend the workflow, the method further includes: Creating a timer event according to the pause request of the workflow; wherein the timer event includes a current pause time and an expected wake-up time; The timer event is persistently stored in the history storage.

4. The method according to claim 3, characterized in that Monitoring that the workflow meets the recovery condition includes: In response to the current time reaching the expected wake-up time, a wake-up event is generated, so as to return to the interruption node and continue to process the workflow based on the wake-up event.

5. The method according to claim 3, characterized in that: The method further comprises: In response to a system failure occurring before the current time reaches the expected wake-up time, a new execution mechanism is determined to replay the historical event according to a preconfigured history replay mechanism based on the new execution mechanism.

6. The method according to claim 1, characterized in that The method further comprises: In response to a change in the code corresponding to the workflow, calling a version management interface to obtain code version information corresponding to the interruption node; The workflow is continued to be processed based on the code version information corresponding to the interrupted node.

7. A workflow recovery device, characterized in that: include: An acquisition module, configured to acquire, from a history storage, historical events corresponding to the workflow based on a received workflow pause request; A replay module, used to replay the historical events according to a pre-configured historical replay mechanism to obtain an interruption node corresponding to the workflow; The recovery module is used to monitor that the workflow meets the recovery condition and return to the interruption node to continue processing the workflow.

8. An electronic device, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 6.

9. A computer readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

10. A computer program product, comprising a computer program, characterized in that When the computer program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images