CN112712335B

CN112712335B - Working method, medium and equipment of workflow engine

Info

Publication number: CN112712335B
Application number: CN202011599921.6A
Authority: CN
Inventors: 王亚飞; 周启航; 高令强
Original assignee: Beijing Yusys Technologies Group Co ltd
Current assignee: Beijing Yusys Technologies Group Co ltd
Priority date: 2020-12-30
Filing date: 2020-12-30
Publication date: 2021-12-10
Anticipated expiration: 2040-12-30
Also published as: CN112712335A

Abstract

The embodiment of the invention provides a working method, a medium and equipment of a workflow engine, wherein the method comprises the following steps: receiving a submission request for a current node; acquiring a handling mode of the current node; when the handling mode of the current node is a first multi-user handling mode, further acquiring a transfer condition configured corresponding to the first multi-user handling mode; judging whether the transfer condition is met; and when the transfer condition is met, ending the current node in advance, and transferring the data stream to be processed to a subsequent node of the current node. Therefore, whether the business needs to be submitted in advance can be determined by self-definition, the handling efficiency is improved, and the requirements of specific business scenes are met.

Description

Working method, medium and equipment of workflow engine

Technical Field

The invention relates to the Internet technology and the financial technology, in particular to a working method, a medium and equipment of a workflow engine.

Background

The concept of workflow originates from the field of production organization and office automation, is a concept mainly proposed for activities with fixed programs in daily life, and aims to decompose work into a series of well-defined tasks and execute the tasks according to certain rules and processes, so that the production efficiency is improved, the production cost is reduced, the production, operation and management level and the enterprise competitiveness of enterprises are improved, and the workflow engine is increasingly frequently applied to a software system along with the development of office automation. The workflow engine is generated for rapidly developing an approval-type software system. Currently, the workflow engines of the open sources in the market are all sourced from foreign countries, such as: JBPM, Activiti, etc. The workflow engine is one of indispensable products in the financial industry, particularly in the credit field, and the localization of the workflow engine is beneficial to guaranteeing the national financial security.

In the process of implementing the invention, the inventor finds that at least the following problems exist in the prior art: the workflow engine in the prior art cannot determine whether to submit in advance through self definition in a plurality of handling modes, is low in handling efficiency, and cannot meet requirements of specific business scenes.

Disclosure of Invention

In view of this, embodiments of the present invention provide a working method, a server, a medium, and a device of a workflow engine, so as to determine whether to submit in advance by customization, improve handling efficiency, and meet requirements of specific service scenarios.

In a first aspect, an embodiment of the present invention provides a method for operating a workflow engine, where the method includes:

receiving a submission request for a current node;

acquiring a handling mode of the current node;

when the handling mode of the current node is a first multi-user handling mode, further acquiring a transfer condition configured corresponding to the first multi-user handling mode;

judging whether the transfer condition is met;

and when the transfer condition is met, ending the current node in advance, and transferring the data stream to be processed to a subsequent node of the current node.

In a second aspect, an embodiment of the present invention provides a server of a workflow engine, including:

a receiving module, configured to receive a submission request for a current node;

the first acquisition module is used for acquiring the handling mode of the current node;

a second obtaining module, configured to further obtain a transfer condition configured corresponding to the first multi-user transaction mode when the transaction mode of the current node is the first multi-user transaction mode;

the judging module is used for judging whether the transfer condition is met;

and the circulation module is used for finishing the current node in advance and circulating the data to be processed to the subsequent node of the current node when the transfer condition is met.

In a third aspect, an embodiment of the present invention provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the computer program implements a working method of the workflow engine.

In a fourth aspect, an embodiment of the present invention provides a computer device, including:

one or more processors;

storage means for storing one or more programs;

the one or more programs, when executed by the one or more processors, cause the one or more processors to implement the method of operation of the workflow engine.

The technical scheme has the following beneficial effects:

the embodiment of the invention receives a submission request aiming at the current node; acquiring a handling mode of the current node; when the handling mode of the current node is a first multi-user handling mode, further acquiring a transfer condition configured corresponding to the first multi-user handling mode; judging whether the transfer condition is met; when the transfer condition is met, the current node is ended in advance, and the data flow to be processed is transferred to a subsequent node of the current node; therefore, whether the business needs to be submitted in advance can be determined by self-definition, the handling efficiency is improved, and the requirements of specific business scenes are met.

Drawings

In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present invention, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

FIG. 1 is a workflow engine architecture and distributed performance diagram of an embodiment of the invention;

FIG. 2 is a schematic block diagram of a web-version flowchart modeling tool according to an embodiment of the present invention;

FIG. 3A is a flow chart of a method of operation of a workflow engine according to an embodiment of the invention;

FIG. 3B is a flowchart of a method of operation of the workflow engine of an embodiment of the present invention;

FIG. 3C is a flow chart of a method of operation of the workflow engine of an embodiment of the present invention;

FIG. 3D is a flow chart of a method of operation of the workflow engine of an embodiment of the present invention;

FIG. 3E is a flow chart of a method of operation of the workflow engine of an embodiment of the present invention;

FIG. 4 is a workflow engine state machine core flow logic diagram of an embodiment of the present invention;

FIG. 5 is a flow diagram of the workflow engine state machine S217 of an embodiment of the present invention;

FIG. 6 is a detailed flow diagram of the workflow engine state machine S2 according to an embodiment of the invention;

FIG. 7 is a detailed flow diagram of the workflow engine state machine S5 of an embodiment of the invention;

FIG. 8 is a detailed flow diagram of the workflow engine state machine S12 of an embodiment of the present invention;

FIG. 9 is a table-partitioned storage diagram of an exemplary flow of an embodiment of the present invention;

FIG. 10 is a schematic diagram of the main functions of a workflow engine according to an embodiment of the invention;

FIG. 11 is a functional block diagram of a server of a workflow engine of an embodiment of the present invention;

FIG. 12 is a functional block diagram of a storage medium of an embodiment of the present invention;

fig. 13 is a functional block diagram of a server of an embodiment of the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

The financial industry has strong national attributes, different countries have own financial approval systems, the workflow is mainly used for process approval, and the workflow engine integrates all the process approval actions in China at present and is an approval software function development tool suitable for Chinese characteristics.

The access flow of the workflow engine which is independently deployed as a service is larger and larger, and the workflow engine provided by the embodiment of the invention is light in weight and has distributed capacity expansion capability.

The existing open-source workflow engine process modeling tools are all based on development tools such as Idea and eclipse, and the workflow engine process modeling tool provided by the embodiment of the invention is provided for developers in a web page mode and can be embedded into a software product and provided for business personnel to use.

Aiming at a complex service development scene, the workflow engine of the embodiment of the invention supports custom extension.

Workflow engine architecture and distributed capabilities:

FIG. 1 is a workflow engine architecture and distributed performance diagram of an embodiment of the invention. As shown in fig. 1, the workflow engine supports cluster deployment, and when the cluster deployment is performed, the cluster deployment is registered in the same registry, and load balancing is performed through the gateway. When the cluster is deployed, communication between services is completed through MQ (Message Queue) middleware.

A workflow engine process WEB version modeling tool:

the process modeling tool based on the web page can be embedded into a software system and can be used by developers and business personnel. FIG. 2 is a schematic block diagram of a web version flowchart modeling tool according to an embodiment of the present invention. And combining the VUE framework and the mxGraph component, and accessing an attribute extension module of the workflow engine. As shown in fig. 2, the flow modeling tool is a web-side visual modeling page developed by combining an vue framework (progressive framework for building user interfaces) and an open-source JS library component mxGraph (web-based JS library component for rendering flow diagrams). Page elements and interactive functions in the page are realized through vue, and the functions of the specific construction flow chart are defined by calling a function API provided by an mxGraph library component; meanwhile, the attribute extension module of the workflow engine is accessed, so that the attribute configuration is more flexible. The workflow engine refers to a server, is a micro-service deployed on a server, provides various functional APIs for workflow operation, and completes a series of operations of the workflow by calling the APIs.

Example one

Fig. 3A is a flowchart of a method for operating a workflow engine according to an embodiment of the present invention. As shown in fig. 3A, it includes the following steps:

s110: receiving a submission request for a current node;

s120: acquiring a handling mode of a current node;

s130: when the handling mode of the current node is a first multi-user handling mode, further acquiring transfer conditions correspondingly configured to the first multi-user handling mode;

s140: judging whether the transfer condition is met;

s150: and when the transfer condition is met, the current node is ended in advance, and the data to be processed is transferred to the subsequent node of the current node.

The above-mentioned branch condition is not fixed, and the branch condition supports a custom extension, including but not limited to any one of the following:

a first transfer condition comprising: the current submitter confirms that the current node is ended in advance;

second transfer conditions comprising: completing the transaction of the current node by one or more designated transactants;

third transfer conditions comprising: and finishing the handling of the current node by a preset number of handling persons.

Fig. 3B is a flowchart of a method of operating the workflow engine according to the embodiment of the present invention. As shown in fig. 3B, in some embodiments, the method may further comprise:

s160: when the transaction mode of the current node is the second multi-user transaction mode, judging whether the current submitter is the last transactor correspondingly configured in the second multi-user transaction mode; the second multi-person transaction mode includes: a multi-person sequential or multi-person parallel transaction mode; in the mode of being handled in parallel to many people, only do not have fixed order of handling between a plurality of people of handling, no matter who handles earlier who handles later can all handle, nevertheless according to handling time difference still can have certain order.

S170: and if the current submitter is the last transactor configured corresponding to the second multi-user transaction mode, submitting the data to be processed to a subsequent node of the current node so as to perform the circulation process between the nodes.

S180: and if the current submitter is not the last transactor correspondingly configured in the second multi-user transaction mode, executing the circulation process in the current node.

Fig. 3C is a flowchart of a working method of the workflow engine according to the embodiment of the present invention. As shown in fig. 3C, in some embodiments, submitting the data to be transacted to a subsequent node of the current node in S170 to perform a flow process between nodes, which may specifically include:

s172: judging whether a subsequent node to be submitted is appointed;

s174: if not, acquiring a subsequent node of the current node and the transactor configured correspondingly by the subsequent node; then, circularly submitting to each subsequent node in the subsequent nodes;

s176: if so, the commit is made directly to each of the subsequent nodes in a loop.

Fig. 3D is a flowchart of a method for operating the workflow engine according to an embodiment of the present invention. As shown in fig. 3D, in some embodiments, submitting to each of the subsequent nodes in S174 may specifically include:

s174-1: it is determined whether the subsequent node to which the submission is made is an end node.

S174-2: if the subsequent node to be submitted to is the end node, migrating the data related to the process instance from the running state table to the transaction table, and deleting the data in the running state table; specifically, the step migrates the data (e.g. flow, node, transactor, opinion) related to the flow instance from the run state (to-do, done) table to the transaction table, and deletes the data in the run state table. The end node is a part of the subsequent node, and the end node is submitted to the end node to represent that the whole flow circulation process is ended, and the additional data processing is required. The process instance refers to a set of flow data in the workflow engine.

S174-3: and detecting whether the flow of the current circulation is a sub-flow.

S174-4: if the sub-process is the sub-process, further judging whether the main process corresponding to the sub-process is in a suspended state, and if the main process is in the suspended state, awakening the main process. The sub-process is a complete process and a new process initiated at a certain node of the main process.

Fig. 3E is a flow chart of a method for operating the workflow engine according to an embodiment of the present invention. As shown in fig. 3E, in some embodiments, the executing the circulation process in the node inside the current node in step S180 may specifically include:

s181: copying the records related to the submitters in the to-do record list of the staff to the handled record list of the staff;

s182: and deleting the record related to the submitter in the personnel to-do record list.

S183: and judging whether the mode is a multi-person sequence handling mode.

S184: if so, the user level of the next transactor to the current submitter of the current node is set to be lowest so that the next transactor to the current submitter can view and process the transaction data.

S185: if not, the flow ends.

FIG. 4 is a workflow engine state machine core flow logic diagram of an embodiment of the present invention. As shown in fig. 4, the execution subject of the flow is the server side.

S201: and submitting through a submitting interface.

S202: after commit, some of the necessary check entries obtained from the front end are checked. If the verification fails, the server end feeds back prompt information that the verification fails to pass to the front end; if the check is passed, the next step S203 is performed. Specifically, the front end calls a submission interface to return submission parameters to the server, and then the server executes the necessary check items according to the submission parameters to detect whether all necessary parameters are submitted by the front end. If the front end does not submit some necessary parameters, the server end returns prompt information to the front end to prompt which parameters are lacked, the front end is required to transmit the lacked parameters back, otherwise, the front end cannot carry out the submitting operation.

For example, when the user submits in the front end, parameters returned by the submission interface include: the primary key of a certain piece of data to be examined, the current submitter (current approver), and the information of the next node to be submitted. If the front end does not transmit the current approval numbers back to the server end, the subsequent steps such as inter-node circulation, newly added personal transaction and deleted personal transaction cannot be operated. The server end can obtain a plurality of corresponding status codes according to the detection result, for example, 0 is a successful status code, 1 is a failed status code, different status codes are pre-configured with corresponding prompt words, when the verification fails, the server end returns the failed status code to the front end, the front end inquires the corresponding prompt word according to the failed status code, and the front end displays the prompt word of the verification failure to the user.

S203: the submitting node is checked for a next node. Specifically, the submission node is an approval node where the current approver is located. According to the definition of the flow chart, the flow approval comprises a plurality of nodes, and the specific execution is to be implemented to the transactants of the nodes. If the submitted node is determined to have no next node through verification, the server end feeds back prompt information to the front end; if it is determined through the check that the commit node has the next node, step S204 is performed. Specifically, whether the submitting node has the next node is checked through the flow chart definition content. The flow circulation is executed according to the nodes defined by the flow chart, each node has the following nodes, and the flow chart is defined by which nodes point to the node. Since the commit function is to be transferred to the subsequent node, the function cannot be continuously executed without the subsequent node. Such a scenario may occur when some of the flow charts are damaged or nodes of the flow charts are added or deleted.

S204: and acquiring process instance information. In the step, the detailed information of the data can be obtained from the database according to the primary key of the batch of data to be examined selected by the user through list display at the front end, so that the current transactor of the data can be known.

Specifically, the process instance information includes: flow chart related information, a sponsor, form parameters, recently approved node information, recently approved transactor information and the like; and, all information associated with the primary key. The flow instance information is flow instance information of the entire flow. The process instance information will be used in subsequent steps. The process instance information can be queried from a correlation table.

S205: and acquiring information of all transactants of the current node. Specifically, the current node and the commit node are all operating nodes. All the transactor information of the current node can be acquired from the transactor to-do list.

S206: and judging whether the initiator of the submitting action is the current transactor of the data. The information of the initiator submitted by the current point is used as a parameter to be transmitted to the server side, and the server side judges whether the initiator is the current transactor of the data. Specifically, it is determined whether all the clerk information inquired in step S205 includes the current operator. If not, the following series of operations are not carried out, and the prompt information is returned to the front end: you are not the current transactor. If the current submitter is the current transactor for the pending data, the process continues to step S207.

S207: and the server side updates the process parameters. The front end can transmit parameters needed by some services to the workflow engine, and then the server end updates the parameters. Specifically, the process parameter is a field of a business form that needs to be temporarily stored in the workflow engine, a string is spliced into a fixed field that is stored in an instance table, and the fixed field is not a parameter in the process. For example, according to the business requirement, which fields need to be stored, the fields are put in json format fields and transmitted back to the server end through front-end processing, the server end converts the json into Map, and then the Map is converted into character strings and stored in a table; each time a new transfer back is committed, it is updated into this string.

S208: and recording the approval opinions. Some examination and approval opinions filled in when the transactor examines and approves are transmitted back to the server side through the interface, and the server side records the examination and approval opinions into the opinion list.

S209: a decision is made whether it is the last handler. In this step, a variable isLastOne can be defined to represent whether the last transactor is present, the initial value is true, and the following judgment is carried out:

inquiring the number of transactants in the current process, and if the number of transactants in the current process is equal to 1, setting isLastone to true; if the transaction type is more than 1, if the transaction type is single sign-off transaction or single competition transaction, no matter how many people to be handled exist, the last handler needs to be forcibly submitted, namely isLastOne is true; if the transaction type is that the sequence of a plurality of people can be finished or the parallel of a plurality of people can be finished, the front end designates that isLastOne is set to true when the front end finishes in advance, and if not, isLastOne is set to false; if the transaction type is multi-person parallel conditional transition, S210 is executed, otherwise, isLastOne is set to false, and S211 is executed.

S210: a branch condition is executed. And (4) running the transfer condition under the condition transfer transaction mode by multiple persons in parallel to judge whether the advance transfer is met. If so, the isLastOne defined in step S209 is set to true, and the unsatisfied value is set to false. S211 is executed after the execution is completed. In some embodiments, a node may be configured to be handled by multiple people, there is a mode that the transactants do not have to execute all the tasks, a condition may be configured, and when the condition is satisfied, the current node may be ended in advance and then the flow is performed to the next node. If the transaction type of the node configuration is single-person sign-off or single-person competition, the node configuration belongs to a single-person transaction mode. Without going through the test, it can be determined that the submitter must be the last handler.

The conditional transfer function of the multi-person approval mode is described below:

as an example: in a multi-person sequence or multi-person parallel mode, the approver is provided with an option to ask whether to end in advance. As an example, for example: A. b, C three transactants approve at a certain node, if a multi-person transaction is configured and the mode can be ended in advance, then A provides a popup window to A at the time of submission to inquire whether A is ended in advance, and A has the right to end the multi-person transaction node in advance and submit to the next node although A is not the last transactant in the three persons. For example, in some business scenarios, the authority of A in A, B, C three transactants is greater, and when A approves the application, it can be decided B, C to end the application in advance and submit to the next node.

As another example, in the multi-user transaction mode, a transition condition may be additionally configured in advance, and the transition may be performed according to the transition condition. This transfer condition may define: when the approval of a specific one or some approvers among the plurality of approvers is completed, the node can be ended in advance. And executing the transfer condition, if the execution result is true, indicating that the preset transfer condition is met, forcibly submitting to the next stage, and not waiting for all people to finish the transaction.

As yet another example: some business scenes need to be examined and approved by multiple persons, many examining and approving persons are appointed, but if each examining and approving person needs to be examined and approved and then submitted, much time can be wasted, and some business scenes sometimes do not need all persons to complete the examination and approval. For example, the branch conditions may be set as: and if 5 approvers among 10 approvers approve, the approvers are regarded as final approval. Therefore, the requirements of certain service scenes can be met, different service scenes can be flexibly adapted, and people who meet the conditions can complete examination and approval, so that the examination and approval efficiency can be improved.

S211: it is judged whether it is the last handler. In this step, the decision result of step S209 is determined, and if the isLastOne field is true, the representative is the last transactor, and the processing is submitted to the next node, and if false, the representative is not the last approver, and the flow processing in the node is executed. This step determines whether the current submitter is the last handler of the submission node. This step determines whether the transactants submitting the node have been completely approved. A node can be configured with a plurality of persons for examination and approval, whether a current submitter belongs to the last handler of the node is judged firstly, if the current submitter is not the last handler of the node, the circulation logic in the node is called, and if the current submitter is the last handler of the node, the circulation logic between the nodes is called, and data is migrated to the next node. The circulation in the node is as follows: the workflow has a plurality of nodes, one node in each approval step of the business can be approved by multiple persons, namely, a plurality of transactants are configured, and the node calculates that the business step is completed after the approval of the transactants is completed. Before the node approval is completed, the node is circulated, namely, circulated among each transactor in the node. The circulation in the node is mainly to perform some updates on the data. For example, the user who has acquired the data before transaction is updated to the personnel needing to be examined and approved in the next step in the node, then the data state of the current submitter is updated to be handled, and the data to be handled of the current submitter is deleted. The flow process in the node includes steps S212, S213, S214, S215.

The transaction types are described in detail as follows:

signing by a single person: when the number of the transacting personnel of the node is multiple, the process instance becomes the exclusive to-do of the signing user only after one user signs; if only one transactor is present in the node, the flow instance does not need to sign in; the signoff may also revoke the signoff.

Single person competition: when the number of the staffs capable of being handled by the node is multiple, the user can handle all the staffs without signing, but after one person submits the staffs, other staffs capable of being handled can not submit the staffs.

Multiple people transact in sequence: the node can be handled by multiple persons, and the multiple persons can be handled one by one according to the sequence selected by the personnel handling the node; the multi-person sequential transaction node must wait for all transaction users to submit before the node can submit to the next node.

Multiple people handle in parallel: the node can be handled by multiple persons, the multiple persons do not have sequence, the multiple persons can be handled in parallel, and the multiple persons can handle the node in parallel only after all the handling users submit the node, the node can submit the node to the next node.

And (3) transferring by multiple persons in parallel according to conditions: the branch condition needs to be configured, the node is handled in parallel according to multiple persons, but the node is migrated when the value returned by the branch condition is true (true).

The multi-person sequence may end: the same multiple person sequence transaction is similar except that the node may end the submission ahead of time, not waiting for all persons to commit.

Multiple people in parallel can end: the same person transacts similarly in parallel, except that the node may end the submission ahead of time, waiting for all to commit. The front end has an early ending option, and the transactor can select to finish the submission when submitting, so that the file can be directly submitted to the next node without waiting for the completion of the transaction of all the transactors.

In some embodiments, when the transaction type is "single sign-on transaction" or "single competition," the forced submission is performed regardless of how many people are to be handled, and the forced setting is the last handler. Specifically, the examination and approval of the current node can be completed only by one person for signing or competition by one person; in the mode, the number of the transactants of the current node can be still multiple, but only one person is needed for submitting, so when the submitting action occurs, the number of the transactants of the current node is not needed to be detected, and because one person already approves and submits, the submitter is the last handler.

The front-end specifies a forced commit, which takes effect when the transaction type is "order by multiple can end" or "parallel by multiple can end", and the front-end may select true and false. Specifically, in the multi-person handling mode, one or more persons can finish in sequence or in parallel, and in the mode, the front end has an option for finishing in advance when submitting, and the left number of approvers cannot be considered when selecting true; the transactor, approver, and handler described herein are the same concept.

S212: the new user is already in the office. The step is a personnel list related data migration step: and migrating the record related to the submitter in the staff to-Do list to the staff-Do list.

S213: and deleting the user to be dealt with.

FIG. 9 is a block diagram of an exemplary process flow of storing data in tables, according to an embodiment of the present invention. As shown in FIG. 9, the data for one process instance is stored in three sets of tables: an instance table, a node table, and a personnel table. Each table contains at least an instance number as a primary key, representing the data belonging to one process instance.

The data related to the personnel handling in the process example is stored in a personnel table and is divided into a personnel to-be-handled record table, a personnel handled record table and a personnel handling record table (a history table) according to different states. For example, a staff to-be-handled form exists for the current staff handling in the process example, after the current staff handling is completed (submitted), the corresponding data is migrated to the staff-handled form, and after the whole process is completed, the staff records related to the process in the staff-handled form are migrated to the staff-to-be-handled form.

The same is true for the node table, and the related data of the nodes in the process example is mainly stored, and is divided into three tables according to the states: a node to-do list, a node already-done list and a node transaction list. The node to-Do table stores node data, which includes: current node, previous node, next node.

Other data in the process example are stored in an example table, and are divided into the following steps according to the states: a run record table (run instance table) and a transaction record table (transaction instance table). The operation example table has flow data including service type, status, etc.

Additionally optionally, a run instance opinion table and a transact instance opinion table are included.

And migrating the data in the circulation, copying the original to-do records to the already-done list, deleting the original to-do records, and adding new to-do records.

And (4) ending data migration in a flow transfer manner, copying all the already-processed records of the nodes and the personnel to the corresponding handling table when the whole flow is ended, copying the running examples and the opinions to the handling table, and deleting the original records.

In the process of flow circulation, a node table and a personnel table are mainly operated, the circulation in the node is only the operator table, the circulation between the nodes still needs to operate the node table and the personnel table, and the submission is finished.

The migration comprises the following steps: after the submission of the examination and approval action is executed, the records of the to-be-handled list are copied and inserted into the already-handled list, and then the records of the to-be-handled list are deleted. Steps S212 and S213 are the corresponding migration procedures.

Specifically, for example: the transactor has three tables (staff tables) which are respectively: a staff to-be-handled list, a staff already-handled list and a staff-to-be-finished list. Accordingly, the node has three tables (node tables), which are: a node to-do list, a node already-done list and a node transaction list. When the examination and approval personnel examine and approve certain data, the data is stored in the to-be-handled list, after the data is handled, the data is migrated and stored in the to-be-handled list, and after the whole examination and approval is finished, the data can be migrated to the handling list. When the data is submitted, a certain transactor approves the data, after the data is transacted, the state of the data is updated, the related data is newly added into the office list, and then the related data is deleted from the office list. In this way, the already-committed data can be viewed within the already-committed list.

S214: judging whether the mode is a multi-person sequence handling mode or the mode can be ended, if so, executing the step S215 to obtain other to-be-handled persons, and updating the user grade of the next to-be-handled person to be zero after the last to-be-handled person is approved and submitted so that the next to-be-handled person can handle or approve the data to be handled; if not, the flow of the flows in the nodes is ended. Specifically, the multi-person sequential transaction mode has a certain order, so the transaction levels of the remaining transactants need to be updated. The multiple person sequence ending transaction mode additionally provides an option of manual ending, and is also substantially processed in the multiple person sequence transaction mode.

S215: and acquiring other backlogs, and updating the grade of the minimum user to be zero.

Specifically, if the current transaction mode or transaction type is a multiple-person sequential transaction mode or a multiple-person sequentially-closeable mode, the multiple approvers may perform transactions in a certain order or a user-preconfigured order. For example, there are A, B, C three transactants, a transacts first, B cannot see the data when a transacts, B cannot see the data until a transacts, B cannot transact until C does not see the data, and C cannot see and transact the data until B transacts. The data has a parameter, for example: the user level is user level, the lower the user level is, and the lower the user level is, the priority is higher. In the multi-person sequential transaction mode, after one transactor completes the transaction, the levels of the other transactants which are not in the process need to be updated. For example: A. b, C the current transaction type is multi-person sequence transaction, the selected transaction sequence is A, B, C, when the data is distributed to the three transactants, the class A is 0, the class B is 1, the class C is 2, only the transactant with class 0 can see the data (e.g., approval of loan funds). After the approval of A is submitted, the remaining B and C levels are 1 and 2 respectively, and at this time, B, C cannot see the data to be processed, so the level parameter of B, C is updated, the level of B is updated to 0, and the level of C is updated to 1. Thus B with a level of 0 can see and process the pending data. After B is transacted, the server side updates the user level of C to 0, so that C with the user level of 0 can see and process the data to be transacted.

Step 216 to step 222 belong to the flow process between nodes.

S216: and carrying out the circulation among the nodes, and initializing the data from the current node to the next node. It is determined whether a node to be submitted to is specified, and if not, step S217 is performed, and if so, step S218 is performed.

S217: if the workflow engine determines that the front end does not specify the node to be submitted in step S216, the workflow engine calls the function of acquiring the subsequent node in the workflow engine to acquire the subsequent node and the corresponding clerk. When the node type is conditional single selection or conditional multiple selection, an online script needs to be run to determine whether to return or not. Conditional single selection is the selection of one commit from the successor nodes (front-end page selection) and conditional multiple selection is the selection of one or more commits from the successor nodes. Conditional single-selection and conditional multiple-selection are single-selection and multiple-selection modes, and provide additional routing conditions to judge whether subsequent branches are available. The routing condition is that a section of executable Java script configured on the connection line between the nodes has a running result of true or false, the connection line is enabled to pass when the running result is true, namely the connection line can be submitted to a subsequent node connected by the connection line, and the false represents that the connection line is disabled to pass. After the single-selection mode or the multiple-selection mode, a plurality of nodes are generally connected for selection and submission, and after the routing condition is added, the nodes can be selected and submitted according to the configured Java script screening, so that the purpose of controlling the flow trend is achieved. After the execution of step S217 is completed, the process proceeds to step S218.

S218: the loop processes each node to be committed to. See fig. 5 for details of the internal logic of S218.

S219: new individuals have been added.

S220: and deleting the personal backlog.

S221: the new node is added.

S222: and deleting the node to be dealt with.

Specifically, steps S219 to S222 specifically include: submitting node data migration: transferring the relevant data of the personnel to-be-handled record list of the submitter to the personnel-handled record list; and migrating the related data in the node to-do record table of the submitting node to the node-done record table.

S223: and the whole submission flow is finished, and a submission result is returned to the front end. The returned front end result contains information such as a result code (0-success, 1-failure), the name of the submitted node, the name of the transactor and the like.

As shown in fig. 5, the internal logic flow of S218 may include the following processing steps:

single node commit begins.

S1: and (4) circularly submitting the operation to each node, wherein each time one node is operated, firstly, whether the next node to be submitted is an end node or not is judged, and if the next node to be submitted is submitted to the end node, the step S2 is executed, and the whole process is ended. The end node is a symbolic node, unlike other approval nodes, and the end node has no configuration such as an approver.

S2: when it is determined that the commit node is the end node, end node processing is performed. As shown in fig. 6, it includes the following steps:

s21: deleting the flow instance and migrating to the history list;

s22: migrating the worked and/or opinions to a history list; this step migrates data related to these to-Do or already-Do tables to the transaction table, i.e., to the history table. This is mainly a migration of data, because after the transaction is finished, some data in the to-Do list is migrated to the history list (i.e. the end list), and then the data in the to-Do list is deleted.

In the step, all the instance table data, the node table data, the personnel table data and the opinion table data need to be subjected to data migration; the running status table (pending, done) is migrated to the transaction status table (history table).

The steps S21-S22 may be summarized as data migration steps:

when submitting to the end node or performing a denial operation, migrating the running state data to the end node, which specifically includes:

migrating the data of the operation instance table and the opinion table to a corresponding history table;

the data of the node to-be-handled record list and the personnel to-be-handled record list are migrated to the handled list, and then all relevant records of the handled list are migrated to the corresponding handling list.

S23: processing a notification service; optionally, the method further comprises notifying the calling service processing. The service processing is an extended function, and is used for performing additional processing on service data, wherein only one-step call notification is provided, and whether the service processing is performed or not is executed according to specific configuration.

S24: the main process is awakened. And judging whether the current flow is a sub-flow, if so, checking whether the main flow corresponding to the sub-flow is in a suspended state (the flow in the suspended state cannot be examined and approved), and if so, awakening the main flow. When the sub-processes are synchronous sub-processes, the main process is suspended after the sub-processes are initiated, the sub-processes are circulated firstly, and the main process is circulated only after the sub-processes are circulated. So that a step of judgment processing is required here, and the processing for submitting to the end node is ended.

Specifically, whether the present flow is a sub-flow is checked first; the instance number is the primary key of the flow instance, the primary instance number is the instance number of the primary flow, if the instance number is the same as the primary instance number, it is not a sub-flow, if it is different, it is a sub-flow.

S3: if the submitting node is judged to be not the end node, the submitting node is judged to be the approval node, the approval node is provided with a corresponding approver, a handler submitted by the front-end page is obtained at this time, and if the handler submitted by the front-end page is absent or absent, the step S5 is executed; if the handler submitted by the front-end page is specified by the system, i.e., the configured "specified manner" is system specification, then step S5 is executed; if the processing person of the front-end page submission is other, i.e., the configured "specified manner" is list selection, indicating that the processing person is submitted, step S4 is executed. In this embodiment, the approval node is configured with an approver, and the approver needs to be processed.

S4: and acquiring basic information such as personnel names. Step S6 is performed after step S4. Specifically, the system is a workflow engine, the system specification is a configuration item of the attribute "specifying mode" of the node, when the configuration is the system specification, a specific transactor does not need to be selected at the front end, and the workflow engine is the owner of the node configuration by default. The "specify mode" options include: the method comprises the following steps of 'personnel list selection', wherein the front end can display all persons configured on nodes in a list and can select from the persons; the system is appointed, the front end returns a special character, and the workflow engine determines to acquire all the persons configured by the nodes according to the special character.

If the configured specified mode of the handler submitted by the front end page is list selection, the basic information of the person is acquired. Specifically, the list selection is to select one or more of all the persons configured on the front-end list display node, and only the ID of the selected person is needed when the ID is returned to the server through the submission interface, so that the basic information (such as name, mail, telephone, and the like) of the person or persons needs to be searched out according to the ID for subsequent use; the IDs are stored in a database table in association with their corresponding base information.

S5: the workflow engine compute node handlers. Step S6 is performed after step S5. As shown in FIG. 7, in some embodiments, the process of the workflow engine computing the transactor for the subsequent node may include: judging whether the subsequent nodes are configured with rework personnel or not; if the rework personnel are configured, acquiring the last transactor of the subsequent node; judging whether the last transactor of the subsequent node is empty or not; when the last transactor of the subsequent node is empty or the subsequent node is not configured with the rework personnel, acquiring the transactors according to the processing object configured by the subsequent node, and filtering and screening the acquired transactors according to a pre-configured personnel allocation rule; and when the last transactor of the subsequent node is not empty, filtering and screening the final transactor directly according to a pre-configured personnel allocation rule.

Further, the specific processing procedure of step S5 may include the following steps:

s51: and judging whether the node reworking personnel is the last transactor. If so, go to step S52; if not, step S54 is performed. And judging whether the node is configured with rework personnel. The re-office worker selects and configures the 'last office worker', the already-handled history of the node needs to be acquired first, and the node office worker is directly set as the already-handled worker. Specifically, if the "re-office worker" is configured with the last transactor, whether a record exists in the personnel already-handled record list is queried according to the ID of the node to be submitted, and if the record indicates that the next node has been transacted, the queried last transactor is taken as the personnel to be submitted this time.

S52: and acquiring the handled personnel. Specifically, this step acquires the last transactor of the subsequent node. And if the selected transactor is the last transactor, acquiring the transactors transacted for the first time according to the configuration, and taking the transactors as the current approver of the step.

S53: and judging whether the staffs already handled are empty or not, namely judging whether the last person handled by the subsequent node is empty or not. When the office worker is empty, step S54 is performed. When the office worker is not empty, step S55 is performed.

S54: and acquiring the transactor according to the processing object configured by the node. Specifically, in this step, according to a transacted object configured in advance by a subsequent node, acquiring transacted staff corresponding to the transacted object, where the transacted object includes any one or more of the following: natural people, institutions, posts, roles, departments, project pools, other transacted objects determined according to a custom method.

S55: and filtering according to the personnel allocation rule or strategy. In the step, personnel allocation rules are filtered, namely the personnel are screened according to the preset personnel allocation rules, some transactants are screened out, and the final examining and approving personnel of the node are obtained after filtering. An interface for calling a personnel allocation rule or an allocation policy is provided, the specific allocation rule is defined in the implementation class of the interface and can be defined according to business needs, and no fixed personnel allocation rule exists. For example, an exemplary people allocation rule may be: and judging according to the current to-do number of the approvers, and taking the approver with the least to-do number as the approver of the next node, so that intelligent balanced order division can be realized. By providing the interface form, the embodiment of the invention can add the custom extender distribution rule according to the service rule by the developer when the service scene needs, and has high degree of freedom.

In some other embodiments, the workflow engine computing node in S5 may further include the following steps:

at the time of front-end submission, the submitter first selects which node to submit to. After the node is determined, the node is configured with a plurality of approvers, not all of the approvers need to be assigned to the node, and some persons can be selected from the node to assign the approval tasks to the nodes, so that the approvers selected at the front end are obtained firstly. If the front end does not select the approver, the process engine acquires all the configured persons of the node according to the transaction objects configured by the node and assigns the pending transaction to the persons.

The node configures a transaction object, which includes: a particular person, institution or station, or a collection of similar such, etc. When the front end does not select a specific transactor, the server end calculates transacted objects configured by the nodes, and the calculated results are used as the transactor to be submitted to. The calculation means that: according to the configured post and/or organization and the like, all people belonging to the post and/or the organization are found out and returned to the server side, namely all people under the post or the organization are found out and then fed back.

The person is processed according to the engine compute node. In this step, if the "assignment mode" is the system assignment, the front end does not need to select a specific approver, and the system will assign all the nodes configured as approvers. Namely, system billing is performed.

If the processing persons submitted by the front-end page are other, namely the configured 'appointed mode' is list selection, the front end selects specific processing persons to return to the back end, and then basic information such as the names of the persons is obtained.

S6: and (5) completing personnel information preparation and performing consignment relationship conversion. Step S7 is performed after step S6. The personnel information obtained in this step is used when data initialization is performed on the submitted nodes. Judging whether a pre-configured entrusting relationship exists or not, if so, performing entrusting conversion on the obtained transactor, and replacing the transactor conforming to the entrusting relationship with the trusted transactor according to the pre-configured entrusting relationship to obtain the final transactor of the subsequent step. The entrusting relation is configured in advance and comprises an entrusting person, an entrusted person, effective time and a service type; in the effective time, the data to be handled submitted to the client is transferred to the client and the client replaces the data to be handled; the step is to judge whether the currently obtained transactor has no corresponding entrusting relation, if so, the transactor is replaced by the entrusted person. Further, the determining whether the pre-configured delegation relationship exists may include: and searching whether a pre-configured entrusting relation exists according to the service type of the current process. If so, a delegated translation is performed, and if not, the delegated translation is not used.

S7: judging the type of the subsequent node, performing different processing according to different types of nodes, and executing steps S8-S9 when the type of the subsequent node is an automatic node; when the type of the subsequent node is the summary node, performing step S10; when the type of the subsequent node is the approval node, step S12 is performed. The collecting node is a special function node for the multiple-choice branch, and is used for collecting and waiting for the multiple-choice parallel branches separated from the multiple-choice node in front, and the collecting node can submit the multiple-choice parallel branches to the subsequent approval nodes when all the multiple parallel branches are submitted to the collecting node.

S8: and automatic node submission processing.

S9: the commit is performed to a subsequent node of the automation node. If the subsequent node is an automatic node, submitting to the next node of the automatic node; and querying the next node of the automatic nodes defined by the flow chart as a node to be submitted, designating the system as a transactor of the next node, and re-executing the single-node submitting step to submit to the next node.

S10: and judging whether other nodes to be handled pass through the summary node, if so, ending, otherwise, executing the step S11. The collecting node is used for collecting and waiting the multi-option branches at the front, and all the branches are submitted to the collecting node and then are submitted to the following nodes. If the subsequent node is a summary node, whether a node passes through the summary node is judged, if yes, the submission is not processed, and the submission process is ended. And inquiring the nodes to be handled contained in all the current records of the process from the node to be handled table, circularly judging the nodes to be handled, and judging whether the nodes are the nodes in front of the summary node according to the definition content of the flow chart. The contents of the flow chart are analyzed into a cache, and the front node or the subsequent node of one node can be judged according to the contents. Firstly, all the to-do nodes ids contained in the node to-do records belonging to the current process in the node to-do record list are inquired, and whether the to-do nodes pass through the summary node or not is judged according to the flow chart definition content in a circulating mode. If yes, the multi-option branch is not checked and approved, waiting is needed, the step S218 is finished, and the subsequent step S218 is directly performed. If not, the multi-selection parallel branch is completely approved, and the multi-selection parallel branch needs to be submitted to a subsequent node.

S11: the commit is performed to a node subsequent to the subsequent node. And if no other node passes through the summary node, inquiring the next node of the summary node defined by the flow chart as the node to be submitted, designating the system as the handling personnel of the next node, and re-executing the single-node submitting step to submit to the next node.

S12: when the node type is an approval node, data processing is performed on the submitted node. If the node is a node of other types (except for the end node) except the two nodes, the subsequent node is subjected to the submission processing continuously. As shown in fig. 8, the specific processing procedure of step S12 may include the following steps:

s121: and submitting to a subsequent node, and firstly judging whether the acquired number of the transactants of the subsequent node is more than 1.

S122: if only 1 transactor exists, initializing data; the data initialization comprises the following steps: s122-1, adding a new transacting personnel record for the personnel to-be-handled list, and S122-2, adding a new node to-be-handled record for the node to-be-handled list; s122-3 and then notifies the service process.

S123: if more than 1 transactor, judging whether the subsequent node is single-person signed-in transacting; if yes, S124 is executed to set the sign-in status of all transactants to be signed in, and S122 is executed to initialize data. When the person of transacting is more than 1, carry out corresponding special treatment according to the type of transacting different, for example single sign-on, only sign-on alone is automatic, and a plurality of people need all set up the state of waiting to sign-on, then the person of transacting can only be handled after the action is signed-on in front-end execution, and other person of transacting who does not sign-on just can not handle.

S124: and setting the sign-in states of all transactants as to-be-signed-in.

S125: if the subsequent node is not single-person sign-in transaction, judging whether the subsequent node is multi-person sequential transaction, if so, executing S126 to number the userLevel of all the transactants in sequence from 0, and then executing S122 to initialize data; when the userLevel is 0, the transactor can see and transact the data; this belongs to the special handling of multi-person sequential transactions, the sequence being the sequence in the array of transacted people. If the process is not multi-person sequential, S122 is executed to initialize data.

And ending the single-node submission process.

Workflow engine main function introduction:

FIG. 10 is a schematic diagram of the main functions of a workflow engine according to an embodiment of the invention. As shown in fig. 10, the workflow engine of the embodiment of the present invention has many functional points, which can meet various business scenario requirements:

the commit function "flows" process data from one node to the next according to the node order defined by the flow graph.

The return function is to return the flow data stream to a node that has been historically approved, such as to the previous node submitted to the node, according to the definition. Which node is backed up to support the extension.

And a return function, namely providing a node list (all nodes which are examined and approved by the history as default), selecting one node from the node list, and returning the flow data to the node for reprocessing, wherein the function belongs to purposeful rejection. The node list described above supports extended screening.

The cooperative function is that when a plurality of persons transact, one transactor is selected to be firstly approved, and then the current person approves the approved person. Optional collaborators support extended screening.

And with the transfer function, the current transactor can transfer the own to-be-handled data to another transactor, and the another transactor carries out examination and approval without examination and approval. Optional forwarders support extended screening.

And the entrusting function is used for transferring the flow data of a certain service type to the offeree to be submitted to be entrusted by the offeree according to a preset entrusting relation.

And due to the hanging function, the initiator can set the process data to be in a hanging state, and the process data cannot be checked and approved.

And (4) awakening the function, setting the flow data in the suspended state into an operating state by the initiator, and continuously examining and approving the flow data.

And the skipping function is used for 'transferring' the flow data to any selected node, and the selectable nodes default to all the nodes without the node sequence defined by the flow chart, so that the expanded screening is supported.

And the sub-process function is used for initiating a new process data in the currently running process approval step and circulating the new process data as a sub-process.

And a take-back function is adopted, so that a transactor can take the process data submitted to the next node back to the step of self approval for reprocessing.

And a copying function, wherein copying personnel can be selected during submission, the submitted process data is copied to the copying personnel, and the copying personnel views the process data on the 'my copying page'.

And the meeting/meeting function initiates a meeting for the process data, selects the processors to participate in voting and commenting, and summarizes the conclusions of all the processors to be used as the node approval result.

And a project pool function, namely, a project pool is configured in advance, the project pool can be used as a processing personnel of the node, the flow data submitted to the node are stored in the project pool, and the processing personnel associated to the project pool through the post can check the flow data in the project pool and sign for transaction.

The competition handling function is realized, a single person competes in a handling mode, a node can be provided with a plurality of handling personnel, the flow data can be seen and examined and approved, and other people cannot see and cannot examine and approve the data after the first person finishes examination and approval.

And a conditional routing function, wherein a section of Java script can be configured on the connection line as a conditional routing, and the connected node with the script running as true can be submitted.

And the parallel summarizing function can select a plurality of branches to examine and approve in parallel after the nodes are selected for multiple times, and the plurality of branches can be summarized by using one summarizing node and submitted uniformly after waiting.

And returning the initiating function and the returning function to the initiating node for re-handling.

The function of urging handling, urging the current handling personnel to handle the flow data as soon as possible, and supporting the user-defined expansion through short messages, mails and other modes.

And a rejection function finishes the approval of the whole process data in advance, and the result is disagreement.

And activating the function, namely activating the flow data after the transaction is finished into an initiating state, and transacting the flow data once again.

The intelligent order distribution function can distribute the flow data to the transactants screened by the distribution strategy in a combined mode of system designation and the distribution strategy, and the distribution strategy supports self-definition.

And (4) submitting a verification function, verifying according to certain conditions before submitting, submitting to the next step after meeting, and otherwise, not allowing to submit, wherein the conditions support custom expansion.

The technical scheme of the embodiment of the invention has the advantages that:

the web version process modeling tool is used for building a business process model, is independent of a development tool, and is attractive and simple in interface, simple to operate and easy to master.

The intelligent routing is divided, intelligent routing screening is achieved through routing conditions, approval personnel distribution is achieved through system designation and distribution strategies, and custom expansion is supported by the two modes.

And automatic approval is realized, and a personnel-free full-automatic process can be realized through automatic nodes.

And according to the transfer condition, the examination and approval of the step can be finished in advance according to a certain condition and then submitted to the next step in a multi-user handling mode, and the transfer condition can be customized.

And parallel summarization is performed, and summarization waiting is performed during parallel approval of multiple branches, so that the uniformity of data circulation is ensured.

Example two

FIG. 11 is a functional block diagram of a server of a workflow engine of an embodiment of the present invention. As shown in fig. 11, the server 300 includes:

a receiving module 310, configured to receive a submission request for a current node;

a first obtaining module 320, configured to obtain a handling mode of a current node;

a second obtaining module 330, configured to further obtain a transfer condition configured corresponding to the first multi-user transaction mode when the transaction mode of the current node is the first multi-user transaction mode;

a judging module 340, configured to judge whether the transfer condition is satisfied;

and the flow module 350 is configured to end the current node in advance when the transfer condition is met, and flow the data to be processed to a subsequent node of the current node.

It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-mentioned division of the functional units and modules is illustrated, and in practical applications, the above-mentioned function distribution may be performed by different functional units and modules according to needs, that is, the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-mentioned functions. Each functional unit and module in the embodiments may be integrated in one processing unit, or each unit may exist alone physically, or two or more units are integrated in one unit, and the integrated unit may be implemented in a form of hardware, or in a form of software functional unit. In addition, specific names of the functional units and modules are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working processes of the units and modules in the system may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

EXAMPLE III

FIG. 12 is a functional block diagram of a computer-readable storage medium of an embodiment of the present invention. As shown in fig. 12, the computer-readable storage medium 400 has stored thereon a computer program 410 which, when executed by a processor, implements:

receiving a submission request for a current node;

acquiring a handling mode of a current node;

when the handling mode of the current node is a first multi-user handling mode, further acquiring transfer conditions correspondingly configured to the first multi-user handling mode;

judging whether the transfer condition is met;

and when the transfer condition is met, the current node is ended in advance, and the data to be processed is transferred to the subsequent node of the current node.

The integrated modules/units, if implemented in the form of software functional units and sold or used as separate products, may be stored in a computer readable storage medium. Based on such understanding, all or part of the flow of the method according to the embodiments of the present invention may also be implemented by a computer program, which may be stored in a computer-readable storage medium, and when the computer program is executed by a processor, the steps of the method embodiments may be implemented. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer-readable medium may include: any entity or device capable of carrying the computer program code, recording medium, usb disk, removable hard disk, magnetic disk, optical disk, computer Memory, Read-Only Memory (ROM), Random Access Memory (RAM), electrical carrier wave signals, telecommunications signals, software distribution medium, and the like. Of course, there are other ways of storing media that can be read, such as quantum memory, graphene memory, and so forth. It should be noted that the computer readable medium may contain content that is subject to appropriate increase or decrease as required by legislation and patent practice in jurisdictions, for example, in some jurisdictions, computer readable media does not include electrical carrier signals and telecommunications signals as is required by legislation and patent practice.

Example four

An embodiment of the present invention further provides a computer device, as shown in fig. 13, including one or more processors, a communication interface, a memory, and a communication bus, where the processors, the communication interface, and the memory complete communication with each other through the communication bus.

A memory for storing a computer program;

a processor for implementing, when executing the program stored in the memory:

receiving a submission request for a current node;

acquiring a handling mode of a current node;

judging whether the transfer condition is met;

In one possible design, the processor executes a process in which the transition condition is determined based on a user-defined configuration.

In one possible design, the processor executes a process in which the branch condition includes, but is not limited to, any of the following:

second transfer conditions comprising: completing the transaction of the node by one or more designated transactants;

third transfer conditions comprising: the nodes are handled by a preset number of transactants.

In one possible design, the processing performed by the processor further includes:

when the transaction mode of the current node is the second multi-user transaction mode, judging whether the current submitter is the last transactor correspondingly configured in the second multi-user transaction mode;

if the current submitter is the last transactor configured corresponding to the second multi-user transaction mode, submitting the data to be processed to a subsequent node of the current node so as to perform a circulation process between the nodes;

and if the current submitter is not the last transactor correspondingly configured in the second multi-user transaction mode, executing the circulation process in the current node.

In one possible design, in the processing executed by the processor, the process of submitting the data to be processed to a subsequent node of the current node to perform a flow process between nodes specifically includes:

judging whether a subsequent node to be submitted is appointed;

if not, acquiring a subsequent node of the current node and the transactor configured correspondingly by the subsequent node; then, circularly submitting to each subsequent node in the subsequent nodes;

if so, the commit is made directly to each of the subsequent nodes in a loop.

In one possible design, the submitting to each of the subsequent nodes in the processing executed by the processor specifically includes:

judging whether the subsequent node to be submitted is an end node or not;

if the subsequent node to be submitted is the end node, transferring the data related to the process instance from the running state table to the transaction table, and deleting the data in the running state table;

detecting whether the flow of the current circulation is a sub-flow;

if the sub-process is the main-process, whether the main-process corresponding to the sub-process is in a suspended state is further judged, and if the main-process is in the suspended state, the main-process is awakened.

if the subsequent node to be submitted is not the end node, processing the handler submitted by the front-end page;

if the processing person submitted by the front-end page is none, the appointed special character or the system appoints, the processing object configured by the subsequent node is calculated:

firstly, judging whether the subsequent node is configured with a rework staff or not; if the rework personnel are configured, acquiring the last time transacting personnel of the subsequent node as the current transacting personnel; if the last transactor of the subsequent node is empty or the subsequent node is not configured with a reworker, acquiring all transactors contained in a processing object according to the processing object configured by the subsequent node;

then, according to a preset staff allocation rule, filtering and screening all the obtained transactants to obtain final transactants;

in the embodiment, the acquired transactants are screened for one time; the specific screening rule is customizable and has no fixed logic, and specifically, according to configuration, a certain policy/rule is configured to carry out screening according to the policy/rule, and if the policy/rule is not configured, the screening cannot be carried out, so that the screening is an extended function; the extension function corresponds to an interface, the realization class of the inheritance interface is a configuration item, and the specific strategy is defined in the realization class.

If the front-end page submits the handlers, the handlers are the transactors of the subsequent node, and basic information of the handlers is obtained;

judging whether a pre-configured entrusting relationship exists or not, if so, performing entrusting conversion on the acquired transactants, and if so, replacing the transactants with the trusted persons to obtain final transactants;

wherein, the entrusting relationship refers to flow data of a certain service type, and in the effective time, if the flow data is originally submitted to a client and handled by the client, the flow data is handed over to a receiver by a workflow engine and the receiver replaces handling; the entrusting relationship is configured in advance (comprising a business type, an effective time, an entrusting person and an entrusted person);

judging the node type of the subsequent node, if the node is an automatic node, acquiring the next node of the automatic node by the workflow engine according to the content defined by the flow chart, taking the next node as the node to be submitted, designating the system as the handling staff of the next node, and re-executing the single-node submitting step to submit to the next node;

if the nodes are summary nodes, judging whether all the nodes to be handled of the current process except the submitted nodes pass through the summary nodes according to the definition content of the flow chart, if so, finishing the submission process without subsequent processing, if not, acquiring the next node of the summary nodes, taking the next node as the node to be submitted, designating the system as a transactor of the next node, and re-executing the single-node submitting step to submit to the next node;

if the node is other than the automatic node, the summary node and the end node, such as a common node and a single-selection multi-selection node, submitting the node;

submitting: judging the number of the obtained transactants, judging whether the transactants are single sign-in transacted or not when more than one transactants exist, if so, setting the sign-in state of the transactants to be signed in, and then performing data initialization; if not, judging whether the multiple persons are handled in sequence, if so, numbering the userLevel from 0 according to the sequence for all the handling personnel, and then performing data initialization; if not, directly carrying out data initialization;

if the transactor only has one bit, directly performing data initialization:

newly adding a handling personnel record in the to-be-handled list of the personnel, and newly adding a node record in the to-be-handled list of the node;

finally, notifying service processing;

ending the submission process of the node;

the single-node commit process ends.

Specifically, when defining the flowchart, the transaction objects configured at the node may be specific persons, or an organization, a post, a role, a department, a project pool, other customization methods, and the like, which are all objects configured by the node, and here, the processing personnel included in each transaction object is respectively detected according to the configured objects.

In a possible design, in the processing executed by the processor, the process of performing a flow in a node inside a current node specifically includes:

copying the records related to the submitters in the to-do record list of the staff to the handled record list of the staff;

deleting the related records of the submitters in the to-be-handled record list of the personnel;

judging whether the mode is a multi-person sequential handling mode;

if so, the user level of the next transactor to the current submitter of the current node is set to be lowest so that the next transactor to the current submitter can view and process the transaction data.

The communication bus mentioned in the electronic device may be a Peripheral Component Interconnect (PCI) bus, an Extended Industry Standard Architecture (EISA) bus, or the like. The communication bus may be divided into an address bus, a data bus, a control bus, etc. For ease of illustration, only one thick line is shown, but this does not mean that there is only one bus or one type of bus. The communication interface is used for communication between the electronic equipment and other equipment.

The Memory may include a Random Access Memory (RAM) or a Non-Volatile Memory (NVM), such as at least one disk Memory. Optionally, the memory may also be at least one memory device located remotely from the processor.

The Processor may be a general-purpose Processor, including a Central Processing Unit (CPU), a Network Processor (NP), and the like; but also Digital Signal Processors (DSPs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs) or other Programmable logic devices, discrete Gate or transistor logic devices, discrete hardware components.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a vehicle-mounted human-computer interaction device, a cellular telephone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

Although the present application provides method steps as described in an embodiment or flowchart, more or fewer steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one manner of performing the steps in a multitude of orders and does not represent the only order of execution. When an actual apparatus or end product executes, it may execute sequentially or in parallel (e.g., parallel processors or multi-threaded environments, or even distributed data processing environments) according to the method shown in the embodiment or the figures.

It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.

All the embodiments in the present specification are described in a related manner, and the same and similar parts among the embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, as for the device, the electronic device and the readable storage medium embodiments, since they are substantially similar to the method embodiments, the description is simple, and the relevant points can be referred to the partial description of the method embodiments.

The above description is only for the preferred embodiment of the present invention, and is not intended to limit the scope of the present invention. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention shall fall within the protection scope of the present invention.

Claims

1. A method of operation of a workflow engine, comprising:

receiving a submission request for a current node;

acquiring a handling mode of the current node;

when the handling mode of the current node is a first multi-user handling mode, further acquiring a transfer condition configured corresponding to the first multi-user handling mode; wherein the first multi-user transaction mode is a multi-user transaction mode in which the current node can be ended in advance, and the transition condition includes: a first transfer condition comprising: the current submitter confirms to finish the current node in advance through a popup window; alternatively, the second transfer condition comprises: completing the transaction of the current node by one or more designated transactants; wherein the popup is used for inquiring whether the current submitter finishes the current node in advance;

judging whether the transfer condition is met;

when the transfer condition is met, the current node is ended in advance, and the data flow to be processed is transferred to a subsequent node of the current node;

when the handling mode of the current node is a second multi-person handling mode, judging whether the current submitter is the last handler correspondingly configured in the second multi-person handling mode;

if the current submitter is the last transactor configured corresponding to the second multi-user transaction mode, submitting the data to be transacted to a subsequent node of the current node so as to perform a flow process between nodes;

if the current submitter is not the last transactor configured corresponding to the second multi-user transaction mode, executing a circulation process in the current node;

wherein, the submitting the data to be transacted to the subsequent node of the current node to perform the flow process between nodes specifically includes:

judging whether a subsequent node to be submitted is appointed;

if not, acquiring a subsequent node of the current node and a transactor correspondingly configured by the subsequent node; then, cyclically submitting to each subsequent node in the subsequent nodes;

if yes, directly and circularly submitting to each subsequent node in the subsequent nodes;

wherein submitting to each of the subsequent nodes specifically includes:

judging whether the subsequent node to be submitted is an end node or not;

if the subsequent node to be submitted is an end node, transferring the data related to the process instance from the running state table to the transaction table, and deleting the data in the running state table;

detecting whether the flow of the current circulation is a sub-flow or not, wherein the sub-flow comprises the following steps: when the instance number corresponding to the flow of the current circulation is different from the main instance number of the main flow, determining that the flow of the current circulation is a sub-flow;

and if the sub-process is the main process, further judging whether the main process corresponding to the sub-process is in a suspended state which cannot be approved, if so, awakening the main process, and setting the main process in the suspended state as an operation state which can be approved.

2. The method of claim 1, further comprising:

if the subsequent node to be submitted is not the end node, acquiring a transactor submitted by the front end;

if the transactor submitted by the front-end page is absent, a preset special character is adopted, or the system specifies, calculating the transactor of the subsequent node;

and if the front-end page submits to the transactor, acquiring the basic information of the transactor.

3. The method of claim 2, after obtaining the base information of the transactor, further comprising: and judging whether a pre-configured entrusting relationship exists or not, if so, performing entrusting conversion on the obtained transactor, and replacing the transactor conforming to the entrusting relationship with the trusted transactor according to the pre-configured entrusting relationship to obtain the final transactor of the subsequent node to be submitted.

4. The method of claim 3, after deriving a final clerk of the subsequent node to submit to, further comprising:

judging the node type of the subsequent node, and performing different processing according to different types of nodes:

if the subsequent node is an automatic node, submitting to the next node of the automatic node;

if the subsequent node is a summary node, judging whether other nodes pass through the summary node or not, if so, the submission is not processed, and the submission process is ended; if not, the next node of the summary nodes defined by the query flow chart is used as the node to be submitted, and the single-node submitting step is executed again to submit to the next node of the summary nodes;

if the node type is an approval node except an automatic node, a summary node and an end node, submitting the approval node to which the node type is submitted in the following process.

5. The method according to claim 2, wherein the calculating the transactor for the subsequent node specifically comprises:

judging whether the subsequent nodes are configured with rework personnel or not;

if the rework personnel are configured, acquiring the last transactor of the subsequent node;

judging whether the last transactor of the subsequent node is empty or not;

when the last transactor of the subsequent node is empty or the subsequent node is not configured with the rework personnel, acquiring the transactors according to the transactors configured by the subsequent node, and filtering and screening the acquired transactors according to a pre-configured personnel allocation rule; wherein the transaction objects comprise any one or more of the following objects: natural people, institutions, posts, roles, departments, project pools, other transacted objects determined according to a custom method.

6. The method of claim 5, further comprising:

and when the last transactor of the subsequent node is not empty, filtering and screening the final transactor directly according to a pre-configured personnel allocation rule.

7. The method according to claim 4, wherein the submitting process of the approval node to which the approval node is subsequently submitted specifically includes:

judging whether the number of the obtained transactants of the approval node to be submitted is more than 1;

if only 1 transactor exists, carrying out data initialization;

if the number of the transactants is more than 1, judging whether the transacting mode of the approval node to be submitted is single-person sign-off transacting; if yes, setting the sign-in states of all transactants to be signed-in, and then performing data initialization;

if the transaction mode of the approval node to be submitted is not single-person sign-off transaction, judging whether the transaction mode is multi-person sequential transaction, if so, numbering the user grades of all the transactants of the approval node from 0 in sequence, and then performing data initialization;

if the multiple persons do not work in sequence, the data initialization is carried out.

8. The method of claim 7, wherein the data initialization comprises: and adding a transacting personnel record in the personnel to-be-handled list, adding a node to-be-handled record in the node to-be-handled list, and then notifying service processing.

9. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out a method of operation of a workflow engine according to any one of claims 1 to 8.

10. A computer device, comprising:

one or more processors;

storage means for storing one or more programs;

the one or more programs, when executed by the one or more processors, cause the one or more processors to implement a method of operation of a workflow engine as recited in any one of claims 1-8.