Task management system and operating method thereof
Patent Information
- Application Number
- TW114112979
- Authority / Receiving Office
- TW · TW
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2025-03-14
- Filing Date
- 2025-04-07
- Publication Date
- 2026-09-16
- Estimated Expiration
- 2045-04-06
Smart Images

Figure TWG2TA001076048_001 
Figure TWG2TA001076048_002 
Figure TWG2TA001076048_003
Abstract
Description
Technical Field
[0001] This invention relates to a management system, and more particularly to an application data-driven task management system and its operating method. Prior Technology
[0002] Generally, enterprise systems can be data-driven to collect, analyze, and utilize large amounts of business data to execute target tasks. However, because current enterprise systems employ a single mapping between business data and tasks, when the same business data triggers the system, the system needs to perceive the different tasks corresponding to that data multiple times. Thus, current enterprise systems cannot efficiently execute target tasks and incur high operating costs in diverse and complex business scenarios. Summary of the Invention
[0003] This invention provides a task management system that can improve the efficiency of data-driven operations.
[0004] The task management system of this invention includes a storage device and a processor. The storage device stores a knowledge graph. The knowledge graph includes type data, data features, events, and relationships between tasks. The processor is coupled to the storage device and an application system. The processor analyzes application data from the application system to generate analysis results. The analysis results include the business type of the application data. Based on the analysis results and the knowledge graph, the processor obtains at least one possible task associated with the application data. The processor executes the possible task based on the application data.
[0005] This invention also provides another method for operating a task management system. The method includes the following steps: 1. Storing a knowledge graph using a storage device. The knowledge graph includes type data, data features, events, and relationships between tasks. 2. Analyzing application data from an application system using a processor to generate analysis results. The analysis results include the business type of the application data. 3. Obtaining at least one possible task related to the application data using the processor based on the analysis results and the knowledge graph. 4. Executing the possible task using the application data using the processor.
[0006] Based on the above, the task management system and its operation method of this invention are based on knowledge graphs. By analyzing the possible tasks associated with application data, it can perceive all possible tasks corresponding to the same application data at once, thereby improving the efficiency and accuracy of data-driven operations. Furthermore, the task management system can avoid setting various single correspondences between application data and tasks, thereby reducing operating costs.
[0007] To make the above features and advantages of the present invention more apparent and understandable, specific embodiments are described below in conjunction with the accompanying drawings for detailed explanation. Simple Explanation of the Diagram
[0008] Figure 1A is a block diagram of a task management system according to an embodiment of the present invention. Figure 1B is a schematic diagram of the operation of the task management system according to the embodiment of Figure 1A of the present invention. Figure 2 is a flowchart illustrating the operation method of a task management system according to another embodiment of the present invention. Figure 3 is an architecture diagram of a task management system according to an embodiment of the present invention. Figure 4 is a flowchart illustrating the operation method of the task management system according to the embodiment of Figure 3 of the present invention. Figure 5 is a flowchart illustrating a portion of the operation method according to the embodiment shown in Figure 3 of the present invention. Figure 6 is a schematic diagram of the operation of the task management system according to the embodiment of Figure 3 of the present invention. Figure 7 is a flowchart illustrating a portion of the operation method according to the embodiment shown in Figure 3 of the present invention. Figure 8 is a schematic diagram of the operation of the task management system according to the embodiment of Figure 3 of the present invention. Implementation
[0009] Some embodiments of the present invention will now be described in detail with reference to the accompanying drawings. Component symbols used in the following description are considered to be the same or similar components when they appear in different drawings. These embodiments are only a part of the present invention and do not disclose all possible implementations of the invention. More precisely, these embodiments are merely examples within the scope of the present invention's patent application.
[0010] Figure 1A is a block diagram of a task management system according to an embodiment of the present invention. Figure 1B is an operational schematic diagram of the task management system according to the embodiment of Figure 1A. Referring to Figures 1A and 1B, the task management system 100 is data-driven. The task management system 100 can observe and analyze the application data D1 of the application system 200 according to unified rules, and execute one or more target tasks TK1~TK2 based on the analysis results. The application data D1 may be, for example, a modified document. Target task TK1 may be, for example, a work order related to the document. Target task TK2 may be, for example, a purchase order related to the document.
[0011] In the embodiment of Figure 1A, the task management system 100 includes a processor 110 and a storage device 120. The processor 110 is coupled to the storage device 120 and the application system 200. The task management system 100 may be located in the cloud. The task management system 100 may be, for example, a Platform as a Service (PaaS) server, to execute corresponding PaaS applications through an Application Programming Interface (API).
[0012] In this embodiment, a user can operate an electronic device to call the task management system 100 via API, and then the task management system 100 executes the corresponding task (e.g., target task TK1) based on data-driven principles. The user can also operate the electronic device to call the application system 200 via API, and then the application system 200 executes various business services. The electronic device can be, for example, a mobile phone, tablet computer, laptop computer, or desktop computer. The application system 200 can be, for example, an Enterprise Resource Planning (ERP) system.
[0013] In this embodiment, storage device 120 stores knowledge graph 121. Knowledge graph 121 includes type data, data features, events, and relationships between tasks. Storage device 120 may be, for example, Dynamic Random Access Memory (DRAM), Lash memory, Non-Volatile Random Access Memory (NVRAM), or a combination of these.
[0014] In this embodiment, the processor 110 accesses the storage device 110 and executes data in the storage device 110 and data from the application system 200 (e.g., application data D1). The processor 110 may be, for example, a signal converter, a field programmable gate array (FPGA), a central processing unit (CPU), or other programmable general-purpose or special-purpose microprocessor, digital signal processor (DSP), programmable controller, application-specific integrated circuit (ASIC), programmable logic device (PLD), or other similar device or combination of these devices, which can load and execute computer program-related firmware or software to implement data-driven and various calculation functions.
[0015] Figure 2 is a flowchart illustrating an operation method of a task management system according to another embodiment of the present invention. Referring to Figures 1A and 2, the task management system 100 executes steps S210-S230 to perform one or more tasks based on data-driven execution. The order of these steps S210-S230 is merely illustrative.
[0016] In step S210, processor 110 analyzes application data D1 from application system 200 to generate analysis result D2. Analysis result D2 includes the business type of application data D1. The business type indicates the business service applied to by application data D1. For example, the business type of application data D1 is a receipt type in a financial system or a traffic light type in a traffic management system.
[0017] In step S220, the processor 110 obtains at least one possible task TKS associated with the application data D1 based on the analysis result D2 and the knowledge graph 121. That is, the processor 110 queries the knowledge graph 121 according to the business type of the application data D1 to obtain all possible task TKS (i.e., tasks in the knowledge graph 121) associated with the business type (i.e., type data in the knowledge graph 121).
[0018] In step S230, processor 110 executes the possible task TKS obtained in step S220 based on application data D1. For example, processor 110 executes accounts receivable operation (i.e., possible task TKS) based on the receipt (i.e., application data D1) to complete the collection operation.
[0019] It is worth mentioning that, based on the relationships stored in the knowledge graph 121, by first analyzing application data D1 and then executing possible tasks TKS, the task management system 100 can perceive all possible tasks TKS associated with application data D1 at once, thereby enhancing its perception capabilities in the data-driven process. Based on the knowledge graph 121, the task management system 100 does not need to set various one-to-one rules between application data D1 and all possible tasks TKS. Thus, the task management system 100 can improve the efficiency and accuracy of data-driven operations and reduce operating costs.
[0020] Figure 3 is an architecture diagram of a task management system according to an embodiment of the present invention. Referring to Figure 3, the task management system 300 includes a processor 310 and a storage device 320. The storage device 320 also stores algorithms, programs, and data related to computing software and other functions used to implement the data-driven, design, various calculations, and software execution functions of the present invention. The processor 310 executes the data and programs in the storage device 320. The processor 310 and the storage device 320 can be deduced by referring to the description of the task management system 100 and by analogy.
[0021] In the embodiment shown in Figure 3, the task management system 300 may be, for example, a PaaS server, and is represented by a framework model. The task management system 300 includes an infrastructure layer, a technology framework layer, a platform layer, an application layer, and an application entry point (including gateways and front-ends).
[0022] In detail, at the infrastructure layer, the task management system 300 includes a database. This database may be, for example, a relational database such as MySQL, Redis, MongoDB, Neo4j, RabbitMQ, and / or Kafka. At the technology framework layer, the task management system 300 includes frameworks such as Spring Boot, MyBatis, Dubbo, and / or DAP.
[0023] Within the platform layer, the task management system 300 includes a business middleware, a knowledge graph management service 311, a change data management service 312, a sensor service 313, a task execution service 314, and a scheduling management service 315. The knowledge graph management service 311 manages the knowledge graph (e.g., knowledge graph 121 shown in Figure 1A). Specifically, when a task is published, the knowledge graph management service 311 synchronizes the knowledge graph. During the runtime phase, the knowledge graph management service 311 queries the knowledge graph.
[0024] The change data management service 312 is used to access the application system (e.g., application system 200 shown in Figure 1A) and to push data and / or information to other services 311 and 313-315. The change data management service 312 may provide, for example, a data receiving service, an event receiving service, a data notification service, an event notification service, and a retry detection task. Specifically, the change data management service 312 receives data from the application system (e.g., application data D1 shown in Figure 1A) and retains the data. When the data is driven by an immediate event, the change data management service 312 immediately delivers the data to the sensor service 313. When the data is driven by an event, the change data management service 312 notifies the scheduling management service 315 so that the scheduling management service 315 periodically triggers an event information collection task. If an event is collected, the change data management service 312 delivers the collected event to the sensor service 313.
[0025] The perceptor service 313 is used to sense the data pushed by the change data management service 312. The perceptor service 313 is used to identify all tasks (e.g., possible tasks TKS shown in Figure 1A) associated with the data based on a knowledge graph (e.g., knowledge graph 121 shown in Figure 1A), and to drive the execution of the tasks accordingly. The perceptor service 313 may provide, for example, a perception trigger service, an instant-driven matching service, an event-driven matching service, and a startup management service. Specifically, the perceptor service 313 senses changed data and dynamically matches, automatically distributes, and drives the execution of subsequent tasks accordingly.
[0026] The task execution service 314 is driven by the sensor service 313 and executes tasks accordingly. The task execution service 314 may provide, for example, a task triggering service, a task execution service, and a data delivery service. Specifically, the task execution service 314 executes tasks. The object of the task may be, for example, a function script or a microservice. After the task is executed, when the execution result generates new changed data, the task execution service 314 delivers the changed data (i.e., as new application data) to the changed data management service 312.
[0027] The scheduling management service 315 is used to periodically trigger event information collection tasks. The scheduling management service 315 may provide services such as adding, modifying, enabling, and disabling schedules. Specifically, the scheduling management service 315 periodically triggers scheduled tasks registered by other services in the platform layer. The scheduling management service 315 itself does not execute specific business logic.
[0028] In the application layer, the task management system 300 includes a task management service 316, an application management service 317, a delivery management service 318, and a backend for frontend (BFF) service. The task management service 316 is used to set (including define) information such as tasks, data descriptions, and events, and automatically generate a knowledge graph (e.g., the knowledge graph 121 shown in Figure 1A) based on the defined information.
[0029] Specifically, during the design phase, the task management service 316 sets (including defines) the driving method of the task (including immediate driving and event driving), and also sets (including defines) the data information that the task is interested in (i.e., focuses on). The data information includes the events of interest, business type, change type, primary key, which fields in the data of interest, and the characteristics of the fields.
[0030] In addition, the task management service 316 also sets (including defines) data descriptions, events, and driving method converters. Data descriptions include descriptions of the business service such as the business type's number, name (e.g., work order), primary key (e.g., work order number), fields, and query methods. Events include event information such as the event's number, name (e.g., traffic congestion), type, and trigger rules. The driving method converter includes converter information. The driving method converter is used to convert the data associated with the event into real-time data based on the converter information. The converter information includes the correspondence between events and data information (i.e., real-time data) (i.e., conversion rules).
[0031] In this embodiment, the task management service 316 generates a knowledge graph (e.g., the knowledge graph 121 shown in Figure 1A) based on the set driving mode, data information, data description (including business type), event information, and driving mode converter (including the correspondence between events and data information). Thus, the knowledge graph indicates the relationship between type data, data features, events, and tasks.
[0032] Figure 4 is a flowchart illustrating the operation method of the task management system according to the embodiment of Figure 3 of the present invention. Referring to Figures 3 and 4, the task management system 300 executes steps S410-S460, S500 and S700 to execute one or more tasks based on data-driven execution.
[0033] During the runtime phase, when changes occur in the application system (e.g., application system 200 shown in Figure 1A), processor 310 accesses the changed data in the application system (i.e., application data D1 shown in Figure 1A). Processor 310 then automatically analyzes the driving method, business type, change type, and data characteristics of the application data to find one or more possible tasks (i.e., possible tasks TKS shown in Figure 1A) from the knowledge graph. Processor 310 matches and distributes the analyzed data characteristics with the possible tasks.
[0034] Continuing with the above description, processor 310 executes the matched possible tasks based on the characteristics of the split data to generate corresponding execution results. Then, processor 310 outputs the execution results of the possible tasks to the application system to update the application system. When the updated application system changes again, processor 310 accesses the changed data in the updated application system as the current application data. Processor 310 performs the various operations described above based on this application data until no data changes in the application system.
[0035] Specifically, in step S410, the processor 310 analyzes the application data to generate analysis results. The analysis results include the service type and driving method of the application data.
[0036] In step S420, the processor 310 determines, based on the analysis results, whether the driving mode of the application data is instant-driven or event-driven.
[0037] When the driving mode is immediate driving, the processor 310 continues with step S500. In step S500, the processor 310 immediately drives and executes the associated possible tasks based on the application data. Details of step S500 can be found in the embodiment shown in Figure 5.
[0038] On the other hand, when the driving method is event-driven, processor 310 continues with steps S430-S460 and S800. In step S430, processor 310 stores application data to storage device 320. That is, processor 310 does not immediately query the possible tasks associated with the application data, but temporarily stores the application data.
[0039] In step S440, the processor 310, based on the application data stored in step S430, invokes the task management service 316 to execute the driver-mode converter and generates a conversion result accordingly. The driver-mode converter includes the relationship between events and real-time data (e.g., conversion rules).
[0040] In step S450, the processor 310 determines, based on the conversion result, whether the application data stored in step S430 has been successfully converted into real-time data.
[0041] When the conversion result indicates failure, processor 310 continues with step S700. In step S700, processor 310 collects application data from the application system within a period to generate event data based on the conversion result. That is, when the application data is only suitable for event-driven scenarios and cannot be converted to instant-driven scenarios, processor 310 collects application data over a period of time and treats the application data as event data. Based on the event data, processor 310 drives and executes any associated possible tasks. Details of step S700 can be found in the embodiment shown in Figure 7.
[0042] When the conversion result indicates success, processor 310 executes step S460. In step S460, processor 310 clears the application data stored in step S430 based on the conversion result. Furthermore, after clearing the aforementioned application data, processor 310 accesses the real-time data converted in step S440, that is, it treats the application data's driving method as real-time driving. Processor 310 continues with step S500 based on the real-time data.
[0043] It should be noted that the task management system 300 calls the sensor service 313 to sense changing data (i.e., application data), and then performs data-task matching, or data-event conversion and triggering. Only after successful matching or event triggering will the task management system 300 call the task execution service 314 to execute all associated possible tasks. In other words, the task management system 300 determines the next operation based on various calculation results, rather than directly driving the corresponding task based on a one-to-one fixed rule.
[0044] Figure 5 is a flowchart illustrating a portion of the operation method according to the embodiment of Figure 3 of the present invention. Referring to Figures 3 and 5, when the application data is driven in a real-time manner, the task management system 300 executes steps S510 to S592 through the processor 310, and the details of step S500 regarding real-time driving in Figure 5 are illustrated by example.
[0045] In this embodiment, the instant-driven approach is configured such that once the application data becomes available, all possible tasks associated with the application data are immediately triggered (i.e., driven). This instant-driven approach is suitable for scenarios requiring rapid responses to single changes in data. Such scenarios include, for example, the generation, modification, or deletion of business documents (i.e., changed data, i.e., application data). Thus, the instant-driven approach can quickly respond to application data to drive possible tasks, thereby improving the immediacy of data processing.
[0046] In step S510, the processor 310 analyzes the business type, change type, and data characteristics of the application data to generate analysis results. The analysis results include that the application data is driven by real-time processes, and also include the business type, change type, and data characteristics of the application data.
[0047] In step S520, the processor 310 queries the knowledge graph based on the analysis results in step S510 to obtain one or more tasks (i.e., potential tasks) associated with the application data (i.e., those of interest).
[0048] In step S530, the processor 310 queries the knowledge graph based on the task obtained in step S520 to obtain query results including the definition of the task (i.e., possible task), the type of data of interest, and data features.
[0049] In step S540, the processor 310 determines whether the task is singular based on the query result in step S530, thus considering it as a single possible task.
[0050] If the judgment result of step S540 is yes, it means that the application data focuses on a single task (i.e., a single possible task). The processor 310 continues with steps S551 to S580.
[0051] In step S551, the processor 310 determines, based on the knowledge graph, whether the possible tasks in step S540 focus on all data features and change types to generate matching results.
[0052] If the judgment result of step S551 is negative, it indicates that the matching result suggests that the possible task is a task that has not been disturbed due to the application data. That is to say, the possible task does not need to be driven or executed.
[0053] On the other hand, if the determination result of step S551 is yes, it indicates that the matching result suggests that the task may be a task disturbed by the application data. The processor 310 continues to step S553.
[0054] In step S553, the processor 310 determines whether the possible task has started the synchronization mechanism based on the query result in step S530. That is, the processor 310 determines whether the possible task is to be executed based on the latest application data.
[0055] If the determination result of step S553 is yes, the processor 310 continues with steps S561 to S563. On the other hand, if the determination result of step S553 is yes, the processor 310 ignores steps S561 to S562 and directly continues with step S563.
[0056] In step S561, the processor 310 accesses the application system based on the analysis results in step S510 to obtain data descriptions of the business types of the application data. That is, the processor 310 accesses the current application system to obtain the latest information on the business types. This information includes the business type's number, name, primary key, and descriptions of its fields.
[0057] In step S562, the processor 310 accesses the application system based on the matching result in step S551 and the service type of the application data to obtain the latest data characteristics of the application data. The service type may be, for example, included in the analysis result in step S510, or the latest service type accessed in step S561.
[0058] In step S563, the processor 310 performs the data feature matching operation from step S562 based on the knowledge graph to generate a matching result. That is, the processor 310 queries the knowledge graph based on the feature data to obtain the task associated with the feature data.
[0059] In step S570, the processor 310 determines, based on the knowledge graph, whether the possible task in step S551 matches the latest data features obtained in step S562, in order to drive the possible task. Alternatively, in the scenario where steps S561-S562 are ignored, the processor 310 determines, based on the knowledge graph, whether the possible task matches the data features analyzed in step S510 as the latest data features, in order to drive the possible task.
[0060] If the determination result of step S570 is yes, the processor 310 continues to step S580. In step S580, the processor 310 drives the matched possible task and executes the possible task according to the application data. On the other hand, if the determination result of step S570 is no, the processor 310 terminates the process.
[0061] On the other hand, if the determination result of step S540 is negative, it indicates that the application data focuses on multiple tasks as multiple possible tasks. The processor 310 continues with steps S552 and S591~592.
[0062] At this point, the processor 310, based on the analysis results (e.g., business type) and the knowledge graph in step S510, obtains the data features associated with the application data and the coexistence relationships between multiple tasks of interest (i.e., multiple possible tasks). The coexistence relationships indicate the execution order among the multiple possible tasks, such as simultaneous execution or sequential execution and their order.
[0063] In step S552, the processor 310 determines whether the data features and the coexistence relationship between multiple possible tasks are "or".
[0064] When the judgment result of step S552 is yes, it means that each possible task that the application data is concerned with can be executed individually. Processor 310 continues to step S591. In step S591, according to the coexistence relationship indicated by "or", processor 310 sequentially judges whether multiple possible tasks are concerned with all data features and change types according to the knowledge graph to generate matching results, and drives multiple possible tasks that are judged to be yes according to the matching results.
[0065] On the other hand, when the judgment result of step S552 is negative, it means that all possible tasks that the application data is concerned with need to be executed simultaneously. Processor 310 continues to step S592. In step S592, processor 310, based on the coexistence relationship indicated as "no", simultaneously determines, according to the knowledge graph, whether multiple possible tasks are concerned with all data features and change types to generate matching results, and drives multiple possible tasks that are judged as yes based on the matching results.
[0066] In other words, the processor 330 executes steps S551 to S580 sequentially or simultaneously based on multiple possible tasks according to the coexistence relationship, so as to drive multiple possible tasks sequentially or simultaneously.
[0067] It should be noted that in complex business scenarios, changes in a single application data point can trigger the execution of multiple tasks, and a single task can simultaneously monitor changes in multiple application data points. The Task Management System 300, by querying a knowledge graph based on the application data to identify all possible tasks that the application data is concerned with, can perform one-time logical awareness.
[0068] Furthermore, by separating the matching and triggering operations of potential tasks into two steps, the task management system 300 can quickly identify potentially disturbed tasks based on a knowledge graph. Simultaneously, the task management system 300 can avoid calculating unnecessary task activation conditions, thereby improving timeliness. By acquiring the latest data features, the task management system 300 can ensure the timeliness and consistency of data.
[0069] Figure 6 is a schematic diagram of the operation of the task management system according to the embodiment of Figure 3 of the present invention, illustrating the application of a real-time driven knowledge graph. Referring to Figures 3 and 6, the knowledge graph includes multiple nodes 611-643 and their relationships.
[0070] In detail, node 611 represents type data. Node 611 may, for example, indicate a business type, such as a payment receipt. Node 611 includes multiple nodes 621-622. These nodes 621-622 represent data characteristics. Node 621 may, for example, indicate the flow type included in the payment receipt. Node 622 may, for example, indicate the claim status included in the payment receipt. Furthermore, node 611 also triggers node 631. Node 631 represents a change type. Node 631 may, for example, indicate the method of changing the payment receipt (e.g., modification, or deletion).
[0071] Furthermore, multiple nodes 641-643 monitor multiple nodes 621-622 and 631, and influence node 611. These nodes 641-643 represent tasks. Node 641 may, for example, instruct the execution of accounts receivable operations based on a receipt. Node 642 may, for example, instruct the execution of other collection operations based on a receipt. Node 643 may, for example, instruct the execution of manual processing operations based on a receipt.
[0072] During the design phase, Task Management Service 316 defines tasks such as accounts receivable operations, other collection operations, and manual processing operations, and also defines the data descriptions for collection slips. Task Management Service 316 publishes multiple defined tasks and generates a knowledge graph based on the defined information, as shown in Figure 6.
[0073] During the design phase, Application Management Service 317 assembles the application based on the knowledge graph by performing tasks. Delivery Management Service 318 delivers the assembled tasks to the designated tenant. Knowledge Graph Management Service 311 synchronizes the knowledge graph based on the assembled tasks.
[0074] During the runtime phase, when a payment receipt changes, the change data management service 312 accesses the receipt as application data. The change data management service 312 invokes the data receiving service to receive the delivered payment receipt. The change data management service 312 records the payment receipt in a data change log database (e.g., MySQL) and sends the payment receipt to an information queue database (e.g., MQ). The change data management service 312 consumes the payment receipt and invokes the data notification service to push the payment receipt to the sensor service 313.
[0075] During the runtime phase, the Perceptor Service 313 invokes the Perception Trigger Service to obtain the definitions of multiple tasks associated with the payment receipt based on the knowledge graph. These tasks include accounts receivable operations, other payment collection operations, and manual processing operations, as indicated by nodes 641-643, as multiple possible tasks. The Perception Trigger Service also accesses the business middle platform to obtain the latest details of the payment receipt as the latest data features of the application data.
[0076] Furthermore, the sensor service 313 also invokes the real-time driven matching service to perform matching based on the acquired multiple possible tasks and the latest details of the receipt to generate a matching result (e.g., the judgment result in step S570). The sensor service 313 invokes the startup management service to, based on the matching result, divert the first data of the receipt to a possible task indicating an accounts receivable operation, and divert the second data of the receipt to a possible task indicating another collection operation.
[0077] During the runtime phase, the task execution service 314 sequentially calls the task triggering service and the task execution service to drive possible tasks indicating accounts receivable operations and other collection operations, respectively. The task execution service 314 also calls the data delivery service to use the task execution result as a new collection slip and outputs the collection slip to the application system and the change data management service 312.
[0078] Figure 7 is a flowchart illustrating a portion of the operation method according to the embodiment of Figure 3 of the present invention. Referring to Figures 3 and 7, when the application data is driven by an event-driven approach, the task management system 300 executes steps S710 to S790 through the processor 310, illustrating the details of step S700 in Figure 5 regarding the event-driven approach.
[0079] In this embodiment, the event-driven approach is configured to trigger possible tasks based on changes in application data over a period of time or when application data meets specific conditions. This event-driven approach is suitable for scenarios requiring decisions based on data trends or patterns. Such scenarios include, for example, traffic flow monitoring and operational monitoring. Thus, the event-driven approach can reduce unnecessary task triggering, thereby improving data processing efficiency.
[0080] In step S710, the processor 310 periodically collects application data and records the collected application data into the storage device 320.
[0081] In step S720, the processor 310 obtains the events associated with the application data based on the knowledge graph.
[0082] In step S730, the processor 310 collects application data from the storage device 320 within a cycle to generate event data. The processor 310 analyzes the event data (i.e., the application data collected within the cycle) to generate analysis results. The analysis results include whether the application data is driven by events, and also include the business type and data characteristics of the application data. The data characteristics include the grouping fields of the events and the characteristics of the fields.
[0083] In step S740, processor 310 groups the event data in step S730 according to data characteristics (e.g., grouping fields) to generate multiple event data groups.
[0084] In step S750, the processor 310 performs feature matching on each event data group in step S740 based on the knowledge graph to determine whether all data features (e.g., grouping fields) of each event data group satisfy the possible task, and generates matching results accordingly.
[0085] In step S760, processor 310 determines whether the matching result in step S750 indicates success. If the determination result in step S760 is negative, it means that the current set of event data in step S740 does not match the possible task. Processor 310 continues to step S790.
[0086] In step S790, the processor 310 determines whether there is a next group of event data in step S760. If the determination result of step S790 is negative, it means that all multiple event data groups have been matched and the process ends. On the other hand, if the determination result of step S790 is positive, the processor 310 continues to step S750 to perform feature matching on the next group of event data.
[0087] On the other hand, if the judgment result of step S760 is yes, it means that the current set of event data in step S740 matches a possible task. Processor 310 continues steps S771 to S780.
[0088] In step S771, the processor 310 queries the knowledge graph based on the current set of event data to obtain tasks that focus on the event data set as possible current tasks.
[0089] In step S771, processor 310 clears the diverted event data.
[0090] In step S780, processor 310, based on the matching result in step S750, drives the corresponding possible task according to the current event data group. Processor 310 continues to step S790.
[0091] Figure 8 is a schematic diagram of the operation of the task management system according to the embodiment of Figure 3 of the present invention, illustrating the application of an event-driven knowledge graph. Referring to Figures 3 and 8, the knowledge graph includes multiple nodes 811-831 and their relationships.
[0092] In detail, node 811 represents type data. Node 811 could indicate a service type, such as a traffic light. Node 821 represents an event. Node 821 could indicate traffic congestion, for example. Node 831 affects node 811 and is concerned with node 821. Node 831 represents a task. Node 831 could indicate adjusting a traffic light, for example.
[0093] During the design phase, Task Management Service 316 defines the data description for adjusting traffic lights and event information such as traffic congestion conditions. Task Management Service 316 publishes the defined tasks and generates a knowledge graph based on the defined information, as shown in Figure 8.
[0094] During the design phase, Application Management Service 317 assembles the application based on the knowledge graph by performing tasks. Delivery Management Service 318 delivers the assembled tasks to the designated tenant. Knowledge Graph Management Service 311 synchronizes the knowledge graph based on the assembled tasks.
[0095] During operation, when a traffic light changes within a certain period, the change data management service 312 accesses the traffic flow at that traffic light during that period as event data. The change data management service 312 then calls the event receiving service to receive the submitted traffic flow data. Finally, the change data management service 312 records the traffic flow data to a data change log database (e.g., MySQL).
[0096] During the operation phase, the scheduling management service 315 periodically triggers traffic congestion event collection tasks to periodically send traffic flow data for a given period to an information queue database (e.g., MQ). The change data management service 312 consumes the traffic flow data and invokes the event notification service to push the traffic flow data to the sensor service 313.
[0097] During the runtime phase, the sensor service 313 calls the perception trigger service to obtain the definitions of multiple tasks associated with traffic flow and the definitions of traffic congestion events based on the knowledge graph, including traffic light adjustment operations as indicated by node 831 as possible tasks.
[0098] In addition, the sensor service 313 also invokes the event-driven matching service to match based on the acquired possible tasks and traffic flow to generate a matching result (e.g., the matching result in step S750). The sensor service 313 invokes the startup management service to drive the indication as a possible task for adjusting the traffic light operation based on the matching result.
[0099] During the runtime phase, the task execution service 314 sequentially calls the task triggering service and the task execution service to drive possible tasks that indicate the adjustment of traffic light operation. The task execution service 314 also calls the data delivery service to use the task execution result as the new traffic flow, and outputs the traffic flow to the application system and the change data management service 312.
[0100] In summary, the task management system and its operating method of this invention, based on data-driven principles, dynamically analyze changing data (i.e., application data or event data) and automatically match relevant potential tasks, enabling the management system to drive one or more potential tasks to form an efficient business processing chain. This allows the task management system to flexibly adapt to complex business scenarios, effectively reducing the problem of rapidly increasing development workload caused by the diversity of business data scenarios. Furthermore, by synchronizing data through a sensor service, the task management system ensures consistency between the database and the application data in the driven potential tasks. This enhances the stability and reliability of the system. Moreover, through an event-driven approach, the task management system achieves efficient, flexible, and intelligent data processing and decision-making, thereby optimizing resource utilization and improving system scalability and response speed.
[0101] Although the present invention has been disclosed above by way of embodiments, it is not intended to limit the present invention. Anyone skilled in the art can make some modifications and refinements without departing from the spirit and scope of the present invention. Therefore, the scope of protection of the present invention shall be determined by the appended claims.
[0102] 100, 300: Task Management System 110, 310: Processor 120, 320: Storage devices 121: Knowledge Graph 200: Application System 311: Knowledge Graph Management Service 312: Change Data Management Service 313: Sensor Service 314: Task Execution Service 315: Scheduling Management Service 316: Task Management Service 317: Application Management Service 318: Delivery Management Services Nodes 611, 621~622, 631, 641~643, 811, 821, 831 D1: Application Data D2: Analysis Results S210~S230, S410~S460, S500, S700, S510~S592, S710~S790: Steps TK1~TK2, TKS: Target Task
Claims
1. A task management system, comprising: A storage device for storing a knowledge graph, wherein the knowledge graph includes type data, data features, events, and relationships between tasks; The processor, coupled to the storage device and the application system, is configured to: analyze application data from the application system to generate analysis results, wherein the analysis results include the business type of the application data; obtain at least one possible task associated with the application data based on the analysis results and the knowledge graph; and execute the at least one possible task based on the application data, wherein the analysis results also include the driving mode of the application data, the data characteristics of the application data, and the change type, wherein the processor is further configured to: determine whether the driving mode is instant-driven or event-driven; when the driving mode is instant-driven, determine whether the at least one possible task pays attention to all the data characteristics and the change type based on the knowledge graph to generate a matching result; and when the driving mode is instant-driven, obtain the latest data characteristics based on the matching result and the business type.
2. The task management system as described in claim 1, wherein the processor is further configured to: access the application data in the application system when the application system changes; Output the execution result of at least one possible task to the application system to update the application system; And when the updated application system changes, the changed data in the updated application system is accessed as the application data.
3. The task management system as described in claim 1, wherein when the driving method is the real-time driving method, the processor is further configured to: determine, based on the knowledge graph, whether the at least one possible task matches the latest data features, so as to drive the at least one possible task.
4. The task management system as described in claim 1, wherein the at least one possible task includes multiple possible tasks, wherein when the driving method is the immediate driving method, the processor is further configured to: obtain the coexistence relationship between the data features and the multiple possible tasks based on the business type and the knowledge graph; and, based on the coexistence relationship, sequentially or simultaneously, determine, based on the knowledge graph, whether the multiple possible tasks pay attention to all the data features and the change type to generate a matching result, so as to drive the multiple possible tasks based on the matching result.
5. The task management system as described in claim 1, wherein when the driving mode is event-driven, the processor is further configured to: store the application data to the storage device; execute a driving mode converter to generate a conversion result based on the stored application data, wherein the driving mode converter includes the relationship between the event and the real-time data; and clear the stored application data based on the conversion result, or collect the application data in the application system periodically to generate event data.
6. The task management system as described in claim 5, wherein when the driving mode is event-driven, the processor is further configured to: after clearing the stored application data, regard the driving mode of the application data as the instant driving mode.
7. The task management system as described in claim 5, wherein the analysis result further includes data features of the application data, wherein when the driving method is event-driven, the processor is further configured to: group the event data according to the data features to generate multiple event data groups; determine, according to the knowledge graph, whether all data features of each event data group satisfy the at least one possible task to generate a matching result; and drive the at least one possible task according to the matching result.
8. The task management system as described in claim 1, wherein the processor is further configured to: set the driving mode of the task and the data information of interest; set the business type; set the event information of the event; set the correspondence between the event and the data information; and generate the knowledge graph based on the set driving mode, the data information, the business type, the event information and the correspondence.
9. A method for operating a task management system, comprising: The knowledge graph is stored through a storage device, wherein the knowledge graph includes type data, data features, events, and relationships between tasks; The processor analyzes application data from the application system to generate analysis results, wherein the analysis results include the business type of the application data; the processor obtains at least one possible task related to the application data based on the analysis results and the knowledge graph; and the processor executes the at least one possible task based on the application data, wherein the analysis results also include the driving method of the application data, the data characteristics of the application data, and the change type, wherein the operation method further includes: determining, through the processor, whether the driving method is real-time driven or event-driven; When the driving method is real-time driving, the processor determines, based on the knowledge graph, whether the at least one possible task pays attention to all the data features and the change types to generate a matching result; and when the driving method is real-time driving, the processor obtains the latest data features based on the matching result and the business type.
10. The operating method as described in claim 9, further comprising: The processor accesses the application data in the application system when the application system changes. The processor outputs the execution results of the at least one possible task to the application system to update the application data in the application system; and the processor accesses the changed data in the updated application system as the application data when the updated application system changes.
11. The operating method as described in claim 9, further comprising: When the driving method is real-time driving, the processor determines whether the at least one possible task matches the latest data features based on the knowledge graph, so as to drive the at least one possible task.
12. The operation method as described in claim 9, wherein the at least one possible task comprises a plurality of possible tasks, and wherein the operation method further comprises: When the driving method is real-time driving, the processor obtains the coexistence relationship between the data features and the multiple possible tasks based on the business type and the knowledge graph; and when the driving method is real-time driving, the processor determines, sequentially or simultaneously, based on the coexistence relationship and the knowledge graph whether the multiple possible tasks pay attention to all the data features and the change type to generate matching results, and drives the multiple possible tasks based on the matching results.
13. The operating method as described in claim 9 further includes: When the driving method is event-driven, the application data is stored to the storage device through the processor; When the driving mode is event-driven, the processor executes a driving mode converter based on the stored application data to generate a conversion result, wherein the driving mode converter includes the relationship between the event and the real-time data; when the driving mode is event-driven, the processor clears the stored application data based on the conversion result, or collects the application data in the application system within a period to generate event data.
14. The operating method as described in claim 13 further includes: When the driving mode is event-driven, the processor, after clearing the stored application data, treats the driving mode of the application data as real-time driven.
15. The method of operation as described in claim 13, wherein the analysis result further includes data characteristics of the application data, and wherein the method of operation further includes: When the driving method is event-driven, the processor groups the event data according to the data characteristics to generate multiple event data groups; When the driving mode is event-driven, the processor determines, based on the knowledge graph, whether all data features of each event data group satisfy the at least one possible task to generate a matching result; and when the driving mode is event-driven, the processor drives the at least one possible task based on the matching result.
16. The operating method as described in claim 9 further includes: The processor is used to set the driving method of the task and the data information of interest. The service type is set through the processor; The event information of the event is set through the processor; The processor establishes the correspondence between the events and the data information. And through the processor, the knowledge graph is generated based on the set driving mode, the data information, the service type, the event information, and the correspondence.
