CN117632443B

CN117632443B - Method, device, equipment and medium for controlling circulation of business process

Info

Publication number: CN117632443B
Application number: CN202410105221.9A
Authority: CN
Inventors: 史高雄; 蔡明师; 林万鹏; 王镇
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2024-01-25
Filing date: 2024-01-25
Publication date: 2024-04-26
Anticipated expiration: 2044-01-25
Also published as: CN117632443A

Abstract

The embodiment of the application discloses a method, a device, equipment and a medium for controlling circulation of a business process, which can be applied to intelligent traffic, auxiliary driving, cloud technology, artificial intelligence and other scenes. The method comprises the following steps: if a starting request for a service flow pre-established in a service flow engine is received, starting the service flow, wherein the service flow comprises at least two task nodes; obtaining survival information corresponding to a service logic executor called by a task node which is transferred by a current flow in a service flow, wherein the service logic executor is used for executing service logic; if the abnormal interruption of the service logic executing body is detected based on the survival information, the service logic executing body is called again, so that the service logic is executed again through the called service logic executing body; after the execution of the business logic is detected, starting the next task node adjacent to the task node to which the business logic is transferred so as to continue the flow of the business flow. The technical scheme of the application improves the flow control reliability of the business process.

Description

Method, device, equipment and medium for controlling circulation of business process

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method for controlling flow of a business process, a device for controlling flow of a business process, an electronic device, and a computer readable medium.

Background

Currently, a common business processing mode is adopted to realize a certain business purpose by executing a certain business process through a business terminal; the business process is determined by connecting a plurality of task nodes according to business logic. In the related technology, task driving interruption of task nodes easily occurs in the circulation process of the service flow, so that the service flow fails to execute.

Therefore, how to improve the flow control reliability of the business process is a problem to be solved.

Disclosure of Invention

The embodiment of the application provides a method, a device, equipment and a medium for controlling the circulation of a business process, which improve the reliability of the circulation control of the business process.

In a first aspect, an embodiment of the present application provides a method for controlling circulation of a service flow, where the method includes: if a starting request for a service flow pre-established in a service flow engine is received, starting the service flow, wherein the service flow comprises at least two task nodes; obtaining survival information corresponding to a service logic executor called by a task node which is turned to by a current flow in the service flow, wherein the service logic executor is used for executing service logic; if the abnormal interruption of the service logic executing body is detected based on the survival information, the service logic executing body is called again, so that the service logic is executed again through the called service logic executing body; and after the execution of the business logic is detected, starting the next task node adjacent to the task node to which the flow is transferred so as to continue the flow of the business flow.

In a second aspect, an embodiment of the present application provides a flow control device for a service flow, where the device includes: the first starting module is configured to start a business process if a starting request for the business process pre-established in the business process engine is received, wherein the business process comprises at least two task nodes; the acquisition module is configured to acquire survival information corresponding to a service logic executor called by a task node which is transferred by the current flow in the service flow, wherein the service logic executor is used for executing service logic; the calling module is configured to call the service logic executor again if the abnormal interrupt of the service logic executor is detected based on the survival information, so as to execute the service logic again through the called service logic executor again; and the second starting module is configured to start the next task node adjacent to the task node to which the service logic is transferred after the execution of the service logic is detected, so as to continue the transfer of the service flow.

In one embodiment of the present application, based on the foregoing solution, the obtaining module is specifically configured to: acquiring identification information corresponding to a service logic executing body called by a task node which is transferred by a current flow in the service flow; acquiring survival information matched with the identification information corresponding to the acquired business logic executor from the designated storage area; the service logic executing body is used for executing the service logic, wherein the survival information of the service logic executing body stored in the designated storage area is continuously generated and transmitted by the service logic executing body in the process of executing the service logic.

In one embodiment of the present application, based on the foregoing solution, the survival information includes timestamp information sent by each heartbeat message, where the heartbeat message includes identification information of the service logic executor and identification information of a service flow to which the service logic executor belongs; the acquisition module is further specifically configured to: selecting the survival information set which is matched with the identification information corresponding to the acquired service logic executing body and the identification information corresponding to the service flow to which the acquired service logic executing body belongs from a plurality of survival information sets stored in the designated storage area; the same survival information set comprises a plurality of time stamp information corresponding to the same business process aimed by the same business logic executive body.

In one embodiment of the present application, based on the foregoing solution, after selecting, from the plurality of surviving information sets stored in the designated storage area, a surviving information set that matches identification information corresponding to the acquired service logic executor and identification information corresponding to a service flow to which the acquired service logic executor belongs, the apparatus further includes: a calculation module configured to calculate a duration of intervals between a current point in time and a plurality of timestamp information in the selected set of survival information; the detection module is configured to detect the survival condition of the service logic execution body based on the relation between the calculated interval duration and a preset interval duration threshold.

In one embodiment of the present application, based on the foregoing solution, the computing module is specifically configured to: selecting timestamp information closest to a current time point from a plurality of timestamp information of the selected survival information set, and calculating interval duration between the selected timestamp information and the current time point; or calculating the interval duration between the current time point and each time stamp information of the selected survival information set to obtain a plurality of interval durations, and selecting the interval duration with the minimum interval duration from the plurality of interval durations.

In one embodiment of the present application, based on the foregoing solution, the detection module is specifically configured to: if the calculated interval time length is greater than a preset interval time length threshold value, a detection result for representing abnormal interruption of the service logic executing body is obtained; and if the calculated interval duration is equal to or smaller than the preset interval duration threshold, obtaining a detection result used for representing normal execution of the service logic execution body.

In one embodiment of the present application, based on the foregoing scheme, the apparatus further includes: the receiving module is configured to receive the execution completion notification information sent by the service logic execution body; the execution completion notification information is generated after the service logic execution body executes the service logic; and a deletion module configured to delete survival information of the business logic execution body from the specified storage area based on the execution completion notification information.

In one embodiment of the present application, based on the foregoing solution, the obtaining module is specifically configured to: starting a service logic execution body detection service; and periodically acquiring survival information corresponding to the service logic executor called by the task node which is transferred by the current flow in the service flow through the started service logic executor detection service, and detecting the survival condition of the service logic executor based on the acquired survival information.

In one embodiment of the present application, based on the foregoing solution, the calling module is specifically configured to: invoking a service retry interface of the service flow engine; restarting the transferred task node through the service retry interface to call the service logic executor again based on the restarted task node.

In one embodiment of the present application, based on the foregoing, the apparatus further includes an exit control module configured to: if a soft interrupt request is received, acquiring a service logic executing body in an executing state currently; waiting for the execution of the service logic by the service logic executing body in the executing state; and after the service logic executor in the execution state executes the service logic, controlling to exit the service flow.

In one embodiment of the present application, based on the foregoing solution, the exit control module is specifically configured to: acquiring a quantity parameter for recording the quantity of service logic executors in an execution state; wherein the quantity parameter is obtained by increasing a specified unit quantity when each service logic executing body is called, and decreasing the specified unit quantity when each service logic executing body completes service logic execution; if the number of the service logic executors in the execution state, which is characterized by the number parameters, is detected to be at least one, determining that the service logic executors in the execution state exist currently; and if the quantity of the service logic executors in the execution state, which is characterized by the quantity parameters, is detected to be zero, controlling to exit the service flow.

In an embodiment of the present application, based on the foregoing solution, the exit control module is further specifically configured to: if the trigger is detected to wait for the execution of the service logic by the service logic executing body in the executing state, recording a waiting starting time point and timing from the starting time point; and if the detected time duration reaches the preset time duration threshold value, controlling to exit the service flow.

In a third aspect, embodiments of the present application provide an electronic device, including one or more processors; and a memory for storing one or more programs that, when executed by the one or more processors, cause the electronic device to implement the flow control method of the business process as described above.

In a fourth aspect, embodiments of the present application provide a computer readable medium having stored thereon a computer program which, when executed by a processor, implements a flow control method for a business process as described above.

In a fifth aspect, embodiments of the present application provide a computer program product comprising computer instructions which, when executed by a processor, implement a flow control method for a business process as described above.

In the technical scheme provided by the embodiment of the application:

After a business process containing task nodes is started, survival information corresponding to a business logic executing body called by the task node which is currently flowed to in the business process is acquired, after an abnormal interrupt of the business logic executing body is detected based on the survival information, the business logic executing body is triggered to be called again, so that the business logic is executed again through the called business logic again, and meanwhile, after the business logic is detected to be executed, the next task node adjacent to the task node which is flowed to is started, so that flow control of the business process is realized.

That is, whether the service logic executing body is abnormally interrupted or not is detected in real time through the survival information of the service logic executing body, and the service logic executing body is called again after the abnormal interruption, so that the phenomenon that the service flow is failed to execute due to the abnormal interruption of the service logic executing body is avoided, the normal execution/circulation of the service flow is ensured, the circulation control accuracy and flexibility of the service flow are improved, and the circulation control reliability of the service flow is high.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application as claimed.

Drawings

FIG. 1 is a schematic diagram illustrating a business process execution failure according to an exemplary embodiment of the present application.

FIG. 2 is a schematic diagram of an exemplary implementation environment in which the techniques of embodiments of the present application may be applied.

Fig. 3 is a flow chart of a flow control method of a business process according to an exemplary embodiment of the present application.

Fig. 4 is a flowchart of a flow control method of a business process according to another exemplary embodiment of the present application.

Fig. 5 is a flowchart of a flow control method of a business process according to another exemplary embodiment of the present application.

Fig. 6 is a schematic diagram of a flow control method of a business process according to another exemplary embodiment of the present application.

Fig. 7 is a flowchart of a flow control method of a business process according to another exemplary embodiment of the present application.

Fig. 8 is a flowchart of a flow control method of a business process according to another exemplary embodiment of the present application.

Fig. 9 is a block diagram of a flow control apparatus of a business process shown in an exemplary embodiment of the present application.

Fig. 10 is a schematic diagram of a computer system suitable for use in implementing an embodiment of the application.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations identical to the present application. Rather, they are merely examples of apparatus and methods that are identical to some aspects of the present application as detailed in the appended claims.

In the present embodiment, the term "module" or "unit" refers to a computer program or a part of a computer program having a predetermined function and working together with other relevant parts to achieve a predetermined object, and may be implemented in whole or in part by using software, hardware (such as a processing circuit or a memory), or a combination thereof. Also, a processor (or multiple processors or memories) may be used to implement one or more modules or units. Furthermore, each module or unit may be part of an overall module or unit that incorporates the functionality of the module or unit.

The block diagrams depicted in the figures are merely functional entities and do not necessarily correspond to physically separate entities. That is, the functional entities may be implemented in software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor devices and/or microcontroller devices.

The flow diagrams depicted in the figures are exemplary only, and do not necessarily include all of the elements and operations/steps, nor must they be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the order of actual execution may be changed according to actual situations.

In the present application, the term "plurality" means two or more. "and/or" describes an association relationship of an association object, meaning that there may be three relationships, e.g., a and/or B may represent: a exists alone, A and B exist together, and B exists alone. The character "/" generally indicates that the context-dependent object is an "or" relationship.

With the development of internet technology, a service processing means which is common in modern life is already processed by utilizing a service system with high efficiency and convenience, and the service system can integrate a plurality of service flows to meet the requirements of service purposes; for example, the enterprise management system may be equipped with a leave examination and approval process, a goods management process, a fee application process, and the like.

It can be understood that the design of the business process is one of the core works in the business system construction process, wherein the business process engine can arrange and combine a plurality of task nodes according to a certain protocol to create/design the business process, and the business process engine can be a BPMN standard process engine; such as active/Flowable. Flowable is a commonly used business process engine that allows developers to design business processes in the form of a flow chart based on business process models and labeling 2.0 (Business Process Model and Notation, BPMN) protocol standards, reducing the difficulty of business process creation/design.

In the related technology, after the business process is established/designed based on the business process engine, task driving interruption of task nodes easily occurs in the circulation process of the business process, so that the business process execution fails. For ease of understanding, referring to fig. 1, fig. 1 is a schematic diagram of a business process execution failure. As shown in fig. 1, during the execution of the service flow, the task node B performs the service logic with abnormal interruption, and cannot trigger the task node B to submit a task, so that the task cannot flow to the task node C, i.e. the service flow fails to flow at this time.

Therefore, in order to improve the flow control reliability of the business process, the application provides a flow control scheme of the business process. Referring to fig. 2, fig. 2 is a schematic diagram of an implementation environment according to the present application. The implementation environment mainly comprises a terminal device 201 and a server 202.

The terminal device 201 may be pre-installed with a software system for managing an enterprise, where the software system may perform a specific business process in response to an operation input by a user, so as to achieve a business purpose corresponding to the business process, and the software system may rely on a business process engine to implement management of a business operation.

In the execution process of the service flow, the terminal device 201 may send survival information corresponding to the service logic executor (which is used for executing the service logic) invoked by each task node in the service flow to the server 202, so that the server 202 determines whether the service logic executor is abnormally interrupted in the execution process based on the survival information corresponding to the service logic executor invoked by each task node, so as to invoke the abnormally interrupted service logic executor to re-execute the service logic after determining that the service logic executor is abnormally interrupted in the execution process, thereby ensuring normal execution of the service flow.

By way of example, the types of terminal devices 201 include, but are not limited to, smartphones, tablets, televisions, notebooks, desktop computers, etc., which are not particularly limited.

Wherein the server 202 has data processing and storage functions.

In the execution process of the service flow, the server 202 may receive the survival information corresponding to the service logic executor invoked by each task node in the service flow sent by the terminal device 201, and determine whether the service logic executor is abnormally interrupted in the execution process based on the survival information corresponding to the service logic executor invoked by each task node, so as to invoke the abnormally interrupted service logic executor to re-execute the service logic after determining that the service logic executor is abnormally interrupted in the execution process, thereby ensuring the normal execution of the service flow.

The server may be an independent physical server, or may be a server cluster or a distributed system formed by a plurality of physical servers, where the server cluster or the distributed system includes a cloud server for providing cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, a content distribution network (Content Delivery Network, CDN), and basic cloud computing services such as big data and an artificial intelligence platform, which are not limited in particular.

It will be appreciated that the communication connection is established between the terminal device 201 and the server 202 via a wired or wireless network. The wireless network or wired network illustratively uses standard communication techniques and/or protocols. The network is typically the internet, but may be any other network including, but not limited to, a local area network (Local Area Network, LAN), metropolitan area network (Metropolitan AreaNetwork, MAN), wide area network (Wide Area Network, WAN), a mobile, wired or wireless network, any combination of private or virtual private networks, and the like.

It should be clear that the number of terminal devices 201 and servers 202 in fig. 2 is only illustrative and that any number of terminal devices 201 and servers 202 may be provided according to actual needs.

It should be noted that, in the specific embodiment of the present application, related data of a user is referred to, when the embodiment of the present application is applied to a specific product or technology, permission or consent of the user needs to be obtained, and collection, use and processing of related data need to comply with related laws and regulations and standards of related countries and regions.

Various implementation details of the technical solution of the embodiment of the present application are set forth in detail below:

Referring to fig. 3, fig. 3 is a flowchart illustrating a method for controlling the circulation of a business process according to an embodiment of the present application, where the method for controlling the circulation of a business process may be performed by the server 202. As shown in fig. 3, the flow control method of the business process at least includes S301 to S304, which are described in detail as follows:

s301, if a starting request for a pre-established business process in a business process engine is received, starting the business process, wherein the business process comprises at least two task nodes.

It can be understood that when a user has an execution requirement for a business process created in advance in the business process engine, the user can issue a start request and send the start request to the server through the terminal device; correspondingly, the server receives a starting request for a pre-established business process in the business process engine, and triggers the starting of the business process, so that the business purpose corresponding to the business process is achieved through the execution of the business process.

In the embodiment of the application, the business process comprises at least two task nodes, and each task node corresponds to a business logic executing body (also called a business executor) for executing business logic; in the execution process of the business flow, when the flow is transferred to the corresponding task node, the task node can call the business logic execution body to execute the business logic.

For example, referring to fig. 1 again, the service flow includes at least 4 task nodes, namely, task node a, task node B, task node C, and task node D, which can call the service logic executing body a to execute the service logic when the flow goes to task node a, and can call the service logic executing body B to execute the service logic when the flow goes to task node B, and so on.

S302, obtaining survival information corresponding to a service logic executor called by a task node which is turned to by a current flow in a service flow, wherein the service logic executor is used for executing service logic.

In the embodiment of the application, after the service flow is started, the task node which is currently flowed to by the service flow can be detected, specifically, survival information corresponding to the service logic executor which is called by the task node which is currently flowed to by the service flow can be obtained, and the survival condition of the service logic executor can be detected based on the survival information.

In the embodiment of the application, the task node which is currently circulated in the business process refers to the task node which is circulated in the current time point in the execution process of the business process, and is different from the task node which is circulated and the task node which is not circulated yet.

For example, assuming that the previous example of fig. 1 is still accepted, and that the current flow is to the task node B, the task node a is referred to as a task node that flows through, and the task nodes C and D are referred to as task nodes that have not yet flowed through.

In the embodiment of the present application, the survival information refers to information for showing whether the service logic executing body survives, where if the survival information indicates that the service logic executing body does not survive, it means that the service logic executing body is abnormally interrupted, that is, the service logic executing body executes the service logic and is abnormally interrupted, and if the survival information indicates that the service logic executing body survives, it means that the service logic executing body is in the process of normally executing the service logic.

In the embodiment of the application, the survival information corresponding to the service logic executor called by the task node to which the current flow is transferred is obtained.

For example, still taking the foregoing example of fig. 1, if the flow goes to the task node a, the survival information corresponding to the service logic executor a called by the task node a is obtained, and over time, if the flow goes to the task node B, the survival information corresponding to the service logic executor B called by the task node B is obtained, and so on.

In one embodiment of the present application, the process of obtaining survival information corresponding to a service logic executor invoked by a task node that is currently streamed to in a service flow in S302 may include:

Starting a service logic execution body detection service;

and periodically acquiring survival information corresponding to the service logic executor called by the task node which is transferred by the current flow in the service flow through the started service logic executor detection service, and detecting the survival condition of the service logic executor based on the acquired survival information.

That is, in an alternative embodiment the server is pre-configured with a service (referred to as a business logic executor detection service, also referred to as an interrupt check service) for acquiring survival information and detecting the survival of the business logic executor, wherein the business logic executor detection service is pre-written by a developer or an automated machine.

In an alternative embodiment, the server may start the service logic executor detection service at the same time/after/before starting the service flow, and then in the execution process of the service flow, the started service logic executor detection service periodically acquires the survival information corresponding to the service logic executor invoked by the task node to which the current flow is transferred, and detects the survival condition of the service logic executor based on the acquired survival information.

In other words, the detection of the survival condition of the service logic executor is periodic, so that the service logic executor with the abnormal interrupt can be found out in time through continuous detection, the recall efficiency of the service logic executor with the abnormal interrupt is improved, and the execution efficiency of the service is high.

Thus, by implementing the alternative embodiment, the service for detecting the survival condition of the service logic execution body can be simply and accurately realized by the started service logic execution body, and powerful support is provided for subsequent recall of the service logic execution body with abnormal interruption.

S303, if the abnormal interrupt of the service logic executing body is detected based on the survival information, the service logic executing body is called again to execute the service logic again through the called service logic executing body.

In the embodiment of the application, if the abnormal interrupt of the service logic executing body is detected based on the survival information, the service logic executing body is required to be called again at the moment, so that the service logic is re-executed by the called service logic executing body again.

It can be understood that if the service logic executing body is detected to normally execute based on the survival information, the corresponding processing is not needed at this time, and the service logic executing body can execute according to the normal service flow.

For example, still taking the foregoing example of fig. 1, during execution of the business process:

When the flow is transferred to the task node A, the survival condition of the service logic executing body a is detected based on the obtained survival information corresponding to the service logic executing body a called by the task node A, and if the service logic executing body a called by the task node A is detected to normally execute the service logic, no corresponding processing is needed at the moment, and only the service logic executing body a needs to wait for the service logic executing body a to execute the service logic so as to be transferred to the task node B.

When the flow goes to the task node B, the survival condition of the service logic executing body B is detected based on the obtained survival information corresponding to the service logic executing body B called by the task node B, and if the abnormal interruption of the service logic executing body B called by the task node B is detected, the service logic executing body B is called again at the moment, so that the service logic is re-executed by the service logic executing body B called again.

The processing of other task nodes is similar.

In one embodiment of the present application, the procedure of calling the service logic executor again in S303 may include:

Invoking a service retry interface of a service flow engine;

restarting the transferred task node through the service retry interface to invoke the service logic executor again based on the restarted task node.

That is, in an alternative embodiment, the server invokes the service retry interface through the address corresponding to the service retry interface of the pre-configured service flow engine, and then the invoked service retry interface restarts the task node that is streamed to execute the service logic by invoking the service logic executor again based on the restarted task node.

In other words, the restarting of the task node drives the restarting of the service logic executing body called by the task node, so that the service logic can be re-executed based on the restarted service logic executing body.

Therefore, through implementing the alternative embodiment, the called service retry interface can simply and conveniently realize the recall of the service logic execution body, thereby ensuring the normal circulation of the service flow.

S304, after the execution of the business logic is detected, starting the next task node adjacent to the task node to which the business logic is transferred to continue the business process.

In the embodiment of the application, if the service logic is executed, the next task node adjacent to the task node to which the current flow is transferred can be started, so that the service flow is executed, and the normal flow of the service flow is ensured.

For example, still adapting to the foregoing example of fig. 1, after the task node a invokes the service logic executor a to execute the service logic, the task node B is started to cause the task node B to invoke the service logic executor B to execute the service logic (after detecting that the service logic executor B is abnormally interrupted, recall the service logic until the service logic executor B has executed the service logic); after the task node B calls the service logic executing body a to execute the service logic, the task node C is started, so that the task node B calls the service logic executing body B to execute the service logic, and the like.

In the embodiment of the application, whether the service logic executor is abnormally interrupted or not is detected in real time through the survival information of the service logic executor, and the service logic executor is called again after the abnormal interruption, so that the phenomenon that the service logic executor is abnormally interrupted to cause failure in executing the service flow is avoided, normal execution/circulation of the service flow is ensured, the circulation control accuracy and flexibility of the service flow are improved, and the circulation control reliability of the service flow is high.

In one embodiment of the present application, another method for controlling the flow of a business process is provided, which may be performed by the server 202. As shown in fig. 4, the flow control method of the business process may include S401 to S402, S301, S303 to S304.

S401 to S402 are described in detail as follows:

s401, obtaining identification information corresponding to a service logic executing body called by a task node which is transferred by a current flow in a service flow.

After the service flow is started, the embodiment of the application can acquire the identification information corresponding to the service logic executor called by the task node which is transferred by the current flow in the service flow.

The identification information corresponding to the service logic executor in the embodiment of the present application is used for uniquely identifying the service logic executor, which includes, but is not limited to, the name of the service logic executor, the identification number of the service logic executor, and the like.

S402, obtaining survival information matched with the identification information corresponding to the obtained business logic execution body from a designated storage area; the service logic executor is used for executing the service logic, wherein the survival information of the service logic executor stored in the designated storage area is continuously generated and transmitted by the service logic executor in the process of executing the service logic.

The designated storage area in the embodiment of the application refers to an area for storing survival information of a service logic executing body. It can be understood that the service logic executor continuously generates survival information of the service logic executor in the process of executing the service logic, and sends the generated survival information to the server; accordingly, the server receives the survival information of the business logic executor and stores it in the designated storage area.

If the flow flows to the task node A, acquiring the identification information "a" of the service logic executing body a called by the task node A, and acquiring survival information matched with the identification information "a" of the service logic executing body a from a designated storage area; the survival information of the business logic executing body a stored in the designated storage area is continuously generated and sent to the server by the business logic executing body a in the process of executing the business logic.

If the flow goes to the task node B, the identification information 'B' of the service logic executing body B called by the task node B is obtained, and survival information matched with the identification information 'B' of the service logic executing body B is obtained from a designated storage area; the survival information of the service logic executing body b stored in the designated storage area is continuously generated and sent to the server by the service logic executing body b in the process of executing the service logic.

The processing of other task nodes is similar.

In one embodiment of the present application, the survival information includes timestamp information sent by each heartbeat message, where the heartbeat message includes, but is not limited to, identification information of a service logic executing body, identification information of a service flow to which the service logic executing body belongs, and the like.

That is, in an alternative embodiment, the alive information includes timestamp information sent by the heartbeat information, optionally, the number of the heartbeat information is multiple, and each heartbeat information includes identification information of the service logic executing body and identification information of a service flow to which the service logic executing body belongs.

For example, please refer to table 1, which is an example of survival information.

TABLE 1

Accordingly, the process of acquiring survival information matched with the identification information corresponding to the acquired service logic executor from the designated storage area in S402 may include:

Selecting the survival information set which is matched with the identification information corresponding to the acquired service logic executing body and the identification information corresponding to the service flow to which the acquired service logic executing body belongs from a plurality of survival information sets stored in the designated storage area; the same survival information set comprises a plurality of time stamp information corresponding to the same business process aimed by the same business logic executive body.

It can be appreciated that, since the execution of a plurality of business processes is generally involved in the practical application, the server receives the survival information of the business logic executor sent by the business logic executor invoked by the plurality of task nodes.

For example, for the business process 1, if the current flow is set to the task node a ₁, the business logic executor a ₁ called by the task node a ₁ continuously generates survival information of the business logic executor a ₁ in the process of executing the business logic, and sends the generated survival information to the server; accordingly, the server receives the survival information of the business logic executor a ₁ and stores it in the designated storage area.

Meanwhile, for the service flow 2, if the current flow is transferred to the task node a ₂, the service logic executor a ₂ called by the task node a ₂ continuously generates survival information of the service logic executor a ₂ in the process of executing the service logic, and sends the generated survival information to the server; accordingly, the server receives the survival information of the business logic executor a ₂ and stores it in the designated storage area.

Therefore, in order to better manage the survival information sent by the service logic executing body, before the process of selecting the survival information set that matches the identification information corresponding to the acquired service logic executing body and the identification information corresponding to the service flow to which the acquired service logic executing body belongs from the plurality of survival information sets stored in the designated storage area, the method may further include:

Classifying the survival information based on the identification information of the service logic executor in the survival information and the identification information of the service flow to which the service logic executor belongs to obtain a survival information set; the same survival information set comprises a plurality of time stamp information corresponding to the same business process aimed by the same business logic executive body.

That is, in the alternative embodiment, the server divides the timestamp information corresponding to the same service logic executor and the same service flow into the same survival information set, and of course, the service logic executor and the service flow corresponding to different survival information sets are different.

For example, taking the foregoing example, a set of survival information N1 and a set of survival information N2 are obtained, where the set of survival information N1 includes the survival information of the business logic executor a ₁ corresponding to the business process 1, and the set of survival information N2 includes the survival information of the business logic executor a ₂ corresponding to the business process 2.

It can be appreciated that, in an alternative embodiment, the server classifies the survival information of the service logic executor in advance to obtain a plurality of survival information sets; therefore, when the survival information corresponding to the service logic execution body of the task node which is currently circulated is required to be acquired, selecting the survival information set which is matched with the identification information corresponding to the service logic execution body of the task node which is currently circulated and the identification information corresponding to the service process to which the service logic execution body belongs from a plurality of survival information sets stored in the designated storage area.

By implementing the optional embodiment, the survival information of the service logic executor is classified in advance, so that the service logic executor is convenient to manage the survival information, the acquisition efficiency of the survival information of the service logic executor can be improved, the detection efficiency of whether the service logic executor is abnormally interrupted is improved, and the service execution efficiency is high.

In one embodiment of the present application, after the process of selecting the surviving information set that matches the identification information corresponding to the acquired service logic executor and the identification information corresponding to the service flow to which the acquired service logic executor belongs from the plurality of surviving information sets stored in the designated storage area, the method may further include:

calculating the interval duration between the current time point and a plurality of time stamp information in the selected survival information set;

and detecting the survival condition of the service logic executor based on the relation between the calculated interval duration and a preset interval duration threshold value.

As described in the foregoing embodiments, the server detects the survival of the business logic execution body based on the survival information. Specifically, in an alternative embodiment, the server realizes the detection of the survival condition of the service logic executor based on the interval duration between the current time point and a plurality of timestamp information in the survival information set corresponding to the service logic executor (i.e., the service logic executor corresponding to the task node to which the current time point flows).

Therefore, by implementing the alternative embodiment, based on the current time point and the interval duration between the plurality of time stamp information in the survival information set corresponding to the service logic execution body, the detection of the survival condition of the service logic execution body can be simply, conveniently and accurately realized, and powerful support is provided for the subsequent recall of the service logic execution body with abnormal interruption.

In one embodiment of the present application, the process of calculating the interval duration between the current time point and the plurality of time stamp information in the selected survival information set may include:

Selecting timestamp information nearest to the current time point from a plurality of timestamp information of the selected survival information set, and calculating interval duration between the selected timestamp information and the current time point; or alternatively

Calculating the interval duration between the current time point and each time stamp information of the selected survival information set, obtaining a plurality of interval durations, and selecting the interval duration with the minimum interval duration from the plurality of interval durations.

In an alternative embodiment, the server may first select timestamp information closest to the current time point from the plurality of timestamp information of the selected survival information set, and then calculate an interval duration between the selected timestamp information and the current time point.

For example, let us say that the selected survival information set N1= { t1, t2, t3}, where t1, t2, t3 each represent time stamp information, t1> t2> t3, where > represents earlier than before, the time stamp information t3 is selected from the survival information set N1, and the interval duration Δt ₃ between the current time point t' and the time stamp information t3 is calculated.

Thus, by implementing the alternative embodiment, only the interval duration between the time stamp information nearest to the current time point and the current time point is calculated, and the calculation resource is saved.

In an alternative embodiment, the server may calculate the interval duration between the current time point and each timestamp information of the selected survival information set to obtain a plurality of interval durations, and then select an interval duration with the smallest interval duration from the plurality of interval durations.

For example, let us say that the selected survival information set n1= { t1, t2, t3}, where t1, t2, t3 each represent timestamp information, t1> t2> t3, where > represents earlier than when the interval duration Δt ₁ between the current time point t ' and the timestamp information t1 can be calculated, the interval duration Δt ₂ between the current time point t ' and the timestamp information t2 can be calculated, and the interval duration Δt ₃ between the current time point t ' and the timestamp information t3 can be calculated, and then the interval duration with the smallest interval duration (i.e., Δt ₃) can be selected from the 3 interval durations Δt ₁,△t₂,△t₃.

Thus, by implementing the alternative embodiment, the interval duration between the current time point and each piece of time stamp information is calculated respectively, and the flow is simple and easy to implement.

In one embodiment of the present application, the process of detecting the survival condition of the service logic executing body based on the relationship between the calculated interval duration and the preset interval duration threshold value may include:

if the calculated interval time length is greater than a preset interval time length threshold value, a detection result for representing abnormal interruption of the service logic executing body is obtained;

And if the calculated interval duration is equal to or smaller than a preset interval duration threshold, obtaining a detection result used for representing normal execution of the service logic executing body.

That is, in an alternative embodiment, for detection of the traffic logic execution volume survival condition, there are two cases:

In case 1, if the interval time length is greater than the preset interval time length threshold, the service logic executor may stop reporting the survival information due to abnormal interruption, and at this time, it is determined that the service logic executor is abnormally interrupted, and the detection result for the abnormal interruption of the service logic executor is obtained.

And 2, if the interval duration is equal to or less than a preset interval duration threshold, characterizing normal execution of the service logic execution body and reporting survival information, and determining that the service logic execution body normally executes at the moment, namely obtaining a detection result for normal execution of the service logic execution body.

For example, in the foregoing example, let the preset interval duration threshold be t0, if Δt ₃ > t0, determine that the service logic executor is aborted, and if Δt ₃ is less than or equal to t0, determine that the service logic executor is executing normally.

Thus, by implementing the alternative embodiment, the detection of the survival condition of the service logic executor can be simply, conveniently and accurately realized by comparing the minimum interval duration with the preset interval duration threshold.

In one embodiment of the present application, it may further include:

Receiving execution completion notification information sent by a business logic executing body; the execution completion notification information is generated after the service logic executor completes the execution of the service logic;

the survival information of the business logic executor is deleted from the designated storage area based on the execution completion notification information.

That is, in an alternative embodiment, after the service logic executing body completes executing the service logic, the service logic executing body may generate execution completion notification information, where the execution completion notification information is used to characterize that the service logic executing body completes executing the service logic, and send the execution completion notification information to the server; accordingly, the server receives the execution completion notification information sent by the service logic execution body, and can determine that the service logic execution body has executed the service logic, so that the survival information of the service logic execution body can be deleted from the designated storage area.

By implementing the alternative embodiment, the service logic executor timely notifies the server after executing the service logic, and the server deletes the survival information of the service logic executor in the designated storage area, so that the storage resource is saved, and the acquisition efficiency/search efficiency of the survival information of the subsequent service logic executor is improved to a certain extent.

In other embodiments, after the server detects that the service logic executor has executed the service logic, the server actively triggers deletion of the service logic executor survival information in the designated storage area, and in practical application, the server may flexibly adjust according to a specific application scenario.

It should be noted that, for the detailed description of S301, S303 to S304 shown in fig. 4, please refer to S301, S303 to S304 shown in fig. 3, and the detailed description is omitted here.

According to the embodiment of the application, the survival information of the service logic executor can be rapidly acquired from the appointed storage area through the identification information corresponding to the service logic executor, so that the acquisition efficiency of the survival information of the service logic executor is improved, the detection efficiency of whether the service logic executor is abnormally interrupted is improved, and the service execution efficiency is high.

In one embodiment of the present application, another method for controlling the flow of a business process is provided, which may be performed by the server 202. As shown in fig. 5, the flow control method of the business process may further include S501 to S503 after S301.

It should be clear that, in the foregoing embodiment, the abnormal interrupt occurs in the service logic executing body, which is generally referred to as a hard interrupt, and has the characteristic of forced interrupt, which is a concept opposite to soft interrupt, and soft interrupt has the characteristic of graceful exit, that is, the soft interrupt can be exited after waiting a period of time. The embodiment of the application is to introduce a processing procedure for soft interrupt.

S501 to S503 are described in detail as follows:

S501, if a soft interrupt request is received, acquiring a service logic executing body in an executing state currently.

It can be understood that, because the execution of a plurality of service flows is generally involved in the practical application, in order to ensure the normal circulation of each service flow, after receiving the soft interrupt request, the service logic executing body in the current executing state may be acquired to execute the corresponding waiting operation based on the service logic executing body in the current executing state.

In the embodiment of the application, the service logic executing body in the executing state refers to the service logic executing body executing the service logic.

In one embodiment of the present application, the process of acquiring the service logic executable currently in the execution state in S501 may include:

Acquiring a quantity parameter for recording the quantity of service logic executors in an execution state; wherein the quantity parameter is obtained by increasing the specified unit quantity when each service logic executing body is called and decreasing the specified unit quantity when each service logic executing body completes the service logic;

If the number of the business logic executives in the execution state, which is characterized by the number parameter, is detected to be at least one, the business logic executives in the execution state are determined to exist currently.

That is, in an alternative embodiment, the server is preset with a number parameter (for example, counter) for recording the number of service logic executives in the execution state, and may continuously detect the call of the service logic executives in the service process.

In an alternative embodiment, each time a service logic executing body is detected to be invoked, the number of service logic executing bodies in an executing state is increased, usually counter= couner +1, and of course, other specified unit quantities may be added, for example, counter= couner +2, etc.; when each service logic executing body detects that the service logic executing body executes the service logic, the number of the service logic executing bodies in the executing state is reduced, usually counter= couner-1, but other specified unit quantities, such as counter= couner-2, can also be reduced. It will be appreciated that the unit amounts for which the increase and decrease are the same.

In an alternative embodiment, if the number of the service logic executives in the execution state, which is characterized by the number parameter, is detected to be at least one, then there is a service logic executor executing the service logic, and if the number of the service logic executives in the execution state, which is characterized by the number parameter, is detected to be zero, then there is no service logic executor executing the service logic.

Therefore, by implementing the alternative embodiment, the number of the service logic executors in the current execution state can be clarified through the setting of the number parameter, and powerful support is provided for the exit control of the service flow.

S502, waiting for the execution of the business logic by the business logic executor in the execution state.

In the embodiment of the application, when the service logic executing body executing the service logic exists, the service logic executing body can wait for the service logic executing body to execute the service logic.

S503, after the execution of the business logic is completed by the business logic executing body in the executing state, the control exits the business process.

In the embodiment of the application, the server can continuously detect the execution condition of the service logic executor aiming at the service logic, and can control to exit the service flow if the service logic executor in the execution state is detected to execute the service logic, namely, the server does not need to wait any more, and can continue waiting if the service logic executor in the execution state is detected to execute the service logic.

In one embodiment of the present application, after the execution of the service logic by the service logic executing body in the execution state in S503, the process of controlling to exit the service flow may include:

And if the number of the service logic executors in the execution state, which is characterized by the parameters, is detected to be zero, controlling to exit the service flow.

That is, in the alternative embodiment, if the number of the service logic executives in the execution state, which is characterized by the number parameter, is detected to be zero, then there is no service logic executor that is executing the service logic, and the control exits the service flow.

In one embodiment of the present application, the process of waiting for the service logic executor in the execution state to finish executing the service logic in S502 may include:

If the service logic executing body triggering the waiting to be in the executing state is detected to execute the service logic, recording a waiting starting time point and timing from the starting time point;

Accordingly, it may further include: and if the detected time duration reaches the preset time duration threshold value, controlling to exit the service flow.

That is, in an alternative embodiment, the server records a waiting start time point when triggering the execution body of the service logic in the execution state to execute the service logic, counts time from the start time point, and further controls to exit the service flow when detecting that the counted time length reaches a preset time length threshold value.

In other words, a timeout period (i.e. a threshold of a preset time period) is set for the soft interrupt, and when the soft interrupt waits for more than the timeout period, the soft interrupt is forcedly interrupted, i.e. belongs to the hard interrupt at the moment.

By implementing the optional embodiment, the business process is controlled to exit by setting the timeout duration and comparing the timing duration with the timeout duration, so that the phenomenon of long waiting is avoided, business execution and exit management are balanced, and the method is suitable for various scenes.

It should be noted that, for the detailed description of S301 to S304 shown in fig. 5, please refer to S301 to S304 shown in fig. 3, and the detailed description is omitted herein.

In the embodiment of the application, under the condition of soft interruption, the business logic executor in the execution state waits for the execution of the business logic, and then the exit of the business process is controlled, so that the normal circulation of the business process is ensured.

The following describes the specific scenario of the embodiment of the present application in detail:

DevOps network operation flow platform NetDevOps: an automatic operation flow development system and an operation platform, in particular to an automatic operation flow development system and an operation platform which are manufactured by a telecommunication network platform part for network operators; the system has the capabilities of managing data, automating operation, managing and controlling the transaction by using a low-code, low-threshold and high-efficiency flow development mode, and integrating and standardizing network operation transactions.

Self-lapping workflow engine (WorkflowEngine): a self-grinding workflow engine for NetDevOps body-building, which is mainly responsible for the circulation driving of tasks in the running process of business processes and the logical distribution of tasks flowing through task nodes; it has capabilities including, but not limited to, storage and management of flow instances/tasks/sequential flows/variables, flow path decisions, task logic distribution, execution of various business executors, flow anomaly control, etc.

In the embodiment of the application, the business process created/designed in the self-grinding workflow engine is taken as an example.

Referring to fig. 6, the self-polishing workflow engine mainly includes a self-polishing workflow engine service process and an interrupt detection service process, wherein:

system initialization phase (i.e. no business process start): the self-grinding workflow engine service process sets a global counter (namely, a quantity parameter) and initializes to 0, namely, the workflow of the work process corresponding to the service executor which is not started currently is represented.

System operation phase (i.e. there is business process start): the task nodes corresponding to the started service flows asynchronously start the work processes corresponding to the service execution units. Firstly, aiming at the initial stage of a working process worker corresponding to a service execution unit, a started service executor is added to a global counter +1, namely, the current representation is performed; then, aiming at the execution stage of the work process worker corresponding to the service execution unit, calling a service executor to execute service logic, and returning an execution result of the service logic; then, aiming at the exit stage of the work process worker corresponding to the service execution unit, the global counter-1, namely the representation is reduced by one started service executor.

The heartbeat unit is used for receiving the heartbeat reported by the work process worker corresponding to the service execution unit and storing the heartbeat into the central mark storage; the interrupt detection service process reads the heartbeat reported by the work process worker corresponding to the service execution unit from the central mark storage to perform timeout detection/calculation, and restarts the work process worker corresponding to the service execution unit (namely drives the restarting of the service executor) when the timeout is determined.

It can be understood that if the timeout means a hard interrupt, the service process of the self-grinding workflow engine forcedly exits, and the heartbeat units corresponding to different threads or coroutines in the same service process are forcedly exited, namely, the heartbeat stops, so that the task nodes are restarted under the condition of the hard interrupt to restart the work process worker corresponding to the service execution unit (namely, restart the service executor).

The step of exiting the worker corresponding to the service execution unit ends reporting the heartbeat to the heartbeat unit (for example, the worker corresponding to the service execution unit sends heartbeat cancellation information to the heartbeat unit to cancel the heartbeat reporting), and then the worker corresponding to the service execution unit exits from the heartbeat unit. Optionally, the heartbeat unit (before exiting) and/or the interrupt detection service process may delete the heartbeat reported by the work process worker corresponding to the service execution unit in the central tag storage.

The system exit phase (i.e., after receiving a soft interrupt request such as singal. Sigtherm): the self-grinding workflow engine service process waits for the global counter to be 0 and then exits, namely the work process worker corresponding to the service execution unit which is not started currently is characterized, and the safe exit is performed at the moment. Optionally, an exit (i.e., a hard interrupt) is forced if a timeout is detected during the wait.

It should be noted that, the difference between the hard interrupt and the soft interrupt is that the hard interrupt cannot be perceived, and the soft interrupt can be perceived, so in the embodiment of the present application, a heartbeat detection scheme is adopted for the hard interrupt, and a global count detection scheme is adopted for the soft interrupt.

The embodiment of the application solves the problem of interruption in the asynchronous execution process of the service executor by combining the heartbeat detection scheme and the global counting detection scheme, and ensures the normal execution of the service executor, thereby ensuring the normal circulation of the service flow and improving the circulation control reliability of the service flow.

Next, the relevant flow of task nodes is described in detail.

Referring to fig. 7, fig. 7 is a flowchart of a flow control method of a business process according to an embodiment of the application. As shown in fig. 7, the flow control method of the business process at least includes S701 to S711, which are described in detail as follows:

s701, the task node asynchronously starts an asynchronous coroutine CO1.

S702, the asynchronous coroutine CO1 counts through a global counter (i.e. counter+1).

S703, the asynchronous coroutine CO1 starts a service executor, and the service logic is executed by the service executor.

S704, after the asynchronous coroutine CO1 detects that the service executor has executed the service logic, callback is performed according to the service logic execution result so as to continue the circulation of the service flow.

And S705, if the asynchronous coroutine CO1 detects that callback is successful, determining that the asynchronous coroutine CO1 finishes calling.

S706, the asynchronous coroutine CO1 updates the global counter (i.e., counter-1).

S707, the asynchronous coroutine CO1 exits and sends heartbeat cancellation information to the asynchronous coroutine CO 2.

S708, the asynchronous coroutine CO1 asynchronously starts the asynchronous coroutine CO2.

S709, performing behavior judgment by using asynchronous CO-range CO 2; if the heartbeat of the service executor is received, S710 is performed, and if the heartbeat cancellation information is received, S711 is performed.

It can be understood that the asynchronous coroutine CO2 performs a loop judgment until the heartbeat cancellation information sent by the asynchronous coroutine CO1 is received.

S710, the asynchronous coroutine CO2 stores the heartbeat of the service executor in a central mark storage.

S711, the asynchronous coroutine CO2 sets the execution end mark of the service executor, and sends the execution end mark of the service executor to the central mark storage, so that the central mark storage deletes the heartbeat of the service executor based on the execution end mark of the service executor, and the asynchronous coroutine CO2 exits.

It should be noted that, in fig. 7, S702 to S707 and S708 to S711 may be executed in parallel, and the detailed description of S701 to S711 is given in the foregoing embodiment, which is not repeated here.

In the embodiment of the application, the task node jointly realizes heartbeat detection and global count detection through two asynchronous coroutines, and has simple flow and wide application scene.

Next, the related flow of the interrupt detection service process is described in detail.

Referring to fig. 8, fig. 8 is a flowchart of a flow control method of a business process according to an embodiment of the application. As shown in fig. 8, the flow control method of the business process at least includes S801 to S805, which are described in detail as follows:

s801, the interrupt detection service routine transmits a query request for querying the service executor for survival information to the central markup store.

It will be appreciated that the interrupt detection service routine sends a query request to the central tag store for querying the survival information of the service executor continuously, e.g., once every 3 seconds, 5 seconds, 10 seconds, etc., to detect the survival condition of the service executor in real time, where the shorter the sending duration, the higher the timeliness of detection, and conversely, the longer the sending duration, the lower the timeliness of detection.

S802, the central mark stores survival information of the service executor returned to the interrupt detection service process based on the query request.

The survival information of the service executor comprises time stamp information sent by each heartbeat of the service executor, and the heartbeat comprises an identifier of the service executor and an identifier of a service flow to which the service executor belongs.

For example, the survival information of the service executor may be reported to the central markup store by the service executor every 5 seconds. The reporting time of the survival information can be flexibly adjusted according to specific application scenes.

S803, the interrupt detection service process detects heartbeat timeliness based on the survival information of the service executor; if the interval time period between the current time point and the timestamp information of the latest heartbeat is detected to be longer than the preset interval time period, S804 is performed, and if the interval time period between the current time point and the timestamp information of the latest heartbeat is detected to be equal to or shorter than the preset interval time period, the flow is ended.

Illustratively, taking the foregoing example, if the service executor survives (i.e., the service executor normally executes the service logic), theoretically, the interval duration between the current time point and the timestamp information of the latest heartbeat is less than or equal to 5 seconds, and if the interval duration between the current time point and the timestamp information of the latest heartbeat is greater than 5 seconds, this means that the service executor does not survive (i.e., is abnormally interrupted, the service executor does not normally execute the service logic).

In an alternative embodiment, the preset interval duration may be set to 20 seconds, so as to avoid a misjudgment phenomenon caused by overtime of the network, thereby improving accuracy of heartbeat timeliness detection.

S804, calling a task retry interface of the workflow engine based on the identification of the business process to which the business executor belongs, and starting the task node to call the business executor again based on the restarted task node to execute business logic.

S805, the workflow engine returns a task retry interface call result.

In the embodiment of the application, after the interrupt detection service process detects the abnormal interrupt of the service executor, the service executor is called again to execute the service logic, so that the normal circulation of the service flow is ensured, and the circulation control reliability of the service flow is improved.

Fig. 9 is a block diagram of a flow control apparatus for a business process according to an embodiment of the present application. As shown in fig. 9, the flow control device of the business process includes:

the first starting module 901 is configured to start a business process if a starting request for a pre-created business process in a business process engine is received, wherein the business process comprises at least two task nodes;

the obtaining module 902 is configured to obtain survival information corresponding to a service logic executor invoked by a task node to which the current flow is transferred in the service flow, where the service logic executor is used for executing service logic;

The calling module 903 is configured to, if the abnormal interrupt of the service logic executing body is detected based on the survival information, call the service logic executing body again, so as to execute the service logic again through the called service logic executing body again;

And the second starting module 904 is configured to start the next task node adjacent to the task node to which the service logic is circulated after the execution of the service logic is detected, so as to continue the circulation of the service flow.

In one embodiment of the present application, based on the foregoing scheme, the acquiring module 902 is specifically configured to:

acquiring identification information corresponding to a service logic executing body called by a task node which is transferred by a current flow in the service flow;

Acquiring survival information matched with the identification information corresponding to the acquired business logic executor from the designated storage area; the service logic executing body is used for executing the service logic, wherein the survival information of the service logic executing body stored in the designated storage area is continuously generated and transmitted by the service logic executing body in the process of executing the service logic.

In one embodiment of the present application, based on the foregoing solution, the survival information includes timestamp information sent by each heartbeat message, where the heartbeat message includes identification information of the service logic executor and identification information of a service flow to which the service logic executor belongs; the obtaining module 902 is further specifically configured to:

In one embodiment of the present application, based on the foregoing solution, after selecting, from the plurality of surviving information sets stored in the designated storage area, a surviving information set that matches identification information corresponding to the acquired service logic executor and identification information corresponding to a service flow to which the acquired service logic executor belongs, the apparatus further includes:

A calculation module configured to calculate a duration of intervals between a current point in time and a plurality of timestamp information in the selected set of survival information;

the detection module is configured to detect the survival condition of the service logic execution body based on the relation between the calculated interval duration and a preset interval duration threshold.

In one embodiment of the present application, based on the foregoing solution, the computing module is specifically configured to:

selecting timestamp information closest to a current time point from a plurality of timestamp information of the selected survival information set, and calculating interval duration between the selected timestamp information and the current time point; or alternatively

Calculating the interval duration between the current time point and each time stamp information of the selected survival information set to obtain a plurality of interval durations, and selecting the interval duration with the minimum interval duration from the plurality of interval durations.

In one embodiment of the present application, based on the foregoing solution, the detection module is specifically configured to:

And if the calculated interval duration is equal to or smaller than the preset interval duration threshold, obtaining a detection result used for representing normal execution of the service logic execution body.

In one embodiment of the present application, based on the foregoing scheme, the apparatus further includes:

The receiving module is configured to receive the execution completion notification information sent by the service logic execution body; the execution completion notification information is generated after the service logic execution body executes the service logic;

And a deletion module configured to delete survival information of the business logic execution body from the specified storage area based on the execution completion notification information.

Starting a service logic execution body detection service;

In one embodiment of the present application, based on the foregoing solution, the invoking module 903 is specifically configured to:

Invoking a service retry interface of the service flow engine;

restarting the transferred task node through the service retry interface to call the service logic executor again based on the restarted task node.

In one embodiment of the present application, based on the foregoing, the apparatus further includes an exit control module configured to:

If a soft interrupt request is received, acquiring a service logic executing body in an executing state currently;

waiting for the execution of the service logic by the service logic executing body in the executing state;

and after the service logic executor in the execution state executes the service logic, controlling to exit the service flow.

In one embodiment of the present application, based on the foregoing solution, the exit control module is specifically configured to:

acquiring a quantity parameter for recording the quantity of service logic executors in an execution state; wherein the quantity parameter is obtained by increasing a specified unit quantity when each service logic executing body is called, and decreasing the specified unit quantity when each service logic executing body completes service logic execution;

If the number of the service logic executors in the execution state, which is characterized by the number parameters, is detected to be at least one, determining that the service logic executors in the execution state exist currently;

and if the quantity of the service logic executors in the execution state, which is characterized by the quantity parameters, is detected to be zero, controlling to exit the service flow.

In an embodiment of the present application, based on the foregoing solution, the exit control module is further specifically configured to:

if the trigger is detected to wait for the execution of the service logic by the service logic executing body in the executing state, recording a waiting starting time point and timing from the starting time point;

and if the detected time duration reaches the preset time duration threshold value, controlling to exit the service flow.

It should be noted that the apparatus provided in the foregoing embodiment and the method provided in the foregoing embodiment belong to the same concept, and the specific manner in which the respective modules and units perform the operations have been described in detail in the method embodiment.

The embodiment of the application also provides electronic equipment, which comprises: one or more processors; and the memory is used for storing one or more programs, and when the one or more programs are executed by the one or more processors, the electronic equipment realizes the circulation control method of the business process.

It should be noted that, the computer system 1000 of the electronic device shown in fig. 10 is only an example, and should not impose any limitation on the functions and the application scope of the embodiments of the present application.

As shown in fig. 10, the computer system 1000 includes a central processing unit (Central Processing Unit, CPU) 1001 that can perform various appropriate actions and processes, such as performing the method in the above-described embodiment, according to a program stored in a Read-Only Memory (ROM) 1002 or a program loaded from a storage portion 1008 into a random access Memory (Random Access Memory, RAM) 1003. In the RAM 1003, various programs and data required for system operation are also stored. The CPU 1001, ROM 1002, and RAM 1003 are connected to each other by a bus 1004. An Input/Output (I/O) interface 1005 is also connected to bus 1004.

The following components are connected to the I/O interface 1005: an input section 1006 including a keyboard, a mouse, and the like; an output portion 1007 including a Cathode Ray Tube (CRT), a Liquid crystal display (Liquid CRYSTAL DISPLAY, LCD), and a speaker, etc.; a storage portion 1008 including a hard disk or the like; and a communication section 1009 including a network interface card such as a LAN (Local Area Network ) card, a modem, or the like. The communication section 1009 performs communication processing via a network such as the internet. The drive 1010 is also connected to the I/O interface 1005 as needed. A removable medium 1011, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like, is installed as needed in the drive 1010, so that a computer program read out therefrom is installed as needed in the storage section 1008.

In particular, according to embodiments of the present application, the processes described above with reference to flowcharts may be implemented as computer software programs. For example, embodiments of the present application include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising a computer program for performing the method shown in the flowchart. In such an embodiment, the computer program may be downloaded and installed from a network via the communication portion 1009, and/or installed from the removable medium 1011. When executed by a Central Processing Unit (CPU) 1001, the computer program performs various functions defined in the system of the present application.

It should be noted that, the computer readable medium shown in the embodiments of the present application may be a computer readable signal medium or a computer readable storage medium, or any combination of the two. The computer readable medium can be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or a combination of any of the foregoing. More specific examples of the computer-readable medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-Only Memory (ROM), an erasable programmable read-Only Memory (Erasable Programmable Read Only Memory, EPROM), a flash Memory, an optical fiber, a portable compact disc read-Only Memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the context of this document, a computer readable medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In the present application, however, a computer-readable signal medium may include a data signal propagated in baseband or as part of a carrier wave, with a computer-readable computer program embodied therein. Such a propagated data signal may take any of a variety of forms, including, but not limited to, electro-magnetic, optical, or any suitable combination of the foregoing. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. A computer program embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. Where each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.

The units involved in the embodiments of the present application may be implemented by software, or may be implemented by hardware, and the described units may also be provided in a processor. Wherein the names of the units do not constitute a limitation of the units themselves in some cases.

Another aspect of the present application also provides a computer readable medium having stored thereon a computer program which, when executed by a processor, implements a flow control method for a business process as before. The computer-readable medium may be included in the electronic device described in the above embodiment or may exist alone without being incorporated in the electronic device.

Yet another aspect of the application provides a computer program product or computer program comprising computer instructions stored in a computer readable medium. The processor of the computer device reads the computer instructions from the computer-readable medium, and the processor executes the computer instructions, so that the computer device performs the flow control method of the business processes provided in the above embodiments.

The foregoing is merely illustrative of the preferred embodiments of the present application and is not intended to limit the embodiments of the present application, and those skilled in the art can easily make corresponding variations or modifications according to the main concept and spirit of the present application, so that the protection scope of the present application shall be defined by the claims.

Claims

1. The method for controlling the circulation of the business process is characterized by comprising the following steps:

If a starting request for a service flow pre-established in a service flow engine is received, starting the service flow, wherein the service flow comprises at least two task nodes;

Obtaining survival information corresponding to a service logic executor called by a task node which is turned to by a current flow in the service flow, wherein the service logic executor is used for executing service logic;

If the abnormal interruption of the service logic executing body is detected based on the survival information, the service logic executing body is called again, so that the service logic is executed again through the called service logic executing body;

after the service logic is detected to be executed, starting the next task node adjacent to the task node to which the service logic is transferred so as to continue the transfer of the service flow;

the obtaining survival information corresponding to the service logic executor invoked by the task node to which the current flow is transferred in the service flow includes:

acquiring survival information matched with the identification information corresponding to the acquired business logic executor from the designated storage area; the service logic executing body is used for executing the service logic, wherein the survival information of the service logic executing body stored in the designated storage area is continuously generated and transmitted by the service logic executing body in the process of executing the service logic;

The survival information comprises time stamp information sent by each heartbeat message, and the heartbeat message comprises identification information of the service logic executing body and identification information of a service flow to which the service logic executing body belongs;

The obtaining survival information matched with the identification information corresponding to the obtained business logic execution body from the appointed storage region comprises the following steps:

2. The method according to claim 1, wherein after selecting the set of surviving information that matches the identification information corresponding to the acquired business logic executor and the identification information corresponding to the business process to which the acquired business logic executor belongs from the plurality of sets of surviving information stored in the designated storage area, the method further comprises:

And detecting the survival condition of the business logic executive body based on the relation between the calculated interval duration and a preset interval duration threshold value.

3. The method of claim 2, wherein calculating the duration of the interval between the current time point and the plurality of timestamp information in the selected set of survival information comprises:

4. The method of claim 2, wherein detecting the survival of the business logic execution body based on the relationship between the calculated interval duration and a preset interval duration threshold comprises:

5. The method according to claim 1, wherein the method further comprises:

receiving execution completion notification information sent by the service logic execution body; the execution completion notification information is generated after the service logic execution body executes the service logic;

and deleting survival information of the business logic execution body from the designated storage area based on the execution completion notification information.

6. The method according to any one of claims 1 to 5, wherein the obtaining survival information corresponding to the service logic executable invoked by the task node to which the current flow is going in the service flow includes:

Starting a service logic execution body detection service;

7. The method of any of claims 1 to 5, wherein the recalling the business logic executor comprises:

Invoking a service retry interface of the service flow engine;

8. The method according to any one of claims 1 to 5, further comprising:

9. The method of claim 8, wherein the obtaining the currently executing service logic executable comprises:

After the execution of the service logic by the service logic executing body in the execution state is completed, the control of exiting the service flow comprises the following steps:

10. The method of claim 8, wherein the method further comprises:

11. A flow control device for a business process, comprising:

The first starting module is configured to start a business process if a starting request for the business process pre-established in the business process engine is received, wherein the business process comprises at least two task nodes;

the acquisition module is configured to acquire survival information corresponding to a service logic executor called by a task node which is transferred by the current flow in the service flow, wherein the service logic executor is used for executing service logic;

The calling module is configured to call the service logic executor again if the abnormal interrupt of the service logic executor is detected based on the survival information, so as to execute the service logic again through the called service logic executor again;

The second starting module is configured to start the next task node adjacent to the task node to which the service logic is transferred after the execution of the service logic is detected, so as to continue the transfer of the service flow;

12. The apparatus of claim 11, wherein the apparatus further comprises:

13. The apparatus of claim 12, wherein the computing module is specifically configured to:

14. An electronic device, comprising:

One or more processors;

A memory for storing one or more programs that, when executed by the electronic device, cause the electronic device to implement the flow control method of the business process of any of claims 1-10.

15. A computer readable medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements a flow control method of a business process according to any one of claims 1 to 10.

16. A computer program product comprising computer instructions which, when executed by a processor, implement a flow control method of a business process according to any one of claims 1 to 10.