A dynamic detection method based on script engine technology

Abstract

The application belongs to the technical field of computer detection, and particularly relates to a dynamic detection method based on script engine technology, wherein business request parameters, basic business data and detection item configuration data are acquired, a dynamic detection framework is constructed, detection script syntax rules, execution order specifications and dependent association mechanisms are defined, meanwhile, according to the business request parameters and detection execution context data, the detection logic script associated with the target business detection item is dynamically loaded, the detection logic is parsed and executed through the script engine, the detection item execution order is determined according to the topological sorting and priority scheduling algorithm, the detection logic is asynchronously executed through the thread pool, the execution results and diagnosis information of each detection item are output in real time, the preset quick repair entry is provided for the abnormal detection item, the repair operation is responded and the repair effect is verified, the evaluation report is generated according to the detection and repair feedback data, and the detection script and configuration information are updated. Thus, the problems of poor adaptability and low execution efficiency in the prior art are solved.

Description

Technical Field

[0001] This invention belongs to the field of computer detection technology, specifically relating to a dynamic detection method based on script engine technology. Background Technology

[0002] As enterprise-level business systems become increasingly complex and multi-scenario-based, the market demands higher levels of flexibility, adaptability, and closed-loop optimization capabilities from dynamic detection technologies. This requires dynamic matching of detection logic with business scenarios, collaborative scheduling of multiple detection items, and deep integration of anomaly repair and detection optimization. However, existing technologies, lacking deep integration between script engines and detection frameworks, and lacking flexible dynamic loading mechanisms for detection logic and cross-detection item collaborative scheduling frameworks, struggle to support accurate detection needs across diverse business scenarios. This falls significantly short of the technical requirements for building a dynamically adaptable, efficiently executed, and closed-loop optimized detection system.

[0003] However, traditional dynamic detection methods have key drawbacks: they often employ fixed detection logic or static configuration patterns, resulting in insufficient accuracy in responding to different business scenarios and versions of business requirements. They are also susceptible to interference from changes in business parameters, interface upgrades, and iterations of detection rules. Furthermore, the models lack dynamic adaptation mechanisms for detection logic, leading to significant deviations in the execution order of detection nodes when faced with detection items of different priorities and dependencies, resulting in low detection efficiency or missed critical anomalies. The data dimension is limited to single detection result outputs or simple anomaly prompts, lacking collaborative processing of detection process data and repair effect data, resulting in a disconnect between the detection logic and actual business needs. With the rapid iteration of business systems in e-commerce, finance, and government sectors, the market urgently needs highly flexible, efficient, and closed-loop dynamic detection technologies. However, existing technologies, due to poor adaptability, low execution efficiency, and lack of closed-loop optimization, struggle to support efficient detection applications in complex business scenarios. Summary of the Invention

[0004] This application provides a dynamic detection method based on script engine technology to solve the problems of poor adaptability and low execution efficiency in the prior art.

[0005] The first aspect of this application provides a dynamic detection method based on script engine technology, comprising the following steps: obtaining business request parameters, basic business data, and detection item configuration data; constructing a script engine-driven dynamic detection framework based on the basic business data and detection item configuration data, defining detection script syntax rules, execution order specifications, and dependency association mechanisms; simultaneously, dynamically loading detection logic scripts associated with target business detection items according to the business request parameters and detection execution context data; parsing and executing the detection logic through the script engine; determining the execution order of detection items according to topology sorting and priority scheduling algorithms; asynchronously executing the detection logic through a thread pool; and outputting the execution results and diagnostic information of each detection item in real time; providing a pre-set quick repair entry for abnormal detection items based on the execution results and diagnostic information of each detection item; responding to repair operations and verifying the repair effect; generating an evaluation report based on the detection and repair feedback data; and updating the detection scripts and configuration information.

[0006] Preferably, the detection logic is parsed and executed by a script engine, and the execution order of the detection items is determined by a topology sorting and priority scheduling algorithm, including: constructing a dependency parser and a scheduler; based on the dependency parser, analyzing the dependency declarations of the detection items in the detection logic script to generate a directed acyclic graph of the detection items; and using the scheduler to perform topology sorting on the directed acyclic graph and, in conjunction with the priority weights defined in the detection item configuration data, determining the execution order queue.

[0007] Preferably, based on the execution results and diagnostic information of each detection item, a preset quick repair entry is provided for the abnormal detection item, including: constructing an abnormal matcher and a repair action mapping table; based on the abnormal matcher, matching the execution results and diagnostic information of the detection item with a predefined abnormal pattern to obtain a matching result; based on the matching result, obtaining and presenting the corresponding quick repair operation entry according to the repair action mapping table.

[0008] Preferably, the topological sorting formula is:

[0009] ;

[0010] ;

[0011] ;

[0012] in, Let j be the i-th detection item node; j is the traversal variable for the summation operation; and n is the total number of detection items. To indicate from the detection item arrive The directed edges; To indicate from the detection item arrive The directed edges; The node representing the deleted detection item; for The set of adjacent nodes; IsValidTopo is the validity flag of the topological sort, where 1 represents a valid topological sort and 0 represents an invalid topological sort.

[0013] Preferably, dynamically loading the detection logic script associated with the target business detection project based on the business request parameters and detection execution context data includes: constructing a detection script repository and a dynamic loading manager; based on the dynamic loading manager, retrieving and obtaining the corresponding detection logic script file from the detection script repository according to the project identifier and version number in the business request parameters; and injecting the detection execution context data into the script runtime environment based on the detection logic script file to dynamically load the detection logic script associated with the target business detection project, wherein the context data includes request parameters, basic business data snapshots, and external interface data caches.

[0014] Preferably, responding to a repair operation and verifying the repair effect includes: constructing a repair executor and an effect verifier; based on the repair executor, executing a user-triggered repair operation, the operation including parameter adjustment, data correction, or interface re-call; simultaneously, through the effect verifier, re-running the associated detection items or executing simplified verification logic, collecting the repaired business status data and comparing it with the expected results, and outputting verification conclusions.

[0015] Preferably, generating an evaluation report based on detection and repair feedback data, and updating the detection script and configuration information, includes: constructing a feedback data aggregator and an evaluation report generator; based on the feedback data aggregator, integrating performance indicators, anomaly distribution, repair success rate, and user operation logs during the detection execution process; generating a comprehensive evaluation report including detection coverage, execution efficiency, anomaly detection accuracy, and repair effectiveness through the evaluation report generator; and triggering version updates of the detection script repository and detection item configuration data based on script logic defects or configuration deficiencies pointed out in the report.

[0016] Preferably, the priority scheduling algorithm formula is:

[0017] ;

[0018] Among them, Priority is the priority score of the detection item; This is the node for the i-th detection item; Let be the weighting coefficient, satisfying ; Assign importance score to the test item; The urgency of the test item is scored; The in-degree of the detection item node; max( ) represents the maximum in-degree of all detection item nodes; This is the resource usage score for the detection item.

[0019] A second aspect of this application provides a dynamic detection system based on script engine technology, comprising: an acquisition module for acquiring business request parameters, basic business data, external interface data, and detection item configuration data; a parsing module for constructing a script engine-driven dynamic detection framework based on the basic business data and detection item configuration data, defining detection script syntax rules, execution order specifications, and dependency association mechanisms, and dynamically loading detection logic scripts associated with target business detection items according to the business request parameters and detection execution context data, parsing and executing the detection logic through the script engine, determining the execution order of detection items according to topology sorting and priority scheduling algorithms, asynchronously executing the detection logic through a thread pool, and outputting the execution results and diagnostic information of each detection item in real time; and a generation module for providing a pre-set quick repair entry for abnormal detection items based on the execution results and diagnostic information of each detection item, responding to repair operations and verifying the repair effect, generating an evaluation report based on detection and repair feedback data, and updating the detection scripts and configuration information.

[0020] A third aspect of this application provides an electronic device, including: a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the program to implement a dynamic detection method based on script engine technology as described in the above embodiments.

[0021] Therefore, this application has the following beneficial effects: By integrating business request parameters, basic business data, external interface data, and detection item configuration data, and leveraging a script engine to drive the construction of a dynamic detection framework, this application achieves dynamic loading, parsing, and execution of detection logic scripts. It optimizes the execution order of detection items by combining topology sorting and priority scheduling algorithms, solving the problems of poor adaptability and low execution efficiency in traditional fixed detection logic, and breaking down the disconnect between detection, repair, and optimization. Simultaneously, by pre-setting a rapid repair entry point, verifying repair effects, and aggregating and analyzing feedback data, it continuously updates the detection scripts and configuration information, significantly improving the closed-loop optimization capability of the detection system while ensuring detection accuracy and efficiency. This effectively fills the gap in the deep integration of script engines and dynamic detection, and the linkage between detection, repair, and optimization in existing technologies, maximizing the reduction of anomaly false negative rates and detection resource waste while meeting diverse business detection needs. Thus, it solves the problems of poor adaptability and low execution efficiency in existing technologies.

[0022] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0023] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the following description of the embodiments taken in conjunction with the accompanying drawings, wherein:

[0024] Figure 1 This is a flowchart of a dynamic detection method based on script engine technology provided according to an embodiment of this application;

[0025] Figure 2 This is a schematic diagram of an intelligent control scenario for the central air conditioning and lighting system of a large commercial complex according to an embodiment of this application;

[0026] Figure 3 This is a schematic diagram of a smart business district pedestrian flow management scenario provided according to an embodiment of this application;

[0027] Figure 4 This is a schematic diagram of a dynamic detection method based on script engine technology according to an embodiment of this application;

[0028] Figure 5 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of this application. Detailed Implementation

[0029] The embodiments of this application are described in detail below. Examples of the embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and intended to explain this application, and should not be construed as limiting this application.

[0030] The following describes a dynamic detection method based on script engine technology according to an embodiment of this application, with reference to the accompanying drawings. Addressing the poor adaptability issue mentioned in the background section, this application provides a dynamic detection method based on script engine technology. This method integrates business request parameters, basic business data, external interface data, and detection item configuration data. A dynamic detection framework is constructed using a script engine driver, enabling dynamic loading and parsing execution of the detection logic script. The execution order of detection items is optimized using topology sorting and priority scheduling algorithms, solving the problems of poor adaptability and low execution efficiency in traditional fixed detection logic, and breaking down the disconnect between detection, repair, and optimization. Simultaneously, by pre-setting a rapid repair entry point, verifying repair effects, and aggregating and analyzing feedback data, the detection script and configuration information are continuously updated. This significantly improves the closed-loop optimization capability of the detection system while ensuring detection accuracy and efficiency, effectively filling the gap in the deep integration of script engines and dynamic detection, and the linkage between detection, repair, and optimization in existing technologies. While meeting diverse business detection needs, it maximizes the reduction of anomaly false negative rates and detection resource waste. Thus, it solves the problems of poor adaptability and low execution efficiency in existing technologies.

[0031] Specifically, Figure 1 This is a flowchart illustrating a dynamic detection method based on script engine technology provided in an embodiment of this application.

[0032] like Figure 1 As shown, this dynamic detection method based on script engine technology includes the following steps:

[0033] In step S101, business request parameters, basic business data, external interface data, and detection item configuration data are obtained.

[0034] Among them, business request parameters refer to the set of core parameters transmitted along with the request when the business system receives user operations or external calls. These parameters include request identifier, business type, version number, key query conditions, etc., and serve as the basis for locating target detection scenarios.

[0035] It is understood that, by obtaining business request parameters, this application embodiment can accurately locate the scenario, version, and core requirements of the target detection business, providing a key index for the subsequent dynamic loading of adapted detection logic scripts; basic business data, as the core analysis object of detection, provides real business scenario data support for detection items, avoiding the disconnect between detection logic and actual business; external interface data supplements the status information of external resources that the business system depends on, ensuring that detection covers all related nodes in the business chain; detection item configuration data clarifies core configurations such as detection rules, priorities, and dependencies, providing a standardized basis for the construction of the dynamic detection framework, breaking the limitation of single data dimensions in traditional detection, and providing comprehensive data support for the dynamic adaptation of detection logic, the optimized scheduling of execution order, and the precise triggering of anomaly repair, ensuring the accuracy of detection results, the efficiency of the detection process, and the adaptability of the detection system.

[0036] In step S102, based on basic business data and detection item configuration data, a dynamic detection framework driven by a script engine is constructed. The detection script syntax rules, execution order specifications, and dependency association mechanisms are defined. At the same time, according to business request parameters and detection execution context data, the detection logic scripts associated with the target business detection items are dynamically loaded. The detection logic is parsed and executed by the script engine. The execution order of the detection items is determined by the topology sorting and priority scheduling algorithm. The detection logic is executed asynchronously by the thread pool, and the execution results and diagnostic information of each detection item are output in real time.

[0037] Among them, the dynamic detection framework refers to an integrated detection architecture that uses a script engine as the core driver and integrates functional modules such as detection script management, execution scheduling, dependency resolution, and result output. It supports dynamic adaptation of detection logic and collaborative scheduling of detection items, and can flexibly adjust detection rules and execution processes according to the needs of different business scenarios.

[0038] It is understood that the embodiments of this application solve the problem of poor adaptability caused by the fixed nature of traditional detection logic by constructing a dynamic detection framework driven by a script engine and defining unified syntax rules and execution specifications. This enables the detection rules to quickly respond to business changes through script iteration. The dynamic loading mechanism of the detection logic scripts achieves accurate matching between business scenarios and detection scripts, avoiding redundant detection logic from consuming resources. The combination of topology sorting and priority scheduling algorithms optimizes the execution order of multiple detection items, ensuring that key detection items are executed first and dependent detection items are executed in an orderly manner, thus improving detection efficiency. The asynchronous execution mode of the thread pool further improves the detection throughput and avoids the overall delay caused by the blocking of a single detection item. The real-time output of detection results and diagnostic information provides accurate problem location basis for subsequent anomaly repair.

[0039] For example, such as Figure 2 As shown, in a financial institution's transaction compliance detection system, S1 is executed first: defining business detection items and clarifying metadata information such as the detection scope and indicator requirements of the "personal credit transaction compliance detection" item; then S2 is executed: configuring the detection item set, determining the priority, dependency, and other configuration data of detection items such as "transaction amount verification," "identity information verification," and "risk control rule matching," and simultaneously constructing a dynamic detection framework based on the Groovy script engine, defining rules such as script input and output formats, variable naming conventions, and dependency declaration syntax; then S3 is executed: defining and deploying detection logic scripts, deploying scripts such as amount exceeding limits detection, credit record query detection, and anti-fraud rule detection to the script repository. When a personal credit transaction request is received, the request parameters include "Transaction Type = Personal Consumer Loan" and "Version Number = V2.3". At this time, S4 is executed: Initialize the execution context and dynamically load the corresponding detection logic script from the script repository. Then, S5 is executed: Execute the business detection process. First, the script engine parses the loaded detection logic script, and then the dependency parser analyzes and finds that "Identity Information Verification" is a prerequisite for "Risk Control Rule Matching". A directed acyclic graph is generated, and the scheduler combines topology sorting and priority algorithm ("Risk Control Rule Matching" has an importance score of 0.8 and an urgency score of 0.9, with the highest priority) to determine the execution order as "Identity Information Verification → Transaction Amount Verification → Credit Record Inquiry → Anti-Fraud Rule Detection → Risk Control Rule Matching", and executes it asynchronously through a thread pool. Next, S6 is executed: Process the detection results. The system outputs the results of each detection item in real time, such as "Anti-fraud rule detection anomaly: High-frequency transaction characteristics exist" and the corresponding diagnostic information "There are 5 similar transactions in the past 1 hour, exceeding the threshold of 3 transactions"; If the detection result is that all are executed successfully (S6-1), it is determined that there are no anomalies under the business detection item, and the process ends; If there are execution failures (S6-2), it is determined that there are anomalies under the business detection item, providing accurate guidance for subsequent repair operations, and subsequent operations are performed as needed.

[0040] In this embodiment of the application, the detection logic is parsed and executed by a script engine, and the execution order of the detection items is determined by a topology sorting and priority scheduling algorithm. This includes: constructing a dependency parser and a scheduler; based on the dependency parser, analyzing the dependency declarations of the detection items in the detection logic script to generate a directed acyclic graph of the detection items; and using the scheduler to perform topology sorting on the directed acyclic graph and, in combination with the priority weights defined in the detection item configuration data, determining the execution order queue.

[0041] Among them, the dependency parser is a functional component that can parse the predefined dependency declarations in the detection logic script, identify the pre-dependencies and post-dependencies between each detection item, and then build a structured dependency model.

[0042] It is understood that the embodiments of this application deeply mine the correlation logic between detection items through the dependency relationship resolver to generate a directed acyclic graph, avoiding the problems of incorrect execution order or duplicate detection caused by chaotic dependency relationships in traditional detection. The scheduler combines topology sorting and priority weights to ensure the orderly execution of dependent detection items (e.g., subsequent detection items will not start if the preceding detection items are not completed) and to realize priority differentiation based on business needs (e.g., core compliance detection items take precedence over non-core performance detection items), which significantly improves the rationality and efficiency of detection execution. The explicit execution order queue provides a clear scheduling basis for asynchronous execution of the thread pool, ensuring that there are no conflicts or omissions when multiple detection items are executed in parallel, while reducing the ineffective occupation of detection resources, and providing efficient execution guarantee for multi-dimensional detection in complex business scenarios.

[0043] It should be noted that the topological sorting formula is as follows:

[0044] ;

[0045] ;

[0046] ;

[0047] in, Let j be the i-th detection item node; j is the traversal variable for the summation operation; and n is the total number of detection items. To indicate from the detection item arrive The directed edges; To indicate from the detection item arrive The directed edges; The node representing the deleted detection item; for The set of adjacent nodes; IsValidTopo is the validity flag of the topological sort, where 1 represents a valid topological sort and 0 represents an invalid topological sort.

[0048] Priority scheduling algorithm formula:

[0049] ;

[0050] Where Priority is the priority score of the detection item; vᵢ is the node of the i-th detection item; Let be the weighting coefficient, satisfying ; Assign importance score to the test item; The urgency of the test item is scored; The in-degree of the detection item node; max( ) represents the maximum in-degree of all detection item nodes; This is the resource usage score for the detection item.

[0051] For example, in the order payment detection scenario of an e-commerce platform, the detection items include "order information integrity detection (A)", "payment account legality detection (B)", "payment amount verification (C)", "risk control rule matching (D)", and "payment interface connectivity detection (E)". After the dependency resolver parses the script dependency declaration, it finds that "B depends on A", "C depends on A", "D depends on B and C", and "E has no prerequisite dependencies", generating a directed acyclic graph (A→B, A→C, B→D, C→D, E is independent). The scheduler first performs a topological sort on the graph to obtain an initial order [A, E, B, C, D]; then, it combines the priority configuration ( ), calculate the priority score for each detection item: A has an importance score of 9 points, an urgency score of 8 points, an in-degree of 0 points, and a resource consumption score of 7 points. E's importance score is 6, urgency score is 5, in-degree is 0, and resource consumption score is 3. The final execution order queue [A (priority 5.9) → E (priority 4.9) → B (priority 5.2) → C (priority 5.1) → D (priority 6.0)] is determined to ensure that the core risk control detection item D is executed first after the preconditions are met, thereby improving the security and efficiency of order payment detection.

[0052] In this embodiment, the detection logic script associated with the target business detection project is dynamically loaded based on the business request parameters and the detection execution context data. This includes: building a detection script repository and a dynamic loading manager; retrieving and obtaining the corresponding detection logic script file from the detection script repository based on the project identifier and version number in the business request parameters using the dynamic loading manager; and injecting the detection execution context data into the script runtime environment based on the detection logic script file to dynamically load the detection logic script associated with the target business detection project. The context data includes request parameters, basic business data snapshots, and external interface data caches.

[0053] The detection script repository refers to a centralized storage system used for unified storage, version management, retrieval and maintenance of various business detection logic scripts, which supports multi-dimensional indexing by project identifier, version number, detection type and other dimensions.

[0054] It is understood that the embodiments of this application, by constructing a detection script repository, achieve standardized storage and version control of detection logic, avoiding the maintenance difficulties and version conflicts caused by the scattered management of scripts in traditional detection; the dynamic loading manager accurately retrieves scripts based on business request parameters, ensuring that the loaded detection logic is fully adapted to the target business scenario and version, solving the problem that fixed scripts cannot cope with business iterations; injecting context data into the runtime environment provides complete input data support for script execution, avoiding the distortion of detection results due to data loss; the dynamic loading mode of scripts allows the detection system to adapt to new detection rules or business versions without restarting, significantly improving the flexibility and iteration efficiency of the detection system, while reducing the resource consumption caused by redundant script loading.

[0055] For example, in the compliance testing system of a government service platform, the testing script repository is built using GitLab and stores testing scripts for various business processes such as "enterprise registration testing," "qualification approval testing," and "license change testing." Each script is named according to "project identifier-version number-script name" (e.g., "enterprise-reg-V1.2-valid.groovy"). When a user initiates a "enterprise registration (project identifier: enterprise-reg)" request, and the version number in the request parameters is V1.2, the dynamic loading manager retrieves and downloads the corresponding script file from the repository using this identifier. Simultaneously, the manager injects the testing execution context data (including the enterprise name and unified social credit code in the request parameters, the industry classification and registered address in the basic business data snapshot, and the legal person identity verification result and address compliance verification result in the external interface data cache) into the Groovy script runtime environment. This dynamically loads the logic in the script, such as "enterprise name compliance testing," "registered address authenticity testing," and "legal person qualification matching testing," ensuring that the testing script can execute accurately based on complete data and adapt to the testing requirements of the current business version.

[0056] In step S103, based on the execution results and diagnostic information of each detection item, a preset quick repair entry is provided for abnormal detection items, the repair operation is responded to and the repair effect is verified, an evaluation report is generated based on the detection and repair feedback data, and the detection script and configuration information are updated.

[0057] The quick repair entry refers to the pre-defined standardized repair operation entry for common anomaly types, including parameter adjustment interface, data correction tool, interface recall button, etc. Users can quickly perform repair operations through the entry without having to manually write repair logic.

[0058] It is understood that the embodiments of this application, by analyzing detection results and diagnostic information, accurately match anomaly types and provide a quick repair entry point, solving the problems of complex and time-consuming anomaly repair operations in traditional detection, and significantly improving anomaly handling efficiency; the repair effect verification mechanism ensures the effectiveness of repair operations and avoids business risks caused by ineffective repairs; the aggregation analysis of feedback data and the generation of evaluation reports provide data support for the optimization of the detection system, and can accurately identify problems such as logical defects in detection scripts and unreasonable configurations; based on the evaluation report, the detection scripts and configuration information are updated to form a closed-loop system of "detection-repair-feedback-optimization", continuously improving the adaptability of detection logic and the accuracy of detection results, and promoting the evolution of dynamic detection systems towards intelligence and self-optimization.

[0059] For example, in a product listing detection system on an e-commerce platform, when an anomaly is detected in the "Product Specification Parameter Completeness Detection" with the diagnostic information "Missing Material Parameters," the system uses an anomaly matcher to find the corresponding anomaly pattern and retrieves the "Specification Parameter Supplementation Entry" from the repair action mapping table. A pop-up supplementation form is then provided to the user on the detection results page. After the user enters "pure cotton" as the product material through this entry, the repair executor automatically updates the parameters to the product database. The effect verifier reruns the "Product Specification Parameter Completeness Detection," collects the repaired parameter data, compares it with the expected result (material parameters not empty), and outputs a verification conclusion of "Repair Successful." The system integrates the process data (detection time 0.5s, repair success rate 100%, user operation time 2s) through a feedback data aggregator, generating an evaluation report pointing out that "the material parameter detection script did not set a default prompt, resulting in a long time for user supplementation." Subsequently, the detection script is updated, adding a default material parameter option prompt in the new version, improving the efficiency of subsequent detection and repair.

[0060] In this embodiment, based on the execution results and diagnostic information of each detection item, a pre-set quick repair entry is provided for the abnormal detection item, including: constructing an abnormal matcher and a repair action mapping table; based on the abnormal matcher, matching the execution results and diagnostic information of the detection item with a predefined abnormal pattern to obtain a matching result; based on the matching result, obtaining and presenting the corresponding quick repair operation entry according to the repair action mapping table.

[0061] Among them, the anomaly matcher refers to an intelligent matching component that can compare the abnormal results and diagnostic information output by the detection with the system's predefined abnormal pattern library in multiple dimensions to accurately identify the anomaly type, cause and corresponding repair solution.

[0062] It is understood that the embodiments of this application achieve accurate identification of anomaly types by constructing an anomaly matcher, avoiding the problem of unclear repair direction caused by ambiguous anomaly prompts in traditional detection; the repair action mapping table associates anomaly types with standardized repair entry points, ensuring the pertinence and efficiency of repair operations and reducing the time cost for users to manually check repair solutions; the intuitive presentation of the quick repair entry point lowers the technical threshold for anomaly handling, enabling non-technical personnel to quickly complete repair operations and improving the usability of the detection system; the collaborative work of the two promotes the transformation of anomaly handling from "passive investigation" to "proactive matching and rapid response", significantly improving the stability of business systems and the efficiency of anomaly handling.

[0063] It should be noted that the predefined exception patterns in the exception pattern library include exception types (such as missing parameters, format errors, logical conflicts, and interface call failures), characteristic keywords (such as "missing", "format mismatch", and "timeout"), and diagnostic information templates (such as "{parameter name} not filled" and "{interface name} call timeout, response code {code}"). The repair action mapping table is stored in key-value pair format, where the key is the exception pattern identifier and the value is the repair entry information (such as entry type, display position, operation logic, and parameter template).

[0064] For example, such as Figure 3 As shown, in the course publishing detection system of a certain online education platform, the anomaly matcher has more than 10 predefined anomaly modes built in, such as "abnormal course name length," "instructor qualification unverified," and "broken course resource link." When the "broken course resource link" anomaly is detected, and the diagnostic information is "video link timeout, response code 504," the anomaly matcher compares the feature keywords "link," "timeout," and "response code 504" with the anomaly mode library, accurately matching the "interface call failure - resource link timeout" mode. Based on this matching result, the system obtains the corresponding repair entry information from the repair action mapping table: the entry type is "link re-entry box + one-click verification button," the display position is on the right side of the detection result list, and the operation logic is "after the user enters a new link, the link validity detection interface is automatically called for verification," and the entry is displayed on the page in real time. Users can quickly complete the link update and verification without manually searching for the repair path.

[0065] In this embodiment of the application, responding to a repair operation and verifying the repair effect includes: constructing a repair executor and an effect verifier; based on the repair executor, executing a user-triggered repair operation, which includes parameter adjustment, data correction, or interface re-call; and simultaneously, through the effect verifier, re-running the associated detection items or executing simplified verification logic, collecting the repaired business status data and comparing it with the expected results, and outputting the verification conclusion.

[0066] Among them, the repair executor refers to a functional component that can parse the repair operation instructions triggered by the user, call the corresponding business interface, data processing module or script execution unit, and complete the anomaly repair.

[0067] It is understood that the embodiments of this application standardize the execution of various repair operations through the repair executor, ensuring the standardization and accuracy of the repair process and avoiding operational errors that may be caused by manual repair; the effect verifier can quickly verify the repair effect by rerunning the detection items or simplifying the verification logic, avoiding potential business risks caused by unverified repairs; the comparison between the business status data after repair and the expected results provides a quantitative basis for the verification conclusion, ensuring that the repair effect is measurable and traceable; the real-time output of the verification conclusion allows users to grasp the repair results in a timely manner, facilitating the advancement of subsequent business processes, and at the same time providing key input for feedback data aggregation, supporting the closed-loop optimization of the detection system.

[0068] For example, during transaction reconciliation checks in a financial payment system, an anomaly of "inconsistency between transaction amount and reconciliation amount" was detected. The diagnostic information was "Transaction amount 1000 yuan, reconciliation amount 990 yuan, difference 10 yuan." The user selected the "Data Correction" operation through the quick repair entry, entered the correct reconciliation amount of 1000 yuan, and submitted. After receiving the instruction, the repair executor called the reconciliation database update interface to correct the reconciliation amount of the corresponding transaction to 1000 yuan and recorded the repair operation log (operator, time, value before modification, value after modification). The effect verifier then executed simplified verification logic, only re-checking the consistency of the transaction amount, collecting the repaired transaction amount of 1000 yuan and the reconciliation amount of 1000 yuan, comparing them with the expected result (amount consistent), and outputting the verification conclusion "Repair successful, transaction amount and reconciliation amount consistent," ensuring that the anomaly has been completely resolved and avoiding impact on subsequent clearing processes.

[0069] In this embodiment of the application, an evaluation report is generated based on the detection and remediation feedback data, and the detection script and configuration information are updated. This includes: building a feedback data aggregator and an evaluation report generator; based on the feedback data aggregator, integrating performance indicators, anomaly distribution, remediation success rate and user operation logs during the detection execution process; and through the evaluation report generator, generating a comprehensive evaluation report that includes detection coverage, execution efficiency, anomaly detection accuracy and remediation effectiveness. Based on the script logic defects or configuration deficiencies pointed out in the report, the version update of the detection script repository and detection item configuration data is triggered.

[0070] Among them, the feedback data aggregator refers to a functional component that can extract key indicators from multiple sources of data, such as detection execution logs, repair operation records, and effect verification results, and then integrate, statistically analyze, and perform such analysis.

[0071] It is understood that the embodiments of this application comprehensively integrate the data of the entire detection and repair process through the feedback data aggregator, providing rich quantitative evidence for the evaluation report and avoiding the one-sidedness caused by traditional evaluations relying on only a single data point. The comprehensive evaluation indicators output by the evaluation report generator clearly present the operating status and optimization space of the detection system, providing data support for management decision-making. Based on the issues pointed out in the report, script and configuration updates are triggered, realizing closed-loop optimization of the detection system, which can continuously improve the accuracy, execution efficiency and repair effectiveness of the detection logic, and solve the problem that traditional detection systems are difficult to self-iterate and optimize. The version update mechanism ensures that the optimized scripts and configurations can be quickly applied to actual testing, promoting the continuous evolution of the detection system with business development.

[0072] It should be noted that the performance metrics integrated by the feedback data aggregator include average execution time of detection items, thread pool utilization, and script loading success rate; anomaly distribution includes the proportion of each anomaly type, high-frequency anomaly detection items, and the distribution of anomaly occurrence times; repair success rate includes the percentage of successful repairs for each anomaly type, first-time repair success rate, and average repair time; user operation logs include the distribution of repair operation types, user dwell time, and operation feedback ratings. The detection coverage in the evaluation report refers to the ratio of the actual number of detected anomalies to the theoretical number of anomalies; execution efficiency is measured by the average execution time of detection items and the overall detection completion time; anomaly detection accuracy refers to the ratio of the number of correctly detected anomalies to the total number of detected anomalies; and repair effectiveness includes the repair success rate and the anomaly recurrence rate after repair.

[0073] For example, in a waybill tracking system of a logistics management system, the feedback data aggregator integrates data monthly: performance metrics show that the average execution time for "waybill status update detection" is 1.2 seconds (exceeding the threshold by 0.8 seconds), and the thread pool utilization rate is 60%; anomaly distribution shows that "missing track nodes" anomalies account for 45%, making it a high-frequency anomaly; repair success rate shows that the repair success rate for "track node supplementation" is 80%, but the first-time repair success rate is only 65%; user operation logs show that 30% of users reported that "the track node supplementation entry operation is cumbersome." The evaluation report generator generates a report based on this data, pointing out that "redundant logic in the waybill status update detection script leads to excessive execution time" and "too many steps in the track node missing anomaly repair entry operation affect the first-time repair success rate." The system triggers an update based on the report: optimizing the detection script, removing redundant verification logic, reducing execution time to 0.7 seconds; simplifying the repair entry operation, merging two steps into one, and updating the repair action mapping table in the new version configuration. Subsequently, the first-time repair success rate for this anomaly increases to 88%.

[0074] A dynamic detection method based on script engine technology, proposed in this application, integrates business request parameters, basic business data, external interface data, and detection item configuration data. It leverages a script engine to drive the construction of a dynamic detection framework, enabling dynamic loading, parsing, and execution of detection logic scripts. By combining topology sorting and priority scheduling algorithms to optimize the execution order of detection items, it solves the problems of poor adaptability and low execution efficiency in traditional fixed detection logic, breaking down the disconnect between detection, repair, and optimization. Simultaneously, through pre-set rapid repair entry points, repair effect verification, and feedback data aggregation and analysis, it continuously updates the detection scripts and configuration information. This significantly improves the closed-loop optimization capability of the detection system while ensuring detection accuracy and efficiency, effectively filling the gap in the deep integration of script engines and dynamic detection, and the linkage between detection, repair, and optimization in existing technologies. It maximizes the reduction of anomaly false negative rates and detection resource waste while meeting diverse business detection needs. Thus, it solves the problems of poor adaptability and low execution efficiency in existing technologies.

[0075] The following will illustrate a dynamic detection method based on script engine technology through a specific embodiment, such as... Figure 4 As shown, it includes:

[0076] A third-party payment platform handles payment and settlement services for e-commerce platforms, offline supermarkets, and other scenarios, with a daily peak transaction volume exceeding 5 million transactions. As online fraud methods constantly evolve, traditional, fixed risk control detection rules are insufficient to address new fraud scenarios (such as fraudulent transactions for cash out, cross-platform fraud, etc.). Furthermore, rule updates require system restarts, resulting in response delays and high maintenance costs, thus increasing the platform's transaction risk exposure. To address this, the platform introduced a dynamic detection method based on script engine technology, enabling flexible iteration of risk control rules and real-time, accurate prevention and control of transaction risks.

[0077] Step 100: Build a front-end and back-end separated web system architecture

[0078] A multi-tiered distributed system architecture based on the B / S model is adopted, providing a stable and reliable basic operating environment for the subsequent construction of a script engine-driven dynamic detection framework. The front-end uses the Vue.js framework to build a responsive user interface and employs the ElementUI component library to implement unified interactive controls. The back-end uses the Spring Boot framework to build a microservice architecture, providing standardized service interfaces through a RESTful API. Secure data communication between the front-end and back-end is achieved through a token-based authentication mechanism and the Ajax protocol. Nginx is used as a reverse proxy server to achieve load balancing and high availability, and a Redis caching database is integrated to improve system performance. This scalable technical architecture supports high-concurrency access and ensures efficient operation of subsequent detection configuration and execution.

[0079] Step 200: Configure detection item metadata

[0080] Through a management interface based on the RBAC permission management model, core metadata attributes of business testing projects are defined, including project name (e.g., "Broadband Business Testing Project"), business type identifier (e.g., "broadband"), activation status, priority configuration, and other parameters. This metadata serves as the foundational business data for subsequent association of testing items. All metadata is stored in a database through a persistent framework, establishing a logical entry point for testing task execution and multi-dimensional classification management capabilities. It supports rapid retrieval and batch operation functions based on business type, facilitating subsequent matching of business request parameters with corresponding testing projects.

[0081] Step 300: Establish a dynamic correlation mechanism between testing items and testing provisions.

[0082] A configurable mapping relationship based on a directed acyclic graph is established between detection projects and detection items: target detection items are dynamically selected through a visual configuration interface, and the system automatically generates associated topology data containing execution order weights and dependencies. For detection items with sequential dependencies, a topology sorting algorithm is used to optimize the execution sequence, while priority configuration is combined to determine the final execution order; predefined quick-fix detection items are provided for abnormal situations, supporting both condition-triggered and manual intervention modes. All mapping relationships are persistently stored in Redis after JSON serialization, achieving complete decoupling and dynamic binding between detection projects and detection items, supporting the need for subsequent dynamic loading of detection logic.

[0083] Step 400: Define detection items and execute scripts

[0084] For each detection item, a business rule processing script based on a DSL domain-specific language is developed. The system defines the syntax rules and interface call specifications for the detection scripts, and provides an online IDE editor with integrated syntax highlighting, intelligent suggestions, and real-time verification, supporting mixed programming of multiple scripting languages. Developers automatically generate interface call code frameworks based on API documentation and perform end-to-end debugging in a local sandbox environment. After the scripts are verified by digital signatures, they are persistently stored in the configuration center using an incremental update strategy, supporting version number management, change history tracking, canary release, and one-click rollback mechanisms. This forms a dynamic rule base that is physically isolated from the core business system, facilitating the subsequent dynamic loading of detection logic scripts associated with target business detection items.

[0085] Step 500: Initialize the detection execution context

[0086] The runtime environment is built based on "business request parameters and detection execution context data," employing a three-layer initialization architecture: First, the detection request is parsed using an annotation-based parameter parser to extract the business account identifier and detection project ID. The database is then queried using the MyBatis-plus framework to obtain the associated detection item queue and configuration information, establishing a high-speed caching mechanism with millisecond-level response. Second, based on the interface dependency descriptions in the detection item configuration, the external system's RESTful API is called via HttpClient. A circuit breaker pattern is used to implement service degradation, performing multi-level format validation and data cleaning on the returned data, storing it in a Redis cluster, and setting a TTL expiration policy. Finally, a structured detection execution context model is built based on the builder pattern, including basic information such as transaction ID, timestamp sequence, and performance monitoring metrics. Configuration information is implemented using a prototype pattern for deep copying, and data information is type-safe through generic programming. The entire process ensures data consistency and concurrency safety through distributed locks and optimistic locking mechanisms, providing a standardized runtime environment for subsequent script execution.

[0087] Step 600: Asynchronous Dynamic Execution Based on Script Engine

[0088] At startup, a multi-instance script engine pool is initialized using a factory pattern, and engine instances are managed using an LRU algorithm. Configurable execution timeout and memory limit parameters are set. Based on the versioned script ID configured for the detection item, the latest encrypted script is obtained through the configuration center client. After verification, the execution environment is dynamically constructed based on reflection, and context data is injected into script variables through a parameter binder. Combining the topology sorting results and priority configuration associated with the detection item, a high-performance thread pool is used to manage asynchronous execution tasks. Performance metrics are collected in real time during worker thread execution, and execution logs and exception information are captured through aspect-oriented programming to generate execution results containing multi-dimensional status codes, structured diagnostic data, and performance analysis reports. Simultaneously, real-time push of execution results is achieved through WebSocket long connections, and the front end provides visualization and interactive control based on state management.

[0089] Step 700: Generate a decision-oriented testing report

[0090] First, the backend aggregates the detection results to generate a structured report. After all detection items are executed, the backend aggregates the structured results of each detection item, sorts them according to the execution order, filters invalid data, generates a JSON-formatted detection report, and persists it to the database, recording the version number. Business traffic routing adopts a state machine pattern: when all tests are successful, resource cleanup and data archiving are completed asynchronously via a message queue; when failures occur, a rule engine is triggered, providing pre-defined quick repair entry points through a strategy pattern, supporting a three-level processing mechanism of one-click repair, automatic retries, and manual intervention. After a user triggers a repair operation, the backend calls the pre-defined repair function through reflection and verifies the repair effect. Finally, an evaluation report is generated based on the detection and repair feedback data, and the detection scripts and configuration information are synchronously updated to the configuration center, completing the closed-loop management of dynamic detection.

[0091] In summary, this invention provides a stable and reliable high-concurrency operating environment for dynamic risk control detection by constructing a multi-layered distributed web system architecture with front-end and back-end separation, combined with a detection item metadata configuration system based on RBAC permission management. Relying on the directed acyclic graph dynamic association mechanism between detection items and detection parameters, and coupled with the scripted definition and version management mode of risk control rules in a DSL domain-specific language, it enables flexible iteration of risk control rules without system restarts, effectively reducing operation and maintenance costs and eliminating the response lag problem of rule updates. When the script engine executes asynchronously, it uses topology sorting and priority scheduling algorithms, combined with real-time performance acquisition and WebSocket long-connection push mechanisms, to achieve an average daily throughput of 5... Real-time and precise risk control under peak transaction volumes of 100 million transactions reduces the platform's transaction risk exposure; the intelligent detection system supports visualized interaction of detection results and a three-tiered handling mechanism including one-click repair and manual intervention, combined with distributed locks and optimistic locks to ensure data consistency, while reducing invalid system operations, improving risk handling efficiency, and enhancing the agility of risk control management; through the feedback data of decision-oriented detection reports and the iterative updates of detection scripts and configuration information, a closed-loop management of "detection-repair-optimization" is formed to ensure that risk control capabilities are adapted to new fraud scenarios, continuously improve the accuracy of risk prevention and control and the adaptability to business scenarios, and achieve a balance between the stability of high-concurrency business of the payment platform and the agility of risk control management.

[0092] Secondly, this application proposes a dynamic detection system based on script engine technology.

[0093] This dynamic detection system based on script engine technology includes: an acquisition module, a parsing module, and a generation module.

[0094] The module comprises the following components: an acquisition module, a parsing module, and a generation module. The acquisition module acquires business request parameters, basic business data, external interface data, and detection item configuration data. The parsing module, based on the basic business data and detection item configuration data, constructs a script engine-driven dynamic detection framework, defines the detection script syntax rules, execution order specifications, and dependency mechanisms. It also dynamically loads the detection logic scripts associated with the target business detection items based on the business request parameters and detection execution context data. The script engine parses and executes the detection logic, determines the execution order of detection items using topology sorting and priority scheduling algorithms, executes the detection logic asynchronously using a thread pool, and outputs the execution results and diagnostic information of each detection item in real time. The generation module provides pre-set quick repair entry points for abnormal detection items based on the execution results and diagnostic information of each detection item, responds to repair operations, verifies the repair effect, generates an evaluation report based on the detection and repair feedback data, and updates the detection scripts and configuration information.

[0095] It should be noted that the foregoing explanation of an embodiment of a dynamic detection method based on script engine technology also applies to an embodiment of a dynamic detection system based on script engine technology, and will not be repeated here.

[0096] A dynamic detection system based on script engine technology, as proposed in this application, integrates business request parameters, basic business data, external interface data, and detection item configuration data. It leverages a script engine to drive the construction of a dynamic detection framework, enabling dynamic loading, parsing, and execution of detection logic scripts. By combining topology sorting and priority scheduling algorithms to optimize the execution order of detection items, it solves the problems of poor adaptability and low execution efficiency in traditional fixed detection logic, breaking down the disconnect between detection, repair, and optimization. Simultaneously, through pre-set rapid repair entry points, repair effect verification, and feedback data aggregation and analysis, it continuously updates the detection scripts and configuration information. This significantly improves the closed-loop optimization capability of the detection system while ensuring detection accuracy and efficiency, effectively filling the gap in the deep integration of script engines and dynamic detection, and the linkage between detection, repair, and optimization in existing technologies. It maximizes the reduction of anomaly false negative rates and detection resource waste while meeting diverse business detection needs. Thus, it solves the problems of poor adaptability and low execution efficiency in existing technologies.

[0097] Figure 5 A schematic diagram of the structure of an electronic device provided in an embodiment of this application. The electronic device may include:

[0098] The memory 501, the processor 502, and the computer program stored on the memory 501 and capable of running on the processor 502.

[0099] When the processor 502 executes the program, it implements a dynamic detection method based on script engine technology provided in the above embodiments.

[0100] Furthermore, electronic devices also include:

[0101] Communication interface 503 is used for communication between memory 501 and processor 502.

[0102] The memory 501 is used to store computer programs that can run on the processor 502.

[0103] The memory 501 may include high-speed RAM (Random Access Memory) memory, and may also include non-volatile memory, such as at least one disk storage device.

[0104] If the memory 501, processor 502, and communication interface 503 are implemented independently, then the communication interface 503, memory 501, and processor 502 can be interconnected via a bus to complete communication between them. The bus can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus, etc. The bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 5 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0105] Optionally, in a specific implementation, if the memory 501, processor 502, and communication interface 503 are integrated on a single chip, then the memory 501, processor 502, and communication interface 503 can communicate with each other through an internal interface.

[0106] Processor 502 may be a CPU (Central Processing Unit), an ASIC (Application Specific Integrated Circuit), or one or more integrated circuits configured to implement embodiments of this application.

[0107] In the description of this specification, the references to "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0108] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified.

[0109] Any process or method description in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing custom logic functions or processes, and the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functions involved, as should be understood by those skilled in the art to which embodiments of this application pertain.

[0110] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware as in another embodiment, it can be implemented using any of the following techniques known in the art, or a combination thereof: discrete logic circuits having logic gates for implementing logical functions on data signals, application-specific integrated circuits (ASICs) having suitable combinational logic gates, programmable gate arrays (PGAs), field-programmable gate arrays (FPGAs), etc.

[0111] Those skilled in the art will understand that all or part of the steps of the methods described in the above embodiments can be implemented by a program instructing related hardware, and the program can be stored in a computer-readable storage medium. When executed, the program includes one or a combination of the steps of the method embodiments.

[0112] Although embodiments of this application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting this application. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of this application.

Claims

1. A dynamic detection method based on script engine technology, characterized in that, include: Obtain business request parameters, basic business data, and detection item configuration data; Based on the aforementioned basic business data and detection item configuration data, a script engine-driven dynamic detection framework is constructed. This framework defines detection script syntax rules, execution order specifications, and dependency mechanisms. Simultaneously, based on the business request parameters and detection execution context data, the detection logic scripts associated with the target business detection items are dynamically loaded. The script engine parses and executes the detection logic, using a topology sorting and priority scheduling algorithm. The topology sorting formula is as follows: ； in, Let j be the i-th detection item node; j is the traversal variable for the summation operation; and n is the total number of detection items. To indicate from the detection item arrive The directed edges; To indicate from the detection item arrive The directed edges; The node representing the deleted detection item; for The set of adjacent nodes; IsValidTopo is the validity identifier of the topology sort, where 1 represents a valid topology sort and 0 represents an invalid topology sort; the execution order of the detection items is determined, wherein the detection logic is parsed and executed by the script engine, and the execution order of the detection items is determined according to the topology sorting and priority scheduling algorithm, including: building a dependency relationship resolver and a scheduler; based on the dependency relationship resolver, analyzing the dependency declarations of the detection items in the detection logic script, and generating a directed acyclic graph of the detection items; using the scheduler, performing topology sorting on the directed acyclic graph, and determining the execution order queue in combination with the priority weights defined in the detection item configuration data; the detection logic is executed asynchronously through a thread pool, and the execution results and diagnostic information of each detection item are output in real time; Based on the execution results and diagnostic information of each detection item, a pre-defined quick repair entry point is provided for abnormal detection items. This process includes: constructing an anomaly matcher and a repair action mapping table; matching the execution results and diagnostic information of the detection items with predefined anomaly patterns based on the anomaly matcher to obtain matching results; obtaining and presenting the corresponding quick repair operation entry point based on the matching results and the repair action mapping table; responding to the repair operation and verifying the repair effect; generating an evaluation report based on the detection and repair feedback data; and updating the detection script and configuration information.

2. The dynamic detection method based on script engine technology according to claim 1, characterized in that, Based on the business request parameters and the detection execution context data, dynamically load the detection logic script associated with the target business detection project, including: Build a detection script repository and dynamic loading manager; Based on the dynamic loading manager, the corresponding detection logic script file is retrieved from the detection script repository according to the project identifier and version number in the business request parameters; Based on the detection logic script file, the detection execution context data is injected into the script runtime environment to dynamically load the detection logic script associated with the target business detection project. The context data includes request parameters, basic business data snapshots, and external interface data caches.

3. The dynamic detection method based on script engine technology according to claim 1, characterized in that, Respond to repair operations and verify the repair results, including: Build a repair executor and an effect verifier; Based on the repair executor, user-triggered repair operations are executed, including parameter adjustment, data correction, or interface re-call. Simultaneously, through the effect verifier, associated detection items are re-run or simplified verification logic is executed, repaired business status data is collected and compared with expected results, and verification conclusions are output.

4. The dynamic detection method based on script engine technology according to claim 1, characterized in that, An evaluation report is generated based on the detection and remediation feedback data, and the detection scripts and configuration information are updated, including: Build a feedback data aggregator and an evaluation report generator; Based on the feedback data aggregator, the performance indicators, anomaly distribution, repair success rate and user operation logs during the detection execution process are integrated. Through the evaluation report generator, a comprehensive evaluation report is generated, which includes detection coverage, execution efficiency, anomaly detection accuracy and repair effectiveness. Based on the script logic defects or configuration deficiencies pointed out in the report, the version update of the detection script repository and detection item configuration data is triggered.

5. The dynamic detection method based on script engine technology according to claim 1, characterized in that, The priority scheduling algorithm formula is as follows: ； Among them, Priority is the priority score of the detection item; This is the node for the i-th detection item; Let be the weighting coefficient, satisfying ; Assign importance score to the test item; The urgency of the test item is scored; The in-degree of the detection item node; This represents the maximum in-degree of all detected item nodes; This is the resource usage score for the detection item.

6. A dynamic detection system based on script engine technology, characterized in that, include: The acquisition module is used to acquire business request parameters, basic business data, external interface data, and detection item configuration data. The parsing module is used to construct a script engine-driven dynamic detection framework based on the basic business data and detection item configuration data. It defines the detection script syntax rules, execution order specifications, and dependency mechanisms. Simultaneously, based on the business request parameters and detection execution context data, it dynamically loads the detection logic scripts associated with the target business detection item. The script engine parses and executes the detection logic, using a topology sorting and priority scheduling algorithm. The topology sorting formula is as follows: ； in, Let j be the i-th detection item node; j is the traversal variable for the summation operation; and n is the total number of detection items. To indicate from the detection item arrive The directed edges; To indicate from the detection item arrive The directed edges; The node representing the deleted detection item; for The set of adjacent nodes; IsValidTopo is the validity identifier of the topology sort, where 1 represents a valid topology sort and 0 represents an invalid topology sort; the execution order of the detection items is determined, wherein the detection logic is parsed and executed by the script engine, and the execution order of the detection items is determined according to the topology sorting and priority scheduling algorithm, including: building a dependency relationship resolver and a scheduler; based on the dependency relationship resolver, analyzing the dependency declarations of the detection items in the detection logic script, and generating a directed acyclic graph of the detection items; using the scheduler, performing topology sorting on the directed acyclic graph, and determining the execution order queue in combination with the priority weights defined in the detection item configuration data; the detection logic is executed asynchronously through a thread pool, and the execution results and diagnostic information of each detection item are output in real time; The generation module is used to provide pre-set quick repair entry points for abnormal detection items based on the execution results and diagnostic information of each detection item. This includes: constructing an anomaly matcher and a repair action mapping table; matching the execution results and diagnostic information of the detection items with predefined anomaly patterns based on the anomaly matcher to obtain matching results; obtaining and presenting the corresponding quick repair operation entry point based on the matching results and the repair action mapping table; responding to the repair operation and verifying the repair effect; generating an evaluation report based on the detection and repair feedback data; and updating the detection script and configuration information.

7. An electronic device, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor executes the program to implement the dynamic detection method based on script engine technology as described in any one of claims 1-5.

Images