A task scheduling device and method of an RPA robot

Abstract

The application relates to a task scheduling device and method of an RPA robot, and belongs to the technical field of automation, and solves the problems of large resource consumption and insufficient intelligent scheduling and distribution of task execution. The device comprises an MQTT server, an RPA robot and a server. The MQTT server is used for establishing an MQTT message queue to receive and send various messages transmitted between the RPA robot and the server. The RPA robot is used for sending heartbeat messages at regular time intervals. The RPA robot is used for obtaining corresponding to-be-executed tasks from the MQTT message queue. The server is used for updating the load of the corresponding RPA robot in a server load table according to the heartbeat messages. The server is used for obtaining N to-be-executed tasks by regularly scanning a task list, and updating the information of RPA load entities in a knowledge graph according to the server load table. According to the parameter information of the N to-be-executed tasks, entities in the knowledge graph are matched, and the optimal RPA robot is taken out, and the optimal RPA robot is added in the corresponding to-be-executed task and sent to the MQTT message queue in the form of an optimal RPA robot identifier. Reasonable and accurate task scheduling is realized.

Description

Technical Field

[0001] This invention relates to the field of automation technology, and in particular to a task scheduling device and method for an RPA robot. Background Technology

[0002] In the process of RPA robot management and application, the gradual migration to the cloud has become an inevitable trend. As the number of clients increases and the tasks become more intensive, how to reasonably schedule and run RPA robots in the cloud and balance the load on RPA clients is a key issue that needs to be addressed.

[0003] Traditional RPA clients and servers use WebSockets, maintaining a persistent connection with the server platform after the client device starts. The relationship between the management platform and the client is simple: issuing and executing commands, using state control to manage the task allocation of the RPA robot.

[0004] Traditional communication methods are resource-intensive, consuming numerous threads and significantly impacting client and server resources during most standby phases. State control methods only address the mechanical processing of RPA client devices during task allocation by the management platform. They lack a long-term, lightweight, and configurable technical support for the allocation methods between changing RPA robots and running client devices; furthermore, they fail to provide sufficient information about the client's status, lacking the necessary mechanisms for the client to report its own status back to the management platform. Summary of the Invention

[0005] Based on the above analysis, the embodiments of the present invention aim to provide a task scheduling device and method for RPA robots to solve the problems of high resource consumption and insufficient intelligence in the scheduling and allocation of task execution in existing systems.

[0006] On one hand, embodiments of the present invention provide a task scheduling device for an RPA robot, including: an MQTT server, used to establish an MQTT message queue to receive and send various messages transmitted between the RPA robot and the server;

[0007] RPA robots are used to send registration messages to establish connections with the server and send heartbeat messages periodically; based on the RPA robot identifier, the corresponding tasks to be executed are retrieved from the MQTT message queue.

[0008] The server-side component establishes connections with each RPA robot. Based on the heartbeat messages collected from the MQTT message queue, it updates the corresponding RPA robot load in the server-side load table. It periodically scans the task list to obtain N tasks to be executed and updates the RPA load entity information in the knowledge graph based on the server-side load table. Based on the parameter information of the N tasks to be executed, it matches entities in the knowledge graph, extracts the optimal RPA robot for each task, adds the optimal RPA robot identifier to the corresponding task, and sends it to the MQTT message queue, where N≥1.

[0009] Based on further improvements to the above-mentioned device, the RPA robot sends a registration message to establish a connection with the server, including:

[0010] The RPA robot collects basic information about the container it is in, encrypts it with a key, and sends it as a registration message to the MQTT message queue.

[0011] The server obtains and decrypts the basic information of the container where each RPA robot is located by subscribing to topics in MQTT; it identifies whether the corresponding RPA robot already exists in the client image. If it does not exist, it creates a virtualized shadow of the RPA robot and sets the online status of the virtualized shadow to offline; and it sends a feedback message to the MQTT message queue.

[0012] After the RPA robot receives the corresponding feedback message from the MQTT message queue, it starts the connection process.

[0013] Based on further improvements to the above device, the RPA robot periodically obtains load information and updates it to the client's load table according to the system commands of the container it is in;

[0014] The RPA robot periodically sends heartbeat messages, including:

[0015] The message encapsulates the heartbeat message, in which the basic information of the container where the RPA robot is located is used as the message's head information, and the load information obtained from the client's load table is used as the message's body information;

[0016] Send a heartbeat message to the MQTT message queue.

[0017] Based on further improvements to the above device, the server also includes: periodically collecting heartbeat messages in the MQTT message queue and updating the online status of the virtualized shadow of the RPA robot, including: counting the number of times each RPA robot has not received a heartbeat message consecutively based on the RPA robot identifier in the collected heartbeat message; updating the online status of the virtualized shadow of the RPA robot whose number of consecutive heartbeat messages has exceeded a threshold to offline, otherwise updating it to online.

[0018] Based on further improvements to the aforementioned device, the entities in the knowledge graph include: RPA robot scene entities, organizational structure entities, RPA robot operating environment entities, and RPA payload entities; among which...

[0019] The RPA robot scene entities include: RPA robot identifier, robot name, scene identifier, and scene version;

[0020] Organizational entities include: organizational identity and organizational hierarchy;

[0021] The RPA robot operating environment includes: RPA robot identifier, operating system, and business system;

[0022] The RPA load entity includes: RPA robot identifier, load identifier, load name, load type, and load value.

[0023] Based on further improvements to the aforementioned device, according to the parameter information of N tasks to be executed, entities in the knowledge graph are matched, and the optimal RPA robot is extracted for each, including:

[0024] Based on the organization identifier in the N parameter information, obtain the corresponding organizational level from the organizational entity in the knowledge graph, and sort the N tasks to be executed according to the organizational level;

[0025] Based on the sorted order of N tasks to be executed, and according to the scenario identifier in the parameter information of each task to be executed, a first robot list is obtained from the RPA robot scenario entity in the knowledge graph; then, based on the operating system and business system in the parameter information, a second robot list containing both the operating system and business system is obtained from the first robot list; based on the RPA load entity, the RPA robot with the smallest load value that does not exceed the threshold is selected from the second robot list as the optimal RPA robot.

[0026] Based on further improvements to the above-mentioned device, the RPA robot retrieves the corresponding task to be executed from the MQTT message queue according to the RPA robot identifier and performs the following:

[0027] Verify whether the scenario version in the parameter information of the task to be executed is consistent with the scenario version in the RPA robot. If they are inconsistent, install or update the scenario code corresponding to the scenario version in the task to be executed, and then send the message of received task to the MQTT message queue. If they are consistent, execute the tasks to be executed in sequence and send the message of received task to the MQTT message queue.

[0028] Once the task is completed, a message indicating task completion is sent to the MQTT message queue, load information is retrieved, and the load table on the client is updated.

[0029] Based on further improvements to the above device, after the server receives a message from the MQTT message queue indicating that a task has been received, it updates the running status of the virtualized shadow of the corresponding RPA robot to "running"; after the server receives a message from the MQTT message queue indicating that a task has been completed, it updates the running status of the virtualized shadow of the corresponding RPA robot to "idle".

[0030] Based on further improvements to the above-mentioned device, the MQTT server uses QoS to configure hierarchical responses to various messages, including:

[0031] Define heartbeat messages as level 0; define messages of received tasks as level 1; define registration messages as level 2.

[0032] On the other hand, embodiments of the present invention provide a task scheduling method for an RPA robot, comprising the following steps:

[0033] Each RPA robot establishes a connection with the server via the MQTT protocol;

[0034] Periodically collect heartbeat information sent by the RPA robot to the MQTT message queue, and update the corresponding RPA robot load in the server-side load table;

[0035] N tasks to be executed are obtained by periodically scanning the task list. The entity information of RPA load in the knowledge graph is updated according to the server load table. According to the parameter information of the N tasks to be executed, the entities in the knowledge graph are matched, the optimal RPA robot is extracted, the optimal RPA robot identifier is added to the corresponding task to be executed, and sent to the MQTT message queue, where N≥1.

[0036] The RPA robot retrieves the corresponding task to be executed from the MQTT message queue based on the RPA robot identifier.

[0037] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects:

[0038] 1. Establish a connection and authentication between the RPA robot and the server via MQTT. Asynchronous message passing between the RPA robot and the server is achieved through the MQTT message processing mechanism. This enables better, more secure, and stable remote communication between the server and the RPA robot, especially in low-bandwidth or unreliable network environments.

[0039] 2. By defining the collection time, heartbeat reporting time, and reporting timing, abnormal loads of RPA robots are identified and the load is dynamically updated, forming a complete reporting and monitoring mechanism. This enables more scientific and reasonable use of artificial intelligence technology to solve RPA robot task allocation.

[0040] 3. By combining RPA robot load with task allocation mechanism rules through knowledge graph technology, knowledge entities and paths for intelligent task allocation and processing are created. The most appropriate RPA robot is matched in a timely manner based on the latest RPA robot load, so as to enable RPA task allocation through knowledge graph services.

[0041] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0042] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts.

[0043] Figure 1 This is a schematic diagram of the task scheduling device for an RPA robot in Embodiment 1 of the present invention. Detailed Implementation

[0044] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0045] Example 1

[0046] A specific embodiment of the present invention discloses a task scheduling device for an RPA robot, such as... Figure 1 As shown, it includes:

[0047] An MQTT server is used to establish MQTT message queues to receive and send various messages transmitted between the RPA robot and the server.

[0048] RPA robots are used to send registration messages to establish connections with the server and send heartbeat messages periodically; based on the RPA robot identifier, the corresponding tasks to be executed are retrieved from the MQTT message queue.

[0049] The server-side component establishes connections with each RPA robot. Based on the heartbeat messages collected from the MQTT message queue, it updates the corresponding RPA robot load in the server-side load table. It periodically scans the task list to obtain N tasks to be executed and updates the RPA load entity information in the knowledge graph based on the server-side load table. Based on the parameter information of the N tasks to be executed, it matches entities in the knowledge graph, extracts the optimal RPA robot for each task, adds the optimal RPA robot identifier to the corresponding task, and sends it to the MQTT message queue, where N≥1.

[0050] It's important to note that MQTT (Message Queuing Telemetry Transport) is a publish / subscribe messaging protocol based on the ISO standard (ISO / IEC PRF20922). It operates on the TCP / IP protocol suite and is designed for remote devices with limited hardware performance and poor network conditions. In this embodiment, the RPA robot is software, defined as a remote device on the server. MQTT is used to establish a connection and authentication between the RPA robot and the server. The MQTT message processing mechanism enables asynchronous message passing between the RPA robot and the server. Furthermore, when the RPA robot and server send and receive messages, by subscribing to topics on the MQTT server, there's no need for extensive message type definitions; only a single, comprehensive message content definition is required to handle messages with different content. Compared to other methods, this is more versatile and flexible. If message processing rules change later, only the topic needs to be adjusted for quick adaptation.

[0051] Specifically, RPA robots establish a connection with the server by sending a registration message, including:

[0052] ① The RPA robot collects basic information about the container it is in, encrypts it with a key, and sends it as a registration message to the MQTT message queue;

[0053] It should be noted that the basic information of the container to be obtained includes: IP address, MAC address, computer name, and port information.

[0054] ② The server obtains and decrypts the basic information of the container where each RPA robot is located by subscribing to topics in MQTT; it identifies whether the corresponding RPA robot already exists in the client image. If it does not exist, it creates a virtualized shadow of each RPA robot and sets the online status of the virtualized shadow to offline; it then sends a feedback message to the MQTT message queue.

[0055] It should be noted that in this embodiment, each RPA robot is an RPA client. Considering that the communication between the RPA robot and the server is asynchronous, in order for the server to obtain the online and running status of each RPA robot in a timely manner, a corresponding virtualized shadow is created on the server after the RPA robot is successfully registered and placed in the client image.

[0056] For example, a topic defined in MQTT might be: `select Robotid, ip, mac, robotname from Robotmassage`, which indicates that the RPA robot identifier, IP address, MAC address, and robot name are retrieved from a message sent by the RPA robot. Based on the RPA robot identifier, the server checks if the corresponding RPA robot already exists in the client image. If not, the server saves the retrieved basic information to a table and uses it as initialization information to create a virtualized shadow of the corresponding RPA robot, setting the virtualized shadow's online status to offline. Simultaneously, a feedback message is generated to indicate successful registration and sent to the MQTT message queue.

[0057] ③ After the RPA robot obtains the corresponding feedback message from the MQTT message queue, it starts the connection program.

[0058] Once the RPA robot successfully connects, it can begin sending messages to the MQTT message queue, including periodic heartbeat messages, messages indicating received tasks, and completion messages indicating completed tasks. The server dynamically controls the online and running status of the virtualized shadow of the RPA robot on the server by receiving different messages from the RPA robot in the MQTT message queue.

[0059] It should be noted that the RPA robot will also periodically obtain load information based on the system commands of the container it resides in and update the load table on the client. When sending heartbeat messages periodically, the load information is uploaded so that the server can obtain the status of each RPA robot in a timely manner and improve the rationality of task scheduling.

[0060] Preferably, load information is queried every 5 minutes and updated in the client load table. For example, in a Linux system, memory usage is obtained using the `free` command, the system average load is obtained using the `uptime` command, and the system CPU usage is obtained using the `vmstat` command.

[0061] The RPA robot's asynchronous interaction with the server when sending heartbeat messages, and its control over the online status of the virtualized shadow, include:

[0062] The RPA robot periodically encapsulates heartbeat messages, using the basic information of the container where the RPA robot resides as the message's header information and the load information obtained from the client's load table as the message's body information; then, the heartbeat message is sent to the MQTT message queue.

[0063] The server periodically collects heartbeat messages from the MQTT message queue and updates the online status of the virtualized shadows of RPA robots. This includes: counting the number of times each RPA robot has not received a heartbeat message based on the RPA robot identifier in the collected heartbeat messages; updating the online status of the virtualized shadow of an RPA robot whose number of heartbeat messages exceeds a threshold to offline and sending a fault message reminder to the administrator; otherwise, updating it to online and updating the corresponding RPA robot load in the server's load table.

[0064] For example, the RPA robot sends a heartbeat message every 30 seconds, and the server collects the heartbeat messages every 10 minutes. Under normal circumstances, multiple heartbeat messages from each RPA robot will be collected. The server then selects the heartbeat message corresponding to the latest time of each RPA robot and updates its load information in the server's load table. If the server does not receive a heartbeat message from a certain RPA robot for 5 consecutive times, it indicates that the RPA robot is very likely offline. The server then updates the online status of its virtualized shadow to offline and sends a fault message alert to the administrator.

[0065] It should be noted that the server-side control over the running status of the virtualized shadow includes:

[0066] When the RPA robot retrieves the corresponding task to be executed from the MQTT message queue, it sends a message indicating that the task has been received to the MQTT message queue. Upon receiving the message, the server updates the running status of the corresponding virtualized shadow to "running".

[0067] After completing its task, the RPA robot sends a task completion message to the MQTT message queue. Upon receiving the message, the server updates the running status of the corresponding virtualized shadow to idle.

[0068] To ensure the stability of messages between the RPA robot and the server, the MQTT server uses QoS to configure tiered responses to various messages, including:

[0069] Heartbeat messages are defined as level 0. These messages are only used to check whether the RPA robot is online. The server has low requirements for the data quality of these messages. If the RPA robot fails to send a heartbeat message, it does not need to be resent. Therefore, with this level of message definition, the server can greatly reduce the load pressure of processing messages.

[0070] Messages indicating received tasks are defined as Level 1. When a task is assigned to an RPA robot, the RPA robot needs to send the received message to the server. If it doesn't, the MQTT service will continuously publish the task message to the RPA robot until it receives at least one response. This approach significantly reduces the risk of task loss during distribution.

[0071] The registration message is defined as level 2. When the RPA robot registers for the first time, the registration information reported to the server is defined as level 2 message. This ensures that the registration message of the RPA robot and the feedback of the server to complete the registration are processed only once, thereby preventing the RPA robot from registering repeatedly.

[0072] Therefore, by layering messages according to their importance, the mechanism ensures that all messages are correctly received and processed by the RPA robot and the server, while minimizing the load on both services. Different processing mechanisms are employed for different messages. When a large number of RPA robots are used in real-world scenarios, MQTT message queue telemetry transmission is more flexible, reasonable, secure, and stable than other message methods.

[0073] For the scheduling and allocation of tasks to be executed, considering the randomness of the creation and number of tasks, the server periodically scans the task list to check if there are any tasks to be executed. If so, the task is retrieved. For example, scanning every 30 seconds may retrieve one or more tasks to be executed.

[0074] The parameter information for the task to be executed includes: task subject information, task scenario information, and task scenario dependency information. Among them, the task subject information includes: the user who created the task, the role that created the task, the creation time, and the organization identifier to which the task belongs; the task scenario information includes: the scenario code, the scenario version, the scenario name, and the scenario authorization information; and the task scenario dependency information includes: the operating system (i.e., the operating system information on which the scenario depends) and the business system (i.e., one or more business systems required for the scenario to run).

[0075] This embodiment constructs an RPA robot task scheduling knowledge graph. Before allocating an RPA robot to each task to be executed, the information of the RPA load entity in the knowledge graph is dynamically updated according to the real-time updated server load table. Then, each task to be executed is filtered through four dimensions: running priority, scenario legality, matching degree of scenario dependency environment, and rationality of RPA load, to select the optimal RPA robot, thereby enabling the knowledge graph service to empower the allocation of RPA running tasks.

[0076] It is worth noting that the server periodically collects heartbeat messages and updates the load of each RPA robot in the server load table. When a task to be executed is obtained periodically, the knowledge graph update service is triggered. The server retrieves the latest load of each RPA robot from the server load table, thereby updating the information of the RPA load entity in the knowledge graph. This ensures that the most accurate information of each RPA robot can be obtained before each task is assigned, so that the task can be reasonably and accurately assigned to the optimal RPA robot.

[0077] Specifically, knowledge graph-based task allocation involves creating the rules for allocating tasks to RPA robots in the form of entities. The entities in the RPA robot task scheduling knowledge graph correspond to the parameter information of the tasks to be executed, and establish relationships between them through attributes with the same meaning, thereby constructing a knowledge path.

[0078] The entities in the knowledge graph include: RPA robot scenario entities, organizational entity entities, RPA robot operating environment entities, and RPA payload entities; among them,

[0079] The RPA robot scene entities include: RPA robot identifier, robot name, scene identifier, and scene version;

[0080] Organizational entities include: organizational identity and organizational hierarchy;

[0081] The RPA robot operating environment includes: RPA robot identifier, operating system, and business system;

[0082] The RPA load entity includes: RPA robot identifier, load identifier, load name, load type, and load value.

[0083] Preferably, multiple PRA load entities can be created for the load information of interest, such as three entities: CPU utilization, memory utilization, and CPU heat rate, each of which has the above four attributes.

[0084] After obtaining N tasks to be executed, based on the parameter information of the N tasks, the entities in the knowledge graph are matched, and the optimal RPA robot is extracted for each task, including:

[0085] ① Based on the organization identifier in the N parameter information, obtain the corresponding organizational level from the organizational entity in the knowledge graph, and sort the N tasks to be executed according to the organizational level;

[0086] It's important to note that the main information of the tasks to be executed includes the organization identifier of the user who created them. These organizations have hierarchical relationships, such as groups, first-level units, and second-level units. The organizational entity in the knowledge graph manages both the organization identifier and the organizational hierarchy. Therefore, when there are multiple tasks to be executed, they are compared and prioritized based on their organizational hierarchy, with the task from the highest-level organization being processed first.

[0087] Preferably, when N=1, there is no need to sort, and the matching in steps ②③④ can be performed directly.

[0088] ② According to the sorted order of N tasks to be executed, and based on the scene identifier in the parameter information of each task to be executed, obtain the first robot list from the RPA robot scene entity in the knowledge graph;

[0089] It should be noted that RPA robots are based on scenarios. They retrieve robots whose scenario identifiers in the task to be executed match the scenario identifiers in the RPA robot scenario entities in the knowledge graph, forming a first robot list, and filtering out robots that have not loaded the scenario required by the task.

[0090] ③ Based on the operating system and business system in the parameter information, obtain the second robot list that contains both the operating system and business system from the first robot list;

[0091] It should be noted that when a scenario is released, the operating system and business system required for each scenario are already defined. Robots that cannot simultaneously meet the operating system and business system requirements of each running scenario are filtered out, thus obtaining a second list of robots.

[0092] For example, the task to be performed is to audit vouchers, and the business system it depends on is a financial management system, with Windows as the operating system.

[0093] ④ Based on the RPA load entity, select the RPA robot with the smallest load value that does not exceed the threshold from the second robot list as the optimal RPA robot.

[0094] It should be noted that if there are no RPA robots whose load values ​​do not exceed the threshold, you can wait a few minutes and update the information of the RPA load entities in the knowledge graph according to the server-side load table before filtering.

[0095] Preferably, if there are multiple load entities in the knowledge graph, robots that have not exceeded their respective load thresholds are selected from the second robot list, and the robot with the lowest load value is chosen as the optimal RPA robot according to the actual settings. If the virtualized shadow of the optimal RPA robot is offline, a task execution reminder is sent to the administrator.

[0096] If too many tasks are retrieved at once, to avoid assigning multiple tasks to the same RPA robot, a judgment on the number of tasks to be executed is added in step ① above. When N > the threshold number, such as 10, after sorting the N tasks to be executed according to the organizational hierarchy, the sorted tasks to be executed are grouped according to the threshold number. For each group of tasks to be executed, the matching in steps ②, ③, and ④ above is performed in sequence, and the tasks to be executed are promptly issued. The knowledge graph update service is triggered to obtain the latest load of each RPA robot from the server load table, ensuring that the load status of each RPA robot can be obtained in time before the next group of tasks is assigned, and the optimal RPA robot is selected.

[0097] Add the optimal RPA robot identifier to the corresponding task to be executed and send it to the MQTT message queue. The RPA robot will then retrieve the corresponding task from the MQTT message queue based on the RPA robot identifier and execute it.

[0098] Specifically, the RPA robot checks whether the scenario version in the parameter information of the task to be executed is consistent with the scenario version in the RPA robot. If they are inconsistent, the robot installs or updates the scenario code corresponding to the scenario version in the task to be executed, executes the task to be executed, and sends the message of the received task to the MQTT message queue. If they are consistent, the robot executes the tasks to be executed in sequence and sends the message of the received task to the MQTT message queue.

[0099] It should be noted that installing or updating the scene code corresponding to the scene version in the task to be executed, and then executing the task to be executed, includes: putting the task to be executed into the cache, calling the server's interface, obtaining the scene code corresponding to the scene version in the parameter information of the task to be executed, installing or updating the scene code, and then executing the task to be executed in the cache.

[0100] If the RPA robot obtains multiple tasks to be executed at the same time, they can be put into the cache first, and then retrieved and executed one by one.

[0101] Once the task is completed, a message indicating task completion is sent to the MQTT message queue, load information is retrieved, and the load table on the client is updated.

[0102] Preferably, after the RPA robot completes its task, it automatically clears its own cache to release CPU load to the maximum extent. The cleared cache data includes listening programs started by the running process; then it obtains the load information and updates it to the client load table.

[0103] Compared with existing technologies, the RPA robot task scheduling device disclosed in this embodiment establishes a connection and authentication between the RPA robot and the server via MQTT, and realizes asynchronous message transmission between the RPA robot and the server through the MQTT message processing mechanism. This enables better, more secure, and stable remote communication between the server and the RPA robot under low bandwidth and unreliable network conditions. By defining collection time, heartbeat reporting time, and reporting timing, it identifies abnormal loads of the RPA robot and dynamically updates the load, forming a complete reporting and monitoring mechanism. This allows for a more scientific and reasonable use of artificial intelligence technology to solve RPA robot task allocation. Furthermore, by combining RPA robot load with task allocation mechanism rules through knowledge graph technology, it creates knowledge entities and paths for intelligent task allocation and processing. Based on the latest RPA robot load status, it matches the most suitable RPA robot in a timely manner, enabling knowledge graph services to empower RPA task allocation.

[0104] Example 2

[0105] Another embodiment of the present invention, using the apparatus of Embodiment 1, discloses a task scheduling method for an RPA robot. The components involved in the method steps are described in the corresponding description in Embodiment 1. The method includes the following steps:

[0106] Each RPA robot establishes a connection with the server via the MQTT protocol;

[0107] Periodically collect heartbeat information sent by the RPA robot to the MQTT message queue, and update the corresponding RPA robot load in the server-side load table;

[0108] N tasks to be executed are obtained by periodically scanning the task list. The entity information of RPA load in the knowledge graph is updated according to the server load table. According to the parameter information of the N tasks to be executed, the entities in the knowledge graph are matched, the optimal RPA robot is extracted, the optimal RPA robot identifier is added to the corresponding task to be executed, and sent to the MQTT message queue, where N≥1.

[0109] The RPA robot retrieves the corresponding task to be executed from the MQTT message queue based on the RPA robot identifier.

[0110] Since the task scheduling method of the RPA robot in this embodiment can be referenced from the aforementioned device in some aspects, it is a repetition of the description here and will not be repeated. Because this method embodiment is based on the same principle as the aforementioned device embodiment, it also has the corresponding technical effects of the aforementioned device embodiment.

[0111] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0112] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A task scheduling device for an RPA robot, characterized in that, include: An MQTT server is used to establish MQTT message queues to receive and send various messages transmitted between the RPA robot and the server. RPA robots are used to send registration messages to establish connections with the server and send heartbeat messages periodically; based on the RPA robot identifier, the corresponding tasks to be executed are retrieved from the MQTT message queue. The server-side component establishes connections with each RPA robot and updates the corresponding RPA robot load in the server-side load table based on heartbeat messages collected from the MQTT message queue. It also periodically scans the task list to obtain N tasks to be executed and updates the information of the RPA load entity in the knowledge graph based on the server-side load table. The entities in the knowledge graph include: RPA robot scenario entities, organizational structure entities, RPA robot runtime environment entities, and RPA load entities. Specifically, the RPA robot scenario entity includes: RPA robot identifier, robot name, scenario identifier, and scenario version; the organizational structure entity includes: organizational identifier and organizational level; the RPA robot runtime environment entity includes: RPA robot identifier, operating system, and business system; and the RPA load entity includes: RPA robot identifier, load identifier, load name, load type, and load value. Based on the N tasks to be executed... The parameter information is matched with entities in the knowledge graph, and the optimal RPA robot is extracted. This includes: obtaining the corresponding organizational level from the organizational entity in the knowledge graph based on the organization identifier in the N parameter information, and sorting the N tasks to be executed according to the organizational level; obtaining a first robot list from the RPA robot scenario entity in the knowledge graph according to the scenario identifier in the parameter information of each task to be executed, in the sorted order of the N tasks to be executed; obtaining a second robot list from the first robot list that simultaneously contains the operating system and business system based on the operating system and business system in the parameter information; selecting the RPA robot with the smallest load value that does not exceed the threshold from the second robot list as the optimal RPA robot based on the RPA load entity; adding the optimal RPA robot identifier to the corresponding task to be executed and sending it to the MQTT message queue, where N≥1.

2. The task scheduling device for RPA robots according to claim 1, characterized in that, The RPA robot sends a registration message to establish a connection with the server, including: The RPA robot collects basic information about its container, encrypts it with a key, and sends it as a registration message to the MQTT message queue. The basic information includes: IP address, MAC address, computer name, and port information. The server obtains and decrypts the basic information of the container where each RPA robot is located by subscribing to topics in MQTT; it identifies whether the corresponding RPA robot already exists in the client image. If it does not exist, it creates a virtualized shadow of the RPA robot and sets the online status of the virtualized shadow to offline; and it sends a feedback message to the MQTT message queue. After the RPA robot receives the corresponding feedback message from the MQTT message queue, it starts the connection process.

3. The task scheduling device for RPA robots according to claim 2, characterized in that, The RPA robot periodically obtains load information and updates it to the client's load table according to the system commands of the container it is in. The RPA robot periodically sends heartbeat messages, including: The message encapsulates the heartbeat message, wherein the basic information of the container where the RPA robot is located is used as the message's head information, and the load information obtained from the client's load table is used as the message's body information; The heartbeat message is sent to the MQTT message queue.

4. The task scheduling device for RPA robots according to claim 3, characterized in that, The server also includes: periodically collecting heartbeat messages from the MQTT message queue and updating the online status of the virtualized shadows of RPA robots, including: based on the RPA robot identifier in the collected heartbeat messages, counting the number of times each RPA robot has not received a heartbeat message consecutively, and updating the online status of the virtualized shadows of RPA robots whose number of heartbeat messages exceeds a threshold to offline, otherwise updating them to online.

5. The task scheduling device for RPA robots according to claim 3, characterized in that, The RPA robot retrieves the corresponding task to be executed from the MQTT message queue based on the RPA robot identifier and performs the following: Verify whether the scenario version in the parameter information of the task to be executed is consistent with the scenario version in the RPA robot. If they are inconsistent, install or update the scenario code corresponding to the scenario version in the task to be executed, and then send the message of received task to the MQTT message queue. If they are consistent, execute the tasks to be executed in sequence and send the message of received task to the MQTT message queue. Once the task is completed, a message indicating task completion is sent to the MQTT message queue, load information is retrieved, and the load table on the client is updated.

6. The task scheduling device for RPA robots according to claim 5, characterized in that, After receiving a message from the MQTT message queue indicating that a task has been received, the server updates the running status of the corresponding virtualized shadow of the RPA robot to "running"; after receiving a message from the MQTT message queue indicating that a task has been completed, the server updates the running status of the corresponding virtualized shadow of the RPA robot to "idle".

7. The task scheduling device for RPA robots according to claim 6, characterized in that, The MQTT server uses QoS to hierarchically configure responses to various messages, including: Define heartbeat messages as level 0; define messages of received tasks as level 1; define registration messages as level 2.

8. A task scheduling method for an RPA robot, executed by the task scheduling device for the RPA robot as described in claim 1, characterized in that, The steps include the following: Each RPA robot establishes a connection with the server via the MQTT protocol; Periodically collect heartbeat information sent by the RPA robot to the MQTT message queue, and update the corresponding RPA robot load in the server-side load table; N tasks to be executed are obtained by periodically scanning the task list, and the entity information of RPA load in the knowledge graph is updated according to the server load table. According to the parameter information of the N tasks to be executed, the entities in the knowledge graph are matched, the optimal RPA robot is extracted, the optimal RPA robot identifier is added to the corresponding task to be executed, and sent to the MQTT message queue, where N≥1. The RPA robot retrieves the corresponding task to be executed from the MQTT message queue based on the RPA robot identifier.

Images