An integrated administrative law enforcement management service system

Abstract

The application discloses a kind of comprehensive administrative law enforcement management service systems, it is related to comprehensive administrative law enforcement management technical field, data acquisition module is used to obtain the case processing result data of each law enforcement department;Transaction risk assessment module is used to calculate transaction failure risk index;Transaction processing module adopts asynchronous message in low-risk condition to combine compensation transaction mode, adopts synchronous two-phase commit mode in high-risk condition to carry out data distribution;Intermediate state storage module is used to write cross-department case processing result data into the intermediate state storage area with version control and tamper-proof ability, and after each relevant law enforcement department confirms consistency, it is submitted to formal storage area;Result submission module submits data to each law enforcement department business system when consistency verification passes;The application can improve transaction processing efficiency while ensuring the consistency of cross-department case data, reduce data conflict and law enforcement dispute, improve the security and reliability of comprehensive administrative law enforcement management.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of comprehensive administrative law enforcement management, and particularly relates to a comprehensive administrative law enforcement management service system. BACKGROUND

[0002] Comprehensive administrative law enforcement management service refers to the unified organization, coordination and implementation of administrative law enforcement work involving multiple fields (such as city management, market supervision, environmental protection, public safety, etc.) by the government or authorized agencies, and the provision of comprehensive management and services such as case acceptance, information management, supervision and examination, data analysis, etc., aiming to improve law enforcement efficiency, reduce repeated law enforcement, standardize law enforcement behavior, and protect public interests and social order.

[0003] In the existing comprehensive administrative law enforcement scene of multi-system integration, the case results often need to be pushed to multiple departments with law enforcement authority at the same time, and the data content needs to be kept completely consistent. The common implementation way is to reduce system coupling by combining asynchronous messages with compensation transactions (Saga mode), but when a department system refuses to store due to permission changes or business rule adjustments, while other departments have successfully completed persistence, the compensation mechanism may fail to execute due to cross-department interface restrictions, network interruptions or insufficient permissions, resulting in data rollback failure and ultimately forming conflicting versions of the same case in different departments. SUMMARY

[0004] The purpose of the present application is to provide a comprehensive administrative law enforcement management service system to solve the problems in the background art.

[0005] To achieve the above purpose, the present application provides the following technical solution: a comprehensive administrative law enforcement management service system, comprising:

[0006] A data collection module is used to acquire case processing result data of each law enforcement department in the scene of comprehensive administrative law enforcement multi-system integration.

[0007] A transaction risk assessment module is used to calculate the risk index of transaction failure based on the cross-department interface dependency coefficient and transaction rollback reachability probability involved in case processing results.

[0008] A transaction processing module is used to execute data distribution by combining asynchronous messages with compensation transactions when the risk index is below a preset threshold, and to execute data distribution by adopting a synchronous two-phase commit transaction mode when the risk index is above or equal to the preset threshold.

[0009] An intermediate state storage module is used to write cross-department case processing result data into an intermediate state storage area based on the transaction processing module, and to submit it to the formal storage area after the consistency of each related law enforcement department is confirmed.

[0010] A consistency verification module is configured to perform hash check or multi-party signature verification on the data of each department through the intermediate state storage area;

[0011] A result submission module is configured to submit the case processing result data to the business systems of the relevant law enforcement departments after the consistency verification passes, and prevent submission and trigger a risk handling strategy when the consistency verification fails.

[0012] Preferably, the method for obtaining the cross-department interface dependency coefficient comprises the following steps:

[0013] All target law enforcement department identifiers involved in the current case processing result are obtained, and interface call link information related to case data submission of each target department is extracted;

[0014] A cross-department interface dependency relationship graph is constructed based on the interface call link information, and the in-degree, out-degree and path length of each target department in the dependency relationship graph are calculated;

[0015] The path length, in-degree and out-degree are weighted and calculated according to a preset weight to obtain the cross-department interface dependency coefficient.

[0016] Preferably, the method for obtaining the transaction rollback reachability probability comprises the following steps:

[0017] Before the transaction is submitted, test packages are sent to the rollback interfaces of the target law enforcement departments in sequence by simulating rollback requests, and the response status and response time are recorded;

[0018] The single-node rollback reachability probability of each target department is calculated in combination with the response status of the test packages, the historical rollback transaction success rate and the current network link quality index;

[0019] The single-node rollback reachability probabilities of the target departments are combined and calculated according to the parallel and serial relationship of the cross-department rollback links to obtain the transaction rollback reachability probability of the current transaction as a whole.

[0020] Preferably, the cross-department interface dependency coefficient and the transaction rollback reachability probability are normalized and given a confidence weight;

[0021] The weighted cross-department interface dependency coefficient and the transaction rollback reachability probability are calculated using a nonlinear fusion function to obtain a transaction failure risk index, wherein the nonlinear fusion function dynamically switches between a logistic regression function and a Sigmoid function according to the system running state.

[0022] Preferably, when the risk index is lower than a preset threshold value;

[0023] A case processing result data generation and distribution message is generated, the message is encapsulated as a structured data packet, and the message is published to a message middleware queue;

[0024] The data packet is distributed to all target department systems in parallel by using the topic subscription mechanism of the message middleware;

[0025] When the target department processing fails or is not responded in timeout, the corresponding rollback interface is called according to the pre-stored compensation instruction information.

[0026] Preferably, when the risk index is higher than or equal to a preset threshold;

[0027] A transaction pre-commit request is sent to all target department systems, and the case processing result data to be distributed is attached;

[0028] The preparation state responses of all target departments are collected, and only when all responses are ready, the transaction commit phase is entered; if any target department returns a failure state or is not responded in timeout, the transaction rollback instruction is sent to all departments that are ready;

[0029] After the global preparation confirmation is passed, the final commit instruction is sent to all target departments, and each department commits the pre-written data as the formal record according to the instruction.

[0030] Preferably, in the intermediate state storage module, the cross-department case processing result data transmitted by the transaction processing module is written into the intermediate state storage area, and the corresponding version number and full data hash value are generated;

[0031] A consistency confirmation request is sent to all related law enforcement departments, and the request content includes the intermediate state version number, the data hash value and the multi-party signature verification information, and each department is required to compare the local pre-processing data and return a consistency confirmation response;

[0032] The confirmation responses returned by all law enforcement departments are collected, and the version number, data hash value and signature verification result are comprehensively compared, and only when all responses are verified, it is determined that the consistency confirmation is successful.

[0033] Preferably, in the consistency verification module;

[0034] The case processing result data corresponding to the target version number, the full data hash value and the multi-party signature set are extracted, and the verification task list is generated according to the department dimension;

[0035] For the data returned by each department, the full data hash value is first calculated and compared with the hash value recorded in the intermediate state storage area; then the signature in the multi-party signature set is verified using the public key of the department;

[0036] According to the success rate of the department hash check and signature verification, the consistency threshold is compared, and when the success rate reaches or exceeds the threshold, the consistency verification is determined to pass; if the threshold is not reached, an abnormal processing procedure is triggered, including resending a consistency confirmation request to the failed department or directly preventing the final submission.

[0037] In the above technical solution, the technical effects and advantages provided by the present application are as follows:

[0038] 1. By introducing the intermediate state storage, consistency verification and transaction mode switching mechanism based on the risk index in the comprehensive administrative law enforcement multi-system integration scene, the present application realizes the full-link controllability of the cross-department case processing result data from generation to final submission. The technical solution can perform risk assessment, tamper-proof storage and consistency verification in the pre-execution, execution and post-execution stages respectively, ensure that only when the preset consistency threshold is met, the formal submission is performed, and in the abnormal case, the rollback or manual review is automatically triggered, thereby reducing the data conflict, repeated law enforcement and legal risk from the source.

[0039] 2. By the double verification mechanism combining hash check and multi-party signature verification, the back-reading comparison mechanism and the dynamic risk processing strategy, the present application realizes the comprehensive guarantee of data integrity, source credibility and result consistency. Compared with the prior art, the present application can flexibly select the high-performance asynchronous mode or the high-reliability synchronous mode according to the real-time risk index while ensuring data consistency, which not only improves the efficiency of transaction processing, but also significantly improves the consistency and security of cross-department transactions, and adapts to the application requirements of high concurrency, strong compliance and high security in government law enforcement. BRIEF DESCRIPTION OF DRAWINGS

[0040] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the drawings needed in the embodiments will be briefly introduced as follows. Obviously, the drawings described below are only some embodiments of the present application, and other drawings can also be obtained by those skilled in the art based on these drawings.

[0041] Figure 1 The system module flowchart of the present application. DETAILED DESCRIPTION

[0042] In order to make the purpose, technical scheme and advantages of the embodiments of the present application more clear, the technical scheme in the embodiments of the present application will be described clearly and completely in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the present application.

[0043] Embodiment, please refer to Figure 1 The embodiment described in the administrative law enforcement management service system, comprising:

[0044] Data acquisition module, for in the scene of comprehensive administrative law enforcement multi-system integration, get each law enforcement department case processing result data;

[0045] Transaction risk assessment module, for based on the cross-department interface dependence coefficient involved in the case processing result and the transaction rollback accessibility probability to calculate the risk index of transaction failure;

[0046] Transaction processing module, for when the risk index is lower than the preset threshold, using asynchronous message combined with compensation transaction mode to execute data distribution; when the risk index is higher than or equal to the preset threshold, using synchronous two-phase commit transaction mode to execute data distribution;

[0047] Intermediate state storage module, for based on the transaction processing module to write cross-department case processing result data into the intermediate state storage area, and after the consistency of each related law enforcement department is confirmed, it is submitted to the formal storage area;

[0048] Consistency verification module, for through the intermediate state storage area to execute hash check or multi-party signature verification on the data of each department;

[0049] Result submission module, for after the consistency verification is passed, the case processing result data is submitted to the business system of each related law enforcement department, and when the consistency verification is not passed, it prevents submission and triggers risk processing strategy.

[0050] Data acquisition module is used for in the scene of comprehensive administrative law enforcement multi-system integration, get each law enforcement department case processing result data.

[0051] In the specific implementation process, the data acquisition module is deployed in the access layer of the comprehensive administrative law enforcement management service system, and communicates with the existing business system of each law enforcement department through the interface. Among them, the interface can be RESTful API, SOAP Web Service, or the standard interface provided by the government affairs special network data exchange platform. In order to adapt to the difference of different department systems, the data acquisition module also includes an interface adaptation sub-module, which dynamically loads the corresponding adapter according to the technical stack and data format characteristics of the department system, so as to realize the data analysis of JSON, XML, CSV and other formats.

[0052] In the data collection process, the data collection module first requests the case processing result from the target department system according to the unique case identification information (including case number, law enforcement department code, business serial number, etc.). The case processing result can include but is not limited to penalty decision number, penalty amount, processing time, case object information, legal basis, execution status, multimedia evidence file path, etc. To improve the real-time performance of data collection, the module supports two collection modes: polling mode and event-driven mode. The event-driven mode realizes instant data acquisition by subscribing to case state change events in message queues (such as Kafka, RabbitMQ) or ESB (Enterprise Service Bus).

[0053] In addition, to improve the traceability of cross-department transaction processing, the data collection module generates collection logs and stores them persistently after collecting the case processing result. The logs include collection time, data source department, interface call time consumption, data packet size, parsing state, signature verification result, etc. In system operation, these collection logs can be used not only for subsequent transaction rollback reachability analysis, but also as an important basis for system audit.

[0054] The transaction risk assessment module provided in this embodiment is used to quantitatively evaluate the transaction failure risk of the cross-department case data distribution process in the scene of integrated administrative law enforcement multi-system integration, and automatically select the optimal transaction processing mode according to the evaluation result.

[0055] The transaction risk assessment module first obtains the unique identification of all target law enforcement departments involved in the current case processing result from the data collection module, such as department code, system node ID, etc. At the same time, it extracts the interface call link information involved in the case data submission link of these departments from the interface call monitoring log, including call source node, target node, call type, call direction, call delay, failure times, etc. This step ensures that the module can fully understand the interface call structure of this transaction between different departments.

[0056] Based on the above interface call link information, the module constructs a cross-department interface dependency graph, which uses a directed graph structure to represent the dependency graph, where the node represents the law enforcement department system, and the edge represents the interface call relationship. The direction of the edge is consistent with the call direction. In the construction process, the module calculates the in-degree (number of calls), out-degree (number of calls to other systems), and path length (length of the call chain from the current node to the target node) of each node in the dependency graph. These parameters reflect the interface dependency complexity of the department in transaction execution.

[0057] The module weights the path length, in-degree and out-degree according to preset weights to obtain a cross-department interface dependence coefficient (CID). The weight value is dynamically adjusted according to the historical transaction execution success rate, for example, when the historical success rate of a certain type of interface is low, the weight value is automatically increased, thereby increasing its contribution in the CID. The higher the CID value, the more cross-department interfaces the transaction depends on in the execution process and the more complex the structure, and the higher the potential transaction risk.

[0058] Before the transaction is formally committed, the module sends test packages to the rollback interface of the target law enforcement department one by one through simulation rollback requests, and records the response state (success or failure) and response time of each request. The test package only contains necessary transaction identification and rollback instruction meta-information, and does not trigger actual data changes, thereby ensuring the safety and controllability of detection.

[0059] The module combines the response state and response time obtained by the rollback link detection with the success rate data of historical rollback transactions, and introduces current network link quality indicators, including network delay, packet loss rate and available bandwidth, to calculate the single-node rollback reachability probability of each target department. This probability reflects the possibility of initiating a rollback request to the department and obtaining an effective response under the current conditions.

[0060] The module combines the single-node rollback reachability probability of each target department according to the topology structure of the cross-department rollback link. When the rollback link is in parallel relationship, the global rollback reachability probability is calculated by taking the complement of the product of each node reachability probability; when the rollback link is in serial relationship, the overall probability is obtained by directly multiplying each node probability. The combination calculation rule is dynamically selected by the topology structure of the rollback path to ensure the adaptability to different business link structures.

[0061] The module normalizes the CID and RRP according to their respective historical extreme value ranges, so that their value ranges are unified between zero and one. In order to improve the accuracy of evaluation, the module introduces a confidence weight based on the normalization result, which is calculated by the data collection time period and the department system stability. For example, when data collection occurs during network peak period and the target department system has frequent faults recently, the confidence weight will be correspondingly reduced, thereby amplifying the influence of this parameter on the risk index.

[0062] The module calculates the weighted CID and RRP using a nonlinear fusion function to obtain a transaction failure risk index (RI). The fusion function can be dynamically switched between a logistic regression function and a Sigmoid function, where the logistic regression function is suitable for scenarios with relatively linear parameter relationships and uniform risk distribution, and the Sigmoid function is suitable for scenarios with nonlinear parameter relationships and concentrated risk distribution. By dynamically selecting the fusion function, the sensitivity and accuracy of risk assessment can be improved under different system operating states.

[0063] The transaction processing module of the present embodiment is used in the integrated administrative law enforcement multi-system integration scenario to dynamically select a transaction execution mode according to the transaction failure risk index (RI) calculated by the transaction risk assessment module, and to use different data distribution strategies under different risk levels to balance processing efficiency and cross-department data consistency.

[0064] In the present system, the preset threshold is determined by historical transaction statistical data and business requirements. When the RI is lower than the preset threshold, it indicates that the possibility of failure during cross-department transaction execution is low, and the system prioritizes performance and concurrent processing capability, using an asynchronous message combined with a compensation transaction mode for data distribution; when the RI is higher than or equal to the preset threshold, it indicates that there is a high risk of failure during cross-department transaction execution, and the system prioritizes consistency and transaction security, using a synchronous two-phase commit transaction mode for data distribution.

[0065] When the risk index is lower than the preset threshold, the transaction processing module first generates a distribution message according to the case processing results provided by the data acquisition module. The distribution message includes case unique identification information (including case number, involved object identification, etc.), target department identification list, and compensation instruction information. The module encapsulates the distribution message into a structured data packet, which uses a unified format definition such as JSON or XML, and attaches message metadata (including message generation timestamp, sender system identification, message sequence number, etc.).

[0066] Subsequently, the module publishes the structured data packet to the queue of the message middleware. The message middleware can be Kafka, RabbitMQ, etc. that support topic subscription mechanism, ensuring that the message can be delivered to the corresponding target department subscription end according to the preset routing rules.

[0067] In the message middleware, the transaction processing module utilizes the topic subscription mechanism to distribute the data package to multiple target department systems simultaneously. This process is parallel distribution, that is, all target departments receive the case processing result almost at the same time, thereby significantly shortening the overall distribution delay. Parallel distribution not only improves processing efficiency, but also realizes asynchronous decoupling between the sending end and the receiving end, that is, the sender can continue to process other transactions without waiting for the receiver to confirm. This mechanism is particularly suitable for environments where network conditions fluctuate or receiving end system loads are uneven, because the message middleware can realize message persistence and buffering, thereby ensuring the final delivery of data.

[0068] To deal with the single-department transaction failure that may occur in the asynchronous mode, the transaction processing module records the processing status of each target department while distributing the data package. When it is detected that a certain target department does not return a successful confirmation within a specified time or explicitly returns a processing failure, the module will call the rollback interface of the department according to the pre-stored compensation instruction information to execute a compensation transaction. The compensation transaction is only performed for the failed department and does not affect other departments that have successfully completed the transaction. The compensation operation may include revoking the data records that have been written, releasing related resources, restoring the original state, and the like, thereby avoiding further spread of transaction inconsistency.

[0069] Through the above design, the asynchronous message combined with the compensation transaction mode can provide high-concurrency and high-throughput data distribution capability in a low-risk situation, and quickly compensate when a local failure occurs, ensuring the rationality of the final result.

[0070] When the risk index is higher than or equal to the preset threshold, the system enters the synchronous transaction mode. The transaction processing module first sends a transaction pre-commit request to all target department systems, and the request is attached with the case processing result data to be distributed. After receiving the pre-commit request, each target department pre-writes the data into the local database or a temporary storage area, but does not perform the final commit operation. At the same time, each department needs to return a preparation state response indicating that it has completed the pre-writing and is ready to perform the final commit.

[0071] The core of this step is to ensure that all target departments are ready to execute the transaction before the final commit, thereby avoiding forced commit that leads to data inconsistency in the case where some departments are not ready.

[0072] The transaction processing module collects all the preparation state responses returned by the target departments. When and only when all responses are in the "ready" state, the transaction enters the final commit phase; if any department returns a failure state or does not return a response within a specified time, the module immediately sends a transaction rollback instruction to all departments that are ready to cancel the pre-written data and restore the original state.

[0073] In this step, the module uses a timeout control and consistency determination algorithm to ensure that in the case of network delay or node abnormality, a rollback decision can be made quickly, thereby preventing the risk of partial commitment.

[0074] When the global preparation confirmation is passed, the transaction processing module sends a final commitment instruction to all target departments. After receiving the final commitment instruction, each target department formally commits the pre-written data to the local database and returns a commitment confirmation. At this time, the transaction is considered to be successfully completed, and the data of all departments remains consistent.

[0075] The intermediate state storage module of the present embodiment is used to ensure the consistency of cross-department case processing result data in the context of comprehensive administrative law enforcement multi-system integration, in cooperation with the transaction processing module. Its core role is to write data into a verifiable consistency intermediate state storage area before the transaction is finally committed to the official storage area, and to perform final commitment after all relevant law enforcement departments complete consistency confirmation, thereby effectively avoiding the inconsistency problem caused by partial commitment or rollback failure of cross-department data.

[0076] The intermediate state storage module is located between the transaction processing module and the official storage area, acting as a verifiable buffer layer. This buffer layer not only temporarily saves the data to be committed, but also has functions such as version management, hash verification, multi-party signature verification, etc. Before the data enters the official storage area, all relevant law enforcement departments must confirm the integrity and consistency of the data, and after successful confirmation, the data will be written into the official storage area.

[0077] This module mainly includes four core steps: intermediate state writing step, consistency confirmation request step, consistency verification step, and official commitment step.

[0078] When the transaction processing module generates case processing result data that needs to be distributed across departments, the intermediate state storage module receives the data and writes it into the intermediate state storage area.

[0079] During the writing process, the module generates a unique version number for the data, such as by concatenating a timestamp and a transaction unique identifier to ensure the global uniqueness of the version number. At the same time, the module uses a hash algorithm (such as SHA-256) to calculate the hash value of the data content, which is used for subsequent consistency verification.

[0080] This intermediate state storage area can be implemented based on a blockchain storage structure or a shared database that supports multi-party signature, thereby ensuring the tamper resistance of data in the intermediate state phase.

[0081] After the data is successfully written into the intermediate state storage area, the module sends a consistency confirmation request to all relevant law enforcement departments.

[0082] The request contains:

[0083] Data version number (uniquely identifies the data state of this transaction);

[0084] Data hash value (used to verify the consistency of data content);

[0085] Multi-party signature verification information (digital signature generated by the transaction initiator system private key, used to prove the authenticity of the request);

[0086] Data digest that the target department needs to compare (such as case number, object involved, penalty amount, etc. Key fields).

[0087] After receiving the consistency confirmation request, each department will compare the data digest in the request with the data in its local preprocessing stage to determine whether they are consistent.

[0088] The intermediate state storage module collects all the consistency confirmation responses returned by the law enforcement departments.

[0089] During the verification process, the module checks the following in turn:

[0090] Whether the returned version number is consistent with the request version number;

[0091] Whether the returned data hash value is consistent with the hash value in the intermediate state storage area;

[0092] Whether the multi-party signature can be verified by the corresponding department public key;

[0093] Whether all responses are returned within the specified time window.

[0094] Only when all responses pass the above verification conditions, the module determines that the consistency confirmation is successful.

[0095] If any item does not pass (including timeout not returned), the module will determine that the consistency confirmation fails, and trigger the exception handling process.

[0096] The consistency verification module works with the intermediate state storage module. When the transaction processing module writes the cross-department case processing result data into the intermediate state storage area, the intermediate state storage module generates the version number, full data hash value and multi-party signature set, and saves these verification information together with the data. The consistency verification module automatically starts the verification process upon receiving the consistency confirmation request or before the transaction is officially submitted, to ensure that the data of all relevant law enforcement departments is consistent with the intermediate state storage area.

[0097] The consistency verification module first extracts the corresponding case processing result data, full data hash value and multi-party signature set from the intermediate state storage area according to the target version number of the current transaction.

[0098] The target version number is a globally unique identifier generated by a transaction unique identifier and a timestamp, used to locate the data version required for this verification;

[0099] The full data hash value is a digest calculated by a one-way hash function (such as SHA-256) on the case processing result data, used to detect whether the data has been tampered with during storage or transmission;

[0100] The multi-signature set is a signature set formed by the digital signature of the intermediate state data by each law enforcement department participating in the transaction. Each signature is generated by the private key of the corresponding department, used to verify the authenticity of the data source.

[0101] After extracting the above data, the module generates a verification task list according to the target department list participating in the transaction, by department dimension. Each task includes the department's data copy, expected hash value, expected signature, and corresponding public key information.

[0102] When executing the verification task, the module first calculates the full data hash value of the data returned by each department. The specific process is as follows:

[0103] Standardize the case processing result data returned by the department (including field order sorting, removing white space, and unifying encoding format, etc.) to avoid inconsistencies in hash values caused by non-content differences;

[0104] Input the standardized data into the hash function for calculation to obtain the actual hash value of the department's returned data;

[0105] Compare the actual hash value with the expected hash value recorded in the intermediate state storage area. If they are consistent, it is determined that the department's data has not been tampered with during transmission and storage; if they are not consistent, record that the department's hash verification has failed, and participate in the consistency determination as a risk factor in the subsequent steps.

[0106] After completing the hash value comparison, the module continues to perform multi-signature verification. For each department's signature, the module decrypts the signature using the department's public key, and compares the decryption result with the original data digest recorded in the intermediate state storage area.

[0107] If the signature verification is passed, it means that the department has indeed signed the data, and the data source is reliable; if the signature verification fails, the following situations may exist:

[0108] The wrong public key is used for verification (the source is not consistent);

[0109] The data was tampered with before and after signing;

[0110] The signature data is damaged or incomplete.

[0111] The department whose signature verification fails will also be recorded as a consistency risk point.

[0112] The module will calculate the success rate of consistency verification according to the hash check results and signature verification results of all departments. The success rate is calculated in the following way:

[0113] The number of departments whose verification is passed is divided by the total number of departments participating in the transaction, and a percentage value is obtained.

[0114] Subsequently, the module compares the success rate with a preset consistency threshold:

[0115] If the success rate is greater than or equal to the threshold, it is determined that the consistency verification is passed, and the final commit phase of the transaction is allowed to enter;

[0116] If the success rate is less than the threshold, it is determined that the consistency verification fails, and the transaction is prevented from entering the final commit phase, and an exception handling process is triggered.

[0117] The setting of the consistency threshold can be flexibly adjusted based on business security requirements. For example, in law enforcement transactions involving highly sensitive data, the threshold can be set to 100%, that is, all departments must pass the verification before allowing submission; in a higher fault-tolerant scenario, the threshold can be appropriately lowered to improve transaction completion rate.

[0118] When the consistency verification fails, the module will start an exception handling process, including:

[0119] Send a retry request to the department whose verification fails, requiring it to return the data copy, signature and confirmation information again;

[0120] In the case that multiple rounds of verification still cannot reach an agreement, inform the transaction processing module to perform a cross-department rollback operation to restore to the state before transaction execution;

[0121] Record the departments whose verification fails, the failure reason, the number of retries, and the final processing result for subsequent analysis and optimization.

[0122] The result submission module of the present embodiment is used to submit case processing result data to the business systems of each relevant law enforcement department in the context of integrated administrative law enforcement multi-system integration when the consistency verification module determines that the consistency verification is passed; when the consistency verification is not passed, the submission operation is prevented and a risk handling strategy is triggered, thereby ensuring the integrity, consistency of cross-department case data and the legality and compliance of business execution. This module directly determines the landing execution of cross-department transactions in the final stage, and is a key link to ensure transaction security.

[0123] The execution timing of the result submission module is located in the last stage of the transaction processing link, that is:

[0124] The transaction processing module completes data distribution and writes data into the intermediate state storage area;

[0125] The consistency verification module completes hash verification and multi-party signature verification on the returned data of each department;

[0126] The verification result reaches the preset consistency threshold (i.e., the consistency verification passes);

[0127] At this time, the result submission module takes over the data processing flow and is responsible for formally pushing the verified data to the business systems of each relevant law enforcement department, realizing the final data landing. If the consistency verification does not pass, the module prevents submission and turns to the risk handling path to prevent the formal application of incorrect data.

[0128] The result submission module first receives the verification result returned by the consistency verification module. If the verification result is marked as "pass" and the verification success rate is greater than or equal to the preset consistency threshold, it enters the submission execution phase; if the verification result is marked as "not pass" or the verification success rate is lower than the threshold, it directly enters the risk handling strategy execution phase without performing any submission operation.

[0129] The preset consistency threshold is set in the following way: divide the number of departments that have passed verification by the total number of departments involved in the transaction to get the consistency ratio, and compare it with the threshold. For example, when the consistency ratio is 95% and the threshold is set to 90%, the judgment condition is met.

[0130] In the case of meeting the submission conditions, the result submission module performs the following operations:

[0131] Data preparation: Extract the confirmed version of the case handling result data from the intermediate state storage area, including case number, information of the object involved, penalty amount, handling conclusion, related evidence link, etc.

[0132] Interface call: For each target law enforcement department, call the formal data receiving interface of its business system. Interface calling can be based on government special network REST API, SOAP Web Service or ESB (Enterprise Service Bus) to ensure safety and controllability;

[0133] Secure transmission: Use HTTPS, government VPN or other encryption tunnel technology during transmission to prevent data from being intercepted or tampered at the network layer;

[0134] Submission confirmation: Receive the submission confirmation response returned by each target department and record the confirmation time, response status, processing time, etc.

[0135] To prevent transmission errors or data loss during interface calling, the result submission module will perform a read-back verification after submission is completed:

[0136] Call the case query interface of the target department to query the submitted data according to the case number;

[0137] Hash the query result and compare it with the hash value of the case version in the intermediate state storage area;

[0138] If the comparison result is consistent, it is determined that the department data submission is successful; if it is not consistent, the department is recorded as a submission exception, and the remedial processing link (such as retry submission or manual intervention) is entered.

[0139] When the consistency verification fails or a submission exception occurs during the submission process, the result submission module triggers a risk handling strategy, including but not limited to:

[0140] When the consistency threshold is not reached, all formal submission operations are directly prevented to prevent partial error data from being solidified to the business system;

[0141] Notify the transaction processing module to perform a rollback operation on the submitted department to restore to the pre-submission state;

[0142] Initiate a re-verification request to the consistency verification module to confirm whether it is a temporary error;

[0143] Package and push the abnormal data to the manual audit system for risk assessment and manual processing by authorized personnel;

[0144] Record the detailed information of the risk event, including time, involved department, failure reason, data summary, etc., for subsequent analysis and system optimization.

[0145] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical scope disclosed in the present application, which should be covered within the protection scope of the present application.

Claims

1. A comprehensive administrative law enforcement management service system, characterized in that: The method comprises the following steps: A data collection module is used to collect case processing result data of each law enforcement department in a comprehensive administrative law enforcement multi-system integration scenario; A transaction risk assessment module is used to calculate a transaction failure risk index based on a cross-department interface dependency coefficient and a transaction rollback reachability probability involved in the case processing result; The cross-department interface dependency coefficient is obtained by: Obtaining all target law enforcement department identifiers involved in the current case processing result, and extracting interface call link information related to case data submission of each target department; Building a cross-department interface dependency graph based on the interface call link information, and calculating the in-degree, out-degree and path length of each target department in the dependency graph; Weighted calculation of the path length, in-degree and out-degree according to a preset weight to obtain the cross-department interface dependency coefficient; Normalizing the cross-department interface dependency coefficient and the transaction rollback reachability probability, and assigning a confidence weight; Using a nonlinear fusion function to calculate the weighted cross-department interface dependency coefficient and the transaction rollback reachability probability to obtain the transaction failure risk index, wherein the nonlinear fusion function dynamically switches between a logistic regression function and a Sigmoid function according to the system running state; A transaction processing module is used to execute data distribution in an asynchronous message combined with a compensation transaction mode when the risk index is lower than a preset threshold, and execute data distribution in a synchronous two-phase commit transaction mode when the risk index is higher than or equal to the preset threshold; An intermediate state storage module is used to write cross-department case processing result data into an intermediate state storage area based on the transaction processing module, and submit to the formal storage area after the consistency of each related law enforcement department is confirmed; A consistency verification module is used to perform hash verification or multi-party signature verification on the data of each department through the intermediate state storage area; A result submission module is used to submit the case processing result data to the business systems of each related law enforcement department after the consistency verification passes, and prevent submission and trigger a risk handling strategy when the consistency verification fails.

2. The integrated administrative law enforcement management service system according to claim 1, characterized in that: The transaction rollback reachability probability is obtained by: Before the transaction is submitted, test packets are sent to the rollback interfaces of the target law enforcement departments in sequence by simulating rollback requests, and the response state and response time are recorded; The single-node rollback reachability probability of each target department is calculated by combining the response state of the test packet, the historical rollback transaction success rate and the current network link quality index; The single-node rollback reachability probability of each target department is combined and calculated according to the parallel and serial relationship of the cross-department rollback link to obtain the transaction rollback reachability probability of the current transaction as a whole.

3. The integrated administrative law enforcement management service system according to claim 1, characterized in that: When the risk index is lower than the preset threshold; The case processing result data is generated into a distribution message, the message is encapsulated into a structured data packet, and the data packet is published to a message middleware queue; The data packet is distributed to all target department systems in parallel by using the topic subscription mechanism of the message middleware; When a target department processing failure or timeout is detected, the corresponding rollback interface is called according to the pre-stored compensation instruction information.

4. The integrated administrative law enforcement management service system according to claim 3, characterized in that: When the risk index is higher than or equal to the preset threshold; Sending a transaction pre-commit request to all target department systems, along with the case processing result data to be distributed; Collecting the preparation status responses from all target departments, and entering the transaction commit phase only when all responses are ready; if any target department returns a failure status or fails to respond within a timeout, sending a transaction rollback instruction to all departments that have been prepared; After the global preparation confirmation passes, sending a final commit instruction to all target departments, which will commit the pre-written data as official records accordingly.

5. The integrated administrative law enforcement management service system according to claim 1, characterized in that: In the intermediate state storage module, receiving the cross-department case processing result data passed by the transaction processing module, writing it into the intermediate state storage area, and generating the corresponding version number and full data hash value at the same time; Sending a consistency confirmation request to all relevant law enforcement departments, including the intermediate state version number, data hash value, and multi-party signature verification information, and requiring each department to compare its local pre-processing data and return a consistency confirmation response; Collecting all the returned confirmation responses from law enforcement departments, and comprehensively comparing the version number, data hash value, and signature verification results; only when all responses pass the verification, the consistency confirmation is successful.

6. The integrated administrative law enforcement management service system according to claim 5, characterized in that: In the consistency verification module; Extracting the case processing result data corresponding to the target version number, as well as its full data hash value and multi-party signature set, and generating a verification task list according to the department dimension; For the data returned by each department, first calculate its full data hash value and compare it with the hash value recorded in the intermediate state storage area; then use the department's public key to verify the signatures in the multi-party signature set; According to the success rate of hash verification and signature verification of each department, compare it with the preset consistency threshold; when the success rate reaches or exceeds the threshold, the consistency verification is passed; if the threshold is not reached, trigger the exception handling process, including resending the consistency confirmation request to the failed department or directly preventing the final commit.

Images