Process operating system and process operating method
Patent Information
- Application Number
- CN202510528142.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Priority Date
- 2025-04-11
- Filing Date
- 2025-04-25
- Publication Date
- 2026-10-20
AI Technical Summary
[0008]为了解决前述的问题,本发明提出的流程操作系统以及方法,将服务建置流程拆分为五大模块管控,五个模块分别为:队列服务(搭配容器技术)、联机模块、回报模块、联机检查模块及通知模块,通过各模块之间的交互作用,以自动化完成各项企业日常繁琐又极为重要的维运流程。
Smart Images

Figure FT_1 
Figure FT_2 
Figure FT_3
Abstract
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. Background Technology
[0002] In recent years, with the significant improvement in hardware computing power, machine learning algorithms have also enhanced their ability to recognize speech and images. Coupled with the successful training of neural networks, this has opened up endless possibilities for artificial intelligence applications. Enterprises have also invested a lot of manpower and resources in the field of artificial intelligence technology. For example, they are developing robotic process automation (RPA) with artificial intelligence to complete daily tasks that were previously performed manually.
[0003] Traditional Robotic Process Automation (RPA) systems can be broadly divided into four main components to complete assigned tasks. These four components include: an AI platform, an RPA platform, endpoint task robots, and a message 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 message 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 rely on an independent orchestrator to assign tasks to endpoint robots. Therefore, a well-equipped orchestrator is essential. Furthermore, for high availability, practical experience suggests having more than one orchestrator to provide backup and assign tasks to idle endpoint robots. This requires platform administrators to invest additional manpower and time in environment setup, resulting in higher initial costs.
[0005] Based on practical experience in enterprises, different departments or units 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 the online schedule to be delayed when the management personnel are busy.
[0006] Enterprises must respond immediately to the demands of rapid change, often facing sudden surges in tasks that urgently need to be executed. Traditional robotic process automation systems require services to be installed on endpoint task robots, and subsequent task assignments 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 (RoLA) systems often use distributed message queues (DMQs) as their queuing service. This architecture employs a publish-subscribe mechanism to divide information into multiple equal parts, thereby increasing throughput. However, distributed message queues, due to the addition of an intermediary server (broker), must address the issues of information loss and duplicate message reception. If these problems arise due to connectivity issues, they can cause significant losses to enterprises. Summary of the Invention
[0008] To address the aforementioned issues, the process operating system and method proposed in this invention break down the service construction process into five modules for management: queue service (with container technology), online module, reporting module, online check module, and notification module. Through the interaction between these modules, various tedious yet crucial daily maintenance processes for enterprises can be automated.
[0009] Embodiments of the present invention provide 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 an online module and performs the following operations: establishing a connection with the queue service's queue by obtaining pre-generated online management information; obtaining a target work task through a queue channel based on default permission settings; and checking the queue connection and queue channel before establishing a connection with the queue service, and if neither exists, establishing a connection based on the online management information.
[0010] In an embodiment of the present invention, the queue service is configured to use Kubernetes container technology in conjunction with RabbitMQ queue service.
[0011] In an embodiment of the present invention, the endpoint task robot further includes a reporting module that performs the following operations: after completing the target task, the endpoint task robot reports to the process operating system via an event bus architecture; and after confirmation, the process operating system notifies the endpoint task robot to delete the target task from the queue service via the queue service.
[0012] In an 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 rebuilds the connection again 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 an embodiment of the present invention, 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 issues a notification when the number of tasks reaches the upper limit; the notification module 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.
[0014] Another embodiment of the present invention provides a process operation method, including: using a queue service integrated with containerization technology; receiving work tasks through a process operation platform and storing them in the task queue of the queue service; and performing the following operations through an endpoint task robot with an online module: completing the queue connection between the endpoint task robot and the queue service by obtaining online management information pre-generated by the queue service; obtaining a target work task through a queue channel according to the default 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 online management information. Attached Figure Description
[0015] Figure 1 This is a schematic diagram of a process operating system 100 illustrated in accordance with an embodiment of the present invention.
[0016] Figure 2 show Figure 1 A schematic diagram of the configuration of the endpoint task robot 30.
[0017] Figure 3 This is an example of the processing flow of the online module 301 of the endpoint task robot 30.
[0018] Figure 4 This is an example of the processing flow of the reporting module 302 of the endpoint task robot 30.
[0019] Figure 5 This demonstrates an example of the deletion process for completed tasks in the endpoint task robot 30, which is paired with the reporting module 302.
[0020] Figure 6 This example shows the processing flow of the online inspection module 303 in the endpoint task robot 30.
[0021] Figure 7 The summary shows the overall processing flow of the operating system 100 in this embodiment.
[0022] [Symbol Explanation]
[0023] 100: Process Operating System
[0024] 10: Process Control Platform
[0025] 20: Process Operation Platform
[0026] 30: Endpoint Task Bot
[0027] 40: Queue Service
[0028] 301: Online module
[0029] 302: Rewards Module
[0030] 303: Online Inspection Module
[0031] 304: Notification Module
[0032] S31~S39: Steps
[0033] S41~S48: Steps
[0034] S51~S54: Steps
[0035] S61~S64: Steps
[0036] S71~S83: Steps Detailed Implementation
[0037] 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 scope of the invention must be understood by referring to the claims below.
[0038] 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, operation processes, components and / or components, but do not preclude the addition of more technical features, values, method steps, operation processes, components, components, or any combination thereof.
[0039] The use of terms such as "first," "second," and "third" in the claims to modify components in the claims is not intended to indicate a priority order, a prior relationship, or that one component precedes another, or the chronological order of the execution of method steps; it is only used to distinguish components with the same name.
[0040] Please refer to Figure 1 , Figure 1 This is a schematic diagram of a process operating system 100 according to an embodiment of the present invention. In the embodiment, as... Figure 1 As shown, 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.
[0041] In this embodiment, the process control platform 10 can be implemented using a server, a laptop computer, or a desktop computer. In this embodiment, the process operation platform 20 can be implemented using a laptop computer, a desktop computer, or a virtual machine. In this embodiment, the process operation platform 20 has Robotic Process Automation (RPA) functionality.
[0042] In this embodiment, the endpoint task robot 30 can be implemented by a laptop computer, a desktop computer, or a virtual machine. In this embodiment, a physical machine (e.g., a server) or a virtual machine (e.g., a virtual machine installed on a server) can both serve as the endpoint task robot 30.
[0043] In the embodiments, 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.
[0044] In this embodiment, the process control platform 10 includes a storage device, which may be implemented using a read-only memory, flash memory, floppy disk, hard disk, optical disk, USB flash drive, magnetic tape, a database accessible via a network, or other storage media with the same function that can be easily conceived by those skilled in the art.
[0045] In this 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 implemented by opening a webpage, application, or scheduling an action to initiate a task through a user device (e.g., a mobile phone, laptop, or desktop computer), such as generating an email to transmit task information.
[0046] In this embodiment, the process control platform 10 receives an email and retrieves a document from it. The process control platform 10 then extracts the task from the document. In this embodiment, the document is, for example, an Excel document. This Excel document, 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 document is then attached to an email and sent to the process control platform 10. Upon receiving the email, the process control platform 10 automatically detects the attached document, for example, by recognizing the content of the email (including attachment fields) or by recognizing the icons of various fields in the email. It then downloads or opens the document, captures the task (e.g., a purchasing task) from the operation information using known semantic analysis methods, and publishes it as a work task.
[0047] 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 capture information and issue work tasks.
[0048] In this embodiment, the queue service 40 employs container technology in conjunction with a container resource scheduling platform to provide the necessary queue services and to offer information such as endpoints, accounts, and passwords required for information exchange in subsequent processes. Here, the queue service 40 in this embodiment is constructed by integrating RabbitMQ queue service with container technology. RabbitMQ is chosen for the queue service 40 in this embodiment because it supports many communication protocols, has comprehensive functionality, and offers good performance, making it more suitable for enterprise-level development.
[0049] 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 or virtual hosts. Furthermore, deploying services using the same application ensures consistent service specifications and makes it easier to scale and manage. The container technology used in this embodiment, for example but not limited to, is the Kubernetes container resource scheduling platform. Because it can automatically detect and manage the status of each container, it can immediately perform automatic scaling or deletion and reconstruction of containers in case of insufficient resources or abnormal situations, ensuring uninterrupted service operation and reducing the burden on administrators.
[0050] In this 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.
[0051] In the embodiments, such as Figure 2As shown, 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 actions are described below in sequence.
[0052] [Online Module]
[0053] 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 Active Directory (AD) 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 to 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 information, while the connection refers to the actual network connection between the RabbitMQ client (endpoint task robot 30) and the RabbitMQ server (queue service 40).
[0054] Because sharing a single queue channel is prone to errors, this embodiment differentiates the permissions of 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 endpoint robot 30 are determined 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 endpoint task robots (digital employees) are also set independently, facilitating monitoring and management, and further enhancing security.
[0055] Before each connection, the endpoint task robot 30 must check the connection queue and channel again. If neither exists, the connection can be established according to the predefined connection management information. If they exist, to ensure the uniqueness of the connection, the connection and channel must be deleted sequentially to avoid multiple queues connecting, which could cause the endpoint robot to fail to execute multiple tasks simultaneously.
[0056] Figure 3This section presents an example of the processing flow of the connection module 301 of the endpoint task robot 30. First, the connection module 301 checks if the connection management information exists (step S31). If it does not exist (step S31: No), for example but not limited to, it notifies the process operating system 100 to set the connection management information (step S32) and proceeds to step S33 to determine if the queue connection exists. If the connection management information already exists (step S31: Yes), it checks if the queue connection exists (step S33). If the queue connection already exists (step S33: Yes), that is, the connection is open, it deletes the queue connection (step S34) and proceeds to step S35. If the queue connection does not exist (step S33: No), it proceeds to step S36.
[0057] 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.
[0058] In step S35, the online module 301 checks whether the queue channel exists. If it exists (step S35: Yes), the queue channel is deleted (step S38). If the queue channel does not exist (step S35: No), the queue channel is created (step S39).
[0059] Endpoint task robot 30 (digital employee) can further, for example but not limited to, configure a QoS (Quality of Service) mechanism in the connection module 301. The QoS mechanism ensures that a connection retrieves only one piece of information at a time, and that information cannot be retrieved by other endpoint task robots before the endpoint task robot replies with confirmation. Therefore, it ensures that a task is executed by only one endpoint task robot from beginning to end. It should be noted that if this task fails to receive a reply 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 after a period of time for delivery to other endpoint robots. This allows other idle digital employees to take over in the event of an anomaly, providing greater operational flexibility.
[0060] [Rewards Module]
[0061] 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 reporting module 302. The process control platform 10 will then report the execution records to the user. After the process control platform 10 finally confirms, it will notify the endpoint task robot 30 to delete the completed work tasks from the queue service.
[0062] The stable operation of endpoint task robots 30 relies on queue service 40 for information exchange. The feedback module 302 in this embodiment focuses on the correctness and availability of information sent to queue service 40. While APIs (Application Programming Interfaces) are fast and have feedback mechanisms, a large number of endpoint task robots 30 (digital employees) can lead to excessive API calls, causing congestion and delays. Therefore, in this embodiment, the feedback module 302 employs an asynchronous queue processing mechanism and incorporates the MassTransit framework. The MassTransit framework supports various information exchange services, providing powerful and complete information models, including publish / subscribe, Saga, and eventual consistency support, along with necessary solutions for inter-endpoint communication, such as exception handling, retry mechanisms, and lifecycle management. Using this framework reduces the complexity of information exchange applications.
[0063] Figure 4 This is an example of the processing flow of the reporting module 302 of the endpoint task robot 30.
[0064] An event bus is an architecture used to pass information 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. Because of this decoupling capability, event senders and receivers only need to rely on the event's identifier or content to interact.
[0065] The reporting module 302 of the endpoint task robot 30 can use an event bus to transmit information or events. In this embodiment, the endpoint task robot 30, for the work task it performs, will report to the process control platform 10 (artificial intelligence platform) via the event bus whether the work task has been successfully completed (step S41). 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 upper 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 upper limit (step S42: Yes), it indicates that the reporting via the event bus has failed (step S44), and then it reports whether it was successful via the API (step S45).
[0066] 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).
[0067] After the endpoint task robot 30 (digital employee) completes its work task and reports its completion, it must wait for a response from the process control platform 10 (artificial intelligence platform) confirming receipt of the report. This allows for data synchronization and facilitates subsequent notification processing, error tracking, and statistical analysis. Once the endpoint task robot 30 receives the task completion notification from the process control platform 10 via the queue service 40, it must connect to the queue service 40 to remove the completed task, ensuring it is not 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. In this case, the deletion operation is not repeated; instead, the connection is re-established using the connection module 301 to prevent the endpoint task robot from stalling and causing delays in task execution.
[0068] Figure 5 This demonstrates an example of the deletion process for completed tasks in the endpoint task robot 30, using the reporting module 302. The process control platform 10 notifies the endpoint task robot 30 via the queue service 40 to delete the completed tasks. 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 attempts has reached the maximum. If not (Step S52: No), it waits for a predetermined time, such as 5 seconds, and then retrys (Step S53). If the number of retry attempts has reached the maximum (Step S52: Yes), the connection module 301 is activated to retrieve the task to be executed again (Step S54).
[0069] [Online Inspection Module]
[0070] In this embodiment, the endpoint task robot 30 online inspection module 303 is used to provide a proper inspection mechanism and to activate the online module 301 at an appropriate time when the online connection is interrupted.
[0071] 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 connection status of the queue. 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. This will lead to new work tasks being acquired and executed, which can cause 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 and reconnected during the next check (after 3 minutes) or during the action of the reporting module 302.
[0072] Figure 6 This example illustrates the processing flow of the connection check module 303 in the endpoint task robot 30. In this embodiment, after the endpoint task robot 30 is enabled, the connection check module performs queue connection checks at predetermined intervals, such as 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 check 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 further confirms whether the endpoint task robot 30 is currently 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. However, if the endpoint task robot 30 is not performing a work task (step S62: No), the connection check module 303 detects whether there are any abnormalities in the queue connection or queue channel (step S63). If an anomaly is detected (step S63: Yes), then the connection module 301 is enabled to establish a connection (step S64); otherwise, the connection check can be terminated.
[0073] [Notification Module]
[0074] In this embodiment, the process operating system 100 uses a mechanism to establish a flow distribution by differentiating endpoint task robots 30 (digital employees) based on permissions in the queue service 40. The number of queue endpoints corresponding to each endpoint task robot is the number of tasks that digital employee is currently waiting to execute.
[0075] The upper limit of the queue endpoint information quantity (the number of tasks pending execution by endpoint task robot 30) can be flexibly adjusted according to the needs of the digital employee's management personnel. Endpoint task robot 30 periodically checks the queue endpoint information quantity with queue service 40. When the upper limit is reached, notification module 304 sends a notification to process operating system 100 or relevant management personnel. This alerts management personnel that there are too many tasks pending execution and more resources may be needed to process them.
[0076] Once the endpoint task robot 30 (digital employee) is enabled, it will send a heartbeat message containing the currently executing task, version, and time to the queue service 40 every fifteen minutes, for example, but not limited to. The process operation platform 20 (RPA platform) has continuously executing services or routines that constantly monitor the queue service 40 and write the received information to the database. If the process operation platform 20 (RPA platform) detects that any digital employee has not responded to the heartbeat message within the specified time, it will notify the relevant administrators via email, reminding them to check or restart the digital employee.
[0077] [Process Operating System]
[0078] Figure 7 The summary shows the overall processing flow of the endpoint task robot 30's online module 301, online check module 302, reporting module 303, and notification module 304, and the queue service 40 in the process operating system 100 of this embodiment.
[0079] In step S71, endpoint robot 30 is activated and connects for the first time via connection module 301. In step S72, 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. Then, 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 no connection check is performed (step S76). If connection check module 302 confirms that endpoint task robot 30 is not performing a work task (step S75: No) and finds that the connection is not normal, then connection module 301 clears the old connection and re-establishes the connection with queue service 40 (step S77).
[0080] 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).
[0081] In step S80, the endpoint task robot 30 periodically checks the queue endpoint information quantity (number of pending work tasks) with the queue service 40, for example, through the notification module 303, and the queue service then sends back the queue endpoint information quantity (step: S81). When it exceeds the upper limit (step: S82), the notification module 304 issues a notification or warning (step: S83).
[0082] The biggest difference between the process operating system and method of this invention and traditional technologies lies in the way work tasks are obtained: from bottom to top, idle endpoint task robots connect with the task queue service and obtain work tasks. However, traditional technologies all use an independent orchestrator to assign tasks to endpoint task robots.
[0083] 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 selects a suitable queue service, which features asynchronous communication and a decoupled architecture. Asynchronous communication allows users to send tasks and endpoint task robots to execute asynchronously; the decoupled architecture allows for independent partitioning of queues, ensuring that when an endpoint in one queue malfunctions and needs to be removed and rebuilt, other queue endpoints are not affected, thus contributing to system stability and maintainability.
[0084] 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 bot incorporates robust error handling and retry mechanisms, ensuring that any abnormalities in task acquisition or connection processes are appropriately addressed to restore normal operation. The process operating system and method of this invention utilize a monitoring / alert mechanism to notify relevant managers when the endpoint task bot fails to respond within a predetermined time or when the number of task queues exceeds the default limit. This approach better aligns with enterprise operational practices, ensuring efficient workload management and meeting the processing needs of work tasks.
[0085] Although the present invention has been disclosed above with reference to 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.
Claims
1. A process operating system, comprising: The queue service runs using containerization technology. The workflow operation platform stores the received work tasks into the task queue of the queue service. as well as Endpoint task robot, with online module, performs the following operations: By obtaining the online management information pre-generated by the queue service, the queue connection with the queue service is completed; Based on default permission settings, the target task is obtained through a queue channel; and Before establishing a connection with the queue service, check the queue connection and the queue channel. If neither exists, establish a connection based on the connection management information.
2. The process operating system as described in claim 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 claim 1, wherein, The endpoint task bot also includes a reporting module that performs the following operations: Through an event bus architecture, after completing the target task, the endpoint task robot reports back to the process operating system; and After confirmation, the process operating system notifies the endpoint task robot through the queue service to delete the target task from the queue service.
4. The process operating system as described in claim 3, wherein, The endpoint task robot also includes an online inspection module; After the endpoint task robot is enabled, the online inspection module performs online inspections 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 again during the next check. When the endpoint task robot is being used for the first time, the connection check module does not perform the queue connection check; and When the endpoint task robot is performing a work task, the online inspection module does not perform the queue online inspection.
5. The process operating system as described in claim 1, wherein, The endpoint task robot also includes a notification module; The notification module obtains the number of pending tasks for 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 predetermined intervals. 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, capturing the tasks in the operation information through semantic analysis methods, and publishing them as the work tasks; in, The process control platform receives the report from the endpoint task robot and, upon confirmation, notifies the endpoint task robot to delete the target work task from the task queue.
7. A process operation method, comprising: Use queue services integrated with containerization technology; The system receives work tasks through the process operation platform and stores them in the task queue of the queue service. as well as Perform the following operations using an endpoint task robot with an online module: By obtaining the online management information pre-generated by the queue service, the connection between the endpoint task robot and the task queue of the queue service is completed; Based on the default permission settings of the endpoint task robot, it further connects to the corresponding channel in the task queue to obtain the target work task; and Before the endpoint task robot establishes a connection with the queue service, it checks the connection between the task queue and the channel. If neither exists, it establishes a connection according to the connection management information.
8. The process operation method as described in claim 7, wherein, The following operations are performed via the return module of the endpoint task robot: Through an event bus architecture, the endpoint task robot reports back after completing the target task; and Upon receiving a notification from the queue service, the endpoint task robot removes the target task from the task queue.
9. The process operation method as described in claim 8, wherein, After the endpoint task robot is enabled, the online check module of the endpoint task robot performs an online 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 again during the next check. When the endpoint task robot is being used 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 online inspection module does not perform an online inspection.
10. The process operating system as described in claim 7, wherein, The notification module of the endpoint task robot 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; as well as The notification module sends heartbeat information to the process operation platform at predetermined intervals. 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.