Activity workflow-based finished process restarting method and system

Abstract

The invention provides an ended process restarting method and system based on an activity workflow. The method comprises the following steps: recovering historical data in a historical table of a process instance into process data in a running table; supplementing the deleted corresponding execution record information in the process data according to the to-be-handled task; deleting process parameter historical data in the historical table, updating a process state, and generating a process task; and according to business requirements, adding flow operation, and generating a final flow task. According to the method, a workflow triggering mechanism and condition judgment logic are combined, the requirements for flow adjustment and change in actual service application are met, and the service flow use scene is enriched; by supplementing the execution record information of the backup historical data and modifying the running state, the process flexibility is improved, and the working efficiency and the resource utilization rate are improved; the continuity and accuracy of the whole process are ensured by tracking and analyzing the historical data of the finished workflow instance.

Description

Technical Field

[0001] The present invention belongs to the technical field of workflow management. Specifically, it relates to a method and system for restarting an ended process based on the activity workflow. Background Art

[0002] In traditional workflow management, it is difficult to reactivate a process after it ends. When facing new requirements, error correction, or new information, only a new process can be restarted or an imperfect result has to be accepted, resulting in waste of resources and a decline in efficiency. The Activity workflow engine has a wide range of application scenarios in enterprise applications. It can help enterprises standardize business processes, optimize internal management, and improve team collaboration efficiency. Through Activity, enterprises can extract complex business processes and use the specialized modeling language BPMN 2.0 to define the execution process. Then, the business system drives the predefined process execution by accessing the Activity interface. In this way, when the business process changes, enterprises only need to adjust the process definition without modifying the business code, thus greatly improving the development and business capabilities. However, most of the process center functions built based on the activity workflow framework only include basic functions such as process submission, rollback, rejection, and transfer. For process handling in some special scenarios, corresponding handling methods are lacking.

[0003] Currently, many inventions have expanded and improved the process flow scenarios. In the prior art, the patent document "A Workflow Update Method, Device, and Office Platform" (CN117557085A) proposes methods for adding signatures, subtracting signatures, and parallel signature addition during the approval process, expanding the process task flow scenarios. However, for an ended process, there is still a lack of corresponding activation and handling methods.

[0004] The patent document "A General Parameter Configuration Method and System for Activity-Based Workflow" (CN115630835A) discloses that in the context of a microservices architecture, workflow parameters can be flexibly set and uniformly planned without invading the business. However, the main problem it solves is the dynamic configuration and acquisition of dynamic values when the process starts. The main processing logic is in the process startup stage, rather than after the process ends, and the operation processing in the end stage.

[0005] Therefore, there is an urgent need for a method for restarting an ended process based on the activity workflow. Aiming at the problem that it is difficult to reactivate a process after it ends, it provides a new solution for the flexibility and adaptability of the workflow to meet the requirements for process adjustment and change in actual business applications. Summary of the Invention

[0006] Aiming at the defects in the prior art, the purpose of the present invention is to provide a method and system for restarting an ended process based on an activity workflow.

[0007] A method for restarting an ended process based on an activity workflow provided by the present invention includes:

[0008] Step S1: Restore the historical data in the historical table of the process instance to the process data in the running table;

[0009] Step S2: Supplement the corresponding execution record information deleted in the process data according to the to-do tasks;

[0010] Step S3: Delete the process parameter historical data in the historical table, update the process status, and generate process tasks;

[0011] Step S4: According to the business requirements, add process operations to generate the final process tasks.

[0012] Preferably, the step S1 includes:

[0013] Step S1.1: Read the data related to the process from the historical table, including process instance historical data, process task historical data, process parameter historical data, and process approver historical data.

[0014] Step S1.2: Migrate the process-related data from the historical table to the running table and update the corresponding association relationships to form the process data in the running state, including process instance data, process task data, process parameter data, and process approver data.

[0015] Preferably, the execution record information includes the sequence of operation processing, whether there is a countersignature, process definition id, and process instance id.

[0016] The step S2 includes:

[0017] Step S2.1: Generate the execution record information including the parent-child hierarchy relationship id and parentId according to the process data in the historical table.

[0018] Step S2.2: Record the execution record information corresponding to the newly reactivated process instance data in the running table.

[0019] Preferably, the step S3 includes:

[0020] Step S3.1: Modify the process status of the process instance data from the ended state to the running state.

[0021] Step S3.2: Modify the process task data in the running table and change the ended state to the uncompleted state.

[0022] Step S3.3: Update the process parameter data of the running process data according to the process parameter historical data in the historical table, delete the process parameter historical data in the historical table, and generate a process task.

[0023] Preferably, the step S4 includes:

[0024] Step S4.1: The system code automatically judges and compares the currently generated process task with the process task requirements of the business system. If the processing node of the generated process task is consistent with the requirements of the business system, it is considered that the activation is completed and the activation ends. If not, step S4.2 is executed.

[0025] Step S4.2: Modify the process definition id in the running table to the temporarily modified process definition id, set the processing node of the process task to the node required by the business system, submit the process to generate the final process task, and run the process.

[0026] Step S4.3: Set the temporarily modified process definition id to the actual process definition id.

[0027] According to the present invention, a restart system for an ended process based on an activity workflow is provided, including:

[0028] Module M1: Restore the historical data in the historical table of the process instance to the process data in the running table;

[0029] Module M2: Supplement the corresponding execution record information deleted in the process data according to the to-do tasks;

[0030] Module M3: Delete the process parameter historical data in the historical table, update the process status, and generate a process task;

[0031] Module M4: Add process operations according to business requirements to generate the final process task.

[0032] Preferably, the module M1 includes:

[0033] Module M1.1: Read the data related to the process from the historical table, including process instance historical data, process task historical data, process parameter historical data, and process approver historical data.

[0034] Module M1.2: Migrate the data related to the process from the historical table to the running table, and update the corresponding association relationships to form the process data in the running state, including process instance data, process task data, process parameter data, and process approver data.

[0035] Preferably, the execution record information includes the sequence of operation processing, whether there is a countersignature, the process definition id, and the process instance id.

[0036] The module M2 includes:

[0037] Module M2.1: Generate execution record information containing parent-child hierarchy relationship IDs and parent IDs based on the process data in the history table.

[0038] Module M2.2: Record the execution record information corresponding to the newly added and reactivated process instance data in the running table.

[0039] Preferably, the module M3 includes:

[0040] Module M3.1: Modify the process status of the process instance data from the end status to the running status.

[0041] Module M3.2: Modify the process task data in the running table and change the end status to the uncompleted status.

[0042] Module M3.3: Update the process parameter data of the running process data according to the process parameter historical data in the history table, delete the process parameter historical data in the history table, and generate a process task.

[0043] Preferably, the module M4 includes:

[0044] Module M4.1: The system code automatically judges and compares the currently generated process task with the process task requirements of the business system. If the processing node of the generated process task is consistent with the requirements of the business system, it is considered that the activation is completed and the activation ends. If not, module M4.2 is triggered.

[0045] Module M4.2: Modify the process definition ID in the running table to the temporarily modified process definition ID, set the processing node of the process task to the node required by the business system, submit the process to generate the final process task, and run the process.

[0046] Module M4.3: Set the temporarily modified process definition ID to the actual process definition ID.

[0047] Compared with the prior art, the present invention has the following beneficial effects:

[0048] 1. The present invention combines the work process trigger mechanism and the conditional judgment logic, provides a new solution for the flexibility and adaptability of the work process, meets the requirements for process adjustment and change in actual business applications, and enriches the usage scenarios of business processes.

[0049] 2. The present invention solves the problem that it is difficult to reactivate the process after the process ends by supplementing the execution record information of the backup historical data, modifying the running status, increases the process flexibility, and improves the work efficiency and resource utilization rate.

[0050] 3. Through the tracking and analysis of the historical data of the workflow instances that have ended, the present invention ensures that the reactivated workflow can accurately continue the previous state and make reasonable adjustments, guaranteeing the coherence and accuracy of the entire process. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] Other features, objects, and advantages of the present invention will become more apparent by reading the following detailed description of non-limiting embodiments with reference to the accompanying drawings:

[0052] Figure 1 Schematic flowchart of the method for reactivating an ended process;

[0053] Figure 2 Overall functional schematic diagram of the process center. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0054] The present invention will be described in detail below with reference to specific embodiments. The following embodiments will help those skilled in the art to further understand the present invention, but do not limit the present invention in any form. It should be noted that those of ordinary skill in the art can make several changes and improvements without departing from the concept of the present invention. These all fall within the protection scope of the present invention.

[0055] For the scenario of reactivating a process and performing subsequent processing after the process ends, after analyzing the data changes in each table during the process from running to ending after submitting the process in the activity process framework, a reverse derivation of the entire logic is performed. According to a method for restarting an ended process based on the activity workflow provided by the present invention, it is used to implement the process of reverting from the ended state to the running state. Taking Figure 1 as an example, it includes:

[0056] Step S1: Restore the backed-up historical data to the data in the running state. After the process instance runs to completion, the data will be automatically backed up to the historical table. At this time, the data needs to be extracted from the historical table and restored to the data in the running table to meet the requirements of subsequent process processing.

[0057] All operations involve operations on the data in the database tables. Extracting data means reading historical data from the historical table to find the historical data required by the process instance.

[0058] The tables related to the process instance are divided into tables in the running state, that is, the running table, and the historical data table, that is, the historical table. After the process instance ends, the relevant data will be archived and saved to the corresponding historical table, and the data in the running table will be deleted. If an ended process needs to be reactivated and used, the data in the historical table needs to be read and transferred to the tables in the running state so that it can continue to flow.

[0059] The step S1 includes the following steps:

[0060] Step S1.1: Read data related to the process from the process history table, covering process instance history data, process task history data, process parameter history data, and process approver history data.

[0061] These data are the core data for process flow. Starting from the process definition, each time a process definition is started, a process instance and related process parameters will be generated, one or more process to-do tasks will be generated, and each to-do task corresponds to an approval handler one by one. All of these will have approval history records, and the entire process will be recorded in relevant tables. Therefore, it is necessary to read process instances, process tasks, process parameters, and process approvers from these tables. The process-related data in the history table is historical data.

[0062] Step S1.2: Migrate the data in Step S1.1 from the history table to the running table and restore it to the process data in the running state. This restoration process needs to migrate process instance history data, process task history data, process parameter history data, and process approver history data to the running process instance table and update the corresponding association relationships.

[0063] Step S2: Supplement the missing information of the process. After the process runs to completion, the execution record information will be deleted. When reactivating an ended process, this part of the missing information needs to be supplemented to ensure the continuous flow of the process.

[0064] The activity framework determines to delete the execution record information after the process is completed. The purpose is to archive the data related to the ended process, reduce the data in the running state, and improve the query performance.

[0065] The execution record information is mainly used to record information such as the sequence of operations, whether there is a joint signature, process definition id, process instance id, etc. during the approval process of multiple to-do tasks corresponding to a process instance. Each to-do task will have corresponding execution record information. Therefore, the execution record information is restored one-to-one according to the process task data in the history table.

[0066] The said Step S2 includes the following steps:

[0067] Step S2.1: Supplement the missing execution record information of the process task. Generate execution records including parent-child levels, that is, execution record information, according to the process task data to ensure that each task processing process has corresponding execution records. The lack of execution record information will affect the normal flow of the process.

[0068] The execution records of the parent-child hierarchy are mainly used to record the sequence of to-do task processing operations (corresponding one-to-one with the to-do tasks). Each execution record contains an id and a parentId, and a tree structure of the parent-child hierarchy is constructed through these two values.

[0069] The content of the parent-child hierarchy records is similar, all containing information such as whether there is a countersignature, process definition id, process instance id, etc. The difference is that the values of the id and parentId of the parent-child hierarchy relationship are different.

[0070] The id in the execution record is unique, which is used to ensure the uniqueness of the data and will not be repeated. And the unique id can locate the unique data for related operations such as deletion or supplementation.

[0071] Step S2.2: Add an execution operation record for reactivating the process instance. When reactivating an ended process, record the operation process at this time for process auditing.

[0072] Step S3: Delete redundant process data and update the relevant process status. After the above steps S1 and S2, there will be redundant process data that needs to be deleted. At the same time, update the relevant process status to support the continuous flow after the process is activated.

[0073] The redundant data mainly targets the historical data table. After the process instance is reactivated, it is necessary to clean up the process parameter information saved in the historical data table and add the corresponding process parameter information after activation.

[0074] The step S3 includes the following steps:

[0075] Step S3.1: Modify the process status in the process instance table from the ended status to the running status.

[0076] Step S3.2: Modify the process task data in the process task table and change the ended status to the uncompleted status.

[0077] Step S3.3: Update the process parameters of the running process instance according to the historical process parameters of the process instance.

[0078] Step S4: Perform additional process operations until the process tasks meet the requirements of the business system. After an ended process is reactivated, process tasks will be generated. By default, the process tasks are assigned to the last process node. At this time, it is necessary to analyze the business requirements to see if additional processing is required.

[0079] The step S4 includes the following steps:

[0080] Step S4.1: The system code automatically determines and compares the process tasks generated in the current process with the process task requirements of the business system. If the requirements are met, the current operation can be ended and the current activation process is completed. If the requirements are not met, the subsequent operation steps are continued.

[0081] What is mainly verified here is whether the information of the processing node of the generated process to-do task after the process instance is activated is consistent with the requirements of the business system. When the user operates to activate the process, they need to select which node to restart to after activation, which is used as the judgment basis for whether to continue jumping after the process is activated. If it is already the specified node after activation, the entire activation process can be ended. If the specified node has not been reached, further jumping is still required.

[0082] Step S4.2: Temporarily modify the process definition, set the node where the process flows to the target node required by the business system, and then execute the process submission operation to generate the final process task.

[0083] Step S4.3: Change the temporarily modified process definition back to the original actual process definition.

[0084] After a terminated process is re-activated, since it is re-activated based on the historical approval process, it can only be restored to the last approved node. At this time, if the business only requires reaching the last approved node and meets the requirements, the process definition will not be modified. However, if the business requirements are not met, the process definition needs to be modified twice. This modification is only temporarily modified in memory and will not be actually saved to the database table. Because the initial process definition does not have a reverse jump line, it is not possible to directly jump to the target approval node according to the initial process definition. Therefore, it is necessary to first temporarily modify the process definition, run the process according to the temporary process definition, and then restore the temporary process definition to the original initial process definition. In this way, the process processing path not included in the process definition is realized. Restoring the temporarily modified process definition to the initial process definition, that is, the actual process definition, is to ensure that the initial process definition remains unchanged and avoid affecting other process instances.

[0085] Figure 2 The functional diagram of the process center is shown, and the main functions of each module are clarified, as well as the position of the present invention in the entire process center function system, which is the business process definition module. The process definition is realized by dragging, pulling, and configuring through the designer, and then the process definition is operated through relevant interfaces to execute operations such as starting the process, generating process instances and process to-dos, ending process instances and process to-dos.

[0086] The present invention also provides a restart system for an ended process based on the activity workflow. The restart system for an ended process based on the activity workflow can be implemented by executing the process steps of the restart method for an ended process based on the activity workflow. That is, those skilled in the art can understand the restart method for an ended process based on the activity workflow as a preferred embodiment of the restart system for an ended process based on the activity workflow.

[0087] According to the present invention, a restart system for an ended process based on the activity workflow is provided, including:

[0088] Module M1: Restore the historical data in the historical table of the process instance to the process data in the running table;

[0089] Module M2: Supplement the corresponding execution record information deleted from the process data according to the to-do tasks;

[0090] Module M3: Delete the process parameter historical data in the historical table, update the process status, and generate process tasks;

[0091] Module M4: Add process operations according to business requirements to generate final process tasks.

[0092] In more preferred examples, the module M1 includes:

[0093] Module M1.1: Read the data related to the process from the historical table, including process instance historical data, process task historical data, process parameter historical data, and process approver historical data.

[0094] Module M1.2: Migrate the process-related data from the historical table to the running table and update the corresponding association relationships to form the process data in the running state, including process instance data, process task data, process parameter data, and process approver data.

[0095] In more preferred examples, the execution record information includes the sequence of operation processing, whether there is a countersignature, process definition id, and process instance id.

[0096] The module M2 includes:

[0097] Module M2.1: Generate execution record information including parent-child hierarchy relationship id and parentId according to the process data in the historical table.

[0098] Module M2.2: Record the execution record information corresponding to the newly reactivated process instance data in the running table.

[0099] In more preferred examples, the module M3 includes:

[0100] Module M3.1: Modify the process status of the process instance data from the end status to the running status.

[0101] Module M3.2: Modify the process task data in the running table, changing the end status to the unfinished status.

[0102] Module M3.3: Update the process parameter data of the running process data according to the process parameter historical data in the historical table, delete the process parameter historical data in the historical table, and generate a process task.

[0103] In more preferred examples, the module M4 includes:

[0104] Module M4.1: The system code automatically judges and compares the currently generated process task with the process task requirements of the business system. If the processing node of the generated process task is consistent with the requirements of the business system, it is considered that the activation is completed and the activation ends. If not, module M4.2 is triggered.

[0105] Module M4.2: Modify the process definition id in the running table to the temporarily modified process definition id, set the processing node of the process task to the node required by the business system, submit the process to generate the final process task, and run the process.

[0106] Module M4.3: Set the temporarily modified process definition id to the actual process definition id.

[0107] Those skilled in the art know that in addition to implementing the system and its various devices, modules, and units provided by the present invention in the form of pure computer-readable program code, the method steps can be logically programmed to enable the system and its various devices, modules, and units provided by the present invention to be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers, etc. to achieve the same function. Therefore, the system and its various devices, modules, and units provided by the present invention can be regarded as a kind of hardware component, and the devices, modules, and units included therein for implementing various functions can also be regarded as the structures within the hardware component; the devices, modules, and units for implementing various functions can also be regarded as both software modules for implementing the method and the structures within the hardware component.

[0108] The specific embodiments of the present invention have been described above. It should be understood that the present invention is not limited to the above specific embodiments, and those skilled in the art can make various changes or modifications within the scope of the claims, which does not affect the essence of the present invention. Without conflict, the embodiments of the present application and the features in the embodiments can be combined with each other arbitrarily.

Claims

1. A method for restarting a finished process based on activity workflow, characterized in that: include: Step S1: restore the historical data in the history table of the process instance to the process data in the running table; Step S2: supplementing the corresponding execution record information deleted in the process data according to the pending tasks; Step S3: Delete the process parameter history data in the history table, update the process status, and generate the process task; Step S4: Add process operations according to business needs and generate final process tasks.

2. The method for restarting a finished process based on an activity workflow according to claim 1, characterized in that: The step S1 comprises: Step S1.1: Read process-related data from the history table, including process instance history data, process task history data, process parameter history data, and process approver history data; Step S1.2: Migrate process-related data from the history table to the running table, and update the corresponding association relationships to form running process data, including process instance data, process task data, process parameter data, and process approver data.

3. The method for restarting a finished process based on an activity workflow according to claim 1, characterized in that: The execution record information includes the order of operation processing, whether there is a countersignature, the process definition ID and the process instance ID; The step S2 comprises: Step S2.1: Generate execution record information including parent-child hierarchical relationship id and parentId according to the process data in the history table; Step S2.2: Record the execution record information corresponding to the newly added reactivated process instance data in the running table.

4. The method for restarting a finished process based on an activity workflow according to claim 1, characterized in that: The step S3 comprises: Step S3.1: modify the process state of the process instance data from the end state to the running state; Step S3.2: Modify the process task data in the run table and change the end status to an unfinished status; Step S3.3: Update the process parameter data of the running process data according to the process parameter history data in the history table, delete the process parameter history data in the history table, and generate a process task.

5. The method for restarting a finished process based on activity workflow according to claim 1, characterized in that: The step S4 comprises: Step S4.1: The system code automatically determines and compares the currently generated process task with the process task requirements of the business system. If the processing node of the generated process task is consistent with the requirements of the business system, the activation is considered to be completed and the activation is terminated. If not, step S4.2 is executed; Step S4.2: Modify the process definition id in the running table to the temporarily modified process definition id, set the processing node of the process task to the node required by the business system, submit the process to generate the final process task, and run the process; Step S4.3: Set the temporarily modified process definition id as the actual process definition id.

6. A system for restarting a finished process based on activity workflow, characterized in that: include: Module M1: restore the historical data in the history table of the process instance to the process data in the running table; Module M2: Supplement the corresponding execution record information deleted in the process data according to the pending tasks; Module M3: Delete the process parameter history data in the history table, update the process status, and generate process tasks; Module M4: Add process operations according to business needs and generate final process tasks.

7. The activity workflow-based ended process restart system according to claim 6, characterized in that: The module M1 comprises: Module M1.1: Read process-related data from the history table, including process instance history data, process task history data, process parameter history data, and process approver history data; Module M1.2: Migrate process-related data from the history table to the running table, and update the corresponding association relationships to form running process data, including process instance data, process task data, process parameter data, and process approver data.

8. The ended process restart system based on activity workflow according to claim 6, characterized in that: The execution record information includes the order of operation processing, whether there is a countersignature, the process definition ID and the process instance ID; The module M2 comprises: Module M2.1: Generate execution record information including parent-child hierarchical relationship id and parentId according to the process data in the history table; Module M2.2: Record the execution record information corresponding to the newly added reactivated process instance data in the run table.

9. The ended process restart system based on activity workflow according to claim 6, characterized in that: The module M3 comprises: Module M3.1: Modify the process state of the process instance data from the end state to the running state; Module M3.2: Modify the process task data in the run table and change the end status to the unfinished status; Module M3.3: Update the process parameter data of the running process data according to the process parameter historical data in the history table, delete the process parameter historical data in the history table, and generate a process task.

10. The ended process restart system based on activity workflow according to claim 6, characterized in that: The module M4 comprises: Module M4.1: The system code automatically judges and compares the currently generated process task with the process task requirements of the business system. If the processing node of the generated process task is consistent with the requirements of the business system, the activation is considered to be completed and the activation is terminated. If not, module M4.2 is triggered; Module M4.2: Modify the process definition ID in the running table to the temporarily modified process definition ID, set the processing node of the process task to the node required by the business system, submit the process to generate the final process task, and run the process; Module M4.3: Set the temporarily modified process definition id to the actual process definition id.

Images