Process operation system and process operation method

Abstract

A process operation system includes a queue service, a process operation platform, and an endpoint task robot. The queue service runs with containerization technology. The process operation platform stores the received tasks into the task queue of the queue service. The endpoint task robot has a connection module and performs the following operations, which include: completing the connection with the queue of the queue service by obtaining the connection factory information pre-generated by the queue service; obtaining a target task through the queue channel according to the preset authority setting; and, before establishing a connection with the queue service, checking the queue connection and the queue channel, if both do not exist, connecting according to the connection factory information.

Description

[Technical Field]

[0001] This invention relates to an operating system, and more particularly to a process operating system and process operation method for automation. [Previous Technology]

[0002] In recent years, with the significant improvement of hardware computing power, the ability of machine learning algorithms to recognize speech and images has also been enhanced. In addition, the successful training of neural networks has opened up unlimited imagination for artificial intelligence applications. Enterprises have also invested a lot of manpower and resources in the field of artificial intelligence technology. For example, they have developed robotic process automation (RPA) with artificial intelligence to complete daily tasks that were previously performed by humans.

[0003] Traditional Robotic Process Automation (RPA) systems can be broadly divided into four main components to complete the assigned tasks. These four components include: an AI platform, an RPA platform, endpoint task robots, and a messaging queue service. The AI ​​platform performs semantic analysis to determine the intent behind the task and generates the task. The RPA platform writes the task execution flow and error handling steps. The endpoint task robots receive the task and execute it according to a predefined flow. The messaging queue service facilitates information exchange between the various platforms and the endpoint task robots. Through the close integration of these four components, automated tasks assigned by the enterprise can be successfully completed, significantly reducing manual processing time and allowing human resources to focus on value-added work.

[0004] Traditional robotic process automation (RPA) systems typically use an independent orchestrator to assign tasks to endpoint robots. Therefore, a well-equipped orchestrator is required. Furthermore, to ensure high availability, practical experience dictates having more than one orchestrator, acting as a backup for each other, to assign tasks to idle endpoint robots. This necessitates additional manpower and time for platform administrators to set up the environment, resulting in higher initial setup costs.

[0005] Based on practical experience in enterprises, different departments or institutions may share the same coordination machine for task assignment. Therefore, when a new skill is completed and tested online, the management personnel must set up the endpoint task robot that will be delivered to the coordination machine in the future. This undoubtedly puts a burden on the management personnel, and may even cause delays in the online schedule when the management personnel are busy.

[0006] Enterprises must respond immediately to the needs of rapid change. There are often sudden surges in tasks that need to be executed. Traditional robotic process automation systems require the installation of services on the endpoint task robots and the subsequent task assignment can only be carried out after the endpoint task robots have completed registration with the coordinating machine. This hinders the flexibility of expanding and reclaiming execution resources.

[0007] Traditional robotic process automation (RPA) systems often use distributed message queues. This architecture employs a publish-subscribe mechanism to divide messages into multiple equal parts, thereby increasing message throughput. However, distributed message queues, due to the addition of intermediary servers (brokers), must consider the issues of message loss and duplicate message reception. If these situations occur due to connectivity problems, they can cause significant losses to enterprises. [Summary of the Invention]

[0008] In order to solve the aforementioned problems, the process operating system and method proposed in this invention divide the service construction process into five modules for management and control. The five modules are: queued service (with container technology), connection module, reporting module, connection check module and notification module. Through the interaction between the modules, various tedious and extremely important daily maintenance processes of enterprises can be completed automatically.

[0009] An embodiment of the present invention provides a process operating system. This process operating system includes: a queue service, a process operation platform, and an endpoint task robot. The queue service operates using integrated containerization technology. The process operation platform stores received work tasks into a task queue within the queue service. The endpoint task robot has a connection module and performs the following operations: establishing a connection with the queue service's queue by obtaining connection management information pre-generated by the queue service; obtaining a target work task through a queue channel according to preset permission distinctions; and, before establishing a connection with the queue service, checking the queue connection and the queue channel; if neither exists, establishing a connection according to the connection management information.

[0010] In one embodiment of the present invention, the queue service is configured to use Kubernetes container technology in conjunction with RabbitMQ queue service.

[0011] In one embodiment of the present invention, the endpoint task robot further includes a reporting module that performs the following operations: after completing the target task through an event bus architecture, the endpoint task robot reports to the process operating system; and after confirmation, the process operating system notifies the endpoint task robot to delete the target task from the queue service through the queue service.

[0012] In one embodiment of the present invention, the endpoint task robot further includes a connection check module; after the endpoint task robot is enabled, the connection check module performs a connection check at predetermined intervals; when it is determined that the connection between the endpoint task robot and the queue service is interrupted, the connection check module re-rebuilds the connection during the next check; when the endpoint task robot is enabled for the first time, the connection check module does not perform the queue connection check; when the endpoint task robot is performing a work task, the connection check module does not perform the queue connection check.

[0013] In one embodiment of the present invention, the endpoint task robot further includes a notification module. The notification module obtains the number of work tasks to be executed by the endpoint task robot, and issues a notification when the number of work tasks reaches the upper limit; the notification module sends heartbeat information to the process operation platform at a predetermined time interval, and issues a warning if the process operation platform finds that the endpoint task robot has not sent the heartbeat information for more than the predetermined time.

[0014] Another embodiment of the present invention provides a process operation method, including: using a queue service integrated by containerization technology; receiving a work task through a process operation platform and storing it in the task queue of the queue service; and performing the following operations through an endpoint task robot with a connection module: completing the queue connection between the endpoint task robot and the queue service by obtaining connection management information pre-generated by the queue service; obtaining a target work task through the queue channel according to the preset permission distinction of the endpoint task robot; and checking the queue connection and the queue channel before the endpoint task robot establishes a connection with the queue service, and if neither exists, establishing a connection according to the connection management information.

Implementation Method

[0015] The following description is a preferred embodiment of the invention and is intended to describe the basic spirit of the invention, but is not intended to limit the invention. The actual invention must be referred to the scope of the following patent application.

[0016] It must be understood that the words “comprising” and “including” used in this specification are used to indicate the presence of specific technical features, values, method steps, work processes, elements and / or components, but do not exclude the addition of more technical features, values, method steps, work processes, elements, components, or any combination thereof.

[0017] The use of words such as “first”, “second”, “third” in the request item is to modify the elements in the request item, and is not used to indicate that there is a priority order, a precedence relationship, or that one element precedes another element, or the time sequence of execution of method steps. It is only used to distinguish elements with the same name.

[0018] Please refer to Figure 1, which is a schematic diagram of a process operating system 100 according to an embodiment of the present invention. In one embodiment, as shown in Figure 1, the process operating system 100 includes a process control platform 10, a process operation platform 20, an endpoint task robot 30, and a queue service 40.

[0019] In one embodiment, the process control platform 10 can be implemented by a server, a laptop computer, or a desktop computer. In one embodiment, the process operation platform 20 can be implemented by a laptop computer, a desktop computer, or a virtual machine. In one embodiment, the process operation platform 20 has the function of Robotic Process Automation (RPA).

[0020] In one embodiment, the endpoint task robot 30 may be implemented by a laptop, a desktop computer, or a virtual machine. In one embodiment, a physical machine (e.g., a server) or a virtual machine (e.g., a virtual machine installed on a server) may serve as the endpoint task robot 30.

[0021] In one embodiment, the process control platform 10, the process operation platform 20 and the endpoint task robot 30 each include a processor, a microcontroller, a microprocessor, a digital signal processor, an application-specific integrated circuit (ASIC), or a logic circuit.

[0022] In one embodiment, the process control platform 10 includes a storage device, which may be implemented by read-only memory, flash memory, floppy disk, hard disk, optical disk, USB flash drive, magnetic tape, database accessible by network, or other storage media with the same function that can be easily conceived by those skilled in the art.

[0023] In one embodiment, the process control platform 10 is responsible for providing a user interface that allows users to start a series of task initiation operations. The user interface can be achieved by opening a webpage, application, or scheduled timer through a user device (e.g., mobile phone, laptop or desktop computer) to initiate a task, such as by generating an email to transmit task information.

[0024] In one embodiment, the process control platform 10 receives an email and retrieves a file from the email. The process control platform 10 then retrieves the task from the file. In one embodiment, this file is, for example, an Excel file. This Excel file, for example but not limited to, is where purchasing personnel record the various part numbers, quantities, and models to be ordered when making purchases. This Excel file is then attached to an email and sent to the process control platform 10. After receiving the email, the process control platform 10 automatically detects the attachment, for example, by recognizing the email content (including the attachment field) through text recognition, or by recognizing the icons of each field in the email. The platform then downloads or opens the file, extracts a task (e.g., a purchasing task) from the operation information using known semantic analysis methods, and publishes it as a work task.

[0025] Here, the process control platform 10 is, for example, an artificial intelligence platform, which can execute known semantic analysis methods, such as natural language processing (NLP) algorithms, machine learning algorithms, text exploration algorithms, parsing algorithms, etc., to extract information and issue work tasks.

[0026] In one embodiment, the queue service 40 uses container technology in conjunction with a container resource scheduling platform to complete the required queue service and provide information such as endpoints, accounts, and passwords required for information exchange in subsequent process operations. Here, the queue service 40 of this embodiment is constructed by integrating RabbitMQ queue service with container technology. The queue service 40 of this embodiment uses RabbitMQ because it supports many communication protocols, has more complete functions and better performance, and is more suitable for enterprise-level development.

[0027] Container technology, because it does not contain an operating system image, has the advantages of requiring fewer resources and being more efficient compared to deploying services on physical and virtual hosts. Furthermore, deploying using the same application allows for consistent service specifications, making it easier to scale and manage. The container technology in this embodiment, for example but not limited to, uses the Kubernetes container resource scheduling platform. Because it can automatically detect and manage the status of each container, if there are insufficient resources or abnormal situations, it can immediately perform automatic scaling or deletion and reconstruction of containers, ensuring uninterrupted service operation and reducing the burden on administrators.

[0028] In one embodiment, the process operation platform 20 stores the work tasks received from the process control platform 10 into the task queue of the queue service 40.

[0029] In one embodiment, as shown in Figure 2, the endpoint task robot 30 includes: a connection module 301, a reporting module 302, a connection check module 303, and a notification module 304. Their operations will be described in sequence below.

[0030] [Connection Module] The application scope of the process operating system 100 in this embodiment can be spread across various business units and support departments of an enterprise. Therefore, for example, but not limited to, it can be used with AD (Active Directory) accounts (also known as digital employee accounts) to distinguish each endpoint task robot 30. After the endpoint task robot is initially enabled and its permissions are verified as a legitimate digital employee, it can use its connection module 301 and obtain the connection management information (Connection Factory) pre-generated by the queue service 40 through encryption and decryption methods to complete the connection. The connection management information is used to create a connection and channel with the server (e.g., RabbitMQ server) of the queue service 40. The channel is the actual channel for sending and receiving messages, while the connection refers to the actual network connection between the RabbitMQ client (endpoint task robot 30) and the RabbitMQ server (queue service 40).

[0031] Because sharing a single queue channel is prone to errors, in one embodiment, access permissions are differentiated for endpoint task robots (digital employees), meaning each endpoint task robot (digital employee) connects independently to its assigned queue channel. For example, the channels available to the endpoint robot 30 are differentiated based on the tasks of the business unit it is handling. Using this method, if a single endpoint task robot malfunctions, it can be independently deleted and rebuilt without affecting others, significantly reducing the impact. For users, the tasks of the endpoint task robots (digital employees) are also set independently, facilitating monitoring and management, and further improving security.

[0032] Before each connection, the endpoint task robot 30 must check the queued connections and channels again. If neither exists, the connection can be made according to the defined connection management information. If they exist, to ensure the uniqueness of the connection, the connection and channel must be deleted in sequence to avoid multiple queued connections causing the endpoint robot to fail to execute multiple tasks simultaneously.

[0033] Figure 3 shows an example of the processing flow of the connection module 301 of the endpoint task robot 30. First, the connection module 301 checks whether the connection management information exists (step S31). If it does not exist (step S31: No), for example but not limited to, the process operating system 100 is notified to set the connection management information (step S32), and proceeds to step S33 to determine whether the instance connection exists. If the connection management information already exists (step S31: Yes), the instance connection is checked to see if it exists (step S33). If the instance connection already exists (step S33: Yes), that is, the connection is in the open state, the instance connection is deleted (step S34), and proceeds to step S35. If the instance connection does not exist (step S33: No), proceeds to step S36.

[0034] In step S36, the connection module 301 establishes a queue connection with the queue service 40. Then, in step S37, the queue channel is deleted and then the queue channel is re-established to complete the connection.

[0035] In step S35, the connection module 301 checks whether the queued channel exists. If it exists (step S35: Yes), the queued channel is deleted (step S38). If the queued channel does not exist (step S35: No), the queued channel is created (step S39).

[0036] The endpoint task robot 30 (digital employee) may further, for example but not limited to, set a QoS (Quality of Service) mechanism in the connection module 301. The QoS mechanism ensures that a connection will only obtain one message at a time, and that message cannot be obtained by other endpoint task robots before the endpoint task robot replies with confirmation. Therefore, it can ensure that a task is executed by only one endpoint task robot from beginning to end. It should be noted that if the task cannot be replied to for a long time, and the endpoint task robot that was originally executing the task goes offline, the task will be returned to the queue service after a period of time so that it can be handed over to other endpoint robots for execution. This allows other idle digital employees to take over when an anomaly occurs, making the operation more flexible.

[0037] [Report Module] After completing the automated operation according to the predetermined process, the endpoint task robot 30 in this embodiment will report to the process control platform 10 (artificial intelligence platform) through the report module 302. The process control platform 10 will then report the execution records to the user. After the process control platform 10 confirms the final results, it will notify the endpoint task robot 30 to delete the completed task from the queue service.

[0038] The stable operation of the endpoint task robot 30 relies on the queue service 40 for information exchange. The feedback module 302 in this embodiment focuses on the correctness and availability of sending messages to the queue service 40. While APIs (Application Programming Interfaces) are fast and have feedback mechanisms, when there are too many endpoint task robots 30 (digital employees), there is a high probability that the number of API calls will be too high, leading to congestion and delays. Therefore, in one embodiment, the feedback module 302 adopts an asynchronous queue processing mechanism and incorporates the MassTransit framework. The MassTransit framework supports various message exchange services, providing powerful and complete message patterns, including publish and subscribe, Saga, and eventual consistency support, along with the necessary solutions between endpoints, such as exception handling, retry mechanisms, and lifecycle management. Using this framework reduces the complexity of message exchange applications.

[0039] Figure 4 shows an example of the processing flow of the reward module 302 of the endpoint task robot 30.

[0040] An event bus is an architecture used to pass messages or events between different components or services. It allows different application components or modules to send and receive events asynchronously (i.e., to communicate asynchronously) without needing to know or be coupled with each other directly. Due to its decoupling capability, event senders and receivers only need to rely on the event's identifier or content to interact.

[0041] The reporting module 302 of the endpoint task robot 30 can use an event bus to transmit messages or events. In one embodiment, the endpoint task robot 30 reports to the process control platform 10 (artificial intelligence platform) whether the task has been successfully completed (step S41) for the work task it performs. If it is successfully completed (step S41: Yes), the reporting ends. If it is not successfully completed (step S41: No), the reporting procedure is repeated (steps S42 and S43). In step S42, if the number of re-reports has not reached the limit (step S42: No), it waits for a predetermined time, such as 5 seconds (step S43), and then returns to step S41. When the number of re-reports has reached the limit (step S42: Yes), it indicates that the reporting through the event bus has failed (step S44), and the reporting is changed to whether it was successful through the API (step S45).

[0042] In step S45, if the report is successful (step S45: Yes), the reporting process ends. If the report is unsuccessful (step S45: No), the reporting procedure is repeated (steps S46 and S47). In step S46, if the number of re-reports has not reached the limit (step S46: No), wait for a predetermined time, such as 5 seconds (step S47), and then return to step S45. If the number of re-reports has reached the limit (step S46: Yes), indicating that the report via API has failed, a log notification is issued and the process ends (step S48).

[0043] After the endpoint task robot 30 (digital employee) completes its work task and submits a completion report, it must wait for the process control platform 10 (artificial intelligence platform) to reply that the report has been received, thereby synchronizing the data for subsequent notification processing, error tracking, and statistical operations. Once the endpoint task robot 30 has indeed received the instruction from the process control platform 10 via the queue service 40 to notify that the task is completed, the endpoint task robot 30 must connect to the queue service 40 to remove the completed work task, ensuring that the completed work task will not be executed again. If this removal step continues to fail, it is determined that there is a high probability that the connection with the queue service 40 has been interrupted; at this time, the deletion operation will not be repeated, but the connection will be re-established using the connection module 301 to avoid the endpoint task robot stalling and causing delays in task execution.

[0044] Figure 5 shows an example of a deletion process for completed tasks in the endpoint task robot 30, using a reporting module 302. The process control platform 10 notifies the endpoint task robot 30 to delete the completed tasks via the queue service 40. In step S51, if the reporting module 302 replies that the deletion was successful (step S51: Yes), the process ends. If the reporting module 302 does not reply that the deletion was successful (step S51: No), the endpoint robot 30 performs a retry operation (steps S52 and S53). In step S52, the reporting module 302 checks whether the number of retry operations has reached the limit. If not (step S52: No), it waits for a predetermined time, such as 5 seconds, and then retryes (step S53). If the number of retry operations has reached the limit (step S52: Yes), it activates the connection module 301 to retrieve the task to be executed again (step S54).

[0045] [Connectivity Check Module] In one embodiment, the endpoint task robot 30 connectivity check module 303 is used to provide a proper check mechanism and to activate the connectivity module 301 at an appropriate time when the connectivity is interrupted.

[0046] In this embodiment, when the endpoint task robot 30 (digital employee) is activated, the connection check module 303 immediately performs a connection check operation, for example, but not limited to, once every three minutes, to ensure the status of the connection. It should be noted that since the connection of the endpoint task robot 30 is only established when it is first activated, checking again at this time would undoubtedly be an extra waste of computing resources. Therefore, the connection check module 303 does not perform a connection check when the endpoint task robot 30 is first activated. Furthermore, when the endpoint task robot 30 establishes a connection while performing a work task, it will be determined to be in an idle state, and thus a new work task will be acquired for execution. This can lead to simultaneous execution anomalies and increase the probability of errors. Therefore, the connection check module 303 does not perform a connection check while the endpoint task robot 30 is performing a work task. If the endpoint task robot 30 is indeed disconnected, it can be reactivated for reconnection during the next check (after 3 minutes) or during the action of the reporting module 302.

[0047] Figure 6 shows an example of the processing flow of the connection checking module 303 in the endpoint task robot 30. In this embodiment, after the endpoint task robot 30 is enabled, the connection checking module performs queue connection checks at predetermined intervals, for example, checking the connection between the endpoint task robot 30 and the queue service 40. In step S61, when the endpoint task robot 30 (digital employee) is enabled for the first time (step S61: Yes), the connection checking module 303 will not perform queue connection checks. When the endpoint task robot 30 (digital employee) is not enabled for the first time (step S61: No), it is further confirmed whether the endpoint task robot 30 is performing a work task (step S62). If the endpoint task robot 30 is performing a work task (step S62: Yes), no connection check is performed. If the endpoint task robot 30 is not performing a work task (step S62: No), the connection check module 303 detects whether there is an abnormality in the queue connection or queue channel (step S63). If an abnormality is detected (step S63: Yes), the connection module 301 is activated to establish a connection (step S64); otherwise, the connection check can be terminated.

[0048] [Notification Module] In one embodiment, the process operating system 100 uses a mechanism to establish a flow distribution mechanism in the queue service 40 by differentiating endpoint task robots 30 (digital employees) based on permissions. The number of messages corresponding to each endpoint task robot in the queue endpoint is the number of tasks that the digital employee currently needs to execute.

[0049] The upper limit of the number of queued endpoint messages (the number of tasks pending execution by the endpoint task robot 30) can be flexibly adjusted according to the needs of the managers of the digital workforce. The endpoint task robot 30 also periodically checks the number of queued endpoint messages with the queueing service 40. When the upper limit is reached, the notification module 304 sends a notification to the process operating system 100 or relevant managers. In this way, managers can be reminded that there are too many tasks pending execution and more resources may be needed to process them.

[0050] Once the endpoint task robot 30 (digital employee) is enabled, it will send heartbeat information, including the currently executed task, version, and time, to the queued service 40 every fifteen minutes, for example, but not limited to. The process operation platform 20 (RPA platform) has a continuously running service or routine that constantly monitors the queued service 40 and writes the received messages to the database. When the process operation platform 20 (RPA platform) detects that any digital employee has not responded to the heartbeat information within the specified time, it will notify the relevant administrators by email, reminding the administrators to check or restart the digital employee.

[0051] [Process Operating System] Figure 7 summarizes and shows the overall processing flow of the endpoint task robot 300's connection module 301, connection check module 302, report module 303, and notification module 304, and the queue service 40 in the process operating system 100 of this embodiment.

[0052] In step S71, endpoint robot 30 is activated and a connection is established for the first time through connection module 301. In step S72, the queue service 40 provides connection management information, digital employee identification (ID), etc., to connection module 301 to establish a connection. A retry mechanism is included in this step to ensure successful connection. In step S73, connection module 301 further confirms the connection. Subsequently, every predetermined time interval, for example, every 3 minutes, in step S74, connection check module 302 performs a connection check. In step S75, if connection check module 302 confirms that endpoint task robot 30 is performing a work task (step S75: Yes), then connection check is not performed (step S76). If the connection check module 302 confirms that the endpoint task robot 30 is not performing a work task (step S75: No) and finds that the connection is not normal, then the connection module 301 clears the old connection and re-establishes the connection with the queue service 40 (step S77).

[0053] In step S78, the reporting module 302 continuously monitors whether the endpoint task robot 30 has completed the work task according to the predetermined process, and transmits the task execution result with the queue service 40 through the event bus and deletes the completed work task from the queue service 40 (step S79).

[0054] In step S80, the endpoint task robot 30 periodically checks the number of queued endpoint messages (number of pending tasks) with the queued service 40, for example, through the notification module 303. The queued service then reports back the number of queued endpoint messages (step: S81). When the number exceeds the upper limit (step: S82), the notification module 304 issues a notification or warning (step: S83).

[0055] The biggest difference between the process operating system and method of this invention and traditional technology lies in the way work tasks are obtained: from bottom to top, idle endpoint task robots connect to the task queue service and obtain work tasks. However, traditional technologies all use an independent coordinator to assign tasks to endpoint task robots.

[0056] Furthermore, the process operating system and method of this invention have advantages such as lower initial setup costs, strict permission differentiation, and easy expansion of execution resources. The process operating system and method of this invention select suitable queue services, which feature asynchronous communication and a decoupled architecture. Asynchronous communication allows users to send tasks and endpoint task robots to execute in a asynchronous manner; the decoupled architecture allows for independent segmentation of queues. When a queue endpoint malfunctions and needs to be removed and rebuilt, other queue endpoints will not be affected, contributing to the stability and maintainability of the system.

[0057] Furthermore, to improve service availability, the queue service employs containerization technology and container scheduling services. These technologies enable automatic monitoring of the queue service and automatic reconstruction in case of anomalies. Additionally, the endpoint task robot incorporates robust error handling and retry mechanisms, ensuring that any abnormalities in task acquisition or connection processes can be appropriately addressed to restore the abnormal endpoint task robot to normal operation. The process operating system and method of this embodiment of the invention utilize a monitoring / alert mechanism to notify relevant managers when the endpoint task robot fails to respond within a predetermined time or when the number of queued tasks exceeds a preset limit. This better aligns with enterprise operational practices, ensuring efficient workload management and meeting the needs of task processing.

[0058] Although the present invention has been disclosed above by way of embodiments, it is not intended to limit the present invention. Any person skilled in the art can make various 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. [Simplified Explanation of the Diagram]

[0059] Figure 1 is a schematic diagram of a process operating system 100 according to an embodiment of the present invention. Figure 2 shows a configuration schematic diagram of the endpoint task robot 30 of Figure 1. Figure 3 shows an example of the processing flow of the connection module 301 of the endpoint task robot 30. Figure 4 shows an example of the processing flow of the report module 302 of the endpoint task robot 30. Figure 5 shows an example of the deletion process of completed work tasks in the endpoint task robot 30 in conjunction with the report module 302. Figure 6 shows an example of the processing flow of the connection check module 303 in the endpoint task robot 30. Figure 7 summarizes the overall processing flow of the process operating system 100 of this embodiment.

Claims

1. A process operating system, comprising: A single service, running by integrating containerization technology; A workflow operation platform stores received work tasks into the task queue of this queue service; And an endpoint task robot, having a connection module, performs the following operations: completing a queue connection with the queue service by obtaining the connection management information pre-generated by the queue service; obtaining a target task through the queue channel according to the preset permission distinction; and checking the queue connection and the queue channel before establishing a connection with the queue service, and establishing a connection according to the connection management information if neither exists.

2. The process operating system as described in request item 1, wherein, The queue service is configured to use Kubernetes container technology in conjunction with RabbitMQ queue service.

3. The process operating system as described in request item 1, wherein, The endpoint task bot further includes a reporting module that performs the following operations: After completing the target task, the endpoint task bot reports to the process operating system via an event bus architecture; and after confirmation, the process operating system notifies the endpoint task bot to delete the target task from the queue service via the queue service.

4. The process operating system as described in request item 3, wherein, The endpoint task robot further includes a connection check module; after the endpoint task robot is enabled, the connection check module performs connection checks at predetermined intervals; when it is determined that the connection between the endpoint task robot and the queue service is interrupted, the connection check module re-establishes the connection during the next check; when the endpoint task robot is enabled for the first time, the connection check module does not perform queue connection checks; and when the endpoint task robot is performing a task, the connection check module does not perform queue connection checks.

5. The process operating system as described in request item 1, wherein, The endpoint task robot further includes a notification module; the notification module obtains the number of tasks to be executed by the endpoint task robot, and sends a notification when the number of tasks reaches the upper limit; and the notification module sends heartbeat information to the process operation platform at a predetermined time. If the process operation platform finds that the endpoint task robot has not sent the heartbeat information for more than the predetermined time, it issues a warning.

6. The process operating system as described in claim 3 further includes a process control platform for receiving operation information, extracting a task from the operation information through a semantic analysis method, and issuing it as the work task; wherein, The process control platform receives the report from the endpoint task robot and, upon confirmation, notifies the endpoint task robot to remove the target task from the task queue.

7. A process operation method, comprising: Use a series of services integrated through containerization technology; Receive work tasks through a workflow platform and store them in the task queue of the queue service; And through an endpoint task robot with a connection module, perform the following operations: by obtaining the connection management information pre-generated by the queue service, complete the connection between the endpoint task robot and the task queue of the queue service; according to the preset permission distinction of the endpoint task robot, further connect to the corresponding channel in the task queue to obtain a target work task; and before the endpoint task robot establishes a connection with the queue service, check the connection between the task queue and the channel, and if neither exists, connect according to the connection management information.

8. The process operation method as described in request item 7, wherein, Through a reporting module of the endpoint task bot, the following operations are performed: the endpoint task bot reports after completing the target task via an event bus architecture; and the endpoint task bot receives a notification from the queue service, causing it to remove the target task from the task queue.

9. The process operation method as described in request item 8, wherein, After the endpoint task robot is enabled, a connection check module of the endpoint task robot performs a connection check at predetermined intervals. When it is determined that the connection between the endpoint task robot and the queue service is interrupted, the connection check module will rebuild the connection during the next check. When the endpoint task robot is enabled for the first time, the connection check module does not perform a connection check. And when the endpoint task robot is performing a work task, the connection check module does not perform a connection check.

10. The process operating system as described in request item 7, wherein, The endpoint task robot's notification module obtains the number of tasks to be executed by the endpoint task robot and issues a notification when the number of tasks reaches the upper limit; the notification module also sends heartbeat information to the process operation platform at predetermined intervals, and issues a warning if the process operation platform finds that the endpoint task robot has not sent the heartbeat information for more than the predetermined time.

Images