CN115187073A - Process recovery method under workflow engine - Google Patents

Abstract

The invention provides a process recovery method under a workflow engine, which relates to the field of workflow engine management and comprises the following steps: managing the process recovery authority, controlling personnel executing the process recovery operation and controlling a process recovery node; managing flow recovery time, wherein personnel executing flow recovery operation can only recover the flow within a specified time range; the invention relates to a method for managing a flow recovery mechanism, which comprises the steps of managing the flow recovery mechanism, executing a next node according to a flow definition after a previous node is executed during flow recovery, and sequentially progressing.

Description

Process recovery method under workflow engine

Technical Field

The invention relates to the field of workflow engine management, in particular to a flow recovery method under a workflow engine.

Background

The workflow engine is a common basic component in the information application based on the process, defines a specific process, enables the business processing process to be executed according to a set process, and can enter the next process node after the user processing is finished at a certain process node and execute the processes in sequence until the process is finished.

The workflow engine supports modes such as sequence, branch and multi-path branch parallel, the processing node supports common operations such as single examination and approval and multi-person signing, and through the workflow engine, developers do not need to pay attention to flow control in the development process of the business system, and only need to put the research and development work into the realization of the business flow.

Various common workflow engines support specific flow business execution according to flow nodes, and on a certain node, a current node processor backs the flow support, and if the current node processor considers that the flow cannot be continued, the flow can be backed to the previous node or a node at the previous level for reprocessing. However, the current workflow engine does not support the process recovery technology, when the process reaches the designated processing node according to the definition of the workflow engine, the flow initiator or the processing person at a certain node in front cannot recover the process, and the process is returned to the starting point or the certain node in front of the current node, and only the current processing person returns step by step, which is very inconvenient in actual operation.

Disclosure of Invention

The present invention provides a method for recovering a workflow process under a workflow engine, so as to solve the above technical problems.

In order to solve the technical problems, the invention adopts the following technical scheme: a process recovery method under a workflow engine comprises the following steps:

managing the process recovery authority, controlling personnel executing the process recovery operation and controlling a process recovery node;

managing flow recovery time, wherein personnel executing flow recovery operation can only recover the flow within a specified time range;

managing a flow recovery mechanism, wherein when the flow is recovered, after the previous node is executed, the next node is executed according to the flow definition, the steps are sequentially carried out, during the recovery period, a person executing the flow recovery operation can withdraw the flow to the appointed node, and for this reason, the flow node which is already completed needs to be rolled back, so that the state of the flow is recovered to the previous state;

flow recovery node record management, wherein flow recovery needs to record each processing node of the flow;

and (3) process recovery monitoring, wherein the recovery monitoring is carried out in an asynchronous mode, after the recovery execution is finished, a monitoring request is sent in a message form, the message is managed in a queue form, the message is read from the message queue through a new thread and the content of the message is stored, and when the message has a problem, a process monitoring alarm is sent to related business personnel.

Preferably, in the process recovery authority management, the process recovery personnel is controlled to design the process recovery authority according to different roles, and the authority constraint content comprises a recoverable node, recovery time constraint, the number of recovery return nodes and a recovery range.

Preferably, in the process recovery authority management, the process recovery node controls and can set a node which can be recovered by the process according to the role of the user.

Preferably, in the process recovery time management, if the user exceeds the recovery time, the current process node cannot be recovered.

Preferably, in the process of flow recovery time management, a background event monitoring mechanism is provided for the recovery time of the node, a flow recovery request triggers the corresponding event monitoring mechanism, and in the event processing process, according to the time rule configured by the flow node, if the time rule configuration is not met, the recovery of the flow node is rejected.

Preferably, in the process recycling mechanism management, in order to ensure the integrity of the rollback operation, the system adopts a command mode, and records and stores each process node and the operation executed by the node in the form of a command object.

Preferably, the command mode is a data-driven design mode, and belongs to a behavioral mode, and the command object includes a do method and an undoo method, which respectively complete the execution of the command and the command withdrawal function.

Preferably, in the process recovery node record management, the nodes involved in recovery are rolled back in sequence, and the system adopts the nodes recovered by the stack team to manage.

Preferably, in the process recovery node record management, after each execution of a process node is completed, the system puts the current node on the stack, and when the recovery operation is performed, sequentially pops out each node from the stack, executes the undoo operation of the relevant command of the node, and completes the rollback of the node transaction.

The invention has the beneficial effects that:

1. in the invention, after a user designs a flow according to a service condition, a flow engine drives flow nodes to execute according to a specified sequence, a current node user can retreat the flow nodes to the previous node according to needs, but the retreat operation can only be initiated by the current node user, a flow recovery mechanism is provided, the finished node user can withdraw the flow, and the processing means of the flow is more flexible.

2. When the process recovery mechanism is not available, if the process recovery mechanism needs to be carried out, the process can be returned only by a processor of the process node, and the process can be returned to the previous step, if the process needs to be returned continuously, the former node processor needs to receive the return, further return and return to the previous processing node, and through the process recovery mechanism, a user with authority can recover the process to a certain specified node and does not need to return step by step, so that the process processing mechanism of the process can be more efficient.

3. Under a recovery mechanism of a workflow engine, a command mode is adopted to abstract nodes of business processing, an object serialization technology is utilized to locally store the nodes and commands related to the nodes, and when the nodes are recovered, the nodes which are already finished can be deserialized from the local storage, so that the integrity of flow recovery operation is ensured, and the reliability of the business processing is further improved.

Drawings

FIG. 1 is a schematic diagram of process recovery model authority in the present invention;

FIG. 2 is a schematic diagram of a process flow of rights recovery in the present invention;

FIG. 3 is a schematic diagram of a node control flow for process recovery according to the present invention;

FIG. 4 is a diagram of a domain-dependent recycling time management model according to the present invention;

FIG. 5 is a schematic diagram of a node recovery time monitoring model according to the present invention;

FIG. 6 is a schematic diagram of a process recovery mechanism domain model in accordance with the present invention;

FIG. 7 is a diagram illustrating stack operation during flow recovery in the present invention;

FIG. 8 is a schematic diagram of a process recovery monitoring module according to the present invention;

FIG. 9 is a diagram of a rights management object model in accordance with the present invention;

FIG. 10 is a schematic diagram of a proxy model of the present invention;

FIG. 11 is a schematic diagram of the engine controlled reversal of the process of the present invention;

Detailed Description

The present invention will be further described with reference to the following detailed description and the accompanying drawings, which are provided for the purpose of illustrating the invention and are not intended to limit the invention to the particular embodiments disclosed. Other embodiments obtained by persons skilled in the art without making creative efforts based on the embodiments in the implementation belong to the protection scope of the invention.

Specific embodiments of the present invention are described below with reference to the accompanying drawings.

Example 1

The embodiment provides a flow recovery method under a workflow engine, which comprises recovery authority management, recovery time management, recovery mechanism management, recovery node recording and recovery monitoring;

1) Recycling rights management

The center of the process recovery method needs to manage the recovery authority of the process, and the design of the authority comprises two aspects: executing personnel control of the process recovery operation and node control of the process recovery;

the system can control personnel for process recovery through roles and can design process recovery authorities aiming at different roles, wherein the constraint content of the authorities comprises recoverable nodes, recovery time constraint, the number of recovery returned nodes and a recovery range, and a domain model for authority recovery is shown as 1;

the following describes the relevant contents of fig. 1:

user: the user model comprises a user identifier, a user account, a user name and a password;

department: a department model, to which a user may belong;

duty: the system comprises a job model, a task module and a task management module, wherein the job model is the job played by a user under a department, and the job is associated with a specific flow result;

FlowDefine: the process definition model comprises the name of the process and the state of the process definition;

flownode: the process node model comprises the names of nodes, a previous node and a next node;

FlowInstance: a process instance model;

role: the role model defines roles capable of executing flow recovery, and controls the authority of flow recovery through the roles, so that a user belongs to a certain role;

RolePurview: and the role authority model comprises recoverable nodes, recovery time constraints, the number of recovery return nodes and a recovery range.

The system processing flow for recovering authority is shown in fig. 2, and the following description is made with respect to fig. 2:

(1) reading a corresponding process example according to the business rule;

(2) judging whether the process example is finished or not through a Status field of the process example;

(3) if the process is not finished, inquiring the process definition according to the process example, acquiring the process node according to the process definition, and further inquiring the current node of the process;

(4) judging whether the user has a recovery authority or not according to the role of the current process user, if the user can execute the process recovery, further judging whether the current process node is in the recovery time range, and if the current process node is in the recovery time range, executing the process recovery;

(5) according to the role to which the user belongs and the authority corresponding to the role, the user can select the recovery process to the designated node.

For the node control of the process recovery, please refer to fig. 3, when the system executes the process recovery, the system may control the node of the process recovery, and may set the node that the process can recover according to the role of the user, for example, the previous node of the current node of the process recovery may be set, and may also set the node that the process recovery starts.

2) Recovery time management

As shown in fig. 4, in a workflow recovery operation, the recovery time of a job must be managed, the time range of the job recovery can be clarified, a user can only recover a flow within a specified time range, and if the recovery time is exceeded, a current flow node cannot be recovered.

The following describes the relevant contents of fig. 4:

NodeConfig: a process node configuration object, which sets relevant configuration information aiming at the process node;

TimeRule: a process recovery time rule abstract class;

DateRule: configuring recycling time according to date, supporting the starting date and time and the ending date and time of recycling;

WeekRule: configuring recovery time according to weeks, and supporting the recovery of the flow from the days of the week to the days of the week;

HalfMonthRule: configuring date recovery time according to half a month as a time node;

MonthRule: and configuring date recovery time according to the month as a time node, and supporting the setting of the recovery time from a number of each month to a number of each month.

For the recovery time of the node, the system provides a background event monitoring mechanism, the process recovery request triggers the corresponding event monitoring mechanism, in the event processing process, according to the time rule configured by the process node, if the configuration of the time rule is not satisfied, the recovery of the process node is rejected, and the process recovery time monitoring model is as shown in fig. 5:

the following describes the related contents in fig. 5:

FlowEngine: the workflow engine class is used as a global workflow scheduling class and comprises all process nodes and process node instances needing to be monitored;

FlowObserve: in the process monitoring interface, all detected objects must realize an Update method in the interface, and when the state of a process instance changes, a process engine informs the related monitored process node instance according to a time rule to start monitoring practice;

FlowNodeInstance: flow node instances representing specific flow node instances, the classes implementing FlowObserve interfaces;

FlowInstance: and the process instance has own state, is registered in the process engine when the process engine is started, and triggers an event in the related monitoring node after the state of the process instance is changed.

3) Reclamation mechanism management

In the process of process recovery, a process recovery mechanism is managed, in the process of process, after the previous node is executed, the next node is executed according to the process definition, and the process is sequentially advanced, when the process is recovered, an initiator of the process can withdraw the process to a designated node, so that the process node which has completed is required to be rolled back, so that the state of the process is restored to the previous state, in order to ensure the integrity of the rolling back operation, the system adopts a command mode, and records and stores the operation executed by each process node and node in the form of a command object, wherein the command mode is a data-driven design mode and belongs to a behavioral mode, the command object comprises a do method and an undo method, and the execution of the command and the undo function of the command are respectively completed, and a related domain model is shown in fig. 6:

the following describes the relevant contents in fig. 6:

an observer: the Command calling class completes the management of a group of Command through a plurality of ICommand interfaces;

node Command: the abstract parent class of the node command comprises the public attribute of the command and the default realization of a do method and an undoo method;

checkCommand: single audit command class;

MutilCheckCommand: a multi-person review command class;

flownode: a process node class, which completes the definition of the process node;

FlowNodeInstance: the flow node instance class provides a Save method, and can store the flow nodes in a serialization way, wherein the flow node instance comprises commands executed by the flow instance nodes, and the commands corresponding to the flow instances are stored in the serialization way.

4) Recycle node record management

In order to ensure that the process recovery can be completed without errors, each processing node of the process needs to be recorded, nodes related to recovery need to be rolled back in sequence during recovery, and the system adopts the nodes recovered by the stack team for management. The method is a linear table with limited operation, and is limited to perform insertion and deletion operations only at the tail of the table.

After the flow node is executed, the system pushes the current node onto the stack, when the recovery operation is executed, each node is sequentially popped from the stack, the unDo operation of the relevant command of the node is executed, the rollback of the node transaction is finished, and the stack pushing and popping operations are shown in fig. 7, referring to the content of fig. 7, by using a special data structure of the stack, the nodes of the flow can be rolled back according to the execution sequence, and the integrity of the flow recovery operation is ensured.

5) Recovery monitoring

The system monitors flow recovery, ensures that the recovery process of recovery can be traced and audited, adopts an asynchronous mode for flow recovery monitoring, sends a monitoring request to a recovery monitoring module in a message form after recovery execution is finished, the monitoring module manages messages in a queue form, reads the messages from a message queue through a new thread, stores the contents of the messages, and sends a flow monitoring alarm to related business personnel when a problem exists in the current messages, wherein the system processing mode is as shown in fig. 8.

The process of the process recovery monitoring module is as follows:

(1) after the process engine finishes the process recovery, the process engine sends a process recovery message to the message gateway;

(2) after receiving the message, the message gateway sends the message to a corresponding message queue according to the type of the message;

(3) after receiving the message, the message queue triggers an event of arrival of a new message, and after capturing the triggered event, the message receiving engine reads the unprocessed message from the message queue;

(4) the message engine pushes the unprocessed message to a service module for processing, and the service module firstly stores the message;

(5) after the message is successfully stored, the message processing module reads the alarm rule from the alarm rule base, studies and judges the message according to the alarm rule, and triggers an alarm process if the message needs to be alarmed.

Example 2

In this embodiment, a method for recovering a process under a workflow engine is provided, in which core contents include an authority management model, a process dynamic proxy, a process engine control inversion, and a process scripting language interpretation;

1) Rights management model

The authority management model for process recovery divides the authority management into four parts of users, roles, resources and operations, wherein the users belong to one or more roles, the roles are distributed with a plurality of resources, and the related operations are distributed aiming at the resources under the roles, and the structure diagram of the authority model is shown in fig. 9;

the following describes the relevant contents in fig. 9:

the user: users are affiliated with one or more roles;

role: the role is a carrier of authority, and an authority model of the role is established by allocating resources for the role and performing executable operation under the resources;

resource: abstractions of objects available in the system;

the operation is as follows: and specific business operations such as approval, review, revocation and the like.

2) Process dynamic proxy

The proxy technology is that a specific operation is forwarded to a proxy object through an object, and the proxy object completes the specific operation, and the structure of a proxy mode is shown in fig. 10;

the following describes the relevant contents in fig. 10:

and (3) a Client: the client object calls a Run method of the Server object;

server: receiving a request of a client, executing related operation, wherein the Server does not execute specific operation but delivers the operation to a proxy class inherited from the Subject abstract class to complete the operation;

subject: the specific proxy class inherits the abstract class to complete the specific operation;

proxy: the proxy class that completes the specific operation.

The agent technology can realize the flexibility of the system, the concrete processing of the system is completed by the agent class, and the agent class can be replaced according to the actual condition as long as the agent class meets the interface requirement of the agent, thereby completing the flexible configuration of the system.

At present, java agents are mainly static agents, the establishment of agent objects is already completed during system coding, flow definition needs to set a flow according to actual service conditions and execute the revocation of the flow, and therefore, when the flow is recycled, a dynamic agent mechanism is adopted, dynamic agent objects are dynamically loaded according to the flow definition during the starting of a flow engine through a Java reflection technology and an object pool technology, and the dynamic processing of flow revocation nodes can be completed according to needs.

3) Process engine control reversal

The process engine control reversal refers to that the calling of the business object is transferred from a user side to the process engine to be called, and the process engine completes the initialization of the business component and the calling of the business component when necessary according to the defined process script. The user component realizes specific business processing, and the process engine connects the business components in series through control reversal and controls the execution of the business components through the process engine. The processing mode of the process engine control inversion is shown in fig. 11, and the process engine must adopt the control inversion technology, so that the process engine can drive the service to realize the recovery of the process.

4) Process scripting language interpretation

The workflow engine mainly determines specific business flow and flow recovery through the analysis of the flow scripting language, so that in order to realize flexible self-defined flow, an interpretation function of the flow scripting language must be provided.

The flow scripting language adopts JSON as a basic data format definition, the JSON is a lightweight data exchange format, in order to ensure the expandability of the flow, the support for JavasScript scripting language is embedded in the flow scripting language analysis, the programmability of a certain link can be realized through JavaScript, and a user-defined processing process is added to the certain link according to the actual service requirements.

The foregoing shows and describes the general principles, essential features, and advantages of the invention. It will be understood by those skilled in the art that the present invention is not limited to the embodiments described above, and the preferred embodiments of the present invention are described in the above embodiments and the description, and are not intended to limit the present invention. The scope of the invention is defined by the appended claims and equivalents thereof.

Claims (9)

1. A process recovery method under a workflow engine is characterized by comprising the following steps:

managing the process recovery authority, controlling personnel executing the process recovery operation and controlling a process recovery node;

managing process recovery time, wherein personnel executing process recovery operation can only recover the process within a specified time range;

managing a flow recovery mechanism, wherein when the flow is recovered, after the previous node is executed, the next node is executed according to the flow definition, the process is sequentially carried out, and during the recovery period, a person who executes the flow recovery operation can withdraw the flow to a specified node, so that the flow node which is already finished needs to be rolled back, and the state of the flow is recovered to the previous state;

managing the records of the process recovery nodes, wherein the process recovery needs to record each processing node of the process;

and (3) process recovery monitoring, wherein the recovery monitoring is carried out in an asynchronous mode, after the recovery execution is finished, a monitoring request is sent in a message form, the message is managed in a queue form, the message is read from the message queue through a new thread and the content of the message is stored, and when the message has a problem, a process monitoring alarm is sent to related business personnel.

2. The method of claim 1, wherein the workflow engine is configured to: in the process recovery authority management, process recovery personnel are controlled, process recovery authorities can be designed according to different roles, and authority constraint contents comprise recoverable nodes, recovery time constraints, recovery return node numbers and recovery ranges.

3. The method of claim 1, wherein the workflow engine is configured to: in the process recovery authority management, the process recovery node control can set the nodes which can be recovered by the process according to the role of the user.

4. The workflow engine based process recovery method of claim 1, wherein: in the process recovery time management, if the user exceeds the recovery time, the current process node cannot be recovered.

5. The workflow engine based process recovery method of claim 1, wherein: in the process of flow recovery time management, a background event monitoring mechanism is provided for the recovery time of the nodes, a flow recovery request triggers the corresponding event monitoring mechanism, and in the event processing process, according to the time rule configured by the flow nodes, if the time rule configuration is not met, the recovery of the flow nodes is rejected.

6. The method of claim 1, wherein the workflow engine is configured to: in the process recycling mechanism management, in order to ensure the integrity of the rollback operation, a system adopts a command mode, and records and stores each process node and the operation executed by the node in the form of a command object.

7. The method of claim 6, wherein the workflow engine is a workflow engine: the command mode is a data-driven design mode, belongs to a behavior mode, and comprises a do method and an undo method for respectively completing the execution of the command and the undo function of the command.

8. The workflow engine based process recovery method of claim 1, wherein: in the process recovery node record management, the nodes related to recovery can be rolled back in sequence, and the system adopts the nodes recovered by the stack team to manage.

9. The workflow engine based process recovery method of claim 1, wherein: in the process recovery node record management, after the process node is executed every time, the system puts the current node on a stack, when the recovery operation is executed, each node is popped from the stack in sequence, the unDo operation of the relevant command of the node is executed, and the rollback of the node transaction is finished.

Images