Cross-domain data product call distribution and dynamic routing method, device and electronic equipment

Abstract

The application discloses a cross-domain data product calling distribution and dynamic routing method and device and electronic equipment, relates to the field of data processing, and comprises the following steps: receiving a service request from a data user, wherein the service request at least comprises a data caller identifier and a request scene parameter comprising a timeout tolerance duration; determining a data distribution channel according to a comparison result of the timeout tolerance duration and a preset threshold, comprising: when it is detected that the timeout tolerance duration is less than or equal to the preset threshold, routing the service request to a first type channel used for responding to each data transmission within a preset duration; when it is detected that the timeout tolerance duration is greater than the preset threshold, routing the service request to a second type channel used for batch transmission of multiple data; and sending a cross-domain calculation instruction to a multi-party cooperation base via the data distribution channel and generating a unique audit tracking code. The application solves the problem that the existing cross-domain data product calling method is difficult to consider high real-time scenes and batch processing scenes.

Description

Technical Field

[0001] This application relates to the field of data processing, and more specifically, to a method, apparatus, and electronic device for cross-domain data product invocation, distribution, and dynamic routing. Background Technology

[0002] In cross-domain data product interaction scenarios, different data users have significantly different timeliness requirements for data access. Some business scenarios require millisecond or second-level real-time responses, such as online transaction risk control and real-time recommendations; while other scenarios can tolerate delays of more than a second, such as batch report generation and offline data analysis.

[0003] However, existing methods for calling cross-domain data products often suffer from significant response latency when handling business requests with high real-time requirements, making it difficult to meet millisecond or second-level response needs. On the other hand, when handling a large number of business requests with low real-time requirements, there are problems with low processing efficiency and insufficient throughput. This makes it difficult to simultaneously meet both high real-time and batch processing needs, and data service providers are unable to provide differentiated service levels for different timeliness requirements, which can easily affect the application effect of cross-domain data products.

[0004] There is currently no effective solution to the above problems. Summary of the Invention

[0005] This application provides a method, apparatus, and electronic device for cross-domain data product invocation, distribution, and dynamic routing, to at least solve the technical problem that existing cross-domain data product invocation methods cannot simultaneously handle high real-time scenarios and batch processing scenarios.

[0006] According to one aspect of the embodiments of this application, a cross-domain data product invocation distribution and dynamic routing method is provided, applied to a gateway system. The method includes: receiving a business request from a data user, wherein the business request includes at least a data user identifier and request scenario parameters, the request scenario parameters including a timeout tolerance duration for the business request; determining a data distribution channel based on a comparison result between the timeout tolerance duration and a preset threshold, including: if the timeout tolerance duration is detected to be less than or equal to the preset threshold, routing the business request to a first type of channel, the first type of channel being used to respond to the transmission of each data within a preset duration; if the timeout tolerance duration is detected to be greater than the preset threshold, routing the business request to a second type of channel, the second type of channel being used to batch transmit multiple data; sending a cross-domain computation instruction to a multi-party collaboration base via the determined data distribution channel, and simultaneously generating a globally unique audit trail code, wherein the audit trail code is used to identify the flow path of this data invocation in the entire link, and the audit trail code is associated with and stored with the business request; the multi-party collaboration base is an underlying system for performing cross-domain data joint computation; the cross-domain computation instruction is used to instruct the multi-party collaboration base to perform data query or joint computation associated with the business request.

[0007] According to another aspect of the embodiments of this application, a cross-domain data product invocation distribution and dynamic routing apparatus is also provided, comprising: a business request receiving unit, configured to receive a business request from a data user, wherein the business request includes at least a data caller identifier and request scenario parameters, the request scenario parameters including a timeout tolerance duration for the business request; and a comparison processing unit, configured to determine a data distribution channel based on a comparison result between the timeout tolerance duration and a preset threshold, including: when it is detected that the timeout tolerance duration is less than or equal to the preset threshold, routing the business request to a first type of channel, the first type of channel being used to respond to each data request within a preset duration. The data transmission is as follows: If the timeout tolerance period exceeds a preset threshold, the business request is routed to a second-type channel, which is used for batch transmission of multiple data items; the output processing unit sends cross-domain computation instructions to the multi-party collaboration base via a defined data distribution channel, and simultaneously generates a globally unique audit trail code. The audit trail code identifies the flow path of this data call throughout the entire chain, and is associated with and stored in relation to the business request; the multi-party collaboration base is the underlying system for performing cross-domain data joint computation; the cross-domain computation instructions instruct the multi-party collaboration base to perform data queries or joint computations associated with the business request.

[0008] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, which stores a computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located executes the above-described cross-domain data product invocation distribution and dynamic routing method.

[0009] According to another aspect of the embodiments of this application, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by one or more processors, the one or more processors cause the one or more processors to execute the above-described cross-domain data product invocation distribution and dynamic routing method.

[0010] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program or instructions, which, when executed by a processor, implement the above-described cross-domain data product invocation distribution and dynamic routing method.

[0011] In this embodiment, firstly, the gateway system receives a business request from a data user, allowing the user's timeliness requirements to be explicitly transmitted to the gateway system as parameters. This business request may carry a timeout tolerance parameter for this request scenario. The timeout tolerance can be the maximum acceptable waiting time for the data user in this call. The value of the timeout tolerance directly reflects the real-time requirements of the business request; that is, a smaller timeout tolerance indicates a higher requirement for response speed, while a larger value indicates that a longer processing delay can be tolerated. Secondly, the gateway system compares the received timeout tolerance with a preset threshold. The preset threshold can be a time value pre-configured in the gateway system, used to distinguish between high real-time requests and batch requests with tolerable delays. When the detected timeout tolerance is less than or equal to the preset threshold, the gateway system determines that the business request belongs to a high real-time scenario and routes the business request to a first-type channel. The first-type channel is used to respond to the transmission of each data item within a preset time, ensuring a fast response for each request. When the timeout tolerance duration exceeds a preset threshold, the gateway system determines that the service request belongs to a batch scenario with tolerable latency and routes the service request to the second type of channel. The second type of channel is used for batch transmission of multiple data items, which can efficiently handle large batch requests without affecting the real-time channel. Through the above comparison and diversion operations, the gateway system can automatically allocate requests with different timeliness requirements to their respective suitable transmission channels according to the relationship between the timeout tolerance duration and the preset threshold, which helps to avoid interference between high real-time requests and batch requests. Furthermore, the gateway system sends cross-domain computing instructions to the multi-party collaborative base through the determined data distribution channel, and at the same time generates a globally unique audit trail code to identify the entire link flow path of this call, which helps to ensure that the instructions are correctly delivered according to the selected distribution channel, and enables traceability of the call process through the audit trail code. This application's embodiments introduce a timeout tolerance period as a request scenario parameter. By comparing this request scenario parameter with a preset threshold, the first type of channel or the second type of channel is dynamically selected. This allows high real-time requests to obtain a fast response channel and batch requests with tolerable latency to obtain a high throughput channel. This facilitates adaptive distribution based on the caller's timeliness requirements, thereby solving the technical problem that existing cross-domain data product calling methods cannot simultaneously accommodate high real-time scenarios and batch processing scenarios. Attached Figure Description

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

[0013] Figure 1 This is a schematic diagram of an optional cross-domain data product invocation distribution and dynamic routing method according to an embodiment of this application;

[0014] Figure 2 This is a schematic diagram of the architecture of an optional cross-domain data product invocation, distribution, and dynamic routing system according to an embodiment of this application;

[0015] Figure 3 This is a schematic diagram of an optional audit trail code generation and business policy downgrade process based on lifecycle timestamps according to an embodiment of this application;

[0016] Figure 4 This is a schematic diagram of an optional cross-domain data product invocation distribution and dynamic routing device according to an embodiment of this application. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0018] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0019] According to an embodiment of this application, a method embodiment for cross-domain data product invocation distribution and dynamic routing is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0020] It should be noted that the information collected in this application (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of this data all comply with relevant laws, regulations, and standards, necessary confidentiality measures have been taken, and they do not violate public order and good morals. Corresponding access points are provided for users to choose to authorize or refuse. For example, interfaces are set up between this system and relevant users or organizations, providing users with corresponding access points to choose to agree to or refuse automated decision-making results; if the user chooses to refuse, the process proceeds to the expert decision-making stage.

[0021] According to the embodiments of this application, a gateway system can be used as the execution subject of the cross-domain data product invocation distribution and dynamic routing method of this application embodiment. The system can be a software system or an embedded system combining software and hardware. Of course, the method execution subject in the embodiments of this application can also be other forms of execution subject, such as devices, equipment, etc. It should be known by those skilled in the art that this application does not particularly limit the specific form of the method execution subject.

[0022] Figure 1 This is a schematic diagram of a cross-domain data product invocation distribution and dynamic routing method according to an embodiment of this application, as shown below. Figure 1 As shown, the cross-domain data product call distribution and dynamic routing method is applied to the gateway system. The method includes the following steps:

[0023] Step S101: Receive a business request from the data user. The business request includes at least the data caller identifier and request scenario parameters, including the timeout tolerance period of the business request.

[0024] For example, the data caller identifier can refer to information that uniquely identifies the initiator of the business request, such as a caller number, application identifier, or interface key. Request scenario parameters can refer to a set of parameters describing the environment and requirements of this business call. The timeout tolerance duration can represent the maximum allowable waiting time for the data user to wait from the issuance of the business request to receiving a complete response. The gateway system receives the business request from the data user and extracts the data caller identifier and timeout tolerance duration from the request. This embodiment of the application helps the gateway system to initially determine the data user's response speed requirements based on the timeout tolerance duration, thereby providing a basis for subsequently selecting a suitable data distribution channel and effectively distinguishing between business requests with high real-time requirements and batch requests with acceptable delays.

[0025] In some embodiments, the request scenario parameters received by the gateway system may further include a data volume estimation field or a priority identifier field corresponding to the service request. After extracting the timeout tolerance duration, the gateway system performs a preliminary comparison with a preset threshold to determine the timeliness category of the service request. This embodiment, by adding auxiliary fields to the request scenario parameters, helps the gateway system make more accurate distribution decisions by incorporating more contextual information when the timeout tolerance duration cannot clearly reflect real-time requirements.

[0026] In other embodiments, the data caller identifier in the service request received by the gateway system is in numeric or string encoding form, and the timeout tolerance duration in the request scenario parameters is carried as a numerical value in milliseconds or seconds. The gateway system parses the data caller identifier to obtain the data user's subscription level information, and simultaneously parses the timeout tolerance duration to determine the upper limit of latency tolerance for the service request. This embodiment allows the gateway system to comprehensively consider the data user's identity level and the timeliness requirements of the request during subsequent routing decisions, facilitating differentiated channel allocation.

[0027] Step S102, determining the data distribution channel based on the comparison result between the timeout tolerance duration and the preset threshold, includes: if the timeout tolerance duration is detected to be less than or equal to the preset threshold, routing the service request to a first type channel, which is used to respond to the transmission of each data within the preset duration; if the timeout tolerance duration is detected to be greater than the preset threshold, routing the service request to a second type channel, which is used to transmit multiple data in batches.

[0028] For example, the preset threshold can refer to a time value pre-configured in the gateway system, used to distinguish business requests with different real-time requirements. The first type of channel can represent a data transmission channel characterized by low latency and sequential response, such as a synchronous application programming interface channel. This first type of channel is used to respond to the transmission of each data item within a preset duration. The second type of channel can represent a data transmission channel characterized by high throughput and batch processing, such as an asynchronous message queue channel. This second type of channel is used to transmit multiple data items in batches. The gateway system compares the received timeout tolerance duration with the preset threshold. When the timeout tolerance duration is detected to be less than or equal to the preset threshold, the business request is routed to the first type of channel; when the timeout tolerance duration is detected to be greater than the preset threshold, the business request is routed to the second type of channel. This embodiment of the application is advantageous in automatically separating high-real-time requests and latency-tolerant batch requests into different transmission channels according to the actual response speed requirements of the data user. This avoids slow batch processing blocking fast response channels and is beneficial in balancing real-time response capabilities in high-concurrency scenarios with throughput efficiency for large-scale data processing.

[0029] In some embodiments, the preset threshold can be set to a predetermined time value. After extracting the timeout tolerance duration from the service request, the gateway system compares the timeout tolerance duration with the preset threshold. If the timeout tolerance duration is less than or equal to the preset threshold, the gateway system routes the service request to a synchronous interface channel, which uses a real-time connection to return the processing result of a single request within a short period of time. If the timeout tolerance duration is greater than the preset threshold, the gateway system routes the service request to an asynchronous message queue channel, which writes the service request into a queue and then returns an acceptance certificate, which is subsequently processed in batches by the consumer. This embodiment, by setting a fixed time threshold, facilitates clear dual-track traffic splitting decisions and reduces the routing complexity of the gateway system.

[0030] In other embodiments, the preset threshold may not be a fixed value, but rather a value dynamically adjusted by the gateway system based on the service level pre-subscribed by the data user. The gateway system first queries the corresponding service level based on the data caller's identifier, obtains the preset threshold associated with that service level, then compares the timeout tolerance period with the preset threshold, and finally determines the data distribution channel based on the comparison result. This embodiment facilitates providing differentiated traffic routing strategies for data users with different service levels, making it easier for data users with higher service levels to trigger the conditions for routing to the first type of channel, thereby obtaining a better real-time response experience.

[0031] Step S103: A cross-domain computation instruction is sent to the multi-party collaboration base via a determined data distribution channel. At the same time, a globally unique audit trail code is generated. The audit trail code is used to identify the flow path of this data call in the entire link and is associated with the business request for storage. The multi-party collaboration base is the underlying system for performing cross-domain data joint computation. The cross-domain computation instruction is used to instruct the multi-party collaboration base to perform data query or joint computation associated with the business request.

[0032] For example, the multi-party collaboration base can refer to an underlying system used to perform cross-domain data joint computation. This underlying system connects multiple data providers and can complete data query or joint computation tasks across multiple data sources according to received instructions. The cross-domain computation instruction can refer to control information issued by the gateway system to the multi-party collaboration base, instructing the execution of data operations associated with a business request. The audit trail code can refer to a globally unique identifier generated by the gateway system for this data call, used to identify the flow path of this data call throughout the entire chain. The gateway system sends the cross-domain computation instruction to the multi-party collaboration base according to the previously determined data distribution channel, and simultaneously generates a globally unique audit trail code at the moment of sending the instruction, and associates and stores the audit trail code with the business request. This embodiment of the application is beneficial for establishing a unique tracking identifier for each cross-domain data call, enabling subsequent billing statistics, reconciliation and settlement, and troubleshooting to be performed based on the audit trail code. It also helps avoid transmitting sensitive business information within the multi-party collaboration base, and facilitates full traceability of the call process and physical isolation of billing data.

[0033] The audit trail code contains only non-sensitive information such as call identifier, channel type, service level and timestamp when it is generated. It does not carry personal entity information or underlying calculation results, which helps to avoid the risk of leakage of personal privacy data in subsequent billing and reconciliation processes.

[0034] In some embodiments, the gateway system generates an audit trail code by: obtaining the current system timestamp, the data caller identifier, and the data distribution channel type identifier; concatenating the obtained information into a string according to a preset format; and using this string as the audit trail code for the current call. The gateway system writes this audit trail code into an extended field of the cross-domain computation instruction, sends it along with the instruction to the multi-party collaboration platform, and stores the audit trail code in the gateway system's local cache or database in association with the service request's reception time and routing channel information. This embodiment, by encoding multiple pieces of information into the audit trail code, facilitates the subsequent parsing of key information such as call time, caller identity, and channel type from the audit trail code itself, enabling rapid statistics and reconciliation.

[0035] In other embodiments, after generating the audit trail code, the gateway system may not send it to the multi-party collaboration base. Instead, it maintains the mapping relationship between the audit trail code and the business request internally. The gateway system sends the cross-domain computation instruction to the multi-party collaboration base in its original format, and simultaneously writes the audit trail code, the receipt time of the business request, and the data caller identifier as a record into a separate bypass storage unit. In this embodiment, the generation of the audit trail code and the sending of the cross-domain computation instruction are executed in parallel, without affecting the transmission latency of the cross-domain computation instruction. Storing audit trail-related information in the bypass facilitates physical isolation between billing data and the main business call link, enhancing data security.

[0036] In some optional embodiments, after sending the cross-domain computation instruction to the multi-party collaboration base and generating a globally unique audit trail code, the method further includes: the gateway system receiving the original computation result returned by the multi-party collaboration base, wherein the original computation result is the underlying data returned by the multi-party collaboration base after performing cross-domain computation, without dimensionality reduction processing, containing continuous numerical computation results or structured fields; dimensionality reduction mapping of the original computation result to a decision label, wherein the decision label is a discrete level identifier, and the data volume of the decision label is smaller than the data volume of the original computation result; encapsulating a lifecycle timestamp for the decision label, wherein the lifecycle timestamp is used to limit the validity period of the decision label; and returning the generated decision label and the encapsulated lifecycle timestamp as a response result to the data user.

[0037] For example, a decision label can refer to a discrete level identifier obtained after dimensionality reduction mapping of the original calculation result, and the data volume of the decision label is smaller than that of the original calculation result. A lifecycle timestamp can refer to time information used to limit the validity period of the decision label, and this lifecycle timestamp can be expressed in the form of an absolute expiration time or a relative duration. After the expiration time indicated by the lifecycle timestamp, the corresponding decision label is considered to have expired in business logic, requiring a re-triggering of the billing request. The gateway system receives the original calculation result returned by the multi-party collaborative base, maps the original calculation result to a decision label through dimensionality reduction, encapsulates the lifecycle timestamp for the decision label, and then returns the generated decision label and the encapsulated lifecycle timestamp as a response result to the data user. This embodiment of the application is beneficial for simplifying the complex underlying calculation result into a discrete level identifier that is easy for business systems to use, reducing data transmission volume. At the same time, by limiting the validity period of the decision label through the lifecycle timestamp, it prevents the data user from reusing the label indefinitely, which is beneficial for achieving pay-per-use billing.

[0038] In some embodiments, the gateway system receives a continuous numerical calculation result, such as a risk score or value score. The gateway system divides this continuous numerical value into multiple discrete intervals according to a preset segmentation mapping rule, with each discrete interval corresponding to a business decision level identifier. After mapping the original calculation result to the corresponding business decision level identifier, the gateway system generates a decision label. This embodiment reduces data dimensionality through segmentation mapping, which helps protect the underlying data details from direct exposure and facilitates data users in executing subsequent business strategies based on the labels.

[0039] In other embodiments, the gateway system receives raw computation results as structured data containing multiple fields, such as a composite result including user identifier, behavior type, timestamp, and numerical value. The gateway system extracts key fields from this data and, according to a pre-defined decision tree or rule engine, comprehensively determines the multi-dimensional input into a discrete level identifier as a decision label. Based on the service level pre-subscribed by the data user or the scenario parameters in the business request, the gateway system determines the validity period of the lifecycle timestamp, converts this validity period into an absolute expiration time, and encapsulates it as a lifecycle timestamp in the response result. This embodiment is beneficial for dimensionality reduction of complex multi-source data output and provides differentiated label validity periods based on the caller level, improving pricing flexibility.

[0040] In some optional embodiments, after sending cross-domain computing instructions to the multi-party collaborative base and generating a globally unique audit trail code, the method further includes: the gateway system can send a record including the audit trail code, call time, and service level information to the bypass ledger center, wherein the call time is the time of receiving the business request or the time of generating the audit trail code; the service level information is the service level pre-subscribed by the data caller or the service level corresponding to the data distribution channel; the bypass ledger center is a record storage unit independent of the main data distribution link, used for call record verification and resource allocation settlement among multiple providers.

[0041] For example, the call time can refer to the timestamp of the gateway system receiving the business request or the timestamp of the audit trail generation, used to identify the moment the call occurred. Service level information can refer to the service level pre-subscribed by the data caller, such as a premium or standard package, or a service level corresponding to the data distribution channel, such as a high-level channel for real-time channels and a standard level for batch channels. The bypass ledger center can refer to a record storage unit independent of the main data distribution link. This record storage unit is used for call record verification and resource allocation settlement among multiple providers, and does not store sensitive data related to the underlying calculation results. In other words, the bypass ledger center can refer to a bypass billing center independent of the main data distribution link. This bypass ledger center is physically isolated from the underlying sensitive data, only receiving and storing audit trails, call times, and service level information, and does not store original calculation results or any sensitive data that can identify an individual entity, for periodic business reconciliation. The gateway system sends records containing audit trails, call times, and service level information to the bypass ledger center. The embodiments of this application facilitate the separation of billing-related metadata from the main business link, enabling multiple data providers to verify the number of calls and settle revenue sharing based on the records in the bypass ledger center, while avoiding the exposure of underlying sensitive data to all parties, which is conducive to achieving de-identified billing and frictionless reconciliation.

[0042] The bypass ledger center only stores audit trail codes, call times, and service level information, and does not store original calculation results or any sensitive data that can identify personal entities, which is conducive to achieving desensitized storage of billing data.

[0043] In some embodiments, after generating an audit trail code, the gateway system can immediately and asynchronously assemble the audit trail code, the current system timestamp, and the service level information subscribed by the data caller into a billing record, and send it to the bypass ledger center via User Datagram Protocol (UDP) or message queue, reducing the blockage of the main link's response process. Upon receiving the billing record, the bypass ledger center writes it to an append-only log file. This embodiment, through asynchronous transmission, helps reduce the impact of billing record operations on the main link's response latency, while ensuring the integrity and persistence of billing data.

[0044] In other embodiments, the gateway system can batch-package audit trail codes, call times, and equivalent service level information determined based on the data distribution channel, and send them all at once to the bypass ledger center after a preset time window. For example, the gateway system sends batch records every 100 accumulated billing records or every ten seconds. After receiving the batch records, the bypass ledger center performs deduplication verification according to the audit trail codes before storing them in its database. This embodiment, through batch sending, helps reduce the number of network interactions between the gateway system and the bypass ledger center, reduces system overhead, and is suitable for high-throughput call scenarios.

[0045] In some optional embodiments, after sending the record containing the audit trail code, call time, and service level information to the bypass ledger center, the method further includes: the gateway system can receive a service request re-initiated by the data user, wherein the service request carries a decision tag and a lifecycle timestamp; extract the lifecycle timestamp from the service request, obtain the current system time, and determine whether the expiration time indicated by the lifecycle timestamp is later than the current system time; if it is detected that the expiration time indicated by the lifecycle timestamp is later than the current system time, determine the service policy level corresponding to the data user based on the decision tag; wherein the service policy level is used to indicate the resource type access permission and processing priority corresponding to the data user; if it is detected that the expiration time indicated by the lifecycle timestamp is earlier than or equal to the current system time, reduce the service policy level corresponding to the data user to a preset minimum level, and carry an indication code requiring a re-initiation of the authorization request in the response message returned to the data user; wherein the preset minimum level is the lowest level in a predefined service policy level sequence.

[0046] For example, a re-initiated service request can refer to a business request initiated by a data user to the gateway system again after obtaining a decision tag and a lifecycle timestamp, based on the decision tag. The lifecycle timestamp can refer to the validity period identifier set by the gateway system for the decision tag, used to distinguish whether the decision tag is in a valid or invalid state. The expiration time indicated by the lifecycle timestamp can refer to the time boundary at which the decision tag is preset to expire. The service policy level can be used to indicate the resource type access permissions and processing priorities corresponding to the data user. The preset minimum level is the lowest level in a predefined service policy level sequence, and the resource access permissions and processing priorities corresponding to this preset minimum level are lower than other levels, such as the default level or an unknown level. After receiving the re-initiated service request from the data user, the gateway system extracts the decision tag and lifecycle timestamp from the service request and obtains the current system time. The gateway system determines whether the decision tag is valid by comparing the expiration time indicated by the lifecycle timestamp with the current system time. If the expiration time indicated by the lifecycle timestamp is later than the current system time, it indicates that the decision tag is still valid. The gateway system directly determines the service policy level corresponding to the data user based on the decision tag, without needing to re-execute the underlying cross-domain calculation. If the expiration time indicated by the lifecycle timestamp is earlier than or equal to the current system time, it indicates that the decision tag has expired. The gateway system does not need to physically intercept the request, such as by directly rejecting the service request. Instead, the gateway system lowers the service policy level corresponding to the data user to the preset minimum level and includes an indication code in the response message returned to the data user requesting a re-initiation of the authorization request. This embodiment of the application binds the validity period of the decision tag to the service policy level of the data user, so that expired decision tags cannot continue to obtain the original service level. This prompts the data user to re-initiate the paid authorization request at the business rule level, which helps to avoid the problem of one-time payment and unlimited use. At the same time, by directly reusing the decision tag when it is valid, it helps to avoid the latency and resource consumption caused by repeatedly executing the underlying cross-domain calculation.

[0047] In some embodiments, the decision tag received by the gateway system in a re-initiated service request can be carried as a preset field name, and the lifecycle timestamp can be carried as an absolute timestamp. After parsing the lifecycle timestamp value from the request message, the gateway system reads the local system clock to obtain the current timestamp and compares the lifecycle timestamp with the current timestamp. If the lifecycle timestamp is greater than the current timestamp, the gateway system determines that the decision tag is still valid, maps it to the corresponding service policy level according to the level identifier carried in the decision tag, and allocates the corresponding resource access permissions and request processing priority according to the level. This embodiment achieves validity period determination by directly comparing timestamp values, which helps improve detection efficiency and reduce computational overhead.

[0048] In other embodiments, the lifecycle timestamp in the re-initiated service request received by the gateway system is represented in the form of a relative duration. The gateway system obtains the absolute time reference point recorded internally when the decision tag was first issued, adds the relative duration to the reference point to calculate the expiration time, and then compares the calculated expiration time with the current system time. When the expiration time is detected to be equal to or earlier than the current system time, the gateway system downgrades the service policy level to the preset lowest level and sets a status code field in the response message. The value of this status code field is the preset value corresponding to the requirement for re-authorization. After receiving the response, the data user parses the status code and actively triggers a new authorization and billing request. This embodiment uses a relative duration to represent the lifecycle, which helps reduce the amount of data carried in the request. At the same time, by downgrading rather than directly rejecting, it helps maintain the continuity of business interaction.

[0049] In some optional embodiments, after determining that the data distribution channel is a second type of channel based on the comparison between the timeout tolerance period and a preset threshold, the method further includes: the gateway system generating a batch authorization order according to a preset period and issuing the batch authorization order to the data user. The batch authorization order is a credential generated by the gateway system for batch authorizing the data user to consume decision tags in the second type of channel within its validity period. The batch authorization order contains an authorization identifier and validity period information. When consuming decision tags in the second type of channel, the data user carries the batch authorization order in the service request returned to the gateway system. After receiving the service request carrying the batch authorization order, the gateway system verifies whether the batch authorization order is valid. If the batch authorization order has expired, the gateway system refuses to process the service request; if the batch authorization order has not expired, the gateway system processes the service request.

[0050] For example, a batch authorization order can refer to a credential generated by the gateway system for batch transmission scenarios in the second type of channel, used to authorize data users to consume decision tags within the validity period. The business rights identifier can be a digital certificate of a commercial contract and service level dynamically issued by the data service operator to the data user. The batch authorization order can serve as the specific carrier of the business rights identifier. The batch authorization order contains an authorization identifier and validity period information. The authorization identifier is used to uniquely identify the batch authorization order, and the validity period information is used to limit the validity period of the batch authorization order. The gateway system generates batch authorization orders according to a preset cycle and issues them to the data user. When consuming decision tags in the second type of channel, the data user includes the batch authorization order in the service request sent to the gateway system. After receiving the service request carrying the batch authorization order, the gateway system verifies whether the batch authorization order is within its validity period: if the batch authorization order is detected to be expired, the gateway system refuses to process the service request; if the batch authorization order is detected to be valid, the gateway system processes the service request normally. The embodiments of this application are beneficial in offline batch processing scenarios, by using periodically issued batch authorization orders to control the validity period of batch data consumption behavior, preventing data users from continuing to consume batch data after the authorization expires, and avoiding the need to generate a separate authorization certificate for each batch of data, which helps to reduce the authorization overhead of the gateway system and improve batch processing efficiency.

[0051] In some embodiments, the gateway system generates a batch authorization order valid for that day at midnight on a daily basis. This batch authorization order includes the current date as validity information and a randomly generated authorization identifier string. The gateway system proactively pushes the batch authorization order to all data users who have signed up to use the second-type channel through a pre-registered data user callback interface. When consuming decision tags in the second-type channel, data users include the authorization identifier string from the batch authorization order as a request header field in their service request. Upon receiving the service request, the gateway system parses the authorization identifier string, queries the locally stored batch authorization order record, obtains the corresponding validity information, and compares the expiration date in the validity information with the current system date. If the current system date is later than the expiration date, the gateway system determines that the batch authorization order has expired and returns a rejection response; if the current system date has not exceeded the expiration date, the gateway system continues to process the service request. This embodiment, by issuing batch authorization orders daily, facilitates unified authorization control of daily batch data and simplifies authorization management logic.

[0052] In other embodiments, the gateway system can generate batch authorization orders on a weekly basis and distribute them as encrypted files to the storage location specified by the data user. When consuming decision tags in the second type of channel, the data user includes the authorization identifier of the batch authorization order and the corresponding signature information in the service request message body. Upon receiving the service request, the gateway system first verifies the validity of the signature information to confirm the integrity of the batch authorization order, and then verifies whether the batch authorization order is within a preset validity window. If the verification finds that the batch authorization order has expired or the signature is invalid, the gateway system refuses to process the service request and returns a specific error code in the response message, indicating that the batch authorization order needs to be re-obtained. This embodiment, by introducing a signature verification mechanism, helps prevent the batch authorization order from being forged or tampered with, and by generating authorization orders at periodic intervals, it helps reduce the network interaction burden caused by frequent issuance.

[0053] In some optional embodiments, generating a globally unique audit trail code includes: the gateway system can obtain the data caller identifier, the type of data distribution channel, the initial service level, and the call timestamp, wherein the initial service level is the service level pre-subscribed by the data caller, and the call timestamp is the timestamp of the gateway system receiving the business request or the timestamp of the audit trail code generation; the data caller identifier, the type of data distribution channel, the initial service level, and the call timestamp are concatenated according to a preset format to generate the audit trail code.

[0054] For example, the data distribution channel type can refer to the routing channel category determined by the gateway system based on the timeout tolerance duration comparison result, such as a first-class channel or a second-class channel. The initial service level can refer to the service level pre-subscribed by the data caller, which is used to identify the service quality level enjoyed by the data caller. The call timestamp can refer to the timestamp of the gateway system receiving the business request or the timestamp of the audit trail code generation. The gateway system obtains the data caller identifier, the data distribution channel type, the initial service level, and the call timestamp, and concatenates the above information according to a preset format to generate a globally unique audit trail code. This embodiment of the application facilitates encoding the key metadata of this call into the audit trail code itself, so that in subsequent billing, reconciliation, or investigation processes, the caller's identity, the type of channel used, the service level, and the call time can be parsed solely from the audit trail code. This reduces additional queries to the associated database, improving reconciliation efficiency and system traceability.

[0055] In some embodiments, the gateway system converts the data caller identifier into a fixed-length hexadecimal string, encodes the data distribution channel type as a single character (e.g., letter A represents a first-class channel, letter B represents a second-class channel), encodes the initial service level as a two-digit number, and converts the call timestamp into a hexadecimal representation of the number of seconds elapsed since a certain base time. The gateway system can then concatenate the fields into an audit trail string, separating them with hyphens, in the order of the hexadecimal representation of the call timestamp, the hexadecimal string of the data caller identifier, the data distribution channel type character, and the numerical encoding of the initial service level. This embodiment, through its fixed format and fixed-length encoding, helps maintain a stable audit trail length, facilitating subsequent parsing and database indexing.

[0056] In other embodiments, after obtaining the data caller identifier, data distribution channel type, initial service level, and call timestamp, the gateway system also adds business dimension parameters carried in the business request as additional fields to the concatenation process, such as business type code or region code. The gateway system sorts all fields in lexicographical order before concatenation and performs a hash operation on the concatenated string, using the hash value as the audit trail code. This embodiment, by introducing a hash operation, makes the audit trail code irreversible, which helps prevent external parties from using the audit trail code to deduce sensitive information such as the data caller identifier or service level, while also helping to maintain the global uniqueness of the audit trail code.

[0057] Figure 2This diagram illustrates the architecture of a cross-domain data product invocation distribution and dynamic routing system provided in an embodiment of this application. This system may include a data user, a gateway system, a multi-party collaboration platform, and a bypass ledger center. On the gateway system side, the system may include a batch authorization order verification module, an audit trail code generation module, and a decision tag generation module. The data user initiates a business request to the gateway system, carrying a timeout tolerance period and optionally a batch authorization order. Upon receiving the business request, if the request includes a batch authorization order, the gateway system can verify its validity using the batch authorization order verification module and generate a globally unique audit trail code using the audit trail code generation module. Simultaneously, the gateway system determines the data distribution channel based on a comparison between the timeout tolerance period in the business request and a preset threshold: if the timeout tolerance period is less than or equal to the preset threshold, the business request is routed to a first-type channel (not separately labeled in the diagram, but corresponding to the return path of the real-time policy result); if the timeout tolerance period is greater than the preset threshold, the business request is routed to a second-type channel. Through a defined data distribution channel, the gateway system sends anonymous cross-domain computation commands to the multi-party collaboration platform. After performing joint cross-domain data computation, the multi-party collaboration platform returns the raw computation results to the gateway system. The gateway system uses a decision label generation module to reduce the dimensionality of the raw computation results and map them into decision labels, then encapsulates a lifecycle timestamp for each decision label. The gateway system returns the generated decision labels and the encapsulated lifecycle timestamps as response results to the data user. The response results returned through the first type of channel correspond to real-time policy results, while those returned through the second type of channel correspond to batch policy results. In the second type of channel scenario, the gateway system can also return batch decision labels to the offline batch computation engine within the data user, such as capacity scheduling and data middleware, through batch task submission. Simultaneously with returning the response results, the gateway system sends billing records to the bypass ledger center. These billing records include audit trail codes, call times, and service level information, used for verifying call records and clearing resource allocation among multiple providers. When the data user initiates a service request again, it can include the audit trail code, decision label, and lifecycle timestamp in the service request. The gateway system extracts the lifecycle timestamp and determines whether it has expired. If it has expired, it triggers a downgrade process, requiring the data user to re-initiate the authorization and billing request.

[0058] In some optional embodiments, the original calculation results are dimensionality-reduced and mapped to decision labels, including: the gateway system can parse the continuous numerical calculation results returned by the multi-party collaborative base from the original calculation results; according to the preset segmentation rules, the continuous numerical calculation results are mapped to discrete service level identifiers; and the service level identifiers are output as decision labels, wherein the value range of the decision labels is smaller than the value range of the continuous numerical calculation results.

[0059] For example, continuous numerical calculation results can refer to numerical data returned by the multi-party collaborative base, whose value range is a continuous interval or contains multiple decimal places. Segmentation rules can refer to a predefined mapping relationship between a set of numerical intervals and business level identifiers, with each numerical interval corresponding to a discrete business level identifier. Discrete business level identifiers can refer to level codes with a finite number of values ​​and no intermediate values ​​between them, such as Level 1, Level 2, Level 3, or Primary, Intermediate, and Advanced. The gateway system parses the continuous numerical calculation results returned by the multi-party collaborative base from the received raw calculation results, maps the continuous numerical calculation results to the corresponding discrete business level identifiers according to the preset segmentation rules, and outputs the business level identifier as a decision label. This embodiment of the application facilitates the transformation of fine-grained numerical values ​​generated by underlying calculations into discrete levels that are easy for the business system to understand and use, significantly reducing the amount of data returned to the data user, while avoiding directly exposing sensitive raw numerical values ​​to the data user, which helps protect the details of underlying data assets and reduces subsequent transmission and storage costs.

[0060] In some embodiments, the preset segmentation rule can be an equal-interval segmentation rule. The gateway system obtains the value range of the continuous numerical calculation result, divides the value range into several sub-intervals of equal length, and assigns a unique service level identifier to each sub-interval. After parsing the continuous numerical calculation result, the gateway system determines which sub-interval the continuous numerical calculation result falls into, and outputs the service level identifier corresponding to the sub-interval as a decision label. This embodiment achieves dimensionality reduction mapping through equal-interval segmentation, which helps ensure the uniformity and interpretability of the mapping rule, making it easier for data users to understand the relative differences between different levels.

[0061] In other embodiments, the preset segmentation rule can be a non-equal spacing segmentation rule. Based on the distribution statistics of historical call data, the gateway system divides intervals with high frequency of continuous numerical calculation results into finer sub-intervals and intervals with low frequency into coarser sub-intervals, assigning a service level identifier to each sub-interval. After parsing the continuous numerical calculation result, the gateway system finds the sub-interval to which the value belongs and outputs the corresponding service level identifier as a decision label. This embodiment, through non-equal spacing segmentation, is beneficial for providing more refined level distinctions in areas with dense numerical distribution, improving the accuracy of decision label expression.

[0062] In some optional embodiments, before determining the data distribution channel based on the comparison between the timeout tolerance period and the preset threshold, the method further includes: the gateway system can obtain the service level pre-subscribed by the data caller as the initial service level; if the initial service level is detected to be a first level, the preset threshold is set to a first value; if the initial service level is a second level, the preset threshold is set to a second value, wherein the first level is higher than the second level and the first value is less than the second value.

[0063] For example, the initial service level can refer to the service level pre-subscribed by the data caller, which identifies the quality of service enjoyed by the data caller. The first level and the second level can be two different levels in a predefined service level sequence, where the first level is higher than the second level. The preset threshold can refer to a time value used by the gateway system for comparison with the timeout tolerance period. The value of this preset threshold determines the boundary for whether a business request is routed to the first type of channel or the second type of channel. The gateway system obtains the initial service level pre-subscribed by the data caller. When the initial service level is detected to be the first level, the preset threshold is set to the smaller first value; when the initial service level is detected to be the second level, the preset threshold is set to the larger second value. This embodiment of the application is beneficial for providing differentiated routing strategies for data callers with different service levels, making it easier for business requests from high-level data users to meet the condition that the timeout tolerance period is less than or equal to the preset threshold, thus increasing the probability of being routed to the more real-time first type of channel for a better response experience. Simultaneously, guiding batch requests from low-level data users to the second type of channel facilitates the rational allocation of computing resources.

[0064] In some embodiments, the gateway system queries the local configuration database or subscription information cache for the subscription level corresponding to the data caller identifier to determine the initial service level as either Level 1 or Level 2. The first value is set to 500 milliseconds, and the second value is set to 3 seconds. After setting the preset threshold, the gateway system compares the timeout tolerance of received service requests with the preset threshold. If the timeout tolerance is less than or equal to the preset threshold, the request is routed to the first type of channel; if the timeout tolerance is greater than the preset threshold, the request is routed to the second type of channel. This embodiment, by assigning different thresholds to different levels, ensures that even if a request from a high-level user has a slightly longer timeout tolerance, it may still be considered a real-time request due to the smaller threshold, thus improving the experience for high-value users.

[0065] In other embodiments, the initial service level includes three or more levels, each corresponding to a preset threshold value, with higher levels corresponding to smaller preset threshold values. The gateway system queries the corresponding threshold value from the preset threshold mapping table based on the initial service level and uses this threshold value as the preset threshold for the current routing decision. When the service level of the data user changes, the gateway system synchronously updates the corresponding relationship in the mapping table, and subsequent routing decisions use the updated threshold. This embodiment supports more granular service level division through multi-level mapping, which is beneficial for implementing differentiated business package designs, while also supporting dynamic adjustment of levels, facilitating flexible changes in operational strategies.

[0066] In some optional embodiments, the decision tag is encapsulated with a lifecycle timestamp, including: the gateway system can obtain the service level pre-subscribed by the data caller as the initial service level; according to the initial service level, query the valid duration corresponding to the initial service level from a preset timestamp value mapping table; and convert the valid duration into an absolute timestamp or a relative duration as the lifecycle timestamp.

[0067] For example, the initial service level can refer to the service level pre-subscribed by the data caller, which is used to identify the service quality level enjoyed by the data user. The preset timestamp value mapping table can refer to a data structure pre-configured in the gateway system for storing the correspondence between the initial service level and the validity period. The validity period can refer to the length of time that the decision tag is allowed to remain valid. The lifecycle timestamp can refer to the time information used to limit the validity period of the decision tag, which can be expressed in the form of an absolute expiration time or a relative duration. The gateway system obtains the initial service level pre-subscribed by the data caller, queries the corresponding validity period from the preset timestamp value mapping table according to the initial service level, and converts the validity period into an absolute timestamp or a relative duration as the lifecycle timestamp of the decision tag. The embodiments of this application are beneficial for providing differentiated decision tag validity periods for data users with different service levels. Data users with higher service levels correspond to longer validity periods, thereby reducing the frequency of re-initiating authorization requests and improving the user experience; data users with lower service levels correspond to shorter validity periods, which is beneficial for increasing the frequency of data product calls.

[0068] In some embodiments, a preset timestamp value mapping table corresponds to different valid duration values ​​for different initial service levels, with higher service levels corresponding to larger valid duration values. After the gateway system queries the mapping table to obtain the valid duration, it obtains the current system time of the gateway system, adds the valid duration to the current system time to calculate the absolute expiration time, and encapsulates this absolute expiration time as a lifecycle timestamp in a decision tag and returns it to the data user. This embodiment represents the lifecycle in the form of an absolute timestamp, which is beneficial for data users to directly determine whether the decision tag has expired based on their own system time.

[0069] In other embodiments, the valid duration is stored as a relative duration in a preset timestamp value mapping table. After the gateway system queries the mapping table to obtain the valid duration, it does not convert the valid duration into an absolute timestamp. Instead, it directly encapsulates the value of the valid duration as a relative duration in the lifecycle timestamp field and returns it to the data user. The data user carries this relative duration in subsequent service requests. When the gateway system receives a service request, it determines whether the timeout has occurred based on the difference between the gateway system's current time and the time when the decision tag was first issued. This embodiment represents the lifecycle in a relative duration format, which helps reduce judgment errors caused by clock asynchrony between different systems.

[0070] Figure 3This illustration shows a schematic diagram of the audit trail generation and business policy degradation process based on lifecycle timestamps provided in an embodiment of this application. First, the gateway system receives a business request from a data user. The gateway system extracts the data caller identifier and request scenario parameters from the received business request, where the request scenario parameters include at least the timeout tolerance period. Optionally, the gateway system also extracts a batch authorization order from the business request. The gateway system verifies the extracted batch authorization order to determine whether it is valid and whether the quota corresponding to the service level is sufficient. When it detects that the batch authorization order has not expired and the service level quota is sufficient, the gateway system continues to execute the subsequent normal process; when it detects that the batch authorization order has expired or the service level is the preset lowest level, the gateway system jumps to the degradation processing path. In the normal process path, the gateway system generates a globally unique audit trail code and encapsulates a lifecycle timestamp for the decision label. Subsequently, the gateway system determines whether the expiration time indicated by the lifecycle timestamp is later than the current system time. If the expiration time indicated by the lifecycle timestamp is later than the current system time, the gateway system determines the service policy level corresponding to the data user based on the decision tag and outputs the corresponding service policy level. If the expiration time indicated by the lifecycle timestamp is earlier than or equal to the current system time, the gateway system lowers the service policy level corresponding to the data user to the preset minimum level and outputs the preset minimum level. In the degradation processing path, i.e., when the batch authorization order has expired or the service level is at the preset minimum level, the gateway system directly enters the degradation processing, lowers the service policy level corresponding to the data user to the preset minimum level, and outputs the preset minimum level. After the above normal path and degradation path are combined, the gateway system returns the generated decision tag and the encapsulated lifecycle timestamp as the response result to the data user. At the same time, before or simultaneously with returning the response result, the gateway system sends a record including the audit trace code, call time, and service level information to the bypass ledger center. Finally, the gateway system returns the response result to the data user.

[0071] In some optional embodiments, after sending records containing audit trail codes, call times, and service level information to the bypass ledger center, the bypass ledger center performs the following steps: based on all records containing audit trail codes, call times, and service level information received within a preset period, it counts the number of calls made by the data user according to the audit trail code or service level information, and obtains statistical results; it generates a reconciliation report based on the statistical results, wherein the reconciliation report includes the number of calls, service level, and allocated resource share corresponding to each audit trail code; and it outputs the reconciliation report within the target duration threshold after the end of each preset period.

[0072] For example, the preset period can refer to a pre-defined time interval length, such as 24 hours or one calendar month. The audit trail code can refer to a globally unique identifier generated by the gateway system for each data call. The call time can refer to the timestamp of the gateway system receiving the business request or the timestamp of the audit trail code generation. Service level information can refer to the service level pre-subscribed by the data caller or the service level corresponding to the data distribution channel. The reconciliation report can refer to a structured data file or collection of data records containing statistical results and resource allocation shares. The target duration threshold can refer to the maximum delay time allowed for outputting the reconciliation report after the preset period ends. The bypass ledger center continuously receives and stores billing records sent by the gateway system within the preset period. Each billing record contains an audit trail code, call time, and service level information. After the preset period ends, the bypass ledger center summarizes all billing records received within that period and counts the number of calls made by the data user according to the audit trail code or service level information to obtain the total number of calls corresponding to each audit trail code or service level. The bypass ledger center generates a reconciliation report based on the statistical results. This report lists the number of calls, service level, and resource allocation share calculated based on the number of calls and service level for each audit trail code. Within the target duration threshold at the end of each preset period, the bypass ledger center outputs the generated reconciliation report to the receiving end designated by the multiple data providers. This embodiment of the application facilitates the independent completion of call count statistics and resource allocation share calculation within the bypass ledger center, enabling multiple data providers to conduct settlement based on a unified reconciliation report. This reduces direct access to underlying sensitive data, mitigates the risk of data exposure during the reconciliation process, and simplifies the profit-sharing process.

[0073] In some embodiments, at the end of a preset period, the bypass ledger center groups and statistically analyzes all billing records received within the current period according to audit trail codes, calculating the number of calls corresponding to each audit trail code. The bypass ledger center parses the service level field in each audit trail code to obtain the corresponding service level information. Based on the service level information, the bypass ledger center queries a pre-configured unit price mapping table, multiplies the number of calls corresponding to each audit trail code by the unit price corresponding to that service level, and calculates the resource share to be allocated for each audit trail code. The bypass ledger center generates a reconciliation report containing the audit trail code, number of calls, service level, and resource share to be allocated, and outputs the report to the reconciliation interface of multiple providers within a target duration threshold after the preset period ends. This embodiment, by statistically outputting data periodically, facilitates periodic reconciliation and meets the timeliness requirements of commercial settlements.

[0074] In other embodiments, after a preset period ends, the bypass ledger center aggregates all billing records received throughout the period, groups them according to service level information, and calculates the total number of calls for each service level and the number of calls corresponding to each data caller identifier. Based on the revenue sharing ratio for each service level and the participation weight of each data provider, the bypass ledger center calculates the resource share allocated to each data provider. The bypass ledger center generates a reconciliation report, which lists the total number of calls and resource shares by service level, and includes detailed data for each data caller identifier. Within a target duration threshold after the preset period ends, the bypass ledger center sends the monthly reconciliation report to the pre-configured receivers of each data provider. This embodiment, by outputting statistics periodically, helps reduce the computational overhead of high-frequency statistics and facilitates periodic settlement.

[0075] In some optional embodiments, encapsulating a lifecycle timestamp for the decision tag includes: the gateway system can extract target flight information from the service request, wherein the target flight information includes flight number, planned departure time and planned arrival time; obtain the current system time, calculate the time difference between the current system time and the planned departure time to obtain the remaining time before departure; set the effective duration of the lifecycle timestamp to the product of the remaining time before departure and a first preset coefficient, or set it to the product of the difference between the planned arrival time and the current system time and a second preset coefficient; determine the absolute expiration time of the lifecycle timestamp based on the current system time and the effective duration, and encapsulate the absolute expiration time as the lifecycle timestamp of the decision tag.

[0076] For example, the target flight information can refer to a set of parameters related to flight operation extracted from the business request, including the flight number, scheduled departure time, and scheduled arrival time. The current system time can refer to the local clock reading when the gateway system performs calculations. The remaining time before departure can refer to the time difference between the current system time and the scheduled departure time. The first preset coefficient and the second preset coefficient can refer to pre-configured scaling factors used to map the remaining time to the effective lifecycle timestamp length. The gateway system extracts the target flight information from the business request, obtains the current system time, and calculates the difference between the current system time and the scheduled departure time to obtain the remaining time before departure. The gateway system multiplies the remaining time before departure by the first preset coefficient to obtain the effective time, or multiplies the difference between the scheduled arrival time and the current system time by the second preset coefficient to obtain the effective time. Since the remaining time before departure decreases over time, the calculated effective time also shortens accordingly, thus continuously shifting the absolute expiration time of the lifecycle timestamp forward. The embodiments of this application are beneficial to dynamically link the validity period of the decision tag with the flight operation time, so that the life cycle timestamp is automatically adjusted as the flight takes off or arrives, avoiding the decision tag remaining valid after the flight ends, which helps to reduce invalid calls after the flight ends and improve the accuracy of billing.

[0077] In some embodiments, the first preset coefficient is set to a positive number less than 1, such as 0.5 or 0.3. After parsing the planned departure time from the service request, the gateway system obtains the current system time, calculates the difference between the planned departure time and the current system time as the remaining time before departure, and multiplies this remaining time before departure by the first preset coefficient to obtain a value less than the remaining time before departure as the valid duration. The gateway system adds the valid duration to the current system time to calculate the absolute expiration time, and encapsulates this absolute expiration time as a lifecycle timestamp. Since the valid duration is always less than the remaining time before departure, the decision tag will inevitably expire before the flight takes off. This embodiment, by setting the valid duration to a coefficient less than 1 multiplied by the remaining time before departure, ensures that the validity period of the decision tag does not exceed a certain proportion of the remaining time before departure, which is beneficial for making the tag expire in advance before the flight takes off, prompting the data user to re-obtain the latest data close to departure.

[0078] In other embodiments, the second preset coefficient is set to a positive number greater than 1, such as 2 or 1.5. After parsing the planned arrival time from the business request, the gateway system obtains the current system time, calculates the difference between the planned arrival time and the current system time, and multiplies this difference by the second preset coefficient to obtain a value greater than the remaining trip duration as the valid duration. The gateway system adds the valid duration to the current system time to calculate the absolute expiration time and encapsulates it as a lifecycle timestamp. Since the valid duration is extended to after the trip ends, the decision tag can cover the entire flight trip and provide additional time buffer. This embodiment, by setting the valid duration to a multiple of the difference between the planned arrival time and the current system time, enables the validity period of the decision tag to cover the entire flight trip and additionally extend the time window by a certain proportion, which is beneficial to meeting the data validity period requirements of post-flight settlement or trip review services.

[0079] In some optional embodiments, after concatenating the data caller identifier, data distribution channel type, initial service level, and call timestamp according to a preset format to generate an audit trail code, the method further includes: the gateway system can obtain aviation business dimension parameters carried in the business request, wherein the aviation business dimension parameters include at least one of route code, cabin class, sales channel identifier, and passenger membership level; adding the aviation business dimension parameters to the audit trail code to obtain a multi-dimensional audit trail code; sending the record including the multi-dimensional audit trail code to the bypass ledger center; wherein, after receiving the record, the bypass ledger center performs the following steps: obtaining the encoded value of each business dimension by parsing each field in the multi-dimensional audit trail code, and then querying a preset profit-sharing rule table according to the encoded value of each business dimension to calculate the resource allocation share corresponding to each business dimension; and generating a multi-level profit-sharing settlement report by summarizing the resource allocation shares of each business dimension, wherein the multi-level profit-sharing settlement report lists the number of calls by the data user and the resource share to be allocated to the data user according to the route code, cabin class, sales channel identifier, or passenger membership level.

[0080] For example, aviation business dimension parameters can refer to multi-dimensional attribute information related to aviation business carried in the business request. A multi-dimensional audit trail code can refer to a globally unique identifier containing multi-business dimension codes, generated by fusing aviation business dimension parameters with basic audit trail code information. A profit-sharing rule table can refer to a pre-configured data structure storing the mapping relationship between the code values ​​of each business dimension and the resource allocation share. A multi-level profit-sharing settlement report can refer to a structured report listing the number of calls and the allocated resource share according to different business dimensions. The gateway system adds aviation business dimension parameters to the basic audit trail code, and the generated multi-dimensional audit trail code expands the original single code that only identifies the call path into a composite code carrying multi-dimensional business attributes. After receiving a record containing a multi-dimensional audit trail code, the bypass ledger center needs to parse the composite code to restore the code values ​​of each dimension. Because the profit-sharing rules may differ across different business dimensions—for example, resource allocation ratios may vary across different routes, and unit prices may differ across different cabin classes—the bypass ledger center needs to query the allocation share corresponding to the coded values ​​of each dimension in the preset profit-sharing rule table, then calculate and summarize the results by dimension to generate a multi-level profit-sharing settlement report. This application's embodiment facilitates encoding multi-dimensional business attributes such as routes, cabin classes, channels, and passenger classes into audit trail codes, enabling the bypass ledger center to perform refined statistics on call counts and profit-sharing shares according to different dimensions. This provides a multi-level profit-sharing settlement basis for multiple providers, improving the precision of profit-sharing settlement.

[0081] In some embodiments, the gateway system parses three dimensions—route code, cabin class, and sales channel identifier—from the message header or body of the business request. The gateway system can then generate a multi-dimensional audit trail code by concatenating these dimensions using delimiters, following the format of the basic audit trail code, route code, cabin class, and sales channel identifier. Upon receiving a record containing this multi-dimensional audit trail code, the bypass ledger center extracts the encoded values ​​of the route code, cabin class, and sales channel identifier, respectively, and queries the profit-sharing ratio corresponding to each dimension in the profit-sharing rule table. For example, if the profit-sharing ratio for the route dimension is 30%, the cabin class dimension is 40%, and the sales channel dimension is 30%, the resource allocation share for each dimension is calculated, generating a multi-level profit-sharing settlement report listing the number of calls and allocation shares by route, cabin class, and sales channel, respectively. This embodiment, through multi-dimensional encoding and profit-sharing rule table queries, facilitates the independent calculation of profit-sharing shares based on different business dimensions, meeting the complex business needs of multiple providers participating in settlement according to different dimensions.

[0082] In other embodiments, the aviation business dimension parameters obtained by the gateway system include passenger membership levels, such as regular members, silver members, gold members, or platinum members. The gateway system encodes the passenger membership level as a two-digit number and adds it to the end field of the audit trail code to generate a multi-dimensional audit trail code. After receiving the record, the bypass ledger center parses the passenger membership level code value and queries the profit-sharing rule table for the additional profit-sharing coefficients corresponding to different membership levels. For example, for call records of gold members and above, the allocation share is calculated based on 120% of the base share. The bypass ledger center counts the number of calls corresponding to different levels according to the membership level code value and generates a profit-sharing settlement report listing the number of calls and the resource share after additional profit-sharing by passenger membership level. This embodiment, by introducing the passenger membership level dimension, facilitates refined profit-sharing based on passenger value and incentivizes data users to call data products related to high-value passengers.

[0083] It should be noted that the cross-domain data product invocation distribution and dynamic routing method involved in the embodiments of this application does not involve underlying data encryption, de-identification algorithms, or privacy computing mechanisms. The aforementioned underlying data encryption, de-identification algorithms, or privacy computing mechanisms belong to the external known supporting environment of the multi-party collaboration foundation and are not improvements of this application. This application mainly transforms the underlying data into an application-layer gateway and commercial flow mechanism for commercial billing interfaces, including dual-track traffic splitting, audit trail code generation, bypass ledger reconciliation, lifecycle timestamps and business policy degradation control, and periodic issuance of batch authorization orders, etc. None of the above technical solutions rely on the specific implementation of underlying encryption or privacy computing.

[0084] For example, taking the high-value service scenario for airline passengers as an example, the cross-domain data product invocation, distribution, and dynamic routing method of this application will be described, which can be carried out through the following steps:

[0085] Step 1: When an airline application user triggers a high-intent action, such as checking upgrade eligibility, the front-end system sends a real-time application programming interface (API) request to the gateway system. This request carries a timeout tolerance period, for example, set to 1 second.

[0086] Step two: After receiving the business request, the gateway system generates a globally unique audit trail code, such as "20241025-API-LevelA-998273", where 20241025 represents the call date, API represents the data distribution channel type, LevelA represents the initial service level, and 998273 represents the caller identification sequence number. The gateway system associates this audit trail code with the business request and stores it, then sends the cross-domain computing instruction to the multi-party collaboration platform.

[0087] Step 3: After the multi-party collaborative platform completes the cross-domain joint computation, it returns the original computation result. The gateway system then maps the original computation result to a decision label and encapsulates a lifecycle timestamp for this decision label. For example, it encapsulates it as a standardized JSON message: {“Trace_ID”:“20241025-...”,“Biz_Decision”:“High_Value”,“Business_TTL”:“1730000000”}, where the lifecycle timestamp is set to 5 minutes after the current time, and the JSON message can refer to a structured data message organized using JavaScript object notation.

[0088] Step four: The gateway system returns a JSON message as a response to the airline system, and sends the audit trail code, call time, and service level information as records to the bypass ledger center. For example, the billing code is “20241025-…”, the billing level is Level A, and the billing is once.

[0089] Step 5: If the airline system attempts to reuse the cached decision tag to request high-value services again after 10 minutes, the gateway system extracts the lifecycle timestamp from the request. If it detects that the timestamp has exceeded the current system time, it triggers the dimensionality reduction strategy and returns a response message to the airline system: {“Biz_Decision”:“Unknown”,“Action”:“Require_ReAuth”}, requiring the airline system to re-initiate the authorization and billing request.

[0090] See Figure 4According to another aspect of the embodiments of this application, a cross-domain data product invocation distribution and dynamic routing apparatus is also provided, comprising: a business request receiving unit, configured to receive a business request from a data user, wherein the business request includes at least a data caller identifier and request scenario parameters, the request scenario parameters including a timeout tolerance duration for the business request; and a comparison processing unit, configured to determine a data distribution channel based on a comparison result between the timeout tolerance duration and a preset threshold, including: when the timeout tolerance duration is detected to be less than or equal to the preset threshold, routing the business request to a first type of channel, the first type of channel being used to respond to each data request within a preset duration. The data transmission is as follows: If the timeout tolerance period exceeds a preset threshold, the business request is routed to a second-type channel, which is used for batch transmission of multiple data items; the output processing unit sends cross-domain computation instructions to the multi-party collaboration base via a defined data distribution channel, and simultaneously generates a globally unique audit trail code. The audit trail code identifies the flow path of this data call throughout the entire chain, and is associated with and stored in relation to the business request; the multi-party collaboration base is the underlying system for performing cross-domain data joint computation; the cross-domain computation instructions instruct the multi-party collaboration base to perform data queries or joint computations associated with the business request.

[0091] Optionally, the cross-domain data product invocation, distribution, and dynamic routing device further includes: a calculation result receiving unit, used to receive the original calculation result returned by the multi-party collaboration base after sending a cross-domain calculation instruction to the multi-party collaboration base and generating a globally unique audit trail code, wherein the original calculation result is the underlying data returned by the multi-party collaboration base after performing cross-domain calculation, without dimensionality reduction processing, containing continuous numerical calculation results or structured fields; a dimensionality reduction mapping unit, used to reduce the dimensionality of the original calculation result to a decision label, wherein the decision label is a discrete level identifier, and the data volume of the decision label is smaller than the data volume of the original calculation result; a timestamp encapsulation unit, used to encapsulate a lifecycle timestamp for the decision label, wherein the lifecycle timestamp is used to limit the validity period of the decision label; and a response return unit, used to return the generated decision label and the encapsulated lifecycle timestamp as a response result to the data user.

[0092] Optionally, the cross-domain data product call distribution and dynamic routing device further includes: a bypass sending unit, used to send a record including the audit trail code, call time, and service level information to the bypass ledger center after sending the cross-domain computing instruction to the multi-party collaboration base and generating a globally unique audit trail code. The call time is the time when the business request is received or the time when the audit trail code is generated; the service level information is the service level pre-contracted by the data caller or the service level corresponding to the data distribution channel; the bypass ledger center is a record storage unit independent of the main data distribution link, used for call record verification and resource allocation settlement among multiple providers.

[0093] Optionally, the cross-domain data product call distribution and dynamic routing device further includes: a re-request receiving unit, used to receive a service request re-initiated by the data user after sending a record containing audit trail code, call time, and service level information to the bypass ledger center, wherein the service request carries a decision tag and a lifecycle timestamp; a timestamp extraction and comparison unit, used to extract the lifecycle timestamp from the service request, obtain the current system time, and determine whether the expiration time indicated by the lifecycle timestamp is later than the current system time; a validity period processing unit, used to determine the service policy level corresponding to the data user based on the decision tag when it is detected that the expiration time indicated by the lifecycle timestamp is later than the current system time; wherein the service policy level is used to indicate the resource type access permission and processing priority corresponding to the data user; and an expiration downgrade processing unit, used to downgrade the service policy level corresponding to the data user to a preset minimum level when it is detected that the expiration time indicated by the lifecycle timestamp is earlier than or equal to the current system time, and carry an indication code requiring a re-initiation of the authorization request in the response message returned to the data user; wherein the preset minimum level is the lowest level in a predefined service policy level sequence.

[0094] Optionally, the cross-domain data product invocation distribution and dynamic routing device further includes: a batch authorization order generation unit, used to generate batch authorization orders according to a preset cycle after determining that the data distribution channel is a second type channel based on the comparison result between the timeout tolerance period and the preset threshold, and to issue the batch authorization orders to the data users. The batch authorization order is a credential generated by the cross-domain data product invocation distribution and dynamic routing device for batch authorization of data users to consume decision tags in the second type channel within the validity period. The batch authorization order contains an authorization identifier and validity period information. When consuming decision tags in the second type channel, the data user carries the batch authorization order in the service request returned to the cross-domain data product invocation distribution and dynamic routing device; and a batch authorization order verification unit, used to verify whether the batch authorization order is valid after receiving a service request carrying the batch authorization order, and to refuse to process the service request if the batch authorization order has expired; and to process the service request if the batch authorization order has not expired.

[0095] Optionally, the output processing unit includes: an audit code information acquisition subunit, used to acquire the data caller identifier, the type of data distribution channel, the initial service level, and the call timestamp, wherein the initial service level is the service level pre-subscribed by the data caller, and the call timestamp is the timestamp of the gateway system receiving the business request or the timestamp of the audit trail code generation; and an audit code splicing subunit, used to splice the data caller identifier, the type of data distribution channel, the initial service level, and the call timestamp according to a preset format to generate an audit trail code.

[0096] Optionally, the dimensionality reduction mapping unit includes: a numerical analysis subunit, used to parse the continuous numerical calculation results returned by the multi-party collaborative base from the original calculation results; a segmented mapping subunit, used to map the continuous numerical calculation results to discrete business level identifiers according to preset segmentation rules; and a label output subunit, used to output the business level identifiers as decision labels, wherein the value range of the decision labels is smaller than the value range of the continuous numerical calculation results.

[0097] Optionally, the cross-domain data product call distribution and dynamic routing device further includes: an initial service level acquisition unit, used to acquire the service level pre-subscribed by the data caller as the initial service level before determining the data distribution channel based on the comparison result between the timeout tolerance duration and the preset threshold; a first threshold setting unit, used to set the preset threshold to a first value when the initial service level is detected to be a first level; and a second threshold setting unit, used to set the preset threshold to a second value when the initial service level is a second level, wherein the first level is higher than the second level, and the first value is lower than the second value.

[0098] Optionally, the timestamp encapsulation unit includes: a service level acquisition subunit, used to acquire the service level pre-subscribed by the data caller as the initial service level; a duration query subunit, used to query the valid duration corresponding to the initial service level from a preset timestamp value mapping table based on the initial service level; and a timestamp generation subunit, used to convert the valid duration into an absolute timestamp or a relative duration as a lifecycle timestamp.

[0099] Optionally, the cross-domain data product call distribution and dynamic routing device also includes a bypass ledger center, which includes: a statistics unit, used to, after sending records containing audit trail codes, call times, and service level information to the bypass ledger center, statistically analyze the number of calls made by the data user according to the audit trail code or service level information based on all records containing audit trail codes, call times, and service level information received within a preset period, and obtain statistical results; a report generation unit, used to generate reconciliation reports based on the statistical results, wherein the reconciliation reports include the number of calls, service level, and allocated resource share corresponding to each audit trail code; and a report output unit, used to output reconciliation reports within a target duration threshold after the end of each preset period.

[0100] Optionally, the timestamp encapsulation unit further includes: a flight information extraction subunit, used to extract target flight information from the business request, wherein the target flight information includes flight number, planned departure time and planned arrival time; a remaining duration calculation subunit, used to obtain the current system time, calculate the time difference between the current system time and the planned departure time, and obtain the remaining duration before departure; an effective duration setting subunit, used to set the effective duration of the lifecycle timestamp to the product of the remaining duration before departure and a first preset coefficient, or to the product of the difference between the planned arrival time and the current system time and a second preset coefficient; and an absolute expiration time determination subunit, used to determine the absolute expiration time of the lifecycle timestamp based on the current system time and the effective duration, and encapsulate the absolute expiration time as the lifecycle timestamp of the decision tag.

[0101] Optionally, the cross-domain data product invocation, distribution, and dynamic routing device further includes: a dimension parameter acquisition unit, used to acquire aviation business dimension parameters carried in the business request after concatenating the data caller identifier, data distribution channel type, initial service level, and call timestamp according to a preset format to generate an audit trail code, wherein the aviation business dimension parameters include at least one of route code, cabin class, sales channel identifier, and passenger membership level; a multi-dimensional audit code generation unit, used to add the aviation business dimension parameters to the audit trail code to obtain a multi-dimensional audit trail code; and a multi-dimensional record sending unit, used to send the record including the multi-dimensional audit trail code to... The bypass ledger center includes: a multi-dimensional parsing unit, which receives records and parses each field in the multi-dimensional audit trail code to obtain the coded values ​​for each business dimension; a profit-sharing calculation unit, which queries a preset profit-sharing rule table based on the coded values ​​of each business dimension and calculates the resource allocation share corresponding to each business dimension; and a multi-level report generation unit, which aggregates the resource allocation shares of each business dimension to generate a multi-level profit-sharing settlement report. The multi-level profit-sharing settlement report lists the number of times data users call the data and the resource share that data users should be allocated, according to route code, cabin class, sales channel identifier, or passenger membership level.

[0102] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, which stores a computer program, wherein when the computer program is executed, the device where the computer-readable storage medium is located executes the above-described cross-domain data product invocation distribution and dynamic routing method.

[0103] According to another aspect of the embodiments of this application, an electronic device is also provided, including one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by one or more processors, the one or more processors cause the one or more processors to execute the above-described cross-domain data product invocation distribution and dynamic routing method.

[0104] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program or instructions, which, when executed by a processor, implement the above-described cross-domain data product invocation distribution and dynamic routing method.

[0105] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments. In the above embodiments of this application, the descriptions of each embodiment have their own emphasis, and for parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0106] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0107] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0108] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0109] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or 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 this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0110] The above description is only a preferred 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 cross-domain data product invocation, distribution, and dynamic routing, characterized in that, Applied to a gateway system, the method includes: Receive a business request from a data user, wherein the business request includes at least a data caller identifier and request scenario parameters, and the request scenario parameters include the timeout tolerance period of the business request; Based on the comparison between the timeout tolerance duration and the preset threshold, a data distribution channel is determined, including: if the timeout tolerance duration is detected to be less than or equal to the preset threshold, the service request is routed to a first type of channel, which is used to respond to the transmission of each data within the preset duration; if the timeout tolerance duration is detected to be greater than the preset threshold, the service request is routed to a second type of channel, which is used to transmit multiple data in batches. A cross-domain computation instruction is sent to the multi-party collaboration base via a defined data distribution channel, and a globally unique audit trail code is generated simultaneously. The audit trail code is used to identify the flow path of this data call in the entire link, and the audit trail code is associated with and stored with the business request. The multi-party collaboration base is the underlying system for performing cross-domain data joint computation. The cross-domain computation instruction is used to instruct the multi-party collaboration base to perform data query or joint computation associated with the business request.

2. The method according to claim 1, characterized in that, After sending cross-domain computing instructions to the multi-party collaborative platform and generating a globally unique audit trail code, the method further includes: Receive the original calculation results returned by the multi-party collaborative base, wherein the original calculation results are the underlying data returned by the multi-party collaborative base after performing cross-domain calculations, without dimensionality reduction processing, and include continuous numerical calculation results or structured fields; The original calculation results are dimensionality reduced and mapped to decision labels, wherein the decision labels are discrete level identifiers, and the data volume of the decision labels is smaller than the data volume of the original calculation results; The decision label is encapsulated with a lifecycle timestamp, wherein the lifecycle timestamp is used to limit the validity period of the decision label; The generated decision label and the encapsulated lifecycle timestamp are returned as a response to the data user.

3. The method according to claim 2, characterized in that, After sending cross-domain computing instructions to the multi-party collaborative platform and generating a globally unique audit trail code, the method further includes: The record, including the audit trail code, call time, and service level information, is sent to the bypass ledger center. The call time is the time the business request is received or the time the audit trail code is generated. The service level information is the service level pre-signed by the data caller or the service level corresponding to the data distribution channel. The bypass ledger center is a record storage unit independent of the main data distribution link, used for call record verification and resource allocation settlement among multiple providers.

4. The method according to claim 3, characterized in that, After sending the record containing the audit trail code, call time, and service level information to the bypass ledger center, the method further includes: Receive a service request initiated again by the data user, wherein the service request carries the decision tag and the lifecycle timestamp; Extract the lifecycle timestamp from the service request, obtain the current system time, and determine whether the expiration time indicated by the lifecycle timestamp is later than the current system time; If the expiration time indicated by the lifecycle timestamp is later than the current system time, the service policy level corresponding to the data user is determined according to the decision tag; wherein, the service policy level is used to indicate the resource type access permission and processing priority corresponding to the data user; If the system detects that the expiration time indicated by the lifecycle timestamp is earlier than or equal to the current system time, the service policy level corresponding to the data user will be reduced to the preset lowest level, and an indication code requiring a re-initiation of the authorization request will be carried in the response message returned to the data user; wherein, the preset lowest level is the lowest level in a predefined service policy level sequence.

5. The method according to claim 4, characterized in that, After determining that the data distribution channel is the second type of channel based on the comparison result between the timeout tolerance duration and the preset threshold, the method further includes: The gateway system generates batch authorization orders according to a preset cycle and issues the batch authorization orders to the data users. The batch authorization order is a certificate generated by the gateway system to authorize the data users to consume decision tags in the second type of channel within a validity period. The batch authorization order contains authorization identifier and validity period information. When the data users consume decision tags in the second type of channel, they carry the batch authorization order in the service request returned to the gateway system. After receiving a service request carrying a batch authorization order, the gateway system verifies whether the batch authorization order is valid. If the batch authorization order has expired, the system refuses to process the service request; if the batch authorization order has not expired, the system processes the service request.

6. The method according to claim 1, characterized in that, Generate globally unique audit trail codes, including: Obtain the data caller identifier, the data distribution channel type, the initial service level, and the call timestamp, wherein the initial service level is the service level pre-subscribed by the data caller, and the call timestamp is the timestamp when the gateway system receives the business request or the timestamp when the audit trail code is generated; The audit trail code is generated by concatenating the data caller identifier, the data distribution channel type, the initial service level, and the call timestamp according to a preset format.

7. The method according to claim 2, characterized in that, The original calculation results are dimensionality-reduced and mapped to decision labels, including: The continuous numerical calculation results returned by the multi-party collaborative base are obtained by parsing the original calculation results; According to the preset segmentation rules, the continuous numerical calculation results are mapped to discrete business level identifiers; The business level identifier is output as the decision label, wherein the value range of the decision label is smaller than the value range of the continuous numerical calculation result.

8. The method according to claim 1, characterized in that, Before determining the data distribution channel based on the comparison result between the timeout tolerance duration and the preset threshold, the method further includes: The service level pre-signed by the data caller is obtained as the initial service level. If the initial service level is detected to be the first level, the preset threshold is set to a first value; When the initial service level is the second level, the preset threshold is set to a second value, wherein the first level is higher than the second level and the first value is less than the second value.

9. The method according to claim 2, characterized in that, Encapsulating a lifecycle timestamp for the decision label includes: The service level pre-signed by the data caller is obtained as the initial service level. Based on the initial service level, query the valid duration corresponding to the initial service level from the preset timestamp value mapping table; The effective duration is converted into an absolute timestamp or a relative duration, which is then used as the lifecycle timestamp.

10. The method according to claim 2, characterized in that, After sending the record containing the audit trail code, call time, and service level information to the bypass ledger center, the bypass ledger center performs the following steps: Based on all records received within a preset period that contain the audit trail code, call time, and service level information, the number of calls made by the data user is counted according to the audit trail code or service level information to obtain statistical results; A reconciliation report is generated based on the statistical results, wherein the reconciliation report includes the number of calls, service level and resource allocation share corresponding to each audit trail code; The reconciliation report is output within the target duration threshold after the end of each preset cycle.

11. The method according to claim 2, characterized in that, Encapsulating a lifecycle timestamp for the decision label includes: Extract the target flight information from the business request, wherein the target flight information includes the flight number, the scheduled departure time, and the scheduled arrival time; Obtain the current system time, calculate the time difference between the current system time and the planned takeoff time, and obtain the remaining time before takeoff; The effective duration of the lifecycle timestamp is set as the product of the remaining time before takeoff and a first preset coefficient, or as the product of the difference between the planned arrival time and the current system time and a second preset coefficient. Based on the current system time and the effective duration, the absolute expiration time of the lifecycle timestamp is determined, and the absolute expiration time is encapsulated as the lifecycle timestamp of the decision tag.

12. The method according to claim 6, characterized in that, After generating the audit trail code by concatenating the data caller identifier, the data distribution channel type, the initial service level, and the call timestamp according to a preset format, the method further includes: Obtain the aviation business dimension parameters carried in the business request, wherein the aviation business dimension parameters include at least one of route code, cabin class, sales channel identifier and passenger membership level; The aviation business dimension parameters are added to the audit trail code to obtain a multidimensional audit trail code; The record including the multidimensional audit trail code is sent to the bypass ledger center; Upon receiving the record, the bypass ledger center performs the following steps: By parsing the fields in the multidimensional audit trail code, the coded values ​​of each business dimension are obtained. Then, based on the coded values ​​of each business dimension, a preset profit-sharing rule table is queried to calculate the resource allocation share corresponding to each business dimension. After summarizing the resource allocation shares of each business dimension, a multi-level profit-sharing settlement report is generated. The multi-level profit-sharing settlement report lists the number of times the data user calls and the resource share that the data user should be allocated according to the route code, the cabin class, the sales channel identifier, or the passenger membership level.

13. A cross-domain data product invocation, distribution, and dynamic routing device, characterized in that, include: A business request receiving unit is used to receive business requests from data users, wherein the business request includes at least a data caller identifier and request scenario parameters, and the request scenario parameters include the timeout tolerance period of the business request; A comparison processing unit is configured to determine a data distribution channel based on a comparison result between the timeout tolerance duration and a preset threshold, including: when the timeout tolerance duration is detected to be less than or equal to the preset threshold, routing the service request to a first type of channel, the first type of channel being used to respond to the transmission of each data item within a preset duration; and when the timeout tolerance duration is detected to be greater than the preset threshold, routing the service request to a second type of channel, the second type of channel being used to transmit multiple data items in batches. The output processing unit is used to send cross-domain computation instructions to the multi-party collaboration base via a defined data distribution channel, and simultaneously generate a globally unique audit trail code. The audit trail code is used to identify the flow path of this data call in the entire link, and the audit trail code is associated with and stored with the business request. The multi-party collaboration base is the underlying system for performing cross-domain data joint computation. The cross-domain computation instructions are used to instruct the multi-party collaboration base to perform data query or joint computation associated with the business request.

14. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein when the computer program is executed, the device in which the computer-readable storage medium is located performs the cross-domain data product invocation distribution and dynamic routing method according to any one of claims 1 to 12.

15. An electronic device, characterized in that, It includes one or more processors and a memory, the memory being used to store one or more programs, wherein when the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to perform the cross-domain data product invocation distribution and dynamic routing method according to any one of claims 1 to 12.

16. A computer program product, characterized in that, It includes a computer program or instructions that, when executed by a processor, implement the cross-domain data product invocation distribution and dynamic routing method of any one of claims 1 to 12.

Images