Methods, devices, and storage media for associating tasks and documents

By processing order and work order data through the Vert.x message bus and Quarkus microservice framework, and utilizing the Drools rule engine and PostgreSQL components, the response latency problem of cross-platform data synchronization in high-concurrency scenarios was solved, achieving low-latency and accurate association between tasks and documents and real-time inventory updates.

CN120706372BActive Publication Date: 2025-11-14深圳渊联技术有限公司
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202511227692.8
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2025-08-29
Publication Date
2025-11-14
Estimated Expiration
2045-08-29

AI Technical Summary

Technical Problem

Existing cross-platform data synchronization solutions suffer from response delays in high-concurrency scenarios, especially when the sales database is locked but the MES work order has not yet been issued, leading to ATP calculation distortion. Furthermore, they cannot achieve hierarchical association between tasks and documents, and cannot support the structured management of complex projects.

Method used

Employing the Vert.x message bus and Quarkus microservice framework, the system receives multi-pipeline order data and XML batch work order data. It utilizes the Drools rule engine and PostgreSQL components to split and match order data, generate task-related data, and achieve real-time synchronization using an Elasticsearch database and WebSocket connection.

Benefits of technology

In high-concurrency scenarios, it achieves low-latency, stable, and accurate matching of task data and work order data, reduces server load, and ensures real-time inventory updates and accurate task association.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120706372B_ABST
    Figure CN120706372B_ABST
Patent Text Reader

Abstract

This invention relates to the field of order data synchronization, and discloses a method, device, and storage medium for associating tasks and documents. The method includes: a front-end input system receiving multi-pipeline order data and writing it to a Vert.x order address; receiving XML batch work order data, splitting the XML batch work order data into N fragmented work orders, and writing the N fragmented work orders to a Vert.x fragmented address; an association system performing matching processing on the multi-pipeline order data according to a preset rule engine to obtain rule matching results; transforming and processing task data to generate a task form; mapping the N fragmented work orders to POJO instances, and matching and writing the POJO instances into rows or columns of the task form to generate task-associated data. In this embodiment of the invention, by using an incremental synchronization algorithm to update only changed fields to reduce server load, a low-latency, stable, and accurate matching effect between task data and work order data is achieved in high-concurrency scenarios.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of order data synchronization, and more particularly to a method, device, and storage medium for associating tasks and documents. Background Technology

[0002] Existing technologies for cross-platform synchronization mainly refer to the real-time or near-real-time synchronization of order information, inventory quantity, and fulfillment status between multiple platforms. The Spring Boot framework is the mainstream technology used for synchronizing order data between sales management platforms (CRM / e-commerce platforms), production execution platforms (MES / APS), and procurement collaboration platforms (SRM / procurement cloud).

[0003] The Spring Boot framework uses an event-driven approach combined with message middleware. Spring Batch batch processing retrieves yesterday's sales, production, and procurement summaries for financial closing. Incremental events based on Spring Cloud Stream ensure real-time updates to inventory and ATP (Available Time to Pay) data. The Spring Boot + Flowable workflow engine allows for drag-and-drop configuration of the sales-production-procurement order flow via BPMN.

[0004] However, during use, the Spring Boot framework can lead to situations where the sales database is locked, but the MES work order has not yet been issued, causing ATP calculation errors. Furthermore, the Spring Boot solution only achieves order-level information synchronization, failing to establish a hierarchical relationship between tasks and documents (e.g., parent tasks are associated with master documents, and child tasks with detailed documents), thus unable to support structured management of complex projects. Existing Spring Boot solutions mostly achieve eventual consistency, and cross-platform inventory "overselling" still relies on manual intervention, resulting in response latency in high-concurrency scenarios (such as large-scale production work order synchronization). Therefore, a new technology is needed to address the high latency issues of existing cross-platform data synchronization solutions in high-concurrency scenarios. Summary of the Invention

[0005] The main objective of this invention is to solve the technical problem of response latency in existing cross-platform data synchronization solutions under high-concurrency scenarios.

[0006] The first aspect of this invention provides a method for associating tasks and documents. This method is applied to a task and document association system, which includes a front-end input system and an association system. The task and document association method includes:

[0007] The front-end input system receives multi-channel order data and writes the multi-channel order data into the Vert.x order address;

[0008] Receive XML batch work order data, split the XML batch work order data into N fragment work orders, and write the N fragment work orders into the Vert.x fragment address, where N is a positive integer;

[0009] The associated system is based on the Vert.x message bus and receives the multi-pipeline order data and the N fragmented work orders;

[0010] The multi-pipeline order data is matched and processed according to the preset rule engine to obtain the rule hit result;

[0011] Based on the preset rendering template, the rule hit result is instantiated to obtain task data, and the task data is transformed and processed based on the PostgreSQL component to generate a task form.

[0012] The N segmented work orders are mapped to POJO instances, and the POJO instances are matched and written into the rows or columns of the task form according to the field values ​​of the POJO instances to generate task association data.

[0013] Optionally, in a first implementation of the first aspect of the present invention, the step of receiving XML batch work order data and splitting the XML batch work order data into N fragmented work orders includes:

[0014] Based on the Kafka message queue, receive batch work order data in XML format;

[0015] Based on the preset fragmentation value, the records of the XML batch work order data are fragmented to obtain N fragmented work orders.

[0016] Optionally, in a second implementation of the first aspect of the present invention, the step of matching the multi-pipeline order data according to a preset rule engine to obtain a rule matching result includes:

[0017] Based on the pre-built Drools rule engine, the multi-pipeline order data is processed one by one to obtain the hit results;

[0018] When the hit result is a match, the order data corresponding to the hit result is written into the preset result frame to generate the rule hit result.

[0019] Optionally, in a third implementation of the first aspect of the present invention, the step of receiving multi-channel order data includes:

[0020] Based on the pre-built HTTP protocol, it receives web page order data sent by the browser;

[0021] Message events are obtained based on Kafka subscription streams, and the message events are deordered to generate JSON order data.

[0022] Optionally, in a fourth implementation of the first aspect of the present invention, the step of writing the multi-pipeline order data to the Vert.x order address includes:

[0023] Based on the pre-built Vert.x message bus, the web page order data and the JSON order data are written into the Vert.x order address.

[0024] Optionally, in a fifth implementation of the first aspect of the present invention, the step of instantiating the rule hit result according to a preset rendering template to obtain task data includes:

[0025] Based on the template structure of the pre-built Qute template engine, the rule hit results are restructured and rendered to obtain task data.

[0026] Optionally, in a sixth implementation of the first aspect of the present invention, the step of mapping the N fragmented work orders to POJO instances includes:

[0027] The RowMapper function is used to transform N fragmented work orders line by line and write them into the POJO framework to generate POJO instances.

[0028] Optionally, in a seventh implementation of the first aspect of the present invention, after the step of matching and writing the POJO instance into the row or column of the task form according to the field value of the POJO instance to generate task association data, the method further includes:

[0029] Write the associated data into the Elasticsearch database;

[0030] Alternatively, based on a pre-configured WebSocket connection, the associated data can be pushed to a pre-configured service port;

[0031] Alternatively, receive a REST query command, match the query associated data corresponding to the REST query command in the task associated data, and send the query associated data to the address corresponding to the REST query command.

[0032] A second aspect of the present invention provides a task and document association device, comprising: a memory and at least one processor, wherein the memory stores instructions, and the memory and the at least one processor are interconnected via a line; the at least one processor invokes the instructions in the memory to cause the task and document association device to perform the task and document association method described above.

[0033] A third aspect of the present invention provides a computer-readable storage medium storing instructions that, when executed on a computer, cause the computer to perform the aforementioned task and document association method.

[0034] In this embodiment of the invention, order task data and XML batch work order data from multiple pipeline sources are written into the Vert.x pipeline stream. The data in the Vert.x pipeline stream is processed based on the Quarkus microservice framework. Taking advantage of the supersonic startup and subatomic memory usage of the Quarkus microservice framework, the association between work order data in the MES system and sales data in the ERP and CRM systems is quickly matched. By using an incremental synchronization algorithm to update only the changed fields to reduce server load, the effect of low-latency, stable and accurate matching of task data and work order data is achieved in high-concurrency scenarios. Attached Figure Description

[0035] Figure 1 This is a schematic diagram of an embodiment of the method for associating tasks and documents in this invention.

[0036] Figure 2 This is a schematic diagram of a specific embodiment of the 102 steps of the task and document association method in this invention.

[0037] Figure 3 This is a schematic diagram of a specific embodiment of the 103 steps of the task and document association method in this invention.

[0038] Figure 4 This is a schematic diagram of a specific embodiment following step 106 of the task and document association method in this invention.

[0039] Figure 5 This is a schematic diagram of one embodiment of the device for associating tasks and documents in this invention. Detailed Implementation

[0040] This invention provides a method, device, and storage medium for associating tasks and documents.

[0041] The embodiments of the present invention will now be described in more detail with reference to the accompanying drawings. While some embodiments of the present invention are shown in the drawings, it should be understood that the present invention can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the accompanying drawings and embodiments are for illustrative purposes only and are not intended to limit the scope of protection of the present invention.

[0042] In the description of the embodiments disclosed in this invention, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0043] For ease of understanding, the specific process of the embodiments of the present invention is described below. Please refer to [link / reference]. Figure 1 This invention provides an embodiment of a method for associating tasks and documents. The method is applied to a task and document association system, which includes a front-end input system and an association system. The task and document association method includes the following steps:

[0044] 101. The front-end input system receives multi-channel order data and writes the multi-channel order data into the Vert.x order address;

[0045] In this embodiment, Vert.x is a high-performance, lightweight, asynchronous event-driven Java application framework suitable for building reactive microservices and high-concurrency applications. First, the Kafka message queue of the front-end input system receives order data from multiple pipelines. The Kafka message queue captures new orders from the sales system and writes the order data to the Vert.x order address. Here, new orders can be in JSON format, for example:

[0046] {"order_no":"SO2025001","status":"Pending shipment","amount":150000}.

[0047] Specifically, the "receiving multi-channel order data" step 101 includes the following specific implementation methods:

[0048] 1011. Based on the pre-built HTTP protocol, receive webpage order data sent by the browser;

[0049] 1012. Obtain message events based on Kafka subscription stream, deorder the message events, and generate JSON order data.

[0050] In steps 1011-1012, the Quarkus framework is used to build responsive RESTful services, which are used by users in their browsers. The RESTful service's JAX-RS endpoint receives and parses the request body. The endpoint does not directly write to the database or perform business processing. Instead, it passes the web page order data object to the Vert.x communication pipeline.

[0051] The sales system, as an external system, writes order events into the command set through the Kafka message queue. Whenever a message arrives, the data message transmitted by the Kafka message queue is deserialized into a JsonObject to generate JSON order data.

[0052] Specifically, step 101, "writing the multi-pipeline order data to the Vert.x order address," includes the following specific implementation methods:

[0053] 1013. Based on the pre-built Vert.x message bus, write the web page order data and the JSON order data into the Vert.x order address.

[0054] In step 1013, EventBus is a messaging mechanism used for communication between different components, modules, or services. The retrieved webpage order data and JSON order data are written to the Vert.x order address, specifically the order.match address, via EventBus.

[0055] 102. Receive XML batch work order data, split the XML batch work order data into N fragment work orders, and write the N fragment work orders into the Vert.x fragment address, where N is a positive integer;

[0056] In this embodiment, a batch of XML work order data containing 1000 records is pushed to a Kafka message queue in the manufacturing MES system. The 1000 records are then split into 10 shard work orders, each containing 100 records. Each of the 10 shard work orders is then encapsulated into a single message and delivered via the Vert.x message bus to the Vert.x shard address, specifically the `batch.shard` address (not the `order.match` address). This step transforms "one huge input" into "ten small, parallel-processable messages," avoiding memory / transaction issues caused by excessively large single messages, while allowing downstream processes to be handled concurrently by shard.

[0057] For details, please refer to Figure 2 , Figure 2 As a specific embodiment of step 102 of the task and document association method in this invention, step 102 includes the following specific implementation:

[0058] 1021. Receive batch work order data from XML based on Kafka message queue;

[0059] 1022. Based on the preset fragmentation value, the records of the XML batch work order data are fragmented to obtain N fragmented work orders.

[0060] In steps 1021-1022, XML batch work order data is received from the manufacturing MES system based on the Kafka message queue. If the sharding value is set to 100, the 1000 records of the XML batch work order data are sharded, resulting in 10 sharded work orders with 100 records each.

[0061] 103. The associated system is based on the Vert.x message bus and receives the multi-pipeline order data and the N fragmented work orders;

[0062] In this embodiment, the front-end input system only provides subscriptions for "order matching" related business and batch work order processing logic, and only performs protocol conversion and event forwarding.

[0063] The associated system receives all message data from the same container through the Vert.x message bus. The container address convention is divided into four types: Vert.x order address, Vert.x template rendering address, Vert.x transformation address, and Vert.x shard address. The multi-pipeline order data received from the Vert.x order address and the 10 shard work orders received from the Vert.x shard address are isolated. The multi-pipeline order data is processed first, and then the processed data is matched with the 10 shard work orders at the Vert.x shard address.

[0064] 104. Based on the preset rule engine, perform matching processing on the multi-pipeline order data to obtain the rule hit result;

[0065] In this embodiment, the multi-pipeline order data received in the Vert.x order address is processed first. For example, the received order message is as follows:

[0066] {

[0067] "orderNo": "O20240815001",

[0068] "amount": 1200,

[0069] "customerLevel": "VIP"

[0070] }

[0071] Based on the rule engine, the input multi-channel order data is modified and classified according to the "VIP large order" rule to obtain the rule hit results after modification and classification.

[0072] For details, please refer to Figure 3 , Figure 3As a specific embodiment of step 103 of the task and document association method in this invention, step 103 includes the following specific implementation:

[0073] 1031. Based on the pre-built Drools rule engine, perform hit processing on the multi-pipeline order data one by one to obtain the hit result;

[0074] 1032. When the hit result is a match, the order data corresponding to the hit result is written into the preset result frame to generate the rule hit result.

[0075] In steps 1031-1032, Drools, an open-source, Java-based rule engine, is used to automate complex business logic and decisions. It allows developers to define business logic through declarative rules (rather than traditional procedural code), thereby improving code maintainability and scalability. For example, upon receiving order data with a VIP identifier, the corresponding adjustment logic can be invoked to adjust the multi-pipeline data and write it into the result framework, generating rule hit results. For instance, when the number of input data items is greater than 1000 and the level is set to VIP, an identifier instruction is inserted into the multi-pipeline order data, or the data structure of the multi-pipeline order data is adjusted using an index.

[0076] 105. Based on the preset rendering template, the rule hit result is instantiated to obtain task data, and the task data is transformed and processed based on the PostgreSQL component to generate a task form;

[0077] In this embodiment, the processed rule hit results are input from the Vert.x order address to the Vert.x template rendering address for rendering. The rendering template is then called to render the rule hit results generated in the previous step into actual executable task data. An example of the task data structure is as follows:

[0078] TaskStructure(

[0079] taskId=O20240815001_QC,

[0080] type=QUALITY_CHECK,

[0081] priority=10,

[0082] status=PENDING,

[0083] payload={orderNo=O202408150001} )

[0085] The task data is output from the Vert.x template rendering address to the Vert.x transformation address for conversion. The PostgreSQL component, an open-source object-relational database system, can convert the task data into SQL format, resulting in a task form. For example, the task data above, converted into a task form, would look like this:

[0086] INSERT INTO tasks(task_id, type, priority, status, payload)

[0087] VALUES (O20240815001_QC, QUALITY_CHECK,10,PENDING, {orderNo=O202408150001}::jsonb).

[0088] Specifically, step 105 includes the following specific implementation methods:

[0089] 1051. Based on the template structure of the pre-built Qute template engine, the rule hit results are restructured and rendered to obtain task data.

[0090] In step 1051, the Qute template engine, a lightweight template engine within the Quarkus framework, allows setting the structure of task data to include specific details such as task number, task type, task priority, task status, and loading time. The task data is populated based on the data structure provided by the template.

[0091] 106. Map the N segmented work orders to POJO instances, and according to the field values ​​of the POJO instances, match and write the POJO instances into the rows or columns of the task form to generate task association data.

[0092] In this embodiment, the Vert.x shard address first receives the shard work order, records and maps each shard work order to a cache in memory, and calls, for example, the shard work order field "cust_id" to the memory field "customerId". Then, the XML node is mapped to a POJO instance, which is a custom Java class used to carry business fields.

[0093] The Vert.x shard address is obtained from the Vert.x address translation to get the already generated task form. Based on the name or code of the POJO instance, the POJO instance is matched and written into the data of the same parent task in the task form, or a new subclass task row or column is created to generate task association data.

[0094] Specifically, the 106 steps include the following specific implementation methods:

[0095] 1061. Using the RowMapper function, transform N fragmented work orders line by line and write them into the POJO framework to generate POJO instances.

[0096] In step 1061, RowMapper is a functional interface that simplifies the conversion from database result sets to Java objects. It reads data from the database column by column and populates these values ​​into the properties of a Java object. Each work order corresponds to a batch iteration object; the RowMapper function converts each row of query results into a task object, enabling rapid generation of POJO instances. Through the RowMapper function, developers can focus on the data processing logic without worrying about the underlying operations, thereby improving development efficiency and code quality.

[0097] For details, please refer to Figure 4 , Figure 4 This is a specific embodiment following step 106 of the task and document association method in this invention. The following specific implementation method is also included after step 106:

[0098] 1071. Write the task-related data into the Elasticsearch database;

[0099] 1072. Alternatively, based on a preset WebSocket connection, push the task-related data to a preset service port;

[0100] 1073, or, receive a REST query instruction, match the query associated data corresponding to the REST query instruction in the task associated data, and send the query associated data to the address corresponding to the REST query instruction.

[0101] In steps 1071-1073, the downstream system can obtain task-related data from any of these steps. The first method utilizes Elasticsearch, a distributed repository. After data is written, it can be queried on other devices and platforms that provide interfaces, synchronizing data to the Elasticsearch database in near real-time. The downstream data platform can then immediately see the latest task management data.

[0102] The second method involves connecting to the backend via WebSocket in the browser frontend. After the server generates data, it immediately pushes JOSN data, and the frontend service system can immediately receive the updated page, which is suitable for real-time monitoring large screen scenarios.

[0103] The third approach is to receive a REST query command, such as a GET request, and immediately match the corresponding query data from the task-related data. The query-related data can be a complete list of all tasks for a single order. Then, the query-related data is returned to the address corresponding to the REST query command, such as a URL address or a set local port.

[0104] In this embodiment of the invention, order task data and XML batch work order data from multiple pipeline sources are written into the Vert.x pipeline stream. The data in the Vert.x pipeline stream is processed based on the Quarkus microservice framework. Taking advantage of the supersonic startup and subatomic memory usage of the Quarkus microservice framework, the association between work order data in the MES system and sales data in the ERP and CRM systems is quickly matched. By using an incremental synchronization algorithm to update only the changed fields to reduce server load, the effect of low-latency, stable and accurate matching of task data and work order data is achieved in high-concurrency scenarios.

[0105] Figure 5 This is a schematic diagram of the structure of a task and document association device 500 provided in an embodiment of the present invention. The task and document association device 500 can vary significantly due to different configurations or performance. It may include one or more central processing units (CPUs) 510 (e.g., one or more processors) and a memory 520, and one or more storage media 530 (e.g., one or more mass storage devices) for storing application programs 533 or data 532. The memory 520 and storage media 530 can be temporary or persistent storage. The program stored in the storage media 530 may include one or more modules (not shown in the diagram), each module may include a series of instruction operations on the task and document association device 500. Furthermore, the processor 510 may be configured to communicate with the storage media 530 and execute the series of instruction operations in the storage media 530 on the task and document association device 500.

[0106] The task- and document-based associated device 500 may also include one or more power supplies 540, one or more wired or wireless network interfaces 550, one or more input / output interfaces 560, and / or one or more operating systems 531, such as Windows Server, Mac OS X, Unix, Linux, Free BSD, etc. Those skilled in the art will understand that... Figure 5 The illustrated task and document association device structure does not constitute a limitation on task and document-based association devices, and may include more or fewer components than illustrated, or combine certain components, or have different component arrangements.

[0107] The present invention also provides a computer-readable storage medium, which may be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium, wherein the computer-readable storage medium stores instructions that, when the instructions are executed on a computer, cause the computer to perform the steps of the method for associating the task and the document.

[0108] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0109] Furthermore, although the operations are described in a specific order, this should be understood as requiring that such operations be performed in the specific order shown or in sequential order, or requiring that all illustrated operations be performed to achieve the desired result. In certain environments, multitasking and parallel processing may be advantageous. Similarly, although several specific implementation details are included in the above discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may also be implemented individually or in any suitable sub-combination in multiple implementations.

[0110] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

Claims

1. A method for associating tasks and documents, characterized in that, The task and document association method is applied to a task and document association system, which includes a front-end input system and an association system. The task and document association method includes the following steps: The front-end input system receives multi-channel order data and writes the multi-channel order data into the Vert.x order address; Receive XML batch work order data, split the XML batch work order data into N fragment work orders, and write the N fragment work orders into the Vert.x fragment address, where N is a positive integer; The associated system is based on the Vert.x message bus and receives the multi-pipeline order data and the N fragmented work orders; The multi-pipeline order data is matched and processed according to the preset rule engine to obtain the rule hit result; Based on the preset rendering template, the rule hit result is instantiated to obtain task data, and the task data is transformed and processed based on the PostgreSQL component to generate a task form. The N segmented work orders are mapped to POJO instances, and the POJO instances are matched and written into the rows or columns of the task form according to the field values ​​of the POJO instances to generate task association data.

2. The method for associating tasks and documents according to claim 1, characterized in that, The step of receiving XML batch work order data and splitting the XML batch work order data into N fragmented work orders includes: Based on the Kafka message queue, receive batch work order data in XML format; Based on the preset fragmentation value, the records of the XML batch work order data are fragmented to obtain N fragmented work orders.

3. The method for associating tasks and documents according to claim 1, characterized in that, The step of matching the multi-pipeline order data according to the preset rule engine to obtain the rule matching result includes: Based on the pre-built Drools rule engine, the multi-pipeline order data is processed one by one to obtain the hit results; When the hit result is a match, the order data corresponding to the hit result is written into the preset result frame to generate the rule hit result.

4. The method for associating tasks and documents according to claim 1, characterized in that, The steps for receiving multi-channel order data include: Based on the pre-built HTTP protocol, it receives web page order data sent by the browser; Message events are obtained based on Kafka subscription streams, and the message events are deordered to generate JSON order data.

5. The method for associating tasks and documents according to claim 4, characterized in that, The step of writing the multi-pipeline order data to the Vert.x order address includes: Based on the pre-built Vert.x message bus, the web page order data and the JSON order data are written into the Vert.x order address.

6. The method for associating tasks and documents according to claim 1, characterized in that, The step of instantiating the rule-hitting results according to the preset rendering template to obtain task data includes: Based on the template structure of the pre-built Qute template engine, the rule hit results are restructured and rendered to obtain task data.

7. The method for associating tasks and documents according to claim 1, characterized in that, The step of mapping the N fragmented work orders to POJO instances includes: The RowMapper function is used to transform N fragmented work orders line by line and write them into the POJO framework to generate POJO instances.

8. The method for associating tasks and documents according to claim 1, characterized in that, After the step of matching and writing the POJO instance into the row or column of the task form based on the field values ​​of the POJO instance to generate task association data, the method further includes: Write the associated data into the Elasticsearch database; Alternatively, based on a pre-configured WebSocket connection, the associated data can be pushed to a pre-configured service port; Alternatively, receive a REST query command, match the query associated data corresponding to the REST query command in the task associated data, and send the query associated data to the address corresponding to the REST query command.

9. A device for associating tasks and documents, characterized in that, The associated device for the task and document includes: a memory and at least one processor, wherein the memory stores instructions and the memory and the at least one processor are interconnected via a line; The at least one processor invokes the instructions in the memory to cause the task and document association device to perform the task and document association method as described in any one of claims 1-8.

10. A computer-readable storage medium storing a computer program thereon, characterized in that, When the computer program is executed by the processor, it implements the method for associating tasks and documents as described in any one of claims 1-8.

Citation Information

Patent Citations

  • Data processing method and device based on time sequence and storage medium

    CN112131286A

  • Order batch loading method and device, storage medium and computer equipment

    CN115147049A