Automated control method based on data injection and event driving and related products

Abstract

The application provides an automatic control method based on data injection and event driving and related products, wherein the method comprises: listening to the connection request of an external client through a TCP server, and establishing a data transmission channel with the target client; executing the operation steps in the preset automatic process, and when the target step associated with the data injection requirement is executed, calling the target script associated with the target step to suspend the current automatic execution thread to release system resources; when the input data from the target client is received through the TCP server, the suspended target script is awakened to identify the data type of the input data to identify the business data; the target script is exited and the subsequent operation steps are continued to be executed to execute corresponding operations on the target application software according to the business data, realize cross-device automatic control, improve the convenience of external data injection, and reduce resource occupation in the data waiting process to reduce resource waste.

Description

Technical Field

[0001] This application relates to the field of automation control technology, and in particular to an automation control method and related products based on data injection and event-driven approaches. Background Technology

[0002] Automation control refers to a control method that automatically executes repetitive tasks in industrial or business scenarios through pre-recorded or programmed operation sequences. As enterprises become increasingly information-driven, more and more business processes rely on automation technology to complete.

[0003] Existing automated process control is typically implemented using RPA (Robotic Process Automation) tools or script automation tools. However, RPA or script automation tools can usually only execute fixed processes according to preset input data. When it is necessary to receive real-time data from external devices to execute cross-device automated tasks, such as tasks that require real-time data from external devices such as barcode scanners, programmable logic controllers (PLCs), host computers, or automated testing platforms, RPA or script automation tools struggle to inject external data. They usually need to develop dedicated application programming interfaces (APIs) or use intermediate files for data exchange, resulting in high system coupling, long development cycles, and the process of waiting for external data injection often involves polling to check the arrival of data, which can easily lead to system resource idleness and waste. Summary of the Invention

[0004] This application provides an automated control method and related products based on data injection and event-driven approaches to solve the problems of difficulty in injecting external data and resource waste while waiting for data in existing automated process control schemes.

[0005] In a first aspect, embodiments of this application provide an automated control method based on data injection and event-driven mechanisms, comprising: The TCP server listens for connection requests from external clients and establishes a data transmission channel with the target client to transmit data when a connection request is detected. The system executes the pre-defined automated process steps, and when it reaches the target step associated with the data injection requirement, it calls the target script associated with the target step to suspend the current automated execution thread, causing the target script to enter a suspended waiting state in order to release system resources. When the TCP server receives input data from the target client, it wakes up the target script that is in a suspended waiting state, so that the awakened target script can identify the data type of the input data in order to identify the business data. Exit the target script and continue with subsequent operation steps to perform corresponding operations on the target application software based on business data, and return the operation results to the target client through the TCP server to achieve cross-device automated control.

[0006] In one embodiment, invoking the target script associated with the target step to suspend the current automated execution thread, causing the target script to enter a suspended waiting state, includes: The target script associated with the target step is invoked to suspend the current automated execution thread by calling the asynchronous event waiting interface, causing the target script to enter a suspended waiting state and send a ready status signal to the target client; the ready status signal is used to notify the target client to send input data.

[0007] In one embodiment, when input data is received from the target client via the TCP server, the target script, which is in a suspended waiting state, is awakened. The awakened target script then performs data type identification on the input data to identify business data, including: When input data is received from the target client via the TCP server, the input data is written to the input data shared variable, and the asynchronous event notification interface is called to wake up the target script that is in a suspended waiting state. After the target script is woken up, it reads the input data from the input data shared variable and performs data type identification. When the input data is identified as business data, the business data is stored in the business data shared variable. When the input data is identified as a control command, the corresponding control processing logic is executed according to the control command.

[0008] In one embodiment, the process of the target script identifying the data type of the input data includes: When the header of the input data is a preset command prefix character, the input data is determined to be a control command; If the header of the input data is not a preset command prefix character, the input data is determined to be business data.

[0009] In one embodiment, performing corresponding operations on the target application software based on business data includes: Read business data from shared business data variables; Enter business data into the input boxes or table cells of the target application software; or, perform a query operation in the target application software based on the business data.

[0010] In one embodiment, the control commands include an exit command, a status query command, and a test command; when input data is identified as a control command, the corresponding control processing logic is executed according to the control command, including: When the control command is an exit command, the automation process is terminated; When the control command is a status query command or a test command, the corresponding information is returned to the target client through the TCP sending interface, and the asynchronous event waiting interface is called to continue waiting.

[0011] In one embodiment, the asynchronous event wait interface is implemented based on an asynchronous event object; when the asynchronous event wait interface is called, the event flag of the asynchronous event object is cleared and the current automated execution thread is suspended; When calling the asynchronous event notification interface, the event flag of the asynchronous event object is set and the thread corresponding to the suspended target script is woken up.

[0012] In one embodiment, the message routing modes supported by the TCP server include automatic processing mode and custom processor mode; before writing the input data into a preset input data shared variable, the method further includes: Determine the message routing mode currently used by the TCP server; When the TCP server is currently in automatic processing mode, it writes the input data into a preset input data shared variable and calls the asynchronous event notification interface to wake up the target script that is in a suspended waiting state to process the input data. When the TCP server is currently using the custom processor mode, the input data is forwarded to the pre-configured message processor for input data processing.

[0013] In one embodiment, the TCP server supports data receiving modes including text mode and binary mode; input data received from the target client via the TCP server includes: When the TCP server's current data receiving mode is text mode, it decodes the byte stream from the target client into a text string according to text encoding to obtain the input data; When the TCP server is currently in binary mode, it parses the binary data packets from the target client according to the preset binary data packet structure to obtain the input data.

[0014] In one embodiment, performing the operation steps in a preset automated process includes: Load the JSON configuration file corresponding to the pre-stored automated process and parse the JSON objects in the JSON configuration file. Each JSON object corresponds to an operation step in the preset automated process. The JSON object corresponding to the operation step includes at least a step type field, a coordinate field, and a window identifier field. Based on the step type field, coordinate field, and window identifier field in the JSON object, execute the corresponding operation steps, and when the target script association field is read from the JSON object, determine that the corresponding operation step is the target step associated with the target script.

[0015] In one embodiment, the JSON object corresponding to the target step also includes a call timing field for the target script, wherein calling the target script associated with the target step includes: Based on the target script's invocation timing field, determine when the target script is invoked. Invocation timing includes invoking before or after the target step is executed. Depending on the timing of the invocation, either before or after the execution of the target step, the target script associated with the target step is invoked based on the fields associated with the target script.

[0016] In one embodiment, when performing subsequent operation steps, the fields in the JSON object corresponding to the current operation step are detected; When the JSON object corresponding to the current operation step is detected to contain a jump target field pointing to the target step, after the current operation step is completed, the user jumps back to the target step according to the jump target field to re-execute the target step and the corresponding target script, and enters the next round of waiting.

[0017] In one embodiment, during the execution of operation steps in a preset automated process, the target script reuses resource instances across loops through a context variable pool; the resource instances are stored in the context variable pool when the target script is first created, and cleanup handles for destroying resource instances are registered to a unified cleanup list; the resource instances include one or more of the following: browser driver instances, COM object instances, network connection instances, database connection instances, and HTTP session instances; In subsequent execution loops, the target script is awakened and retrieves and reuses existing resource instances from the context variable pool.

[0018] In one embodiment, before reusing an existing resource instance, the target script is further configured to: Perform a health check on the resource instance. If the health check fails, destroy the resource instance and create a new resource instance to replace it.

[0019] In one embodiment, the cleanup handle is an asynchronous coroutine function, and the same resource is prevented from being registered repeatedly by a registration status flag during registration; at the end of the preset automated process, the executor traverses the cleanup list in reverse order in the end code block and executes each cleanup handle in an independent exception catching domain; The cleanup handle is associated with a timeout period; if the execution time of the cleanup handle exceeds the associated timeout period, the cleanup handle will be forcibly terminated and the next cleanup handle will continue to be executed.

[0020] Secondly, embodiments of this application provide an automated control system based on data injection and event-driven mechanisms, including a controller comprising: The TCP server module is used to listen for connection requests from external clients and, upon receiving a connection request, establish a data transmission channel with the target client to transmit data. The process execution engine module is used to execute the operation steps in the preset automated process. When it executes the target step associated with the data injection requirement, it calls the target script associated with the target step to suspend the current automated execution thread, so that the target script enters a suspended waiting state to release system resources. When the TCP server receives input data from the target client, it wakes up the target script that is in a suspended waiting state, so that the awakened target script can identify the data type of the input data in order to identify the business data. The process execution engine module is also used to exit the target script and continue to execute subsequent operation steps, so as to perform corresponding operations on the target application software based on business data, and return the operation results to the target client through the TCP server, so as to realize cross-device automated control.

[0021] Thirdly, embodiments of this application provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described method.

[0022] Fourthly, embodiments of this application provide a readable storage medium storing a computer program that, when executed by a processor, implements the steps of the above-described method.

[0023] Fifthly, embodiments of this application provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the above-described method.

[0024] In one solution provided by the aforementioned automated control method and related products based on data injection and event-driven mechanisms, a TCP server is set up to listen for connection requests from external clients and establish a data transmission channel between the target client and the automated control system. This allows external devices to actively inject the required data into the automated process, achieving cross-device data interaction. Simultaneously, during the execution of the automated process, when the execution reaches the target step associated with the data injection requirement, the corresponding target script is invoked to suspend the current automated execution thread into a suspended waiting state. This allows the automated execution thread to pause execution and release occupied system resources while waiting for input data, avoiding resource waste caused by looping or continuous thread occupation. Upon receiving input data from the target client, the input data is transmitted to the target script via the TCP server, waking up the suspended target script for data processing. This ensures that external input data can promptly drive the automated process to continue execution. Furthermore, in subsequent operation steps, corresponding control operations are performed on the target application software based on the business data identified by the target script, achieving data linkage between the automated process and external devices. This improves the convenience of external data injection and reduces resource occupation during data waiting, thus minimizing resource waste. Attached Figure Description

[0025] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments of this application will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a schematic diagram of the structure of an automated control system based on data injection and event-driven operation in one embodiment of this application; Figure 2 yes Figure 1 A schematic diagram of the structure of an automated control system and its controller; Figure 3 This is a flowchart illustrating an automated control method based on data injection and event-driven approaches in one embodiment of this application. Figure 4 This is a schematic diagram of the asynchronous waiting and waking-up timing of the target script in one embodiment of this application; Figure 5 This is a schematic diagram of the target script execution data type identification and corresponding processing flow in one embodiment of this application; Figure 6 This is a schematic diagram of the data reception and parsing process of a TCP server in one embodiment of this application; Figure 7 This is a schematic diagram of the structure of a computer device according to one embodiment of this application. Detailed Implementation

[0027] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0028] It should be understood that, when used in this specification and the appended claims, the term "comprising" indicates the presence of a described feature, integral, step, operation, element, and / or component, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or collections thereof. It should also be understood that, as used in this specification and the appended claims, the term "and / or" refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0029] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0030] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0031] It should be understood that the sequence number of each step in the following embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0032] To illustrate the technical solution of this application, specific embodiments are described below.

[0033] Currently, automated control solutions mainly suffer from the following problems: 1. Difficulty in data interaction between automated processes and external devices. RPA tools or script automation tools can only execute fixed processes according to preset input data. During task execution, when it is necessary to receive real-time data from external devices such as barcode scanners, PLCs, host computers, and automated testing platforms, it is usually necessary to develop dedicated API interfaces or use intermediate files for data exchange, resulting in high system coupling and long development cycles. Moreover, for legacy systems that do not support API calls, external data injection is almost impossible.

[0034] 2. Resource waste occurs when automated processes wait for external data. In scenarios requiring external data input, a polling approach is typically used, which involves repeatedly checking for data arrival. However, too short a polling interval leads to CPU idling and resource waste, while too long an interval results in response delays, failing to meet the real-time requirements of industrial scenarios. Some solutions employ multi-threaded blocking waiting, but thread blocking consumes system resources and can easily lead to deadlocks or resource exhaustion in multi-process concurrent scenarios.

[0035] 3. Inability to distinguish between control commands and business data during external data injection. Existing automation systems typically treat all external inputs as data content, failing to differentiate between commands controlling system behavior and business data to be written into the target software. For example, when an external system sends " / exit", the system cannot recognize it as an exit command and terminates the process directly; when "TPK2500001" is sent, the system cannot inject it as business data into subsequent steps. This problem of "data and control commands being mixed up" limits the remote control capabilities of external systems over automated processes.

[0036] 4. High integration costs when working collaboratively across applications. Enterprises typically have multiple business systems from different periods and with different technical architectures, such as WPS office software, enterprise resource planning systems (ERP systems), manufacturing execution systems (MES systems), and web applications. These systems often do not have open API interfaces, and achieving data collaboration between these systems requires developing a large amount of adaptation code or deploying expensive enterprise service bus (ESB) middleware, which has high technical barriers and high maintenance costs.

[0037] 5. Heavyweight resources are repeatedly created and destroyed during large-scale, loop-based processing. In scenarios requiring the looping processing of large amounts of data, such as batch querying 1000 serial numbers (SN), existing solutions require restarting the browser (WebDriver), re-establishing the serial communication port (COM) connection to WPS / Excel, and re-establishing the TCP connection for each loop. Taking Selenium Web Driver as an example, each Chrome browser startup takes 3-5 seconds and consumes approximately 200MB of memory. Looping 1000 times consumes nearly 5000 seconds (approximately 1.4 hours) just for browser startup time, and frequent starts and stops can easily lead to memory leaks. While existing RPA tools support variable passing, they do not provide an automatic cross-loop reuse mechanism for heavyweight resources, resulting in a disconnect between resource lifecycles and the automation process lifecycle.

[0038] It is evident that existing automation control schemes have significant shortcomings in areas such as real-time external data injection, cross-application collaborative integration, and resource utilization efficiency. Therefore, this application provides an automation control method, system, medium, and program product based on data injection and event-driven mechanisms to address the problems of difficulty in external data injection, resource waste while waiting for data, inability to distinguish between instructions and data, high cross-application integration costs, and performance waste caused by the repeated creation and destruction of heavyweight resources in large-scale cyclic processing.

[0039] The automated control method based on data injection and event-driven mechanisms provided in this application can be applied to applications such as... Figure 1 The data injection and event-driven automated control system (hereinafter referred to as the system) shown includes an external client (i.e., the client of the external device) and a controller. The external client communicates with the controller through a network or bus to realize the execution and control of the automated process.

[0040] In practical applications, when the controller has the need to execute automated processes, it first starts the TCP (Transmission Control Protocol) server. The TCP server listens for connection requests from external clients, and when a connection request is detected, it establishes a data transmission channel with the target client to transmit data.

[0041] While listening on the TCP server, the controller also synchronously executes the operation steps in the preset automated process. When it reaches the target step associated with the data injection requirement, it calls the target script associated with the target step to suspend the current automated execution thread, causing the target script to enter a suspended waiting state to release system resources and wait to receive input data from external clients. The target step associated with the data injection requirement can be a preset operation step that requires input data from an external client for processing, or it can be the previous step of a preset operation step.

[0042] When input data is received from the target client via the TCP server, the target script, which is in a suspended waiting state, is awakened. The input data is then provided to the target script, which identifies the data type of the input data to determine the business data. The target script then exits and continues to execute subsequent operation steps to perform corresponding operations on the target application software based on the business data. Finally, the operation results are returned to the target client via the TCP server, thus achieving automated control across devices.

[0043] In this embodiment, by setting up a TCP server to listen for connection requests from external clients and establishing a data transmission channel between the target client and the automated control system, external devices can actively inject the required data into the automated process, achieving cross-device data interaction. Simultaneously, during the execution of the automated process, when the execution reaches the target step associated with the data injection requirement, the corresponding target script is invoked to suspend the current automated execution thread into a suspended waiting state. This allows the automated execution thread to pause execution and release occupied system resources while waiting for input data, avoiding resource waste caused by looping or continuously occupying threads. Upon receiving input data from the target client, the TCP server transmits the input data to the target script and wakes up the suspended target script for data processing, ensuring that external input data can promptly drive the automated process to continue execution. Subsequently, in subsequent operation steps, corresponding control operations are performed on the target application software based on the business data identified by the target script, achieving data linkage between the automated process and external devices.

[0044] Therefore, this embodiment can improve the real-time performance and flexibility of external data injection, reduce resource consumption during the waiting process of automated processes, improve system resource utilization efficiency, and achieve efficient and stable control of automated processes across devices and application scenarios.

[0045] like Figure 2 As shown, the controller includes a TCP server module, a configuration storage module, a process execution engine module, a script management module, a shared variable storage module, a cross-application operation module, a window operation module, a context variable pool module, and a unified resource recycling module. The detailed descriptions of each functional module are as follows.

[0046] The TCP (Transmission Control Protocol) server module is used to listen for connection requests from external clients. When a connection request is detected, it establishes a data transmission channel with the target client to transmit data. It also parses the received TCP packets according to the configured data receiving mode (such as text mode or binary mode) to obtain input data and writes it into the input data shared variable of the shared variable storage module.

[0047] The configuration storage module (i.e., the JSON configuration storage module) is used to store the JSON configuration files corresponding to the preset automated processes. The JSON configuration file contains multiple JSON objects, and each JSON object includes at least a step type field, a coordinate field, and a window identifier field; some JSON objects also include a target script association field and a jump target field.

[0048] The script (such as Hook script) management module is used to manage one or more target scripts. Each target script contains at least the asynchronous event waiting interface (wait_for_event), the asynchronous event notification interface (notify_event), the TCP sending interface (send_tcp), the shared variable retrieval interface (get_variable), and the shared variable setting interface (set_variable).

[0049] The process execution engine module loads and parses JSON configuration files, executing each JSON object in the order of the parsed JSON list to perform the pre-defined steps in the automated process. When executing a target step associated with data injection requirements, it calls the target script associated with that step, suspending the current automated execution thread by calling an asynchronous event waiting interface, putting the target script into a suspended waiting state. When input data from the target client is received via the TCP server, the suspended target script is awakened via an asynchronous event notification interface. The awakened target script then identifies the data type of the input data, recognizing business data and control commands. Upon recognizing the business data, it stores it and exits the target script, then continues executing subsequent steps to perform corresponding operations on the target application software based on the business data. The operation results are then returned to the target client via the TCP server, achieving cross-device automated control.

[0050] The shared variable storage module is used to store data shared across steps, including input data stored by the TCP server and business data stored by the target script; the shared variable storage module includes input data shared variables and business data shared variables.

[0051] The context variable pool module is used to store data shared across loops and steps, including resource instances and a unified cleanup list (cleanup_handlers).

[0052] The window operation module is used to respond to controls during operation steps to perform click, input, scroll wheel, and other operations on the target window based on the coordinate field and window identifier field of the JSON object.

[0053] The cross-application operation module is used to respond to controls and write business data to the target application software during operation steps. This target application software includes, but is not limited to, WPS Office software, Excel spreadsheets, web pages, ERP clients, and MES system clients. The target application software and the external client are applications located on different devices.

[0054] The unified resource reclamation module is used to traverse and execute all cleanup handles in the cleanup list when the automated process ends, releasing all registered resources. The unified resource reclamation module may include a timeout protection submodule, which is used to forcibly terminate the cleanup handle when it times out and continue to execute the next handle.

[0055] The technical solution of this application embodiment has the following beneficial effects: This application's embodiments implement asynchronous data waiting with zero polling and zero blocking. By introducing asynchronous event waiting interfaces and asynchronous event notification interfaces, the automated execution thread actively suspends and releases system resources (such as CPU resources) while waiting for external data. The TCP server actively wakes it up when the data arrives, realizing an event-driven rather than polling-driven data waiting mechanism. This ensures millisecond-level real-time response while avoiding CPU idling waste.

[0056] This application embodiment realizes intelligent separation of control commands and business data. By setting command prefix character recognition logic in the target script (such as commands starting with " / "), the same TCP channel can transmit both remote commands for controlling system behavior (such as exit, status query, and process control) and business data for subsequent steps, achieving multiple uses for one channel and improving communication efficiency and control flexibility.

[0057] This application's embodiments achieve zero-API integration across applications and systems. External systems (such as automated testing platforms, MES systems, barcode scanning devices, etc.) do not need to understand the target application software's internal architecture and API interfaces; they only need to send text data via the standard TCP protocol to drive automated processes to complete operations on any desktop application (including WPS, Excel, ERP clients, web pages, etc.). It acts as a "universal operation gateway" between heterogeneous systems, greatly reducing the technical threshold and development cost of enterprise system integration.

[0058] This application's embodiments implement a persistent memory-based and infinitely looping automated process. By combining the target script with JSON process redirection (goto), the automated process automatically jumps back to the waiting step after completing one round of data reception, processing, writing, and response, entering the next round of waiting state. The entire process is like a persistent memory-based service process, eliminating the need for repeated startup and destruction, making it particularly suitable for scenarios such as production lines that require continuous processing of large amounts of external input.

[0059] Furthermore, the embodiments of this application also achieve cross-loop heavyweight resource reuse, significantly improving execution efficiency. By using a context variable pool to achieve cross-loop reuse of heavyweight resources such as browser drivers, the repeated creation and destruction of resources in each loop is avoided, saving execution time and significantly reducing the risk of memory leaks.

[0060] In one embodiment, such as Figure 3 As shown, an automation control method based on data injection and event-driven approaches is provided, which is then applied to... Figure 1 Taking the controller in the example, the following steps are included: S10: Listen for connection requests from external clients via the TCP server, and when a connection request is detected, establish a data transmission channel with the target client to transmit data.

[0061] Before initiating the automated control process, the controller first starts a TCP server. The TCP server binds to a preset IP address and port number and begins listening for connection requests from external clients. The IP address and port number are preset by the user in the configuration file. For example, an IP address of 0.0.0.0 indicates listening on all network interfaces, and the port number defaults to a preset port number, such as 8765.

[0062] When a connection request is received from an external client, the TCP server completes a connection handshake with the target client corresponding to the request, establishing a bidirectional data transmission channel. Once established, this data transmission channel remains open for subsequent data and control command transmission.

[0063] In this context, the TCP server refers to a server-side component that provides network listening and data transmission / reception functions based on the Transmission Control Protocol. An external client refers to a device or system located outside the controller that communicates with the TCP server via a network. The target client refers to an external client that has initiated a connection request to the TCP server and established a data transmission channel with it. The data transmission channel refers to the connection established between the TCP server and the target client for bidirectional data transmission.

[0064] For example, in a production line data acquisition scenario, after the controller starts the TCP server, it begins listening on a preset port. An industrial barcode scanner, acting as an external client, initiates a connection request to this port. The TCP server accepts the request and establishes a data transmission channel with the barcode scanner. Subsequently, the barcode data obtained by the barcode scanner can be continuously sent to the controller along this channel without having to re-establish a connection each time it is sent.

[0065] S20: Execute the operation steps in the preset automated process, and when the target step associated with the data injection requirement is executed, call the target script associated with the target step to suspend the current automated execution thread, so that the target script enters a suspended waiting state to release system resources.

[0066] While listening for connection requests from external clients via a TCP server, the controller executes the various steps in a pre-programmed automated process. A pre-programmed automated process refers to a pre-arranged sequence of automated execution steps. An operation step refers to a single execution unit within the automated process.

[0067] When the execution reaches a target step associated with a data injection requirement, the controller, before, during, or after the target step, invokes the target script associated with that target step to suspend the current automated execution thread. This causes the target script to enter a suspended waiting state, meaning it pauses the execution of its subsequent logic and relinquishes the system resources it occupies, awaiting the arrival of external data. During the suspended waiting period, the thread corresponding to the target script does not occupy processor time slices, thereby releasing system resources.

[0068] Here, the target step refers to the operational step associated with the data injection requirement that needs to wait for external data. The target script refers to the script associated with the target step, used to complete the data waiting and data processing logic, such as a hook script. The suspended waiting state refers to the state in which the target script is paused in execution, relinquishing system resources (such as CPU resources), and waiting to be awakened; the data injection requirement refers to the requirement that the operational step depends on external input data to continue execution.

[0069] For example, in an automated process, a certain step requires waiting for an external barcode scanner to upload a barcode before it can continue. This step is the target step. When the controller executes the target step, it calls its associated target script. The target script enters a suspended waiting state by relinquishing execution rights. At this time, the controller does not need to repeatedly poll whether the barcode scanner has uploaded data, and can give system resources to other tasks.

[0070] S30: When input data is received from the target client via the TCP server, the target script that is in a suspended waiting state is woken up, so that the woken target script can identify the data type of the input data in order to identify the business data.

[0071] While the target script is in a suspended state, the TCP server continuously listens on the data transmission channel. When the TCP server receives input data from the target client through this channel, it writes the received input data into a pre-defined shared variable storage area. Simultaneously, the TCP server wakes up the suspended target script, resuming execution to read the input data from the shared variable storage area, identify the data type of the input data, and determine the business data for subsequent operations.

[0072] Input data refers to the raw data sent by the target client to the controller via the data transmission channel. Business data refers to the data obtained by the target script after processing the input data, which is used to drive subsequent operations.

[0073] For example, while the target script is suspended, the barcode scanner scans a barcode and sends the barcode characters as input data; the TCP server receives the barcode characters, writes them into a preset shared variable storage area, and wakes up the target script; the target script performs content verification and formatting on the barcode characters to obtain business data that can be used for subsequent queries, and waits for subsequent steps to call.

[0074] In this process, the automated execution thread actively suspends and releases CPU resources while waiting for external data, and is actively woken up by the TCP server when the data arrives. This implements an event-driven rather than polling-driven data waiting mechanism, which ensures millisecond-level real-time response and avoids CPU idling waste.

[0075] S40: Exit the target script and continue to execute subsequent operation steps to perform corresponding operations on the target application software based on business data, and return the operation results to the target client through the TCP server to achieve cross-device automated control.

[0076] After the target script identifies the business data, the controller exits the target script and continues to execute subsequent operation steps. In the subsequent operation steps, the controller performs corresponding operations on the target application software based on the business data, thereby implementing the externally injected data into the automated control of the target application software, and returning the operation results to the target client through the TCP server, realizing cross-device automated control.

[0077] Among them, target application software refers to application software that runs on target devices or target systems and needs to be automatically controlled; cross-device automation control refers to the control process in which data is injected from external devices and ultimately drives application software on another device to complete the operation.

[0078] For example, after the controller receives the barcode business data uploaded by the barcode scanner, it opens the production management system interface in subsequent operation steps, fills the barcode into the system's query box and triggers the query, thus completing cross-device automated control from the barcode scanner (an external device) to the production management system (a target application software).

[0079] In this embodiment, real-time injection of external data is achieved by establishing a normally open data transmission channel between the TCP server and the target client. Data waiting with zero polling and zero blocking is achieved by suspending and waking up the target script, thus avoiding the occupation of processor resources while waiting for external data. This ensures immediate response after data arrival and avoids the resource waste caused by polling. At the same time, the injected input data is transformed into business data and finally implemented into automated operations on the target application software, realizing cross-device automated control between external devices and target applications. This effectively solves the problems of difficulty in injecting external data and resource waste while waiting for data.

[0080] Furthermore, external systems (such as automated testing platforms, MES systems, and barcode scanning devices) do not need to understand the internal architecture and API interfaces of the target application software. They only need to send text data via the standard TCP protocol to drive automated processes to complete operations on any Windows desktop application (including WPS, Excel, ERP clients, web pages, etc.). The system provided in this embodiment acts as a universal operation gateway between heterogeneous systems, reducing the technical threshold and development cost of enterprise system integration.

[0081] In one embodiment, step S20 or step S201 involves executing the operation steps of a preset automated process, specifically including the following steps: S201: Load the JSON configuration file corresponding to the pre-stored automated process and parse the JSON objects in the JSON configuration file. Each JSON object corresponds to an operation step in the preset automated process. The JSON object corresponding to the operation step includes at least a step type field, a coordinate field, and a window identifier field.

[0082] After the TCP server starts, the controller first loads the pre-stored JSON configuration file corresponding to the automated process. The JSON configuration file is a file that stores the definitions of the preset automated process steps in JSON format; that is, the JSON configuration file contains the definitions of all steps in a complete automated control process. Then, the JSON configuration file is parsed to obtain a JSON list containing one or more JSON objects.

[0083] Here, a JSON object refers to the structure in a JSON configuration file that describes a single operation step; each JSON object corresponds to an operation step in the automation process, and a JSON object can include the following fields: Step numbers are used to identify the execution order of steps; The step type field (type) describes the type of operation step; the value of this field can be step type such as click, text_input, key_combo, etc. The coordinate fields (x, y) are used to locate the operation position of the operation step, such as clicking or entering a position; The window identifier field (window_id) is used to identify the target window associated with the step; The target script associated field (i.e. the hook script associated field: flags.hook) is used to specify the filename of the target script (such as the hook script) that needs to be called before or after the current operation step is executed; The call timing field (flags.hook_timing) is the target script execution timing field. The value of this field can be pre (meaning that the call is made before the current operation step is executed) or post (meaning that the call is made after the current operation step is executed). The jump target field (goto) is used to jump to the step corresponding to the specified label after the current operation step is completed.

[0084] For example, the JSON configuration file contains two JSON objects. The first JSON object describes the click operation performed at a certain window coordinate and has a target script associated field, so it is identified as the target step. The second JSON object describes the operation of writing text to a specified window for execution after receiving data.

[0085] S202: Based on the step type field, coordinate field, and window identifier field in the JSON object, execute the corresponding operation steps, and when the target script association field is read in the JSON object, determine that the corresponding operation step is the target step associated with the target script.

[0086] After parsing the JSON list containing JSON objects, the controller executes each JSON object sequentially according to the order in the list to execute each operation step in the automated process. Specifically, it executes the corresponding operation step based on the step type field, coordinate field, and window identifier field in the JSON object.

[0087] During the execution of an automated process, when a target script-related field is found in a JSON object, the corresponding operation step is identified as a target step associated with a target script. The corresponding target script is then invoked to suspend the automated execution thread, releasing system resources and awaiting external data injection. Specifically, when executing a target JSON object containing a target script-related field, the controller invokes the target Hook script specified by the `flags.hook_timing` field at the appropriate time based on its value. For example, when `flags.hook_timing` is "post", the controller first executes the operation defined in the target JSON object (such as clicking a specified coordinate), and then invokes the target Hook script.

[0088] In this embodiment, the automated process is described declaratively through a JSON configuration file, which allows each operation step of the process to be flexibly arranged and modified through the configuration file without changing the control program, thus improving the maintainability and configurability of the solution.

[0089] In one embodiment, the JSON object corresponding to the target step further includes a call timing field for the target script; this call timing field indicates the timing of the call to the target script relative to the target step. Specifically, in step S20 or S21, calling the target script associated with the target step includes the following steps: S203: Determine the timing of the target script's execution based on the timing of the script's execution field. The timing of the execution includes whether the script is executed before or after the target step.

[0090] S204: Depending on the timing of the call, either before or after the execution of the target step, the target script associated with the target step is called based on the fields associated with the target script.

[0091] For example, if a target step requires clicking a button on the interface before waiting for data, then its timing field is configured to be called after the target step is executed. The controller first executes the click operation, and then obtains the calling script based on the target script association field to call the target script and suspend waiting. If a target step requires obtaining data before execution, then it is configured to be called before the target step is executed. The target script is called first to wait for data, and then the step operation is executed.

[0092] In this embodiment, the timing of the target script is flexibly controlled by the timing field, so that the target script can be called before or after the target step is executed, adapting to the sequential relationship between data waiting and step operation in different business scenarios.

[0093] In one embodiment, the JSON object may further include a target field; the target field is a field used to indicate the target step to which the current operation step will proceed after completion. When performing subsequent operation steps, the method further includes the following steps: S51: Detect the fields in the JSON object corresponding to the current operation step.

[0094] S52: When it is detected that the JSON object corresponding to the current operation step includes a jump target field pointing to the target step, after the current operation step is completed, jump back to the target step according to the jump target field to re-execute the target step and the corresponding target script, and enter the next round of waiting.

[0095] For example, in a production line cycle processing scenario, after the subsequent operation steps are completed and the results are returned, it is detected that the corresponding JSON object contains a jump target field pointing to the target step. Therefore, it jumps back to the target step and waits again, so that the process enters the next cycle and continuously processes the data continuously uploaded by the external client.

[0096] In this embodiment, the process is cyclically jumped to the target field, so that the automated process automatically returns to the waiting state after completing one round of processing, just like a resident service process. This is suitable for scenarios that need to continuously process a large number of external inputs.

[0097] In one embodiment, step S20, which involves suspending the current automated execution thread of the target script associated with the target step and causing the target script to enter a suspended waiting state, specifically includes the following steps: S21: Call the target script associated with the target step to suspend the current automated execution thread by calling the asynchronous event waiting interface, so that the target script enters the suspended waiting state and sends a ready status signal to the target client.

[0098] Upon reaching the target step, the controller activates the target script, which calls the asynchronous event waiting interface to suspend the current automated execution thread, putting the target script into a suspended waiting state and releasing system resources. Simultaneously, the target script sends a ready status signal to the target client via a TCP sending interface, notifying the target client to send input data.

[0099] The asynchronous event waiting interface is an interface called by the target script to put itself into a suspended waiting state. The TCP sending interface is an interface called by the target script to send data to the target client. The ready status signal is a signal sent by the target script to the target client to indicate that it is ready to receive data.

[0100] Specifically, after the target script (i.e., the Hook script) is invoked, the following operations are performed: Retrieve the interface objects in the execution context. These execution context interface objects must include at least the asynchronous event wait interface (wait_for_event), the asynchronous event notification interface (notify_event), the TCP send interface (send_tcp), the shared variable get interface (get_variable), and the shared variable set interface (set_variable).

[0101] A ready status signal is sent to an external client via the TCP send interface. Specifically, the target script can call `send_tcp("ready")` to inform the external client that the current automated process is ready and data can be sent.

[0102] Calling the asynchronous event wait interface suspends the current automated execution thread, causing it to wait indefinitely. The target script can call `await wait_for_event(timeout=None)`, where `timeout=None` indicates indefinite waiting until awakened by an external event. After calling `wait_for_event`, the current automated execution thread enters a suspended state, releasing CPU resources and not occupying any system computing resources.

[0103] For example, before entering the suspend waiting state, the target script first sends a ready status signal to the barcode scanner via the TCP sending interface. After receiving the signal, the barcode scanner lights up an indicator light to prompt the operator that scanning can begin. Then, the target script calls the asynchronous event waiting interface to suspend itself and wait for the barcode scanner to upload subsequent data.

[0104] This embodiment enables the target script to be actively suspended through an asynchronous event waiting interface, and completes a handshake with the target client using a ready status signal, so that the external client can clearly know when the process is ready, thereby ensuring the timing reliability of data injection.

[0105] Correspondingly, in step S30, when input data is received from the target client via the TCP server, the target script, which is in a suspended waiting state, is awakened, so that the awakened target script can identify the data type of the input data in order to identify the business data. Specifically, this includes the following steps: S31: When input data is received from the target client through the TCP server, the input data is written into the preset input data shared variable, and the asynchronous event notification interface is called to wake up the target script that is in a suspended waiting state. After the target script is woken up, it is used to execute steps S32 to S334.

[0106] Among them, the input data shared variable refers to a pre-defined shared storage unit used to temporarily store the input data received by the TCP server. The asynchronous event notification interface is an interface called by the TCP server to wake up the target script that is in a suspended waiting state.

[0107] For example, after the TCP server receives the barcode data uploaded by the barcode scanner, it first writes it into the input data shared variable, and then calls the asynchronous event notification interface to wake up the suspended target script and continue to execute the subsequent data reading and recognition logic.

[0108] S32: Read input data from the input data shared variable and identify the data type.

[0109] After being woken up, the target script reads input data from the shared input data variable and identifies the data type. Specifically, if the header of the input data is a preset command prefix character, the input data is determined to be a control command; if the header of the input data is not a preset command prefix character, the input data is determined to be business data.

[0110] Data type identification refers to the process of determining whether input data belongs to control commands or business data based on its characteristics. Command prefix characters are pre-defined characters located at the beginning of the input data header, used to identify control commands, such as ' / '. Control commands are instructions used to control the behavior of the automated process itself.

[0111] For example, if the target script reads input data that begins with the command prefix character / from the input data shared variable, it identifies it as a control command; if the read input data does not begin with the command prefix character, it identifies it as business data and enters a different processing branch accordingly.

[0112] S33: When the input data is identified as business data, the business data is stored in the business data shared variable.

[0113] When the input data is identified as business data, the target script writes the business data into a preset shared business data variable and exits the target script after the data is stored. The shared business data variable refers to a preset shared storage unit used for transferring business data across steps.

[0114] The target application software includes at least one of WPS Office software, Excel spreadsheets, web pages, ERP clients, and MES system clients; the corresponding operations are performed on the target application software based on business data, including: reading business data from shared business data variables; inputting business data into input boxes or table cells of the target application software; or performing query operations in the target application software based on business data.

[0115] For example, the target script stores the identified barcode business data into a business data shared variable and then exits; subsequent operation steps read the business data from the business data shared variable, input it into the query input box on the web page, or perform a query operation in the system based on the business data.

[0116] S34: When the input data is recognized as a control command, execute the corresponding control processing logic according to the control command.

[0117] When input data is recognized as a control command, the target script responds by executing the corresponding control processing logic. These control commands include exit commands, status query commands, and test commands. When the control command is an exit command, the automation process terminates. When the control command is a status query command or a test command, the corresponding information is returned to the target client via the TCP sending interface, and the asynchronous event waiting interface continues to be called.

[0118] For example, after the target script reads a status query command that begins with a command prefix character, it returns the current running status of the automated process to the target client via the TCP sending interface, and then continues to call the asynchronous event waiting interface to enter the next round of waiting without exiting the target script; if it reads a test command, it returns test information to the target client via the TCP sending interface, and then continues to call the asynchronous event waiting interface to enter the next round of waiting without exiting the target script; if it reads an exit command, it sends an acknowledgment message to the target client via the TCP sending interface, and terminates the execution of the entire automated process after returning the acknowledgment.

[0119] In this embodiment, the handover between the data receiver and the data processor is realized by inputting a shared data variable. The input data is intelligently split into control commands and business data by using command prefix characters. This allows the same data transmission channel to transmit both control commands and business data, enabling multiple uses for a single channel. This avoids misprocessing caused by mixing control commands and business data. At the same time, it allows business data to be transmitted across steps and applied to the target application software via the shared business data variable.

[0120] In one embodiment, the asynchronous event waiting interface is implemented based on an asynchronous event object, which internally maintains an event flag. When the asynchronous event waiting interface is called, the event flag of the asynchronous event object is cleared, and the current automated execution thread carrying the target script is suspended, causing the target script to enter a suspended waiting state. When the asynchronous event notification interface is called, the event flag of the asynchronous event object is set, and the thread corresponding to the suspended target script is awakened.

[0121] In this context, an asynchronous event object refers to a synchronization object used to coordinate the waiting and waking of different execution threads. An event flag is a flag within the asynchronous event object used to indicate whether an event has occurred; the thread corresponding to the target script is the thread that executes the logic of the target script.

[0122] For example, after the target script calls the asynchronous event waiting interface, the event flag is cleared and the execution thread of the target script is suspended; when the TCP server receives the data and calls the asynchronous event notification interface, the event flag is set, and the execution thread of the target script is immediately awakened and resumes execution.

[0123] Unlike the loop polling approach, this embodiment employs an asynchronous event-driven mechanism based on the asynchronous event object asyncio.Event. The asynchronous event waiting interface wait_for_event internally maintains an event flag (EventFlag). When the asynchronous event waiting interface wait_for_event is called, the event flag is cleared (clear()), and the execution thread suspends and waits. When the asynchronous event notification interface notify_event is called externally, the event flag is set (set()), and the suspended execution thread is immediately awakened.

[0124] Taking a target script as a Hook script as an example, such as Figure 4 As shown, a schematic diagram of the asynchronous waiting and waking sequence of the target script is illustrated. Figure 4 As shown, the timing flow of the asynchronous wait and wake-up mechanism is as follows: At time T1: The target script (Hook script) calls the asynchronous event waiting interface wait_for_event, the automated execution thread is suspended, and it enters a suspended waiting state, and the event flag is cleared.

[0125] Time T2: The external client sends data via TCP, and the TCP server receives the data from the external client.

[0126] At time T3: The TCP server parses the input data from the external client and stores it in the input data shared variable.

[0127] At time T4: The TCP server calls the asynchronous event notification interface notify_event, and the event flag is set.

[0128] At time T5: The suspended target script is awakened and reads input data from the input data shared variable.

[0129] Throughout the entire suspension and wake-up process, the delay from time T2 to T5 depends only on the overhead of TCP network transmission and inter-process communication. There is no additional delay caused by the polling interval, achieving millisecond-level real-time response.

[0130] In this embodiment, the event flag of the asynchronous event object is used to achieve precise synchronization of waiting and waking up, so that both suspension and waking up can be completed in real time in the event-driven mode, avoiding processor idle time caused by polling and waiting, while ensuring immediate response after data arrives.

[0131] In one embodiment, such as Figure 5 As shown, after step S21, that is, after the target script is awakened, the target script is specifically used to perform the following processes: S211: Read the preset input data shared variable to obtain the input data of the target client.

[0132] The target script can call get_variable(“tcp_input_data”) to retrieve the input data stored by the TCP server from the input data shared variable.

[0133] S212: Clear the input data shared variable and determine whether the input data read is empty.

[0134] The target script can call `set_variable("tcp_input_data", None)` to clear the shared input data variable, preventing accidental reading of historical data in the next loop. S213: If the input data is empty, the asynchronous event waiting interface will be called again to continue waiting.

[0135] S214: If the input data is not empty, then process the input data.

[0136] If the input data is empty, i.e., the input data is an empty string, the target script will not exit, but will call wait_for_event again to enter the next round of waiting and continue to wait for input data from the external client.

[0137] If the input data shared variable is not empty, the input data is preprocessed: if the input data is of byte type, it is converted to string type, then leading and trailing whitespace characters are removed, and then data type identification is performed.

[0138] After preprocessing the input data, the aforementioned data type identification and corresponding data processing logic are executed. For example... Figure 5As shown, the process first determines whether the input data begins with a preset command prefix character (such as / ). If not, the input data is identified as business data, stored in a shared business data variable, the target script exits, and subsequent steps continue. If it does, the input data is identified as a control command, and the command name is extracted to determine the control command type. After determining the command type, if the control command is a status query command, status information is returned; if the control command is a test command, test information is returned; if the control command is an exit command, the process terminates after the target client confirms; if the control command is another command, undefined information is returned (see above for details).

[0139] In other embodiments, it can be done by first determining whether the input data is empty. If the input data is empty, there is no need to clear the input data shared variable; instead, the asynchronous event waiting interface is called again to continue waiting. If the input data is not empty, the input data shared variable is cleared first, and then the read input data is processed. For example, after the target script is woken up, it reads the input data shared variable and finds that its content is empty, indicating that this wake-up was not triggered by the arrival of valid data. Therefore, the asynchronous event waiting interface is called again to continue waiting. When it is woken up again and reads non-empty barcode data, the barcode content is read first, and then the input data shared variable is cleared to zero to prevent the next loop from misreading the historical data left over from the previous loop.

[0140] In this embodiment, by checking for and clearing the shared variables of the input data to prevent misreading caused by residual historical data, it is ensured that the latest received input data is used in each round of data processing, thereby improving the accuracy of the loop processing.

[0141] In one embodiment, the TCP server supports data receiving modes including text mode and binary mode. Step S30, which involves receiving input data from the target client via the TCP server, specifically includes the following steps: S301: When the TCP server's current data receiving mode is text mode, the byte stream from the target client is decoded into a text string according to text encoding to obtain the input data.

[0142] S302: When the TCP server's current data receiving mode is binary mode, it parses the binary data packets from the target client according to the preset binary data packet structure to obtain the input data.

[0143] Among these, data reception mode refers to the method by which the TCP server parses the received byte stream. Text mode refers to the mode of decoding the byte stream into a text string using text encoding. Binary mode refers to the mode of parsing data according to a preset binary data packet structure.

[0144] In text mode, the TCP server decodes the received byte stream into a text string according to UTF-8 or ASCII encoding. In binary mode, the TCP server parses the received binary data packets according to a preset data packet structure, such as header + length field + data body. The two modes are switched using the configuration parameter `use_binary`. When `use_binary` is false, text mode is used; when `use_binary` is true, binary mode is used.

[0145] For example, when communicating with a barcode scanner, the TCP server can be configured in text mode, and the received barcode byte stream is decoded into a readable text string; when communicating with industrial field equipment that sends a binary protocol, it can be configured in binary mode, and the TCP server can parse the valid data body as input data according to the structure of the packet header, length field and data body.

[0146] In this embodiment, by supporting both text mode and binary mode for receiving data, the solution is applicable to both conventional devices that send text data and industrial field devices that send binary protocols, thus expanding the scope of application of the solution to different types of external devices.

[0147] In one embodiment, the message routing modes supported by the TCP server include automatic processing mode (auto) and custom handler mode (handler). Before step S31, i.e., before writing the input data to a preset input data shared variable, the method further includes the following steps: S35: Determine the message routing mode currently used by the TCP server; if the TCP server is currently using the automatic processing mode, execute steps S31 to S34; if the TCP server is currently using the custom processor mode, execute step S36.

[0148] Among them, message routing mode refers to the mode in which the TCP server processes the received input data. Automatic processing mode refers to the mode in which the TCP server processes the input data according to preset default logic, such as the data processing logic mentioned earlier, which involves storing the data in a preset shared input data variable and waking up the waiting target script. Custom processor mode refers to the mode in which a pre-configured message processor processes the input data; in custom processor mode, the TCP server forwards the received data to a user-defined message processor, giving the user complete control over message distribution, parsing, and response logic.

[0149] S31: Write the input data into a preset shared input data variable and call the asynchronous event notification interface to wake up the target script that is in a suspended waiting state to process the input data.

[0150] S36: The input data is forwarded to a pre-configured message processor via the TCP server for input data recognition.

[0151] The message processor is a pre-configured processor used to process input data. This message processor can implement complex message distribution logic, such as distributing messages to different Hook scripts based on data content, maintaining session states for multiple clients, and implementing request-response interaction protocols.

[0152] When the TCP server is currently in automatic processing mode, the controller writes the input data to a preset shared input data variable and calls the asynchronous event notification interface to wake up the target script that is in a suspended waiting state for input data recognition. This allows the controller to identify business data or control commands and execute the corresponding data processing logic. When the TCP server is currently in custom processor mode, the controller forwards the input data to a pre-configured message processor for input data recognition or processing.

[0153] For example, in a standard production line scenario, the TCP server is configured in automatic processing mode. Input data is identified according to default logic, and when business data is identified, it is stored in the input data shared variable and the target script is awakened. In a scenario that requires parsing private protocols, the TCP server is switched to custom processor mode. Input data is forwarded to the user-preconfigured message processor, which completes the parsing and distribution of the private protocol.

[0154] The user-defined message handler can be a Python script file that must implement the `handle_message(context, client_id, message)` function. This function accepts three parameters: `context` is the execution context (including interfaces such as `send`, `send_all`, `get_variable`, and `set_variable`), `client_id` is the client identifier sending the data, and `message` is the parsed data content. Users can implement the following extended functionalities in their custom message handlers: Custom protocol parsing: Parses non-standard format text protocols or proprietary binary protocols; Multi-client management: Maintain the connection status of multiple TCP clients and execute different processing logic based on the client's identity; Request-response interaction: enabling complex multi-turn conversational interactions, rather than simple single-time data injection; Message filtering and routing: Routing data to different target scripts or processing flows based on message content.

[0155] For details on the TCP server's data reception and parsing process, please refer to [link / reference]. Figure 6 .like Figure 6 As shown, the TCP server receives data packets from the target client. Upon receiving the data packet, the TCP server determines whether the current data reception mode is binary mode. If it is binary mode, it parses the data packet according to its structure to obtain the input data; otherwise, it decodes the data packet according to text mode to obtain the input data. Then, the TCP server determines the current message routing mode. When the message routing mode is automatic processing mode, it stores the input data in a shared input data variable and calls the asynchronous event notification interface to wake up the suspended target script. When the message routing mode is custom processor mode, it forwards the input data to the target processor, causing it to execute the user-defined processing logic until the custom processing is complete. See the above for details.

[0156] In this embodiment, by providing two message routing modes—automatic processing mode and custom processor mode—the solution maintains the simplicity and efficiency of the default processing while supporting users to customize the parsing and distribution of input data. By introducing the custom processor mode, the solution maintains the simplicity and efficiency of the core framework while possessing extremely high scalability and flexibility, thereby expanding the solution's adaptability to complex communication scenarios and enabling it to meet various complex industrial field communication needs.

[0157] In one embodiment, during step S20, i.e., during the execution of the operation steps in the automated process, the target script reuses resource instances across loops through a context variable pool. Resource instances are stored in the context variable pool when the target script is first created, and cleanup handles for destroying resource instances are registered to a unified cleanup list. In subsequent execution loops, the target script, upon being awakened, retrieves and reuses existing resource instances from the context variable pool.

[0158] The executor (i.e., the process execution engine) in the system maintains a global context variable pool (self._hook_variables). This context variable pool refers to the storage space used to share data and resource instances across loops and steps. This context variable pool is created when the executor starts and destroyed when the process ends, persisting throughout the entire lifecycle of the automated process.

[0159] Each target script, upon execution, retrieves a reference to the context variable pool using `context.get('variables')` to reuse resource instances across loops. Because dictionaries in Python are passed by reference, modifications to the context variable pool by the target script are directly reflected in the executor's `self._hook_variables`.

[0160] A resource instance refers to an object instance that is costly to create and can be reused across cycles. A cleanup handle is a handle that encapsulates the logic for destroying a resource instance; a cleanup list is a list used to uniformly register cleanup handles.

[0161] Resource instances include one or more of the following: browser driver instances, COM object instances, network connection instances, database connection instances, and HTTP session instances. A browser driver instance is an object instance used to drive browser operations; a COM object instance is an object instance created based on the component object model; and network connection instances, database connection instances, and HTTP session instances are the object instances corresponding to network connections, database connections, and HTTP sessions, respectively.

[0162] In batch query scenarios, during the first loop, the target script checks if a target resource instance exists in the context variable pool. If it doesn't, it creates the target resource instance (such as a browser driver instance) and stores it in the context variable pool, while simultaneously registering its cleanup handle to the cleanup list. In subsequent loops, the target script directly retrieves the target resource instance from the context variable pool, eliminating the need to create it in every loop iteration, such as when restarting the browser.

[0163] In this embodiment, heavyweight resource instances across loops are reused through a context variable pool, avoiding the repeated creation and destruction of resources in each loop, which greatly improves the efficiency of loop execution and reduces the risk of memory leaks caused by frequent start-stop operations.

[0164] In one embodiment, when a resource instance is first created, the target script (i.e., the resource user) performs a cleanup handle registration operation. This cleanup handle is an asynchronous coroutine function that encapsulates the destruction logic of a specific resource. During cleanup handle registration, a registration status flag (_xxx_cleanup_registered) ensures that each resource is registered only once, preventing the same resource from being registered repeatedly.

[0165] In this context, an asynchronous coroutine function refers to a function defined as a coroutine and executed asynchronously. A registration status flag is a flag used to indicate whether a resource has been registered with a cleanup handle. An end code block is a code block that is always executed when the process ends. An exception handling domain is an independent execution domain used to isolate exceptions occurring during the execution of a single cleanup handle.

[0166] At the end of the pre-defined automated process, the executor iterates through the cleanup list in reverse order within the `finally` block and executes each cleanup handle in a separate exception handling domain. Each cleanup handle is associated with a timeout, which is the maximum allowed execution time. If the execution time of a cleanup handle exceeds its associated timeout, the cleanup handle is forcibly terminated, and the next cleanup handle is executed.

[0167] For example, when the preset automated process ends, the executor traverses the cleanup list in reverse order in the closing code block, and the cleanup handles registered later are executed first; if a cleanup handle fails to complete its execution time after exceeding its associated timeout, it is forcibly terminated and the next cleanup handle is processed, so as to avoid the entire process being unable to exit due to a single resource cleanup being stuck.

[0168] In this embodiment, resource registration status flags are used to prevent duplicate registration, reverse traversal and independent exception capture fields are used to achieve orderly and reliable resource reclamation, and timeout protection is provided through timeout time to avoid resource leakage and ensure that the process can still exit normally if any cleanup fails or gets stuck.

[0169] In one embodiment, before reusing an existing resource instance, the target script is further configured to perform health check-related processing. Specifically, the health check-related processing includes the following steps: performing a health check on the resource instance; if the health check passes, reusing the existing resource instance; if the health check fails, indicating that the resource has failed, automatically destroying the resource instance and creating a new resource instance to replace it.

[0170] Among them, health check refers to the verification process performed to determine whether a resource instance is currently available.

[0171] For example, before reusing a browser driver instance, the target script checks whether the browser process is alive. If the process is alive, the health check passes and the browser driver instance is reused directly. If the browser is detected to have crashed, the health check fails, the old instance is destroyed according to the corresponding cleanup handle in the cleanup list, and a new browser driver instance is created to replace it, ensuring that the process is not interrupted due to resource failure.

[0172] Different resource types correspond to different health check methods. For example, when the resource type is SeleniumWebDriver, the corresponding health check method is to check whether driver.service.process.poll() is None; when the resource type is Playwright, the corresponding health check method is to execute page.evaluate(“1+1”) to verify the connection; when the resource type is a WPS COM object, the corresponding health check method is to try to read sheet.Cells(1,1).Value; and when the resource type is a TCP Socket, the corresponding health check method is to try socket.getpeername().

[0173] In this embodiment, a health check is performed before reusing resource instances, and resources are automatically destroyed and rebuilt when they fail, improving the reliability of the cyclic execution process and enabling the automated process to continue running without interruption when resources malfunction. Furthermore, a separation of responsibilities mechanism—registering the target script for the step and recycling the executor—decouples resource management from the executor: the resource creator (the target script for the target step) defines how to destroy the resource, and the executor decides when to destroy it. When adding a new resource type, only the corresponding cleanup handle needs to be registered in the target script; no modification to the executor is required. This conforms to the open / closed principle and is suitable for all heavyweight resources with high creation costs and requiring cross-cycle reuse, such as browser drivers, COM objects, network connections, database connections, and HTTP sessions.

[0174] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0175] It should be noted that the information interaction and execution process between the various devices / units in the controller are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, and they will not be repeated here.

[0176] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0177] This application also provides a computer device, such as... Figure 7 As shown, the computer device includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor. When the processor executes the computer program, it implements the steps in any of the above method embodiments, or when the processor executes the computer program, it implements the functions of each module / unit in the above device embodiments.

[0178] For example, the computer program may be divided into one or more modules / units, which are stored in the memory and executed by the processor to complete this application. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of the computer program in the computer device.

[0179] Those skilled in the art will understand that Figure 7 The computer device described is merely an example and does not constitute a limitation on the computer device. It may include more or fewer components than shown, or combine certain components, or different components. For example, the computer device may also include input / output devices, network access devices, buses, etc.

[0180] The aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0181] The memory can be an internal storage unit of the computer device, such as a hard drive or RAM. The memory can also be an external storage device of the computer device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory can include both internal and external storage units of the computer device.

[0182] This application also provides a readable storage medium storing a computer program that, when executed by a processor, implements the steps described in the various method embodiments above.

[0183] This application provides a computer program product that, when run on an electronic device, enables the electronic device to perform the steps described in the various method embodiments above.

[0184] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, all or part of the processes in the methods of the above embodiments of this application can be implemented by a computer program instructing related hardware. The computer program can be stored in a computer-readable storage medium, and when executed by a processor, it can implement the steps of the various method embodiments described above. The computer program includes computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. The computer-readable medium can include at least: any entity or device capable of carrying computer program code to a corresponding device, a recording medium, a computer memory, a read-only memory (ROM), a random access memory (RAM), an electrical carrier signal, a telecommunication signal, and a software distribution medium. Examples include USB flash drives, portable hard drives, magnetic disks, or optical disks. In some jurisdictions, according to legislation and patent practice, computer-readable media cannot be electrical carrier signals or telecommunication signals.

[0185] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0186] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0187] In the embodiments provided in this application, it should be understood that the disclosed apparatus / devices and methods can be implemented in other ways. For example, the apparatus / device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0188] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0189] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. An automated control method based on data injection and event-driven principles, characterized in that, include: The TCP server listens for connection requests from external clients and establishes a data transmission channel with the target client to transmit data when a connection request is detected. The system executes the operation steps in the preset automated process, and when it reaches the target step associated with the data injection requirement, it calls the target script associated with the target step to suspend the current automated execution thread, so that the target script enters a suspended waiting state to release system resources. When the TCP server receives input data from the target client, it wakes up the target script that is in a suspended waiting state, so that the awakened target script can identify the data type of the input data in order to identify the business data. Exit the target script and continue with subsequent operation steps to perform corresponding operations on the target application software based on the business data, and return the operation results to the target client through the TCP server to achieve cross-device automated control.

2. The method according to claim 1, characterized in that, The step of suspending the current automated execution thread of the target script associated with the target step, causing the target script to enter a suspended waiting state, includes: The target script associated with the target step is invoked to suspend the current automated execution thread by calling the asynchronous event waiting interface, causing the target script to enter a suspended waiting state and send a ready status signal to the target client; the ready status signal is used to notify the target client to send the input data.

3. The method according to claim 2, characterized in that, When the TCP server receives input data from the target client, it wakes up the target script, which is in a suspended waiting state, so that the awakened target script can identify the data type of the input data to identify business data, including: When input data is received from the target client via the TCP server, the input data is written into a preset input data shared variable, and the asynchronous event notification interface is called to wake up the target script that is in a suspended waiting state. After the target script is woken up, it reads the input data from the input data shared variable and performs data type identification. When the input data is identified as business data, the business data is stored in the business data shared variable. When the input data is identified as a control command, the corresponding control processing logic is executed according to the control command.

4. The method according to claim 1, characterized in that, The operation steps in executing the preset automated process include: Load the pre-stored JSON configuration file corresponding to the automation process, and parse the JSON objects in the JSON configuration file. Each JSON object corresponds to an operation step in the preset automation process. The JSON object corresponding to the operation step includes at least a step type field, a coordinate field, and a window identifier field. Based on the step type field, coordinate field, and window identifier field in the JSON object, the corresponding operation steps are executed, and when the target script association field is read in the JSON object, the corresponding operation step is determined to be the target step associated with the target script.

5. The method according to claim 4, characterized in that, The method further includes: When performing subsequent operation steps, the fields in the JSON object corresponding to the current operation step are detected; When it is detected that the JSON object corresponding to the current operation step includes a jump target field pointing to the target step, after the current operation step is completed, jump back to the target step according to the jump target field to re-execute the target step and the corresponding target script, and enter the next round of waiting.

6. The method according to any one of claims 1-5, characterized in that, During the execution of the preset automated process, the target script reuses resource instances across loops through a context variable pool. The resource instance is stored in the context variable pool when the target script is first created, and a cleanup handle for destroying the resource instance is registered to a unified cleanup list. The resource instance includes one or more of the following: browser driver instance, COM object instance, network connection instance, database connection instance, and HTTP session instance. In subsequent execution loops, the target script is awakened and retrieves and reuses the existing resource instance from the context variable pool.

7. The method according to claim 6, characterized in that, Before reusing the existing resource instance, the target script is also used to: A health check is performed on the resource instance. If the health check fails, the resource instance is destroyed and a new resource instance is created to replace it.

8. An automated control system based on data injection and event-driven principles, characterized in that, Includes a controller, the controller comprising: The TCP server module is used to listen for connection requests from external clients and, upon receiving a connection request, establish a data transmission channel with the target client to transmit data. The process execution engine module is used to execute the operation steps in the preset automated process. When the execution reaches the target step associated with the data injection requirement, the target script associated with the target step is called to suspend the current automated execution thread, so that the target script enters a suspended waiting state to release system resources. When the TCP server receives input data from the target client, it wakes up the target script that is in a suspended waiting state, so that the awakened target script can identify the data type of the input data in order to identify the business data; Exit the target script and continue with subsequent operation steps to perform corresponding operations on the target application software based on the business data, and return the operation results to the target client through the TCP server to achieve cross-device automated control.

9. A readable storage medium storing a computer program, characterized in that, When the computer program is executed by the processor, it implements the steps of the automated control method based on data injection and event-driven methods as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the automated control method based on data injection and event-driven methods as described in any one of claims 1 to 7.

Images