Cross-platform process automation method, apparatus, electronic device, and storage medium

Abstract

The application relates to the technical field of computer software, can be applied to the field of financial technology / digital medicine, and discloses a cross-platform process automation method and device, an electronic device and a storage medium. The method comprises the following steps: obtaining a visual process operation, converting the visual process operation into standardized process definition information through a browser cross-environment execution module; obtaining process operation nodes and execution relationships through analysis, and generating a process scheduling task; determining a target execution node according to the ability and resource state of a heterogeneous execution node; determining a target processor architecture, loading an instruction adaptation plug-in based on a microkernel architecture, converting each node into a target execution instruction, and generating a process execution task; signing, encrypting and sending the task to the node for verification and decryption; after successful verification and decryption, executing the task in an independent running container, obtaining an execution result and a container running state, and updating a task state and a node resource state. The method improves the cross-platform compatibility and execution security of a process automation task.

Description

Technical Field

[0001] This application relates to the field of computer software technology and can be applied to the fields of financial technology / digital healthcare, and in particular to a cross-platform process automation method, device, electronic device and storage medium. Background Technology

[0002] With the increasing informatization of fintech, digital healthcare, and enterprise office environments, robotic process automation (RPA) systems are gradually being applied to repetitive business scenarios such as data entry, report generation, business review, and inter-system data transfer. Existing RPA systems are typically developed based on specific operating systems, runtime frameworks, browser kernels, and database environments. Different hardware and software platforms differ in instruction sets, system interfaces, interface rendering mechanisms, and runtime dependencies. When existing RPA systems are migrated to environments with different operating systems, processor architectures, databases, and browser kernels, problems such as program malfunctions, poor compatibility of process components, abnormal business interface recognition, or operational failures can easily occur. For example, in reconciliation and report processing scenarios in financial institutions, existing automated processes may need to be redeveloped due to changes in the business system's operating environment; in the digital healthcare field, automated processes such as registration, payment settlement, and medical data entry may also fail due to differences between different terminal environments or browser kernels. Furthermore, the existing systems' process design, task execution, and resource scheduling functions are usually closely intertwined, making system expansion and maintenance difficult. When the number of concurrent processes or business load changes, problems such as unreasonable allocation of execution resources, excessive load on some execution nodes, and long task waiting times may also occur. At the same time, the automated process involves the transmission of business data and control commands, and the existing systems still have shortcomings in terms of adaptation to domestic cryptographic systems and security protection during operation. Summary of the Invention

[0003] The main technical problem addressed by the embodiments of this application is that traditional process automation technology suffers from poor compatibility and insufficient security, difficulty in cross-platform process migration, and low utilization of execution resources when adapting to different software and hardware operating environments.

[0004] To address the aforementioned technical problems, the first technical solution adopted in this application is: providing a cross-platform process automation method, comprising: acquiring visual process design operations in a target runtime environment; converting the visual process design operations into standardized process definition information through a browser-based cross-environment execution module; parsing the standardized process definition information to obtain multiple process operation nodes and execution relationships between the multiple process operation nodes; generating a process scheduling task based on the multiple process operation nodes and the execution relationships; acquiring node capability information and resource status information of multiple heterogeneous execution nodes; determining a target execution node based on the process scheduling task, the node capability information, and the resource status information; and determining the target execution node. The target processor architecture of the node loads the corresponding instruction adaptation plugin based on the microkernel architecture, converts the multiple process operation nodes into target execution instructions, and generates process execution tasks in combination with the execution relationship; the process execution tasks are signed and encrypted, and the signed and encrypted process execution tasks are sent to the target execution node, and the target execution node performs signature verification and decryption; when the signature verification is successful and the decryption is successful, the target execution node is controlled to execute the decrypted process execution task in an independently running container, obtain the process execution result and the container running status, and update the task status of the process execution task and the resource status information of the target execution node according to the process execution result and the container running status.

[0005] To address the aforementioned technical problems, the second technical solution adopted in this application is: providing a cross-platform process automation device, comprising: a process definition conversion module, used to acquire visual process design operations in a target operating environment, and convert the visual process design operations into standardized process definition information through a browser-based cross-environment execution module; a process node parsing module, used to parse the standardized process definition information to obtain multiple process operation nodes and the execution relationships between the multiple process operation nodes; a scheduling task generation module, used to generate process scheduling tasks based on the multiple process operation nodes and the execution relationships; and an execution node determination module, used to acquire node capability information and resource status information of multiple heterogeneous execution nodes, and determine a target execution node based on the process scheduling task, the node capability information, and the resource status information; and execute... The instruction adaptation module is used to determine the target processor architecture of the target execution node, load the corresponding instruction adaptation plugin based on the microkernel architecture, convert the multiple process operation nodes into target execution instructions, and generate process execution tasks in combination with the execution relationship. The task security processing module is used to sign and encrypt the process execution task, send the signed and encrypted process execution task to the target execution node, and verify and decrypt the signature through the target execution node. The process task execution module is used to control the target execution node to execute the decrypted process execution task in an independently running container when the signature verification is successful and the decryption is successful, obtain the process execution result and the container running status, and update the task status of the process execution task and the resource status information of the target execution node according to the process execution result and the container running status.

[0006] To solve the above-mentioned technical problems, the third technical solution adopted in the embodiments of this application is: to provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the cross-platform process automation method as described above.

[0007] To solve the above-mentioned technical problems, the fourth technical solution adopted in the embodiments of this application is: to provide a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by an electronic device, the electronic device performs the cross-platform process automation method as described above.

[0008] Unlike related technologies, this application uses a browser-based cross-environment execution module to convert visual process design operations into standardized process definition information, and parses the process operation nodes and execution relationships to generate process scheduling tasks, thus separating the process design logic from the specific runtime environment. Furthermore, it combines the node capability information and resource status information of heterogeneous execution nodes to determine the target execution node, reducing task execution anomalies caused by processor architecture, runtime dependencies, or resource condition mismatches. Based on a microkernel architecture, it loads corresponding instruction adaptation plugins to convert process operation nodes into target execution instructions adapted to the target processor architecture and system interface, reducing the adaptation cost of cross-platform migration of processes. Simultaneously, it signs, encrypts, verifies, and decrypts process execution tasks and executes them in an independent runtime container, improving the security and isolation of task transmission and execution. Updating the task status and node resource status based on the process execution results and container runtime status also provides accurate basis for subsequent task scheduling, thereby improving the cross-platform compatibility, resource utilization, and execution stability of process automation tasks. Attached Figure Description

[0009] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0010] Figure 1 This is a schematic diagram of the operating environment of the cross-platform process automation method provided in the embodiments of this application.

[0011] Figure 2 This is a schematic diagram of the execution flow of the cross-platform process automation method provided in the embodiments of this application.

[0012] Figure 3 This is a schematic diagram of the execution flow for determining the target execution node in the cross-platform process automation method provided in this application embodiment.

[0013] Figure 4 This is a schematic diagram of the execution flow for generating process execution tasks in the cross-platform process automation method provided in this application embodiment.

[0014] Figure 5 This is a schematic diagram of the system structure of the cross-platform process automation device provided in the embodiments of this application.

[0015] Figure 6 This is a schematic diagram of the hardware structure of an electronic device for executing a cross-platform process automation method provided in an embodiment of this application. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. Software tools, components, or servers not belonging to this company that appear in the embodiments of this application are merely illustrative examples and do not represent actual use.

[0017] It should be noted that, unless otherwise specified, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. Furthermore, although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device schematic diagram or the order in the flowchart.

[0018] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The term "and / or" as used in this specification includes any and all combinations of one or more of the associated listed items.

[0019] To facilitate understanding of this embodiment, a cross-platform process automation method disclosed in this application will first be described in detail. Please refer to [link to relevant documentation]. Figure 1 , Figure 1 This is a schematic diagram of the operating environment of the cross-platform process automation method provided in the embodiments of this application, such as... Figure 1 As shown, the execution subject of the cross-platform process automation method provided in this application embodiment is generally an electronic device with a certain computing power, such as a computer device. In some possible implementations, this cross-platform process automation method can be implemented by the processor calling computer-readable instructions stored in the memory. Figure 1 The computer equipment mentioned can be a server. A server can be a standalone server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. This can be understood as... Figure 1 The number of computer devices shown is merely illustrative and can be expanded in any number according to actual needs.

[0020] Please continue reading. Figure 2 , Figure 2 This is a schematic diagram of the execution flow of the cross-platform process automation method provided in the embodiments of this application, such as... Figure 2 As shown, it includes the following steps: S1. Obtain the visual process design operations in the target runtime environment, and convert the visual process design operations into standardized process definition information through the browser-side cross-environment execution module.

[0021] Specifically, the target runtime environment refers to the process automation runtime environment consisting of the target operating system, target browser, target processor, and corresponding runtime dependencies. Visual process design operations refer to the operations performed by the user in the process design interface, such as selecting, dragging, connecting, configuring parameters, and setting the execution order of process components. The browser-side cross-environment execution module is used to parse the visual process design operations and convert the interface operation data into process definition data represented using a unified data structure.

[0022] The browser-side cross-environment execution module can include a portable code execution unit, an operation parsing unit, and an instruction mapping unit. The portable code execution unit executes the process design logic in different browser runtime environments. The operation parsing unit extracts the component information, operation information, and parameter information corresponding to each operation. The instruction mapping unit converts interface operations into process component instructions according to a preset interface operation mapping relationship.

[0023] Standardized process definition information is used to uniformly describe the automated process to be executed. It can include process component identifiers, process component types, component operation parameters, component operation sequence, and connection relationships between process components, thereby providing a data foundation for subsequent process node parsing, process scheduling, and execution instruction adaptation.

[0024] For example, in fintech scenarios, users can configure process components such as account data acquisition, bill retrieval, data comparison, anomaly recording, and result output to form an automated reconciliation process. The browser-side cross-environment execution module collects the connection relationships, component parameters, and execution order of each process component and converts them into unified process definition information. In digital healthcare scenarios, users can configure process components such as patient information retrieval, examination data acquisition, diagnosis and treatment data comparison, anomaly recording, and result output to form a medical data processing process. The browser-side cross-environment execution module can convert the corresponding component operations, parameter configurations, and execution relationships into standardized process definition information.

[0025] As an optional implementation, the process of converting the visual process design operation into standardized process definition information through the browser-side cross-environment execution module in step S1 above may also include the following steps S11 to S14.

[0026] S11. Load the portable code execution unit in the browser of the target runtime environment.

[0027] The portable code execution unit is used to carry the processing logic required for process design operation parsing and process component instruction conversion. It is encapsulated in a portable instruction format supported by the target browser so that it can be loaded and executed in different browser runtime environments.

[0028] During loading, the browser type, version information, and available interface information of the target browser can be obtained. Based on this, the code execution configuration is determined, and the portable code execution unit is loaded into the target browser's runtime space. Then, the operation listening interface, component mapping interface, and data output interface are initialized, which are used to receive visual process design operations, call preset interface operation mapping relationships, and output conversion results, respectively.

[0029] After loading is complete, the availability status of each interface can be checked. If all interfaces are available, the portable code execution unit is considered successfully loaded. If any interface is missing or loading fails, corresponding exception information is generated.

[0030] S12. The visual process design operation is analyzed through the portable code execution unit to determine the interface component identifier, component operation type, component operation parameter and component operation sequence.

[0031] The interface component identifier is used to distinguish different process components in the process design interface. The component operation type describes operations such as adding, deleting, connecting, configuring parameters, and adjusting the order of components. The component operation parameters record parameters such as file location, target system address, data fields, judgment conditions, and output location. The component operation sequence describes the sequential relationship between different component operations.

[0032] The portable code execution unit can receive UI operation events generated in the browser and determine the UI component identifier and component operation type based on the operation object and event type. For parameter configuration operations, it reads the corresponding parameter values. For component connection and order adjustment operations, it determines the component operation order based on the connection direction and arrangement relationship between components.

[0033] For example, when a user connects a file reading component with a data comparison component, the corresponding UI component identifiers of the two components can be determined, parameters such as file address, data format and comparison fields can be read, and the execution order of the two components can be determined according to the connection direction.

[0034] S13. Based on the preset interface operation mapping relationship, convert the interface component identifier, component operation type and component operation parameter into process component instructions.

[0035] The preset interface operation mapping relationship is used to describe the correspondence between interface layer operations and process component instructions. It can include the mapping relationship between interface component identifier and process component type, the mapping relationship between component operation type and instruction type, and the mapping relationship between component operation parameters and instruction parameters.

[0036] During the conversion process, the flow component type can be determined based on the interface component identifier, the instruction type can be determined based on the component operation type, and the component operation parameters can be written into the corresponding instruction parameter field. For example, the add operation corresponding to the file reading component can be converted into a file reading instruction, and the component connection operation can be converted into an instruction connection relationship. For interface operations that are expressed differently in different browser environments but have the same operational semantics, they can be mapped to the same flow component instruction. For interface component identifiers or component operation types that cannot be matched, mapping exception information can be generated.

[0037] S14. Generate standardized process definition information based on process component instructions and component operation sequence.

[0038] This process involves generating corresponding process component records based on process component instructions, and writing the process component type, instruction type, and instruction parameters into the corresponding fields. Then, the sequential relationship between each process component is determined based on the order of component operations, and the connection relationships between process components are established. For branching, looping, or parallel processing relationships, the corresponding process structure is determined based on the component operation type and connection relationships, and written into the process structure field. After completing the organization of process component records and execution relationships, standardized process definition information is generated according to a preset process definition format.

[0039] During the generation process, the uniqueness of component identifiers, the completeness of instruction parameters, and the continuity of component connections can also be verified. If duplicate component identifiers, missing necessary parameters, or interrupted component connections exist, an exception message is generated in the process definition. After successful verification, standardized process definition information with a unified structure and clearly defined execution relationships is obtained.

[0040] As an example, in a fintech scenario, users sequentially configure components for account data acquisition, bill reading, data comparison, discrepancy recording, and result output. The browser-side cross-environment execution module parses the drag-and-drop, connection, and parameter configuration operations of each component, generates corresponding process component instructions, and establishes execution relationships according to the component operation order, forming standardized process definition information to describe the automated reconciliation process. In a digital healthcare scenario, users sequentially configure components for patient information reading, examination data acquisition, diagnosis and treatment data comparison, anomaly recording, and result output. The browser-side cross-environment execution module parses the selection, connection, and parameter configuration operations corresponding to each component, generates patient information reading instructions, examination data acquisition instructions, diagnosis and treatment data comparison instructions, anomaly recording instructions, and result output instructions, and establishes execution relationships according to the component operation order, forming standardized process definition information to describe the medical data processing flow.

[0041] Through steps S11 to S14 above, portable code execution units can be loaded into the browser of the target runtime environment, visual process design operations can be uniformly parsed, and interface operations can be converted into process component instructions. Further organizing the process component instructions according to the component operation sequence can form standardized process definition information with a unified structure and clear execution relationships, improving the compatibility of process design results and cross-environment migration efficiency.

[0042] As an optional implementation, the process of generating standardized process definition information based on process component instructions and component operation sequence in step S14 above may also include the following steps S141 to S143.

[0043] S141. Generate initial operation instructions based on process component instructions.

[0044] Among them, process component instructions are used to describe the operation type and operation parameters corresponding to the process component. According to the instruction type corresponding to the process component instruction, a target instruction template can be determined from a preset instruction template library, and the component operation parameters can be written into the parameter field corresponding to the target instruction template to obtain the initial operation instruction. Each process component instruction can correspond to one or more initial operation instructions, and the correspondence between process component instructions and initial operation instructions is established through component identifiers.

[0045] For example, for the file reading component, file access instructions and data reading instructions can be generated based on the file location, file format, and reading range; for the data comparison component, field extraction instructions and data comparison instructions can be generated based on the comparison fields and comparison conditions.

[0046] S142. Based on preset instruction optimization rules, while maintaining the process dependency relationship corresponding to the component operation order, the initial operation instructions are merged, parameters are reused, and the execution order is adjusted to obtain optimized operation instructions.

[0047] Process dependencies characterize the data transfer relationships and execution order relationships between different process components. Preset instruction optimization rules can include merging conditions, parameter reuse conditions, and order adjustment conditions. Instruction merging refers to combining multiple initial operation instructions with the same operation object and consecutive processing into a single operation instruction to reduce redundant calls. Parameter reuse refers to saving the parameter value obtained the first time when multiple initial operation instructions use the same parameter, and calling that parameter value in subsequent instructions. Execution order adjustment refers to adjusting the execution order of mutually independent initial operation instructions, or setting mutually independent initial operation instructions to execute in parallel, without changing the process dependencies.

[0048] During the optimization process, the process dependencies between initial operation instructions can be determined first based on the process component identifiers and component operation order. Then, initial operation instructions that can be merged, reused, or adjusted can be identified according to preset instruction optimization rules to obtain optimized operation instructions. For initial operation instructions with data dependencies, the original execution order is maintained to avoid changing the process processing results due to instruction optimization.

[0049] S143. Generate standardized process definition information based on optimized operation instructions and component operation sequence.

[0050] Specifically, optimization operation instructions can be arranged according to the component operation order, and sequential execution relationships, branch execution relationships, loop execution relationships, or parallel execution relationships can be established between optimization operation instructions. Then, the instruction identifier, instruction type, instruction parameters, and execution relationship corresponding to each optimization operation instruction are written into a preset process definition structure to obtain standardized process definition information.

[0051] During the generation process, the completeness of parameters and the continuity of execution relationships of optimized operation instructions can also be verified. When necessary parameters are missing, instruction connections are interrupted, or loop relationships are abnormal, corresponding process definition exception information is generated; when the verification passes, standardized process definition information is output.

[0052] As an example, in fintech scenarios, for process components such as account data acquisition, bill reading, and data comparison, corresponding initial operation instructions can be generated. Continuous data reading instructions can be merged, common parameters such as account identifiers and business dates can be reused, and the execution order of dependent instructions can be adjusted while maintaining data reading before data comparison, forming standardized process definition information for the automated reconciliation process. In digital healthcare scenarios, for process components such as patient information reading, examination data acquisition, diagnosis and treatment data comparison, and abnormal records, corresponding initial operation instructions can be generated. Access instructions targeting the same data interface can be merged, parameters such as patient identifiers and consultation times can be reused, and the order of independent data acquisition instructions can be adjusted or configured in parallel, forming standardized process definition information for the medical data processing process.

[0053] Through the above steps S141 to S143, the initial operation instructions can be merged, parameters reused, and execution order adjusted while maintaining process dependencies, thereby reducing duplicate instructions and duplicate parameter readings and improving the efficiency of generating standardized process definition information and process execution efficiency.

[0054] S2. Parse the standardized process definition information to obtain multiple process operation nodes and the execution relationships between them.

[0055] Specifically, standardized process definition information is used to describe the component types, operation parameters, and component connection relationships in an automated process. During parsing, the component identifier, component type, operation instructions, and component parameters corresponding to each process component can be read according to the preset process definition structure, and each process component is converted into a corresponding process operation node. Process operation nodes are used to represent single processing operations in an automated process and can include data reading nodes, interface operation nodes, data processing nodes, condition judgment nodes, and result output nodes. Each process operation node can include a node identifier, node type, operation parameters, input information, and output information. The node identifier is used to distinguish different process operation nodes, the node type is used to determine the corresponding processing function, and the operation parameters are used to limit the data location, operation object, and processing conditions used during node execution.

[0056] The execution relationships between multiple process operation nodes can be determined based on the component operation sequence and component connection relationships in the standardized process definition information. Execution relationships can include sequential execution relationships, branch execution relationships, loop execution relationships, and parallel execution relationships. For sequentially connected process components, a sequential execution relationship can be established between the preceding and following process operation nodes. For conditional decision components, execution relationships corresponding to different branches can be established based on the decision conditions. For loop components, the loop start node, loop end node, and loop condition can be determined. For independent process components, parallel execution relationships can be established.

[0057] During the parsing process, the integrity of connections and parameter correspondences between process operation nodes can also be verified. When there are non-starting nodes without preceding nodes, non-ending nodes without following nodes, or mismatched node inputs and outputs, process parsing exception information can be generated. After successful verification, multiple process operation nodes with a clearly defined structure and their corresponding execution relationships are obtained.

[0058] For example, in fintech scenarios, standardized process definition information can include process components such as account data acquisition, bill reading, data comparison, discrepancy recording, and result output. After parsing, the corresponding account data acquisition node, bill reading node, data comparison node, discrepancy recording node, and result output node can be obtained, establishing an execution relationship where data acquisition and bill reading precede data comparison, and data comparison precedes discrepancy recording and result output. In digital healthcare scenarios, standardized process definition information can include process components such as patient information reading, examination data acquisition, diagnostic data comparison, anomaly detection, and result output. After parsing, the corresponding process operation nodes can be obtained, and based on the component connection relationships, an execution relationship can be established where patient information reading and examination data acquisition precede diagnostic data comparison, and the diagnostic data comparison result triggers anomaly detection and result output.

[0059] Step S2 transforms standardized process definition information into process operation nodes with clear processing functions and establishes execution relationships between process operation nodes, providing a structured data foundation for subsequent process scheduling task generation, target execution node determination, and target execution instruction conversion.

[0060] S3. Generate process scheduling tasks based on multiple process operation nodes and execution relationships.

[0061] Specifically, a process scheduling task describes the node composition, execution logic, and operational requirements of the automated process to be scheduled, providing a basis for subsequent heterogeneous execution node matching. When generating a process scheduling task, the node type, operation parameters, input / output information, and operational dependencies of each process operation node can be extracted. Combined with the execution relationships between multiple process operation nodes, the node execution order and task execution path of the process can be determined. A process scheduling task can include a task identifier, a set of process operation nodes, execution relationships, processor architecture requirement data, operational dependency requirement data, and resource requirement data. The task identifier is used to distinguish different process scheduling tasks. Processor architecture requirement data describes the processor architecture supported or required by the process operation nodes. Operational dependency requirement data describes the operating system interface, runtime components, database interface, or browser environment required for process execution. Resource requirement data describes the processor resources, memory resources, and storage resources required for process operation.

[0062] During the generation process, the corresponding runtime requirements can be determined based on the node type and operation parameters of each process operation node. For example, memory resource requirements are determined based on the data scale of data processing nodes, storage resource requirements are determined based on the number and size of files in file processing nodes, and runtime dependency requirements are determined based on the target application corresponding to the interface operation node. For process operation nodes with parallel execution relationships, the resource requirements of parallel nodes can be aggregated to form the overall resource requirements corresponding to the process scheduling task. For processes with branch execution or loop execution, possible task execution paths can be determined based on branch conditions, loop conditions, and node execution relationships, and the node set and resource requirements corresponding to each execution path are written into the process scheduling task. After generating the process scheduling task, the correspondence between process operation nodes, execution relationships, and runtime requirements can be verified. When there are missing nodes, interrupted execution paths, or incomplete runtime requirements, task exception information can be generated.

[0063] For example, in fintech scenarios, automated reconciliation workflows can be scheduled based on nodes such as account data acquisition, bill reading, data comparison, discrepancy recording, and result output. Operational dependencies are determined based on the account interface and bill data source, while processor, memory, and storage resource requirements are determined based on the number of bills to be processed and the data scale. The execution relationships between each node are then used to form the task execution path. In digital healthcare scenarios, workflows can be scheduled based on nodes such as patient information reading, examination data acquisition, diagnostic data comparison, anomaly detection, and result output. Operational dependencies are determined based on the medical data interface and data processing components, resource requirements are determined based on the patient data volume and examination data scale, and the task execution path is organized according to the execution relationships between nodes.

[0064] Step S3 enables the organization of process operation nodes, execution relationships, and operational requirements into well-structured process scheduling tasks, providing a task data foundation for subsequent capability matching of heterogeneous execution nodes, resource evaluation, and target execution node determination.

[0065] S4. Obtain node capability information and resource status information of multiple heterogeneous execution nodes, and determine the target execution node based on the process scheduling task, node capability information, and resource status information.

[0066] Specifically, heterogeneous execution nodes refer to process task execution devices that employ different processor architectures, operating systems, system interfaces, or runtime components. Multiple heterogeneous execution nodes can form a process task execution node set, each providing node capability information and resource status information to the scheduler, enabling the scheduler to determine which execution node can handle the current process scheduling task. Node capability information describes the relatively stable task execution capabilities of the heterogeneous execution node, and may include information such as processor architecture, operating system type, system interface, runtime components, instruction type, available instruction adapters, and supported task types. Resource status information describes the dynamically changing resource usage of the heterogeneous execution node as the task runs, and may include information such as processor utilization, available memory, available storage space, current number of tasks, number of waiting tasks, and runtime load. Node capability information can be obtained during heterogeneous execution node registration or configuration updates, while resource status information can be collected at preset time intervals or updated when a task starts, ends, or when the resource status changes.

[0067] The process scheduling task records processor architecture requirements, runtime dependency requirements, and resource requirements. Processor architecture requirements define the processor architectures the process task can run on. Runtime dependency requirements define the operating system interfaces, runtime components, and instruction adapters required by the process task. Resource requirements describe the processor, memory, and storage resources required for the process task to run. When determining the target execution node, the node's capabilities are first matched against the processor architecture and runtime dependency requirements to eliminate heterogeneous execution nodes that cannot meet the basic operating conditions of the process task, resulting in multiple candidate execution nodes.

[0068] Based on the premise that the candidate execution nodes meet the basic operating conditions, the resource matching degree can be further determined by comparing resource demand data with the resource status information of each candidate execution node. Node scheduling characteristics are then formed by combining the historical success rate, historical execution duration, historical resource consumption, and historical anomalies of each candidate execution node in executing similar process tasks. A reinforcement learning scheduling model is used to comprehensively evaluate the node capabilities, resource matching degree, and historical execution performance to obtain the scheduling evaluation value for each candidate execution node. The target execution node is then determined based on the scheduling evaluation value.

[0069] After the process execution task is completed, a scheduling feedback value can be determined based on the process execution result and the container's running status, and this value can be used to update the reinforcement learning scheduling model. Positive scheduling feedback is generated when the target execution node successfully completes the process task and the actual execution time, resource consumption, and exception conditions meet expectations. Negative scheduling feedback is generated when the process task fails, resource consumption exceeds the preset range, or a container exception occurs. By continuously adjusting the node selection strategy using actual execution feedback, subsequent process scheduling can adapt to changes in the resource status and task execution capabilities of heterogeneous execution nodes.

[0070] Therefore, the determination of the target execution node is no longer based solely on the processor architecture or current idle resources, but rather comprehensively considers the operational requirements of the process task, the basic capabilities of the node, the real-time resource status, and historical execution performance. This reduces the likelihood of process tasks being assigned to execution nodes with mismatched architectures, missing operational dependencies, or insufficient resources, thereby improving the accuracy of heterogeneous execution node selection and the utilization rate of execution resources.

[0071] As an alternative implementation method, please continue reading. Figure 3 , Figure 3 This is a schematic diagram of the execution flow for determining the target execution node in the cross-platform process automation method provided in this application embodiment. For example... Figure 3 As shown, the process of determining the target execution node based on the process scheduling task, node capability information and resource status information in step S4 above may also include the following steps S41 to S46.

[0072] S41. Extract processor architecture requirement data, runtime dependency requirement data, and resource requirement data from the process scheduling task.

[0073] The processor architecture requirements describe the processor architecture that the process task can run on or will prioritize. The runtime dependency requirements describe the operating system interfaces, runtime components, database interfaces, browser environment, and instruction set plugins required for process execution. The resource requirements describe the processor resources, memory resources, storage resources, and estimated execution time required by the process task.

[0074] During the extraction process, the execution requirements corresponding to each process operation node in the process scheduling task can be read and summarized according to the execution relationship. For sequentially executed process operation nodes, the task resource requirements can be determined based on the maximum resource requirements of each node. For parallel executed process operation nodes, the resource requirements corresponding to the parallel nodes can be merged to obtain the overall resource requirements corresponding to the process scheduling task.

[0075] S42. Based on the processor architecture requirements data and runtime dependency requirements data, match the node capability information of multiple heterogeneous execution nodes to obtain multiple candidate execution nodes.

[0076] Specifically, processor architecture requirements can be matched with the processor architectures supported by each heterogeneous execution node, and runtime dependency requirements can be matched with the system interfaces, runtime components, and instruction adaptation plugins available on each heterogeneous execution node. When the processor architecture of a heterogeneous execution node meets the requirements and has the runtime dependencies required by the process task, that heterogeneous execution node is identified as a candidate execution node. When the processor architecture or necessary runtime dependencies do not match, the corresponding heterogeneous execution node is excluded. For heterogeneous execution nodes lacking non-essential runtime components but which can be supplemented by plugin loading, plugin loading information can be written into the corresponding matching results.

[0077] S43. Based on the resource requirement data and the resource status information of each candidate execution node, determine the resource matching information corresponding to each candidate execution node, and obtain the historical task execution information corresponding to each candidate execution node.

[0078] Resource matching information is used to characterize the degree to which the currently available resources of candidate execution nodes meet the resource requirements of the process tasks. It compares resource requirement data with the available processor resources, available memory, available storage space, and current operating load of candidate execution nodes to obtain information such as resource satisfaction level, remaining resource ratio, and estimated waiting time. Historical task execution information characterizes the historical performance of candidate execution nodes in executing similar process tasks, and can include historical task execution success rate, average execution time, resource consumption, number of exceptions, and number of task interruptions. Historical task execution information can be categorized according to process task type, processor architecture, or runtime dependencies to improve the correlation between historical information and current process scheduling tasks.

[0079] As an optional implementation, the reinforcement learning scheduling model can be an evaluation model for node scheduling based on state-action value, comprising a state feature input layer, a task feature extraction layer, a node feature extraction layer, a feature fusion layer, and an evaluation output layer. The state feature input layer is connected to both the task feature extraction layer and the node feature extraction layer, which are then connected to the feature fusion layer. The feature fusion layer is connected to the evaluation output layer.

[0080] The status feature input layer receives the task requirement features corresponding to the process scheduling task and the node operation features corresponding to the candidate execution nodes. Task requirement features may include processor architecture requirement encoding, runtime dependency requirement encoding, processor resource requirements, memory resource requirements, storage resource requirements, and estimated execution time. Node operation features may include processor architecture matching results, runtime dependency matching results, processor availability ratio, memory availability ratio, storage availability ratio, current running load, number of tasks to be executed, historical task execution success rate, historical average execution time, and historical anomaly rate.

[0081] The task feature extraction layer extracts task requirement representations corresponding to task requirement features, and the node feature extraction layer extracts node running status representations corresponding to node running features. The feature fusion layer fuses the task requirement representations and node running status representations to determine the fit between the process scheduling task and the candidate execution node. The evaluation output layer outputs a scheduling evaluation value based on the fusion result when assigning the process scheduling task to the corresponding candidate execution node.

[0082] In the reinforcement learning scheduling process, the task requirements, node capabilities, resource matching, and historical task execution information of the scheduling task are used to determine the current scheduling state. Then, a candidate execution node is selected from multiple candidate nodes to serve as the scheduling action. The reinforcement learning scheduling model evaluates the expected execution effect of different scheduling actions based on the current scheduling state, thereby obtaining the scheduling evaluation value for each candidate execution node.

[0083] S44. Input the node capability information, resource matching information and historical task execution information of each candidate execution node into the reinforcement learning scheduling model to obtain the scheduling evaluation value corresponding to each candidate execution node.

[0084] Specifically, processor architecture requirements, runtime dependency requirements, and resource requirements in the process scheduling task can be converted into task requirement features, and node capability information, resource matching information, and historical task execution information of candidate execution nodes can be converted into node runtime features. For categorical data such as processor architecture and runtime dependencies, they can be converted into corresponding categorical features according to preset encoding relationships. For numerical data such as processor utilization, available memory, available storage space, estimated waiting time, historical execution success rate, and historical anomaly rate, normalization processing can be performed according to the corresponding value ranges of each data point. Subsequently, the processed task requirement features and node runtime features are organized into scheduling status features corresponding to the candidate execution nodes.

[0085] The reinforcement learning scheduling model processes task requirement features through a task feature extraction layer to obtain a task requirement representation, and processes node running features through a node feature extraction layer to obtain a node running state representation. A feature fusion layer fuses the task requirement representation and the node running state representation to obtain a fused scheduling feature between the scheduled task and the candidate execution node. The evaluation output layer outputs a corresponding scheduling evaluation value based on the fused scheduling feature. The scheduling evaluation value characterizes the expected execution effect after assigning the current scheduled task to the corresponding candidate execution node. A higher scheduling evaluation value is awarded for a candidate execution node whose processor architecture and runtime dependencies better match the task requirements, has more available resources, a higher historical task execution success rate, and a lower historical anomaly rate.

[0086] S45. Based on the scheduling evaluation value, determine the target execution node from multiple candidate execution nodes.

[0087] This process involves comparing the scheduling evaluation values ​​of multiple candidate execution nodes and identifying the candidate execution node with the highest scheduling evaluation value as the target execution node. The operation of selecting the target execution node is defined as the scheduling action corresponding to the current scheduling state, and the scheduling state characteristics, target execution node identifier, scheduling evaluation value, and scheduling action are recorded.

[0088] When multiple candidate execution nodes have the same scheduling evaluation value, the current running load, expected waiting time, and historical task execution success rate of the candidate execution nodes can be compared sequentially to determine the target execution node. For example, candidate execution nodes with lower current running load can be selected first; if the current running load is the same, candidate execution nodes with shorter expected waiting time can be selected.

[0089] During the training phase of the reinforcement learning scheduling model, candidate execution nodes with non-highest scheduling evaluation values ​​can be selected from multiple candidate execution nodes according to preset exploration probabilities to obtain the process execution results corresponding to different scheduling actions. During the model application phase, the candidate execution node with the highest scheduling evaluation value can be selected to improve the expected execution effect of the process task.

[0090] After determining the target execution node, a correspondence can be established between the task identifier of the process scheduling task and the node identifier of the target execution node. The current scheduling status characteristics and scheduling actions can be saved to provide a data foundation for scheduling feedback and model updates after the process execution task is completed.

[0091] S46. Determine the scheduling feedback value based on the process execution result and container running status, and update the reinforcement learning scheduling model based on the scheduling feedback value.

[0092] Upon completion of the task execution, the task success status and result integrity status can be extracted from the process execution results. The actual execution duration, processor resource usage, memory resource usage, storage resource usage, execution exception status, and container exit status can be extracted from the container running status. The scheduling feedback value can be determined based on the task success status, actual execution duration, resource usage, and execution exception status. Specifically, a success feedback component can be determined based on the task success status, a duration feedback component based on the actual execution duration, a resource feedback component based on processor resource usage, memory resource usage, and storage resource usage, and an exception feedback component based on the execution exception status and container exit status. The scheduling feedback value can be determined based on the weighted result of the success feedback component, duration feedback component, resource feedback component, and exception feedback component. As an example, the scheduling feedback value can be determined according to the following relationship: Scheduling feedback value = Success weight × Task execution success flag - Duration weight × Normalized execution duration - Resource weight × Normalized resource usage - Abnormal weight × Execution abnormal flag.

[0093] When a task executes successfully, the success flag can be set to 1; when a task fails, it can be set to 0. When an execution exception occurs or the container exits abnormally, the exception flag can be set to 1; when no exception occurs, it can be set to 0. Actual execution time and resource consumption can be normalized according to their respective preset value ranges. Success weight, duration weight, resource weight, and exception weight can be preset according to the scheduling objectives of the process task.

[0094] A higher scheduling feedback value is generated when the process execution task is successfully completed, the execution time is short, the actual resource usage meets the resource requirements, and no execution exception occurs. A lower scheduling feedback value is generated when the process execution task fails, the actual execution time exceeds the preset time, the resource usage exceeds the preset range, or an execution exception occurs.

[0095] After the process execution task is completed, the resource status information of multiple heterogeneous execution nodes can be retrieved again, and the next scheduling state can be determined based on the updated resource status information. Model training samples are generated based on the current scheduling state characteristics, scheduling actions, scheduling feedback values, and the next scheduling state, and the model training samples are written into the training sample set.

[0096] In one implementation, the target evaluation value can be determined based on the scheduling feedback value, a preset discount coefficient, and the maximum scheduling evaluation value corresponding to the next scheduling state. The target evaluation value can be determined according to the following relationship: Target evaluation value = scheduling feedback value + preset discount coefficient × maximum scheduling evaluation value corresponding to the next scheduling state.

[0097] When the task being executed in the current process is determined to be the terminated task of the current scheduling process, the maximum scheduling evaluation value corresponding to the next scheduling state can be set to 0. The model loss value is determined based on the difference between the target evaluation value and the current scheduling evaluation value output by the reinforcement learning scheduling model, and the model parameters of the task feature extraction layer, node feature extraction layer, feature fusion layer, and evaluation output layer are adjusted according to the preset learning rate.

[0098] The reinforcement learning scheduling model can be updated after each task is completed, or it can be updated by accumulating a predetermined number of training samples in the training sample set and then extracting training samples from the set in batches. By using training samples from multiple task executions to update the reinforcement learning scheduling model, the excessive influence of the result of a single task on the model parameters can be reduced.

[0099] As an example, in a fintech scenario, the processor architecture requirements, database interface requirements, memory resource requirements, storage resource requirements, and estimated execution time for the automated reconciliation process can be converted into task requirement features. The processor architecture matching results, database interface support, available memory, current task load, historical reconciliation task execution success rate, and historical average execution time for each candidate execution node can be converted into node running features. A reinforcement learning scheduling model outputs a scheduling evaluation value for each candidate execution node based on the task requirement features and node running features, and selects the candidate execution node with the higher scheduling evaluation value to execute the automated reconciliation process. After task execution, a scheduling feedback value is determined based on whether the reconciliation task was successful, the actual execution time, resource consumption, and anomaly occurrence. Model training samples are then generated based on the current scheduling status, the target execution node, the scheduling feedback value, and the updated node resource status. In a digital healthcare scenario, medical data interface requirements, patient data volume, examination data volume, and resource requirements can be converted into task requirement features. The medical data interface support, current available resources, historical medical data processing success rate, historical average execution time, and historical anomaly occurrence rate for each candidate execution node can be converted into node running features. The reinforcement learning scheduling model outputs a scheduling evaluation value based on the scheduling state characteristics of each candidate execution node, and determines the target execution node for executing the medical data processing flow. After the medical data processing is completed, a scheduling feedback value is generated based on the completeness of the processing results, the actual execution time, resource consumption, and abnormal container status, and the reinforcement learning scheduling model is updated using the corresponding model training samples.

[0100] Through steps S41 to S46, the task requirements information of the process scheduling task and the node operation information of candidate execution nodes can be organized into scheduling state features. The expected execution effect corresponding to different candidate execution nodes is then evaluated using a reinforcement learning scheduling model. Scheduling feedback values ​​are generated based on the process execution results, actual execution time, resource consumption, and execution anomalies. The reinforcement learning scheduling model is updated using the current scheduling state, scheduling actions, scheduling feedback values, and the next scheduling state. This forms a closed-loop scheduling mechanism between heterogeneous execution node selection and actual task execution feedback, improving the accuracy of target execution node selection and the utilization rate of execution resources.

[0101] S5. Determine the target processor architecture of the target execution node, load the corresponding instruction adapter plugin based on the microkernel architecture, convert multiple process operation nodes into target execution instructions, and generate process execution tasks by combining execution relationships.

[0102] Specifically, different heterogeneous execution nodes may employ different processor architectures, operating systems, and system interfaces. The instruction formats and interface calling methods corresponding to the same process operation node may also differ across different execution nodes. Developing complete process execution programs for each type of processor architecture would couple the process logic with the underlying runtime environment, requiring instruction conversion and interface adaptation to be performed again during process migration.

[0103] The microkernel architecture provides fundamental functions such as plugin registration, plugin loading, instruction delivery, and runtime management, while encapsulating adaptation logic related to specific processor architectures and system interfaces into independent instruction adaptation plugins. The microkernel architecture retains the general processing functions required for task execution and does not directly limit the target processor architecture. Different instruction adaptation plugins record their supported processor architectures, system interfaces, and instruction translation rules, allowing for dynamic selection and loading based on the node capabilities of the target execution node. Therefore, when adding a new processor architecture or system runtime environment, adaptation can be achieved by adding or updating the corresponding instruction adaptation plugins without changing the process design logic or the fundamental functionality of the microkernel architecture.

[0104] After identifying the target execution node, its processor architecture identifier and system interface information can be read. A target instruction adapter plugin matching the target processor architecture and system interface can be selected from the instruction adapter plugin library. Then, the target instruction adapter plugin is loaded through a microkernel architecture to perform semantic parsing of the node types, operation objects, operation parameters, and input / output relationships of multiple process operation nodes, forming intermediate operation instructions independent of the specific processor architecture. The target instruction adapter plugin dynamically compiles the intermediate operation instructions according to the instruction conversion rules corresponding to the target processor architecture, mapping the general interface calls in the intermediate operation instructions to system interface calls that the target execution node can provide, resulting in target execution instructions that the target execution node can recognize and execute. Target execution instructions can include operation instructions, instruction parameters, data input / output information, and system interface call information. Finally, the target execution instructions are organized according to the sequential execution relationship, branch execution relationship, loop execution relationship, or parallel execution relationship between multiple process operation nodes to generate a process execution task adapted to the target execution node's runtime environment.

[0105] Therefore, a relatively independent adaptation relationship is formed between the process design logic and the underlying processor architecture and system interface, enabling the same standardized process to run on different heterogeneous execution nodes by loading different instruction adaptation plugins, thereby reducing the adaptation cost when migrating process tasks across processor architectures and system environments.

[0106] As an alternative implementation method, please continue reading. Figure 4 , Figure 4This is a schematic diagram of the execution flow for generating process execution tasks in the cross-platform process automation method provided in this application embodiment. For example... Figure 4 As shown, the process of generating the process execution task in step S5 above may also include the following steps S51 to S55.

[0107] S51. Read the processor architecture identifier and system interface information from the node capability information of the target execution node, and determine the target processor architecture based on the processor architecture identifier.

[0108] The processor architecture identifier characterizes the processor instruction architecture used by the target execution node. System interface information describes the file access, network communication, process invocation, database access, and user interface (UI) operations that the target execution node can provide. The corresponding node capability information can be read based on the target execution node's node identifier, from which the processor architecture identifier and system interface information can be extracted. The processor architecture identifier is then matched against a pre-defined list of processor architectures to determine the target processor architecture. For unrecognized processor architecture identifiers, an architecture identification error message can be generated, halting the subsequent instruction adaptation process.

[0109] S52. Determine the target instruction adapter plugin from the instruction adapter plugin library that matches the processor architecture identifier and system interface information.

[0110] The instruction adapter plugin library stores instruction adapter plugins corresponding to different processor architectures and system interfaces. Each instruction adapter plugin can have attribute information such as plugin identifier, supported processor architecture, applicable system interface, plugin version, and instruction conversion rules. Instruction adapter plugins supporting the target processor architecture can be filtered based on the processor architecture identifier. Then, based on the system interface information, it can be determined whether each instruction adapter plugin supports the system interface required for process execution. The instruction adapter plugin that simultaneously meets both processor architecture and system interface requirements is identified as the target instruction adapter plugin. When multiple matching plugins exist, selection can be made based on plugin version, interface coverage, or historical operational stability.

[0111] S53. Load the target instruction adapter plugin through the microkernel architecture and perform node semantic parsing on multiple process operation nodes to obtain intermediate operation instructions.

[0112] The microkernel architecture provides plugin registration and instruction interaction interfaces. When loading a target instruction adapter plugin, it reads the plugin identifier and plugin invocation information, registers the target instruction adapter plugin with the microkernel architecture, and establishes the instruction transmission relationship between the microkernel architecture and the target instruction adapter plugin. Node semantic parsing identifies the operation object, operation type, operation parameters, and input / output relationships corresponding to each process operation node. It can read the node information of each process operation node according to the node type and convert the node information into processor architecture-independent intermediate operation instructions. These intermediate operation instructions uniformly describe the process operation logic, providing the instruction foundation for subsequent dynamic compilation and interface mapping.

[0113] S54. The intermediate operation instructions are dynamically compiled through the target instruction adaptation plugin, and the interface is mapped according to the system interface information to obtain the target execution instructions.

[0114] Dynamic compilation is used to convert intermediate operation instructions into architecture-adaptive instructions that can be executed by the target execution node, based on the target processor architecture. Interface mapping is used to convert general interface calls in intermediate operation instructions into system interface calls provided by the target execution node. The target instruction adaptation plugin can read the operation type and operation parameters of the intermediate operation instructions, call the compilation rules corresponding to the target processor architecture to generate architecture-adaptive instructions, and map general interfaces such as file access, network communication, database access, and UI operations to the corresponding target system interfaces based on system interface information. After completing dynamic compilation and interface mapping, the target execution instructions are obtained.

[0115] S55. Generate a process to execute tasks based on the target execution instructions and execution relationships.

[0116] Specifically, according to the correspondence between process operation nodes and target execution instructions, each target execution instruction can be written into the corresponding task node, and the instruction execution relationship between task nodes can be established based on sequential execution relationship, branch execution relationship, loop execution relationship and parallel execution relationship.

[0117] A process execution task can include a task identifier, target execution instructions, instruction execution relationships, instruction parameters, data input / output information, and target execution node identifier. During generation, the completeness of the target execution instructions, interface mapping results, and instruction execution relationships can also be verified. If a target execution instruction is missing, interface mapping fails, or the execution relationship is interrupted, an exception message is generated. After successful verification, a process execution task that can be executed by the target execution node is obtained.

[0118] As an example, in fintech scenarios, a corresponding target instruction adapter plugin can be selected from an instruction adapter plugin library based on the processor architecture and database interface information of the target execution node. Through this plugin, intermediate operation instructions for account data acquisition, bill reading, and data comparison nodes are dynamically compiled into target execution instructions, and a general database access interface is mapped to the database interface provided by the target execution node, generating the workflow execution task corresponding to the automated reconciliation process. In digital healthcare scenarios, a corresponding target instruction adapter plugin can be loaded based on the processor architecture and medical data interface information of the target execution node. This converts patient information reading, examination data acquisition, and diagnosis data comparison nodes into target execution instructions, and organizes these instructions according to the execution relationships between each workflow operation node, generating the workflow execution task corresponding to the medical data processing process.

[0119] Through the above steps S51 to S55, the corresponding instruction adaptation plugin can be dynamically loaded according to the processor architecture and system interface of the target execution node, and the platform-independent process operation node can be converted into the target execution instruction adapted to the target execution node, thereby improving the running compatibility of process tasks in different processor architectures and system environments and reducing the difficulty of cross-platform process migration.

[0120] S6. Sign and encrypt the process execution task, send the signed and encrypted process execution task to the target execution node, and verify and decrypt the signature through the target execution node.

[0121] Specifically, a process execution task may include target execution instructions, instruction parameters, execution relationships, data input / output information, and target execution node identifiers. Signatures are used to verify the source and integrity of the process execution task, while encryption prevents unauthorized reading or modification during transmission. By signing the task summary information and encrypting the process execution task, the source and content of the task can be securely verified without exposing its specific details.

[0122] After the process execution task is generated, the task content can be extracted according to a preset data range and data arrangement order, and a task digest information can be generated using a preset digest algorithm. Subsequently, the task digest information is signed using a preset signature algorithm to obtain the task signature, and the process execution task is encrypted using a preset encryption algorithm to obtain the encrypted process execution task. The task signature and the encrypted process execution task can be combined with the task identifier, signature algorithm identifier, and encryption algorithm identifier to form task transmission data and sent to the target execution node.

[0123] After receiving the task transmission data, the target execution node does not directly load the process to execute the task. Instead, it first calls the hardware-assisted security detection unit to perform integrity checks on the target execution node's startup program, operating system kernel, critical runtime components, instruction adaptation plugins, and container runtime components. The hardware-assisted security detection unit can read the current measurement information corresponding to each detection object and compare the current measurement information with pre-saved trusted measurement information to determine whether the target execution node is in a trusted running state.

[0124] When the runtime environment integrity check passes, the target execution node obtains the decryption information corresponding to the preset encryption algorithm, decrypts the encrypted process execution task, and generates verification digest information based on the data range, data arrangement order, and digest algorithm used by the sender when generating the task digest information. Subsequently, the task signature is verified based on the verification digest information to determine whether the decrypted process execution task is from a trustworthy source and has complete content.

[0125] When the runtime environment integrity check fails, the encrypted process execution task decryption fails, or the task signature verification fails, the corresponding security processing flow is stopped, and the process execution task is prevented from being loaded into the independent running container. When the integrity check, decryption, and signature verification all pass, the decrypted process execution task is allowed to be passed to the subsequent container execution process. Thus, runtime environment trust checks are combined with task transmission security verification, reducing the possibility of abnormal runtime environments or abnormal process execution tasks entering the actual execution stage.

[0126] As an optional implementation, the process of performing security processing on the process execution task in step S6 above may also include the following steps S61 to S66.

[0127] S61. Generate task summary information by executing tasks according to the process.

[0128] The task summary information is used to characterize the content features of the process execution task. It can extract the task identifier, target execution instruction, instruction parameters, execution relationships, and target execution node identifier from the process execution task according to a preset data arrangement order, and organize the extracted data into data to be summarized. Then, a preset summarization algorithm is used to process the data to be summarized to obtain fixed-length task summary information. When the target execution instruction, instruction parameters, or execution relationships in the process execution task change, the corresponding task summary information changes accordingly, thus providing a basis for subsequent task integrity verification.

[0129] S62. Sign the task digest information using a preset signature algorithm to obtain the task signature, and encrypt the process execution task using a preset encryption algorithm to obtain the encrypted process execution task.

[0130] Specifically, the system can obtain the signature key corresponding to the task sender, and use a preset signature algorithm to sign the task digest information to obtain the task signature. The task signature is used to verify whether the process execution task originates from a trusted task sender and to determine whether the task content has changed during transmission. Simultaneously, the system can obtain the encryption key corresponding to the process execution task, and use a preset encryption algorithm to encrypt the task identifier, target execution instructions, instruction parameters, execution relationships, and data input / output information to obtain the encrypted process execution task. The encryption key can be generated based on the target execution node and stored and transmitted using a preset key management method.

[0131] S63. Send the task signature and encryption process execution task to the target execution node.

[0132] Specifically, the corresponding task receiving address can be determined based on the target execution node identifier recorded in the process execution task. The task signature, encrypted process execution task, signature algorithm identifier, encryption algorithm identifier, and task identifier are then organized into task transmission data. Before sending, the integrity of the fields in the task transmission data can be verified. After receiving the task transmission data, the target execution node can establish a task receiving record based on the task identifier and write the task signature and encrypted process execution task into the corresponding secure storage area, awaiting subsequent integrity checks, decryption, and signature verification.

[0133] S64. The hardware-assisted security detection unit is invoked through the target execution node to perform integrity detection on the operating environment of the target execution node.

[0134] The hardware-assisted security detection unit is used to detect whether the runtime environment of the target execution node is in a trusted state based on hardware security capabilities. The integrity detection objects can include the target execution node's bootloader, operating system kernel, critical runtime components, instruction adapter plugins, and container runtime components. During the detection process, the current measurement information corresponding to each detection object can be read and compared with pre-saved trusted measurement information. When the current measurement information of each detection object conforms to the trusted measurement information, the integrity detection is deemed successful. When any detection object is modified, missing, or in an abnormal running state, the integrity detection is deemed unsuccessful, and corresponding security exception information is generated.

[0135] S65. When the integrity check passes, the encryption process execution task is decrypted, and verification digest information is generated based on the decrypted process execution task.

[0136] The target execution node can obtain the corresponding decryption key based on the encryption algorithm identifier and decrypt the encryption process execution task to obtain the task identifier, target execution instruction, instruction parameters, execution relationship, and data input / output information. After decryption, the decrypted process execution task is processed according to the data range, data arrangement order, and digest algorithm used when generating the task digest information to obtain the verification digest information. If a key mismatch, abnormal data format, or incomplete task content occurs during the decryption process, decryption is determined to have failed, and the subsequent task loading process is stopped.

[0137] S66. Verify the task signature based on the verification digest information. If the integrity check fails, decryption fails, or signature verification fails, prevent the process execution task from being loaded into an independent running container.

[0138] This process involves obtaining the signature verification key corresponding to the task sender and verifying the task signature based on the verification digest information. When the task signature matches the verification digest, the signature verification is successful, indicating that the decrypted execution task origin is trustworthy and its content is complete. When the task signature does not match the verification digest, the signature verification is unsuccessful.

[0139] If the integrity check fails, the decryption process is stopped. If decryption fails, the signature verification process is stopped. If signature verification fails, the corresponding process execution task is marked as a verification exception. In any of the above cases, the process execution task is prevented from being loaded into a standalone running container, and the task identifier, target execution node identifier, and exception type are recorded. If the integrity check, decryption, and signature verification all pass, the decrypted process execution task is allowed to be passed to the subsequent container execution process.

[0140] As an example, in fintech scenarios, task summary information can be generated based on the target execution instructions, account interface parameters, and execution relationships corresponding to the automated reconciliation process. This task summary information is then signed and the automated reconciliation process execution task is encrypted. Upon receiving the task, the target execution node checks the integrity of the operating system, database access components, and container runtime components. If the checks pass, the task is decrypted and its signature is verified, preventing tampering of account data processing instructions before transmission or execution. In digital healthcare scenarios, task summary information can be generated based on patient information reading instructions, examination data acquisition instructions, and diagnostic data comparison instructions in the medical data processing process. This task is then signed and encrypted. The target execution node checks the integrity of the medical data interface components, instruction adaptation plugins, and container runtime components, and then completes task decryption and signature verification, preventing unauthorized reading or modification of medical data processing instructions.

[0141] Through the above steps S61 to S66, source verification, content integrity protection, and transmission encryption can be performed on the process execution task. Combined with the integrity detection of the target execution node's operating environment, abnormal process execution tasks are prevented from entering the independent running container, thereby improving the security of process task transmission and execution.

[0142] S7. When the signature verification is successful and the decryption is successful, control the target execution node to execute the decrypted process execution task in an independently running container, obtain the process execution result and the container running status, and update the task status of the process execution task and the resource status information of the target execution node according to the process execution result and the container running status.

[0143] Specifically, the standalone running container provides a runtime space isolated from other tasks on the target execution node for the process execution task. After successful signature verification and decryption, the processor resources, memory resources, storage resources, and system interfaces required during execution can be determined based on the decrypted process execution task, and a standalone running container corresponding to the process execution task can be created. By limiting the container's resource quotas, data access scope, and system interface access permissions, resource contention and data interference between different process execution tasks can be reduced. After the process execution task is loaded into the standalone running container, the corresponding instructions are executed sequentially or in parallel according to the execution relationship between the target execution instructions, and the execution output, completion status, and exception information of each target execution instruction are collected. During execution, the container's resource usage and operational exceptions are monitored synchronously. After the task is completed, the task status is updated based on the process execution results, and the resources occupied by the container are released to update the resource status information of the target execution node.

[0144] As an optional implementation, the process of executing the decrypted process execution task in an independent running container in step S7 above may also include the following steps S71 to S75.

[0145] S71. Determine resource requirement data by performing tasks according to the decrypted process.

[0146] This process can parse and decrypt the execution task, read the target execution instructions, instruction parameters, data input / output information, and execution relationships, and determine processor resource requirements, memory resource requirements, storage resource requirements, and system interface access requirements based on the processing type and amount of data to be processed for each target execution instruction. For target execution instructions executed sequentially, resource requirements can be determined based on the target execution instructions that consume the most resources simultaneously during execution. For target execution instructions executed in parallel, the resource requirements corresponding to the target execution instructions running concurrently can be summarized. For target execution instructions executed in a loop, the estimated execution time and resource consumption can be determined by combining the number of loop iterations, the loop condition, and the amount of data processed per iteration.

[0147] S72. Create an independent running container corresponding to the process execution task, and configure the processor resources, memory resources, storage resources and system interface access permissions of the independent running container according to the resource requirement data.

[0148] Specifically, independent running containers can be created based on the task identifiers of the process execution tasks, and a mapping relationship between task identifiers and container identifiers can be established. Based on resource requirement data, processor time, memory space, and storage space are allocated to the independent running containers, and corresponding resource usage limits are set to prevent a single process execution task from consuming node resources exceeding a preset range. System interface access permissions are used to restrict the file access interfaces, network communication interfaces, database interfaces, and user interface operation interfaces that the process execution tasks can call. Corresponding interfaces can be opened according to the actual operational requirements of the target execution instructions, and the accessible data directories, network addresses, database objects, and target applications can be restricted. System interfaces that the process execution tasks do not need to call can remain in a prohibited state.

[0149] After creation, you can also check the resource configuration and interface permission configuration results of the independently running container. When the allocated resources are lower than the resource requirements or necessary system interfaces are not open, you can adjust the resource configuration or generate container creation exception information to avoid loading the process to execute tasks when the running conditions are incomplete.

[0150] S73. Load the decrypted process execution task into an independent running container, execute the target execution instructions according to the execution relationship, and isolate the running resources and task data between different process execution tasks.

[0151] Specifically, the system can load the target execution instructions, instruction parameters, execution relationships, and data input / output information from the process execution task into independent running containers, and determine the start conditions and execution order of each target execution instruction based on the execution relationships. For sequential execution relationships, the next target execution instruction can be started after the previous one has been executed. For branch execution relationships, the corresponding target execution instruction can be selected based on the result of a condition judgment. For loop execution relationships, the corresponding target execution instructions can be repeatedly executed according to the loop condition. For parallel execution relationships, target execution instructions that do not have data dependencies on each other can be executed simultaneously.

[0152] Different process execution tasks are executed in their respective independent running containers, each using isolated processor resource quotas, memory space, and storage areas. Task data can be stored in the independent data space of the corresponding container, and access permissions can be used to restrict other process execution tasks from reading or modifying it, thereby reducing the possibility of interference between different process execution tasks.

[0153] S74. Monitor the resource usage and execution anomaly status of independently running containers to obtain process execution results and container running status.

[0154] This process can collect the instruction output, execution progress, completion status, and exception information corresponding to each target execution instruction during the execution process. The instruction output is then organized according to the execution relationships between the target execution instructions to obtain the process execution result. The process execution result can include task output data, the execution status of each target execution instruction, and whether the process has been completed.

[0155] Simultaneously, it can monitor the processor utilization, memory usage, storage usage, API call status, and continuous runtime of independently running containers. When resource usage exceeds the corresponding resource usage limit, target execution instructions fail, system API calls fail, or the container exits abnormally, the corresponding exception type and location can be recorded. The container running status is generated based on resource usage status, execution exception status, and container exit status. The container running status can be used to characterize whether the independently running container is operating normally, whether resource shortages have occurred, and whether the process execution task has been completely completed.

[0156] S75. Based on the process execution results and container running status, update the task status of the process execution task and the resource status information of the target execution node.

[0157] Specifically, the task status of a process execution task can be determined based on whether the process execution result is complete, whether each target execution instruction was executed successfully, and whether the independently running container exited normally. When all target execution instructions are executed successfully and the container exits normally, the task status is updated to "Execution Completed." When any target execution instruction fails, the task status is updated to "Execution Failed." When the container experiences resource overruns, interface exceptions, or abnormal exits, the task status is updated to "Execution Exception," and the corresponding exception information is recorded.

[0158] After the process execution task is completed, the processor, memory, and storage resources occupied by the independently running container can be released, access permissions to system interfaces opened during task execution can be closed, and temporary task data in the container can be cleaned up. Then, the available resources, current number of tasks, and running load of the target execution node can be retrieved again, and the resource status information of the target execution node can be updated to provide a basis for subsequent process scheduling tasks to select execution nodes.

[0159] As an example, in a fintech scenario, resource requirements can be determined based on the number of bills, data comparison instructions, and result output instructions corresponding to the automated reconciliation process. An independent running container can then be created, and access permissions for the account data interface, bill storage area, and result output directory can be configured. Within the container, target execution instructions are run according to the execution relationship of account data acquisition, bill reading, data comparison, and difference output, while monitoring the container's memory usage and instruction execution status. Upon task completion, reconciliation results are generated, container resources are released, and the task status of the automated reconciliation process and the resource status information of the target execution node are updated. In a digital healthcare scenario, resource requirements can be determined based on target execution instructions such as patient information reading, examination data acquisition, diagnosis and treatment data comparison, and abnormal records. An independent running container can then be created, and access permissions for the patient data storage area and medical data interface can be limited. Within the container, patient information and examination data are processed according to the execution relationship, isolating the data spaces corresponding to different medical data processing tasks, and monitoring the container's resource usage and interface call anomalies. Upon task completion, the medical data processing results and container running status are obtained, and the task status of the process execution task and the resource status information of the target execution node are updated.

[0160] Through steps S71 to S75, independently running containers can be configured according to the resource requirements of the process execution tasks, and different process execution tasks can be isolated through resource quotas, system interface permissions, and task data space. Combined with resource monitoring and anomaly monitoring during process execution, the process execution results and container running status can be accurately obtained, and container resources can be released, task status and node resource status can be updated in a timely manner, thereby improving the security and stability of process execution.

[0161] The cross-platform process automation method provided in this application converts visual process design operations into standardized process definition information through a browser-side cross-environment execution module. This reduces the impact of different browsers and operating system environments on process design results, improving the compatibility of process definitions and the efficiency of cross-environment migration. Process scheduling tasks are generated based on process operation nodes, execution relationships, node capability information, and resource status information. Target execution nodes are determined by combining historical task execution information and a reinforcement learning scheduling model, improving the accuracy of heterogeneous execution node selection and resource utilization. Furthermore, by dynamically loading instruction adaptation plugins that match the target processor architecture and system interface based on a microkernel architecture, process operation nodes are converted into target execution instructions. This reduces the coupling between process logic and the underlying runtime environment, improving the operational compatibility of process tasks across different processor architectures and system environments. Simultaneously, by signing, encrypting, performing runtime environment integrity checks, decrypting, and verifying signatures on process execution tasks, and by configuring resources, controlling permissions, and isolating task data in an independent runtime container, the security and stability of process task transmission and execution are improved. The system updates task status, node resource status, and scheduling model based on process execution results and container running status. It can also provide accurate status basis for subsequent process task scheduling, forming a complete processing link of process design, node scheduling, instruction adaptation, secure transmission, isolated execution, and feedback updates.

[0162] Please continue reading. Figure 5 , Figure 5 This is a schematic diagram of the system structure of the cross-platform process automation device provided in the embodiments of this application, such as... Figure 5As shown, the cross-platform process automation device 50 includes: a process definition conversion module 51, used to acquire visual process design operations in the target operating environment and convert the visual process design operations into standardized process definition information through a browser-side cross-environment execution module; a process node parsing module 52, used to parse the standardized process definition information to obtain multiple process operation nodes and the execution relationships between them; a scheduling task generation module 53, used to generate process scheduling tasks based on multiple process operation nodes and execution relationships; an execution node determination module 54, used to acquire node capability information and resource status information of multiple heterogeneous execution nodes and determine the target execution node based on the process scheduling task, node capability information, and resource status information; an execution instruction adaptation module 55, used to determine the target processor architecture of the target execution node, load the corresponding instruction adaptation plugin based on the microkernel architecture, convert multiple process operation nodes into target execution instructions, and generate process execution tasks by combining the execution relationships; and a task security processing module 56, used to sign and encrypt the process execution tasks, send the signed and encrypted process execution tasks to the target execution node, and verify and decrypt the signature through the target execution node. The process task execution module 57 is used to control the target execution node to execute the decrypted process execution task in an independently running container when the signature verification is successful and the decryption is successful, to obtain the process execution result and the container running status, and to update the task status of the process execution task and the resource status information of the target execution node based on the process execution result and the container running status.

[0163] It should be noted that the aforementioned cross-platform process automation device can execute the cross-platform process automation method provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects of the method. Technical details not described in detail in the embodiments of the cross-platform process automation device can be found in the cross-platform process automation method provided in the embodiments of this application.

[0164] Figure 6 This is a schematic diagram of the hardware structure of an electronic device for executing a cross-platform process automation method provided in an embodiment of this application, as shown below. Figure 6 As shown, the electronic device 600 includes: One or more processors 610 and memory 620, Figure 6 Take the 610 processor as an example.

[0165] The processor 610 and the memory 620 can be connected via a bus or other means. Figure 6 Taking the example of a connection between China and Israel via a bus.

[0166] The memory 620, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the cross-platform process automation method in the embodiments of this application. The processor 610 executes various functional applications and data processing of the server by running the non-volatile software programs, instructions, and modules stored in the memory 620, thereby realizing the cross-platform process automation method in the above-described method embodiments.

[0167] Memory 620 may include a program storage area and a data storage area, wherein the program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the cross-platform process automation device, etc. Furthermore, memory 620 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, memory 620 may optionally include memory remotely located relative to processor 610, and this remote memory may be connected to the cross-platform process automation device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0168] The one or more modules are stored in the memory 620. When executed by the one or more processors 610, they perform the cross-platform process automation method in any of the above method embodiments, for example, the method described above. Figure 2 Method steps S1 to S7, Figure 3 Method steps S41 to S46, Figure 4 Steps S51 to S55 in the method are implemented. Figure 5 The functions of modules 51-57 in the document.

[0169] The above-described product can perform the methods provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for performing the methods. Technical details not described in detail in this embodiment can be found in the methods provided in the embodiments of this application.

[0170] This application provides a non-volatile computer-readable storage medium storing computer-executable instructions that are executed by one or more processors, for example... Figure 6 One of the processors 610 enables the one or more processors to execute the cross-platform process automation method in any of the above method embodiments, for example, to perform the above-described... Figure 2 Method steps S1 to S7, Figure 3 Method steps S41 to S46, Figure 4Steps S51 to S55 in the method are implemented. Figure 5 The functions of modules 51-57 in the document.

[0171] This application provides a computer program product, which includes a computer program stored on a non-volatile computer-readable storage medium. The computer program includes program instructions that, when executed by an electronic device, enable the electronic device to perform the cross-platform process automation method described in any of the above method embodiments, for example, to execute the above-described... Figure 2 Method steps S1 to S7, Figure 3 Method steps S41 to S46, Figure 4 Steps S51 to S55 in the method are implemented. Figure 5 The functions of modules 51-57 in the document.

[0172] The device embodiments described above are merely illustrative. 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 modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0173] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software and a general-purpose hardware platform, or of course, using hardware. Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0174] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0175] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of this application as described above, which are not provided in detail for the sake of brevity; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A cross-platform process automation method, characterized in that, include: The visual process design operations in the target runtime environment are obtained, and the cross-environment execution module on the browser side converts the visual process design operations into standardized process definition information. The standardized process definition information is parsed to obtain multiple process operation nodes and the execution relationships between the multiple process operation nodes; A process scheduling task is generated based on the multiple process operation nodes and the execution relationship; Obtain node capability information and resource status information of multiple heterogeneous execution nodes, and determine the target execution node based on the process scheduling task, the node capability information, and the resource status information; The target processor architecture of the target execution node is determined, and the corresponding instruction adaptation plugin is loaded based on the microkernel architecture to convert the multiple process operation nodes into target execution instructions, and process execution tasks are generated in combination with the execution relationship. The process execution task is signed and encrypted, and the signed and encrypted process execution task is sent to the target execution node, where the target execution node performs signature verification and decryption. When the signature verification is successful and decryption is successful, the target execution node is controlled to execute the decrypted process execution task in an independently running container, obtain the process execution result and the container running status, and update the task status of the process execution task and the resource status information of the target execution node according to the process execution result and the container running status.

2. The cross-platform process automation method according to claim 1, characterized in that, The step of converting the visual process design operation into standardized process definition information through the browser-side cross-environment execution module includes: Load the portable code execution unit into the browser of the target runtime environment; The portable code execution unit parses the visual process design operation to determine the interface component identifier, component operation type, component operation parameter, and component operation sequence. Based on a preset interface operation mapping relationship, the interface component identifier, the component operation type, and the component operation parameters are converted into process component instructions; The standardized process definition information is generated based on the process component instructions and the order of component operations.

3. The cross-platform process automation method according to claim 2, characterized in that, The step of generating the standardized process definition information based on the process component instructions and the order of component operations includes: Generate initial operation instructions based on the process component instructions; Based on preset instruction optimization rules, while maintaining the process dependencies corresponding to the operation order of the components, the initial operation instructions are merged, parameters reused, and the execution order is adjusted to obtain optimized operation instructions. The standardized process definition information is generated based on the optimized operation instructions and the component operation sequence.

4. The cross-platform process automation method according to claim 1, characterized in that, The process of determining the target processor architecture of the target execution node, loading the corresponding instruction adaptation plugin based on the microkernel architecture, converting the multiple process operation nodes into target execution instructions, and generating a process execution task based on the execution relationship includes: Read the processor architecture identifier and system interface information from the node capability information of the target execution node, and determine the target processor architecture based on the processor architecture identifier; Determine the target instruction adapter plugin from the instruction adapter plugin library that matches the processor architecture identifier and the system interface information; The target instruction adapter plugin is loaded through the microkernel architecture, and node semantic parsing is performed on the multiple process operation nodes to obtain intermediate operation instructions. The intermediate operation instructions are dynamically compiled by the target instruction adaptation plugin, and the interface is mapped according to the system interface information to obtain the target execution instructions; The process execution task is generated based on the target execution instruction and the execution relationship.

5. The cross-platform process automation method according to claim 1, characterized in that, The step of determining the target execution node based on the process scheduling task, the node capability information, and the resource status information includes: Extract processor architecture requirements data, runtime dependency requirements data, and resource requirements data from the process scheduling task; Based on the processor architecture requirement data and the runtime dependency requirement data, the node capability information of the multiple heterogeneous execution nodes is matched to obtain multiple candidate execution nodes; Based on the resource requirement data and the resource status information of each candidate execution node, determine the resource matching information corresponding to each candidate execution node, and obtain the historical task execution information corresponding to each candidate execution node; The node capability information, resource matching information, and historical task execution information of each candidate execution node are input into the reinforcement learning scheduling model to obtain the scheduling evaluation value corresponding to each candidate execution node. Based on the scheduling evaluation value, the target execution node is determined from the plurality of candidate execution nodes; The scheduling feedback value is determined based on the process execution result and the container running status, and the reinforcement learning scheduling model is updated based on the scheduling feedback value.

6. The cross-platform process automation method according to claim 1, characterized in that, The process of signing and encrypting the execution task, sending the signed and encrypted execution task to the target execution node, and verifying and decrypting the signature through the target execution node includes: The task is executed according to the described process to generate task summary information; The task digest information is signed using a preset signature algorithm to obtain a task signature, and the process execution task is encrypted using a preset encryption algorithm to obtain an encrypted process execution task. The task signature and the encrypted process execution task are sent to the target execution node; The target execution node invokes a hardware-assisted security detection unit to perform integrity checks on the target execution node's operating environment. When the integrity check passes, the encryption process execution task is decrypted, and verification digest information is generated based on the decrypted process execution task. The task signature is verified based on the verification digest information. If the integrity check fails, decryption fails, or signature verification fails, the process execution task is prevented from being loaded into the independent running container.

7. The cross-platform process automation method according to claim 1, characterized in that, The control of the target execution node to execute the decrypted process execution task in an independently running container includes: Based on the decrypted process, execute the task to determine resource requirement data; Create an independent running container corresponding to the process execution task, and configure the processor resources, memory resources, storage resources and system interface access permissions of the independent running container according to the resource requirement data; The decrypted process execution task is loaded into the independent running container, the target execution instruction is executed according to the execution relationship, and the running resources and task data between different process execution tasks are isolated. Monitor the resource usage and execution anomaly status of the independently running container to obtain the process execution result and the container running status; Based on the process execution result and the container running status, update the task status of the process execution task and the resource status information of the target execution node.

8. A cross-platform process automation device, characterized in that, include: The process definition conversion module is used to obtain the visual process design operations in the target runtime environment and convert the visual process design operations into standardized process definition information through the browser-side cross-environment execution module. The process node parsing module is used to parse the standardized process definition information to obtain multiple process operation nodes and the execution relationship between the multiple process operation nodes. The scheduling task generation module is used to generate process scheduling tasks based on the multiple process operation nodes and the execution relationship; The execution node determination module is used to obtain node capability information and resource status information of multiple heterogeneous execution nodes, and determine the target execution node based on the process scheduling task, the node capability information and the resource status information; An instruction adaptation module is used to determine the target processor architecture of the target execution node, load the corresponding instruction adaptation plugin based on the microkernel architecture, convert the multiple process operation nodes into target execution instructions, and generate process execution tasks in combination with the execution relationship. The task security processing module is used to sign and encrypt the process execution task, send the signed and encrypted process execution task to the target execution node, and verify and decrypt the signature through the target execution node. The process task execution module is used to control the target execution node to execute the decrypted process execution task in an independently running container when the signature verification is successful and the decryption is successful, to obtain the process execution result and the container running status, and to update the task status of the process execution task and the resource status information of the target execution node according to the process execution result and the container running status.

9. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the cross-platform process automation method according to any one of claims 1-7.

10. A non-volatile computer-readable storage medium, characterized in that, The non-volatile computer-readable storage medium stores computer-executable instructions that, when executed by an electronic device, cause the electronic device to perform the cross-platform process automation method according to any one of claims 1-7.

Images