Alarm extension information write-back method, system and storage medium

Abstract

The present application relates to the technical field of distributed message processing, and particularly relates to an alarm extension information write-back method and system and a storage medium. The method comprises the following steps: receiving an evidence state change message, and performing pre-filtering on the message to screen out valid messages; obtaining evidence details based on the valid messages, generating an automatic determination result according to the evidence details, and performing persistent storage on evidence processing records containing the automatic determination result; when the automatic determination result is invalid, performing an invalid evidence linkage update operation, which comprises binding a special tag to an associated business object and updating an alarm state; and performing an extension column write-back operation, assembling an extension field according to the automatic determination result and file information in the evidence details, and writing back the extension field to a dynamic extension column of the business object. The technical solution can distinguish between invalid evidence and manual evidence, and ensure real-time consistency between evidence processing records and the state of the business object.

Description

Technical Field

[0001] This invention relates to the field of distributed message processing technology, specifically to a method, system, and storage medium for writing back alarm extended information. Background Technology

[0002] In vehicle-mounted traffic violation evidence collection applications, the evidence data processing flow typically encompasses several key stages, including quality assessment after evidence download, dashboard statistical registration, and write-back of alarm information. Currently, existing technical solutions generally employ an architecture where functions such as status monitoring, manual review, and platform field updates are deployed in separate modules. This decentralized approach results in a lack of tight coupling and linkage between different business stages, making it difficult to form an automated closed-loop processing mechanism with evidence status changes as a single entry point.

[0003] Specifically, existing technologies typically employ the following methods: after receiving evidence status notifications via a message queue, they are directly written into the business table; or invalid evidence is manually reviewed on a specific interface, and information such as license plates is manually entered before data entry. Although some existing systems support the basic function of filtering images by channel, the overall business process design fails to integrate the evidence quality assessment based on channel existence with alarm status updates, dedicated tag binding, and extended column write-back operations into the same transaction chain for coordinated processing.

[0004] Furthermore, in ensuring data consistency, existing consumer-side systems mostly employ distributed locks combined with a full pre-consumption alignment mechanism. However, these mechanisms are primarily designed for device reporting links, focusing on resolving concurrency issues during device data reporting. They struggle to directly adapt to and cover complex business requirements such as multi-target write-back and status linkage triggered by evidence quality assessment results. This limitation results in low automation levels in existing solutions when facing changes in evidence status, and makes it difficult to guarantee real-time consistency between evidence processing records and the status of business objects. Summary of the Invention

[0005] The purpose of this invention is to propose an alarm extended information write-back method, system, and storage medium that can distinguish between invalid evidence and evidence awaiting manual processing, and ensure real-time consistency between evidence processing records and business object status.

[0006] To achieve the above objectives, in a first aspect, the present invention proposes an alarm extended information write-back method, comprising: Receive evidence status change messages and perform pre-filtering on the messages to select valid messages that meet the preset target status and belong to the preset business type; Based on the valid message, obtain the evidence details, generate an automatic judgment result based on whether there is a file belonging to a predetermined image channel set in the evidence details, and persistently store the evidence processing record containing the automatic judgment result. When the automatic determination result is invalid, an invalid evidence linkage update operation is performed. The invalid evidence linkage update operation includes binding a special tag to the associated business object and updating the alarm status. Perform an extended column write-back operation, assemble extended fields and write them back to the dynamic extended column of the business object based on the automatic judgment result and the file information in the evidence details.

[0007] Beneficial effects of the basic solution: This technical solution receives evidence status change messages and performs pre-filtering. Based on whether a file belonging to a predetermined image channel set exists in the evidence details, it generates an automatic judgment result, achieving automated identification of evidence validity. When the automatic judgment result is invalid, the system automatically executes an invalid evidence linkage update operation and persists the processing record. This replaces the traditional manual registration and review method, significantly reducing operation and maintenance costs and improving the automation level of evidence processing.

[0008] This technical solution tightly integrates automatic judgment results with extended column write-back operations. While performing invalid evidence linkage update operations, it assembles extended fields based on the automatic judgment results and file information in the evidence details, and writes them back to the dynamic extended columns of the business object. This ensures closed-loop consistency between evidence status, alarm tags, processing records, and platform-displayed information, effectively avoiding data inconsistencies caused by human error. The judgment is based on file information (such as VAI structured data) in the evidence details, ensuring the rigor of the judgment logic.

[0009] This technical solution performs pre-filtering and automatic judgment based on preset target states, preset business types, and a predetermined set of image channels, thus strongly binding the evidence review rules to the actual evidence collection equipment channels and business types. This allows the solution to flexibly adapt to the differences in evidence collection rules at different locations; at the same time, by combining the document information in the evidence details for judgment, the rigor of the judgment logic is ensured.

[0010] When performing extended column write-back operations, this technical solution assembles extended fields based on document information in the evidence details, making the source of the write-back information in the extended columns clear and identifiable. This not only avoids data source confusion and ensures data traceability and auditability, but also supports accurate write-back without mistakenly writing other fields in specific scenarios (such as when assembling based on document information).

[0011] Upon receiving a message indicating a change in evidence status, the message is pre-filtered, and the evidence processing record containing the automatic determination result is persistently stored in subsequent processing. This ensures that the processing logic for the same evidence is controlled, guarantees the accuracy of the data status, and improves the stability and robustness of the system under high concurrency or complex message scenarios.

[0012] As a feasible and preferred approach, message pre-filtering includes: Parse the evidence status change message and extract the status field and alarm type field; The message is retained only if the value of the status field is equal to the download completed state and the alarm type field belongs to the pre-configured set of violation alarm types; Idempotency verification is performed based on a combination of tenant identifier and evidence identifier. If a corresponding processing record already exists in the database, the message is ignored.

[0013] As a feasible preferred solution, the pre-filtering step further includes: initializing the tenant context based on the tenant identifier in the valid message, so that subsequent interface calls have the corresponding tenant permissions.

[0014] As a feasible preferred solution, an automatic determination result is generated based on whether a file belonging to a predetermined image channel set exists in the evidence details, including: From the file list of the evidence details, files whose file type is image and whose channel number belongs to the predetermined image channel set are selected to obtain the judgment module; If the determination module is empty, an automatic determination result indicating invalidity and a type identifier indicating automatic processing by the system are generated. If the determination module is not empty, it generates an automatic determination result indicating that it needs to be manually reviewed and a type identifier indicating that it has not been automatically processed.

[0015] As a feasible and preferred solution, the invalid evidence linkage update operation also includes: Before binding the dedicated tag, query the local cache or tag management service to obtain the identifier of the dedicated tag; If the dedicated tag does not exist, create the dedicated tag and update the cache; If the tag binding or alarm status update interface call fails, log the error but do not revoke the persisted evidence processing record.

[0016] As a feasible and preferred approach, performing an extended column write-back operation includes: When the evidence details contain a file belonging to a predetermined image channel set, the image with the largest channel number is selected as the parsing source, and the license plate number is parsed from the image's metadata. Assemble the extended field mapping object: If the parsed license plate number is not empty, write it to the license plate number extended field; write it to the processing type extended field only if the automatic determination result is invalid. Call the extended column update interface to write back the extended field mapping object to the business object; if the extended field mapping object is empty, skip the write-back operation.

[0017] As a feasible and preferred solution, the extended column write-back operation is performed on evidence that is automatically determined to be invalid or requires manual review. When the automatic determination result is invalid, the extended field mapping object includes a processing type extended field, or includes both a processing type extended field and a license plate number extended field. When the automatic determination result is that manual review is required, the extended field mapping object only includes the license plate number extended field and does not include the processing type extended field.

[0018] As a feasible and preferred solution, the method adopts a batch message listening mode, which confirms the consumption offset uniformly after the entire batch of messages is processed; if a single message processing exception occurs, only the log is recorded and the remaining messages in the same batch are processed, without blocking the confirmation process of the entire batch of messages. If obtaining the evidence details fails, the current evidence processing flow will be terminated, the evidence processing record will not be written, and subsequent linkage updates and extended column write-back operations will not be performed. The evidence processing record serves as the sole data basis for subsequent alarm status updates, tag binding, and extended column write-back; the range of values ​​for the automatic judgment result is limited to invalid or pending manual review; valid values ​​are independently written by the downstream manual review module or AI analysis module.

[0019] Secondly, this application proposes an alarm extended information write-back system, applied to the aforementioned alarm extended information write-back method, comprising: The message filtering module is used to receive evidence status change messages and perform pre-filtering on the messages to select valid messages that meet the preset target status and belong to the preset business type. The determination module is used to obtain evidence details based on the valid message, and generate an automatic determination result based on whether there is a file belonging to a predetermined image channel set in the evidence details; The processing record persistence module is used to persistently store the evidence processing records containing the automatic judgment results; The alarm linkage module is used to perform an invalid evidence linkage update operation when the automatic judgment result is invalid, including binding a special tag to the associated business object and updating the alarm status. The tag caching module is used to cache the identifiers of the dedicated tags and supports querying and creating tags when the cache is not hit. The license plate parsing module is used to select the image with the largest channel number value to parse the license plate number when a file belonging to a predetermined image channel set exists. The extended column write-back module is used to assemble extended fields based on the automatic determination result and file information and write them back to the dynamic extended column of the business object.

[0020] Thirdly, this application proposes a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the aforementioned alarm extended information write-back method. Attached Figure Description

[0021] Figure 1 This is a logical diagram of a method for writing back alarm extended information.

[0022] Figure 2 This is a mapping diagram of the image verification and processing results for a predetermined channel.

[0023] Figure 3 This is a timing diagram for invalid linkage and extended column write-back. Detailed Implementation

[0024] To make the technical solution and advantages of this application clearer, the technical solution of the present invention will be further described in detail below with reference to the accompanying drawings. It is understood that the specific embodiments described herein are only some embodiments of the present invention, and are only used to explain this application, not to limit it. It should be noted that the technical features or combinations of technical features described in the following embodiments should not be considered isolated; they can be combined with each other to achieve better technical effects. The same reference numerals appearing in the accompanying drawings of the following embodiments represent the same features or components, and can be applied to different embodiments.

[0025] Furthermore, unless otherwise defined, the technical or scientific terms used in this invention description shall have the ordinary meaning understood by one of ordinary skill in the art to which this invention pertains.

[0026] The present invention will now be described in further detail with reference to the accompanying drawings.

[0027] Example 1 The operating environment of this embodiment does not require special customization; it can be deployed using only existing components of a conventional vehicle monitoring platform. The required basic components include: Message queue: Apache Kafka is used as the distributed message queue to receive evidence state change events reported by the device side. The topic is configured as a state change message topic (e.g., evidence_state_change_topic), and the consumer group is configured as a message consumer group identifier (e.g., evidence_process_group). Database: A relational database (such as MySQL) is used, which includes an evidence processing record table (evidence_processing_record) and an alarm information table (alarm_info). Caching: Use local memory caching (such as ConcurrentHashMap) or distributed caching (such as Redis) to store identifiers for invalid evidence (such as No C27 pictures) special tags, reducing the frequency of database queries.

[0028] In one embodiment, a container initialization hook is added during service startup. During the application service's startup and loading phase, the query interface of the tag management service is proactively invoked to directly obtain the labelId of the invalid evidence tag and pre-write it into a dedicated tag cache (e.g., C27NoImageLabelCache) within the process. Subsequent step S302 does not require triggering a cache miss rollback query creation process; the tag identifier is directly read from the pre-warmed cache, further reducing runtime query overhead and improving tag binding execution efficiency.

[0029] This embodiment uses the general configuration values ​​for vehicle monitoring scenarios by default: Pre-defined image channel configuration parameter (evidence_processing_c27_channels): The configuration value for the set of pre-defined image channels. The default value is a comma-separated string (e.g., 12, 13, 14, 15), which means that the corresponding channel number belongs to the range of image channels to be verified. Violation Alarm Type Configuration Set (violationAlarmTypes in this example): This is the configuration set for violation alarm types, which by default includes enumeration values ​​for alarm types corresponding to four types of violations: running red lights, crossing lines, illegal parking, and speeding.

[0030] Target state code (target_state_code in this embodiment): The state code for the evidence download completion state (default value is 3). The default value is the corresponding enumeration value (SUCCESS), which means that the evidence file has been fully downloaded and has entered the processable state. Dedicated label name configuration item (c27_no_image_label_name in this embodiment): Dedicated label name, configured as the dedicated label name for invalid evidence (No C27 pictures in this embodiment), used to mark invalid evidence.

[0031] In one embodiment, without modifying any subsequent channel filtering execution logic, the interface for pulling the channel set only needs to replace the original logic of reading the local global configuration file with querying the corresponding channel number list from the independent configuration table at the tenant / application level based on the currently passed tenantId or applicationId, which is fully adaptable to the different evidence collection and verification rules customized by different sites.

[0032] Reference Figure 1 This invention provides a method for writing back alarm extended information, comprising: Step S100, message access and pre-filtering, using evidence status change messages as the trigger source, completes invalid event filtering and idempotency control at the business layer to prevent non-target events from entering the subsequent processing chain from the entry point, including: Step S101: Message parsing. The message listening service acts as a consumer, subscribing to the state change message topic `evidence_state_change_topic` in the distributed message queue Kafka. It pulls messages using a batch listening mode, with a batch size set to, for example, 10 or 50 messages.

[0033] For each received raw message (JSON format string), perform a parsing operation to deserialize it into a uniform envelope structure KafkaCommonMsg.

[0034] The specific analysis process is as follows: Assuming the original message payload is a JSON object, after parsing, the payload field is extracted and encapsulated into a state change message body, EvidenceStateChangeData object. This object must contain at least the following fields: tenantId (tenant ID): Used for multi-tenant isolation to distinguish business data of different operating entities.

[0035] evidenceId (Evidence ID): A string type, a unique identifier for the evidence.

[0036] state: An integer value representing the current state of the evidence.

[0037] alarmInfo (alarm information object): contains subfields such as alarmId (alarm ID), alarmType (alarm type), and vehicleId (vehicle ID).

[0038] deviceId (Device ID): String type.

[0039] If a single message's JSON structure is invalid, causing deserialization failure, the JsonParseException exception is caught, the error log is logged, and the message is skipped, continuing to process the next message in the batch. If the entire batch of messages fails to deserialize, a batch-level error is logged, and the consumption offset of the current batch is manually committed in the final code block to avoid blocking subsequent message consumption, relying on the upstream resend mechanism to ensure reliability.

[0040] In one embodiment, the message middleware Kafka can be replaced with other message queues such as RabbitMQ, or the upstream evidence state change HTTP callback interface can be directly connected. Only the message retrieval / receiving logic corresponding to different message sources in step S101 and the parsing rules adapted to the unified envelope structure need to be modified. All closed-loop core execution steps from step S102 to step S403 do not need to be modified at all, so that message notification triggering methods in different scenarios can be quickly adapted.

[0041] Step S102, state filtering: Iterate through each valid message parsed in S101, and read the state field of the EvidenceStateChangeData object in the state change message body for judgment.

[0042] The message is allowed to proceed to the next processing step only if the value of state is equal to the download completed state (i.e., the value 3, corresponding to the SUCCESS semantics); all other states, including downloading, download failed, and deletion states, are ignored and do not proceed to any subsequent processing steps.

[0043] This step directly filters out intermediate events where evidence has not yet been fully downloaded, avoiding the execution of invalid verification logic on incomplete evidence and reducing unnecessary resource consumption.

[0044] Step S103, Business Type Filtering Step: Read the alarm information alarmInfo and alarm type field alarmType from the current message state change message body EvidenceStateChangeData and perform verification.

[0045] If the alarmInfo object is null and does not exist, or if the alarmType field is blank, it is determined to be a non-violation alarm and the message is ignored.

[0046] The process is only allowed to proceed to the next step if the alarmType value in the current message belongs entirely to the pre-configured violationAlarmTypes service type set. Non-violation alarms, such as device offline alarms and vehicle movement alarms, are all directly blocked outside the link to prevent irrelevant events from occupying automatic processing resources.

[0047] Step S104, idempotency control: Perform database-based idempotency checks before business processing to prevent duplicate Kafka message delivery from causing duplicate processing. Specific implementation details are as follows: Use the combination of the tenantId and evidenceId fields carried in the current message as a composite unique key to query the existing evidence processing record table in the relational database.

[0048] If the query result is not empty, meaning that the (tenant ID, evidence ID) combination already has a corresponding processing record, the current message will be ignored and no further operations will be performed. The message is only allowed to proceed to the next processing step if the query result is empty, completely eliminating the problem of the same evidence being processed repeatedly due to duplicate delivery of Kafka messages and ensuring business idempotency.

[0049] Step S105: Tenant context initialization. Since the platform adopts a multi-tenant architecture, subsequent calls to internal platform interfaces (such as obtaining evidence details and updating alarms) require tenant permissions.

[0050] Based on the tenantId obtained from parsing the current message, initialize the tenant administrator request context corresponding to this tenant.

[0051] This context carries the correct tenant isolation identifier and a valid administrator authentication header, ensuring that all subsequent operations calling the platform's internal APIs can be executed normally within the tenant's permission scope, and there will be no unauthorized access to data across tenants.

[0052] After this step is completed, the listener layer can uniformly confirm the Kafka message offset after all messages in the batch have been processed. If a single message processing fails, only an error log is recorded separately, and the remaining messages in the same batch continue to be processed. The confirmation process for the entire batch will not be blocked due to a single message exception. This embodiment does not employ distributed single-livelocks, full cache alignment before consumption, or the holdOffset strategy for failures. It is completely independent of the consumption consistency scheme of the device reporting link and does not affect each other.

[0053] Step S200: Automatic channel determination and processing record persistence. Based on the pre-filtering, evidence details are retrieved, the existence of a predetermined set of image channels is determined, and the processing results of the automatic link are generated and persistently stored as the sole data source for all subsequent operations, including: Step S201, the evidence details acquisition step, calls the platform's preset evidence details query interface, passes the evidenceId of the current evidence as input parameter, and requests that the interface return at least two core fields: file information and access address file_url, where the file field is a list of all file information associated with the current evidence fileList.

[0054] If the call to the evidence details interface times out or returns an error code and cannot obtain complete details, the entire process of this piece of evidence will be terminated directly. No processing record will be written, and it will not enter the subsequent linkage update logic to avoid generating incorrect judgment results based on incomplete file data.

[0055] Step S202, image selection step, refer to Figure 2 ,include: The channel number string is obtained by reading the global configuration item predefined image channel configuration parameters. The string is then split by commas to obtain a list of all channel numbers belonging to the predefined set. In this embodiment, the default result after splitting is a channel array of [12,13,14,15].

[0056] Iterate through each file object in the fileList returned by step S201, and filter the files that meet two conditions at the same time: the first condition is that the file attribute fileType is of type IMAGE, and the second condition is that the file channel number attribute channelNo belongs to the set of predefined channel numbers after segmentation. Finally, summarize all the files that meet the conditions to obtain the judgment module.

[0057] The length of this list directly determines the subsequent automatic judgment result. A length of 0 means that there is no image from the predetermined channel that meets the requirements for this evidence.

[0058] Step S203, the result mapping step, strictly follows preset rules in generating the results. It does not output valid VALID values; the VALID results are only manually verified downstream or written separately by the AI ​​analysis module, completely separate from this automatic entry point. The execution rules are strictly based on the following branch judgments: First branch: If the judgment module obtained by filtering is empty, the automatic assignment and automatic judgment result is invalid, and the assignment processing is marked as automatic system processing (processType=SYSTEM_AUTO).

[0059] Second branch: If the selected judgment module is not empty, and the additional image quality verification rules are not enabled in this preferred embodiment, the automatic judgment result is automatically assigned as pending manual review (processResult=NULL), and the processing type identifier is assigned as automatic processing (ProcessType=WITHOUT_PROCESS).

[0060] The third branch: If unexpected situations such as system anomalies or interface errors occur during the analysis and judgment process, the process will be downgraded directly, and the automatic judgment result will be assigned as pending manual review (processResult=NULL). This will not interrupt the main process, and the abnormal evidence will be transferred to the subsequent manual process for backup.

[0061] In one embodiment, only a custom image quality verification rule needs to be inserted before the original third branch abnormal degradation logic. Custom verification logic such as image clarity and license plate occlusion rate is performed on samples with a non-empty target image list. When the verification result is qualified, the result processResult will be automatically assigned a valid VALID, and when the verification result is unqualified, it will be assigned an invalid INVALID. In addition, the preferred embodiment clearly states that this extension is not enabled by default. The VALID result still retains the original main logic written by the downstream manual review or AI analysis module, and is fully compatible with the original closed-loop process.

[0062] Step S204: Process record assembly. Create a new empty EvidenceProcessingRecord object and assign values ​​to all related fields in sequence. The complete list of fields to be assigned values ​​is as follows: tenantId: A unique identifier for the tenant currently processing the evidence, derived from the message context; appId: A unique identifier for the current business application; evidenceId: The globally unique identifier of the current evidence, derived from the message data; alarmId: The unique identifier of the business object to which the current evidence is bound, derived from data.alarmInfo.alarmId.

[0063] vehicleId: A unique identifier associated with the vehicle, derived from data.alarmInfo.vehicleId.

[0064] deviceId: A unique identifier for the associated forensic device, derived from message data.

[0065] processResult: The automatic determination result generated by step S203, with a value of INVALID or NULL, representing the result of step S203.

[0066] processType: An enumeration value of the processing type generated by step S203, which is the type determined by step S203.

[0067] processTime: The timestamp at which the current execution is automatically determined, for example, System.currentTimeMillis().

[0068] Audit timestamp field: Used to record the creation and update times of data for subsequent operation traceability.

[0069] Step S205, the persistence step, involves performing an INSERT operation on the EvidenceProcessingRecord object assembled in step S204, directly writing it into the evidence processing record table of the relational database.

[0070] This table serves as the sole reliable data source for subsequent platform dashboard statistics and issue tracing. All subsequent alarm updates, tag bindings, and extended column write-back operations are based solely on the judgment result of this record.

[0071] If obtaining evidence details fails in step S201, all subsequent steps S202 to S205 will be skipped, no record will be written to the evidence processing record table, and the subsequent linkage update process will not be initiated.

[0072] Step S300, Invalid Evidence Linkage Update: This step only applies to evidence whose automatic determination result is INVALID (invalid). It completes the binding of a dedicated tag and the update of the alarm status for the business object. Evidence with a determination result of NULL (requiring manual intervention) skips all steps in this stage and proceeds to the next stage's extended column write-back process, including: Step S301, invalid evidence linkage update entry, including: Read the processResult field from the evidence processing record persisted in step S205 and perform the judgment.

[0073] Entering the invalid alarm linkage update branch of S302 and S303 is allowed only if the value of processResult is INVALID.

[0074] If the value of processResult is NULL, skip steps S302 and S303 and proceed directly to the next stage of the extended column write-back process.

[0075] Step S302: Dedicated label binding, read the dedicated label cache in the local cache within the process, and attempt to directly obtain the unique labelId label ID corresponding to the predefined invalid evidence dedicated label.

[0076] Cache miss handling logic: If the tag is not found in the in-process cache, a double-check mechanism is executed inside the synchronized block of the synchronization lock. First, the cache is checked again to confirm that the tag still does not exist. Then, the pagination query interface of the tag management service is called to traverse the global tag list that has been created and search for the special tag named "Dedicated Tag for Invalid Evidence". If the query finds that the label does not exist in the system, the label creation interface is called directly to create the global private label, and the newly generated labelId is written back to the private label cache in the process.

[0077] After obtaining a valid label ID, the platform's preset alarm label binding interface handleAlarm is called to bind the list of label IDs carrying the labelId to the alarmId business object associated with the currently processed evidence.

[0078] If both the tag cache and the database service are unavailable, skip the tag binding step directly without throwing an exception to interrupt the main process, and continue to attempt to execute the alarm status update operation in step S303.

[0079] Step S303, alarm status update, including: Construct an alarm status update request object to directly update the status of the business object corresponding to the current alarmId to the status value corresponding to the invalid semantics of INVALID defined by the platform.

[0080] After the update, the alarm status displayed on the platform is completely consistent with the automatic judgment results of the evidence processing records, avoiding inconsistencies between the two sets of data.

[0081] If the call to the alarm status update interface statusUpdate or the handleAlarm interface bound to the tag fails, only the error log will be logged. The evidence processing records that have been successfully inserted in the previous S205 step will not be revoked, ensuring that the data source for audit traceability will not be lost.

[0082] Step S400, Extended column write-back, refer to Figure 3 This step can be executed for evidence of both judgment results (applicable to both INVALID and NULL paths), and is completely decoupled from the invalid alarm linkage update step in the previous stage. The extended column write-back operation runs independently of the status update and tag binding process. Even if an anomaly occurs in the preceding steps, this step can still attempt to execute, including: Step S401, Pre-selection of images and license plate parsing: The license plate parsing operation in this step is only performed if the target image list obtained from step S202 is not empty; if the target image list is empty, this step is skipped directly and no parsing logic is executed.

[0083] In the list of all non-empty target images, the image with the largest channelNo value is selected as the sole source for parsing. This selection rule ensures that the source of license plate parsing is completely identifiable and auditable, and avoids the problem of random and unstable source selection when multiple images coexist.

[0084] Using the fileUuid, the unique identifier of the selected image with the highest channel number, as the input parameter, the getFileDetail interface is called to obtain the complete metadata information of the image file.

[0085] Parse the exInfo extended information field in the returned metadata, and read the devExtraInfo.VAI.VN field under the nested level. This field is the license plate number field in the VAI vehicle analysis extended information structure generated by the device side. After reading, assign it the value of the identification license plate number violationPlateNumber.

[0086] When the determination result is INVALID, the target image list is empty in most scenarios. This step will skip the license plate parsing operation and only write the extendedProcessType field in the subsequent steps.

[0087] Step S402, ExtendColumn Assembly: Create an empty `extendColumns` dynamic mapping object and perform field assignment operations according to different scenarios of the judgment result: Scenario 1: If the license plate number obtained from step S401 is not empty and has a value `violationPlateNumber`, write a key-value pair with the license plate number as the key of the extendedVehicleNumber field and the value of the obtained license plate number to the extended column object. This field is written when the judgment result is NULL and needs to be manually checked. This can directly pre-fill the license plate information for the subsequent manual review process, greatly improving the efficiency of manual processing.

[0088] Scenario 2: If and only if the current processing result processResult is INVALID, a key-value pair with the key of the processing type extended field extendProcessType and the value of the enumeration value SYSTEM_AUTO is additionally written to the extendedColumns of the extended field mapping object; if the processing result is NULL, the key will not be written to the extendedColumns of the extended field mapping object, completely preventing the automatic judgment module from tampering with the processing type field of the evidence to be manually reviewed.

[0089] S403, Extended Column Writeback Execution, includes: The platform's preset alarm extension field write-back interface updateAlarmExtendColumns is called, passing in a list of alarmIds associated with the current evidence, and the extendedColumns mapping object assembled in step S402, to complete the batch write-back operation of the dynamic extension fields of the business object.

[0090] If the final assembled extendColumns mapping object is empty, record an alarm log directly, skip the call to the extended column write-back interface, and do not perform an invalid empty update operation.

[0091] The complete execution path for evidence with two different judgment results is clearly compared as follows: Complete path for invalid evidence INVALID: Step S302 (tag binding), step S303 (alarm status update), followed by the extended column write-back process from S401 to S403. The final extended column combination commonly includes only extendedProcessType, or both extendedProcessType and extendedVehicleNumber.

[0092] NULL awaiting complete manual evidence path: directly skip the invalid linkage steps of S302 and S303, directly execute the extended column write-back process from S401 to S403, and finally write only the extendedVehicleNumber license plate field, without writing the extendedProcessType field.

[0093] The final consistency strategy for all exceptions is completely unified, and the handling rules for all exception scenarios are as follows: If a single piece of evidence encounters a processing error at any step, only an error log is recorded, and the next piece of evidence in the same batch continues to be processed. The error will not be thrown upwards to the outermost entry point of the message listener, and will not affect the processing of other normal evidence.

[0094] If the extended column write-back step fails, only an error log will be recorded. It will not affect the evidence processing records that have already been persisted, nor will it undo the successfully executed alarm status update and tag binding operations. All historical operations can be traced through the processing records, and there will be no data loss issues.

[0095] In one embodiment, after the original INVALID path step description "the common result is only extendProcessType or a combination of extendProcessType and extendVehicleNumber", the following extended operation logic is added: when the determination result is INVALID, after the S403 extended column write-back step is completed, the interface of the associated manual review task module deployed in the platform is directly called, and the current evidenceId and alarmId are passed in. The manual review task corresponding to the invalid evidence is automatically closed, and no manual intervention is required to perform subsequent review operations on this type of invalid evidence, further reducing the manual handling cost of invalid evidence.

[0096] This disclosure also provides an alarm extended information write-back system, including: The message filtering module is used to receive evidence status change messages and perform pre-filtering on the messages to select valid messages that meet the preset target status and belong to the preset business type. The determination module is used to obtain evidence details based on the valid message, and generate an automatic determination result based on whether there is a file belonging to a predetermined image channel set in the evidence details; The processing record persistence module is used to persistently store the evidence processing records containing the automatic judgment results; The alarm linkage module is used to perform an invalid evidence linkage update operation when the automatic judgment result is invalid, including binding a special tag to the associated business object and updating the alarm status. The tag caching module is used to cache the identifiers of the dedicated tags and supports querying and creating tags when the cache is not hit. The license plate parsing module is used to select the image with the largest channel number value to parse the license plate number when a file belonging to a predetermined image channel set exists. The extended column write-back module is used to assemble extended fields based on the automatic determination result and file information and write them back to the dynamic extended column of the business object.

[0097] This embodiment also provides a storage medium storing a computer program. When the computer program is executed by a processor, it implements the steps of the above-described alarm extended information write-back method.

[0098] Those skilled in the art will understand that implementing all or part of the processes in the above-described alarm extended information write-back method can be accomplished by a computer program instructing related hardware. The program can be stored in a non-volatile computer-readable storage medium. When executed, the program can include the processes of various embodiments of the alarm extended information write-back method. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM).

[0099] The above content is merely an embodiment of the present invention. Commonly known structures and characteristics are not described in detail here. Those skilled in the art are aware of all common technical knowledge in the field prior to the application date or priority date, are aware of all existing technologies in that field, and have the ability to apply conventional experimental methods prior to that date. Those skilled in the art can improve and implement the present invention based on the guidance provided in this application and their own capabilities. Typical well-known structures or operating methods should not be obstacles for those skilled in the art to implement this application. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention, and these should also be considered within the scope of protection of the present invention. These modifications and improvements will not affect the effectiveness of the present invention or the practicality of the patent. The scope of protection claimed in this application should be determined by the content of its claims, and the specific embodiments described in the specification can be used to interpret the content of the claims.

Claims

1. A method for writing back alarm extended information, characterized in that, include: Receive evidence status change messages and perform pre-filtering on the messages to select valid messages that meet the preset target status and belong to the preset business type; Based on the valid message, obtain the evidence details, generate an automatic judgment result based on whether there is a file belonging to a predetermined image channel set in the evidence details, and persistently store the evidence processing record containing the automatic judgment result. When the automatic determination result is invalid, an invalid evidence linkage update operation is performed. The invalid evidence linkage update operation includes binding a special tag to the associated business object and updating the alarm status. Perform an extended column write-back operation, assemble extended fields and write them back to the dynamic extended column of the business object based on the automatic judgment result and the file information in the evidence details.

2. The alarm extended information write-back method according to claim 1, characterized in that, Pre-filtering of messages includes: Parse the evidence status change message and extract the status field and alarm type field; The message is retained only if the value of the status field is equal to the download completed state and the alarm type field belongs to the pre-configured set of violation alarm types; Idempotency verification is performed based on a combination of tenant identifier and evidence identifier. If a corresponding processing record already exists in the database, the message is ignored.

3. The alarm extended information write-back method according to claim 2, characterized in that, The pre-filtering step also includes: initializing the tenant context based on the tenant identifier in the valid message.

4. The alarm extended information write-back method according to claim 1, characterized in that, Based on whether the evidence details contain files belonging to a predetermined image channel set, an automatic determination result is generated, including: From the file list of the evidence details, files whose file type is image and whose channel number belongs to the predetermined image channel set are selected to obtain the judgment module; If the determination module is empty, an automatic determination result indicating invalidity and a type identifier indicating automatic processing by the system are generated. If the determination module is not empty, it generates an automatic determination result indicating that it needs to be manually reviewed and a type identifier indicating that it has not been automatically processed.

5. The alarm extended information write-back method according to claim 1, characterized in that, The invalid evidence linkage update operation also includes: Before binding the dedicated tag, query the local cache or tag management service to obtain the identifier of the dedicated tag; If the dedicated tag does not exist, create the dedicated tag and update the cache; If the tag binding or alarm status update interface call fails, log the error but do not revoke the persisted evidence processing record.

6. The alarm extended information write-back method according to claim 1, characterized in that, Perform extended column write-back operations, including: When the evidence details contain a file belonging to a predetermined image channel set, the image with the largest channel number is selected as the parsing source, and the license plate number is parsed from the image's metadata. Assemble the extended field mapping object: If the parsed license plate number is not empty, write it to the license plate number extended field; write it to the processing type extended field only if the automatic determination result is invalid. Call the extended column update interface to write back the extended field mapping object to the business object; if the extended field mapping object is empty, skip the write-back operation.

7. The alarm extended information write-back method according to claim 6, characterized in that, The extended column write-back operation is performed on evidence that is automatically determined to be invalid or requires manual review. When the automatic determination result is invalid, the extended field mapping object includes a processing type extended field, or includes both a processing type extended field and a license plate number extended field. When the automatic determination result is that manual review is required, the extended field mapping object only includes the license plate number extended field and does not include the processing type extended field.

8. The alarm extended information write-back method according to claim 1, characterized in that, The method adopts a batch message listening mode, and confirms the consumption offset uniformly after the entire batch of messages is processed; if a single message processing error occurs, only the log is recorded and the remaining messages in the same batch are processed, without blocking the confirmation process of the entire batch of messages. If obtaining the evidence details fails, the current evidence processing flow will be terminated, the evidence processing record will not be written, and subsequent linkage updates and extended column write-back operations will not be performed. The evidence processing record serves as the sole data basis for subsequent alarm status updates, tag binding, and extended column write-back; the range of values ​​for the automatic judgment result is limited to invalid or pending manual review; valid values ​​are independently written by the downstream manual review module or AI analysis module.

9. An alarm extended information write-back system, characterized in that, include: The message filtering module is used to receive evidence status change messages and perform pre-filtering on the messages to select valid messages that meet the preset target status and belong to the preset business type. The determination module is used to obtain evidence details based on the valid message, and generate an automatic determination result based on whether there is a file belonging to a predetermined image channel set in the evidence details; The processing record persistence module is used to persistently store the evidence processing records containing the automatic judgment results; The alarm linkage module is used to perform an invalid evidence linkage update operation when the automatic judgment result is invalid, including binding a special tag to the associated business object and updating the alarm status. The tag caching module is used to cache the identifiers of the dedicated tags and supports querying and creating tags when the cache is not hit. The license plate parsing module is used to select the image with the largest channel number value to parse the license plate number when a file belonging to a predetermined image channel set exists. The extended column write-back module is used to assemble extended fields based on the automatic determination result and file information and write them back to the dynamic extended column of the business object.

10. A computer-readable storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements an alarm extended information write-back method as described in any one of claims 1 to 8.

Images