Multi-tenant data pushing method

Abstract

The invention provides a multi-tenant data pushing method, and relates to the technical field of computer software and information, and the method comprises the steps: achieving unified identity authentication through single sign-on, and dynamically distributing a pushing authority based on an authority strategy; defining conversion rules and tasks by utilizing a visual interface of the low-code configuration center, and generating a standardized data packet; and centralized scheduling is carried out in a multi-tenant management and control center, and the stability of the system is guaranteed by combining a current limiting and dynamic retry mechanism. Source system data are collected in real time, and format conversion is completed through a rule engine after grammar, permission and event state verification. And pushing in an asynchronous mode, and recording full-link information including a tracking ID, a timestamp, a data fingerprint and a response state. And when pushing fails, a compensation mechanism is triggered, degradation or retry is carried out according to a preset rule, final consistency of data is ensured, and the reliability and maintainability of the system are improved.

Description

Technical Field

[0001] This application belongs to the field of computer software and information technology, and specifically relates to a multi-tenant data push method. Background Technology

[0002] With the increasing complexity of enterprise information systems, cross-system data integration and push have become crucial for business collaboration, especially in scenarios where multiple systems coexist, such as Human Resource Management (HCM) and Enterprise Resource Planning (ERP). Data needs to flow efficiently and securely between different platforms (such as WeChat Work, Lark, DingTalk, and external OA systems). Traditional data push methods typically rely on hard-coding, requiring developers to write customized code for each data format, push target, and business rule. This results in long development cycles, high maintenance costs, and difficulty in adapting to frequently changing business needs.

[0003] Furthermore, with the widespread adoption of multi-tenant architecture in SaaS platforms, multiple tenants share the same system but need to achieve data isolation and independent management. Existing technologies lack a unified push task scheduling mechanism, making it impossible to achieve tenant-level rate limiting, retries, and access control. At the same time, the data push process generally lacks end-to-end tracing capabilities. Once a push fails or data inconsistency occurs, it is difficult to quickly locate the cause of the problem, creating blind spots in security auditing and failing to meet enterprises' requirements for data compliance and traceability. Summary of the Invention

[0004] This application provides a multi-tenant data push method to solve one of the aforementioned technical problems.

[0005] The technical solution adopted in this application is as follows:

[0006] This application provides a multi-tenant data push method, including:

[0007] The single sign-on function enables unified user identity authentication and dynamically allocates data push permissions based on access control policies.

[0008] In the low-code configuration center, data transformation rules and push tasks are defined through a visual interface, generating standardized data packages;

[0009] In the multi-tenant management center, the data push requests of each subtenant are centrally managed, and push tasks are scheduled based on the rate limiting mechanism and dynamic retry strategy.

[0010] Real-time collection of business data from the source system; verification of the legality of the business data; and conversion of the business data into standardized data packets conforming to the target system format through a rule engine.

[0011] Asynchronous push is used to send standardized data packets to the target system and record end-to-end tracking information, including push timestamps, data fingerprints, and the target system's response status.

[0012] If an anomaly is detected by monitoring the push results, a compensation mechanism is triggered to downgrade the process or re-push the data according to preset rules until the preset reliability threshold is met.

[0013] According to one embodiment of this application, the single sign-on function is implemented in the following ways:

[0014] Use OAuth 2.0 or OpenID Connect protocol to verify user identity through a unified identity authentication server;

[0015] Data push permissions are dynamically assigned based on role or attribute-based permission models to ensure that users can only access data and functions within their authorized scope.

[0016] According to one embodiment of this application, the low-code configuration center is implemented in the following ways:

[0017] It provides a drag-and-drop visual interface, allowing users to generate data transformation rules by selecting predefined templates and configuring parameters;

[0018] An integrated formula engine allows users to customize data mapping logic and save configuration history through versioning management.

[0019] According to one embodiment of this application, the multi-tenant management and control center is implemented in the following ways:

[0020] A rate limiting mechanism is implemented using the token bucket algorithm to prevent system overload in high-concurrency scenarios;

[0021] An exponential backoff algorithm is used to dynamically adjust the retry strategy, and the retry interval is optimized based on the load status of the target system and network latency.

[0022] According to one embodiment of this application, the data verification is implemented in the following ways:

[0023] Syntax validation, based on JSON Schema to verify the validity of the data structure;

[0024] Permission verification checks the permission matching relationship between the data sender and the target system.

[0025] Event verification uses a finite state machine to confirm that a business event is in a pushable state.

[0026] According to one embodiment of this application, the asynchronous push is implemented in the following ways:

[0027] Establish long-lived connections using the HTTP / 2 protocol and employ connection pooling technology to manage communication resources with the target system;

[0028] Each push generates a globally unique tracking ID and records the request header, encrypted request body, target system response status code, and network latency information.

[0029] According to one embodiment of this application, the compensation mechanism is implemented in the following ways:

[0030] Periodically scan push notification records that are incomplete or incomplete to analyze the reasons for any anomalies.

[0031] Perform downgrade processing according to the preset strategy:

[0032] If the target system is unavailable, switch to the backup communication channel;

[0033] If the risk of data loss is high, trigger a full data rollback and re-push;

[0034] Limit the maximum number of retries.

[0035] According to one embodiment of this application, a data storage optimization step is also included:

[0036] Regularly clear historical push notifications that have exceeded a preset time threshold;

[0037] Migrate cold data to low-cost object storage while retaining index mapping tables to ensure query efficiency.

[0038] A second aspect of this application provides a computer-readable storage medium having a program stored thereon that, when executed by a processor, implements the steps described in the method.

[0039] A third aspect of this application provides an electronic device including a memory, a processor, and a program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the method as described.

[0040] Due to the adoption of the above technical solution, the beneficial effects achieved by this application are as follows:

[0041] This application addresses the issues of fragmented permissions and inconsistent authentication in traditional systems. It ensures the legitimacy of user identities and precise control over operational permissions, preventing unauthorized access and unauthorized push notifications, thus improving system security and compliance. It achieves zero-code configuration of data push rules, significantly lowering the technical barrier and enabling non-developers to quickly configure push logic, shortening deployment cycles, and improving system flexibility and maintainability. It also solves the problems of high development costs and slow iteration associated with traditional hard-coding methods. Tenant-level resource isolation and unified scheduling are implemented. This effectively prevents service avalanches caused by excessive system resource consumption by a single tenant in high-concurrency scenarios, improving system stability and resource utilization, and resolving the problem of disordered competition for push tasks in multi-tenant environments. Structured validation and format conversion of data before push are implemented. A three-level validation mechanism (syntax, permissions, and event status) ensures the integrity and business compliance of push data, preventing invalid or erroneous data from entering the target system, thus improving data quality and system robustness. Asynchronous decoupling and full traceability of the push process are achieved. By generating globally unique tracking IDs and employing a double-buffered log writing mechanism, log integrity is ensured under high concurrency, facilitating fault diagnosis and auditing, and resolving the lack of monitoring and auditing capabilities in traditional push methods. Automatic recovery capability is achieved after push failures. Combined with a dynamic retry cycle algorithm and a degradation channel switching strategy, the system significantly improves eventual data consistency assurance capabilities, reduces manual intervention costs, and solves the problems of traditional systems relying on manual intervention and having low recovery efficiency in anomaly handling. Attached Figure Description

[0042] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0043] Figure 1 A flowchart illustrating a multi-tenant data push method provided in an embodiment of this application;

[0044] Figure 2 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0045] Figure label:

[0046] 810, Processor; 820, Communication interface; 830, Memory; 840, Communication bus. Detailed Implementation

[0047] To more clearly illustrate the overall concept of this application, a detailed explanation is provided below with reference to the accompanying drawings.

[0048] Many specific details are set forth in the following description to provide a thorough understanding of this application. However, this application may also be implemented in other ways different from those described herein. Therefore, the scope of protection of this application is not limited to the specific embodiments disclosed below. It should be noted that, unless otherwise specified, the embodiments of this application and the features thereof can be combined with each other.

[0049] In this application, unless otherwise expressly specified and limited, the "above" or "below" of the second feature can mean that the first and second features are in direct contact, or that the first and second features are in indirect contact through an intermediate medium. In the description of this specification, references to terms such as "an embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described can be combined in any suitable manner in one or more embodiments or examples.

[0050] Example 1

[0051] like Figure 1 As shown, a multi-tenant data push method includes:

[0052] The single sign-on feature enables unified user authentication and dynamically assigns data push permissions based on access control policies.

[0053] As mentioned above, by integrating a Single Sign-On (SSO) mechanism, users only need to complete authentication once within the platform to access all authorized business systems or data interfaces, avoiding the cumbersome operations and security risks associated with repeatedly logging into multiple systems. Furthermore, the system dynamically determines whether a user has the authority to initiate or configure data push tasks based on their identity attributes (such as role, organization, and position) and preset access control policies.

[0054] This access control policy not only covers access control for the push function but also includes operation permissions for specific data resources (such as the types of data that can be pushed, the target system scope, and tenant boundaries), ensuring that only users with the corresponding permissions can perform the corresponding operations. Permission allocation and verification are performed in real time before each push task is triggered, possessing dynamic and context-aware capabilities. This effectively prevents security issues such as unauthorized operations and illegal data leakage, providing a trusted identity foundation and security boundary for subsequent data transformation, push scheduling, and other processes.

[0055] For example, in a Human Resources Management System (HCM), the company headquarters and multiple branch offices share the same data push platform. The HR administrator at headquarters needs to push employee onboarding information to WeChat Work, while the HR specialist at a regional branch office can only push attendance change data to Lark.

[0056] When the headquarters administrator logs into the system, the system completes identity authentication through the single sign-on function and automatically grants them configuration and execution permissions for the "Employee Master Data" and "WeChat Work" push channels based on their "Headquarters HR Administrator" role. At this time, the user can create push tasks in the low-code configuration center to synchronize new employee information to WeChat Work.

[0057] When a regional branch HR specialist logs in, the system identifies their "Regional HR Specialist" role and organizational scope, allowing them only to configure data push tasks related to attendance, and limiting the target system to Lark. If the user attempts to configure the push of employee payroll data to WeChat Work, the system will perform a permission check before the task is submitted, determining that they do not have the corresponding data access permissions and target system operation permissions, immediately blocking the operation and displaying a "Permissions Insufficient" message.

[0058] Furthermore, if a user is transferred out of the HR department due to a job adjustment, their role information in the single sign-on system will be updated synchronously, and the system will automatically revoke all their data push permissions. This eliminates the need to adjust permissions one by one in multiple subsystems, achieving centralized and automated permission management.

[0059] It should be noted that, in specific implementation scenarios, in addition to OAuth 2.0 and OpenID Connect, the system can also be compatible with mainstream authentication protocols such as SAML and LDAP, adapting to the IT infrastructure of different enterprises and improving the platform's compatibility and deployment flexibility.

[0060] In specific implementation scenarios, based on the above solutions and the existing Role-Based Access Control (RBAC), further comprehensive permission decisions can be made by combining user attributes (such as department, job level, and geographical location), resource attributes (such as data sensitivity level and tenant type), and environmental attributes (such as access time and IP address), to achieve more granular and intelligent dynamic permission control.

[0061] In specific implementation scenarios, based on the above solution, after the permission verification is passed, the system can automatically anonymize the pushed data according to the user's permission level. For example, ordinary administrators can only push employee names and employee IDs, while senior administrators can push complete personal information, achieving dual control of "permissions + data content".

[0062] In specific implementation scenarios, based on the above solution, all permission allocation, revocation, and modification operations can be recorded in the audit log and associated with subsequent data push behavior. This supports tracing "who performed what push operation, when, and with what permissions" after a security incident, thus meeting compliance audit requirements.

[0063] In specific implementation scenarios, based on the above solutions, in a multi-tenant environment, the access control policy can isolate the data and configuration resources of each tenant by default, allowing only the platform super administrator to perform cross-tenant operations with authorization, preventing data leakage between tenants and enhancing security in a multi-tenant architecture.

[0064] In specific implementation scenarios, based on the above solutions, the system can also provide real-time prompts on the user's current permission scope during the user's configuration of push tasks, and issue early warnings of "target system unavailable" or "no permission to access certain types of data", thereby improving configuration efficiency and user experience.

[0065] In the low-code configuration center, data transformation rules and push tasks are defined through a visual interface, generating standardized data packages.

[0066] As mentioned above, the low-code configuration center provides a unified visual editing environment, allowing users to complete the following core operations through drag-and-drop, selection, and parameter input:

[0067] Define the data source and target system: Select the source of the business data to be pushed (such as employee ledgers, attendance records) and the target receiving system (such as WeChat Work, Lark, external HR system);

[0068] Configure data conversion rules: Through functions such as field mapping, condition judgment, and format conversion, the original data structure of the source system is converted into the standardized format required by the target system;

[0069] Set push trigger conditions: Configure when the task is executed, such as automatically triggering when data is added, modified or deleted, or executing on a scheduled basis;

[0070] Generate standardized data packets: The system automatically generates data structures (such as JSON format) that conform to the target interface specifications based on the configuration, and encapsulates them into pushable standardized data packets to ensure compatibility and consistency.

[0071] This configuration process supports version management, template reuse, and access control. All configuration information is stored in a unified configuration repository, which facilitates subsequent auditing, rollback, and cross-tenant sharing. It is the core support for achieving rapid integration and agile response to business changes.

[0072] For example, in an enterprise human resource management system, a client needs to automatically synchronize "employee onboarding" events to the Lark system they use, in order to generate organizational structure information and notify relevant personnel.

[0073] Traditional methods require developers to write API call code and manually handle field mappings (such as mapping "employee number" to "employee ID" and "department name" to Lark organization ID), which results in long development cycles and is difficult to modify.

[0074] In this solution, after logging into the platform, the business administrator enters the low-code configuration center and completes the configuration through the following steps:

[0075] Select "Employee Master Data" from the list of data sources as the push source;

[0076] Select Lark as the target system;

[0077] In the field mapping area, drag and drop to connect the "Employee Name" field to the "name" field of the Lark interface, and map the "Mobile Number" to the "mobile" field;

[0078] For the "Department" field, select the preset "Department-Lark Organization ID" mapping table to achieve automatic conversion;

[0079] Set the trigger condition to "when the employee's status changes to 'employed'";

[0080] Click "Save and Enable", and the system will automatically generate a push task and monitor data changes in the background.

[0081] When a new employee completes the onboarding process, the system automatically collects data, generates a standardized data package that conforms to the Lark API requirements based on the above configuration, and initiates a push notification. If the Lark API fields change subsequently, the administrator only needs to modify the mapping relationship in the configuration center; no redevelopment is required to complete the adaptation.

[0082] It should be noted that, in specific implementation scenarios, in addition to the above solutions, the system also has a built-in standardized configuration template library for mainstream third-party platforms (such as WeChat Work, DingTalk, SAP, Workday, etc.), which users can directly select and fine-tune, greatly shortening the configuration time and improving deployment efficiency.

[0083] In specific implementation scenarios, based on the above solutions, multiple similar business entities (such as "employee resignation" and "internship conversion") can be inherited and modified based on existing rule templates, supporting batch application configuration and reducing repetitive operations.

[0084] In specific implementation scenarios, based on the above solutions, the system metadata model can be called in real time during the configuration process to automatically identify the source data field type, length, required fields and other attributes, assisting users in completing the correct mapping and avoiding format errors.

[0085] In specific implementation scenarios, based on the above solutions, users can also set up conditional judgment logic of "if...then..." in a visual way (such as "if the employee's job level is 'senior executive', then push to the senior executive dedicated channel") to achieve flexible adaptation to complex business scenarios.

[0086] In specific implementation scenarios, based on the above solutions, for critical push tasks, configuration changes can be set to require approval before taking effect, ensuring the compliance and controllability of high-risk operations.

[0087] In specific implementation scenarios, based on the above solution, all configuration changes can be automatically recorded with version information, allowing users to view historical versions, compare differences, and quickly roll back to a stable version in case of configuration errors, thus ensuring system stability.

[0088] In specific implementation scenarios, based on the above solutions, the visual configuration results can be synchronized to the backend rule engine in real time, supporting dynamic loading and hot updates, ensuring that configuration changes take effect without restarting the service, thus improving system availability.

[0089] In specific implementation scenarios, based on the above solutions, in a multi-tenant environment, the platform can support the sharing of general configuration templates among tenants (such as unified group push specifications), while allowing each tenant to make personalized adjustments within their permissions, balancing standardization and flexibility.

[0090] In the multi-tenant management center, the data push requests of each subtenant are centrally managed, and push tasks are scheduled based on the rate limiting mechanism and dynamic retry strategy.

[0091] As described above, by establishing a multi-tenant management and control center, centralized and strategic management of data push activities from multiple sub-tenants can be achieved. This center, as the core scheduling hub of the entire data push platform, is responsible for receiving, allocating, monitoring, and optimizing push tasks initiated by each tenant, ensuring reasonable allocation of system resources and stable and reliable service.

[0092] During task scheduling, the system introduces a rate limiting mechanism. Based on each tenant's subscription level, historical call frequency, or overall system load, the maximum number of push requests per unit time is dynamically set to prevent a single tenant from exhausting system resources due to high-frequency pushes, thus affecting the service quality of other tenants. Rate limiting strategies can be implemented based on models such as token bucket and leaky bucket, and support configuration by tenant, interface, target system, and other dimensions.

[0093] Meanwhile, the system employs a dynamic retry strategy to handle push failure scenarios. When the target system times out, returns an error code, or experiences a network interruption, the system does not immediately abandon the task. Instead, it determines whether to retry based on preset rules and intelligently adjusts the retry interval. For example, it retryes after a short wait following the initial failure; if there are consecutive failures, the waiting period is gradually extended to avoid a cascading impact on the target system. The retry process is limited by a maximum number of attempts and supports fallback channel switching to ensure the eventual reachability of critical data.

[0094] This mechanism not only improves the robustness of the system in high-concurrency and weak network environments, but also achieves fairness and controllability in resource use among tenants, making it a key technical means to support large-scale SaaS deployment.

[0095] For example, a large corporation uses this platform to centrally manage the push of human resources data to external systems for its 10 subsidiaries (i.e., 10 sub-tenants). Each subsidiary can be configured to push "employee onboarding information" to WeChat.

[0096] During a concentrated recruitment period on a certain day, subsidiary A experienced a large number of push requests due to the influx of new employees; while subsidiaries B and C only had a few employee changes, resulting in a smaller number of requests.

[0097] Without a control mechanism, the high frequency of requests from subsidiary A may exhaust the platform's connection pool or cause the WeChat Work interface to limit traffic, thereby affecting the normal push of other subsidiaries.

[0098] In this solution, the multi-tenant control center pre-sets differentiated rate limiting strategies for each subsidiary:

[0099] Subsidiary A (large unit) is allowed a maximum of 50 push requests per minute;

[0100] Subsidiaries B to J (small and medium-sized units) are allowed a maximum of 20 requests per minute.

[0101] When subsidiary A's requests exceed the threshold, the excess tasks will be temporarily queued and cached, and executed after the token is released in the next time window to avoid impacting the system.

[0102] Meanwhile, during one push notification, a 503 error was returned due to a temporary unavailability of the WeChat Work interface. Instead of directly marking it as failed, the system initiated a dynamic retry strategy:

[0103] After the first failure, wait 30 seconds to try again;

[0104] After the second failure, wait 60 seconds to try again;

[0105] After the third failure, wait 120 seconds to retry (but not exceeding the maximum waiting limit);

[0106] If all three attempts fail, a backup channel will be triggered (e.g., pushing to the Lark message queue), and the administrator will be notified for further action.

[0107] The entire process requires no manual intervention and does not affect the normal scheduling of other tenant tasks, demonstrating the synergistic advantages of centralized control and intelligent scheduling.

[0108] It should be noted that, in specific implementation scenarios, based on the above solution, task priorities can be set according to the tenant's Service Level Agreement (SLA). Tasks of high-priority tenants will be executed first when resources are scarce, thus ensuring the service quality of core customers.

[0109] In specific implementation scenarios, based on the above solutions, the system can automatically adjust the rate limiting thresholds for each tenant according to the overall platform load, the response status of the target system, or the historical success rate, so as to achieve a balance between maximizing resource utilization and stability.

[0110] In specific implementation scenarios, based on the above solution, it is also possible to support allocating a total quota of push tasks to each tenant (such as 100,000 calls per day). If the limit is exceeded, push will be automatically paused or an upgrade prompt will be given, which is convenient for commercial operation and cost control.

[0111] In specific implementation scenarios, multiple preset retry modes (such as "fast retry", "exponential backoff" and "fixed interval") can be provided on the basis of the above solutions. Tenants can choose the applicable strategy according to the importance of their business and support customizing the maximum number of retries and timeout rules.

[0112] In specific implementation scenarios, based on the above solution, when a tenant frequently triggers rate limiting or fails to retry, an alarm notification can be automatically sent to the platform administrator or the tenant's manager, supporting timely intervention to investigate the problem.

[0113] In specific implementation scenarios, based on the above solutions, when traffic is limited or the system is busy, tasks can be pushed into a queue to wait for execution. The system can intelligently sort tasks according to task type (such as "urgent change" or "normal update"), tenant level, or data timeliness to improve the response speed of critical tasks.

[0114] In specific implementation scenarios, based on the above solutions, the control center can generate reports on indicators such as push success rate, average latency, and number of retries for each tenant, which can be used for service evaluation, fault analysis, and optimization decisions.

[0115] In specific implementation scenarios, based on the above solutions, within the scope of permissions, tenant administrators can configure the rate limiting threshold, retry rules and task priorities for their tenants through a visual interface, thereby improving the flexibility and autonomy of use.

[0116] In specific implementation scenarios, historical scheduling data can be used to predict future resource demands based on the above solutions, assisting the platform in making operational decisions such as server expansion and connection pool optimization, thereby improving system scalability.

[0117] The system collects business data from the source system in real time, verifies the legality of the business data, and then uses a rule engine to convert the business data into a standardized data packet that conforms to the format of the target system.

[0118] As mentioned above, firstly, the system uses a listening mechanism or polling method to capture business data change events occurring in the source system (such as human resources system, ERP system, CRM system, etc.) in real time, ensuring the timeliness of data push. The collection scope includes, but is not limited to, data records involved in operations such as adding, modifying, and deleting.

[0119] Secondly, before data enters the push process, multi-level validity checks are performed to ensure that the data to be pushed complies with business logic and system security requirements. The checks include:

[0120] Syntax validity: Checks whether the data structure is complete, whether the field types match, and whether required fields exist;

[0121] Permission validity: Confirm whether the current operator (user or system) has the permission to push this data;

[0122] Business status validity: Verify whether the business process status of the data meets the push prerequisites (e.g., "Logistics information is only allowed to be pushed when the order status is 'paid'").

[0123] Only data that passes all validations can proceed to the next step of processing. Data that fails validation will be intercepted and logged to prevent invalid or illegal data from entering subsequent processes.

[0124] Finally, the rule engine performs format conversion on the valid data. Based on mapping rules, field processing logic, and data structure templates pre-defined in the low-code configuration center, the rule engine dynamically converts the original data structure of the source system into a standardized format (such as JSON, XML, etc.) required by the target system, generating a standardized data package with a unified structure and clear semantics. This process supports various processing methods such as field renaming, value conversion, conditional judgment, and default value filling, ensuring that the output data is fully compatible with the target interface.

[0125] This step automates, standardizes, and controls data processing, and is a key technical step in ensuring push quality and improving system compatibility.

[0126] For example, a company uses this platform to push the "employee conversion" event from its human resources system to the Lark system to automatically create formal employee files.

[0127] When HR changes an employee's "employment status" from "probation" to "permanent" in the human resources system, the system immediately captures the change event and initiates the data processing flow.

[0128] During the data collection phase, the system obtains the employee's complete information, including fields such as name, employee ID, department, position, date of employment, and date of formal employment.

[0129] Upon entering the validity verification phase, the system performs the following checks in sequence:

[0130] Check if the "Probation Date" is empty and if the format is correct (syntax check);

[0131] Verify whether the current user is the HR manager of the employee's department (permission verification);

[0132] Determine whether the employee was previously in a "probationary" state and was not marked as "official" (business status verification).

[0133] If any of the above checks fails (e.g., it is discovered that the employee has already been promoted to a permanent position), the process will be interrupted and a "duplicate push" warning will be recorded.

[0134] If all validations pass, the process proceeds to the format conversion stage. The rule engine uses the preset "Employee Probation → Lark" mapping rules:

[0135] Map the "employee ID" field to the "employee_id" required by the Lark API;

[0136] Convert the "job title" into the standard job level code in Lark's organizational structure;

[0137] Automatically populate the "Job Type" field with the fixed value "Formal Job Entry";

[0138] Organize the JSON structure according to Lark API requirements to generate standardized data packets.

[0139] Finally, the standardized data packet was submitted to the push scheduling module, ready to be sent to the Lark system.

[0140] It should be noted that, in specific implementation scenarios, in addition to real-time monitoring, the system can also support various data acquisition methods such as scheduled batch collection, incremental log retrieval (such as database binlog), and message queue subscription, adapting to the data openness capabilities of different source systems.

[0141] In specific implementation scenarios, based on the above solutions, users can also customize validation rules through a visual interface (such as "salary field must be greater than 0" and "mobile phone number must conform to 11-digit number format"), and support the templated validation rules for reuse by multiple push tasks.

[0142] In specific implementation scenarios, based on the above solution, the verification process can be divided into "pre-emptive lightweight verification" and "post-emptive deep verification". The former is used to quickly intercept obvious errors, while the latter reconfirms data consistency before pushing, thereby improving processing efficiency.

[0143] In specific implementation scenarios, based on the above solutions, different handling strategies can be developed according to the type of verification failure. For example, "warning" errors can be logged only, while "blocking" errors can be terminated. User-defined response actions are also supported.

[0144] In specific implementation scenarios, based on the above solution, when the conversion rules change, the system can dynamically load the new rules without restarting, ensuring that the configuration update takes effect immediately and improving system availability.

[0145] In specific implementation scenarios, the rule engine can also handle complex transformation scenarios such as nested structures, array mapping, and merging of multiple source fields (e.g., merging "registered address" and "current residence address" into a "contact information" object) based on the above solutions, meeting diverse interface requirements.

[0146] In specific implementation scenarios, each conversion operation can be recorded in detail based on the above solution (such as "field A is mapped to field B" and "default value C is filled"), which facilitates subsequent auditing and problem investigation.

[0147] In specific implementation scenarios, based on the above solutions, the system can automatically establish a mapping relationship chain between source fields and target fields, forming a data lineage graph, which supports tracing the data source and processing path of a target field.

[0148] In specific implementation scenarios, based on the above solutions, the system can also identify sensitive fields such as ID card numbers and mobile phone numbers during the conversion process, and automatically perform desensitization processing (such as masking or encryption) according to the permission policy to ensure data security and compliance.

[0149] In specific implementation scenarios, based on the above solutions, if an anomaly occurs during the conversion process, the system can retain a snapshot of the original data and support rollback to the previous stable state to prevent data loss or contamination.

[0150] Asynchronous push is used to send standardized data packets to the target system and record end-to-end tracking information, including push timestamps, data fingerprints, and the target system's response status.

[0151] As described above, after data processing is complete, the system does not directly call the target system interface using a synchronous blocking method. Instead, it submits the generated standardized data packets to a background task queue, where an independent push execution engine asynchronously completes the actual sending at a later time. This approach effectively decouples the data generation and network communication processes, avoiding the blocking of the source system's business processes due to target system response delays or momentary unavailability, thus improving the overall system's response speed and stability.

[0152] Meanwhile, the system establishes a full-link tracing mechanism throughout the entire push process, generating a unique trace ID for each push task and continuously recording execution information of key nodes to form a complete call chain view. The recorded trace information includes at least:

[0153] Push timestamp: Accurately records the time points of each stage of a task, such as entering the queue, starting execution, actually sending, and receiving a response, for analysis and handling of delays;

[0154] Data fingerprinting: Generates a unique hash value or digest information based on standardized data packet content, used to verify data integrity and identify duplicate pushes or content tampering;

[0155] Target system response status: Capture the HTTP status code, response body, error message, etc. returned by the target system to determine whether the push result was successful.

[0156] This tracking information is stored in conjunction with push task logs, user operation logs, etc., and supports quick retrieval and backtracking by conditions such as task ID, data fingerprint, and time range, providing data support for fault diagnosis, performance optimization, and compliance auditing.

[0157] For example, a company uses this platform to push employee resignation information to WeChat for automatic account deactivation and notification to department heads.

[0158] Once an employee completes the resignation approval process in the HR system, the system generates a standardized data packet and adds it to the push queue. At this point, HR users can immediately return to the interface to continue other tasks without waiting for the push to complete—this demonstrates the advantage of asynchronous push notifications: business processes are unaffected by network communication.

[0159] Upon receiving a task, the background push engine immediately records the entire tracking information for that push notification:

[0160] Generate a unique trace ID: trace-20250405-hr-00123;

[0161] Record the "Task Entry Time" as 10:00:05, the "Start Execution Time" as 10:00:08, and the "Request Sending Time" as 10:00:09;

[0162] Data fingerprints (such as SHA-256 digests) are generated based on the data packet content, with values ​​a1 b2c3d4...;

[0163] A call was made to the WeChat Work API, and a response was received after 5 seconds. The "response arrival time" was recorded as 10:00:14, the HTTP status code was 200, and the response body was {"result":"success"}.

[0164] If it is subsequently discovered that an employee's WeChat Work account was not deactivated in a timely manner, the administrator can check the push record for this event using the tracking ID or employee ID to confirm:

[0165] Is the data packet content correct (by comparing data fingerprints)?

[0166] Check if the message was successfully sent (check the response status);

[0167] Which stage has a delay (analyze the timestamps of each stage)?

[0168] If a 503 response status is found, a retry mechanism can be used for compensation to ensure eventual consistency.

[0169] It should be noted that, in specific implementation scenarios, based on the above solution, priority queues can be set for tasks of different business types (such as "employee onboarding" as high priority and "batch update" as low priority) to ensure that critical data is processed first and improve service quality.

[0170] In specific implementation scenarios, based on the above solutions, a task execution status dashboard can be provided in the management console to display the stage of the task (such as "pending execution", "sending", "successful"), supporting tenant administrators to monitor the push progress in real time.

[0171] In specific implementation scenarios, based on the above solutions, the system can also identify tasks with the same data fingerprint to prevent the target system from processing repeatedly due to repeated event triggering, thus ensuring data idempotency.

[0172] In specific implementation scenarios, based on the above solutions, tracking logs can be centrally stored using a distributed log system, supporting high-concurrency writing and massive data retention, facilitating long-term archiving and big data analysis.

[0173] In specific implementation scenarios, based on the above solution, when the average delay of a certain type of push task exceeds the threshold or the failure rate suddenly increases, the system can automatically trigger an alarm notification to prompt maintenance personnel to intervene and investigate.

[0174] In specific implementation scenarios, based on the above solutions, if the target system also has tracking capabilities, the tracking ID of this platform can be transmitted to the downstream system to achieve end-to-end cross-platform connectivity and build an enterprise-level observability system.

[0175] In specific implementation scenarios, based on the above solutions, the system can automatically perform anonymization processing on tracking logs containing sensitive fields (such as ID card numbers and salaries) before storage to ensure the security and compliance of audit data.

[0176] In specific implementation scenarios, based on the above solutions, it is also possible to statistically analyze indicators such as the overall success rate, average time consumption, and failure reason distribution of a certain type of business (such as "onboarding push"), which can be used for service optimization and SLA evaluation.

[0177] In specific implementation scenarios, based on the above solutions, when the tracking logs show that a certain task has failed continuously, polling compensation or degradation channel switching can be automatically triggered to improve the system's self-healing capabilities.

[0178] In specific implementation scenarios, based on the above solutions, third-party auditing systems can also obtain push link details through standard interfaces to meet internal and external compliance review requirements.

[0179] If an anomaly is detected by monitoring the push results, a compensation mechanism is triggered to downgrade the process or re-push the data according to preset rules until the preset reliability threshold is met.

[0180] As mentioned above, after the standardized data packet is asynchronously pushed, the system continuously monitors the push result in real time and determines whether the push was successful by analyzing the target system's response status, network communication results, and task execution logs.

[0181] When an anomaly is detected (such as the target system returning an error code, connection timeout, response timeout, data verification failure, etc.), the system automatically triggers a compensation mechanism, initiating the recovery process without manual intervention. This compensation mechanism is not a simple retry, but rather intelligently selects a recovery path based on preset policy rules:

[0182] Retransmission: For temporary failures (such as network jitter or instantaneous overload of the target system), the system performs a limited number of retransmissions according to a dynamic retry strategy. The interval between each retry can increase with the number of failures (such as exponential backoff) to avoid causing continuous impact on the target system.

[0183] Degradation handling: For severe or persistent failures (such as the target system being unavailable for an extended period of time), the system can switch to a backup channel or perform degradation operations through a simplified process, such as writing data to a local cache queue, transferring it to a message middleware, or pushing it to a backup notification channel (such as SMS or email), to ensure that critical information is not lost.

[0184] The compensation process continues until a "preset reliability threshold" is met. This threshold can be defined in various forms, such as:

[0185] Confirmation receipt successfully delivered to the target system;

[0186] The data is stably stored in the backup channel and marked as "pending recovery";

[0187] After N consecutive retries, the application will be entered into the manual review queue.

[0188] Or the maximum number of retries has been reached and the downgrade channel has been enabled.

[0189] Through this mechanism, the system can maintain the reliable flow of core business data even when faced with unstable external dependencies, significantly improving the overall service's fault tolerance and robustness.

[0190] For example, a company uses this platform to push employee payroll records to an external tax filing system to automatically generate individual income tax filing data.

[0191] During one push notification, the system received a 504 Gateway Timeout error from the target system after sending a request, indicating a communication failure. The monitoring module immediately marked the task as "push failure" and triggered a compensation mechanism.

[0192] The system performs the following actions based on the preset compensation rules for this task:

[0193] First attempt: After waiting 30 seconds, the message was pushed again, but it still timed out.

[0194] Second attempt: After waiting 60 seconds, the target system returned a 503 Service Unavailable error.

[0195] Third time: After waiting 120 seconds, I tried again, but it still failed.

[0196] At this point, the system determines that the preset "maximum number of retries" (3 times) has been reached, but the "reliability threshold" (i.e., data delivery or safe temporary storage must be ensured) has not yet been met.

[0197] The system then initiated a downgrade process: it packaged the salary data along with the original task information, transferred it to the "emergency cache queue," and simultaneously pushed an alarm message to the administrator's workbench: "The tax system is unavailable; salary data has been temporarily stored and is awaiting recovery."

[0198] Simultaneously, the system marks the task status as "Degraded - Pending" and continues to periodically poll the tax system's availability. Once the target system is detected to have returned to normal, the system automatically retrieves the data from the cache queue and re-pushes it, updating the status to "Final Success" upon completion. The entire process requires no manual intervention, ensuring the preservation and recoverability of critical financial data.

[0199] It should be noted that, in specific implementation scenarios, the above solution can be further enhanced by setting different levels of reliability requirements based on business importance. For example, "employee onboarding" requires successful delivery, while "attendance changes" can tolerate a certain delay, and the system dynamically adjusts the strength of the compensation strategy accordingly.

[0200] In specific implementation scenarios, based on the above solutions, the system can automatically identify fault types (such as network problems, interface changes, and authentication failures) based on error codes, response patterns, and historical data, and match the optimal compensation path to improve recovery efficiency.

[0201] In specific implementation scenarios, the platform can also incorporate multiple degradation channel templates (such as local storage, message queue, email notification, and API gateway switching) based on the above solutions. Users can pre-configure the priority order to achieve flexible switching.

[0202] In specific implementation scenarios, based on the above solutions, the complete compensation trajectory of the task can be displayed in the management interface, including the number of retries, the result of each response, the degradation time point, the current status, etc., supporting full lifecycle auditing.

[0203] In specific implementation scenarios, based on the above solutions, when a task enters a degradation process or fails to retry continuously, a tiered alarm (such as an in-site message, SMS, or telephone call) can be automatically triggered to notify relevant personnel to intervene in a timely manner.

[0204] In specific implementation scenarios, in addition to the above solutions, a manual review portal can be provided when automatic compensation fails to resolve the issue. This allows administrators to view the original data, modify the target address, or force a resend, forming a collaborative mechanism of "automatic as the primary method and manual as the secondary method."

[0205] In specific implementation scenarios, based on the above solutions, compensation tasks can be run in an independent execution queue to avoid competing for resources with normal push tasks and prevent abnormal handling from affecting the performance of the main process.

[0206] In specific implementation scenarios, version control of compensation rules can be supported on the basis of the above solutions, which facilitates rollback, comparison and canary release, and improves configuration security.

[0207] In specific implementation scenarios, based on the above solutions, the system can also statistically analyze indicators such as availability and average recovery time of each target system according to the compensation results, which can be used for service level agreement (SLA) evaluation and optimization.

[0208] In specific implementation scenarios, based on the above solutions, if the target system recovers after the downgrade process, the system can proactively initiate a data consistency verification request to ensure that the supplementary data has been correctly received and processed.

[0209] According to one embodiment of this application, the single sign-on function is implemented in the following ways:

[0210] Use OAuth 2.0 or OpenID Connect protocol to verify user identity through a unified identity authentication server;

[0211] Data push permissions are dynamically assigned based on role or attribute-based permission models to ensure that users can only access data and functions within their authorized scope.

[0212] As described above, firstly, the system uses the OAuth 2.0 or OpenID Connect protocol to verify the user's identity through a unified identity authentication server. The system redirects the user's login request to the unified identity authentication server, where the user completes the input of identity credentials (such as username and password, multi-factor authentication, etc.). After successful verification by the authentication server, a token containing the user's identity information is generated and securely returned to the system. The system verifies the validity and signature of this token to confirm the authenticity of the user's identity and complete the login authentication process. This method enables single-time authentication and global login for users across multiple related business systems, avoiding repeated credential input and improving both user experience and security.

[0213] Secondly, data push permissions are dynamically allocated based on a role- or attribute-based permission model. After user authentication, the system dynamically determines the scope of data that the user can access and the functions they can perform based on their role (e.g., administrator, regular user, tenant manager) or attribute (e.g., organization, position, rank) within the unified identity system, combined with preset permission control policies. For example, only users with specific roles may be allowed to configure data push tasks, or users within a certain organization may be restricted to pushing data relevant to their own department. Permission verification is performed in real time when a user initiates configuration or triggers a push operation, ensuring that users can only access data and use functions within their authorized scope, preventing unauthorized operations, and ensuring system and data security.

[0214] According to one embodiment of this application, the low-code configuration center is implemented in the following ways:

[0215] It provides a drag-and-drop visual interface, allowing users to generate data transformation rules by selecting predefined templates and configuring parameters;

[0216] An integrated formula engine allows users to customize data mapping logic and save configuration history through versioning management.

[0217] As mentioned above, a drag-and-drop visual interface is provided, allowing users to drag and drop functional components (such as data sources, field mappings, conditional judgments, target systems, etc.) from the component library to the configuration canvas using the mouse, and establish logical relationships through connections or property panels. The interface includes various pre-built templates suitable for common business scenarios, such as "Employee Onboarding Synchronization" and "Attendance Change Notification," which users can directly select and adjust parameters according to actual needs to quickly generate data transformation rules without writing code. During configuration, users can define push tasks through dropdown selection, field matching, and condition settings. The system provides real-time feedback on the configuration results, improving operational efficiency and accuracy.

[0218] Meanwhile, the low-code configuration center integrates a formula engine, allowing users to input custom expressions in field mappings or conditional statements to implement complex data processing logic. For example, users can set composite conditions such as "if the department is 'Sales Department' and the job level is higher than 'Manager,' then push to the executive channel," or perform calculations on numerical fields and string concatenation through expressions. All configuration content automatically generates version identifiers upon saving, supporting viewing historical configuration versions in chronological order, comparing version differences, and rolling back to any historical stable state, ensuring that the configuration change process is traceable and recoverable.

[0219] According to one embodiment of this application, the multi-tenant management and control center is implemented in the following ways:

[0220] A rate limiting mechanism is implemented using the token bucket algorithm to prevent system overload in high-concurrency scenarios;

[0221] An exponential backoff algorithm is used to dynamically adjust the retry strategy, and the retry interval is optimized based on the load status of the target system and network latency.

[0222] As described above, a rate limiting mechanism is implemented using the token bucket algorithm. Each subtenant is allocated an independent token bucket, and the number of tokens in the bucket represents its available push task quota. The system adds tokens to the bucket at a fixed rate. When a tenant initiates a push request, it needs to obtain the corresponding number of tokens from the bucket. If there are insufficient tokens, the request is rejected or queued. This mechanism effectively controls the task submission frequency of each tenant within a unit of time, preventing one tenant from consuming excessive system resources due to sudden high concurrency requests, thus affecting the services of other tenants and ensuring resource fairness and system stability in a multi-tenant environment.

[0223] Meanwhile, an exponential backoff algorithm is employed to dynamically adjust the retry strategy. When a push task fails to execute due to a target system response failure or network anomaly, the system initiates a retry mechanism and dynamically extends the retry interval based on the number of consecutive failures. For example, after the first failure, a certain base time is waited; after the second failure, the waiting time increases exponentially until the maximum interval threshold is reached. This algorithm intelligently determines the retry timing by combining the target system's load status and network latency, avoiding frequent requests when the target system is still under high load or unavailable, reducing invalid calls, improving the retry success rate, and optimizing overall push efficiency.

[0224] According to one embodiment of this application, the data verification is implemented in the following ways:

[0225] Syntax validation, based on JSON Schema to verify the validity of the data structure;

[0226] Permission verification checks the permission matching relationship between the data sender and the target system.

[0227] Event verification uses a finite state machine to confirm that a business event is in a pushable state.

[0228] As mentioned above, the system first performs syntax validation. Based on a predefined JSON Schema, it verifies the structural validity of the collected business data. This Schema specifies constraints such as the names, types, required fields, value ranges, and nested structures of fields in the data packet. The system compares the data to be pushed item by item against the Schema, checking for issues such as missing fields, incorrect types, format mismatches, or structural anomalies. Only data that conforms to the Schema definition passes syntax validation, ensuring the standardization and parsability of the data format during subsequent processing.

[0229] Secondly, permission verification is performed. Before data is pushed, the system checks the permission matching relationship between the data sender and the target system. This process includes verifying whether the current user or the calling system has the permission to send data to the specified target system, and whether it has authorization to access the pushed data content. The system combines the unified identity authentication result and permission control policy to confirm the legality of the data flow path, prevent unauthorized entities from pushing data to unauthorized systems, and ensure data security and controllable access.

[0230] Finally, event verification is performed. The system uses a finite state machine model to determine the current state of business events and confirm whether they are in a lifecycle stage where push notifications are permitted. The state transitions of each business entity (such as employees, orders, and contracts) are modeled as state machines. The system determines whether the push prerequisites are met based on the current state and the triggering event. For example, the "employee promotion" event is only allowed to be pushed when the employee's status transitions from "probationary" to "probationary". Through the state machine mechanism, the system ensures that only events that conform to the business process logic are processed, avoiding invalid or duplicate pushes and improving the accuracy of data pushes and business compliance.

[0231] The above three types of checks are performed in sequence. Only after all checks pass can the data enter the subsequent conversion and push process. If any check fails, the data is intercepted and logged to ensure that the structure of the pushed data is correct, the permissions are legal, and the status is compliant.

[0232] According to one embodiment of this application, the asynchronous push is implemented in the following ways:

[0233] Establish long-lived connections using the HTTP / 2 protocol and employ connection pooling technology to manage communication resources with the target system;

[0234] Each push generates a globally unique tracking ID and records the request header, encrypted request body, target system response status code, and network latency information.

[0235] As described above, the system establishes a persistent connection with the target system via the HTTP / 2 protocol. Leveraging the multiplexing feature of this protocol, multiple push requests can be transmitted in parallel over a single connection, improving communication efficiency and reducing connection overhead. To enhance resource utilization and response speed, the system employs connection pooling technology for unified management of communication connections with each target system. The connection pool pre-maintains a certain number of active connections. Available connections are retrieved from the pool during push task execution and returned after use, avoiding performance degradation caused by frequent connection establishment and disconnection. Simultaneously, the connection pool supports connection health checks and automatic reconstruction, ensuring the stability of the communication link and adapting to high-concurrency, long-running push scenarios.

[0236] During each push notification execution, the system generates a globally unique tracking ID and binds it to the entire lifecycle of that push notification. This tracking ID is used to identify and connect the various stages of the push notification, supporting subsequent log queries and link tracing. The system also records key information related to this push notification, including: the complete request header content for reconstructing the call context; encrypted request body data to ensure the security of sensitive information in the logs; the response status code returned by the target system to determine whether the push was successful; and network latency information, including the time interval from sending the request to receiving the response, to evaluate communication performance and the target system's processing efficiency.

[0237] The above information, associated with the tracking ID, is persistently stored to form a complete push operation record, providing data support for subsequent monitoring and analysis, troubleshooting, performance optimization, and compliance auditing. In this way, the system achieves asynchronous decoupling while ensuring the traceability of the push process and efficient management of communication resources.

[0238] According to one embodiment of this application, the compensation mechanism is implemented in the following ways:

[0239] Periodically scan push notification records that are incomplete or incomplete to analyze the reasons for any anomalies.

[0240] Perform downgrade processing according to the preset strategy:

[0241] If the target system is unavailable, switch to the backup communication channel;

[0242] If the risk of data loss is high, trigger a full data rollback and re-push;

[0243] Limit the maximum number of retries.

[0244] As described above, the system periodically scans the push record database for push tasks with a status of "incomplete," including those that have "failed to push," are "waiting for retry," or have "timed out and not responded." During the scan, the system reads the end-to-end tracing information for each abnormal record, and automatically analyzes the cause of the anomaly and determines the nature of the fault, such as target system service unavailability, network interruption, data verification failure, or response timeout, by combining the response status code, network latency, error type, and context logs. This provides a basis for decision-making for subsequent compensation actions.

[0245] After identifying the cause of the anomaly, the system performs corresponding degradation processing according to the preset compensation strategy. If the analysis results show that the target system is currently unavailable (e.g., continuously returning 503 or connection timeout), the system switches the original push request to a backup communication channel. For example, it converts data originally pushed via API to be delivered via message queue, file transfer, or email notification, ensuring that critical information can still be transmitted when the main channel fails, thus guaranteeing business continuity.

[0246] If the system determines that the risk of data loss is high, such as when core business changes (e.g., employee departures, salary payments) are involved and multiple retries fail, the system will trigger a full data backtracking mechanism. This mechanism retrieves the latest complete state of the data entity from the source system, generates a new push package based on the change timestamp, and re-initiates the push through the original or optimized path to ensure that the target system ultimately obtains complete and accurate data, avoiding data inconsistency due to partial failures.

[0247] Throughout the compensation process, the system strictly limits the maximum number of retries. Each push task is bound to a retry policy upon creation, specifying its maximum allowed number of retries (e.g., 3 or 5). After each retry, the system updates the retry count. Once the preset limit is reached, no new retry requests are initiated to prevent infinite retry loops that waste resources or put pressure on the target system. The final task status will be marked as "Degraded," "Push Successful (Re-push)," or "Push Failed (Retry Limit Reached)," and relevant administrators will be notified for further handling.

[0248] Through the above methods, the compensation mechanism enables automatic identification, intelligent response, and controllable recovery of push anomalies, improving the system's robustness and data reliability in complex network environments and under unstable external dependencies.

[0249] According to one embodiment of this application, a data storage optimization step is also included:

[0250] Regularly clear historical push notifications that have exceeded a preset time threshold;

[0251] Migrate cold data to low-cost object storage while retaining index mapping tables to ensure query efficiency.

[0252] As described above, the system periodically cleans up historical push records, identifying push data that has exceeded its retention period based on preset time thresholds (such as 180 days or 365 days). For records that meet the cleanup criteria, the system archives or deletes them from the main database, freeing up storage space and improving database query performance and operational efficiency, provided that they are no longer involved in business processing, auditing, or compensation tasks. The cleanup process employs a batch processing mechanism to avoid excessive pressure on system resources from a single operation, and records task logs for each cleanup to ensure that the operation is auditable and traceable.

[0253] For historical data that has entered the cold data stage but still needs to be retained for future queries or compliance reviews, the system does not delete it directly. Instead, it migrates it to a low-cost object storage system (such as the archive storage layer in cloud storage services). During the migration process, the original data content is compressed and encrypted before being uploaded to the object storage. At the same time, a lightweight index mapping table is maintained in the main database or a separate metadata management module. This index table contains key query fields, such as push tracking ID, data fingerprint, source system identifier, target system identifier, push time, and status, but does not contain the complete request body or response content.

[0254] When a user or external system initiates a query request for historical push records, the system first performs a quick match using an index mapping table to locate the storage path of the required data in object storage. If a match is successful, the system reads and decrypts the original data from object storage as needed, restoring the complete record and returning it to the querying party. This approach ensures that historical data is searchable and usable while significantly reducing long-term storage costs and achieving hierarchical management and efficient utilization of storage resources.

[0255] Through the above data storage optimization steps, the system balances storage costs, query efficiency, and system performance while meeting data retention compliance requirements, making it suitable for large-scale, long-term data integration platforms.

[0256] A second aspect of this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described in any of the embodiments of the first aspect above.

[0257] Figure 2 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 2 As shown, the electronic device may include: a processor 810, a communication interface 820, a memory 830, and a communication bus 840, wherein the processor 810, the communication interface 820, and the memory 830 communicate with each other via the communication bus 840. The processor 810 may call logical instructions in the memory 830 to execute the method in any of the embodiments of the first aspect described above, the method including:

[0258] The single sign-on function enables unified user identity authentication and dynamically allocates data push permissions based on access control policies.

[0259] In the low-code configuration center, data transformation rules and push tasks are defined through a visual interface, generating standardized data packages;

[0260] In the multi-tenant management center, the data push requests of each subtenant are centrally managed, and push tasks are scheduled based on the rate limiting mechanism and dynamic retry strategy.

[0261] Real-time collection of business data from the source system; verification of the legality of the business data; and conversion of the business data into standardized data packets conforming to the target system format through a rule engine.

[0262] Asynchronous push is used to send standardized data packets to the target system and record end-to-end tracking information, including push timestamps, data fingerprints, and the target system's response status.

[0263] If an anomaly is detected by monitoring the push results, a compensation mechanism is triggered to downgrade the process or re-push the data according to preset rules until the preset reliability threshold is met.

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

[0265] On the other hand, the present invention also provides a computer program product, the computer program product comprising a computer program, the computer program being able to be stored on a non-transitory computer-readable storage medium, and when the computer program is executed by a processor, the computer being able to perform the methods provided by the above methods, the method comprising:

[0266] The single sign-on function enables unified user identity authentication and dynamically allocates data push permissions based on access control policies.

[0267] In the low-code configuration center, data transformation rules and push tasks are defined through a visual interface, generating standardized data packages;

[0268] In the multi-tenant management center, the data push requests of each subtenant are centrally managed, and push tasks are scheduled based on the rate limiting mechanism and dynamic retry strategy.

[0269] Real-time collection of business data from the source system; verification of the legality of the business data; and conversion of the business data into standardized data packets conforming to the target system format through a rule engine.

[0270] Asynchronous push is used to send standardized data packets to the target system and record end-to-end tracking information, including push timestamps, data fingerprints, and the target system's response status.

[0271] If an anomaly is detected by monitoring the push results, a compensation mechanism is triggered to downgrade the process or re-push the data according to preset rules until the preset reliability threshold is met.

[0272] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the cigarette box image recognition method provided by the methods described above, the method comprising:

[0273] The single sign-on function enables unified user identity authentication and dynamically allocates data push permissions based on access control policies.

[0274] In the low-code configuration center, data transformation rules and push tasks are defined through a visual interface, generating standardized data packages;

[0275] In the multi-tenant management center, the data push requests of each subtenant are centrally managed, and push tasks are scheduled based on the rate limiting mechanism and dynamic retry strategy.

[0276] Real-time collection of business data from the source system; verification of the legality of the business data; and conversion of the business data into standardized data packets conforming to the target system format through a rule engine.

[0277] Asynchronous push is used to send standardized data packets to the target system and record end-to-end tracking information, including push timestamps, data fingerprints, and the target system's response status.

[0278] If an anomaly is detected by monitoring the push results, a compensation mechanism is triggered to downgrade the process or re-push the data according to preset rules until the preset reliability threshold is met.

[0279] For any parts not mentioned in this application, existing technologies may be used or referenced.

[0280] The various embodiments in this specification are described in a progressive manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0281] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A multi-tenant data push method, characterized in that, include: The single sign-on function enables unified user identity authentication and dynamically allocates data push permissions based on access control policies. In the low-code configuration center, data transformation rules and push tasks are defined through a visual interface, generating standardized data packages; In the multi-tenant management center, the data push requests of each subtenant are centrally managed, and push tasks are scheduled based on the rate limiting mechanism and dynamic retry strategy. Real-time collection of business data from the source system; verification of the legality of the business data; and conversion of the business data into standardized data packets conforming to the target system format through a rule engine. Asynchronous push is used to send standardized data packets to the target system and record end-to-end tracking information, including push timestamps, data fingerprints, and the target system's response status. If an anomaly is detected by monitoring the push results, a compensation mechanism is triggered to downgrade the process or re-push the data according to preset rules until the preset reliability threshold is met.

2. The method according to claim 1, characterized in that, The single sign-on function is implemented in the following ways: Use OAuth 2.0 or OpenID Connect protocol to verify user identity through a unified identity authentication server; Data push permissions are dynamically assigned based on role or attribute-based permission models to ensure that users can only access data and functions within their authorized scope.

3. The method according to claim 1, characterized in that, The implementation methods of the low-code configuration center include: It provides a drag-and-drop visual interface, allowing users to generate data transformation rules by selecting predefined templates and configuring parameters; An integrated formula engine allows users to customize data mapping logic and save configuration history through versioning management.

4. The method according to claim 1, characterized in that, The implementation methods of the multi-tenant management and control center include: A rate limiting mechanism is implemented using the token bucket algorithm to prevent system overload in high-concurrency scenarios; An exponential backoff algorithm is used to dynamically adjust the retry strategy, and the retry interval is optimized based on the load status of the target system and network latency.

5. The method according to claim 1, characterized in that, The data verification is implemented in the following ways: Syntax validation, based on JSON Schema to verify the validity of the data structure; Permission verification checks the permission matching relationship between the data sender and the target system. Event verification uses a finite state machine to confirm that a business event is in a pushable state.

6. The method according to claim 1, characterized in that, The asynchronous push implementation methods include: Establish long-lived connections using the HTTP / 2 protocol and employ connection pooling technology to manage communication resources with the target system; Each push generates a globally unique tracking ID and records the request header, encrypted request body, target system response status code, and network latency information.

7. The method according to claim 1, characterized in that, The compensation mechanism is implemented in the following ways: Periodically scan push notification records that are incomplete or incomplete to analyze the reasons for any anomalies. Perform downgrade processing according to the preset strategy: If the target system is unavailable, switch to the backup communication channel; If the risk of data loss is high, trigger a full data rollback and re-push; Limit the maximum number of retries.

8. The method according to claim 1, characterized in that, It also includes data storage optimization steps: Regularly clear historical push notifications that have exceeded a preset time threshold; Migrate cold data to low-cost object storage while retaining index mapping tables to ensure query efficiency.

9. A computer-readable storage medium having a program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the method as described in any one of claims 1-8.

10. An electronic device comprising a memory, a processor, and a program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the method as described in any one of claims 1-8.

Images