A database configuration driving-based heterogeneous platform alarm docking and forwarding method

Abstract

The application discloses a kind of based on database configuration drive's heterogeneous platform alarm docking and forwarding method, belong to computer data processing and intelligent monitoring technical field.The method obtains the configuration record of target platform by inquiring database configuration table, judges whether the forwarding link is enabled based on the real-time value of link enable state field, executes dynamic authentication processing to obtain authentication token using the authentication parameter stored in parameterized authentication field when enabling, and based on push address field, alarm data is pushed to corresponding target platform.The application realizes the decoupling of alarm docking logic and code, supports the online hot update of forwarding strategy and link second-level start-stop management and control, solves the problem of high system coupling degree and heterogeneous authentication adaptation difficulty under existing hard coding mode.

Description

Technical Field

[0001] This invention relates to the field of computer data processing and intelligent monitoring technology, specifically to a method for alarm connection and forwarding on heterogeneous platforms based on database configuration-driven approaches. Background Technology

[0002] With the deepening development of smart cities, safe campuses, and enterprise digital transformation, video surveillance and intelligent analytics technologies have been widely applied in various scenarios. Front-end deployed intelligent edge analytics appliances (AI Boxes), with their advantages of performing real-time video stream analysis locally and reducing bandwidth pressure, have become the core source of alarm data. In the actual deployment of video surveillance and intelligent analytics systems, alarm data generated by edge devices (such as smoke, intrusion, and crowd gathering) typically needs to be uniformly accessed through a convergence platform before being forwarded to one or more higher-level headquarters platforms to achieve cross-level coordinated handling and global visualization.

[0003] Due to significant differences in alarm data formats and communication protocols output by intelligent analysis devices from different manufacturers, and the varying alarm data receiving interfaces and authentication methods of different upstream target platforms, a complex interoperability requirement arises between multi-source heterogeneous devices and heterogeneous platforms. In implementing this alarm data link, existing technologies typically employ the following two methods: 1. Hard-coded point-to-point connection mode: Developers directly write fixed connection logic in the backend code of the aggregation platform for specific manufacturer equipment and specific target platform interface specifications, including device protocol parsing rules, target platform interface address, authentication credentials and message format conversion, etc.

[0004] 2. Static configuration file mapping mode: Static configuration files such as XML, JSON, or property files are used to store device access parameters and forwarding target information. The configuration is loaded and the mapping relationship is established when the system starts.

[0005] When faced with real-world application scenarios involving diverse device types, heterogeneous target platform interfaces, and frequent adjustments to forwarding strategies, the aforementioned existing technologies reveal the following significant shortcomings: First, the high coupling between configuration and code leads to high costs for expansion and maintenance. Adding heterogeneous devices from different vendors or changing the target platform interface often requires modifying the source code or static configuration files, necessitating recompilation or even service restart. This tightly coupled model, where "changing one part affects the whole," results in long system response cycles, high deployment risks, and difficulty in adapting to the needs of large-scale, dynamically changing monitoring networks.

[0006] Second, there is a lack of fine-grained dynamic control over forwarding links across multiple heterogeneous platforms. Existing methods struggle to independently enable or disable alarm forwarding links for specific target platforms without restarting the service. When an interface on a target platform malfunctions, if the corresponding forwarding link cannot be severed within seconds, a large amount of alarm data may accumulate on the aggregation platform, potentially leading to thread pool exhaustion and impacting the overall system stability.

[0007] Third, adapting authentication mechanisms across heterogeneous platforms is difficult. Different target platforms have significantly different authentication methods, such as varying token acquisition strategies, signature generation rules, and request header field combinations. Existing methods lack a unified, configuration-driven adaptation mechanism that abstracts authentication credentials and the authentication process in a unified manner. This results in the need to write independent authentication code for each platform, leading to high code redundancy and extremely low efficiency in adapting to heterogeneous authentication.

[0008] Currently, technical personnel mainly address these challenges by increasing the frequency of manual maintenance or manually adjusting configuration files. However, this approach is not only inefficient when dealing with a large number of heterogeneous devices and frequently changing interoperability requirements, but also highly susceptible to operational errors. Therefore, how to construct an efficient alarm interoperability solution that can flexibly define interoperability rules, automatically adapt to multiple platform interfaces, and support dynamic hot updates of forwarding strategies has become a pressing technical problem for those skilled in the art. Summary of the Invention

[0009] The purpose of this invention is to address the technical problems in existing alarm integration systems caused by hard-coding or static configuration methods, such as high coupling, high expansion and maintenance costs, difficulty in adjusting forwarding strategies in real time without service interruption, inability to adapt to differentiated authentication mechanisms of heterogeneous platforms, and lack of fine-grained dynamic control over specific forwarding links. This invention provides a database configuration-driven method for alarm integration and forwarding across heterogeneous platforms. By constructing a standardized database configuration model, this invention abstracts the access parameters, forwarding rules, and authentication credentials of different target platforms into configurable database fields. A dynamic configuration engine is then used to parse these fields in real time to perform automatic token acquisition and dynamic signature calculation, thereby endowing the alarm integration system with online hot update capabilities and non-intrusive, second-level start / stop control capabilities for heterogeneous platform links.

[0010] To achieve the above objectives, this invention provides a database configuration-driven method for alarm integration and forwarding across heterogeneous platforms, comprising: Get the alarm data to be pushed; Query the database configuration table to obtain at least one configuration record of the target platform that matches the alarm data, wherein the configuration record includes a link enable status field, a parameterized authentication field, and a push address field; Based on the real-time value of the link activation status field, determine whether the target platform forwarding link corresponding to the configuration record is enabled; When the forwarding link is determined to be enabled, the authentication parameters stored in the parameterized authentication field of the configuration record are obtained; Dynamic authentication processing is performed using the authentication parameters to obtain the target platform authentication token; Based on the push address field, the alarm data is pushed to the corresponding target platform using the authentication token.

[0011] Furthermore, the link enable status field includes an enable status identifier or a disable status identifier; when the real-time value of the link enable status field is the disable status identifier, the push processing of the corresponding target platform is skipped, and no alarm data push is initiated.

[0012] Furthermore, the parameterized authentication field includes: a signature path subfield for defining the logical path of the signature algorithm, a token address subfield for specifying the token acquisition interface address, and a credential field group for storing static identity credentials; the credential field group includes at least one of key identifier, key, customer identifier, and user identifier.

[0013] Furthermore, the step of performing dynamic authentication processing using the authentication parameters includes: Based on the signature rules defined in the signature path subfield and combined with the key in the authentication parameters, a request signature is dynamically generated. The request signature is assembled into a preset request header field of the authentication request.

[0014] Furthermore, it also includes: Maintain the cache state of the acquired target platform authentication tokens, wherein the cache state includes at least a valid state, a pre-expiration state, and an expired state; When the local cached target platform authentication token is detected to have entered the pre-expiration state, a token refresh request is asynchronously initiated in the background to the address corresponding to the token address subfield, so as to complete the authentication token update without external intervention.

[0015] Furthermore, it also includes: Read the authentication logic identifier from the database configuration table; In response to the authentication logic identifier, the corresponding authentication processing function is matched and loaded from the preset authentication logic library; The authentication parameters are processed using the loaded authentication processing function to adapt to the changes in the authentication protocol of the target platform.

[0016] Furthermore, when multiple configuration records matching the alarm data are obtained, it is determined whether the forwarding link corresponding to each configuration record is enabled. When multiple forwarding links are enabled at the same time, the alarm data is pushed to the target platform corresponding to each enabled forwarding link in parallel.

[0017] Furthermore, the configuration record also includes a message format mapping field; before pushing the alarm data to the corresponding target platform, it also includes: Based on the mapping relationship stored in the message format mapping field, the source fields of the alarm data are converted into the message format required by the target platform.

[0018] Furthermore, the configuration record also includes a deduplication configuration field; before pushing the alarm data to the corresponding target platform, it also includes: Based on the deduplication time window and deduplication key value defined in the deduplication configuration field, multiple alarm data with the same deduplication key value within the deduplication time window are aggregated to reduce redundant pushes to the target platform.

[0019] Furthermore, the configuration record also includes a forwarding priority field; when there are multiple configuration records that match the alarm data, the alarm data of the corresponding target platform is pushed sequentially according to the forwarding priority field of each configuration record in descending order of priority, so as to realize the step-by-step forwarding of multi-level target platforms.

[0020] Furthermore, it also includes: The alarm push feedback information of the target platform is collected in real time, and the feedback information includes at least the response latency and error return code; Calculate the link anomaly frequency weight for the target platform based on the feedback information; When the abnormal frequency weight of the link exceeds a preset threshold, the link enable status field in the configuration record is automatically modified to a disable status flag to suspend alarm push to the corresponding target platform.

[0021] Compared with the prior art, the present invention has the following significant advantages: This invention abstracts and stores the access parameters, forwarding rules, and authentication credentials of different target platforms in a unified manner within fields of a database configuration table, which are then read and parsed in real time by a dynamic configuration engine. When a new platform needs to be added or the configuration information of an existing platform needs to be changed, only the corresponding record in the database needs to be modified for immediate effect, without modifying the source code, recompiling, or restarting the service. This fundamentally solves the shortcomings of long system response cycles and high deployment risks in the hard-coded mode, and significantly reduces the expansion and maintenance costs of large-scale monitoring networks.

[0022] This invention sets a link activation status field in the configuration record. Before pushing data, the system determines whether the corresponding forwarding link is enabled based on the real-time value of this field. When an interface of a target platform malfunctions, maintenance personnel can immediately modify this field in the corresponding configuration record to a disabled status, cutting off the faulty link within seconds without affecting the operation of other normal links. This effectively avoids the cascading risks of alarm data backlog and thread pool exhaustion caused by a single platform failure, ensuring the overall operational stability of the aggregation platform.

[0023] This invention unifies and abstracts the differentiated authentication information of different target platforms, including static credentials such as key identifiers, keys, customer identifiers, and user identifiers, as well as authentication logic parameters such as signature algorithm paths and token acquisition interface addresses, into subfields of a parameterized authentication field. The engine automatically parses and executes token acquisition and dynamic signature calculation. When adding or changing the authentication method for a target platform, adaptation can be completed simply by configuring the corresponding field values ​​in the database, eliminating the need to write separate authentication code for each platform, effectively reducing code redundancy and the complexity of authentication adaptation.

[0024] This invention maintains a three-level cache of the acquired target platform authentication tokens: valid, pre-expiration, and expired. When a token is detected to be in the pre-expiration state, a refresh request is asynchronously initiated in the background to the token acquisition address, completing the token update in advance. This mechanism ensures that the token refresh process is imperceptible to normal push services, avoiding push interruptions caused by token expiration and reducing the frequency of manual intervention.

[0025] This invention sets a message format mapping field and a deduplication configuration field in the configuration record. Before pushing, the source fields of the alarm data are converted into the message format required by the target platform according to the mapping relationship, and duplicate alarms with the same deduplication key value are aggregated within the deduplication time window. This not only adapts to the different requirements of different target platforms for alarm data formats, but also effectively reduces the impact of redundant pushes on the target platform's receiving capacity and network bandwidth.

[0026] This invention supports parallel push to multiple heterogeneous target platforms when matching multiple configuration records from the same source alarm data. Each link independently maintains its own authentication status, achieving one-to-many synchronous distribution. Simultaneously, through a forwarding priority field, it supports hierarchical forwarding to multi-level target platforms in descending priority order, adapting to complex network requirements of multi-level reporting at the national, provincial, municipal, and county levels. Combined with a database-driven architecture, forwarding priority can be adjusted in real time, giving the alarm scheduling system greater flexibility.

[0027] This invention collects push feedback information from the target platform in real time, including response latency and error return codes, and calculates the link anomaly frequency weight based on this. When the weight exceeds a preset threshold, the link enable status field in the corresponding configuration record is automatically changed to a disabled status, and alarm pushes to the target platform are suspended. This closed-loop mechanism upgrades the discovery and isolation of faulty links from passive manual operation to proactive automatic response, further improving the system's intelligent operation and maintenance level. Attached Figure Description

[0028] Figure 1 This is a flowchart of the heterogeneous platform alarm docking and forwarding method of the present invention. Detailed Implementation

[0029] like Figure 1 As shown, this embodiment provides a database configuration-driven method for alarm integration and forwarding across heterogeneous platforms, including: S1: Get the alarm data to be pushed.

[0030] In this step, alarm data originates from front-end intelligent analysis devices deployed in different areas, such as smoke and fire detection alarms, intrusion alarms, and crowd gathering alarms generated by edge-side intelligent analysis all-in-one machines. This alarm data is received uniformly by the aggregation platform and used as input for this method. Because the alarm data formats and communication protocols output by intelligent analysis devices from different manufacturers differ, the aggregation platform can uniformly convert the received alarm data into an internal standardized format for subsequent processing. For example, an alarm field from an all-in-one machine from manufacturer A might be named "alarmType," while an alarm field from manufacturer B might be named "eventType." Both can be uniformly mapped to internal standard fields on the aggregation platform. This unified processing lays the data foundation for subsequent matching and multi-target distribution based on configuration records.

[0031] S2: Query the database configuration table to obtain at least one configuration record of the target platform that matches the alarm data, wherein the configuration record includes a link enable status field, a parameterized authentication field, and a push address field.

[0032] This step is one of the core aspects that distinguishes this invention from existing technologies. The database configuration table (exemplarily referred to as the `alarm_push_config` table in this embodiment) pre-stores the access parameters, authentication credentials, and forwarding policies for different target platforms in the corresponding fields of each configuration record. When alarm data enters the system, the engine queries this configuration table and, based on the alarm type, source region, or other service identifier carried by the alarm data, matches the configuration records of which target platforms the alarm needs to be forwarded to.

[0033] Taking a real-world scenario as an example: In a provincial-level security project, both a facial recognition all-in-one machine from vendor A and a smoke and fire detection all-in-one machine from vendor B are deployed at the front end. The configuration table contains two records corresponding to the "provincial-level video surveillance platform" and the "municipal-level video surveillance platform," respectively. When a smoke and fire alarm is generated, the system automatically matches the corresponding push target. In another scenario, a regular intrusion alarm in a large industrial park project only needs to be pushed to the property management center, corresponding to one configuration record, while a high-risk fire alarm needs to be pushed to both the property management center and the municipal fire safety video surveillance platform, corresponding to two configuration records. This matching logic is entirely driven by the fields in the configuration table, requiring no platform integration logic to be written in the code.

[0034] S3: Based on the real-time value of the link activation status field, determine whether the target platform forwarding link corresponding to the configuration record is enabled.

[0035] The link enable status field is key to achieving fine-grained dynamic control of the forwarding link in this invention. This field is read in real time before each push, rather than being loaded all at once when the system starts. When the real-time value of this field is an enable status indicator, the system continues to execute subsequent authentication and push steps; when the real-time value is a disable status indicator, the system directly skips the corresponding target platform and does not initiate any push processing.

[0036] Taking a major event emergency response scenario as an example: During the event, it is necessary to temporarily push alarms from a certain area to a temporary command center in real time. Operations personnel only need to add a record to the configuration table pointing to the temporary command center's push address and set the link activation status field of that record to an activated status flag. The system will immediately begin pushing alarms to the temporary command center. After the event ends, changing this field to a deactivated status flag will immediately stop the system from pushing alarms. The entire process requires no downtime or service restart, achieving dynamic scheduling of the alarm forwarding link.

[0037] S4: When the forwarding link is determined to be enabled, obtain the authentication parameters stored in the parameterized authentication field of the configuration record; use the authentication parameters to perform dynamic authentication processing to obtain the target platform authentication token.

[0038] This step achieves unified adaptation to authentication mechanisms across different target platforms by parameterizing authentication fields. In practical applications, the authentication methods of different target platforms vary significantly: some platforms use the OAuth2 protocol, requiring a token to be obtained first and then used to access business interfaces; some platforms use a custom signature mechanism, requiring request parameters to be sorted according to specific rules to generate a signature string and placed in the request header; and some platforms require both a token and a signature to be included. This invention abstracts all these differentiated authentication requirements into fields in a configuration table, which are uniformly parsed and executed by the engine, eliminating the need to write separate authentication code for each target platform.

[0039] As one implementation method, the parameterized authentication fields in this embodiment include: a signature path subfield for defining the logical path of the signature algorithm, a token address subfield for specifying the token acquisition interface address, and a credential field group for storing static identity credentials; the credential field group includes at least one of key identifier, key, customer identifier, and user identifier. Taking an actual configuration as an example, the parameterized authentication fields in the configuration record can store static credentials such as appKey (application key identifier), secretKey (private key), customerCode (customer code), and userCode (user code), while also storing authentication logic parameters such as signaturePath (signature string generation rule path) and getTokenUrl (token acquisition address).

[0040] As one implementation method, the dynamic authentication process performed using the authentication parameters in this embodiment includes: dynamically generating a request signature based on the signature rules defined in the signature path subfield and the key in the authentication parameters; and assembling the request signature into a preset request header field of the authentication request.

[0041] In its implementation, the engine first parses the signature rule definition pointed to by the signature path subfield. This rule defines how the signature string is generated, such as which fields participate in the signature calculation, the concatenation order of the fields, and the selection of the hash algorithm. Then, the engine extracts the corresponding field values ​​from the current request, combines them with the key to perform signature calculation, and generates a dynamic signature string. Finally, the engine assembles this signature string into a specified field in the HTTP request header (such as the X-Signature header or the Authorization header) to complete the authentication of the request. Since both the signature rules and the key are stored in a configuration table, when the target platform upgrades its authentication algorithm or changes its key, only the corresponding fields in the configuration table need to be modified for adaptation; no code modification is required.

[0042] As one implementation method, this embodiment also includes: maintaining the cache state of the acquired target platform authentication token, the cache state including at least a valid state, a pre-expiration state, and an expired state; when the target platform authentication token in the local cache is detected to enter the pre-expiration state, a token refresh request is asynchronously initiated in the background to the address corresponding to the token address subfield, so as to complete the authentication token update without external intervention.

[0043] In its implementation, the system maintains an independent token cache for each target platform and records the token acquisition time and validity period. When the system determines that the difference between the current time and the token acquisition time is close to the token's validity period, reaching a preset level of proximity, it marks the token as pre-expiration. At this point, the system does not wait for the current push task but starts an asynchronous thread in the background, automatically sending a token acquisition request to the address specified in the token address subfield, carrying static credentials (such as userCode, passWord, etc.) stored in the configuration table. The returned new token replaces the local cache. This mechanism makes the token refresh process completely invisible to normal push operations, avoiding push interruptions caused by token expiration. Even if the target platform's token validity period is short, the system can maintain the authentication validity of the push link for a long time without human intervention.

[0044] As one implementation method, this embodiment further includes: reading an authentication logic identifier from the database configuration table; responding to the authentication logic identifier, matching and loading a corresponding authentication processing function from a preset authentication logic library; and using the loaded authentication processing function to process the authentication parameters to adapt to the authentication protocol changes of the target platform.

[0045] In practical implementation, when the authentication protocols of certain target platforms are unique and cannot be fully covered by parameter configuration alone—for example, when a password needs to be hashed using a specific algorithm before signing, or when a temporary token and a formal token need to be obtained in two steps—the system can pre-register authentication processing functions for that platform in the authentication logic library. The configuration table only records the authentication logic identifier of the function, and the engine dynamically loads the corresponding processing function based on this identifier at runtime. When the target platform upgrades its authentication protocol, developers only need to add a new processing function and update the identifier in the configuration table; no modification to the main engine code is required. This mechanism, based on the flexibility of parameterized configuration, further ensures a fallback capability for extremely diverse authentication scenarios.

[0046] S5: Based on the push address field, use the authentication token to push the alarm data to the corresponding target platform.

[0047] After completing the authentication process and obtaining the authentication token, the system sends the alarm data to the target platform according to the URL address specified in the push address field. The push request carries the authentication token and related request header information. After the target platform verifies the data, it receives and processes it.

[0048] As one implementation method, in this embodiment, when multiple configuration records matching the alarm data are obtained, it is determined whether the forwarding link corresponding to each configuration record is enabled. When multiple forwarding links are enabled at the same time, the alarm data is pushed to the target platform corresponding to each enabled forwarding link in parallel.

[0049] For example, in a large industrial park project, high-risk fire alarms need to be pushed to both the property management center platform and the municipal fire safety monitoring platform simultaneously. After retrieving configuration records from the configuration table where both links have an "enabled" status field, the system performs independent authentication processing on each record to obtain authentication tokens for their respective target platforms, and then initiates the push in parallel. Each of the two push links independently maintains its authentication status and push results; the failure of one link does not affect the normal push of the other.

[0050] As one implementation method, the configuration record in this embodiment further includes a message format mapping field; before pushing the alarm data to the corresponding target platform, it further includes: converting the source field of the alarm data into the message format required by the target platform according to the mapping relationship stored in the message format mapping field.

[0051] In practical implementations, different target platforms have varying requirements for the naming and structure of alarm data fields. For example, a provincial platform might require the alarm time field to be named "alarmTime" in timestamp format, while a municipal platform might require it to be named "eventTime" in ISO 8601 string format. This invention sets a message format mapping field in the configuration record, storing the mapping relationship between source and target fields in key-value pairs. The engine automatically performs field mapping and format conversion before pushing the data, enabling the same source alarm data to adapt to the message format requirements of different target platforms without requiring conversion logic to be written in the code for each format combination.

[0052] As one implementation method, the configuration record in this embodiment further includes a deduplication configuration field; before pushing the alarm data to the corresponding target platform, it further includes: according to the deduplication time window and deduplication key value defined by the deduplication configuration field, aggregating multiple alarm data with the same deduplication key value within the deduplication time window to reduce redundant push to the target platform.

[0053] In real-world monitoring scenarios, the same event may trigger multiple alarms within a short period. For example, if the same source of smoke is detected in multiple consecutive frames and generates multiple alarms, pushing all of them to the upper-level platform would consume network bandwidth and increase the processing load on the target platform. This invention addresses this by setting a deduplication configuration field in the configuration record, defining a deduplication time window and a deduplication key. The deduplication key can be a combination of device number and alarm type. Before pushing, the system merges multiple alarms with the same deduplication key within the same time window, for example, retaining the first alarm and counting it, or updating the time of the last alarm, and only sending the aggregated result to the target platform, significantly reducing redundant pushes.

[0054] As one implementation method, the configuration record in this embodiment also includes a forwarding priority field; when there are multiple configuration records that match the alarm data, the alarm data of the corresponding target platform is pushed sequentially according to the forwarding priority field of each configuration record in descending order of priority, so as to realize the step-by-step forwarding of multi-level target platforms.

[0055] This implementation method is particularly suitable for network scenarios where multiple levels of management departments report information layer by layer. For example, in a four-level architecture of edge, regional, provincial, and ministerial levels, configuration records can set different forwarding priorities for regional, provincial, and ministerial platforms, respectively. When an alarm is generated, the system pushes it sequentially from highest to lowest priority, first to the regional platform. After the regional platform confirms receipt, it is then pushed to the provincial platform by the aggregation platform, and so on. If a platform fails to push the alarm, a policy can be implemented to decide whether to continue pushing to the next level or to suspend cascading, thereby ensuring the requirement for reporting at each level while avoiding a complete link interruption due to a failure at the first level.

[0056] As one implementation method, this embodiment further includes: real-time collection of alarm push feedback information from the target platform, the feedback information including at least response latency and error return code; calculation of the link anomaly frequency weight for the target platform based on the feedback information; when the link anomaly frequency weight exceeds a preset threshold, automatically modifying the link enable status field in the configuration record to a disable status identifier to pause alarm push to the corresponding target platform.

[0057] In its implementation, the system records the response latency and return code of each alarm push to the target platform. If the return code is a 5xx server error or connection timeout, the push is marked as abnormal. Within a sliding time window, the system calculates the proportion of abnormal pushes to the total number of pushes for each target platform, using this as the link abnormality frequency weight. When this weight exceeds a preset threshold, the system determines that the target platform interface is unstable, automatically changes the link enable status field in the platform's corresponding configuration record from enabled to disabled, and suspends subsequent alarm pushes to that platform. After the target platform interface returns to normal, maintenance personnel can manually restore the field to enabled, or the system will automatically restore it when the abnormality rate drops below the threshold in another monitoring period. This closed-loop mechanism upgrades the discovery and isolation of faulty links from passive manual operation to proactive automatic response, effectively reducing the risk of alarm data loss and system resource consumption caused by prolonged target platform anomalies.

[0058] This embodiment, through the coordinated operation of the above steps, constructs a complete closed loop from alarm data reception to forwarding to multiple target platforms. The above are merely preferred embodiments of the present invention and are not intended to limit the invention. It should be noted that any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

[0059] The above are merely preferred embodiments of the present invention and are not intended to limit the present invention. It should be noted that any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for alarm integration and forwarding on heterogeneous platforms based on database configuration-driven architecture, characterized in that, include: Get the alarm data to be pushed; Query the database configuration table to obtain at least one configuration record of the target platform that matches the alarm data, wherein the configuration record includes a link enable status field, a parameterized authentication field, and a push address field; Based on the real-time value of the link activation status field, determine whether the target platform forwarding link corresponding to the configuration record is enabled; When the forwarding link is determined to be enabled, the authentication parameters stored in the parameterized authentication field of the configuration record are obtained; Dynamic authentication processing is performed using the authentication parameters to obtain the target platform authentication token; Based on the push address field, the alarm data is pushed to the corresponding target platform using the authentication token.

2. The method according to claim 1, characterized in that, The link enable status field includes an enable status identifier or a disable status identifier; when the real-time value of the link enable status field is the disable status identifier, the push processing of the corresponding target platform is skipped and no alarm data push is initiated.

3. The method according to claim 1, characterized in that, The parameterized authentication fields include: a signature path subfield for defining the logical path of the signature algorithm, a token address subfield for specifying the token acquisition interface address, and a credential field group for storing static identity credentials; the credential field group includes at least one of key identifier, key, customer identifier, and user identifier.

4. The method according to claim 3, characterized in that, The process of performing dynamic authentication using the authentication parameters includes: Based on the signature rules defined in the signature path subfield and combined with the key in the authentication parameters, a request signature is dynamically generated. The request signature is assembled into a preset request header field of the authentication request.

5. The method according to claim 3, characterized in that, Also includes: Maintain the cache state of the acquired target platform authentication tokens, wherein the cache state includes at least a valid state, a pre-expiration state, and an expired state; When the local cached target platform authentication token is detected to have entered the pre-expiration state, a token refresh request is asynchronously initiated in the background to the address corresponding to the token address subfield, so as to complete the authentication token update without external intervention.

6. The method according to claim 3, characterized in that, Also includes: Read the authentication logic identifier from the database configuration table; In response to the authentication logic identifier, the corresponding authentication processing function is matched and loaded from the preset authentication logic library; The authentication parameters are processed using the loaded authentication processing function to adapt to the changes in the authentication protocol of the target platform.

7. The method according to claim 1, characterized in that, When multiple configuration records matching the alarm data are obtained, it is determined whether the forwarding link corresponding to each configuration record is enabled. If multiple forwarding links are enabled at the same time, the alarm data is pushed to the target platform corresponding to each enabled forwarding link in parallel.

8. The method according to claim 1, characterized in that, The configuration record also includes a message format mapping field; before pushing the alarm data to the corresponding target platform, it also includes: Based on the mapping relationship stored in the message format mapping field, the source fields of the alarm data are converted into the message format required by the target platform.

9. The method according to claim 1, characterized in that, The configuration record also includes a deduplication configuration field; before pushing the alarm data to the corresponding target platform, it also includes: Based on the deduplication time window and deduplication key value defined in the deduplication configuration field, multiple alarm data with the same deduplication key value within the deduplication time window are aggregated to reduce redundant pushes to the target platform.

10. The method according to any one of claims 1 to 9, characterized in that, Also includes: The alarm push feedback information of the target platform is collected in real time, and the feedback information includes at least the response latency and error return code; Calculate the link anomaly frequency weight for the target platform based on the feedback information; When the abnormal frequency weight of the link exceeds a preset threshold, the link enable status field in the configuration record is automatically modified to a disable status flag to suspend alarm push to the corresponding target platform.

Images