Script processing method and device, computer equipment, readable storage medium and program product

Abstract

The invention relates to a script processing method and device, computer equipment, a computer readable storage medium and a computer program product. The method comprises the steps of obtaining a target script execution result; the target script execution result is obtained by formatting a collected initial script execution result; according to a mapping relationship between script result fields and attribute fields, storing each field result in the target script execution result to a corresponding attribute position; and sending a field result matched with a callback triggering condition in the target script execution result to target equipment. By adopting the method, the development cost can be reduced.

Description

Technical Field

[0001] This application relates to the field of system operation and maintenance technology, and in particular to a script processing method, apparatus, computer equipment, computer-readable storage medium, and computer program product. Background Technology

[0002] With the rapid development of information technology and cloud computing, enterprise operation and maintenance (O&M) systems are gradually evolving from single-platform environments to heterogeneous environments with multiple operating systems and scripting languages ​​running in parallel. To improve system controllability and automation, more and more enterprises are adopting script-based automated O&M methods, using scripts to perform operations such as host configuration, service deployment, environment monitoring, and system updates. Because different business systems run on different operating system platforms and use different O&M scripting languages, a large number of script execution results with varying structures and inconsistent formats are generated during actual O&M operations.

[0003] In related technologies, developers often need to write separate parsing logic or adaptation programs for different script types or different operating system environments. Although this approach can complete basic data collection and display functions, it is necessary to redevelop and maintain the corresponding processing interface or parsing logic for each new script type or operation and maintenance scenario, resulting in high development costs. Summary of the Invention

[0004] Therefore, it is necessary to provide a script processing method, apparatus, computer device, computer-readable storage medium, and computer program product that can reduce development costs in response to the above-mentioned technical problems.

[0005] Firstly, this application provides a script processing method, including:

[0006] Obtain the execution result of the target script; the execution result of the target script is obtained by formatting the collected initial script execution result;

[0007] Based on the mapping relationship between script result fields and attribute fields, the results of each field in the execution result of the target script are stored in the corresponding attribute location;

[0008] The field results in the execution result of the target script that match the callback triggering condition are sent to the target device.

[0009] In one embodiment, the formatting process of the initial script execution result includes:

[0010] Extract metadata tags from the initial script execution results, and determine the template based on the metadata tags;

[0011] According to the processing rules in the template, at least one of the following is performed on the initial script execution result: field escaping, result filtering, and parameter compatibility, to obtain the target script execution result.

[0012] In one embodiment, the field is escaped to replace the field name in the initial script execution result according to the template;

[0013] The result filtering involves removing invalid information from the initial script execution results according to preset filtering rules.

[0014] The parameter compatibility refers to the conversion of data type, unit format, or encoding method in the execution result of the initial script.

[0015] In one embodiment, storing the results of each field in the target script execution result into the corresponding attribute location according to the mapping relationship between the script result field and the attribute field includes:

[0016] Based on the mapping relationship between the script result fields and attribute fields, determine the field results from the execution results of the target script;

[0017] The field result is validated, and if the validation passes, the field result is stored in the corresponding attribute location.

[0018] In one embodiment, the method further includes:

[0019] If the validation fails and the field result is a critical field, the field result is saved to the critical field pending processing table, and the reason for the exception is recorded.

[0020] In one embodiment, sending the field result in the target script execution result that matches the callback triggering condition to the target device includes:

[0021] Receive the callback trigger information; the callback trigger information is generated at a lifecycle node of the target script execution.

[0022] The execution status of the target script is obtained based on the callback trigger information;

[0023] When the execution status meets the callback triggering condition, the field result in the target script execution result that matches the callback triggering condition is encapsulated into a message body;

[0024] The message body is sent to the target device.

[0025] Secondly, this application also provides a script processing apparatus, comprising:

[0026] The acquisition module is used to acquire the execution result of the target script; the execution result of the target script is obtained by formatting the acquired initial script execution result;

[0027] The mapping module is used to store the results of each field in the execution result of the target script into the corresponding attribute location according to the mapping relationship between the script result fields and the attribute fields;

[0028] The callback module is used to send the field results in the execution result of the target script that match the callback triggering condition to the target device.

[0029] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method in any of the above embodiments.

[0030] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method in any of the above embodiments.

[0031] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the methods in any of the above embodiments.

[0032] The aforementioned script processing methods, devices, computer equipment, computer-readable storage media, and computer program products collect initial script results generated based on different operating systems. Since the output formats, field naming, and return structures differ between different operating systems and scripting languages, a corresponding result template is matched to the initial script execution results. The result content is then formatted according to the template to obtain a target script execution result with a unified structure. Subsequently, based on the mapping relationship between script result fields and database attribute fields, different field results in the target script are automatically stored in the corresponding database, and the corresponding field results are reported according to preset callback trigger conditions. This enables unified parsing and management of different script execution results, avoiding redundant development of interfaces or parsing logic, thereby significantly reducing system maintenance and expansion costs. Attached Figure Description

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

[0034] Figure 1A flowchart illustrating a script processing method in one embodiment;

[0035] Figure 2 This is a structured schematic diagram of one embodiment;

[0036] Figure 3 A schematic diagram illustrating the saving of field results in one embodiment;

[0037] Figure 4 This is a schematic diagram of a multi-level callback in one embodiment;

[0038] Figure 5 This is a structural block diagram of a script processing device in one embodiment;

[0039] Figure 6 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0040] 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.

[0041] In one embodiment, such as Figure 1 As shown, a script processing method is provided. This embodiment illustrates the method applied to a terminal. It is understood that this method can also be applied to a server, and further to a system including both a terminal and a server, and is implemented through interaction between the terminal and the server. In this embodiment, the method includes the following steps:

[0042] Step 102: Obtain the target script execution result; the target script execution result is obtained by formatting the collected initial script execution result.

[0043] The initial script execution results are generated by different operating systems or operation and maintenance platforms. Due to differences in scripting languages ​​and execution environments used by operations and maintenance personnel, scripts executed on different platforms often differ in output format, field naming, log structure, and error message description. For example, in Linux systems, script output is usually returned in the form of standard output stream (stdout) and error output stream (stderr), while in Windows systems, script results may be returned in the form of text logs or structured tables; some customized operation and maintenance platforms may also encapsulate the results in JSON, XML, or custom formats.

[0044] Therefore, when a script completes execution on different systems or platforms, although the task logic is the same, the generated script execution results differ in data format, number of fields, and semantic structure. Directly using these results for subsequent processing will lead to difficulties in unified parsing and comparison. To achieve standardization and unified management of the results, the collected initial script execution results need to be formatted to generate target script execution results with consistent structure and unified semantics.

[0045] Furthermore, in this embodiment, the initial script execution result is formatted to obtain the target script execution result.

[0046] Optionally, formatting may include one or more of field escaping, result filtering, and parameter compatibility, as described in the following embodiments.

[0047] Step 104: Based on the mapping relationship between the script result fields and the attribute fields, store the results of each field in the target script execution result into the corresponding attribute location.

[0048] Since the execution results of operation and maintenance scripts often involve the operational status of the production system, and the results may be lost during the callback process due to network jitter or interface timeouts, this application stores the target script execution results in the corresponding attribute location after formatting them. This approach ensures reliable retention and traceability of execution results while providing a unified data source for asynchronous callbacks and multi-system reuse, thereby significantly improving system stability and scalability.

[0049] The attribute location can be an attribute field in the corresponding Configuration Management Database (CMDB) within the database, used to store the running status or configuration information of specific types of configuration items. Each attribute location belongs to a specific configuration model, such as a server, database, or network device model. Attribute fields under different models are used to record key parameters and operating metrics for that type of object. Additionally, the attribute location can also be other types of result storage units, such as an operation and maintenance result repository or monitoring metric repository, used to record unstructured logs, performance metrics, or temporary data during script execution. In this case, the system will automatically select the corresponding storage target based on the script type and field attributes, writing status-type data to the CMDB and statistical or log-type data to the result repository or metric repository.

[0050] Furthermore, to facilitate structured management and subsequent querying of different types of script execution results, the system categorizes and saves the target script execution results based on the mapping relationship between script result fields and attribute fields. For example, the system will write the field results of different scripts into the corresponding categorized storage areas according to the configuration model or result type to which each field belongs. For instance, the results of host monitoring scripts will be written into the attribute fields under the "Server" categorization model, the results of database health check scripts will be written into the attribute fields under the "Database" categorization model, and the results of network link detection scripts will be written into the attribute fields under the "Network Device" categorization model.

[0051] The mapping relationship between the script result fields and the attribute fields is pre-set and is used to indicate the correspondence between each field and the attribute position in the script execution result.

[0052] Step 106: Send the field results in the target script execution result that match the callback trigger condition to the target device.

[0053] Optionally, after the system receives the callback trigger information, it will extract the field results that match the callback trigger conditions from the stored target script execution results based on the job instance identifier, step identifier and trigger timing carried in the callback trigger information.

[0054] In the script processing method described above, initial script results generated based on different operating systems are collected. Since the output formats, field naming, and return structures differ between operating systems and scripting languages, a corresponding result template is matched to the initial script execution results. The result content is then formatted according to the template to obtain a target script execution result with a unified structure. Subsequently, based on the mapping relationship between script result fields and database attribute fields, different field results in the target script are automatically stored in the corresponding database, and the corresponding field results are reported according to preset callback trigger conditions. This enables unified parsing and management of different script execution results, avoiding redundant interface or parsing logic development, thereby significantly reducing system maintenance and expansion costs.

[0055] Furthermore, in one embodiment, the formatting process of the initial script execution result includes: extracting metadata tags from the initial script execution result and determining a template based on the metadata tags; and performing at least one of field escaping, result filtering, and parameter compatibility on the initial script execution result according to the processing rules in the template to obtain the target script execution result.

[0056] Because script results output from different operating systems or operations and maintenance platforms vary in format, field naming, log structure, and encoding, the system first extracts metadata tags from the initial script execution results to achieve unified parsing and standardized representation of the results. Based on these metadata tags, the system determines the applicable template. Metadata tags are identifying information that characterizes the script's source or execution environment, used to assist in template matching and field identification. Metadata tags may include, but are not limited to: operating system type (e.g., Linux, Windows), scripting language type (e.g., Shell, Python, PowerShell), execution platform identifier (e.g., Ansible, SaltStack, operations and maintenance console), version number, or output format identifier. A template is a set of pre-configured formatting rules based on different script types, output formats, and field structures. Each template carries processing rules to guide result parsing, including field name mapping rules, filtering rules, compatibility rules, and methods for handling abnormal fields.

[0057] After determining the applicable template based on metadata tags, the system uses the rules in the template to standardize the initial script execution results, thereby generating target script execution results with a uniform structure. This enables automatic parsing of results from different sources.

[0058] Furthermore, in one embodiment, the above-mentioned field escaping is to replace the field names in the initial script execution result according to the template; result filtering is to remove invalid information in the initial script execution result according to preset filtering rules; parameter compatibility is to convert the data type, unit format or encoding method in the initial script execution result.

[0059] Specifically, based on the field mapping rules in the template, the field names in the initial script execution results are replaced to ensure semantic consistency across fields output by different scripts. For example, the field "CPUUsage" output by Windows platform scripts is replaced with "cpu_usage" in a unified format, and the path-type field "system.status.code" is replaced with "status_code". Through field escaping, differences in field naming across different systems and scripts can be eliminated, ensuring semantic consistency across fields.

[0060] For example, referring to Table 1, which shows the field name mapping relationship in one embodiment.

[0061] Table 1

[0062]

[0063] Specifically, based on preset filtering rules, redundant or invalid information in the initial script execution results is removed, retaining only key fields related to the operation and maintenance tasks. For example, debug logs, duplicate timestamps, or error stack trace information are deleted from the script results, retaining only core result fields such as CPU, memory, disk, and process status.

[0064] Specifically, parameter compatibility involves converting the data types, unit formats, or encoding methods in the initial script execution results to ensure data consistency across different systems. For example, converting the string value 85% to the floating-point value 0.85, uniformly converting "MB" to "GiB", or converting the GBK encoding output by Windows to UTF-8 encoding.

[0065] Furthermore, since the execution result of an initial script often contains multiple structured fragments, and different fragments may correspond to different types of templates, the system needs to support parallel matching of multiple templates.

[0066] Alternatively, batch matching can be performed using a trained matching model.

[0067] The matching model includes a script-side structural tower, a template-side structural tower, a field alignment module, and an error-aware calibration module.

[0068] First, the script-side structural tower is used to structurally encode the input script execution results. The system not only extracts metadata such as operating system type, scripting language, output format, and task category, but also parses field paths, hierarchical structure, and inter-field dependencies from the initial script results. Through a tree-structured encoder (such as Tree-LSTM or Tree-Transformer), the model can capture the hierarchical features of the script results and output script vectors containing both global semantics and field-level vectors containing local semantics. These field-level vectors provide the foundational features for subsequent template alignment.

[0069] Subsequently, the template-side structural tower performs feature modeling on the internal mapping structure of the candidate templates. The system abstracts information such as field-attribute mapping relationships, data compatibility rules, filtering conditions, and mandatory constraints in the template into a graph structure, and extracts template structural features through a graph neural network (GCN / GAT). The template vector and attribute-level vector output by the template tower can fully represent the logical relationships and semantic rules of the template, thus enabling matching with the output of the script tower in the same feature space.

[0070] Next, the field alignment module is responsible for establishing the semantic mapping between the two structures. The model employs a bidirectional attention mechanism to match the script field vectors and template attribute vectors, forming a field-level alignment matrix. Through this matrix, the system can not only calculate the global matching score between the script and the template, but also identify the correspondence and matching confidence of specific fields. This alignment result can then be directly reused in subsequent formatting processes, achieving interpretable mapping of the template.

[0071] After the alignment process is complete, the results are input into the error-aware calibration module for reliability assessment. This module combines historical execution data to perform statistical learning on the matching performance of different templates, including information such as field parsing error types (e.g., type mismatch, missing values, inconsistent units), parsing success rate, and number of manual corrections. Based on this, the model outputs the final matching confidence score and provides error correction suggestions, such as whether to enable field compatibility rules or trigger weak template synthesis. If the confidence score is high, the system directly adopts the template; if the confidence score is medium, it adaptively optimizes through a field fusion mechanism; if the confidence score is low, it triggers the template reset inference module to regenerate a temporary template.

[0072] For example, in combination Figure 2 , Figure 2 This is a structured diagram of one embodiment. The left side shows the data source log, which is the initial script execution result. The middle section shows the formatting and transformation process performed by the system based on the template.

[0073] In the above embodiments, by extracting metadata tags to match templates and formatting the initial script execution results according to the processing rules in the templates, unified parsing and standardized processing of different script results can be achieved, thereby reducing the amount of repetitive development work.

[0074] In one embodiment, storing the results of each field in the target script execution result into the corresponding attribute location based on the mapping relationship between the script result field and the attribute field includes: determining the field results from the target script execution result based on the mapping relationship between the script result field and the attribute field; validating the field results; and storing the field results into the corresponding attribute location if the validation passes.

[0075] The script result fields and attribute fields are pre-set, for example, defining the correspondence between script output fields and configuration management database (CMDB) attribute fields.

[0076] Optionally, the field stage is first determined from the target script execution result based on the mapping relationship between the script result fields and attribute fields. Although the target script execution result has already undergone field unification and format standardization during the formatting stage, a secondary validation is still required before storage. This is because the formatting stage only ensures the consistency of field names, units, and data types, while abnormal field values, missing values, or logical inconsistencies may still occur in different host or task environments. Therefore, the field results are validated, and if the validation passes, the field results are stored in the corresponding attribute locations.

[0077] Optionally, the process of determining the field results from the target script execution results based on the mapping relationship between the script result fields and the attribute fields can be achieved through a pre-trained filtering model.

[0078] Alternatively, to avoid the workload of manually maintaining the mapping table, the system can automatically determine the field results based on the trained filtering model.

[0079] Specifically, after receiving the execution result of the target script, the system extracts the semantic and hierarchical information of all fields and forms a field feature matrix, which is then input into the first channel of the filtering model. Simultaneously, it extracts the features of all attribute fields under the corresponding model from the Configuration Management Database (CMDB) and forms an attribute feature matrix, which is then input into the second channel. The model calculates the field-attribute correspondence probability between the two feature matrices using an interactive attention mechanism, forming a field-attribute matching matrix, and automatically outputs batch mapping results based on this matrix.

[0080] In practical applications, the system can automatically determine the optimal mapping path based on the probability distribution of each field in the matching matrix. Fields with probabilities below a threshold are temporarily not entered into the database but instead enter a manual confirmation or automatic learning queue. When a new script type or a new field appears, the system can perform incremental learning based on the existing mapping matrix, automatically supplementing the new field-attribute correspondences, thereby achieving self-learning and continuous optimization of batch mapping. Through the above batch mapping mechanism, the system can complete the identification and matching of multiple fields in a single processing step, significantly reducing manual configuration costs and ensuring high consistency between script results and the CMDB attribute structure.

[0081] Optionally, if the validation fails and the field result is a critical field, the field result is saved to the critical field pending processing table, and the reason for the exception is recorded.

[0082] Among them, key fields are those that play a decisive role in the execution of subsequent tasks, the maintenance of configuration consistency, or the linkage with external systems. They can be set according to the actual use case.

[0083] Since critical fields are typically depended upon by multiple modules in the operation and maintenance task chain, discarding them directly will prevent subsequent jobs from correctly associating with target resources or triggering callback logic. For example, if the host identifier, task number, or running status field is missing, the system will be unable to determine the script execution target or callback object, causing task interruption or data silos. By temporarily storing abnormal fields, core operational information can be avoided when data import fails.

[0084] For example, in combination Figure 3 , Figure 3 This is a schematic diagram illustrating the saving of field results in one embodiment.

[0085] In the above embodiments, by saving the field results according to the mapping relationship between the script result fields and the attribute fields, the automatic correspondence between the script results and the configuration database attributes can be realized, thereby uniformly mapping the script outputs from different sources and with different structures to a standardized data model.

[0086] In one embodiment, sending the field result in the execution result of the target script that matches the callback trigger condition to the target device includes: receiving callback trigger information; the callback trigger information is generated at a node in the execution lifecycle of the target script; obtaining the execution status of the target script based on the callback trigger information; when the execution status meets the callback trigger condition, encapsulating the field result in the execution result of the target script that matches the callback trigger condition into a message body; and sending the message body to the target device.

[0087] Callback trigger information refers to the trigger instruction generated by the system or external task management module during the execution of the target script, which is used to indicate whether the script execution result needs to be reported to the specified target device.

[0088] For example, callback triggering information may include job ID, step ID, callback address, and triggering strategy.

[0089] Specifically, callback trigger information will be automatically generated when the target script reaches a critical node in its lifecycle, such as the execution completion node, the exception node, or the intermediate step node.

[0090] For example, when the script finishes execution or an error occurs, the system generates corresponding callback trigger information and pushes it to the result processing module to drive the result reporting.

[0091] The execution status of the target script refers to the script's running status or stage status monitored by the system within the current execution cycle.

[0092] For example, after receiving the callback trigger information, the system will query and update the current execution status of the target script; when the status matches the preset callback trigger conditions, the result reporting operation will be triggered.

[0093] During the reporting process, the field results in the target script execution result that match the callback trigger condition will be encapsulated into a message body and pushed to the target device via an HTTP interface or message queue.

[0094] Optionally, the system will perform multi-level callbacks based on callback trigger information. When the script executes, it will complete multiple steps sequentially. Upon completion of any step, the system can generate a step-level callback to report the execution result of that step in real time. When all steps on a single device have been executed and completed, the system will trigger a single-device-level callback to report the complete execution result of that device. When the task involves multiple devices, the system will trigger multi-device-level callbacks after all device scripts have been executed, achieving the final summary and reporting of the entire batch of tasks. For example, combined with... Figure 4 , Figure 4 This is a schematic diagram of a multi-level callback in one embodiment.

[0095] In the above embodiments, callback trigger information can be automatically generated at key nodes in the script execution lifecycle, and the callback conditions can be accurately determined based on the actual execution status, thereby realizing automatic reporting and real-time callback of script results.

[0096] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages of other steps.

[0097] Based on the same inventive concept, this application also provides a script processing apparatus for implementing the script processing method described above. The solution provided by this apparatus is similar to the implementation scheme described in the above method; therefore, the specific limitations in one or more script processing apparatus embodiments provided below can be found in the limitations of the script processing method described above, and will not be repeated here.

[0098] In one exemplary embodiment, such as Figure 5As shown, a script processing device is provided, including: an acquisition module, a mapping module, and a callback module, wherein:

[0099] The acquisition module is used to obtain the execution result of the target script; the execution result of the target script is obtained by formatting the initial script execution result collected.

[0100] The mapping module is used to store the results of each field in the execution result of the target script into the corresponding attribute location according to the mapping relationship between the script result fields and the attribute fields.

[0101] The callback module is used to send the field results from the execution result of the target script that match the callback triggering condition to the target device.

[0102] In one embodiment, the above-mentioned acquisition module includes:

[0103] The tag extraction unit is used to extract metadata tags from the initial script execution results and determine the template based on the metadata tags.

[0104] The formatting unit is used to perform at least one of the following on the initial script execution result: field escaping, result filtering, and parameter compatibility, according to the processing rules in the template, to obtain the target script execution result.

[0105] In one embodiment, the fields in the above formatting unit are escaped to replace the field names in the initial script execution result according to the template.

[0106] In one embodiment, the result filtering in the above formatting unit is to remove invalid information from the initial script execution result according to a preset filtering rule.

[0107] In one embodiment, the parameters in the above formatting unit are compatible with converting the data type, unit format, or encoding method in the initial script execution result.

[0108] In one embodiment, the mapping module described above includes:

[0109] The field determination unit is used to determine the field results from the execution result of the target script based on the mapping relationship between the script result fields and the attribute fields.

[0110] The storage unit is used to validate the field results and, if the validation passes, store the field results in the corresponding attribute location.

[0111] In one embodiment, the mapping module further includes:

[0112] The exception recording unit is used to save the field result to the critical field pending processing table and record the reason for the exception when the validation fails and the field result is a critical field.

[0113] In one embodiment, the above-mentioned callback module includes:

[0114] The information receiving unit is used to receive callback trigger information; the callback trigger information is generated at the lifecycle node of the target script execution.

[0115] The status acquisition unit is used to obtain the execution status of the target script based on the callback trigger information.

[0116] The encapsulation unit is used to encapsulate the field results in the target script execution result that match the callback triggering condition into a message body when the execution status meets the callback triggering condition.

[0117] The sending unit is used to send the message body to the target device.

[0118] Each module in the aforementioned script processing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device, or stored in the memory of a computer device as software, so that the processor can call and execute the operations corresponding to each module.

[0119] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 6 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The database stores the execution results of target scripts. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. When the computer program is executed by the processor, it implements a script processing method.

[0120] Those skilled in the art will understand that Figure 6 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0121] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps of the method in any of the above embodiments.

[0122] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the method in any of the above embodiments.

[0123] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, implements the steps of the method in any of the above embodiments.

[0124] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0125] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0126] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A script processing method, characterized in that, The method includes: Obtain the execution result of the target script; the execution result of the target script is obtained by formatting the collected initial script execution result; Based on the mapping relationship between the script result fields and the attribute fields, the results of each field in the execution result of the target script are stored in the corresponding attribute location; The field results in the execution result of the target script that match the callback triggering condition are sent to the target device.

2. The method according to claim 1, characterized in that, The formatting process for the initial script execution result includes: Extract metadata tags from the initial script execution results, and determine the template based on the metadata tags; According to the processing rules in the template, at least one of the following is performed on the initial script execution result: field escaping, result filtering, and parameter compatibility, to obtain the target script execution result.

3. The method according to claim 2, characterized in that, The field escaping refers to replacing the field names in the initial script execution result according to the template; The result filtering involves removing invalid information from the initial script execution results according to preset filtering rules. The parameter compatibility refers to the conversion of data type, unit format, or encoding method in the execution result of the initial script.

4. The method according to claim 1, characterized in that, The step of storing the results of each field in the target script execution result into the corresponding attribute location according to the mapping relationship between the script result fields and attribute fields includes: Based on the mapping relationship between the script result fields and attribute fields, determine the field results from the execution results of the target script; The field result is validated, and if the validation passes, the field result is stored in the corresponding attribute location.

5. The method according to claim 4, characterized in that, The method further includes: If the validation fails and the field result is a critical field, the field result is saved to the critical field pending processing table, and the reason for the exception is recorded.

6. The method according to claim 1, characterized in that, Sending the field result in the execution result of the target script that matches the callback trigger condition to the target device includes: Receive callback trigger information; the callback trigger information is generated at a lifecycle node of the target script execution. The execution status of the target script is obtained based on the callback trigger information; When the execution status meets the callback triggering condition, the field result in the target script execution result that matches the callback triggering condition is encapsulated into a message body; The message body is sent to the target device.

7. A script processing device, characterized in that, The device includes: The acquisition module is used to acquire the execution result of the target script; the execution result of the target script is obtained by formatting the acquired initial script execution result; The mapping module is used to store the results of each field in the execution result of the target script into the corresponding attribute location according to the mapping relationship between the script result fields and the attribute fields; The callback module is used to send the field results in the execution result of the target script that match the callback triggering condition to the target device.

8. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the method according to any one of claims 1 to 6.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the method according to any one of claims 1 to 6.

Images