SaaS-based multi-party system data pushing method and system, and storage medium

Abstract

The application provides a multi-party system data pushing method and system based on SaaS, and a storage medium. The method comprises the following steps: obtaining a differentiated pushing rule pre-configured by a target tenant, wherein the differentiated pushing rule comprises a field selection rule, a data filtering rule and a data format conversion rule for a target interface; obtaining original data to be sent to the target tenant, performing field screening on the original data based on the field selection rule to obtain first intermediate data; performing content filtering on the first intermediate data based on the data filtering rule to obtain second intermediate data; performing format conversion on the second intermediate data based on the data format conversion rule to obtain to-be-transmitted data meeting the customized format requirement of the target tenant; and sending the to-be-transmitted data to a receiving system corresponding to the target tenant. The application can safely, efficiently and at low cost push multi-party system data.

Description

Technical Field

[0001] This application relates to the field of data interaction technology, and in particular to a SaaS-based multi-party system data push method, system, and storage medium. Background Technology

[0002] With the increasing prevalence of cloud computing and big data applications, SaaS platforms have become a core hub for data integration and business collaboration for many enterprises. These platforms typically need to push data to multiple external systems, such as different tenants' own business systems and third-party service platforms, to support cross-organizational business processes such as application chain collaboration, financial reconciliation, and marketing analytics. In practice, platforms often need to provide data to multiple recipients through the same data interface.

[0003] Currently, common SaaS platform data push solutions typically employ standardized and uniform processing logic. Specifically, when a platform pushes data through a specific interface, it often sends the exact same data content and format to all recipients. While this one-size-fits-all data push model simplifies the platform's processing logic, it exposes numerous technical problems when dealing with scenarios where different recipients have varying needs regarding data fields, content, and formats. First, regarding data security and compliance, the inability to hide or filter sensitive fields that recipients don't need to know, such as personal information and trade secrets, poses a risk of unauthorized access and data leakage. Second, in terms of data transmission efficiency, uniform push content inevitably includes a large number of redundant fields that are of no value to specific recipients, leading to inefficient use of network bandwidth and low transmission efficiency. Furthermore, for data recipients, the data they receive is often not ready to use out of the box; additional resources are required for secondary filtering, format conversion, and other processing, increasing the processing burden and complexity of the business system. Furthermore, for SaaS platform operators, in order to meet the personalized needs of different recipients, it is usually necessary to develop customized data push modules or interfaces for each recipient, resulting in long development cycles, high maintenance costs, and poor system flexibility and scalability.

[0004] Therefore, the existing technology lacks a technical solution that can efficiently, flexibly and securely customize and push the same data source according to the actual needs of each recipient. This has become a key bottleneck restricting the deep collaboration between SaaS platforms and multiple heterogeneous systems. Summary of the Invention

[0005] In order to enable differentiated data push methods that perform field-level filtering, content-level filtering, and format-level conversion on data pushed through the same interface according to the individual needs of each tenant, and to overcome the technical problems of poor security, low efficiency, heavy processing burden on the recipient, and high adaptation cost of the platform in the existing SaaS platform data push methods, this application provides a SaaS-based multi-party system data push method, system, and storage medium.

[0006] Firstly, this embodiment provides a SaaS-based multi-party system data push method, the method comprising:

[0007] Obtain the pre-configured differentiated push rules for the target tenant, wherein the differentiated push rules include field selection rules, data filtering rules, and data format conversion rules for the target interface;

[0008] Obtain the raw data to be sent to the target tenant, and filter the raw data by field based on the field selection rules to obtain the first intermediate data;

[0009] Based on the data filtering rules, the first intermediate data is filtered to obtain the second intermediate data;

[0010] Based on the data format conversion rules, the second intermediate data is format converted to obtain data to be transmitted that meets the target tenant's customized format requirements;

[0011] The data to be transmitted is sent to the receiving system corresponding to the target tenant.

[0012] In some embodiments, after obtaining the raw data to be sent to the target tenant, the method further includes:

[0013] Obtain the identity authentication information and data access permissions associated with the target tenant and the target interface;

[0014] The receiving system verifies the legitimacy of the target tenant's identity based on the identity authentication information;

[0015] And based on the data access permissions, perform permission verification on the tenant identifier and interface identifier associated with the original data;

[0016] After both the identity verification and the permission verification are passed, the original data is filtered based on the field selection rules to obtain the first intermediate data.

[0017] In some embodiments, the step of filtering the original data based on the field selection rules to obtain the first intermediate data includes:

[0018] Parse the field selection rules to obtain the target field identifier group selected by the target tenant for the target interface;

[0019] Construct or select the corresponding dynamic field extractor based on the target field identifier group;

[0020] The dynamic field extractor is used to traverse the structure of the original data to extract the fields and corresponding data values ​​that match each target field identifier in the target field identifier group to generate the first intermediate data.

[0021] In some embodiments, the step of filtering the first intermediate data based on the data filtering rules to obtain the second intermediate data includes:

[0022] Parse the data filtering rules to obtain at least one filtering condition expression for some or all fields in the target field identifier group;

[0023] Match the conditional execution engine corresponding to the data structure type of the first intermediate data;

[0024] The conditional execution engine is used to convert the filtering condition expression into executable data filtering logic;

[0025] Based on the data filtering logic, each record in the first intermediate data is evaluated and matched to remove records that do not meet the filtering condition expression to obtain the second intermediate data.

[0026] In some embodiments, the step of converting the second intermediate data according to the data format conversion rules to obtain the data to be transmitted that conforms to the target tenant's customized format requirements includes:

[0027] The data format conversion rules are parsed to obtain a format configuration set, wherein the format configuration set includes at least field mapping relationships, outer wrapper label definitions, date format templates, and numerical precision specifications;

[0028] A transformation execution chain matching the data structure of the second intermediate data is generated based on the format configuration set;

[0029] The second intermediate data is input into the transformation execution chain to replace the source field name in the second intermediate data with the target field name based on the field mapping relationship to obtain the mapped data;

[0030] Based on the outer packaging label definition, at least one outer label is added to the mapped data to obtain the packaged data;

[0031] The data to be transmitted is obtained by formatting the field values ​​of the corresponding type in the packaged data based on the date format template and / or the numerical precision specification.

[0032] In some embodiments, sending the data to be transmitted to the receiving system corresponding to the target tenant includes:

[0033] Obtain the transmission security policy and transmission scheduling policy configured for the target tenant, encrypt the data to be transmitted using a hybrid encryption algorithm based on the transmission security policy to obtain encrypted transmission data, and generate a digital authentication credential corresponding to the target tenant.

[0034] The target transmission priority and corresponding transmission queue of the encrypted transmission data are determined based on the transmission scheduling strategy.

[0035] The encrypted transmission data carrying the digital authentication credential is delivered to the sending queue and an abnormal sending task bound to the sending queue is triggered;

[0036] During the execution of the abnormal transmission task, the network status and response status of the target tenant's receiving system are monitored in real time.

[0037] When a network anomaly or response failure is detected, the encrypted transmission data is temporarily stored in an offline cache associated with the target tenant based on a preset retry rule, and the encrypted transmission data is retrieved from the offline cache for interrupted transmission after the network is restored.

[0038] When the receiving system successfully receives and returns a confirmation message, a full-link tracking log containing the sending timestamp, data identifier, and receiving confirmation status is recorded, and the confirmation message is synchronized to the business status record of the target tenant.

[0039] In some embodiments, the process of obtaining the pre-configured differentiated push rules for the target tenant further includes:

[0040] Receive configuration operations submitted by the target tenant through the visual configuration interface, generate differentiated push rules based on the configuration operations, and store them;

[0041] The configuration operation includes selecting a target interface from the receiving list, selecting the required fields from the field list for the target interface to form the field selection rules, configuring logical conditions for filtering data content to form filtering rules, and specifying data encapsulation format, field mapping relationship or data type conversion template to form data format conversion rules.

[0042] In some embodiments, the method further includes:

[0043] After the data to be transmitted is sent to the receiving system corresponding to the target tenant, the data processing status feedback returned by the receiving system is received in real time.

[0044] Based on the data processing status feedback, update the data sending task status corresponding to the target tenant, and generate a visual monitoring report including sending success rate, failure reason analysis and tenant receiving delay statistics.

[0045] When the data processing status feedback includes a data format verification error or content verification failure, an automatic diagnostic process for the differentiated push rules for the target tenant is triggered, and rule optimization suggestions are pushed to the target tenant.

[0046] Secondly, this embodiment provides a SaaS-based multi-party system data push system, which includes: an acquisition module, a processing module, and a push module; wherein,

[0047] The acquisition module is used to acquire the pre-configured differentiated push rules of the target tenant, wherein the differentiated push rules include field selection rules, data filtering rules and data format conversion rules for the target interface;

[0048] The processing module is used to acquire the raw data to be sent to the target tenant, filter the raw data based on the field selection rules to obtain first intermediate data, filter the first intermediate data based on the data filtering rules to obtain second intermediate data, and convert the format of the second intermediate data based on the data format conversion rules to obtain data to be transmitted that meets the customized format requirements of the target tenant.

[0049] The push module is used to send the data to be transmitted to the receiving system corresponding to the target tenant.

[0050] Thirdly, this embodiment provides a computer-readable storage medium storing a computer program that can run on a processor, wherein the computer program, when executed by the processor, implements the SaaS-based multi-party system data push method as described in the first aspect.

[0051] By employing the above method, this application first obtains the pre-configured differentiated push rules of the target tenant. These rules include field selection rules, data filtering rules, and data format conversion rules for the target interface. Then, it obtains the original data to be sent to the target tenant and filters the original data based on the field selection rules to obtain first intermediate data. Based on the data filtering rules, it filters the first intermediate data based on its content to obtain second intermediate data. Based on the data format conversion rules, it converts the format of the second intermediate data to obtain data to be transmitted that meets the customized format requirements of the target tenant. Finally, it sends the data to be transmitted to the receiving system corresponding to the target tenant. This differentiated data push method, capable of performing field-level filtering, content-level filtering, and format-level conversion on data pushed through the same interface according to the personalized needs of each recipient (tenant), overcomes the problems of poor security, low efficiency, heavy processing burden on recipients, and high adaptation costs for the platform in existing SaaS platform data push methods. Attached Figure Description

[0052] Figure 1 This is a flowchart of a SaaS-based multi-party system data push method provided in this application.

[0053] Figure 2 This is a flowchart of a method provided in this application for obtaining first intermediate data by filtering the original data based on field selection rules.

[0054] Figure 3 This is a flowchart of a method provided in this application for obtaining second intermediate data by content filtering of first intermediate data based on data filtering rules.

[0055] Figure 4 This is a flowchart of a method provided in this application for converting the format of second intermediate data based on data format conversion rules to obtain data to be transmitted that meets the customized format requirements of the target tenant.

[0056] Figure 5 This is a schematic diagram of the connection of the SaaS-based multi-party system data push system provided in this application. Detailed Implementation

[0057] To better understand the purpose, technical solutions, and advantages of this application, it has been described and illustrated below with reference to the accompanying drawings and embodiments. However, those skilled in the art should understand that this application can be implemented without these details. It will be apparent to those skilled in the art that various modifications can be made to the embodiments disclosed in this application, and the general principles defined in this application can be applied to other embodiments and application scenarios without departing from the principles and scope of this application. Therefore, this application is not limited to the illustrated embodiments, but is consistent with the broadest scope claimed in this application.

[0058] The embodiments of this application will now be described in further detail with reference to the accompanying drawings.

[0059] Figure 1 This is a flowchart of the SaaS-based multi-party system data push method provided in this application. For example... Figure 1 As shown, the SaaS-based multi-party system data push method includes the following steps:

[0060] Step S100: Obtain the pre-configured differentiated push rules for the target tenant. The differentiated push rules include field selection rules, data filtering rules, and data format conversion rules for the target interface.

[0061] This application describes the process from the push perspective. To achieve differentiated, secure, and efficient push notifications of the same data source to different tenants, the key lies in precisely processing the data according to rules independently defined by each tenant before data push. Specifically, obtaining the pre-configured differentiated push rules of the target tenant involves first configuring interface subscriptions. Specifically, the tenant selects the target interface from the list of available interfaces provided by the SaaS platform to receive data. The system records the subscription relationship between the tenant identifier and the interface identifier and stores it in the permission database, completing the initial binding of interface-level permissions.

[0062] Next, the field selection rules are configured. Specifically, for each subscribed target interface, a list of all data fields that the interface can provide is displayed to the tenant. Tenants use a graphical field selector to independently select the target fields required for their business needs; for example, tenant A selects the order number and amount, while tenant B selects the order number, amount, and shipping address. Based on the selection results, a field selection rule is generated for that tenant for that interface. This rule is essentially a set of identifiers for the fields selected by the tenant. It is used to extract only these fields during subsequent data pushes, automatically filtering out unselected fields. This eliminates redundant data transmission at the source, improves transmission efficiency, and reduces the risk of sensitive information leakage by adhering to the principle of data minimization.

[0063] Next, data filtering rules are configured. Specifically, tenants use a drag-and-drop condition editor to set data content filtering conditions based on the fields selected in the field selection rule configuration process described above. The user-defined natural language or logical conditions are parsed and converted into executable data filtering rules, such as Stream API filtering expressions, SQLWHERE clauses, or XPath expressions. These data filtering rules ensure that only data records that meet the tenant's specific business conditions are pushed, achieving precise control at the data content level and further improving data security and business relevance.

[0064] Finally, data format conversion rules are configured. Specifically, tenants specify the data output format in the visual interface according to the requirements of their receiving system. Specific configuration items include field mapping, outer wrapper label definition, date and time format templates, and numerical precision specifications. Field mapping refers to mapping the field names within the SaaS platform to the field names expected by the tenant system, and outer wrapper definition refers to adding custom root nodes or outer labels to the output data. Saving these configuration items forms the tenant's data format conversion rules, ensuring that the pushed data format can be directly recognized and used by the tenant system, saving the recipient from tedious format conversion work.

[0065] All of the above configuration operations are completed within a unified web-based visual configuration interface, and the configuration results are saved in real time to a rule configuration repository isolated from the tenant. When the SaaS platform needs to push data to a target tenant, it accesses this rule configuration repository to obtain the pre-configured differentiated push rules for the target tenant. These differentiated push rules specifically include various push methods such as HTTP, MQTT, and RabbitMQ. This approach refines access control from the interface level to the field and data content level. Through tenant-configured field selection and data filtering rules, a four-level security boundary is constructed, encompassing tenant, interface, field, and data, minimizing unauthorized data access and reducing the risk of sensitive data leakage. Furthermore, it transforms differentiated requirements that previously required developers to code into self-service tasks that tenants can complete quickly through a visual interface, thereby shortening the onboarding cycle for new tenants or new systems.

[0066] Step S200: Obtain the original data to be sent to the target tenant, and filter the original data by field selection rules to obtain the first intermediate data.

[0067] After obtaining the differentiated push rules for the target tenants, the SaaS platform needs to extract and process the raw information from the corresponding data sources based on these rules. This requires first efficiently, accurately, and scalably obtaining the raw data to be sent to the target tenants. Obtaining the raw data to be sent to the target tenants includes the following steps.

[0068] The first step involves determining the data source identifier and extraction parameters. Specifically, based on the target interface identifier subscribed to by the target tenant, the interface-data source mapping table is queried to determine one or more data source identifiers corresponding to that interface and their access methods. Each data source identifier is associated with a specific data storage location, data structure type, and access credentials. Simultaneously, the push client extracts the target field identifier group selected by the tenant in the field selection rules, which serves as the basis for field filtering in subsequent data extraction.

[0069] The second step involves performing data source adaptation and data extraction. Specifically, for each data source identifier identified in the first step, the corresponding data source adapter is invoked to perform data extraction operations. The data source adapter is a pre-configured component that supports access protocols and query syntax for common database structures, message brokers, and file storage systems. The extraction process includes: for SQL-based data sources, dynamically generating a list of SELECT fields based on the target identifier group, appending tenant-related data partitioning or time range conditions, and executing the query statement; for NoSQL or search engine-based data sources, constructing a projection or source filtering request containing only the target fields; and for message stream data sources, consuming messages from the corresponding topic based on the tenant's subscription start offset or timestamp, and filtering out the required fields in memory in real time. All extraction operations are executed using data access credentials isolated within the local tenant, ensuring that data permissions are controlled during the extraction phase.

[0070] The third step involves data preprocessing and field pre-screening. Specifically, the raw datasets extracted from various data sources may contain redundant fields not specified in the field selection rules. Before data merging, the result sets returned by each data source are pre-screened based on the target field identifier groups in the field selection rules, removing unselected fields and retaining only the fields allowed by the rules and their corresponding values. If the same field has different names in different data sources, it is normalized according to the platform's pre-built field synonym mapping table to ensure consistent field identifiers.

[0071] The fourth step involves assembling multi-source data into a unified raw data object. Specifically, the pre-screened result sets from various data sources are merged and assembled according to the data structure specifications defined in the interface, generating a structured raw data object containing all fields in the target field identifier group. If related data of the same entity exists in different data sources, they are joined using predefined keys or association keys. For scenarios involving the fusion of streaming and batch data, alignment is achieved using time windows or event markers. During the assembly process, the original values ​​of the data are preserved, and content filtering and format conversion are not performed initially to maintain the data's adaptability in subsequent processing stages.

[0072] This approach, through the data source adapter mechanism, allows for seamless integration with various heterogeneous data sources without requiring rewriting the core push logic for new data sources. Simply adding a corresponding adapter supports new data types and storage systems, thus enhancing the flexibility and scalability of data extraction. Furthermore, by dynamically constructing query statements or projection requests based on field selection rules during data source queries, the network and memory overhead associated with fetching all fields from the data source and then filtering them at the application layer is avoided, significantly reducing data transfer volume and extraction time. Additionally, the normalization and assembly of multi-source data ensures that data from different storage systems is delivered to subsequent processing modules in a unified structure, providing standardized input for subsequent filtering and transformation, and improving the stability and maintainability of the processing flow.

[0073] After obtaining the raw data to be sent to the target tenant, to ensure the security and compliance of the data push process, an authorization verification step is also included. That is, after obtaining the raw data to be sent to the target tenant, the following steps are also included:

[0074] Step S201: Obtain the identity authentication information and data access permissions associated with the target tenant and the target interface.

[0075] Step S202: Verify the identity legitimacy of the target tenant's receiving system based on the identity authentication information.

[0076] Step S203 involves verifying the permissions of the tenant identifier and interface identifier associated with the original data based on data access permissions.

[0077] Step S204: After both identity verification and permission verification are passed, the original data is filtered based on the field selection rules to obtain the first intermediate data.

[0078] Specifically, firstly, when a push task is triggered, the push system queries and retrieves the identity authentication information and fine-grained data access permissions associated with the tenant-interface binding from an independent permission center based on the target tenant identifier and the target interface identifier. The identity authentication information refers to API keys, digital certificates, etc. Data access permissions are stored in the form of policies, which at least include the data scope authorized for the tenant and the interface call frequency quota.

[0079] Then, before initiating data transmission to the receiving system, the push system initiates an authentication handshake based on the OAuth 2.0 protocol or two-way certificates. It exchanges credentials with the receiving system, carrying authentication information obtained from the authorization center. The verification process includes verifying the validity of the API key, the issuance chain of the digital certificate, and its validity period. Only when both parties successfully verify each other's identities is a trusted transmission channel established, effectively preventing unauthorized systems from impersonating others and stealing data.

[0080] Next, at the data level, the push system extracts the implicit or explicit source tenant identifier and source interface identifier from the original data object. The source tenant identifier refers to tenant I of the data producer. These two identifiers are then compared and verified against the data scope authorized to the target tenant as queried in step S201. For example, this verifies whether the target tenant has the right to receive data from a specific source tenant, or whether it has the right to obtain a certain type of data through the current interface. This step achieves a secondary verification of the ownership of the data content itself, based on interface permissions.

[0081] Finally, only when the verifications in steps S202 and S203 pass are the push process allowed to enter the core data processing stage. At this point, the original data object is filtered according to the field selection rules to generate the first intermediate data. If any verification fails, the push process is immediately terminated, a security audit log is recorded, and an alarm is triggered.

[0082] This constructs a dual security barrier of identity authentication for the transmission channel and permission verification for data content. It ensures that the recipient of the data is trustworthy and that the data sent is compliant and authorized for viewing by the recipient. This comprehensive verification mechanism, completed at the initial stage of data push and spanning both the communication and data layers, prevents unauthorized data access from the application logic layer to the transmission initialization phase, significantly improving the overall security and reliability of the solution and meeting the compliance audit requirements for cross-border and cross-tenant data flows.

[0083] After verifying identity and permissions, the current push task has a secure and compliant execution foundation. At this point, access to the original data object has been explicitly granted to the target tenant, and the push process enters the core data differentiation processing stage. Next, based on the field selection rules pre-configured by the target tenant, the original data will be finely filtered to generate first intermediate data containing only the fields required by the tenant. Figure 2 This is a flowchart illustrating the method provided in this application for obtaining first intermediate data by filtering original data based on field selection rules. For example... Figure 2 As shown, the process of obtaining the first intermediate data by filtering the original data based on field selection rules includes the following steps:

[0084] Step S205: Parse the field selection rules to obtain the target field identifier group selected by the target tenant for the target interface.

[0085] Step S206: Construct or select the corresponding dynamic field extractor based on the target field identifier group.

[0086] Step S207: Use the dynamic field extractor to traverse the structure of the original data to extract the fields and corresponding data values ​​that match each target field identifier in the target field identifier group to generate the first intermediate data.

[0087] Specifically, firstly, the field selection rules configured by the target tenant for the current target interface are read from the rule configuration library. These rules are stored in a structured form during the configuration phase, such as a JSON array or database record, explicitly listing the set of field identifiers that the tenant can independently select from all available fields of the interface. The built-in rule parser loads and parses this rule, extracting the defined target field identifier group. Each field identifier uses a platform-wide unified naming convention, and this identifier group constitutes a precise field whitelist for subsequent data extraction. This transforms user-level business requirements into identifiable and unambiguous technical instructions, laying the data foundation for subsequent targeted extraction.

[0088] After obtaining the target field identifier group, a matching dynamic field extractor needs to be dynamically constructed or selected from a pre-built extractor factory based on the actual structure type of the original data, such as JSON objects, XML documents, database row records, Avro records, etc. This extractor is a lightweight adapter component whose core logic is designed to focus solely on efficiently locating and extracting the fields and their values ​​specified by the target field identifier group from a specific data structure. For example, for JSON-formatted raw data, the system generates an extractor based on JSONPath or a similar query language; for XML data, it generates an extractor based on XPath; and for relational data structures, the extractor simulates a projection operation containing only the target fields. This decouples the processing logic from the data structure, and through the adapter pattern, allows the same set of field filtering rules to be flexibly applied to various heterogeneous data sources, significantly improving the versatility and scalability of the solution.

[0089] Finally, the original data is used as input and passed to the dynamic field extractor constructed or selected in the previous step for extraction. The extractor traverses the complete structure of the original data, performing precise matching based on each field identifier in the target field identifier group. For successfully matched fields, the extractor retrieves their corresponding data values, collecting them with the field identifier as the key and the data value as the value. Fields that exist in the original data but are not specified in the target field identifier group are ignored and not extracted. This traversal and extraction process is completed efficiently in memory, ultimately generating a new, structured data object, namely the first intermediate data. This data only contains the fields explicitly requested by the tenant; the order and nesting of these fields can be reorganized according to configuration or default rules, but the core content has already achieved field-level purification of the original data.

[0090] This approach, on the one hand, fundamentally prevents the leakage of unauthorized sensitive fields by strictly enforcing a "field whitelist"-based screening system, achieving field-level access control, adhering to the principle of data minimization, and improving data security and compliance. On the other hand, eliminating redundant fields early on the push end significantly reduces the amount of data involved in subsequent serialization, network transmission, and receiver parsing, lowering bandwidth consumption and processing latency, and optimizing data transmission and processing efficiency. Furthermore, the separation of "rule parsing and dynamic extraction" makes the field screening logic independent of the specific data source format. When new data structure types need to be supported, only the extractor factory needs to be extended, without modifying the core rule parsing and processing flow, reducing coupling and maintenance costs, and enhancing flexibility and maintainability.

[0091] Step S300: Based on the data filtering rules, the first intermediate data is filtered to obtain the second intermediate data.

[0092] After completing field-level filtering and generating first intermediate data containing only the target fields, the push process enters the data content filtering stage. Based on the business conditions set by the tenant, data records that meet their specific needs are accurately filtered from the first intermediate data, thereby achieving differentiated push at the data content level and further improving data security and business relevance. Figure 3 This is a flowchart illustrating the method provided in this application for obtaining second intermediate data by content filtering of first intermediate data based on data filtering rules. For example... Figure 3 As shown, the process of obtaining the second intermediate data by filtering the first intermediate data based on data filtering rules includes the following steps:

[0093] Step S301: Parse the data filtering rules to obtain at least one filtering condition expression for some or all fields in the target field identifier group.

[0094] Step S302: Match the conditional execution engine corresponding to the data structure type of the first intermediate data.

[0095] Step S303: Use the conditional execution engine to convert the filter condition expression into executable data filtering logic.

[0096] Step S304: Based on the data filtering logic, each record in the first intermediate data is evaluated and matched to remove records that do not meet the filtering condition expression to obtain the second intermediate data.

[0097] Specifically, firstly, the data filtering rules configured by the target tenant for the current target interface are retrieved from the rule configuration library. These rules are generated during the configuration phase using a visual condition editor and stored in a structured intermediate representation or a declarative script. The intermediate representation can be an Abstract Syntax Tree (AST), and the declarative script can be a JSON structure. The rule parser loads the rule, performs lexical and syntactic analysis, and identifies the field identifiers, logical operators, comparison operators, and constant values ​​referenced in the rule. The parsing process transforms and regularizes the user-configured rules, which may contain natural language descriptions or complex logical combinations, into at least one formalized, unambiguous filter condition expression. Each filter condition expression explicitly specifies the target field it acts on and the numerical or logical relationship it must satisfy. The target field comes from the target field identifier group obtained above. For example, the user-configured region as East China and the order status as paid is parsed into the formalized expression `region=='EastChina' AND order_status=='PAID'`. This transforms the filtering intent of business personnel into precise, computer-processable technical instructions.

[0098] After obtaining the filtering condition expression, the specific data structure type of the first intermediate data is automatically detected, such as whether it is a JSON object array, an XML document node list, an in-memory Java object collection, or a database query result set. A condition execution engine registry is maintained, which registers various execution engine instances optimized for different data structures, such as engines based on JsonPath or JmesPath for JSON data, engines based on XPath or XQuery for XML data, engines based on the Java Stream API or C# LINQ for in-memory collections, and cursor-based iteration-based filtering engines for database result sets. Based on the data structure type of the first intermediate data, the most suitable condition execution engine is quickly searched and matched from the registry. This matching mechanism ensures that the execution environment of the filtering logic is highly compatible with the physical and logical structure of the data, laying the foundation for efficient and accurate data filtering in the future.

[0099] Next, the filtering condition expression parsed in step S301 is submitted to the matching condition execution engine in step S302. Internally, the engine, based on its own technical characteristics and the characteristics of the data structure it processes, compiles or adapts the general filtering condition expression into a data filtering logic that can be directly and efficiently executed in this specific data environment. For example, for a matched JSON Stream API engine, it may convert the filtering condition expression into a series of chained calls to the filter() operator; for a matched SQL result set engine, it may dynamically concatenate the expression into supplementary conditions for the WHERE clause, performing filtering at the database driver level; for a matched XPath engine, it will convert the expression into the corresponding XPath predicate. This conversion process is not only a translation of syntax but may also include performance optimizations, such as precompiling expressions, caching compilation results to avoid repeated parsing, or adjusting the evaluation order based on the data index.

[0100] Finally, the conditional execution engine loads the first intermediate data as the input dataset. It applies the executable data filtering logic generated in step S303, traversing and evaluating each data record in the dataset. During evaluation, the engine extracts the values ​​of corresponding fields from the records according to the filtering logic and compares them with the expected values ​​or ranges defined in the filtering conditions, calculating the result of the entire logical expression—true or false. Records with a true evaluation result are retained; records with a false evaluation result are removed from the currently processed dataset. This process of evaluating and matching records one by one continues until all records have been processed. Finally, the engine outputs a new dataset containing only data records that satisfy all filtering condition expressions—the second intermediate data. This data not only meets the tenant's requirements in terms of field dimensions but also precisely matches the tenant's business filtering conditions in terms of record content.

[0101] This approach, on the one hand, ensures that the pushed data content is strictly limited to the scope required by the business by executing tenant-defined filtering rules, effectively preventing the leakage of irrelevant or unauthorized data. It deepens data security control from the interface and field levels to the data content level, thereby achieving precise and secure data content management. On the other hand, filtering out data records that do not meet the conditions at the push end significantly reduces the amount of data requiring serialization, encryption, network transmission, and subsequent processing by the recipient, lowering load and network bandwidth consumption, thus improving data processing and transmission efficiency. Furthermore, the loosely coupled design of rule parsing, engine matching, and logical transformation allows complex data filtering requirements to be implemented in a configurable manner and flexibly adaptable to various underlying data structures. When the data structure changes or a new filtering engine is added, the core processing flow does not need to be modified, demonstrating good scalability. Moreover, the data pushed to tenants is already ready-to-use and content-filtered, eliminating the need for tenants to invest resources in secondary data cleaning and filtering, thus improving business integration efficiency.

[0102] Step S400: Based on the data format conversion rules, the second intermediate data is format converted to obtain the data to be transmitted that meets the target tenant's customized format requirements.

[0103] After filtering the first intermediate data based on data filtering rules to obtain the second intermediate data, the push process enters the data format conversion stage. In this stage, according to the tenant's pre-defined personalized format requirements, the content-filtered second intermediate data undergoes structural reorganization and value formatting to generate a final data form that can be directly recognized, parsed, and used by the target tenant's receiving system. This achieves out-of-the-box data usability, effectively eliminating the need for secondary format conversion by the recipient. Figure 4 This is a block diagram of a method provided in this application for converting the format of second intermediate data based on data format conversion rules to obtain data to be transmitted that meets the customized format requirements of the target tenant. For example... Figure 4 As shown, the process of converting the second intermediate data to a format that meets the target tenant's customized format requirements, based on data format conversion rules, includes the following steps:

[0104] Step S401: Parse the data format conversion rules to obtain a format configuration set, wherein the format configuration set includes at least field mapping relationships, outer wrapper label definitions, date format templates, and numerical precision specifications.

[0105] Step S402: Generate a transformation execution chain that matches the data structure of the second intermediate data based on the format configuration set.

[0106] Step S403: Input the second intermediate data into the transformation execution chain to replace the source field name in the second intermediate data with the target field name based on the field mapping relationship to obtain the mapped data.

[0107] Step S404: Based on the outer packaging label definition, add at least one outer label to the mapped data to obtain the packaged data.

[0108] Step S405: Format the field values ​​of the corresponding type in the packaged data based on the date format template and / or numerical precision specification to obtain the data to be transmitted.

[0109] Specifically, the system first retrieves the data format conversion rules configured by the target tenant for the current target interface from the rule configuration library. These rules are generated through a visual interface during the configuration phase and persistently stored as a structured configuration object. The rule parser is then invoked to load and parse this configuration object, extracting all defined format customization items to form a complete format configuration set. This set primarily includes the following key configuration items: field mapping relationships, represented as a set of key-value pairs, explicitly defining the mapping between source field names used internally by the SaaS platform and target field names expected by the tenant system; outer wrapper tag definitions, specifying the name, namespace, and attributes of the root node or outer element added to the final output data packet; date format templates, defining the output string format for date and time type fields; and numeric precision specifications, defining the output precision, rounding rules, and thousands separator for numeric type fields. This accurately and unambiguously transforms the tenant's format customization operations on the interface into a set of formatting instructions that can be recognized and executed by a computer program, providing a clear and complete basis for subsequent automated format conversion. Its technical advantage lies in achieving precise translation and instruction of format customization requirements, ensuring that the subsequent conversion process can strictly follow the tenant's personalized requirements, and laying the foundation for generating directly compatible data formats.

[0110] After obtaining the format configuration set, an ordered transformation execution chain is dynamically constructed based on the specific data structure type of the second intermediate data (e.g., a list of JSON objects, a set of XML nodes, a collection of objects in memory), and the transformation requirement types contained in the format configuration set. This transformation execution chain is a processing pipeline composed of multiple lightweight, single-responsibility transformation processors linked in a specific order. A transformation processor factory is maintained, registering various processors such as field mapping processors, outer wrapper processors, date formatting processors, and numeric formatting processors. First, the format configuration set is analyzed to determine the type of transformation to be applied, such as whether field mapping or adding an outer wrapper is required. Then, based on the structure type of the second intermediate data, the corresponding processor instance is selected and instantiated from the factory. For example, for JSON-structured second intermediate data, a processor based on a JSON manipulation library is selected; for XML structures, a processor based on a DOM or streaming XML API is selected. Finally, these processors are assembled into a transformation execution chain according to the logical order from field mapping to adding an outer wrapper to formatting specific type values. This ensures that each transformation step has a clear responsibility and can be independently maintained and replaced. By dynamically assembling the conversion execution chain, the conversion logic and data structure are decoupled, and the conversion steps are pluggable and scalable. When new data formats or a new conversion type need to be supported, only the new processor needs to be registered in the processor factory, without modifying the core conversion flow control logic, which greatly improves flexibility and maintainability.

[0111] Next, the second intermediate data is used as input and injected into the beginning of the transformation execution chain. The field mapping processor in the transformation execution chain is activated first. This processor reads the field mapping relationship configuration items in the format configuration set. Then, it iterates through each data record or each data node in the second intermediate data, and for each field in the record, it checks whether its field name is in the key set of the field mapping relationship. If a mapping relationship exists, the field name is replaced with the corresponding target field name in the field mapping relationship; if no mapping relationship exists, the original field name is retained. This replacement operation is completed at the data object level in memory, without changing the actual content of the data, only modifying its field identifier. After processing, a new data object with the field names updated according to the tenant's requirements is output, called the mapped data. This achieves adaptive normalization of data field names, enabling the data structure from within the SaaS platform to seamlessly adapt to the field naming conventions defined by different tenant systems, eliminating data parsing failures or business logic errors caused by inconsistent field names, and improving the accuracy of data integration and the integration efficiency of the receiving system.

[0112] After the field mapping processor completes its work, the outer wrapper processor in the transformation execution chain continues execution. This processor reads the outer wrapper tag definition configuration items from the format configuration set to obtain information such as the name and attributes of the outer tags to be added. Next, the processor constructs the corresponding wrapping logic based on the final target format of the mapped data, such as XML or JSON. For example, for the target format of XML, the processor creates a new XML document with the tag name specified in the outer wrapper tag definition as the root element and inserts the mapped data as a child node of that root element. The mapped data is typically converted into an XML element or node list. For the target format of JSON, the processor creates a new JSON object, using the tag name specified in the outer wrapper tag definition as the key and the mapped data as its value. If multiple layers of wrapping are configured or namespaces or other attributes need to be added, the processor will construct a more complex document structure accordingly. The data object obtained after this step is called the wrapped data, and its outermost structure strictly conforms to the requirements of the tenant receiving system for data packet encapsulation. This enables personalized customization of data packet structure, meeting the mandatory requirements of downstream systems for data root nodes, namespaces, or specific encapsulation formats. It ensures that the pushed data packets can be correctly identified and parsed by the receiving system at the structural level, avoiding interface call failures caused by packaging format mismatch.

[0113] After the structural packaging is complete, the date formatter and numeric formatter in the transformation execution chain begin their work. The date formatter reads the date format template from the format configuration set, then iterates through the packaged data, identifying all fields marked as date / time types. For each identified date / time field value, the processor converts its internal representation into a string of the specified format according to the date format template. The numeric formatter works similarly, reading the numeric precision specification, iterating through the numeric type fields in the packaged data, and performing rounding, precision control, and adding thousands separators according to the specification, converting the internal numeric objects into strings or numeric representations that conform to the specification. These processes are completed field by field in memory without disrupting the overall data structure. After all formatting processors have completed their execution, the transformation execution chain outputs the final data object, i.e., the data to be transmitted. At this point, the data to be transmitted not only meets the tenant's requirements in terms of field composition and record content, but its field names, overall structure, and representation formats of specific field types are also fully adapted to the target tenant's receiving system. This achieves precise and standardized representation of data values, ensuring the consistency of formats for key business information such as time and amount. It avoids business calculation errors or display anomalies caused by chaotic date formats or differences in numerical precision, allowing the recipient to directly use the data in their business without any additional conversion. This significantly improves the end-to-end availability of data push and the efficiency of business processing.

[0114] This achieves automated and precise conversion from intermediate data to fully customized data to be transmitted. The entire process strictly follows the tenant's predefined format configuration set, and completes field name mapping, structure packaging, and value formatting sequentially through a dynamically assembled conversion execution chain. The final output is data that can be used out of the box by heterogeneous receiving systems, alleviating the problems of format incompatibility and secondary processing required by the receiver in traditional solutions.

[0115] Step S500: Send the data to be transmitted to the receiving system corresponding to the target tenant.

[0116] After converting the second intermediate data according to data format conversion rules to obtain the data to be transmitted, the push process enters the final transmission execution stage. This stage ensures that the customized data to be transmitted can be delivered securely, reliably, and efficiently to the target tenant's receiving system, and achieves monitorability and traceability of the transmission process. Sending the data to be transmitted to the target tenant's corresponding receiving system includes the following steps:

[0117] Step S501: Obtain the transmission security policy and transmission scheduling policy configured for the target tenant, use a hybrid encryption algorithm based on the transmission security policy to encrypt the data to be transmitted to obtain encrypted transmission data, and generate a digital authentication credential corresponding to the target tenant.

[0118] Step S502: Determine the target sending priority and corresponding sending queue for encrypted transmission data based on the transmission scheduling strategy.

[0119] Step S503: Deliver the encrypted transmission data carrying the digital authentication credential to the sending queue and trigger the abnormal sending task bound to the sending queue.

[0120] Step S504: During the execution of the abnormal sending task, monitor the network status and response status of the target tenant's receiving system in real time.

[0121] Step S505: When a network anomaly or response failure is detected, the encrypted transmission data is temporarily stored in the offline cache associated with the target tenant based on the preset retry rules, and the encrypted transmission data is retrieved from the offline cache for interrupted transmission after the network is restored.

[0122] Step S506: When it is detected that the receiving system has successfully received and returned an acknowledgment message, a full-link tracking log containing the sending timestamp, data identifier and receiving acknowledgment status is recorded, and the acknowledgment message is synchronized to the target tenant's business status record.

[0123] Specifically, before initiating a transmission, the system first retrieves the pre-configured transmission security policy and transmission scheduling policy for the target tenant from an independent policy management database, based on the target tenant's identifier. The transmission security policy specifies at least the encryption algorithm combination, key management method, and authentication credential type. In this embodiment, a hybrid encryption algorithm is used for encryption. First, a high-strength symmetric encryption algorithm is used to generate a random session key, which is then used to encrypt the data to be transmitted, resulting in ciphertext data. Subsequently, an asymmetric encryption algorithm, such as RSA-2048, is used to encrypt the aforementioned session key, where the public key comes from the key pair bound to the target tenant. This hybrid encryption algorithm combines the efficiency of symmetric encryption with the secure key distribution advantages of asymmetric encryption, ensuring the confidentiality and integrity of the data during transmission and preventing data from being stolen or tampered with on public networks. Simultaneously, a digital authentication credential is generated according to the transmission security policy. This credential can exist in the form of a Bearer Token based on the OAuth 2.0 protocol or a client digital certificate based on the X.509 standard, embedding information such as the tenant identifier, interface permissions, and validity period, used for authentication during the transmission establishment phase.

[0124] Then, the acquired transmission scheduling strategy is parsed, which defines priority rules corresponding to different business data types. Based on the business type identifier carried in the data to be transmitted, its target transmission priority (e.g., high, medium, low) is automatically matched and determined. The push system maintains transmission queues corresponding to each priority level, such as high-priority queues, medium-priority queues, and low-priority queues. Each transmission queue is associated with independent thread pool resources and flow control parameters. According to the determined target transmission priority, the encrypted transmission data and its metadata, such as the target address and digital authentication credentials, are assembled into a transmission task unit and delivered to the corresponding transmission queue for scheduling execution. This achieves differentiated allocation of transmission resources, ensuring that critical business data can obtain transmission resources first, and optimizing overall transmission efficiency and timeliness.

[0125] Once encrypted transmission data is placed in the sending queue, an asynchronous sending task bound to that queue is immediately triggered. This task runs independently of the main business process and is managed and executed by the corresponding thread pool. The asynchronous sending task first extracts the network endpoint information, digital authentication credentials, and encrypted transmission data from the target receiving system from the task unit. Before formally establishing a connection, the task uses the digital authentication credentials to perform a two-way authentication handshake with the receiving system, such as OAuth 2.0-based token verification or TLS-based two-way certificate authentication. Only after successful authentication is a secure transmission channel, such as an HTTPS connection, established. Subsequently, the task sends the encrypted transmission data and the encrypted session key to the receiving system through this secure channel. The asynchronous sending task mechanism avoids data transmission blocking the main business thread, improving the overall concurrent processing capability and response speed of the SaaS platform.

[0126] The asynchronous transmission task initiates a real-time monitor during transmission. This monitor continuously tracks network connection health metrics between the sender and receiver, such as network latency, packet loss rate, and connection interruption status. Simultaneously, after sending data, the monitor waits for and checks the response from the receiver, including HTTP status codes and agreed-upon acknowledgments. All status information is collected in real-time and temporarily stored in an in-memory status table. This real-time monitoring mechanism provides a basis for subsequent anomaly identification and automatic recovery, enabling the system to detect changes in the transmission environment and the receiver's processing status.

[0127] If the monitor detects a network anomaly or response failure, the transmission task is deemed a failure. In this case, the data is not immediately discarded; instead, it is processed according to the pre-defined retry rules in the transmission scheduling strategy. Upon the first failure or reaching the non-final retry count, the asynchronous transmission task completely saves the encrypted transmission data, encrypted session key, and task metadata to an offline buffer uniquely associated with the target tenant. This offline buffer can be implemented using high-performance, persistent key-value storage, ensuring data isolation between tenants. When the monitor subsequently detects network recovery or reaches the retry waiting time, it retrieves the task data from the offline buffer and triggers a new asynchronous transmission task to resume transmission, achieving breakpoint continuation. If the retry count is exhausted and the transmission still fails, the task is marked as a final failure and an alarm is triggered. This mechanism greatly enhances transmission reliability and effectively addresses network fluctuations and temporary unavailability of the receiving system.

[0128] Finally, once the monitor confirms that the receiving system has successfully received the data and returned the correct confirmation message, the transmission is marked as successful. The asynchronous transmission task generates a full-link tracing log, which includes at least the precise timestamp of the data transmission, a unique data identifier, the target tenant identifier, the interface identifier used, the encrypted digest, and the final reception confirmation status. This log is persistently stored in a dedicated log database or file for auditing and troubleshooting. Simultaneously, the confirmation message returned by the receiving system is extracted and the business status records related to the target tenant and this data transmission within the SaaS platform are updated synchronously. This achieves a closed-loop data transmission process, satisfying compliance requirements for operational traceability and ensuring that the business status reflects the latest data push results in real time, improving the transparency and collaborative efficiency of business processes.

[0129] Preferably, after the data to be transmitted is sent to the receiving system corresponding to the target tenant, a closed-loop monitoring and intelligent feedback process is further executed to ensure that the data is correctly parsed, processed, and ultimately applied to business at the receiving end. This involves receiving data processing status feedback from the receiving system in real time. Based on this feedback, the data transmission task status corresponding to the target tenant is updated, and a visual monitoring report is generated, including transmission success rate, failure cause analysis, and tenant reception delay statistics. When the data processing status feedback includes data format verification errors or content verification failures, an automatic diagnostic process based on differentiated push rules for the target tenant is triggered, and rule optimization suggestions are pushed to the target tenant.

[0130] Specifically, after the receiving system successfully processes the pushed data, it returns a structured confirmation message to the SaaS platform. This message not only contains basic successful reception indicators but can also be extended to include business-level processing results, such as data being stored in the database, verification passing, or specific business processing status codes. The platform's message feedback listening service continuously monitors the feedback interfaces agreed upon with each tenant, asynchronously receiving and parsing these feedback messages. This transforms data push from one-way transmission to two-way interaction, providing direct evidence for evaluating push effectiveness. This establishes an end-to-end confirmation mechanism, enabling the pusher to accurately perceive the final processing status of the data on the receiver, rather than merely remaining at the level of successful network transmission, laying a data foundation for accurate business status synchronization and reliable transmission assurance.

[0131] Upon receiving feedback, the platform immediately updates the status field of the corresponding record in the task status database based on the task identifier in the feedback. Simultaneously, regardless of success or failure, all feedback information, along with previous sending logs, is aggregated and analyzed by the data analysis engine. This engine performs aggregated analysis on all tenants' push tasks at preset intervals: calculating the sending success rate for each tenant and each interface over the past hour; automatically categorizing failed tasks based on error codes or failure reason descriptions in the feedback to create a failure reason distribution map; and calculating the average latency from data transmission to receiving successful feedback. These analysis results are dynamically rendered onto the administrator's visual monitoring dashboard, displaying core indicator trends, failed task rankings, and latency heatmaps for each tenant in chart form. This transforms fragmented feedback data into systematic operational insights, enabling administrators to comprehensively and in real-time grasp the quality of push services, quickly locate abnormal tenants or interfaces, and shift from passively responding to faults to proactively discovering potential risks, significantly improving operational efficiency and system reliability.

[0132] Finally, the platform features a rule diagnostic engine. When the feedback analysis module identifies a failure due to rule-related errors such as mismatched field names, invalid date formats, or values ​​exceeding range, it automatically triggers a diagnostic process for the relevant differentiated push rules for that tenant. The diagnostic engine performs the following operations: **Association and Location:** Based on the failed task identifier, it locates the specific differentiated push rule version used by the task. **Root Cause Analysis:** It compares and analyzes the specific error information in the feedback with the rule content. **Suggestion Generation:** Based on the root cause analysis results, it automatically generates a specific and actionable rule optimization suggestion. **Suggestion Push:** The generated optimization suggestion is instantly pushed to the configuration administrator of the target tenant via the platform's internal message center or email. This achieves an automated closed loop from detecting failures to diagnosing root causes and providing solutions. This significantly lowers the barrier to entry and reduces the troubleshooting time for tenants experiencing integration failures due to improper configuration, improves the service intelligence level and user experience of the SaaS platform, and also reduces customer support costs caused by configuration errors, demonstrating the solution's self-optimization and self-service capabilities.

[0133] Preferably, before obtaining the pre-configured differentiated push rules of the target tenant, the process further includes: receiving configuration operations submitted by the target tenant through a visual configuration interface, generating differentiated push rules based on the configuration operations, and storing them. The configuration operations include selecting a target interface from a received list, selecting required fields from a field list for the target interface to form the field selection rules, configuring logical conditions for filtering data content to form filtering rules, and defining data encapsulation formats, field mapping relationships, or data type conversion templates to form data format conversion rules.

[0134] Specifically, the SaaS platform provides tenants with a unified, web-based visual configuration interface. This interface, designed as a wizard or panel, guides tenants step-by-step through configuring their personalized data push needs. Tenants access this interface by logging into their dedicated account, and all configuration operations are completed within this interface. First, the target interface is selected; the visual configuration interface initially displays a list of all currently available data interfaces currently open on the SaaS platform. The tenant selects one or more target interfaces from this list from which their business system needs to receive data. The subscription relationship between the tenant identifier and the target interface identifier is recorded and stored in the permission database, completing the initial binding of interface-level permissions. Then, field selection rules are formed. For each target interface subscribed to by the tenant, the visual configuration interface dynamically loads and displays a list of all data fields that the interface can provide. A graphical field selector is provided on the interface; tenants can independently select the target fields required by their business from the full field list by checking boxes. Based on the user's selections, a field selection rule for that target interface is automatically generated for the tenant. This rule is essentially a set of identifiers for the target fields selected by the tenant, serving as a whitelist for field filtering during subsequent data pushes. Next, data filtering rules are formed. Based on the selected fields, the visual configuration interface provides a drag-and-drop condition editor. Tenants use this editor to configure logical conditions for filtering data content based on the selected target fields. Users combine conditions by dragging and dropping fields, operators, and input values. The interface parses these user-defined natural language or logical combinations in real time and converts them into structured, executable filtering condition expressions, saving these expressions to form the tenant's data filtering rules. Finally, data format conversion rules are formed. The visual configuration interface provides a format customization panel for tenants to specify the data encapsulation format required by their receiving system. Specific configuration items include: field mapping relationships, where tenants can map source field names within the SaaS platform to target field names expected by their receiving system via dropdown menus or manual input; outer packaging label definitions, where tenants can specify the root node or outer label name and attributes to be added to the final output data packet; and date format templates and numerical precision specifications, where tenants can define the output format of date and time fields and the precision and rounding methods of numerical fields through selection or input. The user's settings on these configuration items are saved as a complete set of format configurations, which is the tenant's data format conversion rules. All the above configuration operations are completed in one stop within the visual configuration interface. After the tenant submits the configuration, the results of the above steps are integrated, namely the field selection rules, data filtering rules, and data format conversion rules—together forming the tenant's complete differentiated push rules for a specific target interface. These rules are stored in a structured form in real time in an isolated rule configuration library associated with the tenant identifier. When data push is required, the pre-configured differentiated push rules are retrieved from this library.This approach transforms the previously SaaS platform-driven, in-depth coding required for personalized data pushes to different tenants into a self-configuration task that tenant administrators can complete quickly through a visual configuration interface. This significantly reduces the platform's adaptation development costs and operational burden, shortening the onboarding cycle for new tenants or systems from days or even weeks to minutes, dramatically improving business agility. Furthermore, the visual configuration interface's field selectors, drag-and-drop condition editor, and format customization panel intuitively and unambiguously translate tenant business requirements into precise, computer-interpretable, and executable technical rules. This accurate translation of business intent into technical instructions provides reliable and clear input for subsequent automated and differentiated data processing, ensuring that the final pushed data accurately matches tenant expectations. Additionally, all configurations are completed and centrally managed within a unified interface, avoiding the cumbersome and error-prone configuration issues caused by tenants switching between different systems or tools, improving the user-friendliness and efficiency of the configuration experience, and facilitating unified rule management and auditing for the platform.

[0135] Figure 5 This is a schematic diagram of the connection of the SaaS-based multi-party system data push system provided in this application. For example... Figure 5 As shown, the SaaS-based multi-party system data push system includes: an acquisition module, a processing module, and a push module.

[0136] The system comprises the following modules: **Acquisition Module:** This module acquires the pre-configured differentiated push rules for the target tenant. These rules include field selection rules, data filtering rules, and data format conversion rules for the target interface. **Processing Module:** This module acquires the raw data to be sent to the target tenant. Based on the field selection rules, it filters the raw data to obtain first intermediate data. Based on the data filtering rules, it filters the first intermediate data to obtain second intermediate data. Based on the data format conversion rules, it converts the second intermediate data to a format that meets the target tenant's customized requirements, resulting in data to be transmitted. **Push Module:** This module sends the data to be transmitted to the target tenant's receiving system.

[0137] The other functions performed by the above-mentioned acquisition module, processing module, and push module, as well as the technical details of each function, are the same or similar to the corresponding features in the SaaS-based multi-party system data push method described above, so they will not be repeated here.

[0138] This application also provides a computer storage medium storing a computer program that, when run on a computer, enables the computer to execute the steps in the SaaS-based multi-party system data push method described above.

[0139] It should be understood that although the steps in the flowcharts in the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order requirement for the execution of these steps, and they can be performed in other orders.

[0140] The above description is only a partial embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for pushing system data based on SaaS, characterized in that, The method includes: Obtain the pre-configured differentiated push rules for the target tenant, wherein the differentiated push rules include field selection rules, data filtering rules, and data format conversion rules for the target interface; Obtain the raw data to be sent to the target tenant, and filter the raw data by field based on the field selection rules to obtain the first intermediate data; Based on the data filtering rules, the first intermediate data is filtered to obtain the second intermediate data; Based on the data format conversion rules, the second intermediate data is format converted to obtain data to be transmitted that meets the target tenant's customized format requirements; The data to be transmitted is sent to the receiving system corresponding to the target tenant; The step of filtering the original data based on the field selection rules to obtain the first intermediate data includes: Parse the field selection rules to obtain the target field identifier group selected by the target tenant for the target interface; Construct or select the corresponding dynamic field extractor based on the target field identifier group; The dynamic field extractor is used to traverse the structure of the original data to extract the fields and corresponding data values ​​that match each target field identifier in the target field identifier group to generate the first intermediate data; The step of filtering the first intermediate data based on the data filtering rules to obtain the second intermediate data includes: Parse the data filtering rules to obtain at least one filtering condition expression for some or all fields in the target field identifier group; Match the conditional execution engine corresponding to the data structure type of the first intermediate data; The conditional execution engine is used to convert the filtering condition expression into executable data filtering logic; Based on the data filtering logic, each record in the first intermediate data is evaluated and matched to remove records that do not meet the filtering condition expression to obtain the second intermediate data; The process of converting the second intermediate data according to the data format conversion rules to obtain the data to be transmitted that meets the target tenant's customized format requirements includes: The data format conversion rules are parsed to obtain a format configuration set, wherein the format configuration set includes at least field mapping relationships, outer wrapper label definitions, date format templates, and numerical precision specifications; A transformation execution chain matching the data structure of the second intermediate data is generated based on the format configuration set; The second intermediate data is input into the transformation execution chain to replace the source field name in the second intermediate data with the target field name based on the field mapping relationship to obtain the mapped data. Based on the outer packaging label definition, at least one outer label is added to the mapped data to obtain the packaged data; The data to be transmitted is obtained by formatting the field values ​​of the corresponding type in the packaged data based on the date format template and / or the numerical precision specification.

2. The method according to claim 1, characterized in that, The process of obtaining the raw data to be sent to the target tenant also includes: Obtain the identity authentication information and data access permissions associated with the target tenant and the target interface; The receiving system verifies the legitimacy of the target tenant's identity based on the identity authentication information; And based on the data access permissions, perform permission verification on the tenant identifier and interface identifier associated with the original data; After both the identity verification and the permission verification are passed, the original data is filtered based on the field selection rules to obtain the first intermediate data.

3. The method according to claim 1, characterized in that, The step of sending the data to be transmitted to the receiving system corresponding to the target tenant includes: Obtain the transmission security policy and transmission scheduling policy configured for the target tenant, encrypt the data to be transmitted using a hybrid encryption algorithm based on the transmission security policy to obtain encrypted transmission data, and generate a digital authentication credential corresponding to the target tenant. The target transmission priority and corresponding transmission queue of the encrypted transmission data are determined based on the transmission scheduling strategy. The encrypted transmission data carrying the digital authentication credential is delivered to the sending queue and an abnormal sending task bound to the sending queue is triggered; During the execution of the abnormal transmission task, the network status and response status of the target tenant's receiving system are monitored in real time. When a network anomaly or response failure is detected, the encrypted transmission data is temporarily stored in an offline cache associated with the target tenant based on a preset retry rule, and the encrypted transmission data is retrieved from the offline cache for interrupted transmission after the network is restored. When the receiving system successfully receives and returns a confirmation message, a full-link tracking log containing the sending timestamp, data identifier, and receiving confirmation status is recorded, and the confirmation message is synchronized to the business status record of the target tenant.

4. The method according to claim 1, characterized in that, Before obtaining the pre-configured differentiated push rules for the target tenant, the following steps are also included: Receive configuration operations submitted by the target tenant through the visual configuration interface, generate differentiated push rules based on the configuration operations, and store them; The configuration operation includes selecting a target interface from the receiving list, selecting the required fields from the field list for the target interface to form the field selection rules, configuring logical conditions for filtering data content to form filtering rules, and specifying data encapsulation format, field mapping relationship or data type conversion template to form data format conversion rules.

5. The method according to claim 1, characterized in that, The method further includes: After the data to be transmitted is sent to the receiving system corresponding to the target tenant, the data processing status feedback returned by the receiving system is received in real time. Based on the data processing status feedback, update the data sending task status corresponding to the target tenant, and generate a visual monitoring report including sending success rate, failure reason analysis and tenant receiving delay statistics. When the data processing status feedback includes a data format verification error or content verification failure, an automatic diagnostic process for the differentiated push rules for the target tenant is triggered, and rule optimization suggestions are pushed to the target tenant.

6. A SaaS-based multi-party system data push system, characterized in that, The system includes: an acquisition module, a processing module, and a push module; The acquisition module is used to acquire the pre-configured differentiated push rules of the target tenant. The differentiated push rules include field selection rules, data filtering rules, and data format conversion rules for the target interface. The processing module is used to acquire the raw data to be sent to the target tenant, filter the raw data based on the field selection rules to obtain first intermediate data, filter the first intermediate data based on the data filtering rules to obtain second intermediate data, and convert the format of the second intermediate data based on the data format conversion rules to obtain data to be transmitted that meets the customized format requirements of the target tenant. The push module is used to send the data to be transmitted to the receiving system corresponding to the target tenant; The step of filtering the original data based on the field selection rules to obtain the first intermediate data includes: Parse the field selection rules to obtain the target field identifier group selected by the target tenant for the target interface; Construct or select the corresponding dynamic field extractor based on the target field identifier group; The dynamic field extractor is used to traverse the structure of the original data to extract the fields and corresponding data values ​​that match each target field identifier in the target field identifier group to generate the first intermediate data; The step of filtering the first intermediate data based on the data filtering rules to obtain the second intermediate data includes: Parse the data filtering rules to obtain at least one filtering condition expression for some or all fields in the target field identifier group; Match the conditional execution engine corresponding to the data structure type of the first intermediate data; The conditional execution engine is used to convert the filtering condition expression into executable data filtering logic; Based on the data filtering logic, each record in the first intermediate data is evaluated and matched to remove records that do not meet the filtering condition expression to obtain the second intermediate data; The process of converting the second intermediate data according to the data format conversion rules to obtain the data to be transmitted that meets the target tenant's customized format requirements includes: The data format conversion rules are parsed to obtain a format configuration set, wherein the format configuration set includes at least field mapping relationships, outer wrapper label definitions, date format templates, and numerical precision specifications; A transformation execution chain matching the data structure of the second intermediate data is generated based on the format configuration set; The second intermediate data is input into the transformation execution chain to replace the source field name in the second intermediate data with the target field name based on the field mapping relationship to obtain the mapped data. Based on the outer packaging label definition, at least one outer label is added to the mapped data to obtain the packaged data; The data to be transmitted is obtained by formatting the field values ​​of the corresponding type in the packaged data based on the date format template and / or the numerical precision specification.

7. A computer-readable storage medium having a computer program stored thereon that can run on a processor, characterized in that, When the computer program is executed by the processor, it implements the SaaS-based multi-party system data push method as described in any one of claims 1 to 5.

Images