Method and system for processing data self-audit tasks

Abstract

This application provides a method and system for processing data self-audit tasks, including: intercepting a user's trigger operation for a target task to prevent the execution of the data processing operation corresponding to the target task; sending a pre-check query request to the server to obtain predefined rule information associated with the target task returned by the server; generating a secondary confirmation interface based on the predefined rule information; and sending a task processing request to the server when a confirmation instruction triggered by the user on the secondary confirmation interface is received, so that the server executes the data processing operation corresponding to the target task. This method, by introducing operation interception and pre-check query mechanisms into the data self-audit task execution process, can improve the integrity and security of core data assets in the data governance platform.

Description

Technical Field

[0001] This application relates to the field of computer data processing technology, and in particular to a method and system for processing data self-examination tasks. Background Technology

[0002] In the data middle platform or data governance platform of large enterprises, the processing personnel need to review and process a large number of data self-audit tasks generated every day. These tasks usually involve business scenarios such as data quality verification, data standard review and security scanning of core data assets.

[0003] Existing processing methods typically employ a direct trigger mechanism. After finding the target task in the task list interface, the user directly clicks a button such as "Process," "Approve," or "Reject," and the system immediately invokes the backend service to execute the corresponding data modification logic. Because the task list is densely packed, and existing secondary confirmation mechanisms often consist of static text lacking contextual risk warnings, users are highly prone to accidental clicks when fatigued or experiencing interface lag. Once an accidental click occurs, the system immediately performs data modification or deletion operations that are often irreversible or have extremely high recovery costs. Summary of the Invention

[0004] In view of this, the purpose of this application is to provide a processing method and system based on data self-audit tasks. By introducing operation interception and pre-inspection query mechanisms into the data self-audit task execution process, the risk of misoperation caused by click behavior directly triggering core data changes in the prior art can be eliminated, thereby improving the integrity and security of core data assets in the data governance platform.

[0005] In a first aspect, the present invention provides a method for processing a data self-examination task, comprising: In response to a user's triggering action for a target task, the triggering action is intercepted to prevent the data processing operation corresponding to the target task from being executed.

[0006] Send a pre-check query request to the server for the target task to obtain predefined rule information associated with the target task returned by the server.

[0007] A secondary confirmation interface is generated based on predefined rule information; the secondary confirmation interface includes risk warning content generated based on the predefined rule information.

[0008] When a confirmation command triggered by the user on the secondary confirmation interface is received, a task processing request is sent to the server so that the server can perform the data processing operation corresponding to the target task.

[0009] In an optional implementation, the step of intercepting the triggering operation in response to a user's triggering operation for a target task includes: Listen for trigger events of the processing controls for the target task.

[0010] When an event is triggered, prevent the preset execution behavior corresponding to the triggering operation from being executed.

[0011] In an optional implementation, the triggering operation includes a click operation and / or an operation triggered based on preset interaction conditions.

[0012] In an optional implementation, the step of sending a pre-detection query request for the target task to the server includes: Obtain the identification information of the target task.

[0013] A pre-inspection query request is generated based on the identification information and sent to the server through an asynchronous communication interface.

[0014] Receive predefined rule information returned by the server; wherein, the predefined rule information is obtained by the server from the preset rule information database based on the identification information.

[0015] In an optional implementation, the predefined rule information includes at least one of the attribute information of the data object associated with the target task and the operation impact information.

[0016] In an optional implementation, the step of generating a secondary confirmation interface based on predefined rule information includes: Extract risk warning fields from predefined rule information and generate risk warning content based on these fields.

[0017] The risk warning content is dynamically populated into the preset confirmation interface template to generate a visual risk warning message.

[0018] The front-end interface uses visual risk warnings and interactive controls to render and display a secondary confirmation interface.

[0019] In an optional implementation, the step of rendering and displaying the secondary confirmation interface includes: Obtain the role and permission verification results returned by the server based on the user's identity identifier.

[0020] When the role permission verification result indicates insufficient permissions, the interactive control corresponding to the confirmation command is disabled in the secondary confirmation interface.

[0021] In an optional implementation, the step of sending a task processing request to the server when a confirmation command triggered by the user on the secondary confirmation interface is received includes: Upon receiving the confirmation instruction, a task processing request is constructed based on the identification information of the target task.

[0022] Send a task processing request to the server to trigger the server to perform data processing operations.

[0023] In an optional implementation, the method further includes: When a cancellation command is received from the user on the secondary confirmation screen, the secondary confirmation screen is closed, and the current state of the target task remains unchanged.

[0024] Secondly, the present invention provides a data self-examination task processing system, comprising: The operation interception module is used to respond to user-triggered operations on a target task and intercept the triggered operations to prevent the data processing operations corresponding to the target task from being executed.

[0025] The pre-check query module is used to send a pre-check query request to the server for the target task in order to obtain the predefined rule information associated with the target task returned by the server.

[0026] The interface generation module is used to generate a secondary confirmation interface based on predefined rule information; the secondary confirmation interface includes risk warning content generated based on the predefined rule information.

[0027] The task execution module is used to send a task processing request to the server when it receives a confirmation command triggered by the user on the secondary confirmation interface, so that the server can perform the data processing operation corresponding to the target task.

[0028] This application provides a method and system for processing data self-audit tasks. By intercepting the execution process when a user performs an operation on a target task, and introducing a pre-inspection query mechanism based on the target task to obtain predefined rule information associated with the task, a secondary confirmation interface containing risk warnings is generated. The server is only triggered to perform data processing operations after the user confirms the confirmation. This allows users to make decisions with full access to task-related risk information, improving the security and controllability of the data processing process. It also enhances users' awareness of the consequences of their operations and the accuracy of their decisions. Furthermore, it achieves pre-control of high-risk operations without changing the original data processing logic, thus improving system compatibility.

[0029] Other features and advantages of this application will be set forth in the following description and will be apparent in part from the description or may be learned by practicing the application.

[0030] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

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

[0032] Figure 1 A flowchart illustrating the data self-examination task processing method provided in this application embodiment; Figure 2 This is a flowchart of the interception method for triggering operations provided in an embodiment of this application; Figure 3 Flowchart of the pre-detection query request sending method provided in the embodiments of this application; Figure 4 Flowchart of the method for generating a secondary confirmation interface provided in the embodiments of this application; Figure 5 A flowchart of a task processing request sending method provided in an embodiment of this application; Figure 6 A schematic diagram of the data self-examination task processing system provided in this application embodiment.

[0033] Icons: 1-Operation interception module; 2-Pre-inspection query module; 3-Interface generation module; 4-Task execution module. Detailed Implementation

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

[0035] To help those skilled in the art better understand this application, a brief introduction to its application scenarios and design concepts is provided.

[0036] In practical data governance platforms, there are typically numerous data self-audit tasks awaiting processing, such as data quality verification, data standard review, and data security scanning. Personnel usually process these tasks one by one through a task list interface. In existing technologies, after a user selects a target task on the interface, clicking the corresponding processing control (such as "Process," "Pass," or "Reject") directly triggers the backend logic to execute the corresponding data processing operation.

[0037] However, the following technical problems exist: First, there is a lack of an effective buffer mechanism between operation triggering and data processing execution. Once a user accidentally touches a processing control, the system immediately executes the corresponding data processing operation. This can easily lead to misoperation due to accidental clicks, user fatigue, or interface response delays, causing irreversible damage to the data and reducing the security and reliability of data processing. Second, existing systems typically only provide simple confirmation prompts, and the prompts are mostly fixed text, without dynamically displaying the actual risk information of the target task. This prevents users from fully understanding the importance and scope of the data involved in the task before performing the operation, thus affecting the accuracy of their judgment. Third, existing solutions lack the ability to proactively perceive and warn of task risks. The front-end interaction process and back-end rule information are not effectively linked, making it difficult to effectively warn and intervene in potential risks before operation execution.

[0038] Based on this, embodiments of this application provide a method and system for processing data self-audit tasks. By intercepting the user's triggering of a target task processing operation and initiating a pre-inspection query request to the server to obtain predefined rule information associated with the target task, a secondary confirmation interface containing risk warnings is generated. This allows the user to obtain risk information related to the task before executing the operation, and the data processing operation is only triggered after confirmation. Without changing the original data processing logic, a risk perception and confirmation mechanism is introduced into the operation execution path, achieving pre-control of data processing operations.

[0039] This application effectively reduces data processing risks caused by misoperation and improves the security of the data processing process. By generating dynamic risk warnings based on predefined rules, users gain sufficient decision-making basis before operation, thereby improving the accuracy and standardization of operations. Furthermore, this application achieves the above functions through front-end and back-end collaboration, without requiring complex modifications to the underlying data processing logic, exhibiting good compatibility and scalability, and facilitating deployment in existing systems.

[0040] To facilitate understanding of this embodiment, the embodiments of this application will be described in detail below.

[0041] This application provides a method for processing data self-examination tasks, referring to... Figure 1 The data self-examination processing method provided in this application includes: Step S101: In response to the user's trigger operation for the target task, the trigger operation is intercepted to prevent the data processing operation corresponding to the target task from being executed.

[0042] Here, in the task list interface of the data governance platform or data middleware, personnel can execute processing instructions for a specific target task in the task list by clicking the mouse, tapping the touchscreen, or entering shortcut keys. Target tasks can include data quality verification tasks, data standard review tasks, data security scanning tasks, or data cleanup tasks. When a user clicks the "Process," "Pass," or "Reject" button next to a target task, the front-end code listens for and captures the triggered operation in real time.

[0043] Upon capturing a triggering operation, the default commit behavior of that operation is immediately intercepted by calling an event interception function (such as event.preventDefault()) or by setting a logical gating switch. This ensures that the system does not immediately send a formal data change request to the backend execution engine after the user clicks the button. This front-end interception method eliminates the risk of irreversible data corruption caused by accidental actions, user fatigue, or interface lag, and prevents the data processing operations corresponding to the target task from being executed without secondary confirmation.

[0044] In one implementation, the timing of the trigger operation is not limited to a click action; it can also be triggered by detecting that the positioning device (such as a mouse cursor) hovers over the processing control of the target task for more than a preset time threshold (such as 2 seconds). In this case, the system will automatically identify the user's intention to perform the action and initiate the interception logic and subsequent pre-inspection process before the user actually clicks, thereby providing more proactive operational security.

[0045] Step S102: Send a pre-check query request for the target task to the server to obtain the predefined rule information associated with the target task returned by the server.

[0046] Here, after the interception action occurs, the front-end application initiates an asynchronous preflight query request to the server-side preflight interface via an asynchronous communication interface (such as Ajax or the Fetch API). This preflight query request carries task identifier information that uniquely identifies the target task. Upon receiving the preflight query request, the server parses the task identifier and retrieves the predefined rule information bound to the target task from the backend rule information database or data governance rule base.

[0047] Predefined rule information refers to risk attribute data that is pre-configured by the system administrator or generated by automated scripts based on the data dictionary during the task creation phase. This information is typically encapsulated in structured data formats such as JSON or XML and returned to the front-end application. Specifically, predefined rule information may include attribute information of data objects associated with the target task (such as the name of the associated data table, the number of associated data tables, the data source path, etc.) and operational impact information (such as data criticality level P0 / P1 / P2, the estimated scope of downstream business systems affected, the dimensions of the affected user profiles, and the relevance of billing and accounting logic, etc.).

[0048] In addition, the predefined rule information can be further expanded to include reference metrics for task execution, such as the estimated processing time for this type of task, the historical rollback rate of this type of operation in the past thirty days, or the success rate of the operation.

[0049] Step S103: Generate a secondary confirmation interface based on predefined rule information; wherein, the secondary confirmation interface includes risk warning content generated based on predefined rule information.

[0050] Here, after successfully receiving the predefined rule information returned by the server, the front-end application automatically calls the interface rendering engine for processing. First, it parses the various risk dimension parameters in the predefined rule information and transforms these technical parameters into easily understandable visual prompt text according to pre-set mapping logic. Next, it populates these dynamically generated risk prompts into a preset secondary confirmation interface template.

[0051] The secondary confirmation interface is displayed in a prominent position on the user interface in the form of a pop-up, floating window, or sidebar. The generated risk warning content is not fixed static text, but rather contextual information highly relevant to the current target task. For example, the risk warning content may explicitly state: The task the user is about to handle involves three core business tables, the data level is extremely high risk, and the operation will affect the user profile and billing system.

[0052] The process of generating the secondary confirmation interface can also incorporate permission verification logic. If the server returns a verification result indicating that the current user's role permissions are insufficient to handle tasks of that risk level, the system will automatically set the confirmation instruction controls (such as the confirmation processing button) on the interface to an unclickable state or hide them directly while generating the secondary confirmation interface, and display a warning message about insufficient permissions to the user.

[0053] Step S104: When a confirmation instruction triggered by the user on the secondary confirmation interface is received, a task processing request is sent to the server so that the server can perform the data processing operation corresponding to the target task.

[0054] Here, if a user views the risk warning and believes the operation is risky and clicks the cancel button, the front-end application will directly destroy the DOM elements of the secondary confirmation interface, terminating the entire process. The status of the target task and the associated data assets will not change.

[0055] If the user confirms the operation is correct and triggers the confirmation command on the secondary confirmation interface (such as clicking the confirmation button), the front-end application will then formally build and send a task processing request to the server's task processing interface. This task processing request also carries a task identifier and necessary verification tokens. Only after receiving this formal task processing request will the server's task execution engine actually begin executing the core logic related to the target task, such as data modification, data deletion, state changes, or rule validation.

[0056] By introducing an intelligent interruption and confirmation process, the originally high-risk direct operation is transformed into an information-driven safe operation, which maximizes the accuracy and security of data processing without affecting operational efficiency.

[0057] In an optional implementation, refer to Figure 2 Step S101 includes the following steps S201-S202.

[0058] Step S201: Listen for trigger events of the processing control for the target task.

[0059] Here, in the task list interface of the data governance platform, the front-end application uses JavaScript code to monitor the real-time status of the processing controls corresponding to each target task. These processing controls are typically represented by "Process," "Approve," or "Reject" buttons on the interface. The monitoring mechanism is implemented by binding specific event listeners to the processing controls; these event listeners can capture various user interactions.

[0060] When a user interacts with the processing controls using a mouse, touchscreen, or other input device, the front-end application immediately recognizes and captures the signal generated by that interaction. This monitoring mechanism ensures that any initial operation that might lead to changes in back-end data is detected by the system.

[0061] Step S202: When the triggering event is triggered, prevent the preset execution behavior corresponding to the triggering operation.

[0062] Here, when the listener captures the trigger event of the control, the front-end application does not submit a data processing request to the back-end server directly according to the usual logic. Instead, the front-end application immediately calls a preset interception function (such as executing the `event.preventDefault()` method) to sever the association between the trigger event and the browser's default submission behavior at the underlying logic level. In this way, the trigger operation can be successfully intercepted, and the preset execution behavior corresponding to the trigger operation can be prevented, that is, the behavior of immediately calling the back-end service to execute the data change logic can be prevented. This interception mechanism provides users with an operation buffer period, allowing the system to initiate subsequent risk pre-check processes before actually performing irreversible data modification or deletion operations.

[0063] In an optional implementation, the triggering operation includes a click operation and / or an operation triggered based on preset interaction conditions.

[0064] In practical applications, triggering operations can take several flexible forms. The first common form is a click operation, where the operator issues a processing command by clicking the left mouse button or a touchscreen control. The second form is an operation triggered based on preset interaction conditions. This method does not rely on a specific click action but rather determines the user's intent by recognizing specific interactive behaviors.

[0065] In one feasible implementation, the preset interaction condition can be set as a mouse hover trigger mode. When the operator moves and hovers the mouse cursor over the processing control, and the hover duration exceeds a preset time threshold (e.g., 2 seconds), the preset interaction condition is automatically determined to be met, thereby triggering a pre-check query request and displaying risk information in a pop-up window on the interface. This hover duration-based triggering method allows operators to perceive the potential data risks of the target task more proactively before officially clicking confirm.

[0066] In addition, preset interaction conditions can include double-click operations, specific key combinations, or long-press operations, among other methods. These diverse triggering modes together constitute the system's operation perception layer, enhancing the flexibility of the interaction process.

[0067] In an optional implementation, refer to Figure 3 The step of sending a pre-check query request for the target task to the server in step S102 includes the following steps S301-S303.

[0068] Step S301: Obtain the identification information of the target task.

[0069] Here, after the front-end application successfully intercepts the triggered operation targeting the task, it automatically extracts the target task's identification information from the context data of the current task list. The target task's identification information is a unique identifier that uniquely points to that specific self-review task, such as a task ID. The task ID is automatically generated by the system when the task is created and bound to the corresponding processing control in the task list interface. The front-end application ensures that it can accurately obtain the target task's identification information by reading the control's attribute values ​​or associated data model.

[0070] Step S302: Generate a pre-inspection query request based on the identification information, and send the pre-inspection query request to the server through an asynchronous communication interface.

[0071] Here, after obtaining the target task's identification information, the front-end application invokes pre-defined request construction logic to encapsulate the target task's identification information into the preflight query request data packet. The front-end application then uses asynchronous communication interfaces such as Ajax or the Fetch API to send this preflight query request asynchronously to a specific preflight interface address on the server. The purpose of using asynchronous communication interfaces is to avoid blocking other interactive logic on the front-end interface during the query initiation process, while ensuring a smooth silent preflight process after the interception operation. The preflight query request carries the target task's identification information across the network layer to reach the server, triggering the server's logic processing flow.

[0072] Step S303: Receive predefined rule information returned by the server; wherein the predefined rule information is obtained by the server from a preset rule information database based on the identification information.

[0073] Here, upon receiving a pre-detection query request, the server-side interface controller parses out the target task's identifier information. Subsequently, the server-side data access layer performs a matching query in a pre-defined rule information database or a data governance rule base based on this identifier information. The pre-defined rule information database stores risk parameters defined by the system administrator or automated scripts at the time of task creation. The server encapsulates the retrieved parameters into predefined rule information in a pre-defined format (e.g., JSON data) and sends it back to the front-end application via an HTTP response. The front-end application receives this predefined rule information and caches it in memory, ready for subsequent UI rendering and content population.

[0074] In an optional implementation, the predefined rule information includes at least one of the attribute information of the data object associated with the target task and the operation impact information.

[0075] Here, the predefined rule information is a core dataset used to quantify the risk level of the target task. The attribute information of the data objects associated with the target task is mainly reflected in the associated data object data, specifically including the names of the associated data tables involved in the execution of the target task, the number of associated data tables, and the storage location of the data.

[0076] Operation impact information describes the potential business consequences of executing the task, specifically including data importance level information and impact scope information. Data importance level information defines the criticality of the processed data, typically using hierarchical labels such as P0, P1, and P2. For example, P0 represents extremely critical core business data. Impact scope information describes the downstream systems or business modules that may be affected by the operation in terms of data lineage. For example, the impact scope may include user profiling systems, billing systems, and reporting systems.

[0077] Furthermore, predefined rule information may also include the estimated processing time of the target task, informing the user of the potential waiting time when performing the operation; and may also include historical operation rollback rate information for the target task, providing users with historical experience-based decision-making support by statistically analyzing the probability of similar tasks being manually rolled back within the past thirty days. By including at least one of the following: related data object data, data importance level information, and impact scope information, predefined rule information can provide detailed and context-sensitive risk warnings for the secondary confirmation interface.

[0078] In an optional implementation, refer to Figure 4 Step S103 includes the following steps S401-S403.

[0079] Step S401: Extract the risk warning field from the predefined rule information and generate the risk warning content based on the risk warning field.

[0080] Here, after successfully receiving the predefined rule information data packet returned by the server via network protocol, the front-end application automatically initiates data parsing logic. The front-end application uses a preset parsing algorithm to extract multiple risk warning fields from the predefined rule information. These risk warning fields specifically include key parameters such as the name of the data table associated with the target task, the number of associated data tables, the data criticality level, and the estimated scope of operational impact. After extracting the risk warning fields, the front-end application performs string concatenation or template mapping based on these fields to generate risk warning content that corresponds to the current target task in real time. This risk warning content generated based on field extraction ensures that the warning information has a high degree of business context relevance, rather than being fixed static text, thus providing accurate decision support for processing personnel.

[0081] Step S402: Dynamically populate the risk warning content into the preset confirmation interface template to generate visual risk warning content.

[0082] Here, after the front-end application obtains the generated risk warning content, it calls a preset confirmation interface template pre-stored in the local cache or remote configuration center. The preset confirmation interface template defines the layout structure, style specifications, and text placeholders for the secondary confirmation interface. The front-end application uses dynamic binding technology to populate the risk warning content into the corresponding placeholder positions in the preset confirmation interface template in real time, thereby generating a complete and visually appealing risk warning.

[0083] The visual risk warning is presented as follows: "The system has detected that the task you are about to process has the ID DATA-AUDIT-2025-001; the associated data tables are 3 core business tables; the data level is P0 (extremely high); the impact involves user profiles and the billing system."

[0084] Step S403: Render and display a secondary confirmation interface on the front-end interface based on the visual risk warning content and interactive controls.

[0085] Here, after generating the visual risk warning content, the front-end application uses the front-end framework's rendering engine to build and pop up a secondary confirmation interface on top of the current task list interface. While displaying the visual risk warning content, the secondary confirmation interface also simultaneously loads and renders necessary interactive controls. These interactive controls include at least a "Confirm Process" button for receiving user confirmation instructions and a "Cancel" button for receiving user cancellation instructions.

[0086] In an optional implementation, the secondary confirmation interface may also include an auxiliary information box displaying the estimated processing time of the task or the historical operation rollback rate, as well as a prompt label for secondary permission verification. By rendering and displaying the secondary confirmation interface, the front-end application forcibly establishes an interactive barrier before personnel perform core data change operations, requiring them to fully read and understand the visual risk warnings before making a clear selection through interactive controls. This achieves the technical objective of preventing accidental clicks and misoperations at the system level.

[0087] In an optional implementation, the step of rendering and displaying the secondary confirmation interface in step S403 includes the following steps S501-S502.

[0088] Step S501: Obtain the role permission verification result returned by the server based on the user's identity identifier.

[0089] Here, during the rendering and display of the secondary confirmation interface, the server, upon receiving a pre-check query request and retrieving rule information, simultaneously triggers permission auditing logic. The server extracts the identity identifier of the currently logged-in user and matches it against the predefined rule information corresponding to the target task. The predefined rule information includes the data importance level, and the server determines whether the current user's role permissions are sufficient to execute tasks with the corresponding data importance level. Subsequently, the server encapsulates the generated role permission verification result in an asynchronous response data packet and returns it to the front-end application. While parsing the predefined rule information, the front-end application obtains the role permission verification result returned by the server based on the user's identity identifier, thus providing a decision-making basis for the interaction state of the secondary confirmation interface.

[0090] Step S502: When the role permission verification result indicates insufficient permissions, disable the interactive control corresponding to the confirmation command in the secondary confirmation interface.

[0091] Here, after obtaining the role permission verification result, the front-end application performs a logical judgment on the result. If the role permission verification result indicates that the current user's permissions are insufficient to handle the target task (e.g., a regular user attempting to handle a highly critical task), the front-end application automatically changes the operability of interactive controls during the generation and rendering of the secondary confirmation interface. Specifically, the front-end application disables the interactive controls corresponding to the confirmation command in the secondary confirmation interface (e.g., setting the confirmation button to an unclickable grayed-out state), thereby ensuring that the user cannot issue the final task processing request through this interface. Simultaneously, the front-end application adds an additional permission insufficient warning message to the visual risk warning content, such as "Your permissions are insufficient, please contact the administrator." In this way, the anti-misoperation interception mechanism is deeply integrated with the permission control system, further improving the execution security of high-risk data governance tasks.

[0092] In an optional implementation, refer to Figure 5 Step S104 includes the following steps S601-S602.

[0093] Step S601: After receiving the confirmation instruction, construct a task processing request based on the identification information of the target task.

[0094] Here, after the secondary confirmation interface is rendered and displayed, the process enters the human decision-making stage. If the operator, after reading the visual risk warning and confirming that the operation is correct, triggers the confirmation button on the secondary confirmation interface by clicking, touching, or using a shortcut key, the front-end application will immediately capture the confirmation instruction.

[0095] Upon receiving the confirmation command, the frontend application extracts the pre-cached identifier information of the target task and constructs a formal task processing request according to the interface protocol of the backend task execution engine. The task processing request includes the identifier information of the target task, the current user's authentication token, and the operation instruction type after secondary confirmation. This process of constructing the task processing request ensures that the data packet ultimately sent to the server has a complete execution context, enabling it to be accurately identified and responded to by the backend logic.

[0096] Step S602: Send the task processing request to the server to trigger the server to perform data processing operations.

[0097] Here, the front-end application sends the constructed task processing request to the server-side task processing interface via network protocol. Upon receiving the request, the server-side task processing engine parses the target task's identifier and formally initiates the core data processing logic related to that task. Data processing operations specifically include modifying or deleting data in core business tables, cleaning rules, or archiving status. This formal request mechanism, triggered by secondary confirmation, ensures that every high-risk data change is executed only after the personnel involved have fully understood the risk warnings and received explicit authorization.

[0098] In an optional implementation, the method further includes: When a cancellation command is received from the user on the secondary confirmation screen, the secondary confirmation screen is closed, and the current state of the target task remains unchanged.

[0099] Here, if, after reviewing the visual risk warnings on the secondary confirmation interface, the operator finds that the data involved in the operation is of excessively high criticality or that the estimated impact exceeds expectations, the operator can click the cancel button on the secondary confirmation interface to issue a cancellation command. Upon receiving the cancellation command, the front-end application will immediately execute the interface cleanup logic.

[0100] Specifically, the front-end application will directly destroy or close the DOM elements of the secondary confirmation interface, returning the interactive interface to the initial task list state. During this process, the front-end application will not send any execution requests to the server's task processing interface, thereby ensuring that the current state of the target task remains unchanged and the associated underlying data assets are not affected in any way.

[0101] This application provides a data self-audit task processing method. By introducing operation interception and an asynchronous pre-inspection mechanism based on a backend rule base into the data self-audit task execution process, it achieves real-time interruption of high-risk operations and dynamic quantification of task impact dimensions. This eliminates the risk of misoperation caused by click behavior directly triggering core data changes in the prior art. Combined with role permission verification and multi-dimensional risk parameter display, it improves the security of core data assets and the standardization of operations in the data governance platform while ensuring interactive flexibility and system integration convenience.

[0102] Based on the above embodiments, this application provides a data self-examination task processing system reference. Figure 6 The data self-examination task processing system provided in this application embodiment includes: Operation interception module 1 is used to intercept user-triggered operations on target tasks in response to user-triggered operations, so as to prevent the data processing operations corresponding to the target tasks from being executed.

[0103] Here, the operation interception module 1 listens for triggering operations of processing controls in the task list interface via a front-end script. When a user triggers a processing button, the operation interception module 1 immediately calls the function to prevent the default behavior, thereby interrupting the form submission action that the browser originally planned to send to the backend. Through this front-end interception mechanism, the operation interception module 1 provides an operation buffer period for the system, eliminating direct data changes caused by manual errors or fatigue at the interaction logic level, and greatly reducing the risk of data misoperation.

[0104] The pre-inspection query module 2 is used to send a pre-inspection query request for the target task to the server in order to obtain the predefined rule information associated with the target task returned by the server.

[0105] Here, after the interception action is completed, the pre-inspection query module 2 sends a pre-inspection request to the backend server via an asynchronous query interface. The pre-inspection request carries the task identifier of the target task. The pre-inspection query module 2 receives structured predefined rule information returned by the server. This information is obtained by the server from a preset rule information database. The predefined rule information specifically includes the number of associated data tables, the data criticality level, and the estimated impact range. In addition, the predefined rule information can be expanded to include decision reference dimensions such as the estimated processing time of the task or the historical operation rollback rate.

[0106] Interface generation module 3 is used to generate a secondary confirmation interface based on predefined rule information; wherein, the secondary confirmation interface includes risk warning content generated based on predefined rule information.

[0107] Here, the interface generation module 3 parses the technical parameters obtained from the pre-inspection query module 2, transforming the underlying rule data into easily understandable visual risk warnings. The interface generation module 3 dynamically populates the preset confirmation interface template with the target task's task identifier, core business table relationships, P0-level extremely high risk warning, and affected downstream business systems. The secondary confirmation interface rendered by the interface generation module 3 is displayed as a modal pop-up on the user interface front end, forcing personnel to review the contextual risk information before performing core operations. In this way, the interface generation module 3 transforms blind confirmation into information-driven decision-making, improving the standardization and prudence of operations.

[0108] Task execution module 4 is used to send a task processing request to the server when it receives a confirmation instruction triggered by the user on the secondary confirmation interface, so that the server can perform the data processing operation corresponding to the target task.

[0109] Here, if the user selects the cancel command on the secondary confirmation interface, task execution module 4 will destroy the interface DOM elements, the process will terminate, and the data state will remain unchanged; if the user clicks the confirm processing button, task execution module 4 will then formally send the final execution request carrying the task identifier to the server's task processing interface. Only after the server's task execution engine receives this formal request will it initiate the review, modification, or cleanup logic for the core data.

[0110] In an optional implementation, the interception module 1 is further configured to: Listen for trigger events of the processing controls for the target task.

[0111] When an event is triggered, prevent the preset execution behavior corresponding to the triggering operation from being executed.

[0112] In an optional implementation, the triggering operation includes a click operation and / or an operation triggered based on preset interaction conditions.

[0113] In an optional implementation, the pre-detection query module 2 is further configured to: Obtain the identification information of the target task.

[0114] A pre-inspection query request is generated based on the identification information and sent to the server through an asynchronous communication interface.

[0115] Receive predefined rule information returned by the server; wherein, the predefined rule information is obtained by the server from the preset rule information database based on the identification information.

[0116] In an optional implementation, the predefined rule information includes at least one of the attribute information of the data object associated with the target task and the operation impact information.

[0117] In an optional implementation, the interface generation module 3 is further configured to: Extract risk warning fields from predefined rule information and generate risk warning content based on these fields.

[0118] The risk warning content is dynamically populated into the preset confirmation interface template to generate a visual risk warning message.

[0119] The front-end interface uses visual risk warnings and interactive controls to render and display a secondary confirmation interface.

[0120] In an optional implementation, the interface generation module 3 is further configured to: Obtain the role and permission verification results returned by the server based on the user's identity identifier.

[0121] When the role permission verification result indicates insufficient permissions, the interactive control corresponding to the confirmation command is disabled in the secondary confirmation interface.

[0122] In an optional implementation, task execution module 4 is further configured to: Upon receiving the confirmation instruction, a task processing request is constructed based on the identification information of the target task.

[0123] Send a task processing request to the server to trigger the server to perform data processing operations.

[0124] In an optional implementation, task execution module 4 is further configured to: When a cancellation command is received from the user on the secondary confirmation screen, the secondary confirmation screen is closed, and the current state of the target task remains unchanged.

[0125] The data self-audit task processing system provided in this application, through the coordinated operation of the operation interception module, pre-inspection query module, interface generation module, and task execution module, achieves real-time blocking and dynamic risk perception of high-risk operations using a lightweight security gateway without reconstructing the underlying data governance logic. The system feeds back key parameters such as associated data tables, risk levels, and impact scope from the backend rule base to the secondary confirmation interface in real time, thereby eliminating the risk of direct data alteration due to manual errors or fatigue, while improving the security of core data assets in the data governance platform and the intelligence level of system interaction.

[0126] The computer program product provided in this application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0127] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0128] Furthermore, in the description of the embodiments of this application, unless otherwise expressly specified and limited, the terms "installation," "connection," and "linking" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this application based on the specific circumstances.

[0129] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0130] In the description of this application, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are used only for the convenience of describing this application and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this application. Furthermore, the terms "first," "second," and "third" are used for descriptive purposes only and should not be construed as indicating or implying relative importance.

[0131] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments within the scope of the technology disclosed in this application, or make equivalent substitutions for some of the technical features. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the protection scope of this application.

Claims

1. A method for processing a data self-audit task, characterized in that, include: In response to a user's triggering operation for a target task, the triggering operation is intercepted to prevent the data processing operation corresponding to the target task from being executed; Send a pre-detection query request for the target task to the server to obtain predefined rule information associated with the target task returned by the server; A secondary confirmation interface is generated based on the predefined rule information; wherein, the secondary confirmation interface includes risk warning content generated based on the predefined rule information; When a confirmation instruction triggered by the user on the secondary confirmation interface is received, a task processing request is sent to the server so that the server can perform the data processing operation corresponding to the target task.

2. The method according to claim 1, characterized in that, The step of intercepting the triggering operation in response to a user's triggering operation for a target task includes: Listen for trigger events of the processing controls for the target task; When the triggering event is triggered, the preset execution behavior corresponding to the triggering operation is prevented.

3. The method according to claim 2, characterized in that, The triggering operations include click operations and / or operations triggered based on preset interaction conditions.

4. The method according to claim 1, characterized in that, The step of sending a pre-detection query request for the target task to the server includes: Obtain the identification information of the target task; The pre-detection query request is generated based on the identification information and sent to the server through an asynchronous communication interface; The server receives predefined rule information returned by the server; wherein the predefined rule information is obtained by the server from a preset rule information database based on the identification information.

5. The method according to claim 4, characterized in that, The predefined rule information includes at least one of the attribute information and operation impact information of the data object associated with the target task.

6. The method according to claim 1, characterized in that, The step of generating a secondary confirmation interface based on the predefined rule information includes: Extract risk warning fields from the predefined rule information, and generate the risk warning content based on the risk warning fields; The risk warning content is dynamically filled into a preset confirmation interface template to generate a visual risk warning content; The secondary confirmation interface is rendered and displayed on the front-end interface based on the visual risk warning content and interactive controls.

7. The method according to claim 6, characterized in that, The step of rendering and displaying the secondary confirmation interface includes: Obtain the role permission verification result returned by the server based on the user's identity identifier; When the role permission verification result indicates insufficient permissions, the interactive control corresponding to the confirmation command is disabled in the secondary confirmation interface.

8. The method according to claim 1, characterized in that, The step of sending a task processing request to the server when receiving a confirmation command triggered by the user on the secondary confirmation interface includes: Upon receiving the confirmation instruction, the task processing request is constructed based on the identification information of the target task; The task processing request is sent to the server to trigger the server to execute the data processing operation.

9. The method according to claim 1, characterized in that, The method further includes: When a cancellation command triggered by the user on the secondary confirmation interface is received, the secondary confirmation interface is closed, and the current state of the target task remains unchanged.

10. A data self-examination task processing system, characterized in that, include: An operation interception module is used to intercept a user's trigger operation for a target task, thereby preventing the data processing operation corresponding to the target task from being executed. The pre-inspection query module is used to send a pre-inspection query request to the server for the target task in order to obtain the predefined rule information associated with the target task returned by the server. An interface generation module is used to generate a secondary confirmation interface based on the predefined rule information; wherein, the secondary confirmation interface includes risk warning content generated based on the predefined rule information; The task execution module is used to send a task processing request to the server when it receives a confirmation instruction triggered by the user on the secondary confirmation interface, so that the server can perform the data processing operation corresponding to the target task.

Images