Work order operation method and system capable of superposing and hierarchically displaying front-end page

Abstract

The invention discloses a work order operation method and system with a front-end page capable of being displayed in an overlaid and layered mode. The method comprises the steps that work order process instance operation data and historical work order data are stored in ElasticSearch; and storing the work order process definition data and the in-transit work order data in a database PostgresSQL. In the workflow definition, a plurality of message starting events are introduced to adapt to execution of work order services, and different work order process instances are triggered and started through different messages to execute work order service logic. Based on the work order ID, respectively obtaining an XML message defined by the process and a process instance operation data set, and constructing a front-end flow chart message format for the process instance operation data set according to the XML message defined by the process; and constructing a superposed flow chart component on the page, and rendering and presenting the superposed flow chart component. The method has remarkable advantages in the aspects of data storage, query efficiency, complex process support, visualization effect, system flexibility and the like.

Description

Technical Field

[0001] The present invention belongs to the field of computer technology, and in particular relates to a work order operation method and system with front-end pages capable of superimposing and displaying in layers. Background Art

[0002] Workflow is a process used to manage and coordinate multiple tasks and activities. It ensures that tasks can be executed in a predetermined order and according to the predetermined rules by defining a series of steps, roles, rules and conditions. In traditional workflow-based work order systems, workflow definition data and workflow process instance operation data are stored in relational databases. Work order business is often completed by a workflow instance in the background, and the front-end page can only display the data of a flowchart. For complex work order management scenarios where a work order needs to execute multiple process instances of the same work order process definition to achieve a closed business loop, traditional work order systems cannot do this either in terms of performance or in terms of fine-grained display of flowcharts on the front-end page. Therefore, although traditional workflow-based work order systems have been widely used in many industries and fields, the existing technologies have the following defects when facing complex business work orders: ① There is a performance bottleneck: Both process definition data and process instance running data are stored in relational databases. On the one hand, the amount of process instance running data is very large, which will lead to slow data query, thus affecting the response speed of presenting the flowchart on the page; on the other hand, the concurrent read and write operation performance in the relational database is limited by IO performance and concurrent locking mechanism, and cannot effectively handle the scenario of concurrent execution of a large number of work orders.

[0003] ② Poor flexibility: In traditional workflow-based work order systems, a work order is often implemented by a workflow instance. Traditional work order systems cannot flexibly adapt to complex business scenarios where a work order process definition needs to contain multiple "Message Start Events" and a work order requires multiple process instances of the same work order process definition to complete the work order.

[0004] ③ The page flow chart does not support superposition and layered display: When displaying the work order flow chart on the page, the traditional work order system often only supports the display of a single flow chart data. The running data of multiple process instances of the same work order process definition of the same work order cannot be superimposed and displayed in layers, and the requirements for complex work orders to have fine-grained viewing and presentation of the execution trajectory cannot be met. Summary of the invention

[0005] The purpose of the present invention is to provide a work order operation method and system with a front-end page capable of superimposing and displaying a work order in layers, aiming to solve the above-mentioned problems.

[0006] The present invention is mainly achieved through the following technical solutions: A work order operation method in which a front-end page can be superimposed and displayed in layers, comprising the following steps: Step S1: Store the work order process instance running data and historical work order data in ElasticSearch; store the work order process definition data and in-transit work order data in the relational database PostgresSQL; Step S2: Create a new workflow definition, design the business execution process of the work order, and then generate a workflow instance. Drive the execution of the work order business by starting the workflow instance. In the workflow definition, introduce multiple message start events to adapt the execution of the work order business, and trigger different work order process instances through different messages to execute the work order business logic. Step S3: Obtain the work order record data through the interface, and then obtain the XML message of the process definition and the process instance running data set based on the work order ID, and construct the front-end flowchart message format of the process instance running data set according to the XML message of the process definition; construct the superimposed flowchart component on the page and present it after rendering.

[0007] In order to better implement the present invention, further, step S2 includes the following steps: Step S21: Create a new workflow definition, design the business execution process of the work order, and store it in the PostgresSQL database; Step S22: the external system generates a work order record by calling the work order creation interface, and binds the work order record to the workflow definition; Step S23: Call the workflow engine to generate a workflow instance based on the workflow definition; drive the execution of the work order business by running the workflow instance, and write the data during the operation of the workflow instance into ElasticSearch.

[0008] In order to better implement the present invention, further, the step S2 further includes the following steps: Step S24: parsing the work order number and message type code from the message parameters of the message receiving interface; Step S25: Then, the work order number is associated with the work order record, and then the work order record is associated with the workflow definition bound to the work order; Step S25: Finally, the message start event is triggered by the parsed message type code, thereby starting a new workflow instance of the current work order to drive the execution of the work order business.

[0009] In order to better implement the present invention, further, step S3 includes the following steps: Step S31: call the work order process page data query interface and query the flowchart data; obtain the work order ID from the interface parameters of the work order process page data query interface, and then execute steps S32 and S33 separately or in sequence; Step S32: query the work order record from the PostgresSQL database through the work order ID; query the process definition record through the work order process definition ID in the work order record; obtain the XML message of the process definition from the process definition record; Step S33: query the workflow instance key data set associated with the work order from the database PostgresSQL through the work order ID; query the workflow instance running data set from the ElasticSearch index through the workflow instance key; construct the process instance running data set with the process instance as the dimension; Step S34: construct the front-end flowchart message format according to the XML message of the process definition by using the process instance running data set; Step S35: encapsulate the work order process page data query interface result response object message and return it to the page; Step S36: After the page receives the interface result response object, it parses the message and builds a multi-layer front-end container component based on the DIV layout. Each layer then builds a flowchart component based on bpmn.js+DIV and is located in the multi-layer container component, thereby forming an overlaid flowchart component; finally, the flowchart component is rendered and presented.

[0010] The present invention is mainly achieved through the following technical solutions: A work order operation system with a front-end page capable of stacking and layering displays is based on the above method and includes a message receiving interface, a work order creation interface, a work order execution module, a work order process display module, a relational database PostgresSQL and ElasticSearch; The relational database PostgresSQL is used to store work order process definition data and in-transit work order data, and ElasticSearch is used to store work order process instance operation data and historical work order data; the index of the ElasticSearch is in days, and the index name uses the date as a suffix; The external system is connected to the work order execution module through the message receiving interface and the work order creation interface respectively. The work order execution module is used to generate a work order record and bind the work order process definition and call the workflow engine to generate a workflow instance, so as to start the workflow instance to drive the execution of the work order business; The work order process display module is used to call the work order process page data query interface to query the flowchart data, and form and display the rendered superimposed flowchart components, and superimpose the flowchart on the front end.

[0011] Preferably, it also includes a work order process management module, which is used for defining and managing the work order workflow.

[0012] In order to better implement the present invention, further, the in-transit work order data is stored in an in-transit work order table; the in-transit work order table includes a work order ID, a work order type ID, a work order name, a work order number and a process definition ID, wherein the work order number is globally unique.

[0013] In order to better implement the present invention, further, the work order process definition data is stored in XML format, and the work order process definition data includes a process definition table, a process message type definition table and a work order and process instance relationship table; the process definition table includes a process definition ID, a process definition key, a process name, and an XML process definition text, wherein the process definition key is globally unique; the process message type definition table includes a message type ID, a process definition ID, a message type code, and a message type name, wherein the message type code is globally unique; the message type code represents a message event, which is used to start a process instance to complete business logic; the work order and process instance relationship table includes a relationship ID, a work order ID, a process definition ID, a process instance key, and a message type code.

[0014] In order to better implement the present invention, further, the work order process instance running data includes a process instance model, a process instance variable model and a process job model, the process instance object model includes a process instance key, a process definition ID, a BPMN element ID, and a BPMN element type, wherein the process instance key is globally unique; the process instance variable model includes a variable instance ID, a process instance key, a variable code, and a variable value, wherein the variable instance ID is globally unique; the process job model includes a job ID, a process instance key, a BPMN element instance key, a BPMN element ID, a variable set, and a number of retries, wherein the job ID is globally unique.

[0015] The beneficial effects of the present invention are as follows: (1) The present invention solves the problem that the same work order needs to execute the process instances of the same workflow definition multiple times before the business closed-loop processing can be achieved, and realizes the scenario in which the flowchart can be superimposed and layered on the page to truly and completely display the work order business. The present invention introduces the "Message Start Event" method to enable work orders for complex businesses to execute multiple process instances defined by the work order process. The present invention realizes the construction and display of multiple superimposed flowcharts based on the workflow definition XML message combined with the workflow instance data stored in ElasticSearch. Compared with the traditional single flowchart display, the superimposed display can more comprehensively and truly reflect the process execution status. The present invention has significant advantages in data storage, query efficiency, complex process support, visualization effect, system flexibility, etc.

[0016] (2) The present invention stores workflow process definition data and process instance running data separately. The process instance running data with a large amount of data is stored separately in ElasticSearch, thereby solving the system performance bottleneck. The business work order number and the ElasticSearch index name contain the date in the "YYYYMMDD" format. When querying the work order process instance running data, the index in ElasticSearch can be quickly located and data retrieval can be completed quickly.

[0017] (3) The dynamic overlay display of the flowchart implemented by the present invention keeps the nodes and paths in the flowchart unchanged, and the execution paths can be displayed in different colors or styles. Users can clearly see which paths are executed more and which are executed less, which improves the visualization effect of the process. This is more conducive to the intuitive presentation of complex work order processes, and is more conducive to guiding the optimization of production processes or managing business data quality. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 A schematic diagram of the storage structure of work order data of the present invention; Figure 2 Flowchart for work order execution; Figure 3 It is an execution flowchart that can be superimposed and layered on the page to display the work order flowchart. DETAILED DESCRIPTION

[0019] Embodiment 1: A work order operation method in which a front-end page can be superimposed and displayed in layers, comprising the following steps: 1. Separate storage between relational database and ElasticSearch according to data characteristics. ElasticSearch is a distributed, RESTful-style search and data analysis engine, often used to solve the storage, retrieval and analysis of massive data. In order to improve system performance and make full use of ElasticSearch's advantages in large-scale data query, the data of work order process definition and process instance operation data are stored separately, and the in-transit work order data and historical work order data are stored separately.

[0020] The process instance operation data and historical work order data are stored in ElasticSearch, and the system performance is improved by using ElasticSearch's query advantage on large amounts of data. Specifically, the index is maintained in units of days, the index name uses the "YYYYMMDD" format date as a suffix, and the index is allocated to multiple partitions according to the number of ElasticSearch cluster nodes.

[0021] The work order process definition data and in-transit work order data are stored in the relational database PostgresSQL. Specifically, the work order process definition data is defined based on the BPMN2.0 specification and stored in the relational database PostgresSQL in XML format. In-transit work order data refers to work order data whose processes have not been completed and whose business has not been closed.

[0022] A work order may need to start multiple instances of the workflow definition associated with the work order to complete the business closed loop. The relationship data between the work order and the workflow instance is stored in PostgreSQL. The work order workflow instance operation data is stored in ElasticSearch due to the large amount of data.

[0023] 2. In the workflow definition, "Message Start Event" is used to adapt the execution of complex work orders, and different work order process instances are started by different messages to execute specific work order business logic. Message Start Event is an event type in BPMN (Business Process Model and Notation, a standard graphical representation for describing business processes), which indicates that an external message can start a process instance.

[0024] 3. When the front-end opens the work order flowchart to view the page, the work order record data is obtained through the interface, and the flowchart component after the page construction is rendered and presented. In the flowchart after the page is presented and superimposed, the node and execution path data of each process instance started during the work order execution can be viewed by layer, and the nodes and paths passed by the process will be rendered in color for eye-catching prompts. The flowchart displayed by the front-end after superimposition can intuitively reflect the most executed paths in the process of a certain type of work order, which is conducive to optimizing the work order process, or improving the production process, or promoting the improvement of business data quality, etc.

[0025] Preferably, if Figure 1 As shown, the core model is designed as follows: ① In-transit work order table: Contains core fields such as work order ID (primary key), work order type ID, work order name, work order number, process definition ID (foreign key), etc. The work order number is prefixed with the date in the "YYYYMMDD" format and is globally unique.

[0026] ②Process definition table: contains core fields such as process definition ID (primary key), process definition key (unique), process name, XML process definition text, etc. Each work order type will define a process according to business needs.

[0027] ③ Process message type table: contains core fields such as message type ID (primary key), process definition ID (foreign key), message type code, message type name, etc. The message type code is globally unique. A message type code represents a specific message event, which is used to start a process instance to complete a specific business logic.

[0028] ④ Work order and process instance relationship table: Contains core fields such as relationship ID (primary key), work order ID (foreign key), process definition ID (foreign key), process instance key, message type code, etc. A work order may need to start multiple process instances to complete the business closed loop. The relationship between the work order and the process instance is stored in this table.

[0029] ⑤Process instance model: Contains core fields such as process instance key (unique), process definition ID, BPMN element ID, BPMN element type, etc. The process instance key is globally unique. Process instance object data is stored in the ElasticSearch index.

[0030] ⑥Process instance variable model: Contains core fields such as variable instance ID (unique), process instance key, variable code, variable value, etc., where the variable instance ID is globally unique. The variable information of the process instance during operation is stored in the ElasticSearch index.

[0031] ⑦Process job model: Contains core fields such as job ID (unique), process instance key, BPMN element instance key, BPMN element ID, variable set, and number of retries. A process instance generally executes multiple jobs during operation, and the job information is stored in the ElasticSearch index.

[0032] Specifically, the work order number is prefixed with the date in the "YYYYMMDD" format, and the date prefix in the work order number can be used to quickly locate the ElasticSearch index to be searched. The index name of the workflow instance running data stored in ElasticSearch uses the date in the "YYYYMMDD" format as a suffix, which is convenient for quick association through the date prefix of the work order number, further improving the query and retrieval efficiency of workflow instance data in ElasticSearch.

[0033] Preferably, if Figure 2 As shown in the figure, the work order execution process design, for example, a work order needs to run multiple process instances of the same work order process definition to complete the business together. The specific steps are as follows: 1) Create a new work order process definition, design the business execution process of the work order, and store the process definition in the PostgreSQL database 2) The external system generates a work order record by calling the "work order creation interface" 3) When a work order record is generated, a specific workflow definition is bound to it 4) Generate workflow instances through the workflow engine based on the workflow definition of the work order 5) Start the workflow instance to drive the execution of the work order business, and write the data during the workflow instance operation to ElasticSearch 6) For complex work orders, the process definition bound to the work order generally needs to be instantiated and executed multiple times to complete the business. Multiple "Message Start Events" are introduced in the same workflow definition to adapt to the flexibility of complex work order business and state change logic.

[0034] 7) According to the needs of the work order business, the external system drives the work order to continue to execute in a message manner through the "message receiving interface" of the work order system. The work order system first parses the two key parameters of the work order number and message type code from the "message receiving interface" message parameters, and then associates it with the specific work order record through the work order number, and then associates it with the workflow definition bound to the work order through the work order record. Finally, the specified MessageStart Event is triggered through the message type code in the interface parameter, thereby starting a new process instance of the current work order to drive the execution of the work order business.

[0035] 8) Different messages drive the execution of different business logics of the work order until the complete logic of the work order is completed and the work order execution is ended after the business loop is closed.

[0036] Preferably, if Figure 3 As shown, the specific steps of the page superposition and layered display of the work order flow chart are as follows: (1) The operator opens the work order process page.

[0037] (2) The page initiates a call to the "Work Order Process Page Data Query Interface" to query the flowchart data.

[0038] (3) Use the work order ID obtained through the interface parameters of the "work order process page data query interface" to query the work order record from the PostgresSQL database; obtain the work order process definition ID from the work order record and then query the process definition record; obtain the process definition XML message from the process definition record.

[0039] (4) The work order ID obtained through the interface parameters of the "work order process page data query interface" is used to query the workflow instance key data set associated with the work order from the database PostgresSQL; the workflow instance running data set is queried from the ElasticSearch index through the workflow instance key; and the process instance running data set is constructed with the process instance as the dimension.

[0040] (5) Construct the front-end flowchart message format according to the XML message of the process definition by using the process instance running data set.

[0041] (6) Encapsulate the result response object message of the "Work Order Process Page Data Query Interface".

[0042] (7) After receiving the interface result response object, the page parses it and builds a multi-layer front-end container component based on the DIV layout. Each layer then builds a flowchart component based on bpmn.js+DIV and is located in the multi-layer container component, thus forming a superimposed composite component.

[0043] (8) The page is rendered and then presented after the overlaid flowchart component.

[0044] Embodiment 2: A method for running work orders with superimposed layered displays on the front-end page is applied to the work order process of the data professional link port alarm scenario in a certain telecommunications operator's fault handling scenario. The work order process consists of two parts: the main process and the group fault process. The main process is responsible for the creation, transfer, upgrade, diagnosis, recovery and archiving of work orders, and the group fault process is responsible for the group fault generation and opening of the alarm associated with the work order. The entry triggering methods of these two parts are different. The main process is triggered by calling the work order creation interface through the upstream system. The group fault process is triggered by the upstream system dispatching the alarm list under the work order in sequence, and the message receiving interface is called.

[0045] After a work order is created, the upstream system will push the alarms associated with the work order through the message receiving interface according to certain rules. Before the group fault is repaired, the pushed alarms will be merged into the work order for processing. After the group fault is repaired, the work order meets the closed-loop conditions in the business, the work order process ends, and the work order is completed. Users can query the details of the work order by the work order number on the page, and can view the detailed information of the work order process execution in layers.

[0046] The above description is only a preferred embodiment of the present invention and does not limit the present invention in any form. Any simple modification or equivalent change made to the above embodiment based on the technical essence of the present invention shall fall within the protection scope of the present invention.

Claims

1. A work order operation method in which a front-end page can be displayed in layers, characterized in that: The following steps are involved: Step S1: Store the work order process instance running data and historical work order data in ElasticSearch; Store the work order process definition data and in-transit work order data in the relational database PostgresSQL; Step S2: Create a new workflow definition, design the business execution process of the work order, and then generate a workflow instance. Drive the execution of the work order business by starting the workflow instance. In the workflow definition, introduce multiple message start events to adapt the execution of the work order business, and trigger different work order process instances through different messages to execute the work order business logic. Step S3: Obtain the work order record data through the interface, and then obtain the XML message of the process definition and the process instance running data set based on the work order ID, and construct the front-end flowchart message format of the process instance running data set according to the XML message of the process definition; construct the superimposed flowchart component on the page and present it after rendering.

2. According to claim 1, a work order operation method with front-end pages capable of superimposing and displaying in layers is characterized in that: The step S2 comprises the following steps: Step S21: Create a new workflow definition, design the business execution process of the work order, and store it in the PostgresSQL database; Step S22: the external system generates a work order record by calling the work order creation interface, and binds the work order record to the workflow definition; Step S23: Call the workflow engine to generate a workflow instance based on the workflow definition; drive the execution of the work order business by running the workflow instance, and write the data during the operation of the workflow instance into ElasticSearch.

3. According to claim 2, a work order operation method with front-end pages capable of superimposing layered displays is characterized in that: The step S2 further comprises the following steps: Step S24: parsing the work order number and message type code from the message parameters of the message receiving interface; Step S25: Then, the work order number is associated with the work order record, and then the work order record is associated with the workflow definition bound to the work order; Step S25: Finally, the message start event is triggered by the parsed message type code, thereby starting a new workflow instance of the current work order to drive the execution of the work order business.

4. According to claim 1, a work order operation method with front-end pages capable of superimposing layered displays is characterized in that: Step S3 includes the following steps: Step S31: call the work order process page data query interface and query the flowchart data; obtain the work order ID from the interface parameters of the work order process page data query interface, and then execute steps S32 and S33 separately or in sequence; Step S32: query the work order record from the PostgresSQL database through the work order ID; query the process definition record through the work order process definition ID in the work order record; obtain the XML message of the process definition from the process definition record; Step S33: query the workflow instance key data set associated with the work order from the database PostgresSQL through the work order ID; query the workflow instance running data set from the ElasticSearch index through the workflow instance key; construct the process instance running data set with the process instance as the dimension; Step S34: construct the front-end flowchart message format according to the XML message of the process definition by using the process instance running data set; Step S35: encapsulate the work order process page data query interface result response object message and return it to the page; Step S36: After the page receives the interface result response object, it parses the message and builds a multi-layer front-end container component based on the DIV layout. Each layer then builds a flowchart component based on bpmn.js+DIV and is located in the multi-layer container component, thereby forming an overlaid flowchart component; finally, the flowchart component is rendered and presented.

5. A work order operation system with a front-end page capable of stacking and displaying in layers, based on the work order operation method with a front-end page capable of stacking and displaying in layers as described in any one of claims 1 to 4, characterized in that: Including message receiving interface, work order creation interface, work order execution module, work order process display module, relational database PostgresSQL and ElasticSearch; The relational database PostgresSQL is used to store work order process definition data and in-transit work order data, and ElasticSearch is used to store work order process instance operation data and historical work order data; the index of the ElasticSearch is in days, and the index name uses the date as a suffix; The external system is connected to the work order execution module through the message receiving interface and the work order creation interface respectively. The work order execution module is used to generate a work order record and bind the work order process definition and call the workflow engine to generate a workflow instance, so as to start the workflow instance to drive the execution of the work order business; The work order process display module is used to call the work order process page data query interface to query the flowchart data, and form and display the rendered superimposed flowchart components, and superimpose the flowchart on the front end.

6. A work order operation system with a front-end page capable of superimposing and displaying in layers according to claim 5, characterized in that: The in-transit work order data is stored in an in-transit work order table; the in-transit work order table includes a work order ID, a work order type ID, a work order name, a work order number and a process definition ID, wherein the work order number is globally unique.

7. According to claim 5, a work order operation system with front-end pages capable of stacking and displaying in layers is characterized in that: The work order process definition data is stored in XML format, and the work order process definition data includes a process definition table, a process message type definition table, and a work order and process instance relationship table; the process definition table includes a process definition ID, a process definition key, a process name, and an XML process definition text, wherein the process definition key is globally unique; the process message type definition table includes a message type ID, a process definition ID, a message type code, and a message type name, wherein the message type code is globally unique; the message type code represents a message event, which is used to start a process instance to complete business logic; the work order and process instance relationship table includes a relationship ID, a work order ID, a process definition ID, a process instance key, and a message type code.

8. According to claim 5, a work order operation system with front-end pages capable of stacking and displaying in layers is characterized in that: The work order process instance running data includes a process instance model, a process instance variable model and a process operation model, and the process instance object model includes a process instance key, a process definition ID, a BPMN element ID, and a BPMN element type, wherein the process instance key is globally unique; The process instance variable model includes variable instance ID, process instance key, variable code, and variable value, where the variable instance ID is globally unique; the process job model includes job ID, process instance key, BPMN element instance key, BPMN element ID, variable set, and number of retries, where the job ID is globally unique.

Images