Robot management method and related product

Abstract

The invention discloses a robot management method and related products, and the method comprises the steps: obtaining robot basic information and a communication text through a basic script development framework file when a robot is created and mounted; and creating and mounting the robot at least according to the basic script development framework which obtains the basic information and the communication text of the robot. According to the scheme, a basic script development framework file is provided for a developer, the framework file only limits robot basic information and communication texts which must be filled in by the developer, a robot execution function is not limited, data input and output forms are not limited, and the development efficiency is improved. Therefore, the requirement of a large number of non-standard scenes of the B-end enterprise robot is met.

Description

Technical Field

[0001] The present invention generally relates to the field of robot management technology. More specifically, the present invention relates to a robot management method and related products. Background Art

[0002] In the current technology environment, low-code platforms are becoming an important tool for achieving automation and robotic process automation (RPA). These platforms allow users to easily create and deploy software robots through visual interfaces and drag-and-drop functions without in-depth programming knowledge. However, although this approach simplifies the robot creation process, it also brings many limitations, especially in the B-side enterprise environment, which limits the processing of standard and non-standard input and output of manufacturers, as follows:

[0003] Low-code platforms usually require that the input and output of robots meet specific manufacturer standards, which is critical to ensuring data consistency and compatibility. However, B-side enterprises often face a large number of non-standard input and output situations in actual operations, which requires enterprises to invest additional resources to handle these non-standard input and output contents when using low-code platforms. To make matters more complicated, when encountering special non-standard inputs that cannot be processed, it may lead to the inability to create a specific robot, thereby limiting the applicability of low-code solutions.

[0004] In short, the creation of robots and their automatic mounting after creation are implemented based on the low-code platform. The input and output of each robot must meet the manufacturer's standards. However, for B-side enterprises, the large number of non-standard inputs and outputs in the robot implementation process means that the use of this method will bring a large amount of additional input and output content processing, and when extremely special non-standard inputs cannot be processed, the robot creation will be impossible. Summary of the invention

[0005] In order to at least solve one or more of the technical problems mentioned above, the present invention proposes a robot management method and related products in multiple aspects.

[0006] In a first aspect, the present invention provides a method for robot management, comprising: when creating and mounting a robot, obtaining basic information and communication text of the robot through a basic script development framework file, so as to create and mount the robot at least based on the basic script development framework that has obtained the basic information and communication text of the robot.

[0007] In one embodiment, the basic script development framework file includes a concurrent asynchronous framework file.

[0008] In one embodiment, the method further includes: during the robot execution process, in response to a new task being created but no waiting queue for resource allocation exists, determining the order of resource allocation for the tasks according to the order in which the tasks are created.

[0009] In one embodiment, the method further includes: during the robot execution process, in response to the existence of a waiting queue waiting for allocation of resources, for each task in the waiting queue, determining its execution order according to its execution priority, wherein the execution priority of the task is determined according to the weight of the task.

[0010] In one embodiment, the execution priority of each task is determined by the following method: when a newly created task begins to enter the waiting queue, its initial weight is determined; and the execution priority of each task in the waiting queue is determined based on the initial weight and the current weights of other tasks in the waiting queue.

[0011] In one embodiment, determining the initial weight includes: determining the initial weight according to one or more of the urgency of the task, the estimated execution time, and the task type.

[0012] In one embodiment, the method further includes: determining the current weight of the task waiting in the waiting queue according to its waiting execution time; and dynamically adjusting the execution priority of each task in the waiting queue according to the current weight of each task.

[0013] In one embodiment, the method further includes: during the robot execution process, using a dynamic file loading strategy to obtain the file.

[0014] In one embodiment, the method further includes: the robot's tasks are performed in the cloud.

[0015] In a second aspect, the present invention further provides a device, comprising: a processor; a memory storing program instructions executable by the processor, wherein when the program instructions are executed by the processor, the device executes the method according to any embodiment of the first aspect.

[0016] In a third aspect, the present invention further provides a computer-readable medium storing robot management instructions, which, when executed by at least one processor, causes the method according to any embodiment of the first aspect to be executed.

[0017] In general, compared with the prior art, the above technical solution conceived by the present invention can achieve the following beneficial effects: This solution provides developers with a basic script development framework file, which only limits the basic robot information and communication text that developers must fill in, and does not limit the robot execution function, and does not limit the form of data input and output, thereby solving the needs of a large number of non-standard scenarios for B-end enterprise robots. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] By reading the following detailed description with reference to the accompanying drawings, the above and other objects, features and advantages of the exemplary embodiments of the present invention will become readily understood. In the accompanying drawings, several embodiments of the present invention are shown in an exemplary and non-limiting manner, and the same or corresponding reference numerals represent the same or corresponding parts, wherein:

[0019] Figure 1 An exemplary flow chart of the robotic process automation method of the present invention is shown;

[0020] Figure 2 An example diagram of element distribution of the automatic construction framework of the front-end page of the present invention is shown;

[0021] Figure 3 An exemplary flow chart showing a method for robot management according to an embodiment of the present invention is shown;

[0022] Figure 4 An exemplary flow chart showing a method for robot management according to another embodiment of the present invention;

[0023] Figure 5 An exemplary flow chart showing a method for robot management according to another embodiment of the present invention;

[0024] Figure 6 is a structural block diagram of a device according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0025] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present invention.

[0026] It should be understood that the terms "include" and "comprising" used in the description and claims of the present invention indicate the presence of described features, integers, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or combinations thereof.

[0027] It should also be understood that the terms used in this specification of the present invention are only for the purpose of describing specific embodiments and are not intended to limit the present invention. As used in the specification of the present invention and the claims, the singular forms of "a", "an" and "the" are intended to include the plural forms unless the context clearly indicates otherwise. It should also be further understood that the term "and / or" used in the specification of the present invention and the claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes these combinations.

[0028] As used in this specification and claims, the term "if" may be interpreted as "when" or "upon" or "in response to determining" or "in response to detecting," depending on the context. Similarly, the phrase "if it is determined" or "if [described condition or event] is detected" may be interpreted as meaning "upon determination" or "in response to determining" or "upon detection of [described condition or event]" or "in response to detecting [described condition or event]," depending on the context.

[0029] The specific embodiments of the present invention are described in detail below with reference to the accompanying drawings.

[0030] In order to fully understand the solution of the present invention, the main process of the present invention is first described.

[0031] Figure 1 An exemplary flow chart of the robot process automation method of the present invention is shown below. Figure 1 The following sections describe some of the processes in this section.

[0032] During the robot registration and creation process, you need to enter the robot registration parameters, which may include: Robot name: The robot name is unique to the robot; Robot description: A user-oriented description of the robot's functions; Special dependencies required by the robot: Python dependencies that need to be installed additionally when using it; The value created by a single execution: The man-hours corresponding to the workload completed by the robot.

[0033] Next, write the robot initial script file

[0034] After completing the robot registration parameter filling, the robot platform will automatically write the registration parameters into the robot registration table, generate the corresponding Robot_Id (robot identification) and record it in the robot management table. At the same time, it will write these parameters into the Robot_Base.Py file (robot basic file), and then generate the {robot_id}.py file to initialize the robot registration. This file is a sample script file that can be run directly. The communication module access and Sdk (software development kit) access have been completed in the file. Developers can start coding directly on the script file to implement the corresponding functions. At the same time, the platform will generate the {robot_id}.json configuration file, which is used to edit the robot interface and operation window on the platform.

[0035] Next, get the configuration file / robot script file address

[0036] The system will return the configuration file address and the robot script file address based on the user's registration information (registration parameters). The user downloads the configuration file and the robot script file to the local computer according to the address to edit the configuration file and compile the robot script file.

[0037] After generating the initial file, the platform will transfer the script file and configuration file to the OSS (cloud storage service) object storage, add the initial version number and initial configuration record in the management table, and then display the download address of the script file in OSS on the robot registration page. Developers can directly click to download the script file and configuration file.

[0038] Next, edit the configuration file

[0039] The configuration file is mainly used for front-end and back-end automation of robot interactive pages, and is used to build element content under fixed element distribution. The configuration file uses a Json string to define the window type and window position required by the front-end page. The first is the fixed 4 partitions (such as Figure 2 ), followed by the content in the partition block, including the link to the instruction manual of element 1 (pdf file link, directly loaded when the user uses it); the progress bar data of element 2, which includes the number and name of the progress nodes; the input parameter creation module of element 3, where an array is used to define a preset module arrangement list, and multiple types of front-end page preset modules such as selectors, multi-selectors, input data, input date, input files, etc. can be used to complete parameter arrangement; the communication window of element 3 is not displayed here by default, and is used for data display and reception when the user needs to participate in the operation process during the operation of individual robots, such as clicking, scanning codes, etc. Table 1 shows the description of each element.

[0040] Table 1

[0041]

[0042] Next, front-end automation

[0043] According to the configuration file, the front-end page will first pull the corresponding Json string when loading the robot, then check whether the defined module is complete, and then fill the corresponding module into the corresponding partition according to the preset module dictionary to form the robot operation page.

[0044] Next, update the robot script file

[0045] The update robot is suitable for scenarios such as function iteration and bug (vulnerability) repair. In other low-code RPA development platforms, the modification-detection-release-online process is adopted, which is very troublesome for robots with urgent functions and frequent updates (user needs change quickly). The update robot action in the present invention adopts the design logic of dynamic pull and hot update, and adopts the modification-automatic inspection / version management-online process when updating, which are introduced below.

[0046] The first is modification. In the present invention, any modification of the robot after registration is regarded as an update operation. The update operation requires uploading the robot script file and configuration file, and then passing the test parameter in the upper parameter input box (such as the robot needs to enter a number, then fill in a Json format parameter {"num": num}), the parameter will be retained in the corresponding version of the data in the registry, when the next update, if no new parameter is passed in, the parameter will be used for automated testing, if there is no operation error or communication error message after the test, the update is considered complete, at this time the management table parameter information of the last robot will be copied, and a new management table parameter with an auto-incrementing version number will be added (the auto-incrementing management table parameter means a structured data table with an auto-incrementing sequence index. When the robot is updated, a new column will be automatically added to the table according to the desc parameter in the passed-in robot file to indicate the latest version of the robot parameter for version checking), and the new robot script file and configuration file will be uploaded to OSS to complete the version management update action.

[0047] Then, when the user clicks on the robot to run, the platform will first perform a version check based on the management table. If the version number of the robot in the current Python lib is inconsistent with the version number in the management table, the platform will obtain the OSS file address stored in the management table, download the latest version of the script file and configuration file, and then import the new Py file (source code file written in Python) through Python's dynamic library import and push out the old version to achieve hot update for user use.

[0048] Next, check the robot script file

[0049] Check robot script files uploaded by users.

[0050] Step 1: Check the structural integrity of the robot, mainly checking the following

[0051] ①There is only one main function

[0052] ② Communication module initialization exists

[0053] ③ Check log count (for subsequent calculation progress)

[0054] ④Exception throwing existence check

[0055] Step 2: If it is the first time to upload, the user is required to enter the test parameters so that the online test robot can run normally.

[0056] Step 3: Update the robot files and display the robot in the robot management.

[0057] The main process of the present invention is introduced above, and the scheme of the present invention is described in detail below in combination with the above content.

[0058] Figure 3 An exemplary flow chart of a robot management method 300 according to an embodiment of the present invention is shown.

[0059] like Figure 3 As shown in, method 300 may include, at step S301, obtaining robot basic information and communication text through a basic script development framework when the robot is created and mounted, so as to create and mount the robot at least based on the basic script development framework that has obtained the robot basic information and communication text.

[0060] In the field of automation, "creation" usually refers to registering a robot program into the system, while "mounting" means deploying or connecting it to a specific working environment to perform tasks. The robot basic information can be the robot registration parameters mentioned above.

[0061] This solution provides developers with a basic script development framework file. This file framework file only limits the basic robot information and communication text that developers must fill in, and does not limit the robot execution function, which solves the needs of a large number of non-standard scenarios for B-end enterprise robots. Specifically: the basic script development framework file can use platform capabilities such as visual recognition interface, text generation, file caching, OSS interaction, etc. by introducing the robot platform SDK. In the basic script development framework file, real-time communication and message forwarding are achieved by accessing the platform interaction Websocket (a protocol for full-duplex communication on a single TCP connection) communication module defined by the SDK and connecting to related platforms (such as DingTalk robots). For non-standard scenarios, such as text reading comprehension and heterogeneous data merging, developers can solve them by writing processing flows in the main function. The biggest advantage of this method over low-code platforms is that a large number of complex capability interfaces can be accessed in the basic script development framework file. Developers only need to focus on the core data processing logic. The input and output of data can be in any form, which can effectively solve the problem that low-code RPA platforms such as Yingdao do not meet the needs of scenarios in terms of heterogeneous data processing and extended interface access.

[0062] In this solution, each robot is essentially an independent Python file, so it can be understood as running multiple files by creating multiple Python running threads. The operation and communication of multiple threads are isolated from each other. Each robot call request initiated by each user will be regarded as a new thread initiation request, so it is necessary to use a thread pool to limit the number of threads running simultaneously. The thread pool solution adopted by the present invention uses the Threading software library (which can create independent thread running programs) to create and manage threads, because the system (the execution system running the robot file, which supports the version management, call arrangement, and operation management functions of the robot, and provides a code operation environment for the robot operation to rely on) is deployed on multiple servers, so the number of thread pools for each service is determined according to the number of threads of the server physical machine. The robot concurrent execution capability that can be provided by deploying a single service is affected by the server hardware equipment. Multiple servers can be deployed at the same time to run more robots at the same time, so that load balancing can be guaranteed. In addition, because each robot will communicate with the user during operation, such as status reporting, receiving instructions, etc., each robot thread needs to have an independent channel for communicating with the user.

[0063] In the present invention, the interaction between the robot execution platform and the user is separated. A forwarding service is built between the two. After the user's request and operation are edited into the corresponding robot request on the forwarding platform, the robot execution platform uses parameters to execute the robot. During this period, the robot execution platform only communicates with the forwarding platform and does not directly interact with the user. Therefore, the present invention uses a unique channel number identification code to isolate messages. When multiple robots are running at the same time, the message will be sent to the forwarding platform through the Websocket of the robot execution module. Each message is accompanied by the channel number identification generated when the task is initiated. The forwarding platform sends the corresponding message to the Websocket of the user page (front end) according to the channel number to complete multi-threaded communication.

[0064] The current low-code platform has the following user experience limitations when the robot is executing: when the robot is executing a task, the user is usually unable to perform other operations and must wait for the robot to complete the task before continuing to operate. This limitation reduces work efficiency, especially when the robot is executing a long-running task. Therefore, in order to solve the asynchronous and concurrent problems of multiple robots and achieve high-performance asynchronous real-time communication, in one embodiment, the above-mentioned basic script development framework file can include a concurrent asynchronous framework file.

[0065] By using a concurrent asynchronous framework when processing session requests, users can separate the robot from other threads, without affecting other user operations during the robot execution process, solving the concurrency problem of multiple users executing the robot at the same time, and handling the problem of multiple robots executing at the same time, thereby improving the processing speed and efficiency of tasks.

[0066] In one implementation, this solution uses an asynchronous network framework based on Fastapi and Asyncio asynchronous programming to solve a large number of concurrent tasks and asynchronous communication problems faced in actual usage scenarios. Furthermore, a Websocket network framework based on Fastapi is used. Fastapi is a modern high-performance asynchronous network programming framework in Python that can provide encapsulated asynchronous network programming APIs; Asyncio is an asynchronous programming library in Python that can provide asynchronous programming capabilities for a single function or class.

[0067] The robot execution module is essentially an asynchronous network service that uses Importlib to dynamically manage the import and removal of packages. In each robot script file, asynchronous programming is used to solve the problem of running blocking, so that after creating an independent thread for each task, the task can continue to run, interrupt, and communicate. When the robot transmits parameters (parameters that the user needs to fill in when calling the robot), the communication is established by passing in the Websocket network protocol defined in the robot execution module. This method makes data exchange between the client and the server simpler, and allows the server to actively push data to the client. In the WebSocketAPI, the browser and the server only need to complete a handshake, and a persistent connection can be directly created between the two, and two-way data transmission can be carried out. In the robot platform SDK, the RobotLogger class is defined (the RobotLogger method provided by the SDK provides a standard communication text framework for parsing data interaction between the robot and the platform. Messages such as {"code":xxx,"chain":1,"msg_type":running_status,"timing":178524398 (timestamp), "msg_content":xxxx}) to standardize multiple types of message formats. When the robot script file is loaded, the number of Logger messages sent in the robot file is calculated as the total progress step number of the robot execution. When the robot is running, the execution progress is indicated by accumulating the number of messages sent.

[0068] It is understandable that the execution of robot tasks is carried out in the task queue. However, according to the description of the thread pool in the previous article, the number of tasks that can be executed simultaneously in the task queue is limited by the number of threads running simultaneously, that is, the number of tasks that can be executed simultaneously is limited. When the number of tasks to be executed is greater than the number of tasks that can be executed simultaneously, the excess tasks will start to queue up to form a waiting queue.

[0069] When each task is created, that is, when the robot is loaded into the execution module, a task attribute Semaphore is added to the Tasks dictionary of the execution module (the dictionary used by the platform to store tasks in the task queue). The task attribute contains Robot_Id (robot identifier), number of messages (messages sent by the robot to the platform during operation, the format of which can be {"code":xxx,"chain":1,"msg_type":running_status,"timing":178524398(timestamp),"msg_content":xxxx}), task value, and task creation timestamp, so as to record the requested robot in the execution module. The upper limit of the number of tasks in the task pool is the thread pool upper limit. When a request task appears (a task is created) and the task pool has reached the thread pool upper limit, the task attributes will be stored in the Wait_Job dictionary (that is, the dictionary storing tasks in the waiting queue) and wait for execution. After the task enters the waiting queue, it will first return a message to the user whether to continue queuing. If the user gives up queuing, the task will be directly pushed out of the waiting queue. If the user chooses to continue queuing, it will continue according to the subsequent process. The subsequent execution process will be described below.

[0070] When executing tasks, the first-come-first-served algorithm (FCFS) is used in the task queue, that is, if there is no waiting task, the initiated task will be executed. For example, a machine can provide 20 threads to serve at the same time. Then, when the number of parallel tasks is less than 20, there will be no waiting tasks (parallel includes running and newly initiated), and there will be no waiting queue; when the number of parallel tasks reaches 20, the newly created or initiated tasks need to start waiting. For example, if there are 21 parallel tasks, there will be 20 tasks in the task queue and 1 task in the waiting queue. If there is a waiting queue, when a task in the task queue ends, a task is selected from the waiting queue to enter the task queue. For example, if there are 21 parallel tasks, there are 20 tasks in the task queue and 1 task in the waiting queue. Now one task has finished executing, and the number of tasks in the task queue becomes 19. At this time, 1 task can be selected from the waiting queue to enter the task queue. At this time, the number of tasks in the task queue becomes 20, and the number of tasks in the waiting queue becomes 0.

[0071] Based on the above understanding, the following Figure 4 Another robot management method is shown in . Figure 4 An exemplary flow chart of a robot management method 400 according to another embodiment of the present invention is shown.

[0072] like Figure 4As shown in , method 400 may include, at step S401, obtaining robot basic information and communication text through a basic script development framework when the robot is created and mounted, so as to create and mount the robot at least according to the basic script development framework that has obtained the robot basic information and communication text. This step has been described in detail in conjunction with the embodiment above and will not be described in detail here.

[0073] At step S402, during the robot execution process, in response to the creation of a new task but no waiting queue for resource allocation, the order of resource allocation is determined according to the creation order of the task, that is, resources are allocated and executed first for tasks with earlier creation time, and then resources are allocated and executed for tasks with later creation time. That is, a first-come, first-served strategy (FCFS) is adopted, which can solve the problem of multi-robot queuing.

[0074] For tasks in the waiting queue, the order in which they are executed can be determined according to their execution priorities. Therefore, the present invention provides another embodiment to illustrate the implementation method.

[0075] Figure 5 An exemplary flow chart of a robot management method 500 according to another embodiment of the present invention is shown.

[0076] like Figure 5 As shown in , method 500 may include, at step S501, obtaining robot basic information and communication text through a basic script development framework when the robot is created and mounted, so as to create and mount the robot at least according to the basic script development framework that has obtained the robot basic information and communication text. This step has been described in detail in conjunction with the embodiment above and will not be described in detail here.

[0077] At step S502, during the robot execution process, in response to the existence of a waiting queue waiting for resource allocation, for each task in the waiting queue, its execution order is determined according to its execution priority, wherein the execution priority of the task is determined according to the weight of the task. It can be understood that the greater the weight, the higher the execution priority, the earlier the execution order of the task, and the smaller the weight, the lower the execution priority, and the later the execution order of the task.

[0078] In an implementation scenario, the execution priority of each task can be determined by the following method:

[0079] When a newly created task begins to enter the waiting queue, its initial weight is determined. In one implementation, determining its initial weight may include: determining its initial weight based on one or more of the urgency of the task, the estimated execution time, and the task type. The higher the urgency, the greater the weight of the task, and the lower the urgency, the smaller the weight of the task, thereby ensuring that urgent tasks (urgent tasks can also be defined as high-value tasks, and the task value is the manual replacement hours filled in when the robot is registered or updated. The manual replacement hours can be understood as the excess of manual hours relative to machine hours when completing the same job. For example, if a job requires 4 working days to be done manually, and the working hours per day are 8 hours, then the job requires 4*8=32 hours to complete, and the robot needs 10 minutes to complete this job, then the replacement hours = 32 hours - 10 minutes, which is approximately equal to 31.5 manual hours. working hours, then the task value of the robot is 31.5. This value may be modified during the update. For example, if the manual labor becomes faster, it will be recalculated and modified. The higher the manual replacement working hours, the higher the task value, and vice versa. The lower the task value) will be executed first; the shorter the expected execution time of the task, the greater its weight, and the longer the expected execution time of the task, the smaller its weight, so as to ensure that short tasks are executed first. The short task is usually a task with a small amount of messages (messages sent when the robot is running). For example, when the robot is running, a task that sends more than or equal to 50 messages is set as a long task, then a task that sends less than 50 messages is a short task. Of course, the initial weight of the task can also be comprehensively determined by combining two or more of these conditions, such as determining it according to the urgency of the task and the expected execution time, determining it according to the task type and the expected execution time, or determining it according to the urgency of the task, the expected execution time and the task type.

[0080] After determining the initial weight, the execution priority of each task in the waiting queue can also be determined according to the initial weight and the current weights of other tasks in the waiting queue. At this time, the execution priority of each task in the waiting queue can be sorted according to the initial weight of the task and the weight of the existing tasks in the waiting queue.

[0081] In order to avoid task starvation, during the task waiting process, it is necessary to ensure that the tasks with longer waiting time are executed first. Therefore, the weights of each task can be continuously calculated during the process to re-determine the execution priority. Therefore, the method of this solution can also include:

[0082] For tasks waiting in the waiting queue, their current weight can be determined according to their waiting execution time. It is understandable that for tasks entering the waiting queue, if the user chooses to continue waiting, a timer will be created.

[0083] In one implementation, the weight of a task can be calculated using the following formula:

[0084] V=ax+by

[0085] Among them, V is the weight, a and b represent a constant coefficient, x is the task value, and y is 1-(number of messages / 500), where the number of messages is known in advance.

[0086] The task value here is related to the waiting execution time of the task. The longer the waiting execution time of the task, the higher its task value, and the shorter the waiting execution time of the task, the lower its task value. The relationship between the task value and its waiting execution time can be proportional or other specific relationships. For example, the task value of the task can be increased by a preset value, such as 0.2, every preset time (the time can be counted by a timer), for example, every 1 second. It can be understood that the relationship between the task value and its waiting execution time here is only exemplary and not restrictive, and other relationships can also be selected, and the present invention is not limited to this.

[0087] After obtaining the current weight of the task, the execution priority of each task in the waiting queue can be dynamically adjusted according to the current weight of each task.

[0088] It can be seen that this scheme can dynamically adjust the execution order of tasks by weighting them during waiting, so as to ensure that when a task's waiting time exceeds the weight of other tasks, it can be executed first, thereby avoiding task starvation.

[0089] It is understandable that when a newly created task enters the waiting queue, it is necessary to redetermine the execution priority of each task based on the initial weight of the new task and the weight of each task in the current waiting queue, thereby determining the resource allocation order of each task.

[0090] According to the above method of the present invention, it can be ensured that low-priority tasks can also be executed eventually, thereby avoiding task starvation.

[0091] According to the above description, this solution adopts a weight-based priority queue scheduling algorithm. If there is no waiting queue, a first-come, first-served strategy is used to execute tasks, that is, resource allocation is initiated in the order in which tasks are created, and they are executed in sequence. If there is a waiting queue, tasks are executed according to the execution priority. Therefore, this solution can ensure that the executing robots can fully use server resources. In general, this solution uses a weight-based priority queue scheduling algorithm to solve the resource allocation problem in the execution process of multiple robots. By integrating technologies such as concurrent asynchronous frameworks and weight-based priority queue scheduling algorithms, the smoothness of the robot execution process is achieved, ensuring that users can handle other tasks at the same time when executing robots, and avoiding the phenomenon that users cannot operate due to robot execution.

[0092] In one embodiment, the method of this solution further includes: during the robot execution process, using a dynamic file loading strategy to obtain files. This solution uses a dynamic library file loading strategy to ensure that the robot files are pulled as needed, thereby solving the problem of storage resource occupation and realizing hot update.

[0093] Existing low-code platform technologies usually need to perform tasks on client devices, which means that they have a certain dependence on the performance of hardware devices. For enterprise-level activities that require a lot of computing resources or complex processing, this dependence may cause the task execution time to be too long, or even unable to be executed when hardware conditions are insufficient. This not only affects efficiency, but also limits the feasibility of low-code solutions in enterprise-level applications. In order to solve this problem, this solution can also include: the robot's tasks are executed in the cloud. In this way, all tasks of the robot can be executed in the cloud, thereby reducing dependence on user hardware conditions, and then the execution speed of tasks can be increased, ensuring that the robot tasks of enterprise-level users can be executed efficiently. As a result, the problem of multiple systems of B-side enterprises coordinating activities, low manual efficiency, cumbersome operation, and low accuracy is solved.

[0094] The overall effect of the method of the present invention is summarized below. The present invention solves the problem of non-standard input. Here, it mainly refers to the requirements for the use of traditional low-code RPA platforms, especially in common scenarios such as data modification, batch data processing, browser operation input and output: 1. The data input format must be consistent; 2. The context connection of all nodes must be a platform standard data structure; 3. Accurate processing logic must be set, which is very difficult for the user group applicable to this system and requires a lot of time and energy investment; 4. Running locally, occupying local computer resources, is not friendly to old models and will cause jams that affect the normal application of users.

[0095] All script files of the present invention are written by developers, which are accurate, and the platform provides many encapsulation capabilities to save development time. All tasks are run in the cloud, which relieves the pressure of users and only requires managed processing. Data input and output are generalizable. The parameter input of all robots in this system has multiple types, which basically covers the needs within the enterprise, and supports hot updates and can be modified and used at any time. The platform adopts a concurrent asynchronous framework, which can support large-scale tasks to run and communicate simultaneously, and service resources support dynamic expansion.

[0096] Figure 6 is a structural block diagram of a device 600 according to an embodiment of the present disclosure.

[0097] like Figure 6As shown in , the device 600 includes a processor 601 (processor), a memory 602 (memory) and a bus 603; wherein the processor 601 and the memory 602 communicate with each other through the bus 603. The memory 602 stores program instructions executable by the processor 601. In operation, the processor 601 is used to call the program instructions in the memory 602. When the program instructions are executed by the processor 601, the device 600 executes the method steps described above in conjunction with the drawings.

[0098] The equipment of this solution provides developers with a basic script development framework file. This file framework file only limits the basic robot information and communication text that developers must fill in. It does not restrict the robot's execution functions, and does not restrict the form of data input and output, thereby solving the needs of a large number of non-standard scenarios for B-side enterprise robots.

[0099] A person skilled in the art can understand that all or part of the steps of implementing the above method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable medium, which, when executed, executes the steps of the above method embodiment.

[0100] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a necessary general hardware platform, and of course, by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the prior art can be embodied in the form of a software product, which can be stored in a computer-readable medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0101] It should be understood that the terms "first", "second", "third" and "fourth" etc. in the claims, specifications and drawings of the present invention are used to distinguish different objects rather than to describe a specific order. The terms "include" and "comprise" used in the specification and claims of the present invention indicate the presence of the described features, wholes, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, wholes, steps, operations, elements, components and / or their collections.

[0102] Although multiple embodiments of the present invention have been shown and described herein, it will be apparent to those skilled in the art that such embodiments are provided by way of example only. Those skilled in the art may conceive of many changes, modifications, and alternatives without departing from the thought and spirit of the present invention. It should be understood that in the process of practicing the present invention, various alternatives to the embodiments of the present invention described herein may be adopted. The appended claims are intended to define the scope of protection of the present invention, and therefore cover equivalents or alternatives within the scope of these claims.

Claims

1. A method for robot management, comprising: When the robot is created and mounted, the basic information and communication text of the robot are obtained through the basic script development framework file, so as to create and mount the robot at least according to the basic script development framework that has obtained the basic information and communication text of the robot.

2. The method according to claim 1, wherein the basic script development framework file comprises a concurrent asynchronous framework file.

3. The method according to claim 1, further comprising: During the robot execution process, in response to a new task being created but no waiting queue for resource allocation exists, the order of resource allocation for the tasks is determined according to the order in which the tasks are created.

4. The method according to claim 1, further comprising: During the robot execution process, in response to the existence of a waiting queue waiting for resource allocation, the execution order of each task in the waiting queue is determined according to its execution priority, wherein the execution priority of the task is determined according to the weight of the task.

5. The method according to claim 4, wherein the execution priority of each task is determined by the following method: When a newly created task begins to enter the waiting queue, its initial weight is determined; and The execution priority of each task in the waiting queue is determined according to the initial weight and the current weights of other tasks in the waiting queue.

6. The method according to claim 5, wherein determining its initial weight comprises: The initial weight of the task is determined based on one or more of its urgency, estimated execution time and task type.

7. The method according to claim 5, further comprising: For tasks waiting in the waiting queue, their current weight is determined according to their waiting execution time; as well as The execution priority of each task in the waiting queue is dynamically adjusted according to the current weight of each task.

8. The method according to any one of claims 1 to 7, further comprising: During the robot execution, a dynamic file loading strategy is used to obtain files.

9. The method according to any one of claims 1 to 7, further comprising: The robot's tasks are performed in the cloud.

10. A device comprising: processor; A memory storing program instructions executable by a processor, wherein when the program instructions are executed by the processor, the device executes the method according to any one of claims 1 to 9.

11. A computer-readable medium storing instructions for robot management, which, when executed by at least one processor, causes the method according to any one of claims 1 to 9 to be performed.

Images