CN118426762A - Method for designing general service model based on ACTIVIT flow engine - Google Patents

Abstract

The invention provides a method for designing a general service model based on ACTIVIT flow engine, which comprises the following steps: step one, creating and deploying a flow model file; step two, an external form is constructed and is associated with the flow model of the step one; writing a flow model analysis acquisition tool for the flow model file in the first step, and constructing a robust core interface class by combining the external form and the built-in API of the second step; and step four, realizing a front end UI of the corresponding function through the core interface class constructed in the step three so as to realize a free configuration function after the developer is separated. The invention can realize that the flow engine is completely separated from the developer in the actual service use process, reduce the cost of the user and improve the application efficiency.

Description

Method for designing general service model based on ACTIVIT flow engine

Technical Field

The invention relates to the technical field of business processes, in particular to a general business model design method based on ACTIVIT process engines.

Background

At present, most developers only develop customized development with characteristic attribute fields aiming at a specific service when using a flow engine for integrated development, and the integrated mode has the advantages that the integration is quick, codes of service design belong to a separated state, debugging of the developers is convenient, but the integrated mode is unfriendly to the service personnel, and as the complexity of user service is increased and new service is expanded, professional code developers are required to develop again when the service attribute fields in the existing flow are required to be newly increased or modified. This approach to non-sustainable integration has become increasingly unacknowledged by project administrators as the process engine technology matures.

The inventors of the present application have found through studies that: new integration trends are biased away from the general purpose schemes that developers need only be simply configured. Implementing this solution requires a deep understanding of the flow engine by the developer, by constructing a robust code approach, orderly re-splitting and combining the distributed APIs everywhere, forming a generic set of interface schemes. The universality of the models is embodied in the same service model, and if no change flow node exists, only the pure service attribute fields are added and deleted, only the form JSON bound by the corresponding model is modified. The modification does not affect the existing flow under the model, only the subsequent newly initiated flow is effective, and the bright spot is not possessed by other similar products. The robustness of the code design is reflected in that the code design can still normally operate under the condition of processing different models or different version numbers of the same model, and other existing version processes are not influenced. By realizing the two characteristics of the universality of the model and the robustness of the code design, the process engine can be completely separated from a developer in the actual service use process, so that the cost of a user is certainly reduced, and the application efficiency is improved.

Disclosure of Invention

In view of the above, the present invention aims to provide a method for designing a general service model based on ACTIVIT flow engine, which realizes that the flow engine is completely separated from a developer in the actual service use process, reduces the cost of users, and improves the application efficiency.

A method for designing a general service model based on ACTIVIT flow engine comprises the following steps:

step one, creating and deploying a flow model file;

Step two, an external form is constructed and is associated with the flow model of the step one;

Writing a flow model analysis acquisition tool for the flow model file in the first step, and constructing a robust core interface class by combining the external form and the built-in API of the second step;

And step four, realizing a front end UI of the corresponding function through the core interface class constructed in the step three so as to realize a free configuration function after the developer is separated.

Further, the first step specifically includes:

Step 1.1: determining names and types in each flow node;

Step 1.2: creating a flow model file by using a model editor integrating bpmn.js according to the name and the type determined in the step 1.1;

Step 1.3: exporting the compressed package from the flow model file created in the step 1.2 through an editor;

step 1.4: and (3) uploading the flow model file by calling the built-in API function of the flow engine to the compression packet derived in the step (1.3).

Further, the second step specifically includes:

Step 2.1: constructing an external form, using an open source version self-defined form generator FormMaking tool to make the form and display back data, introducing an open source VUE component at the front end, after designating the version number of the component, rendering a corresponding page according to a official guide document, and leading out the drawn external form into a JSON data file at the front end by a user;

Step 2.2, updating the external form into a flow model, binding the JSON data file exported in the step 2.1 with a corresponding flow model through a back-end core interface service, initializing the JSON data file into relational data, injecting the relational data into a flow variable when each flow is started, and changing the external form bound by a subsequent model so as not to influence the external form of the existing flow;

step 2.3: the process model enables an external form: reading the relation data in the step 2.2 in the process of starting the flow instance of the corresponding version of the flow model, and updating the json data of the external form into the instance variable for persistence and storage through the characteristic of the initialization attribute of the starting flow instance;

Step 2.4: recording data generated in the process of running the flow instance by the external form: and continuously acquiring attributes in the instance variables for display and editing in the process of flow instance circulation, and after a user fills out service data through the external form displayed back, storing the external form and the filled-in service data serialization JSON into a newly-added history flow instance record table by a back-end program.

Further, the history flow instance record table belongs to a data table built in a non-flow engine, the table data source is generated by a program after the business data filled by a user are combined with the gateway type of a flow model to redirect the trend of the flow, the table independently records all the form data of each flow at each node, the table is expanded according to the actual business requirement, and the basic attributes comprise: model ID, model identification, flow instance ID, instance node name, instance node external form data, data creation time, creator, operator time.

Further, the third step specifically includes:

Step 3.1: writing a flow model analysis acquisition tool: the method comprises the steps of analyzing an uploaded model BYTE [ ] data stream through a flow built-in service RepositoryService to form a split JSON array, and packaging the JSON array to obtain model basic data in a multi-dimension mode through the JSON array, wherein the JSON array comprises node information, form information, gateway information and line information in the model;

Step 3.2: a process node history record tool is constructed: the encapsulation obtains all historical data of the process instance through the assigned process instance ID and returns the historical data according to the positive sequence of the creation time; the encapsulation obtains a first method of creating time reverse order through an appointed flow instance ID and an instance node ID;

Step 3.3: a flow disturbance tool is constructed for correction of flow instances:

Step 3.4: the basic function interface class is constructed, which comprises the steps of inquiring a flow list available for use, activating or suspending a certain flow in the flow list, starting a specified flow in the flow list and generating a flow example, inquiring a flow example list running a certain flow, inquiring an example node list distributed to a user identifier through a flow example ID and the user identifier, displaying a SVG progress chart and history information of the flow example through the flow example ID, reassigning a responsible person in an example node through the flow example ID and the example node ID, and completing the example node through the flow example ID and the example node ID, so that the flow example node reaches the next flow example node.

Further, the method for obtaining the model basic data by using the multiple dimensions in the step 3.1 includes: the method comprises the steps of obtaining all information of the node through the designated instance node name, obtaining all postnatal nodes of the flow node through the designated flow node name, and obtaining all prepositive nodes of the flow node through the designated flow node name.

The invention is based on the ACTIVIT version 7 official specification improvement, essentially the expansion and packaging design of ACTIVIT built-in services, which aims at better service changing business requirements. After the developer is separated from the service personnel, the service personnel can still interact with the designed core interface class through the pre-developed UI page so as to realize free configuration of the flow.

Drawings

FIG. 1 is a flow diagram of a generic business model design method implemented based on ACTIVIT flow engine in accordance with an embodiment of the present invention;

FIG. 2 is a schematic diagram of a model designer page integrating the BPMN2.0 standard according to an embodiment of the present invention;

FIG. 3 is a functional schematic diagram of uploading, exporting, deleting, suspending, etc. a model according to an embodiment of the present invention;

FIG. 4 is a diagram of a tool of the open source custom form generator FormMaking in accordance with one embodiment of the present invention;

FIG. 5 is a schematic diagram of a custom form generator developed according to FormMaking tools in accordance with an embodiment of the present invention;

FIG. 6 is a schematic diagram of a historical approval record for viewing a running instance according to an embodiment of the present invention;

FIG. 7 is a schematic diagram of a list of tasks presented to a user for review to be done in accordance with an embodiment of the invention;

FIG. 8 is a real-time operational diagram of one example of an embodiment of the present invention;

FIG. 9 is a real-time operational diagram of another example of an embodiment of the present invention;

FIG. 10 is a schematic diagram of a business form display back page with a view of a running instance based on FormMaking in accordance with an embodiment of the present invention.

Detailed Description

For the purpose of making the objects, technical solutions and advantages of the embodiments of the present invention more apparent, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention, and it is apparent that the described embodiments are some embodiments of the present invention, but not all embodiments of the present invention. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.

Interpretation of the terms

And (3) model: the flow model file is a file stored in an xml form. The main attributes include: model name, model identification, model node set, model gateway set, model version number.

Model node: a model has a plurality of nodes consisting essentially of a start node, service 1, service 2. Such nodes are form data free. The main attributes include: model node name, model node type, model node responsible person, model node front line and gateway information, model node back line name.

The flow is as follows: after the model is imported, the flow engine generates a flow with a specified name according to the model. The main attributes include: flow name, flow ID, flow identification (model designer also called model identification), flow version number (incremented according to model identification), flow node set (model designer also called model node set).

The flow node: a flow has a plurality of nodes, basically consisting of a start node, service 1, service 2. Such nodes are form data free. The main attributes include: flow node name, flow node ID, flow node type, flow node responsible person, flow node front line and gateway information, flow node back line name.

Flow example: an ongoing instance is replicated through the process. It is understood that the flow is mother and the flow example is child. The main attributes include: flow ID, flow instance ID, node set currently activated by the flow instance (instance node set).

Example node: the nodes in the process instance are also called task nodes, and at this time, the nodes are already running, so that the process instance also has current service form data. The main attributes include: the system comprises a flow node name, a flow node ID, a flow node type, a flow node responsible person, flow node front line and gateway information, a flow node back line name, an instance node ID, instance node business form data and an instance node actual responsible person ID.

Process variable: the scope range of the variable is all instances in the current model version number.

Example variables: the scope range of this variable is merely the current example.

Built-in forms: and presetting and embedding service related fields of node attributes in advance in the model node design process. The method is only suitable for transmission of small data volume, does not support field preservation of complex types, is not beneficial to decoupling design of a service system and a flow engine, and is difficult to carry out continuous iteration under the conditions of frequent change of service and frequent upgrade of version.

An external form: the method is a supplement to the built-in forms in the model nodes, the content is not affected by the model, the attribute can be expanded without limit, the types are rich, but certain technical access difficulty exists.

ACTIVIT7 is a micro-service based on ACTIVIT Cloud cloud platform, so that a developer can design and deploy a business process by using a tool provided by a cloud, and can also use an encapsulation package shared by an open source community to perform private cloud deployment. The 7 series is designed across code compared to previous historical versions so that built-in services familiar in previous versions are discarded and reconstructed. Rendering modeling is performed on a designer by using the BPMN2.0 standard, and model creation and editing can be realized by integrating bpmn.js on a web end so as to support integration with most cloud infrastructures for third parties.

The invention provides a method for designing a general service model based on ACTIVIT flow engine, which comprises the following steps:

step one, creating and deploying a flow model file; specifically, the implementation process of the first step is as follows:

Step 1.1: determining names and types in each flow node;

Step 1.2: and (3) creating a flow model file by using a model editor integrating bpmn.js according to the name and the type determined in the step 1.1. Specifically, a unique identifier of the naming model in the editor, namely a service identifier, such as a SHOP; naming identification, type, attribute, responsible person, built-in form and the like of each node of the naming model in the editor; the gateway of the model in the flow is created according to the BPMN2.0 specification;

step 1.3: exporting the flow model file created in the step 1.2 to a compression package (for example, SHOP. ZIP) through an editor, as shown in FIG. 2;

Step 1.4: and (3) uploading the flow model file by calling a flow built-in service function of the compression packet derived in the step (1.3), wherein the built-in service function can analyze the uploaded model BYTE [ ] data flow and judge whether a same-name model exists according to the unique identification of the model, and after the uploading is successful, a released built-in service exists, and only if the built-in service is released, a user can see the flow of the new version. Directly generating a new flow with a version number of 1 if the homonymous model does not exist; the existence of the homonym model increases one version according to the version number of the existing flow, but does not cover the old flow, for example, the homonym flow with the existing version number of 1, and when the homonym model is reintroduced, the new flow model version is defined as 2, but still remains 1. The user can still continue to start the flow with the version number of 1 or start the flow with the version number of 2, as shown in fig. 3;

the process model file is created by using a designer integrating the BPMN2.0 standard, wherein the creation model not only needs to consider the completeness of a business process, but also needs to consider the expandability of subsequent updating, and the node design of the process also needs to be careful, because the subsequent expandable updating does not allow the nodes of the process to change.

Step two, an external form is constructed and is associated with the flow model; specifically, the implementation process of the second step is as follows:

Step 2.1: the external form is constructed, and an open source custom form generator FormMaking tool can be used for making the form and displaying back data, the principle is that an open source VUE component is introduced at the front end, after the version number of the component is designated, the corresponding page is rendered according to a official guide document (https:// form. Making. Link /) and the user exports the drawn external form into a JSON data file at the front end, as shown in figure 4;

And 2.2, updating the external form into the flow model, binding the JSON data file exported in the step 2.1 with the corresponding flow model through the back-end interface service, initializing the JSON data file into relational data, injecting the relational data into the flow variable when each flow is started, and ensuring that the external form of the existing flow is not influenced by the change of the external form bound by the subsequent model. The data format is as follows: flow identification, form JSON data, form unique identification, flow version number, as shown in fig. 5.

Step 2.3: the flow model enables an external form. Step 2.2 may repeat the operation on a certain model, and the operated model will be immediately effective, but will not affect the running model instance, and only the newly started flow instance will be effective after updating the flow model. And 2, in the process of starting the flow instance of the corresponding version of the flow model, the relation data in the step 2.2 needs to be read, and the json data of the external form is updated into instance variables for persistence and storage through the characteristic that the initialization attribute is required to be started for the flow instance.

Step 2.4: and recording data generated by the external form in the process of running the flow instance. In the process of flow instance circulation, the attribute in the instance variable is required to be continuously acquired for display and editing, after a user fills out service data through the external form of the back display, the back-end program is required to store the external form and the filled-in service data serialization JSON into a newly added historical flow instance record table, and the table belongs to a data table built in a non-flow engine and is an additional table which is independently added for facilitating subsequent general design. Wherein: (1) The table data source is generated after the program redirects the trend of the flow by combining the business data filled by the user with the gateway type of the flow model, the table needs to record all the table data of each flow at each node independently, for example, 10 nodes exist in one flow model, and when the corresponding example of the flow model is started, a table record belonging to the example node of the flow model exists in the table, so that the complex operations of history record back display, node back display and the like can be conveniently carried out subsequently. (2) The table design can be extended according to the actual business needs, but the basic attributes must include: model ID, model identification, flow instance ID, instance node name, instance node external form data, data creation time, creator, operator time, etc. Through the design of the table, various continuous table query operations can be conveniently carried out with the built-in data table of the flow engine. As shown in fig. 6.

In the step, an open source self-defined form generator FormMaking tool is used for making forms and displaying back data, a strong association record is established between the forms and a flow model, and when the service generates the requirement of adding and deleting service attribute fields, the forms JSONs bound by the corresponding models are only modified.

And thirdly, writing an analysis acquisition tool for the flow model file in the first step, and constructing a robust core interface class by combining the external form and the flow built-in service of the second step. The service in the process is not provided with the capability of directly using the service, a developer needs to have a certain process engine development knowledge to combine the APIs required by the service, in the combining process, the developer cannot only consider that the single service is completed, but also needs to consider the expandability after the combination, wherein the steps 3.1 to 3.3 are tool types, the step 3.4 is a specific core interface type, and the implementation process of the step three is as follows:

step 3.1: and writing a flow model analysis and acquisition tool, analyzing the uploaded model BYTE [ ] data stream through a flow built-in service RepositoryService to form a split JSON array, and packaging a method for acquiring model basic data in multiple dimensions through the JSON array for use. The JSON array contains node information, form information, gateway information and line information in the model. The node information comprises attributes such as node names, node types, node responsibility people, form names and the like. The gateway information includes gateway name, gateway type, gateway condition. The line information includes a line name; the method for acquiring the model basic data in a multi-dimension way comprises the following steps:

(1) A method for acquiring all information of the node by specifying an instance node name; the getBpmnModel method of the call flow built-in service RepositoryService may be implemented.

(2) The method comprises the steps of obtaining all the rear-mounted nodes of a process node through designating the name of the process node; after all the information of the nodes is obtained in the step (1), the method can be realized after the process node where the corresponding process node name is located is positioned by combining the process built-in service TASKSERVICE.

(3) And acquiring all the front nodes of the process node by designating the name of the process node. After all the information of the nodes is obtained in the step (1), the method can be realized by combining the built-in service TASKSERVICE to locate the flow node where the corresponding flow node name is located.

Step 3.2: building a robust core interface class requires building a process node history record tool, which can be realized through the newly-added history process instance record table in the step 2.4;

(1) And the encapsulation obtains all historical data of the process instance through the assigned process instance ID and returns the historical data according to the positive sequence of the creation time.

(2) And the encapsulation obtains the method of creating the first bar of the time reverse order through the appointed flow instance ID and the instance node ID.

Step 3.3: building a robust core interface class requires building a flow disturbance tool. The method is mainly used for correcting the flow instance under the condition of misoperation of a user.

(1) The current task node of the flow instance changes the responsible person, and needs to specify an instance ID, a task node ID, a responsible person ID or an identification. The SETASSIGNEE method of the call flow built-in service TASKSERVICE may be implemented.

Step 3.4: the building of the robust core interface class needs to build the basic function interface class, which is realized by combining the steps 3.1, 3.2 and 3.3 on the basis of the built-in interfaces of the flow.

(1) The list of available flows is queried. The query method of the call flow built-in service RepositoryService can be implemented.

(2) A certain flow in the flow list is activated or suspended. The activateProcessDefinitionById, suspendProcessDefinitionById method of the call flow built-in service RepositoryService may be implemented.

(3) And starting the processes specified in the process list and generating a process instance. startProcessInstanceByKey of call flow build-in service RuntimeService may be implemented.

(4) A list of process instances in which a process is running is queried. The query method of the call flow built-in service RuntimeService can be implemented.

(5) The list of instance nodes assigned to the user identity is queried by the flow instance ID and the user identity. As shown in fig. 7. The query method of the call flow built-in service TASKSERVICE can be implemented.

(6) And displaying the SVG progress chart and the history information of the process instance through the process instance ID. As shown in fig. 8 and 9. The GENERATEDIAGRAM method combined with the flow built-in service ProcessDiagramGenerator after the flow model is acquired in the step 3.1 is called.

(7) Reassigning responsible persons in the instance nodes by the flow instance ID and the instance node ID. As shown in fig. 10. The calling step 3.3 can be implemented.

(8) And completing the instance node through the flow instance ID and the instance node ID, so that the flow instance node reaches the next flow instance node. The complete method of call flow build-in service TASKSERVICEE may be implemented.

Step four, realizing a front end UI of a corresponding function through the interface written and constructed in the step three so as to realize a free configuration function after the developer is separated; specific implementation steps may be referred to fig. 1 to 10.

The invention is improved based on ACTIVIT version 5 and version 6, the latest ACTIVIT is the version 7 at present, and the domestic common integration scheme for the version 7 is basically not available; in addition, the invention is based on ACTIVIT version 7 official specification improvement, after the current universality integration method is realized, after the developer is separated, business personnel can still carry out flow creation, form creation, flow release and form binding through a pre-developed configuration page.

The foregoing is merely illustrative embodiments of the present invention, and the present invention is not limited thereto, and any changes or substitutions that may be easily contemplated by those skilled in the art within the scope of the present invention should be included in the scope of the present invention. Therefore, the protection scope of the present invention should be subject to the protection scope of the claims.

Claims (6)

1. A method for designing a general service model based on ACTIVIT flow engine is characterized by comprising the following steps:

step one, creating and deploying a flow model file;

Step two, an external form is constructed and is associated with the flow model of the step one;

Writing a flow model analysis acquisition tool for the flow model file in the first step, and constructing a robust core interface class by combining the external form and the built-in API of the second step;

And step four, realizing a front end UI of the corresponding function through the core interface class constructed in the step three so as to realize a free configuration function after the developer is separated.

2. The method for designing a generic business model based on ACTIVIT flow engine implementation of claim 1, wherein: the first step specifically comprises:

Step 1.1: determining names and types in each flow node;

Step 1.2: creating a flow model file by using a model editor integrating bpmn.js according to the name and the type determined in the step 1.1;

Step 1.3: exporting the compressed package from the flow model file created in the step 1.2 through an editor;

step 1.4: and (3) uploading the flow model file by calling the built-in API function of the flow engine to the compression packet derived in the step (1.3).

3. The method for designing a generic business model based on ACTIVIT flow engine implementation of claim 1, wherein: the second step specifically comprises:

Step 2.1: constructing an external form, using an open source version self-defined form generator FormMaking tool to make the form and display back data, introducing an open source VUE component at the front end, after designating the version number of the component, rendering a corresponding page according to a official guide document, and leading out the drawn external form into a JSON data file at the front end by a user;

Step 2.2, updating the external form into a flow model, binding the JSON data file exported in the step 2.1 with a corresponding flow model through a back-end core interface service, initializing the JSON data file into relational data, injecting the relational data into a flow variable when each flow is started, and changing the external form bound by a subsequent model so as not to influence the external form of the existing flow;

step 2.3: the process model enables an external form: reading the relation data in the step 2.2 in the process of starting the flow instance of the corresponding version of the flow model, and updating the json data of the external form into the instance variable for persistence and storage through the characteristic of the initialization attribute of the starting flow instance;

Step 2.4: recording data generated in the process of running the flow instance by the external form: and continuously acquiring attributes in the instance variables for display and editing in the process of flow instance circulation, and after a user fills out service data through the external form displayed back, storing the external form and the filled-in service data serialization JSON into a newly-added history flow instance record table by a back-end program.

4. The generic business model design method based on ACTIVIT flow engine implementation of claim 3, wherein: the history flow instance record list belongs to a data list which is built in a non-flow engine, the list data source is generated by a program after the business data filled by a user are combined with the gateway type of a flow model to redirect the trend of the flow, the list independently records all the form data of each flow at each node, the list is expanded according to the actual business requirement, and the basic attributes comprise: model ID, model identification, flow instance ID, instance node name, instance node external form data, data creation time, creator, operator time.

5. The method for designing a generic business model based on ACTIVIT flow engine implementation of claim 1, wherein: the third step specifically comprises:

Step 3.1: writing a flow model analysis acquisition tool: the method comprises the steps of analyzing an uploaded model BYTE [ ] data stream through a flow built-in service RepositoryService to form a split JSON array, and packaging the JSON array to obtain model basic data in a multi-dimension mode through the JSON array, wherein the JSON array comprises node information, form information, gateway information and line information in the model;

Step 3.2: a process node history record tool is constructed: the encapsulation obtains all historical data of the process instance through the assigned process instance ID and returns the historical data according to the positive sequence of the creation time; the encapsulation obtains a first method of creating time reverse order through an appointed flow instance ID and an instance node ID;

Step 3.3: a flow disturbance tool is constructed for correction of flow instances:

Step 3.4: the basic function interface class is constructed, which comprises the steps of inquiring a flow list available for use, activating or suspending a certain flow in the flow list, starting a specified flow in the flow list and generating a flow example, inquiring a flow example list running a certain flow, inquiring an example node list distributed to a user identifier through a flow example ID and the user identifier, displaying a SVG progress chart and history information of the flow example through the flow example ID, reassigning a responsible person in an example node through the flow example ID and the example node ID, and completing the example node through the flow example ID and the example node ID, so that the flow example node reaches the next flow example node.

6. The method for designing a generic business model based on ACTIVIT flow engine implementation of claim 5, wherein: the method for obtaining the model basic data by the multi-dimension in the step 3.1 comprises the following steps: the method comprises the steps of obtaining all information of the node through the designated instance node name, obtaining all postnatal nodes of the flow node through the designated flow node name, and obtaining all prepositive nodes of the flow node through the designated flow node name.