A multi-tenant compliance automation management system based on a SaaS architecture

Abstract

The application discloses a kind of multi-tenant compliance automation management systems based on SaaS architecture, it is related to electric digital data processing technical field, system is parsed rule dependency by rule topological organ and generates directed acyclic graph, when basic rule changes, along the reverse traversal of dependent edge, locate derivative rule and generate cascading update content;Through transaction binder, compliance inspection is embedded in business operation with atomic sub-transaction, generate global operation fingerprint associated business and inspection result;Through scheduling allocator, according to tenant urgency, resources are reversely deprived, and computing quota is preferentially allocated to high-priority tenants;Through closed-loop checker, rule execution bias, evidence association state and resource fairness data are collected, and after calculating comprehensive health degree, it is back to rule topological organ and scheduling allocator, correct node weight and distribution coefficient, after comparing preset threshold value for several rounds, output system stable operation state.

Description

Technical Field

[0001] This invention relates to the field of electronic digital data processing technology, specifically to a multi-tenant compliance automated management system based on a SaaS architecture. Background Technology

[0002] As enterprises deepen their digital transformation, compliance management has evolved from static policy documents to dynamic, high-frequency runtime requirements. Current mainstream compliance systems often employ single-tenant custom development or centralized platforms based on traditional SOA, exhibiting significant architectural flaws when dealing with multi-tenant SaaS scenarios: compliance rules are inherently heterogeneous among tenants, and the rule engine is strongly coupled with business logic, preventing hot reloading and tenant-level isolation of rule changes; the collection of compliance evidence chains lacks atomic transaction binding with business processes, affecting the judicial non-repudiation of evidence; the lack of dependency graph topology awareness during dynamic rule evolution easily leads to rule conflicts or execution deadlocks; simultaneously, in multi-tenant shared infrastructure, compliance computing resources lack weight-based dynamic scheduling, easily generating noisy neighbor effects, causing high-priority tenants to experience excessive response latency. The root cause of these problems lies in traditional systems treating compliance as an independent, additional inspection layer, rather than a primary constraint natively integrated into the SaaS multi-tenant architecture. Therefore, there is an urgent need for an automated management solution that reconstructs the entire chain from tenant models and rule lifecycles to evidence storage, addressing the issues of dynamic isolation of compliance rules, atomic binding of evidence, cascading rule updates, and elastic resource scheduling in multi-tenant environments. Summary of the Invention

[0003] The purpose of this invention is to provide a multi-tenant compliance automated management system based on a SaaS architecture to solve the problems mentioned in the background art.

[0004] To address the aforementioned technical problems, this invention provides the following technical solution: a multi-tenant compliance automated management system based on a SaaS architecture, comprising a rule base, a business executor, and a computing resource pool, and further comprising a rule topology, a transaction binder, a scheduler, and a closed-loop verifier; The rule topology obtains the compliance rules of each tenant from the rule base, parses the dependency conditions between rules and generates a dependency graph. When external regulations trigger changes to the basic rules, the rule topology traverses backwards according to the dependency graph to determine all derived rules affected by the basic rules and generates corresponding cascading update content. When the business executor starts a business operation, the transaction binder declares the compliance check action as an atomic sub-transaction, executes the atomic sub-transaction before the business operation is submitted, and generates a global operation fingerprint after the sub-transaction is completed. This fingerprint is used to associate the business operation with the compliance check result. The scheduler obtains the currently available computing quota from the computing resource pool, and according to the priority level of each tenant, schedules the compliant tasks of high-priority tenants into the execution queue in a reverse preemption manner, and reduces the resource consumption share of low-priority tenants in the computing resource pool. The closed-loop verifier collects in real time the node execution deviation data in the rule topology, the evidence association status data in the transaction binder, and the resource allocation fairness data in the scheduler and allocator. It calculates the overall health score based on the collected data and inputs the health score back into the rule topology to correct the weight coefficients of each node in the dependency graph. At the same time, it inputs the health score back into the scheduler and allocator to correct the allocation coefficients of resource occupancy shares. The closed-loop verifier also compares the corrected and recalculated health score with a preset threshold.

[0005] Preferably, the dependency graph adopts a directed acyclic graph structure, where each node corresponds to a single compliance rule, and the directed edges between nodes correspond to the triggering conditions between rules.

[0006] Preferably, during reverse traversal, the rule topologist starts from the basic rule node and searches upwards level by level along the opposite direction of the directed edge, including all upstream nodes that can be associated through the path into the scope of the derived rules; The rule topology also sets update priorities for derived rules based on path length, with shorter paths having higher update priorities.

[0007] Preferably, the atomic sub-transaction adopts the TCC protocol, which divides compliance checks into a resource reservation phase, an execution confirmation phase, and a compensation rollback phase. During the resource reservation phase, the transaction binder locks the sensitive data fields to be inspected; During the confirmation and execution phase, the transaction binder performs sensitive field scanning and de-identification verification and generates the global operation fingerprint; During the compensation rollback phase, if the compliance check fails, the transaction binder releases the locked data fields and notifies the business executor to revoke the current business operation.

[0008] Preferably, the scheduler monitors the task queue length of each tenant's compliant tasks in real time and records the execution time consumed by each tenant. The scheduler calculates the remaining response time margin for each tenant based on the task queue length and the execution time already consumed. Tenants with smaller margins have higher priority levels.

[0009] Preferably, the reverse preemption method is as follows: when a new compliance task arrives for a high-priority tenant, the scheduler forcibly reclaims some thread resources from the currently executing low-priority tasks and allocates the reclaimed thread resources to the new compliance task of the high-priority tenant.

[0010] Preferably, the closed-loop verifier obtains a first health score during the first calculation, which corresponds to the basic indicators of rule node deviation rate, evidence chain breakage, and resource preemption conflict. The closed-loop validator sends the first health value back to the rule topologist, and the rule topologist adjusts the execution order weight of each node in the dependency graph according to the health value sent back. The closed-loop verifier also sends the first health value back to the scheduler, and the scheduler adjusts the initial resource reservation share of each tenant based on the health value sent back. After the adjustment is completed, the closed-loop verifier is triggered to perform a second execution to obtain the second health status.

[0011] Preferably, the closed-loop verifier obtains a preset qualified health threshold and compares the second health score with the threshold. If the second health level is greater than or equal to the threshold, the closed-loop verifier outputs the final operating state of the current system. If the second health score is less than the threshold, the closed-loop validator will pass the second health score back to the rule topology and the scheduler, triggering a third execution. It will then continue to compare the health score calculated in the third iteration with the threshold, iterating repeatedly until the health score reaches the acceptable threshold. The system also has a maximum number of iterations. If the health score still does not reach the acceptable threshold after reaching this maximum number of iterations, the closed-loop validator will continue running with the parameters corresponding to the last iteration and output this state as the current available state of the system.

[0012] Preferably, when collecting data, the closed-loop verifier obtains the rule execution deviation rate from the rule topology, which reflects the degree of difference between the actual execution result and the expected update range. The completeness of the chain of evidence is obtained from the transaction binder, which reflects the proportion of compliance checks that have successfully generated operation fingerprints out of all compliance checks. Resource scheduling fairness is obtained from the scheduler, which reflects the degree of deviation between the actual computing resources obtained by each tenant and the resources they should theoretically receive; The closed-loop verifier performs a weighted sum of the above deviation rate, integrity, and fairness according to preset weights to obtain the overall health score.

[0013] Preferably, the transaction binder configures a time window for the atomic sub-transaction. The start time of this time window is the time when the business executor starts the business operation, and the end time is determined by a preset window length. The transaction binder waits for the atomic sub-transaction to return the global operation fingerprint within the time window. If it does not receive the fingerprint within the timeout period, it determines that the compliance check has failed and immediately sends a global rollback instruction to the business executor.

[0014] This invention provides a multi-tenant compliance automated management system based on a SaaS architecture. It has the following beneficial effects: By refactoring compliance management from an additional inspection layer to a primary constraint, native integration of rule topology awareness, atomic transaction binding, and dynamic resource scheduling is achieved. The rule topology generator, based on a reverse traversal mechanism of dependency graphs, enables the system to accurately locate the affected derivative rules and generate cascading updates when basic rules change, avoiding execution conflicts or process interruptions caused by strong rule coupling in traditional methods. The transaction binder embeds compliance checks into the main process of business operations in the form of atomic sub-transactions and uniquely associates the check results with business operations through global operation fingerprints, eliminating the timeline misalignment between evidence collection and business execution, and making the evidence chain traceable and verifiable. The scheduler and allocator implements reverse preemptive resource allocation based on the tenant's urgency, allowing urgent tasks to obtain execution opportunities in a timely manner when resources are scarce, alleviating queuing delays caused by resource contention in a multi-tenant shared environment.

[0015] The closed-loop validator collects real-time operational status data from each module and calculates a comprehensive health score. This health score is then fed back to the rule topology and scheduler / allocator as the basis for parameter adjustments, enabling the system to automatically correct its execution strategy based on changes in its own status during operation. Through round-by-round comparison and iterative adjustment of the health score against preset thresholds, the system can continuously approach a stable operational equilibrium point, preventing prolonged deviations due to single improper parameter settings. Data flows between modules form a mutually verifying and constraining relationship. Execution deviations in the rule topology affect the resource allocation benchmark of the scheduler / allocator, while the resource preemption behavior of the scheduler / allocator affects the execution success rate of the transaction binder. The fingerprint generation status of the transaction binder is simultaneously fed back into the node weight correction logic of the rule topology. This multi-dimensional coupled collaboration allows the system to self-adjust when facing regulatory changes, tenant load fluctuations, or resource shortages. Attached Figure Description

[0016] Figure 1 This is a data flow and feedback structure diagram of the multi-tenant compliance automated management system based on SaaS architecture of this invention; Figure 2 This is a flowchart of the health calculation and threshold iteration process of the present invention. Detailed Implementation

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

[0018] Please see Figure 1 and Figure 2 This invention provides a multi-tenant compliance automated management system based on a SaaS architecture. During deployment, each tenant independently configures its own compliance rule entries, and the system aggregates all rules and stores them in a rule base. The rule topology reads the rule lists of each tenant from the rule base and performs dependency resolution on each rule. The resolution process checks for conditional references or triggering actions pointing to other rules. For any such references, a directed edge is added to the dependency graph, pointing from the dependent to the dependent, ultimately forming a complete directed acyclic graph.

[0019] When external regulations change, the system receives an update instruction and locates the basic rule node. Starting from this node, the rule topologist searches upwards along the opposite direction of each directed edge in the dependency graph, identifying all nodes that can be reached through the reverse path as affected derived rules. The rule topologist groups and arranges the derived rules according to the length of the reverse path, with the group with the shorter path being processed first.

[0020] The transaction binder intervenes when the business executor begins executing a tenant's business operation. It generates a globally unique operation identifier for each operation and, based on the tenant's pre-configured list of compliance checks, generates corresponding sub-tasks for each check. These sub-tasks exist as atomic sub-transactions. The transaction binder manages these sub-transactions using the TCC protocol. During the reservation phase, the transaction binder locks the sensitive data fields to be checked to prevent interference from other operations. During the confirmation phase, the transaction binder performs field scanning and format validation. Once all validations pass, the transaction binder binds the check results to the operation identifier, generating a global operation fingerprint. If any validation fails, the transaction binder enters the compensation phase, releasing all previously locked data fields and informing the business executor to cancel the current business operation.

[0021] The scheduler maintains an internal task management queue, which is divided into different priority bands according to the configuration level of each tenant. The scheduler continuously monitors the arrival status of compliant tasks for each tenant, recording the number of tasks currently queued and the elapsed waiting time for each tenant. Based on this, the scheduler calculates the remaining tolerable waiting time for each tenant; tenants with shorter tolerable waiting times are considered to have higher scheduling urgency. When a new task arrives from a high-urgency tenant, the scheduler proactively checks the currently running low-urgency tasks, selects the task consuming the most thread resources, interrupts it, reclaims the threads it occupies, and immediately allocates them to the newly arrived high-urgency task.

[0022] The closed-loop verifier obtains the deviation generated when the rule node is actually executed from the rule topology, the ratio of the number of failed operation fingerprint generation attempts to the total number of attempts from the transaction binder, and the difference between the actual amount of computing resources obtained by each tenant and the theoretical amount they should have obtained from the scheduler and allocator. The closed-loop verifier integrates the deviation, failure ratio and difference into a comprehensive health value according to the preset contribution ratio of each dimension.

[0023] After obtaining the overall health score, the closed-loop validator sends it back to the rule topology module and the scheduler / allocator. The rule topology module adjusts the execution order weights of each node in the dependency graph based on the received health score, and the scheduler / allocator adjusts the initial resource reservation ratios of each tenant based on the received health score. After the adjustments are complete, the system continues to run and generates a new round of overall health scores. The closed-loop validator compares the new health score with the target value set internally by the system. If the target value is reached, the current parameters are maintained and the system continues to run. If the target value is not reached, the new health score is sent back to the rule topology module and the scheduler / allocator again, triggering a new round of adjustments. This cycle continues until the health score stabilizes within the target range.

[0024] During the dependency graph construction process, the system pre-assigns an independent graph node to each compliant rule in the rule base. The node records the rule's unique ID, rule type, and the names of the data objects involved in the rule. When a rule needs to confirm that another rule has already been executed before execution, or when the output condition of one rule is directly referenced by another rule, the system establishes a directed edge between the nodes corresponding to these two rules. The edge's direction points from the referenced rule to the referencing rule, indicating that the referenced rule is a prerequisite condition of the referencing rule. After establishing all edges, the system uses a depth-first traversal to perform cyclic dependency detection on the entire graph. If a path leads back to the starting point via other paths, the system determines that a circular dependency exists. In this case, the system records the information of each node on the circular path and prompts the administrator for intervention. The system will not include these rules in the automated update process until the circular dependency is manually resolved.

[0025] The system determines the topology hierarchy based on the position of each node in the dependency relationship. Rule nodes that are depended on by the most other nodes are placed at the bottom layer, while leaf nodes with no dependencies are placed at the top layer. When storing this dependency graph, the system simultaneously saves the dependency count and dependency depth value for each node. The dependency count reflects the scope of impact when a rule changes, and the dependency depth value reflects the rule's upstream or downstream position in the execution chain. When rule entries are added or deleted from the rule base, the system only recalculates the associated edges and topology hierarchy for the nodes that have changed, without affecting the storage structure of other existing nodes.

[0026] During runtime, the system determines the propagation direction of rule change notifications based on the dependency graph. When a basic rule is updated, the system searches upwards level by level along the opposite direction of each directed edge to find all upper-level rules that directly or indirectly reference the underlying rule, and then passes the updated content to these upper-level rules in reverse order of the topology hierarchy.

[0027] During the reverse traversal, the rule topologist first obtains the unique identifier of the base rule node based on the received update instruction. Then, using this node as the starting point, it visits all directed edges in the dependency graph that reference this node. For each such edge, the rule topologist extracts the starting node of the edge, which is the upper-level rule that directly depends on the base rule. The rule topologist marks these directly dependent nodes as first-level derived rules and adds them to the pending list.

[0028] Next, the rule topologist retrieves the first-level derived rule nodes from the list of pending rules. It then searches for all directed edges with these nodes as references in the same way, extracts the corresponding starting nodes as second-level derived rules, and adds them to the list of pending rules. The rule topologist expands upwards layer by layer until it reaches a leaf node that is not referenced by any other node. All the nodes traversed along the way together constitute the complete set of derived rules affected by the basic rule.

[0029] During the expansion process, the rule topologist records the reverse traversal level value for each derived rule node. Nodes directly dependent on the base rule have a level value of one, nodes indirectly dependent on it through an intermediate node have a level value of two, and so on. After completing all traversals, the rule topologist sorts the derived rules in ascending order of level value, placing nodes with smaller level values ​​at the front of the update queue for priority update. For multiple derived rule nodes at the same level, the rule topologist further compares the dependency counts of each node, prioritizing nodes with larger dependency counts within that level to avoid temporary rule inconsistencies due to improper processing order within the same level. The rule topologist then passes this sorted queue to the update execution module, which generates and applies the corresponding cascading update content one by one according to the queue order.

[0030] When the transaction binder atomically processes compliance check actions, it internally uses the TCC protocol to manage the lifecycle of each check subtask; the TCC protocol divides the subtask into three consecutive operation phases: reserving resources, confirming execution, and compensating rollback.

[0031] During the resource reservation phase, the transaction binder first receives a list of data object names to be checked from the business executor, and then analyzes the storage location corresponding to each data object in the list. For data fields marked as sensitive types, the transaction binder sends a lock request to the data storage layer. The lock request includes the storage path of the field and a unique identifier for this operation. After receiving the lock request, the data storage layer checks whether the field is currently occupied by another transaction. If it is not occupied, it marks the field as locked and returns a lock success response. If it is occupied, it waits for a certain period of time and then retryes. If the retry still fails, it returns a reservation failure signal to the transaction binder.

[0032] During the confirmation and execution phase, after confirming that all sensitive fields have been successfully locked during the resource reservation phase, the transaction binder begins to execute various compliance checks. These checks include format validation of sensitive field content to ensure it conforms to the tenant's configured data format specifications, and verification of the anonymization status of sensitive field content to check for any unanonymized personal identification or financial information. The transaction binder executes each check sequentially and records the pass / fail result for each check. Once all checks have passed, the transaction binder merges the operation identifier of this business operation, the timestamp of the check execution, and the pass / fail results of each check into a single data packet, and performs a hash calculation on this data packet to obtain the global operation fingerprint.

[0033] During the compensation rollback phase, if any sensitive field fails to lock during the resource reservation phase, the transaction binder sends a release command to all successfully locked fields. This release command includes the field's storage path and operation identifier. The data storage layer verifies the legality of the release request based on the operation identifier and restores the field to an unlocked state. If any compliance check fails during the confirmation execution phase, the transaction binder also triggers a compensation rollback operation after generating a failure record, releasing all locked sensitive fields and sending a global rollback signal for this business operation to the business executor. This signal includes the operation identifier and a list of failed check names. The business executor then uses this signal to revert all data changes made during this business operation.

[0034] During system operation, the scheduler maintains a tenant status record table, with a separate record for each registered tenant. Each record contains the tenant's task queue pointer, the number of compliant tasks currently waiting to be executed in the queue, the timestamp of the tenant's most recent task entering the queue, and the total waiting time accumulated from the first task enqueuing to the current moment. The scheduler polls this status record table at fixed intervals, updating the task queue length and accumulated waiting time for each tenant with each poll.

[0035] When calculating the remaining response time margin for each tenant, the scheduler determines it based on the promised completion time stipulated in the tenant's service level agreement (SLA) and the total amount of waiting time already consumed. Each tenant's SLA pre-defines the maximum allowed time for a compliant task to be queued and completed. The scheduler reads this maximum time value, subtracts the total amount of waiting time already consumed, and obtains the remaining available waiting time value, which is the remaining response time margin. A smaller margin indicates a smaller tolerable further waiting space for the tenant. The scheduler uses this margin value as the sorting criterion, arranging tenants in ascending order.

[0036] After the sorting is complete, the scheduler marks the tenant with the smallest margin as the highest priority tenant in the current period, and the tenant with the largest margin as the lowest priority tenant. The scheduler then appends this priority label to the header of each tenant's compliant task for use in subsequent queue scheduling. Whenever a new task arrives, the scheduler triggers an immediate margin recalculation and sorting update to ensure that newly arrived tenants can participate in the current period's priority sorting in a timely manner, preventing urgent tasks from being unrecognized due to a fixed sorting cycle.

[0037] When the scheduler receives a new compliant task from a high-priority tenant, it first checks the number of idle threads in the current compute resource pool. If the number of idle threads is sufficient to meet the needs of the new task, the scheduler directly allocates an idle thread to the new task without triggering a reverse preemption operation. If the number of idle threads is insufficient to meet the needs of the new task, the scheduler initiates the reverse preemption process.

[0038] In the reverse preemption process, the scheduler first iterates through all currently executing compliant tasks and obtains the tenant priority label corresponding to each running task. The scheduler then filters out tasks from these running tasks that belong to tenants with lower priorities than the new task. Among the filtered low-priority tasks, the scheduler further checks the execution duration of each task, prioritizing tasks with shorter execution durations as preemption targets to reduce redundant work caused by task interruptions.

[0039] After determining the preemption target, the scheduler sends an interrupt signal to the thread executing that task. Upon receiving the interrupt signal, the thread saves its current task state information and completed intermediate results while ensuring data consistency. It then releases all computing resources occupied by the thread, including CPU time slices and memory cache. After the thread has been released, the scheduler marks the thread as reclaimable and adds it to the resource allocation set for new tasks. Subsequently, the scheduler allocates the thread to the new task, along with other threads added from the idle resource pool as needed.

[0040] After the scheduler completes thread allocation, it sends the new task to the head of the execution queue, ensuring it can be executed immediately at the start of the next scheduling cycle. For low-priority tasks of preempted threads, the scheduler marks a recovery point in the corresponding tenant state record table. When system resources become available later, the scheduler restarts the remaining part of the task based on this recovery point information, ensuring that low-priority tasks do not completely lose execution progress due to preemption.

[0041] When the closed-loop validator performs its first calculation, the system collects status data generated during the operation of each module. After each rule update, the rule topology records the actual number of updated rule nodes and the number of nodes that match the expected update range. The closed-loop validator obtains these two values ​​from the rule topology and calculates the rule node execution deviation by comparing the difference between them. During compliance checks, the transaction binder records whether the global operation fingerprint corresponding to each check was successfully generated, and also counts the number of failed global operation fingerprint generation attempts and the total number of compliance check attempts. The closed-loop validator obtains the number of failures and the total number of attempts from the transaction binder. When allocating computing resources, the scheduler records the actual execution time slice length obtained by each tenant and calculates the theoretical execution time slice length that each tenant should receive based on the service level agreement of each tenant. The closed-loop validator obtains the actual and theoretical time slice lengths of each tenant from the scheduler.

[0042] After obtaining the above data, the closed-loop validator converts the execution deviation of the rule nodes into a basic deviation rate metric. This metric reflects the accuracy of the updated content when the rule topology performs cascading updates. The closed-loop validator uses the ratio of the number of failures to the total number of failures as a basic metric for the number of broken evidence chains. This metric reflects the reliability of the transaction binder's check results when binding compliance checks to business operations. The closed-loop validator sums the absolute values ​​of the differences between the actual time slice length and the theoretical time slice length for each tenant, and uses the sum as a basic metric for the number of resource preemption conflicts. This metric reflects the fairness of resource allocation when the scheduler implements reverse preemption.

[0043] When the closed-loop validator substitutes the first health score back to the rule topologist, the rule topologist adjusts the execution order weights of each node in the dependency graph based on the received health score values. Previously, the rule topologist determined the node execution order solely based on the reverse traversal level values. After receiving the health score values, the rule topologist generates an adjustment factor for each node individually. This adjustment factor is positively correlated with the health score value; the lower the health score, the larger the adjustment factor. The rule topologist multiplies each node's original level value by its corresponding adjustment factor to obtain a new execution order value and rearranges the node execution order according to the new values.

[0044] When the closed-loop checker sends the first health score back to the scheduler, the scheduler adjusts the initial resource reservation share of each tenant based on the received health score value. The resource reservation share originally allocated to each tenant by the scheduler was determined based on the tenant's service level agreement (SLA). After receiving the health score value, the scheduler uses this value as a global correction factor to adjust the resource reservation share of all tenants proportionally. The adjusted share is linked to the original share through this global correction factor. In subsequent resource allocation processes, the scheduler uses the adjusted share as the starting base value for dynamic preemption operations.

[0045] After the adjustment is completed, the closed-loop verifier waits for each module of the system to run a complete task scheduling cycle according to the new parameters. The length of this scheduling cycle is determined by the system's preset polling interval. After the cycle ends, the same data acquisition and calculation process is executed again to obtain the second health score. The closed-loop verifier saves the second health score as a quantitative representation of the current system state for subsequent comparison with preset thresholds.

[0046] After the closed-loop validator completes the calculation of the second health level, the system pre-stores a qualified health level threshold. This threshold is set uniformly by the system administrator during deployment according to the compliance requirements of each tenant, or a default value can be automatically generated by the system based on historical operating data. The closed-loop validator obtains this preset threshold and then compares the value of the second health level with this threshold.

[0047] If the second health level reaches or exceeds the preset threshold, the closed-loop verifier considers the current system's operating state to be within an acceptable range. At this point, the closed-loop verifier stops its iterative loop, solidifies the various operating parameters of the current system, and marks the final operating state of the system as a stable state before outputting it to the system management module. The management module continues to maintain the system's operation according to this state.

[0048] If the second health score does not reach the preset threshold, the closed-loop validator determines that the current system still needs further optimization and adjustment. At this point, the closed-loop validator uses the second health score as a new input parameter and substitutes it back to the rule topology and scheduler. The rule topology adjusts the execution order weights of each node in the dependency graph based on the second health score, and the scheduler adjusts the resource reservation share of each tenant based on the second health score. After the adjustments are complete, the closed-loop validator waits for the system to run stably according to the new parameters, then re-collects the operating status data of each module and calculates the third health score using the same calculation method as the first and second health scores.

[0049] The closed-loop checker continues to compare the third health score with the preset threshold. If the threshold is still not met, the third health score is substituted back, triggering the fourth round of execution, and so on. In each iteration, the closed-loop checker limits the difference between the current health score and the previous health score to a preset upper limit. If the deviation between the adjusted calculated health score and the previous health score exceeds this upper limit, the closed-loop checker truncates the value to avoid system oscillations caused by excessively large single adjustment steps. The system continues to run and cycle through the above process until the calculated health score after a certain iteration reaches or exceeds the preset threshold. Once the health score is reached, the closed-loop checker terminates the loop and outputs the current stable operating status of the system.

[0050] When calculating the overall health score in each iteration, the closed-loop validator obtains raw running data from three different modules.

[0051] On the rule topology side, the closed-loop validator reads the execution log recorded by this module in the most recent statistical period. The execution log records the identifiers of the base rule nodes and derived rule nodes involved in each cascading update operation, as well as the identifiers of the nodes that were actually updated. The closed-loop validator compares the expected set of updated nodes recorded in the execution log with the actual set of updated nodes, and counts the number of nodes that differ from the expected set. The ratio of this number to the total number of expected updated nodes is taken as the rule execution deviation rate. The smaller the deviation rate, the more accurately the rule topology locates the derived rules when performing cascading updates.

[0052] On the transaction binder side, the closed-loop validator reads the fingerprint generation log recorded by this module in the most recent statistical period. The fingerprint generation log records the total number of compliance checks corresponding to each business operation, as well as the number of checks that successfully generated a global operation fingerprint. The closed-loop validator divides the number of checks that successfully generated fingerprints by the total number of compliance checks, and the resulting ratio is used as the evidence chain completeness. The closer the completeness value is to full coverage, the higher the success rate of compliance checks executed by the transaction binder during atomic binding.

[0053] On the scheduling and allocation side, the closed-loop verifier reads the resource allocation logs recorded by this module in the most recent statistical period. The resource allocation logs record the actual computing resource usage of each tenant, as well as the theoretical resource requirements calculated based on each tenant's service level agreement (SLA). The closed-loop verifier calculates the absolute value of the difference between the actual usage and the theoretical requirement for each tenant, then sums the absolute values ​​of the differences for all tenants. The summation is divided by the total number of tenants, and the resulting value is used as the resource scheduling fairness index. The smaller the fairness index value, the smaller the deviation between the resources actually obtained by each tenant and the resources they should theoretically receive.

[0054] After obtaining the basic values ​​for the three dimensions mentioned above, the closed-loop validator reads the preset weight coefficients corresponding to each dimension from the system configuration. The weight coefficients for rule execution deviation rate, evidence chain integrity, and resource scheduling fairness are preset by the system administrator according to the actual focus of the current business scenario. The closed-loop validator multiplies the rule execution deviation rate value with its weight coefficient to obtain the first product, multiplies the evidence chain integrity value with its weight coefficient to obtain the second product, and multiplies the resource scheduling fairness value with its weight coefficient to obtain the third product. The three products are then added together to obtain the overall health score.

[0055] When processing atomic sub-transactions for compliance checks, the transaction binder allocates a separate time window for each sub-transaction. The length of this time window is pre-configured by the system administrator based on the business characteristics of each tenant. Different tenants can configure different window length values, and the system stores the window length value in association with the tenant identifier.

[0056] The start time of the time window is set to the moment when the business executor initiates the current business operation. The transaction binder starts timing immediately upon receiving the business start signal. The transaction binder calculates the end time of the time window by adding a preset window length value to the start time as a reference point. During the time period between the start and end times, the transaction binder is in a waiting state, waiting for the atomic sub-transactions to complete and return the global operation fingerprint.

[0057] While waiting, the transaction binder continuously checks whether the current system time has exceeded the termination time. If the current time has not yet reached the termination time and the atomic sub-transaction has returned the global operation fingerprint, the transaction binder determines that the compliance check has been completed within the allowed time frame, and the system continues to execute the subsequent processes of the business operation. If the current time has reached or exceeded the termination time, and the transaction binder has not yet received the global operation fingerprint returned by the atomic sub-transaction, the transaction binder determines that the compliance check has timed out.

[0058] Upon determining a timeout, the transaction binder immediately stops waiting for the execution result of the atomic sub-transaction and ceases waiting for any further information from that sub-transaction. The transaction binder then sends a global rollback command to the business executor, carrying the operation identifier of this business operation. Upon receiving the global rollback command, the business executor locates all data change records involved in this business operation based on the operation identifier and reverts these changes one by one, restoring the business data to its state before the operation began. The transaction binder also logs the timeout event, including the time of the timeout, the corresponding tenant identifier, and the type of the timed-out sub-transaction, for subsequent troubleshooting and analysis by the system administrator.

[0059] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0060] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A multi-tenant compliance automated management system based on a SaaS architecture, comprising a rule base, a business executor, and a computing resource pool, characterized in that, It also includes a rule topology generator, a transaction binder, a scheduler / allocator, and a closed-loop checker; The rule topology obtains the compliance rules of each tenant from the rule base, parses the dependency conditions between rules and generates a dependency graph. When external regulations trigger changes to the basic rules, the rule topology traverses backwards according to the dependency graph to determine all derived rules affected by the basic rules and generates corresponding cascading update content. When the business executor starts a business operation, the transaction binder declares the compliance check action as an atomic sub-transaction, executes the atomic sub-transaction before the business operation is submitted, and generates a global operation fingerprint after the sub-transaction is completed. This fingerprint is used to associate the business operation with the compliance check result. The scheduler obtains the currently available computing quota from the computing resource pool, and according to the priority level of each tenant, schedules the compliant tasks of high-priority tenants into the execution queue in a reverse preemption manner, and reduces the resource consumption share of low-priority tenants in the computing resource pool. The closed-loop verifier collects in real time the node execution deviation data in the rule topology, the evidence association status data in the transaction binder, and the resource allocation fairness data in the scheduler and allocator. It calculates the overall health score based on the collected data and inputs the health score back into the rule topology to correct the weight coefficients of each node in the dependency graph. At the same time, it inputs the health score back into the scheduler and allocator to correct the allocation coefficients of resource occupancy shares. The closed-loop verifier also compares the corrected and recalculated health score with a preset threshold.

2. The multi-tenant compliance automated management system based on SaaS architecture according to claim 1, characterized in that: The dependency graph adopts a directed acyclic graph structure, where each node corresponds to a single compliance rule, and the directed edges between nodes correspond to the triggering conditions between rules.

3. The multi-tenant compliance automated management system based on SaaS architecture according to claim 2, characterized in that: During reverse traversal, the rule topologist starts from the basic rule node and searches upwards level by level along the opposite direction of the directed edges, including all upstream nodes that can be associated through the path into the scope of the derived rules. The rule topology also sets update priorities for derived rules based on path length, with shorter paths having higher update priorities.

4. The multi-tenant compliance automated management system based on SaaS architecture according to claim 3, characterized in that: The atomic sub-transaction adopts the TCC protocol, which divides compliance checks into a resource reservation phase, an execution confirmation phase, and a compensation rollback phase. During the resource reservation phase, the transaction binder locks the sensitive data fields to be inspected; During the confirmation and execution phase, the transaction binder performs sensitive field scanning and de-identification verification and generates the global operation fingerprint; During the compensation rollback phase, if the compliance check fails, the transaction binder releases the locked data fields and notifies the business executor to revoke the current business operation.

5. The multi-tenant compliance automated management system based on SaaS architecture according to claim 4, characterized in that: The scheduler monitors the task queue length of each tenant's compliant tasks in real time and records the execution time consumed by each tenant. The scheduler calculates the remaining response time margin for each tenant based on the task queue length and the execution time already consumed. Tenants with smaller margins have higher priority levels.

6. The multi-tenant compliance automated management system based on SaaS architecture according to claim 5, characterized in that: The reverse preemption method is as follows: when a new compliance task arrives for a high-priority tenant, the scheduler forcibly reclaims some thread resources from the currently executing low-priority tasks and allocates the reclaimed thread resources to the new compliance task of the high-priority tenant.

7. The multi-tenant compliance automated management system based on SaaS architecture according to claim 6, characterized in that: The closed-loop verifier obtains a first health score during the first calculation. This first health score corresponds to the basic indicators of rule node deviation rate, evidence chain breakage, and resource preemption conflict. The closed-loop validator sends the first health value back to the rule topologist, and the rule topologist adjusts the execution order weight of each node in the dependency graph according to the health value sent back. The closed-loop verifier also sends the first health value back to the scheduler, and the scheduler adjusts the initial resource reservation share of each tenant based on the health value sent back. After the adjustment is completed, the closed-loop verifier is triggered to perform a second execution to obtain the second health status.

8. The multi-tenant compliance automated management system based on SaaS architecture according to claim 7, characterized in that: The closed-loop verifier obtains a preset qualified health threshold and compares the second health score with the threshold. If the second health level is greater than or equal to the threshold, the closed-loop verifier outputs the final operating state of the current system. If the second health score is less than the threshold, the closed-loop verifier will pass the second health score back to the rule topologist and the scheduler, triggering a third execution, and continue to compare the health score calculated in the third calculation with the threshold. This process is repeated until the health score reaches the qualified threshold.

9. The multi-tenant compliance automated management system based on SaaS architecture according to claim 8, characterized in that: When collecting data, the closed-loop verifier obtains the rule execution deviation rate from the rule topology, which reflects the degree of difference between the actual execution result and the expected update range. The completeness of the chain of evidence is obtained from the transaction binder, which reflects the proportion of compliance checks that have successfully generated operation fingerprints out of all compliance checks. Resource scheduling fairness is obtained from the scheduler, which reflects the degree of deviation between the actual computing resources obtained by each tenant and the resources they should theoretically receive; The closed-loop verifier performs a weighted sum of the above deviation rate, integrity, and fairness according to preset weights to obtain the overall health score.

10. A multi-tenant compliance automated management system based on a SaaS architecture as described in claim 9, characterized in that: The transaction binder configures a time window for the atomic sub-transaction. The start time of this time window is the time when the business executor starts the business operation, and the end time is determined by the preset window length. The transaction binder waits for the atomic sub-transaction to return the global operation fingerprint within the time window. If it does not receive the fingerprint within the timeout period, it determines that the compliance check has failed and immediately sends a global rollback instruction to the business executor.

Images