Universal task query device compatible with various service characteristics

Abstract

The invention relates to a universal task query device compatible with various service characteristics, which comprises a process engine interface module, a service model registration center, a service data aggregation module, a task context assembly module and a unified output module, and is characterized in that service data is automatically pulled from a dispersed MIS system by registering a service model, and the task context assembly module and the unified output module are integrated. And fusing with a process task to generate an operable rich to-do task with complete information. The method has the advantages that the key business data are directly displayed in the to-be-processed list, a user does not need to skip for the second time, and the decision process is accelerated; and a new type of to-do task can be accessed or the existing logic can be changed by configuring the service model, and the core device does not need to be changed, so that decoupling with specific services is realized.

Description

Technical Field

[0001] This invention belongs to the field of task query technology, and in particular relates to a general-purpose task query device that is compatible with multiple business characteristics. Background Technology

[0002] In large industrial enterprises, especially in the manufacturing sector, process engines (such as Camunda and Flowable) are commonly used to drive business processes (such as "work order approval" and "equipment repair process"), while specific business data (such as work order details, equipment information, and bills of materials) are stored in their respective independent production MIS systems (such as MES, ERP, and EAM). This forms a typical architecture where "process tasks are handled by the process engine, while business data is scattered across various MIS systems."

[0003] Currently, the following technical challenges are faced when displaying tasks in the unified task center:

[0004] 1. Information fragmentation: The workflow engine can only obtain basic information about tasks (such as title and initiator), lacking detailed business data to support decision-making (such as detailed content of pending work orders and current status of equipment requiring repair). Users need to jump back to the original system to view this information, which interrupts the workflow.

[0005] 2. Complex integration: Each type of task requires a separate interface to be developed to query business data from the corresponding MIS system. The more task types there are, the greater the development workload, resulting in a "spider web" style integration architecture.

[0006] 3. Poor flexibility: When business processes change or new business types are added, code needs to be modified and pending services need to be redeployed, making it impossible to quickly respond to changes in production needs.

[0007] 4. Performance bottleneck: Serially querying data from multiple systems will cause the response time to accumulate, affecting the user experience.

[0008] Therefore, there is an urgent need for a universal solution that can bridge process engines with multiple business data sources and flexibly and efficiently assemble task contexts. Summary of the Invention

[0009] The purpose of this invention is to overcome the shortcomings of the prior art and provide a universal task query device that is compatible with multiple business characteristics.

[0010] Firstly, a general-purpose task query device compatible with multiple business characteristics is provided, including:

[0011] The process engine interface module is used to obtain the user's list of pending process tasks from the process engine data source. Each pending process task contains at least a process instance ID, a task definition KEY, and a business instance ID.

[0012] The business model registry is used to store metadata models of multiple business systems. Each metadata model is associated with a task definition key and a business type, and defines the business data query method, data assembly rules, and task operation context for that business type in a specific production MIS system.

[0013] The business data aggregation module, connected to the process engine interface module and the business model registry center, is used to locate the corresponding metadata model from the business model registry center based on the business instance ID and task definition KEY in the process pending task list, and to query and extract business data in parallel from multiple dispersed production MIS system data sources according to the business data query method defined therein.

[0014] The task context assembly module is used to merge the basic information of the pending tasks from the process engine interface module with the business data from the business data aggregation module according to the data assembly rules defined in the metadata model, and assemble them into a rich pending task item containing a complete context.

[0015] The unified output module is used to standardize the output of the assembled list of rich to-do items.

[0016] Preferably, the business data aggregation module includes:

[0017] The query routing unit is used to route the business instance ID to the corresponding metadata model and the corresponding production MIS system data source based on the task definition KEY.

[0018] The parallel query unit is used to execute multiple different business data query requests concurrently to reduce overall query latency;

[0019] Data adapters are used to interface with different types of data sources, including relational databases, SOAP, or RESTful APIs, and to perform initial data format conversion.

[0020] Preferably, the device further includes:

[0021] The operation capability parsing engine, connected to the task context assembly module and the business model registration center, is used to obtain the task operation context from the corresponding metadata model based on the current status and business type of the rich to-do task item, dynamically parse and generate a list of operation buttons that the user can execute on the current task item.

[0022] Preferably, the task operation context includes operation button definitions, front-end component identifiers, back-end API interfaces, and business rule validator addresses.

[0023] Preferably, the business model registry defines a metadata model through an extensible markup language or configuration file, and the business data query method is a parameterized SQL statement, a pre-built API call template, or a specific function service.

[0024] Preferably, the rich to-do items output by the unified output module include core fields for interface rendering, business detail data from the production MIS system, and a list of executable operations.

[0025] Preferably, the device further includes:

[0026] The result caching module is used to cache the rich to-do task items and generate corresponding cache keys. The cache key is composed of user identity, task definition KEY and business instance ID.

[0027] Secondly, a general-purpose task query method compatible with multiple business characteristics is provided, executed by any of the devices described in the first aspect, comprising:

[0028] S1. Obtain the user's list of pending tasks from the process engine data source, where each pending task contains at least a process instance ID, a task definition KEY, and a business instance ID;

[0029] S2. Stores metadata models for multiple business systems. Each metadata model is associated with a task definition key or business type, and defines the business data query method, data assembly rules, and task operation context for that business type in a specific production MIS system.

[0030] S3. Based on the business instance ID and task definition KEY in the process to-do task list, locate the corresponding metadata model from the business model registration center, and query and extract business data in parallel from multiple dispersed production MIS system data sources according to the business data query method defined therein.

[0031] S4. According to the data assembly rules defined in the metadata model, the basic information of the pending tasks from the process engine interface module and the business data from the business data aggregation module are merged and assembled into a rich pending task item containing a complete context.

[0032] S5. Standardize and output the assembled list of tasks to be done.

[0033] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method as described in the second aspect.

[0034] Fourthly, a computer-readable storage medium is provided, on which a computer program is stored, which, when executed by a processor, implements the method described in the second aspect.

[0035] The beneficial effects of this invention are:

[0036] 1. Information integration improves efficiency: Key business data is displayed directly in the to-do list, eliminating the need for users to navigate to different pages and accelerating the decision-making process.

[0037] 2. High decoupling and versatility: New types of to-do tasks or changes to existing logic can be added by configuring the business model, without requiring any changes to the core devices, thus achieving decoupling from specific business operations.

[0038] 3. Clear architecture and easy maintenance: All business data query logic is centrally managed in the calibration center, avoiding code dispersion and redundant development, and greatly reducing maintenance costs.

[0039] 4. High performance: It adopts a parallel query mechanism, which sends requests to multiple MIS systems at the same time, effectively reducing the total query latency.

[0040] 5. Dynamic operation parsing: Operation buttons are dynamically generated based on the complete task context, ensuring the accuracy and context relevance of the operation. Attached Figure Description

[0041] Figure 1 This is a general structural block diagram of the device provided in the embodiments of the present invention.

[0042] Figure 2 This is a detailed flowchart of the pending task query and assembly in an embodiment of the present invention. Detailed Implementation

[0043] The present invention will be further described below with reference to embodiments. The description of the embodiments below is only for the purpose of helping to understand the present invention. It should be noted that those skilled in the art can make several modifications to the present invention without departing from the principle of the present invention, and these improvements and modifications also fall within the protection scope of the claims of the present invention.

[0044] Example 1:

[0045] To address the challenge of task querying in existing technologies with a separation of process and business data architecture, Embodiment 1 of this application provides a general-purpose task query device compatible with various business characteristics. By registering a business model, it automatically pulls business data from a distributed MIS system and integrates it with process tasks to generate rich, complete, and operable tasks, thereby improving work efficiency and system flexibility.

[0046] Specifically, the device includes:

[0047] The process engine interface module, serving as the data entry point, retrieves the basic to-do list from a unified source. Specifically, the process engine interface module is used to obtain the user's list of process to-do tasks from the process engine data source, where each process to-do task contains at least a process instance ID, a task definition KEY, and a business instance ID.

[0048] The business model registry stores knowledge on how all task types retrieve business data. Furthermore, the business model registry defines how to retrieve business data for different types of tasks (identified by `task_def_key`). Specifically, the business model registry stores metadata models for multiple business systems. Each metadata model is associated with a task definition key and a business type, and defines the business data query methods, data assembly rules, and task operation context for that business type in a specific production MIS system.

[0049] The task operation context includes operation button definitions, front-end component identifiers, back-end API interfaces, and business rule validator addresses.

[0050] In addition, the business model registry defines a metadata model through an extensible markup language or configuration file, and the business data query method is a parameterized SQL statement, a pre-built API call template, or a specific function service.

[0051] The business data aggregation module is used to retrieve data from various MIS systems in parallel according to instructions from the business model registry center. Specifically, the business data aggregation module connects to the process engine interface module and the business model registry center. It is used to locate the corresponding metadata model from the business model registry center based on the business instance ID and task definition KEY in the process pending task list, and query and extract business data in parallel from multiple distributed production MIS system data sources according to the defined business data query method.

[0052] The task context assembly module combines basic task information with detailed business data. Specifically, according to the data assembly rules defined in the metadata model, the task context assembly module merges the basic information of the pending tasks from the process engine interface module with the business data from the business data aggregation module to assemble a rich pending task item containing a complete context.

[0053] The unified output module is used to standardize the output of the assembled list of rich to-do items.

[0054] The rich to-do items output by the unified output module include core fields for interface rendering, business detail data from the production MIS system, and a list of executable operations.

[0055] Example 2:

[0056] Based on Embodiment 1, Embodiment 2 of this application provides a more specific general-purpose task query device compatible with multiple business characteristics, such as... Figure 1 As shown, it includes:

[0057] The process engine interface module is used to obtain the user's list of pending process tasks from the process engine data source. Each pending process task contains at least a process instance ID, a task definition KEY, and a business instance ID.

[0058] For example, such as Figure 2 As shown, the workflow engine interface module queries the user's pending tasks using the native REST API or Java API provided by the workflow engine (such as Camunda, Flowable, or Activiti). The query result is a basic list of tasks, where each task item contains at least the following key metadata:

[0059] task_id: A unique identifier for the task

[0060] task_def_key: Task definition key (e.g., "equipment_repair_approval"), used to identify the type of task.

[0061] biz_instance_id: Business instance ID (e.g., "WO202400001"), is a unique key associated with specific business data.

[0062] task_name: Task name

[0063] create_time: Task creation time

[0064] The business model registry is used to store metadata models of multiple business systems. Each metadata model is associated with a task definition key or business type, and defines the business data query method, data assembly rules, and task operation context for that business type in a specific production MIS system.

[0065] For example, the business model registry uses a MySQL relational database as the storage medium, and achieves metadata model persistence, version management and efficient querying through a standardized table structure.

[0066] Database table structure design:

[0067] (1) Business Model Main Table (biz_model)

[0068]

[0069] (2) Data source configuration table (datasource_config)

[0070]

[0071] (3) Field mapping table (field_mapping)

[0072]

[0073]

[0074] Configuration example:

[0075] The configuration for the equipment repair approval model in the datasource_config table is as follows:

[0076]

[0077] For SQL type data sources:

[0078]

[0079] The business data aggregation module, connected to the process engine interface module and the business model registry center, is used to locate the corresponding metadata model from the business model registry center based on the business instance ID and task definition KEY in the process pending task list, and to query and extract business data in parallel from multiple dispersed production MIS system data sources according to the business data query method defined therein.

[0080] For example, the business data aggregation module is responsible for efficiently and reliably executing data acquisition tasks based on MySQL model configurations.

[0081] Configuration loader: When the module starts, it loads all enabled (status=1) business model configurations from the MySQL database and creates an index in memory from task_definition_key to the model configuration. Simultaneously, a listening mechanism is established to detect and update the configuration in memory in real time when model configurations change, using the updated_time field in the database or a dedicated configuration change event table.

[0082] Query routing and execution engine: Retrieve the corresponding data source configuration from the memory index based on the `task_def_key` in the task. The execution engine calls the appropriate adapter based on the `source_type`.

[0083] REST API adapter: Constructs HTTP requests based on configuration, automatically replaces biz_instance_id in URL parameters or request body, handles authentication tokens, and sets timeout and retry mechanisms.

[0084] SQL adapter: Obtains a connection from the corresponding data source connection pool (such as Druid), executes parameterized queries, uses PreparedStatement to prevent SQL injection, and converts the ResultSet into a standard Map structure.

[0085] Script engine adapter: For complex business logic, it supports Groovy scripts and can combine data from multiple systems.

[0086] Parallel query optimization: Asynchronous parallel queries are implemented using CompletableFuture. For multiple tasks in a single user's to-do list, data query requests are initiated simultaneously, with concurrency controlled by ExecutorService to ensure system stability.

[0087] The task context assembly module is used to integrate the basic information of the pending tasks from the process engine interface module with the business data from the business data aggregation module according to the data assembly rules defined in the metadata model, and assemble them into rich pending task items containing complete context.

[0088] For example, the task context assembly module performs precise data transformation and assembly based on field mapping rules stored in MySQL.

[0089] Dynamic field mapping engine: Reads all field mapping rules for the current task type from the field_mapping table, sorts them by display_order, and executes them sequentially. The engine supports complex source field paths, such as data.equipment.baseInfo.name, and extracts values ​​through reflection and expression parsing (such as Spring SpEL).

[0090] Data transformation pipeline: Each field goes through a transformation pipeline during the mapping process.

[0091]

[0092]

[0093] The convertValue method executes the Groovy script defined in converter_script to achieve flexible data cleaning, format conversion, and business logic processing.

[0094] The unified output module is used to standardize the output of the assembled list of rich to-do items.

[0095] For example, this module encapsulates the completed rich list of to-do tasks into a JSON response in a uniform format. Meanwhile, the MySQL caching policy table `cache_policy` determines whether to cache and the cache duration. The cache key generation strategy is: MD5(user_id+task_def_key+biz_instance_id), ensuring key uniqueness and query efficiency.

[0096] In addition, the device includes an operation capability parsing engine, which can determine and generate executable operations based on the fused complete context. Specifically, the operation capability parsing engine is connected to the task context assembly module and the business model registry center, and is used to obtain the task operation context from the corresponding metadata model based on the current state and business type of the rich to-do task item, dynamically parse and generate a list of operation buttons that the user can execute on the current task item.

[0097] For example, the operation capability parsing engine implements dynamic permission control based on predefined operation policies in MySQL.

[0098] Operation policy configuration: Create a new table named action_policy in MySQL to store the list of operations available for each task type under different states, as well as the display conditions for each operation (defined via Groovy scripts).

[0099] Dynamic Operation Analysis: Engine Execution Flow:

[0100] (1) Query all available operations for the current task type

[0101] (2) For each operation, execute its precondition script, passing in all the data of the rich to-do task items as context.

[0102] (3) The operation is added to the final operation list only if the precondition returns true.

[0103] (4) Generate complete context information for each operation, including API endpoints, front-end components, validation rules, etc.

[0104] Furthermore, the device also includes a result caching module for caching the rich to-do task items, wherein the cache key is composed of the user identity, the task definition KEY, and the business instance ID.

[0105] It should be noted that the parts in this embodiment that are the same as or similar to those in Embodiment 1 can be referred to each other, and will not be repeated in this application.

[0106] Example 3:

[0107] Based on Embodiment 1, Embodiment 3 of this application provides a general task query method compatible with multiple business characteristics, including:

[0108] S1. Obtain the user's list of pending tasks from the process engine data source, where each pending task contains at least a process instance ID, a task definition KEY, and a business instance ID.

[0109] S2 stores metadata models for multiple business systems. Each metadata model is associated with a task definition key or business type and defines the business data query method, data assembly rules, and task operation context for that business type in a specific production MIS system.

[0110] S3. Based on the business instance ID and task definition KEY in the process pending task list, locate the corresponding metadata model from the business model registration center, and query and extract business data in parallel from multiple dispersed production MIS system data sources according to the business data query method defined therein.

[0111] S4. According to the data assembly rules defined in the metadata model, the basic information of the to-do task from the process engine interface module and the business data from the business data aggregation module are merged to assemble a rich to-do task item containing a complete context.

[0112] S5. Standardize and output the assembled list of tasks to be done.

[0113] It should be noted that the method provided in this embodiment is the corresponding method of the device provided in embodiment 1. Therefore, the parts that are the same as or similar to those in embodiment 2 in this embodiment can be referred to each other, and will not be repeated in this application.

[0114] In summary, through the detailed implementation based on MySQL storage described above, this invention constructs a to-do task query device and method that ensures data consistency while possessing high flexibility and performance.

Claims

1. A universal task query device compatible with multiple business characteristics, characterized in that, include: The process engine interface module is used to obtain the user's list of pending process tasks from the process engine data source. Each pending process task contains at least a process instance ID, a task definition KEY, and a business instance ID. The business model registry is used to store metadata models of multiple business systems. Each metadata model is associated with a task definition key and a business type, and defines the business data query method, data assembly rules, and task operation context for that business type in a specific production MIS system. The business data aggregation module, connected to the process engine interface module and the business model registry center, is used to locate the corresponding metadata model from the business model registry center based on the business instance ID and task definition KEY in the process pending task list, and to query and extract business data in parallel from multiple dispersed production MIS system data sources according to the business data query method defined therein. The task context assembly module is used to merge the basic information of the pending tasks from the process engine interface module with the business data from the business data aggregation module according to the data assembly rules defined in the metadata model, and assemble them into a rich pending task item containing a complete context. The unified output module is used to standardize the output of the assembled list of rich to-do items.

2. The universal task query device compatible with multiple business characteristics according to claim 1, characterized in that, The business data aggregation module includes: The query routing unit is used to route the business instance ID to the corresponding metadata model and the corresponding production MIS system data source based on the task definition KEY. The parallel query unit is used to execute multiple different business data query requests concurrently to reduce overall query latency; Data adapters are used to interface with different types of data sources, including relational databases, SOAP, or RESTful APIs, and to perform initial data format conversion.

3. The universal task query device compatible with multiple business characteristics according to claim 2, characterized in that, The device further includes: The operation capability parsing engine, connected to the task context assembly module and the business model registration center, is used to obtain the task operation context from the corresponding metadata model based on the current status and business type of the rich to-do task item, dynamically parse and generate a list of operation buttons that the user can execute on the current task item.

4. The universal task query device compatible with multiple business characteristics according to claim 3, characterized in that, The task operation context includes operation button definitions, front-end component identifiers, back-end API interfaces, and business rule validator addresses.

5. The universal task query device compatible with multiple business characteristics according to claim 4, characterized in that, The business model registry defines a metadata model through an extensible markup language or configuration file, and the business data query method is a parameterized SQL statement, a pre-built API call template, or a specific function service.

6. The universal task query device compatible with multiple business characteristics according to claim 5, characterized in that, The rich to-do items output by the unified output module include core fields for interface rendering, business detail data from the production MIS system, and a list of executable operations.

7. The universal task query device compatible with multiple business characteristics according to claim 6, characterized in that, The device further includes: The result caching module is used to cache the rich to-do task items and generate corresponding cache keys; the cache key is composed of user identity, task definition KEY and business instance ID.

8. A general-purpose task query method compatible with multiple business characteristics, characterized in that, Performed by the apparatus according to any one of claims 1 to 7, comprising: S1. Obtain the user's list of pending tasks from the process engine data source, where each pending task contains at least a process instance ID, a task definition KEY, and a business instance ID; S2 stores metadata models for multiple business systems. Each metadata model is associated with a task definition key or business type and defines the business data query method, data assembly rules, and task operation context for that business type in a specific production MIS system. S3. Based on the business instance ID and task definition KEY in the process to-do task list, locate the corresponding metadata model from the business model registration center, and query and extract business data in parallel from multiple dispersed production MIS system data sources according to the business data query method defined therein. S4. According to the data assembly rules defined in the metadata model, the basic information of the pending tasks from the process engine interface module and the business data from the business data aggregation module are merged and assembled into a rich pending task item containing a complete context. S5. Standardize and output the assembled list of tasks to be done.

9. A computer device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the method of claim 8.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as described in claim 8.

Images