Multi-cloud network service e-commerce transaction method, device, medium and product

Abstract

The invention discloses a multi-cloud network service e-commerce transaction method and device, a medium and a product. The method comprises the following steps: acquiring network service description data, and carrying out standardization processing on the network service description data to generate standardized service commodity data; performing demand feature extraction on the service demand data to obtain a demand feature vector; matching and screening the standardized service commodity data to obtain a candidate service commodity set, comprehensively scoring each service commodity, and generating a recommended service commodity sorting list; in response to a selection operation of the buyer on the target service commodity, generating transaction order data; obtaining a corresponding interface adapter, sending a configuration instruction to a service provider system, and receiving delivery state data; and charging the usage amount data of the target service commodity according to the delivery state data to generate settlement bill data. By implementing the scheme, the problems of slow decision making, long delivery period, incapability of automatically charging and the like caused by different standards of cross-cloud network services are solved.

Description

Technical Field

[0001] This application relates to the field of cloud computing technology, specifically to a method, device, medium, and product for e-commerce transactions of multi-cloud network services. Background Technology

[0002] Currently, transactions for multi-cloud network services are primarily conducted through offline manual procurement, official cloud vendor marketplaces, or traditional B2B (Business-to-Business) e-commerce platforms. In the offline manual procurement model, companies sign contracts with cloud service providers and manually configure services through sales representatives or agents. In the official cloud vendor marketplace model, buyers purchase third-party network services within a single cloud platform. In the traditional B2B e-commerce platform model, service providers post information about their network services, and buyers and sellers communicate online before completing service delivery offline. These methods, to a certain extent, meet the transaction needs for network services.

[0003] However, due to significant differences among different cloud service providers and network operators in their description of service performance parameters, service level agreement definition standards, price model expression forms, and service delivery interface specifications, and the lack of a unified, machine-readable standard, buyers find it difficult to compare service quality and evaluate prices based on a unified standard when faced with similar network services offered by multiple service providers. This not only affects the efficiency of transaction decisions but also hinders the technical implementation of automated transaction and delivery processes for cross-cloud network services. Summary of the Invention

[0004] To address the aforementioned technical issues, this application provides a method, device, medium, and product for e-commerce transactions of multi-cloud network services.

[0005] The first aspect of this application provides a method for e-commerce transactions of multi-cloud network services, which adopts the following technical solution: Obtain network service description data, and standardize the network service description data according to the preset network service description specifications to generate standardized service product data; Receive service request data submitted by the buyer, extract the service request features from the service request data, and obtain a request feature vector; The standardized service product data is matched and filtered according to the demand feature vector to obtain a set of candidate service products. Based on the standardized performance parameters, price model parameters and service provider credit data of each service product in the candidate service product set, a comprehensive score is given to each service product to generate a recommended service product ranking list. In response to the buyer's selection of a target service product from the recommended service product sorting list, transaction order data is generated; Obtain the corresponding interface adapter based on the transaction order data, send configuration instructions to the service provider system through the interface adapter, and receive delivery status data returned by the service provider system; Based on the delivery status data, the usage data of the target service product is billed, and settlement bill data is generated.

[0006] By adopting the above technical solutions, a unified service description specification is defined, transforming heterogeneous network services into standardized product data. This enables buyers to compare and evaluate services based on unified parameters. Automated demand matching and comprehensive scoring mechanisms improve transaction decision-making efficiency. Interface adapters facilitate automatic connection and configuration with service provider systems, streamlining the automated delivery process. Furthermore, usage monitoring and billing processes create a closed-loop transaction system. This effectively solves the technical problems of difficulty in comparison, slow decision-making, long delivery cycles, and lack of automatic billing caused by inconsistent standards in cross-cloud network services.

[0007] Optionally, the step of standardizing the network service description data according to a preset network service description specification to generate standardized service product data includes: The network service description specification is parsed to obtain performance parameter mapping rules, service level classification rules, pricing model templates, and interface specification templates. Parse the performance metric field, service commitment field, pricing information field, and interface configuration field in the network service description data; Extract the original performance metrics corresponding to the performance metric fields, and convert the original performance metrics into standardized performance parameters according to the performance parameter mapping rules; Extract the service commitment information corresponding to the service commitment field, classify the service commitment information according to the service level classification rules, and generate service level agreement parameters; Extract the pricing information corresponding to the pricing information field, and convert the pricing information into price model parameters in a unified format according to the price model template; Extract the interface configuration information corresponding to the interface configuration fields, standardize the interface configuration information according to the interface specification template, and generate delivery interface parameters; The standardized performance parameters, service level agreement parameters, pricing model parameters, and delivery interface parameters are structured and encapsulated to generate the standardized service product data.

[0008] By employing the above technical solution, heterogeneous service description data is systematically parsed and transformed. Performance indicators, service commitments, pricing information, and interface configurations from different sources are unified into machine-readable standardized parameters, tiered agreements, formatted pricing models, and standardized interface parameters, ultimately encapsulated into structured product data. This effectively solves the problem of difficulty in directly comparing and automatically processing data caused by inconsistent performance descriptions, varying SLA (Service Level Agreement) standards, diverse pricing models, and different interface specifications.

[0009] Optionally, the step of comprehensively scoring each service product based on its standardized performance parameters, price model parameters, and service provider credit data in the candidate service product set to generate a recommended service product ranking list includes: Extract standardized performance parameters of each service product in the candidate service product set, and calculate the similarity between the standardized performance parameters and the performance requirement values ​​in the demand feature vector to obtain a service performance matching score. Extract the price model parameters of each service in the candidate service product set, calculate the conformity between the price model parameters and the price constraint values ​​in the demand feature vector, and obtain the price advantage score. Based on a preset service provider credit database, historical transaction success rate data and historical user evaluation data of the service providers corresponding to each service product in the candidate service product set are obtained, and the service provider credit score is calculated based on the historical transaction success rate data and historical user evaluation data. The service performance matching score, the price advantage score, and the service provider credit score are weighted and summed according to preset weight coefficients to obtain the comprehensive matching score of each service product. The service products in the candidate service product set are sorted from high to low according to the comprehensive matching score to generate the recommended service product sorting list.

[0010] By adopting the above technical solution, a multi-dimensional quantitative scoring model is constructed, effectively solving the problems of inconsistent standards and low efficiency in manual evaluation. Key factors such as performance, price, and credit are transformed into calculable matching degree, advantage degree, and credit score, respectively, and then comprehensively weighted and ranked based on preset weights. This mechanism enables buyers to conduct rapid and comprehensive quantitative comparisons and optimal selections of candidate services based on unified and objective data standards, thereby significantly improving the scientific nature and efficiency of multi-cloud network service transaction decisions.

[0011] Optionally, the step of sending configuration instructions to the service provider system through the interface adapter and receiving delivery status data returned by the service provider system includes: Parse the transaction order data to extract service type identifier, resource specification parameters, and deployment region parameters. Based on the service provider identifier of the target service product, query the preset interface adapter configuration library to obtain the parameter mapping rule table and application programming interface call template corresponding to the interface adapter; Based on the parameter mapping rule table, the resource specification parameters and the deployment region parameters are converted into the parameter format defined by the service provider system, and the configuration instructions containing the parameter format are generated by calling the template according to the application programming interface; The configuration command is sent to the service provider system through the interface adapter, and the unique resource identifier and initial status code returned by the service provider system are received. Establish an association mapping relationship between the unique identifier of the resource and the order identifier in the transaction order data, and store the association mapping relationship in a preset order resource mapping table; According to a preset query cycle, a status query request is sent to the service provider system. The status query request carries the unique identifier of the resource. The delivery progress information returned by the service provider system is received. The configuration stage identifier and completion value are extracted from the delivery progress information to generate the delivery status data.

[0012] By adopting the above technical solution, automated delivery and status monitoring of cross-cloud network services are achieved. Pre-defined mapping rules and application programming interface (API) templates automatically convert unified order parameters into service provider-specific instructions and establish a mapping between orders and physical resources. Delivery status is tracked in real time through periodic queries. This mechanism overcomes the technical obstacle of inconsistent interface specifications preventing automated configuration and delivery, ensuring the automated execution of the transaction loop.

[0013] Optionally, after receiving the resource unique identifier and initial status code returned by the service provider system, the method further includes: Determine whether the initial status code is a status code in the preset success status code set; When the initial status code does not belong to the preset success status code set, the error type identifier and error description information are extracted from the response data returned by the service provider system; Based on the error type identifier, query the preset exception handling rule library to obtain the corresponding handling strategy identifier; When the processing strategy identifier is a retry strategy identifier, a preset retry parameter configuration is obtained, which includes the retry interval duration and the maximum number of retries. The parameters in the configuration command are adjusted according to the error description information, and the adjusted configuration command is resent to the service provider system after waiting for the retry interval. Record the current number of retries. When the current number of retries reaches the maximum number of retries, generate a delivery anomaly identifier and send an anomaly alarm message containing the transaction order data and the error description information to the preset operation and maintenance management system.

[0014] By adopting the above technical solutions, the robustness and delivery success rate of the service configuration process are improved. When a configuration request is abnormal, the system can automatically identify the error type, dynamically adjust parameters, and perform retries, thereby effectively handling network jitter or momentary anomalies in the service provider's system. This avoids the inefficiency and delays of manual intervention and provides timely alerts in the event of eventual failure, achieving reliable control and closed-loop management of the entire automated delivery chain for cross-cloud services.

[0015] Optionally, the step of billing the usage data of the target service product based on the delivery status data and generating settlement bill data includes: Based on the unique resource identifier in the delivery status data, query the preset resource usage monitoring system to obtain the usage data of the target service product, and extract resource usage duration data, network traffic consumption data and application programming interface call count data from the usage data. The pre-designed fee rule base is queried according to the service type identifier of the target service product to obtain the corresponding billing model parameters. The billing model parameters include the duration unit price coefficient, traffic unit price coefficient, call unit price coefficient, and billing cycle configuration. The resource usage duration data is multiplied by the duration unit price coefficient to obtain the duration-based cost value; The initial traffic cost is obtained by multiplying the network traffic consumption data with the traffic unit price coefficient. The pricing range of the network traffic consumption data is determined according to the preset traffic tier pricing rules. The discount coefficient corresponding to the pricing range is obtained. The initial traffic cost is multiplied by the discount coefficient to obtain the traffic dimension cost value. The application programming interface call count data is multiplied by the call unit price coefficient to obtain the call dimension cost value; The total cost is obtained by summing the cost values ​​for duration, traffic, and invocation. Based on the billing cycle configuration, the total cost value is aggregated over a time period to generate settlement billing data that includes the billing cycle start time, billing cycle end time, cost details for each dimension, and the total cost value.

[0016] By adopting the above technical solution, usage data from different dimensions is automatically collected and integrated. Based on a preset model (including tiered pricing), calculations are performed and aggregated to generate a structured and detailed bill. This solves the problems of inefficiency, error-proneness, and lack of transparency caused by complex pricing models and reliance on manual billing, and completes a full transaction loop from service matching and automated delivery to accurate billing.

[0017] Optionally, the method further includes: The service level agreement parameters of the target service product are parsed, and a set of performance indicator thresholds is extracted from the service level agreement parameters. The set of performance indicator thresholds includes a latency upper limit threshold, an availability lower limit threshold, and a bandwidth guarantee threshold. According to the preset monitoring and collection cycle, a network performance detection tool is used to initiate a detection request to the network resources corresponding to the target service product, and collect real-time latency measurement values, real-time availability measurement values, and real-time bandwidth measurement values. The real-time delay measurement value is compared with the delay upper limit threshold. When the real-time delay measurement value is greater than the delay upper limit threshold, the default time point is recorded, and the duration of continuous default is calculated. When the duration of continuous default reaches the preset default judgment duration threshold, a default record is generated that includes a default type identifier, default start time, default end time and default duration. According to the compensation rule table defined in the service level agreement parameters, the compensation ratio coefficient corresponding to the breach duration is queried, and the compensation amount is calculated based on the compensation ratio coefficient and the billing amount of the target service product. The account adjustment interface of the preset settlement system is invoked to transfer the compensation amount from the account balance of the service provider corresponding to the target service product to the account balance of the buyer; The default record is associated with the service provider identifier of the target service product, and the cumulative number of defaults and credit score corresponding to the service provider identifier in the service provider credit database are updated.

[0018] By adopting the above technical solution, when a continuous breach of service indicators is detected, the system automatically generates a breach record, calculates the compensation amount according to the agreement terms, and executes automatic compensation by calling the settlement interface. This mechanism not only transforms the traditional, inefficient manual monitoring and claims process into real-time, accurate, automated closed-loop processing, but also creates positive feedback on performance quality by updating service provider credit data, effectively protecting the buyer's rights and service experience.

[0019] A second aspect of this application provides an electronic device including a processor, a memory, a user interface, and a network interface, wherein the memory is used to store instructions, the user interface and the network interface are both used to communicate with other devices, and the processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any of the foregoing.

[0020] A third aspect of this application provides a computer-readable storage medium storing instructions that, when executed, perform the method described in any of the preceding descriptions.

[0021] A fourth aspect of this application provides a computer program product that, when run on an electronic device, causes the electronic device to perform the method as described in any of the preceding claims.

[0022] In summary, one or more technical solutions provided in the embodiments of this application have at least the following technical effects or advantages: By defining machine-readable unified description specifications and service level standards, heterogeneous network services are transformed into quantifiable and comparable standardized commodities. A multi-dimensional quantitative scoring model is constructed to achieve automated optimal recommendation based on performance, price, and credit, significantly improving transaction decision efficiency. Interface adapters and exception handling mechanisms shield underlying differences and enable automated and robust control over service configuration and delivery. Usage monitoring and multi-dimensional billing models enable transparent and accurate automated settlement. Continuous SLA monitoring and automatic compensation mechanisms ensure service quality and form a closed loop of performance credit. This end-to-end technical solution solves a series of problems caused by inconsistent standards and fragmented processes in cross-cloud network services, such as difficulty in comparison, slow decision-making, long delivery cycles, opaque billing, and difficulty in service assurance. It achieves a complete automated transaction closed loop from commoditization, transaction, delivery, billing to after-sales support. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the system architecture of an embodiment of a multi-cloud network service e-commerce transaction method applying this application; Figure 2 This is a flowchart illustrating a method for e-commerce transactions of multi-cloud network services disclosed in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device disclosed in an embodiment of this application.

[0024] Explanation of reference numerals in the attached figures: 100, System architecture; 101, First terminal device; 102, Second terminal device; 103, Third terminal device; 104, Network; 105, Server; 301, Processor; 302, Communication bus; 303, User interface; 304, Network interface; 305, Memory. Detailed Implementation

[0025] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments.

[0026] In the description of the embodiments of this application, the words "for example" or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design that is described as "for example" or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design options. Rather, the use of the words "for example" or "for instance" is intended to present the relevant concepts in a specific manner.

[0027] In the description of the embodiments of this application, the term "multiple" means two or more. For example, multiple systems means two or more systems, and multiple screen terminals means two or more screen terminals. Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the indicated technical features. Thus, a feature defined with "first" or "second" may explicitly or implicitly include one or more of that feature. The terms "comprising," "including," "having," and variations thereof all mean "including but not limited to," unless otherwise specifically emphasized.

[0028] like Figure 1 As shown, system architecture 100 may include terminal devices 101, 102, and 103, a network 104, and a server 105. Network 104 serves as the medium for providing communication links between terminal devices 101, 102, and 103 and server 105. Network 104 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc.

[0029] Users can use terminal devices 101, 102, and 103 to interact with server 105 via network 104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 101, 102, and 103, such as model training applications, video recognition applications, web browser applications, social platform software, etc.

[0030] Terminal devices 101, 102, and 103 can be either hardware or software. When terminal devices 101, 102, and 103 are hardware, they can be various electronic devices with displays, including but not limited to smartphones, tablets, e-book readers, MP3 (Moving Picture Experts Group Audio Layer III) players, MP4 (Moving Picture Experts Group Audio Layer IV) players, laptops, and desktop computers, etc. When terminal devices 101, 102, and 103 are software, they can be installed in the aforementioned electronic devices. They can be implemented as multiple software programs or software modules (e.g., multiple software programs or software modules used to provide distributed services) or as a single software program or software module. No specific limitations are imposed here.

[0031] This embodiment discloses a method for e-commerce transactions of multi-cloud network services. Figure 2 This is a flowchart illustrating a method for e-commerce transactions of multi-cloud network services disclosed in an embodiment of this application, as shown below. Figure 2 As shown, the method includes the following steps: S201. Obtain network service description data, and standardize the network service description data according to the preset network service description specification to generate standardized service product data. In one specific embodiment of this application, the execution of step S201 begins with the system obtaining network service description data through various preset methods. These methods may include, but are not limited to: the first method is to automatically pull service catalog data in JSON or XML format by calling the API (Application Programming Interface) pre-registered by each service provider; the second method is for the service provider to upload service description data conforming to a predefined template (e.g., CSV or Excel file) through the management portal provided by this platform; the third method is for the system to start a configured web crawler module for service providers that do not provide structured data, to crawl and parse unstructured HTML data from their publicly available product web pages. Subsequently, the system loads the "pre-defined network service description specification" stored internally. This specification is a core data model and rule set, which consists of four main parts: First, performance parameter mapping rules, which define the mapping and conversion formulas between platform standard performance terms (such as standard_bandwidth_mbps) and heterogeneous terms (such as Bandwidth, throughput) and units (such as Gbps to Mbps) of various service providers; Second, service level classification rules, which unify the diverse service commitments of service providers (such as availability of four nines) into the platform-defined level system (such as platinum, gold, and silver levels); Third, pricing model template, which provides a unified structured description framework for various billing methods (such as annual / monthly subscription, pay-as-you-go, tiered pricing, and 95% peak bandwidth billing); Fourth, interface specification template, which abstracts and defines a set of standard parameters required for automated delivery. During standardization, the system initiates a transformation process for each piece of raw descriptive data. This process first calls the corresponding parser (such as a JSON parser or HTML parser) to extract fields such as raw performance metrics, service commitments, pricing information, and interface configurations. Then, for each extracted field, the system searches for and applies the corresponding transformation rules in the description specification. For example, a bandwidth metric of 10Gbps is converted to the value 10240 according to the mapping rules and stored in the `standard_bandwidth_mbps` field; 99.99% availability is marked as Platinum level according to the grading rules. Finally, the system encapsulates all the transformed and standardized data, including standardized performance parameters, service level agreement parameters, uniformly formatted price model parameters, and standardized delivery interface parameters, along with metadata such as service provider identifiers and service IDs, into a structured, machine-readable standardized service product data object (e.g., a well-organized JSON object). This object is persistently stored in the platform's product database, thus laying a unified and solid data foundation for subsequent automated matching, price comparison, and delivery processes, ensuring the feasibility and efficiency of the entire e-commerce transaction process.

[0032] Optionally, the step of standardizing the network service description data according to a preset network service description specification to generate standardized service product data includes: parsing the network service description specification to obtain performance parameter mapping rules, service level classification rules, price model templates, and interface specification templates; parsing the performance indicator field, service commitment field, pricing information field, and interface configuration field in the network service description data; extracting the original performance indicators corresponding to the performance indicator field and converting the original performance indicators into standardized performance parameters according to the performance parameter mapping rules; extracting the service commitment information corresponding to the service commitment field and classifying the service commitment information into levels according to the service level classification rules to generate service level agreement parameters; extracting the pricing information corresponding to the pricing information field and converting the pricing information into price model parameters in a unified format according to the price model template; extracting the interface configuration information corresponding to the interface configuration field and standardizing the interface configuration information according to the interface specification template to generate delivery interface parameters; and structurally encapsulating the standardized performance parameters, service level agreement parameters, price model parameters, and delivery interface parameters to generate the standardized service product data.

[0033] Specifically, the system executes the step of parsing the network service description specification. In this embodiment, the network service description specification is not a single file, but a comprehensive set of rules stored in a configuration database or a set of versioned YAML / JSON files. The system loads this specification at startup or on demand to obtain all the instructions and templates required for subsequent conversion operations. Specifically, the system parses out four core modules: 1) Performance parameter mapping rules, which exist in the form of key-value pairs or more complex mapping tables, defining in detail the correspondence between platform standard performance terms (such as standard_bandwidth_mbps) and service provider private terms (such as Alibaba Cloud's Bandwidth, AWS's ConnectionSpeed), and including unit conversion logic (such as the multiplication factor of 1024 from Gbps to Mbps). 2) Service level classification rules, which define a series of conditional judgment logic, for example, IF original_availability>=99.99% THEN sla_level="PLATINUM", thereby quantifying the diverse SLA commitments of service providers and classifying them into the platform's unified classification system. 3) Pricing Model Template: This is a set of predefined JSON Schemas that provide a standardized data structure for various billing models such as annual / monthly subscriptions, pay-as-you-go pricing, and tiered pricing. 4) Interface Specification Template: This defines an abstract set of service activation parameters, such as {"region_id": string, "instance_type": enum, "parameters": object}, providing a unified data contract for subsequent automated delivery interface adaptation.

[0034] Further, the system performs the step of parsing the network service description data. The system dynamically selects an appropriate parser based on the data's source and format. For example, for JSON data obtained through an API, the system calls the built-in JSON parsing library for processing; for CSV files uploaded by service providers, the system uses the CSV parsing module; and for HTML data scraped from web pages, the system utilizes libraries such as Beautiful Soup or lxml to locate and extract information using predefined XPath or CSS selector paths. The core objective of this step is to accurately extract performance indicator fields, service commitment fields, pricing information fields, and interface configuration fields carrying key information from the raw, diverse data carriers, and use them as input for subsequent standardization transformations.

[0035] Furthermore, after obtaining the specifications and raw fields, the system begins to perform standardization transformations one by one. For performance metrics, the system extracts their raw performance metric values ​​(e.g., "10Gbps") and then queries the loaded performance parameter mapping rules. According to the rules, the system identifies the Gbps unit and applies a conversion formula to convert it to 10240, ultimately generating a standardized performance parameter `standard_bandwidth_mbps` with a value of 10240. For service commitments, the system extracts their service commitment information (e.g., annual service availability of no less than 99.95%), then applies service level classification rules for matching, ultimately generating structured SLA parameters containing fields such as `{availability: 99.95, sla_level: "GOLD"}`.

[0036] Similarly, for pricing information, the system extracts the original pricing description (e.g., monthly fee of ¥10,000, additional data usage of ¥0.5 / GB) and formats it according to the pricing model template. The system recognizes this as a hybrid "base fee + pay-as-you-go" model and converts it into a standardized pricing model parameter containing fields such as {type: "monthly_plus_usage", base_fee: 10,000, currency: "CNY", usage_rates: {"traffic_gb": 0.5}}. For API configuration, the system extracts the original API configuration information (e.g., the API endpoint URL and specific parameters {"RegionId": "cn-hangzhou", "Spec": "Large"} required to activate the service) and standardizes it according to the API specification template, converting it into delivery interface parameters containing standard key names such as {"region_id": "cn-hangzhou", "instance_type": "L", "parameters": {...}}. This greatly simplifies the subsequent work of the automated delivery adapter.

[0037] Furthermore, after all dimensions of information have undergone standardized transformation, the system performs a structured encapsulation step. It integrates and encapsulates all the standardized data generated in the preceding steps—namely, standardized performance parameters, service level agreement parameters, pricing model parameters, and delivery interface parameters—along with basic metadata such as service provider identifiers, service names, and product descriptions, into a single, rigorously structured JSON object. This object is the final standardized service product data, which will be assigned a unique product ID and stored in the platform's product database for unified use in subsequent intelligent matching, transaction processing, and automated delivery processes. Through this series of refined parsing, transformation, and encapsulation operations, this application effectively resolves data barriers and standard differences between different service providers, achieving true commoditization of heterogeneous network services and providing a solid technical foundation for building an efficient and transparent multi-cloud network service e-commerce trading platform.

[0038] S202. Receive service request data submitted by the buyer, extract the service request data to obtain a request feature vector; In one specific embodiment of this application, step S202 begins with the system receiving service requirement data submitted by the buyer through two main channels: the first channel is through a graphical user interface deployed on the platform website or application, where the buyer fills in a form, selects options, or inputs their requirements via a slider, for example, entering a bandwidth value of 500Mbps in a text box, selecting the region from Beijing to Singapore in a drop-down menu, and setting a budget limit of "$2000"; the second channel is through the platform's API, allowing enterprise users or automated procurement systems to submit a structured request (e.g., a JSON-formatted data packet) programmatically. Regardless of the channel, the received raw service requirement data is inherently user-friendly but non-standardized. Therefore, the system then initiates a dedicated processing module for requirement feature extraction. The core task of this module is to parse, clean, and transform these raw inputs into a unified, structured requirement feature vector that can be used for subsequent algorithmic calculations. The extraction process specifically includes: First, standardizing geographic location information, for example, accurately mapping the user-inputted Beijing or Beijing to the platform's unified regional identifier cn-north-1 through the internal geographic location coding library; Second, quantifying performance indicators and unifying units, for example, parsing the string 500Mbps into the value 500 (unit unified as Mbps), converting 1Gbps into 1024, and parsing constraints such as latency less than 30ms into a structured object containing the operator (less_than) and the value (30); Third, standardizing commercial constraints such as budget, for example, combining the budget amount of 2000 with the currency unit USD into a standard price constraint field. Finally, the system aggregates all extracted and standardized features, including service type identifiers, regional endpoint codes, quantified performance requirements, and price constraints, into a multi-dimensional, machine-readable structured data object (i.e., a demand feature vector).

[0039] S203. Match and filter the standardized service product data according to the demand feature vector to obtain a candidate service product set. Based on the standardized performance parameters, price model parameters and service provider credit data of each service product in the candidate service product set, give a comprehensive score to each service product and generate a recommended service product ranking list. In one specific embodiment of this application, during the matching and filtering stage, the system uses the generated demand feature vector as query conditions to perform an efficient multi-dimensional filtering of all standardized service product data stored in the product database. This filtering process can be specifically implemented as follows: the system constructs a database query statement or a series of filtering logics. This logic strictly requires that candidate products must simultaneously meet all non-negotiable constraints in the demand feature vector. For example, the geographical coverage of the service product (such as endpoint_A and endpoint_B) must completely match the geographical endpoints in the demand; the minimum guaranteed bandwidth (standard_bandwidth_mbps) in its standardized performance parameters must be greater than or equal to the bandwidth value required by the user; and its service level agreement parameter (sla_level) must meet or exceed the minimum level requirement specified by the user. Through this round of precise filtering, the system can quickly eliminate a large number of irrelevant service products, thereby generating a significantly reduced but highly relevant set of candidate service products. Subsequently, the system enters the comprehensive scoring stage, whereby for each service product in the candidate set, a preset, configurable comprehensive scoring model is invoked to calculate its recommendation score. The model is implemented by quantitatively evaluating and weighting the results of three core dimensions: The first dimension is a performance matching score, which considers not only whether the requirements are met but also the extent to which they are exceeded. For example, for indicators like bandwidth, where higher is better, the score is directly proportional to its standardized performance parameter value; for indicators like latency, where lower is better, the score is inversely proportional to its parameter value. This score is normalized to reflect its performance advantage. The second dimension is a cost-effectiveness score. The system uses the price model parameters of each product and an estimated usage model (which can be provided by the user or defaulted by the system based on historical data) to calculate an estimated monthly or annual total cost. This score is inversely proportional to the estimated cost, allowing products with high cost-effectiveness to receive higher scores. The third dimension is a service provider credit score. The system retrieves service provider credit data associated with the product provider from an independent service provider reputation database. This data is a dynamic score calculated by integrating factors such as historical SLA compliance rate, customer satisfaction evaluation, fault response time, and industry certifications. Finally, the system uses a configurable weighting formula to weight and sum the scores from the three dimensions, obtaining a final comprehensive score for each candidate service item. After calculating the scores for all candidate items, the system sorts them in descending order of comprehensive score, ultimately generating an intuitive, objective, and highly valuable list of recommended service items, which is then presented to the buyer as a basis for decision-making.

[0040] Optionally, the step of comprehensively scoring each service product based on standardized performance parameters, price model parameters, and service provider credit data in the candidate service product set to generate a recommended service product ranking list includes: extracting standardized performance parameters from each service product in the candidate service product set; calculating the similarity between the standardized performance parameters and the performance requirement values ​​in the demand feature vector to obtain a service performance matching score; extracting price model parameters from each service product in the candidate service product set; calculating the conformity between the price model parameters and the price constraint values ​​in the demand feature vector to obtain a price advantage score; obtaining historical transaction success rate data and historical user evaluation data of the service providers corresponding to each service product in the candidate service product set based on a preset service provider credit database; calculating a service provider credit score based on the historical transaction success rate data and the historical user evaluation data; weighting and summing the service performance matching score, the price advantage score, and the service provider credit score according to preset weight coefficients to obtain a comprehensive matching score for each service product; and ranking the service products in the candidate service product set from high to low according to the comprehensive matching score to generate the recommended service product ranking list.

[0041] Specifically, the first step is to calculate the service performance matching score (Score_performance) for each candidate service. To achieve this, the system first extracts specific performance values ​​related to the buyer's demand feature vector from the standardized performance parameter database of each candidate service, such as bandwidth, latency, and concurrent connections. Next, the system calculates the similarity between these actual performance parameters and the expected values ​​in the demand. Since the evaluation criteria for different performance indicators differ, the calculation methods should also vary. For example, for indicators like bandwidth, where higher values ​​are better, the sub-score can be calculated using the following example formula: Score_bw = min(100, (Actual_Bandwidth / Required_Bandwidth) × 100). In this formula, Score_bw is the bandwidth sub-score, Actual_Bandwidth is the actual bandwidth value provided by the product, Required_Bandwidth is the bandwidth value required by the buyer, and the min() function is used to cap the score at 100. Conversely, for metrics like latency, where lower values ​​are better, the sub-score can be calculated using Score_latency = min(100, (Required_Latency / Actual_Latency) × 100), where Required_Latency is the maximum acceptable latency for the buyer, and Actual_Latency is the actual latency of the product. Finally, the system will perform a weighted average of all performance sub-scores according to preset weights to obtain an overall service performance matching score.

[0042] The second step in this process is to calculate the price advantage score (Score_price) for each candidate service. The system first extracts the price model parameters for each candidate service, which may include fixed monthly fees, on-demand pricing, or tiered pricing strategies. Combining this with the estimated usage provided in the buyer's demand feature vector, the system can calculate an estimated periodic total cost (Estimated_Cost). Then, the system calculates the compliance of this estimated cost with the price constraint value set in the demand feature vector, i.e., the budget limit (User_Budget). A specific and effective calculation logic is: if Estimated_Cost exceeds User_Budget, then Score_price is directly recorded as 0; otherwise, the score can be calculated using the formula Score_price = (1 - (Estimated_Cost / User_Budget)) × 100. The core idea of ​​this formula is that, without exceeding the budget, the lower the cost, the smaller its proportion of the budget, the more obvious the price advantage, and the higher the score.

[0043] The third step in this process is to calculate the service provider credit score (Score_credit) for each candidate service. This step aims to take into account the service provider's historical performance and market reputation. The system queries a pre-set, dynamically updated service provider credit database to retrieve two key data points associated with the current candidate service provider: historical transaction success rate data (Success_Rate) and historical user rating data (Avg_Rating). Based on these two data points, the system calculates the credit score using a weighted summation. For example, the following formula can be used: Score_credit = (Success_Rate × 100) × W_rate + (Avg_Rating / Max_Rating × 100) × W_rating. In this formula, Success_Rate is the service provider's historical transaction fulfillment rate; Avg_Rating is the average user rating obtained by the service provider; Max_Rating is the maximum score of the rating system (e.g., 5 in a 5-star system), used to normalize user ratings; and W_rate and W_rating are preset weighting coefficients, the sum of which is 1, representing the platform's emphasis on the objective indicator of transaction success rate and the subjective indicator of user evaluation, respectively.

[0044] Furthermore, after calculating the scores for the three dimensions mentioned above, the system merges them to obtain a comprehensive matching score (Comprehensive_Score) for each service product. This step is accomplished by weighting and summing the service performance matching score, price advantage score, and service provider credit score. The calculation formula can be expressed as: Comprehensive_Score = Score_performance × W_perf + Score_price × W_price + Score_credit × W_credit. In this formula, W_perf, W_price, and W_credit are the final weighting coefficients assigned to the scores of the three dimensions according to a preset strategy, and their sum is 1. These weights can be set uniformly by the platform or can be customized by the buyer according to their own purchasing priorities. After calculating the comprehensive matching score for all candidate service products, the system sorts the products in descending order of the score, thereby generating a final, multi-dimensional, quantitatively objective recommended service product ranking list, which is then presented to the buyer.

[0045] S204. In response to the buyer's selection of a target service product from the recommended service product sorting list, generate transaction order data; Specifically, the system monitors the buyer's interactive behavior on the user interface in real time and responds to the buyer's explicit selection of a target service product in the sorted list. This selection can take various forms, such as, but not limited to, clicking interactive controls associated with the target service product, such as "Buy Now," "Confirm Selection," or "Generate Order." Once the system detects this selection event signal, it immediately initiates the order data generation process. The core task of this process is to automatically aggregate all necessary information related to the transaction to construct a structured, complete, and persistent transaction order data record. This data may include, but is not limited to: buyer identity information (such as user ID and enterprise authentication information) obtained from the currently logged-in user session; service provider identity information (such as service provider ID) extracted from the data record of the selected target service product; detailed specifications of the service product (such as service ID, name, and configuration details); finalized price and billing model data (such as unit price, period, and total price); and automatically generated order metadata (such as a globally unique order number, order creation timestamp, and initial order status as pending payment or confirmation). The final generated transaction order data will be atomically written into the platform's order database, laying a solid data foundation for subsequent payment, service activation, and fulfillment management, thereby achieving a seamless connection from intelligent recommendation to transaction initiation.

[0046] S205. Obtain the corresponding interface adapter based on the transaction order data, send a configuration instruction to the service provider system through the interface adapter, and receive the delivery status data returned by the service provider system. Specifically, after a transaction order is successfully generated and payment confirmation is completed (when necessary), the system will automatically trigger the automated configuration and delivery process for the service. First, the system extracts key service provider identification information (e.g., Provider_ID) from the transaction order data. Based on this identifier, the system queries a pre-configured interface adapter registry, which maintains a mapping table that maps each integrated service provider identifier to its dedicated software interface adapter module. This interface adapter is essentially a software component conforming to a predetermined interface specification, encapsulating all the protocols, authentication methods, data formats, and API endpoint information required to communicate with a specific service provider system. Through this dynamic lookup and loading of the corresponding adapter, the platform can interact with numerous heterogeneous service provider backend systems in a unified and standardized manner. After obtaining the corresponding interface adapter instance, the system passes the service configuration details from the transaction order (such as bandwidth, CPU cores, storage capacity, etc.) as standardized parameters to the adapter. The adapter then converts these standardized parameters into configuration instructions that the service provider system can recognize. For example, an HTTP POST request in JSON format conforming to its RESTful API specification and containing all necessary parameters. Subsequently, the adapter handles all underlying communication details, including but not limited to establishing a secure connection, attaching authentication credentials (such as an API Key or OAuth Token), and sending the configuration command to the service provider's designated automated configuration interface. After the command is sent, the adapter listens for and receives HTTP (Hypertext Transfer Protocol) responses from the service provider's system, which contain delivery status data. The adapter parses the response (e.g., parses returned JSON or XML data), extracts key status information (such as configuring, successful, failed, and the reason for failure) and possible deliverables (such as the IP address of the newly created cloud host, login credentials, etc.), and converts them into a unified status code and data structure within the platform for subsequent order status updates and user notifications, thus completing a fully automated and traceable service delivery loop.

[0047] Optionally, the step of sending configuration instructions to the service provider system through the interface adapter and receiving delivery status data returned by the service provider system includes: parsing the transaction order data and extracting service type identifier, resource specification parameters, and deployment region parameters from the transaction order data; querying a preset interface adapter configuration library based on the service provider identifier of the target service product to obtain the parameter mapping rule table and application programming interface call template corresponding to the interface adapter; converting the resource specification parameters and deployment region parameters into a parameter format defined by the service provider system according to the parameter mapping rule table, and generating a configuration instruction containing the parameter format according to the application programming interface call template; sending the configuration instruction to the service provider system through the interface adapter and receiving the resource unique identifier and initial status code returned by the service provider system; establishing an association mapping relationship between the resource unique identifier and the order identifier in the transaction order data, and storing the association mapping relationship in a preset order resource mapping table; sending a status query request to the service provider system according to a preset query period, the status query request carrying the resource unique identifier; receiving delivery progress information returned by the service provider system, and extracting the configuration stage identifier and completion value from the delivery progress information to generate the delivery status data.

[0048] As a more specific and optimized implementation of the aforementioned embodiments, the process of interacting with the service provider's system through an interface adapter to complete the automated delivery of services can be broken down into a series of precise and orderly technical steps, thereby ensuring compatibility and operational reliability with heterogeneous systems of different service providers.

[0049] Specifically, the process begins with a deep analysis of transaction order data. The system precisely extracts three core dimensions of information from confirmed transaction order data: first, a service type identifier, such as virtual machine, object storage, or load balancing, which determines the type of service to be configured; second, resource specification parameters, a set of key-value pairs detailing the service configuration, such as {cpu_cores: 4, ram_gb: 8, disk_size_gb: 100, os_image: "ubuntu_20.04"}; and third, deployment region parameters, such as region: "us-east-1", which specifies the physical deployment location of the resource. These parameters, extracted from standardized orders within the platform, constitute the raw input for automated configuration.

[0050] Furthermore, the system will query a pre-defined interface adapter configuration library based on the service provider identifier in the order. This configuration library is crucial for seamless integration between the platform and multiple service providers, storing two types of core configuration data for each service provider: a parameter mapping rule table and an application programming interface (API) call template. The parameter mapping rule table defines how standardized parameters within the platform (e.g., ram_gb=8) are converted into parameter formats recognizable by a specific service provider's API (e.g., instance_type="t2.large"). The API call template is a pre-defined request structure containing placeholders, such as an HTTP POST request template for creating a virtual machine. Based on the retrieved parameter mapping rule table, the system will convert the resource specification parameters and deployment region parameters extracted in the previous step one by one, and then fill the corresponding placeholders in the API call template with the converted results, thereby dynamically generating a configuration instruction that fully conforms to the service provider's interface specifications and contains all necessary parameters.

[0051] Furthermore, after the configuration command is generated, the interface adapter is responsible for executing the actual API call. It sends the command to the designated API endpoint of the service provider's system via a secure network connection (such as HTTPS). Since the creation of service resources is typically an asynchronous process, the service provider's system, upon receiving and verifying the command, usually does not immediately return a final success status. Instead, it immediately returns a unique resource identifier (e.g., Amazon AWS instance-id or Alibaba Cloud instanceId) and an initial status code (e.g., PENDING or CREATING). This unique resource identifier serves as the credential for all subsequent operations. Upon receiving this response, the system immediately creates a new record in the pre-defined order resource mapping table, establishing a strong association between the order identifier of this transaction and the newly acquired unique resource identifier, and persisting this mapping relationship. This mapping relationship is crucial for tracking the resource lifecycle.

[0052] Furthermore, to monitor resource delivery progress in real time, the system initiates an asynchronous polling mechanism. Based on a preset query cycle (e.g., every 5 or 10 seconds), the system sends a status query request to the service provider's status query API endpoint. This request must carry the unique resource identifier stored in the previous step, allowing the service provider to accurately locate the resource being created. The service provider's system returns a response containing current delivery progress information. The system parses this response, extracting specific configuration stage identifiers (e.g., network configuration, operating system installation) and quantified completion percentages (e.g., 35%). The system integrates this dynamically acquired stage and progress information to generate structured delivery status data, which is updated in real-time to the platform's order details interface, providing the buyer with a transparent and visualized view of the service activation process. This series of steps ensures that even with complex and time-consuming resource creation tasks, the platform can achieve accurate and reliable automated delivery and status tracking.

[0053] Optionally, after receiving the unique resource identifier and initial status code returned by the service provider system, the method further includes: determining whether the initial status code is a status code in a preset success status code set; when the initial status code does not belong to the preset success status code set, extracting an error type identifier and error description information from the response data returned by the service provider system; querying a preset exception handling rule base according to the error type identifier to obtain a corresponding handling strategy identifier; when the handling strategy identifier is a retry strategy identifier, obtaining a preset retry parameter configuration, the preset retry parameter configuration including a retry interval duration and a maximum number of retries; adjusting the parameters in the configuration instruction according to the error description information, waiting according to the retry interval duration, and resending the adjusted configuration instruction to the service provider system; recording the current number of retries, and when the current number of retries reaches the maximum number of retries, generating a delivery exception identifier and sending an exception alarm message containing the transaction order data and the error description information to a preset operation and maintenance management system.

[0054] To further enhance the stability and fault tolerance of automated service delivery, a preferred implementation method is provided. This method introduces an intelligent exception handling and retry mechanism after receiving the initial response from the service provider's system. This mechanism aims to automatically handle recoverable temporary or configuration errors, thereby reducing manual intervention and improving the delivery success rate.

[0055] This process is activated after the interface adapter receives the initial response from the service provider's system. The system first performs a critical status check on the response content. Specifically, it parses the response, extracts the initial status code, and compares it with a pre-defined set of success status codes. This set predefines a series of status codes representing that the request has been successfully received and is being processed, such as, but not limited to, PENDING, CREATING, PROCESSING, or ACCEPTED. If the initial status code belongs to this set, the process continues with asynchronous status polling according to the normal path. However, when the initial status code is not in this set, for example, when an error status code such as INVALID_PARAMETER, QUOTA_EXCEEDED, or INTERNAL_ERROR is returned, the system determines that the initial submission of this configuration command has failed and immediately initiates an exception handling sub-process.

[0056] Furthermore, structured error information is extracted from the complete response data returned by the service provider, typically including an error type identifier and an error description. The error type identifier is machine-readable code (such as InvalidParameter.InstanceType), while the error description is human-readable text. The system then uses this error type identifier as an index to query a pre-defined exception handling rule base. This rule base is a crucial decision center, mapping various known error types to predefined handling strategy identifiers. For example, for a QUOTA_EXCEEDED error, the handling strategy might be identified as an alert and transfer to a human operator; while for errors like InvalidParameter, the handling strategy might be identified as a "retry strategy."

[0057] Furthermore, when the queried processing policy identifier is confirmed to be a retry policy identifier, the system will execute an intelligent, corrective retry operation. First, it retrieves the preset retry parameter configuration associated with the retry policy from the configuration. This typically includes the retry interval duration (e.g., an initial wait of 10 seconds, which can be increased exponentially using a backoff strategy) and the maximum number of retries (e.g., 3 times). The core intelligence lies in the system's attempt to automatically adjust the parameters in the original configuration command based on the error description information. For example, if the error message indicates that a certain instance specification does not exist, the system can replace the instance specification parameter in the configuration command with the next available specification based on a preset list of alternative specifications; if the error message indicates that the resource name already exists, the system can append a random suffix to the original name to generate a new unique name. After completing the parameter adjustment, the system will wait according to the retry interval duration and then resend the adjusted configuration command to the service provider system through the interface adapter. Simultaneously, the system internally maintains a retry counter associated with the order and increments it after each retry. If the service provider's system still returns a failure response after reaching the maximum number of retries, the system will assume that the error cannot be automatically recovered. It will then generate a delivery anomaly identifier in the order data and immediately call the alarm interface to send an anomaly alarm message containing complete transaction order data and the last error description information to the preset operation and maintenance management system (such as a work order system or monitoring platform). This will enable operation and maintenance personnel to intervene in a timely manner, thereby building a complete and reliable fault handling closed loop from automatic repair attempts to manual intervention.

[0058] S206. Based on the delivery status data, perform billing processing on the usage data of the target service product to generate settlement bill data.

[0059] Specifically, once the delivery status data clearly indicates that the target service has been successfully delivered and is available, the system will trigger an automated billing process. This process is executed by an independent metering and billing engine, which first extracts the exact effective timestamp and unique resource identifier from the delivery status data. Subsequently, the billing engine obtains usage data based on the service billing model defined in the transaction order data (e.g., prepaid annual / monthly subscription model or postpaid pay-as-you-go model). For time-based services such as annual / monthly subscriptions, the usage data is the length of time from the effective timestamp to the end of the current billing period; while for pay-as-you-go services, the billing engine will use the unique resource identifier to call the usage query interface provided by the service provider according to a preset metering period (e.g., hourly or daily) to obtain accurate consumption indicators, such as used storage space (GB), outbound traffic (GB), or API call count. After acquiring usage data, the billing engine queries the pricing model library associated with the target service product to find the corresponding unit price or tiered pricing rule. It then performs calculations based on the usage data and pricing rules to accurately calculate the payable amount for the current billing cycle, ultimately generating a structured settlement bill. This bill records detailed information such as order identifier, resource identifier, billing cycle, specific usage, unit price, and total amount, and is persistently stored in the billing database. This serves as the authoritative basis for issuing invoices to users, conducting cost accounting, and reconciling financial statements, thus achieving an automated closed loop from service delivery to value settlement.

[0060] Optionally, the step of billing the usage data of the target service product based on the delivery status data and generating settlement billing data includes: querying a preset resource usage monitoring system based on the unique resource identifier in the delivery status data to obtain the usage data of the target service product; extracting resource usage duration data, network traffic consumption data, and application programming interface call count data from the usage data; querying a preset billing rule base based on the service type identifier of the target service product to obtain the corresponding billing model parameters, the billing model parameters including duration unit price coefficient, traffic unit price coefficient, call unit price coefficient, and billing cycle configuration; multiplying the resource usage duration data with the duration unit price coefficient to obtain the duration dimension cost value; and multiplying the network traffic consumption data... The initial traffic cost is obtained by multiplying the traffic consumption data with the traffic unit price coefficient. Based on a preset traffic tiered pricing rule, the pricing range of the network traffic consumption data is determined, and the discount coefficient corresponding to the pricing range is obtained. The initial traffic cost is multiplied by the discount coefficient to obtain the traffic dimension cost value. The application programming interface call count data is multiplied with the call unit price coefficient to obtain the call dimension cost value. The duration dimension cost value, the traffic dimension cost value, and the call dimension cost value are summed to obtain the total cost value. Based on the billing cycle configuration, the total cost value is processed by time period aggregation to generate settlement billing data including the billing cycle start time, billing cycle end time, cost details for each dimension, and the total cost value.

[0061] As a specific and refined implementation of the aforementioned billing processing steps, a multi-dimensional, tiered pricing-supporting automated billing scheme is also provided to adapt to the complex billing models of cloud service products. The execution of this scheme begins with the accurate collection of usage data for delivered resources. Specifically, the system uses the unique resource identifier in the delivery status data as a unique query credential to interact with a pre-set resource usage monitoring system. This monitoring system continuously collects real-time operational metrics of resources from the underlying service provider or through deployed agents. By calling the system's query interface, the platform can obtain all relevant usage data associated with the unique resource identifier. Subsequently, the system parses and categorizes this raw data, accurately extracting core metrics for multiple billing dimensions, such as, but not limited to: resource usage duration data (e.g., in hours or minutes) representing resource occupancy time, network traffic consumption data (e.g., in GB or TB) representing data transmission volume, and application programming interface call count data representing the frequency of service interface calls.

[0062] Furthermore, after acquiring the raw usage data, the system's billing engine enters the price and rule matching phase. It queries and matches the target service product's service type identifier (e.g., high-performance computing virtual machine or object storage service - standard type) against a pre-defined billing rule base. This rule base contains detailed billing model parameters configured for each service type. These parameters form the basis of the billing calculation and mainly include: a duration-based unit price coefficient for calculating duration fees (e.g., 0.5 yuan per hour), a traffic-based unit price coefficient for calculating basic traffic fees (e.g., 0.8 yuan per GB), a call-based unit price coefficient for calculating API call fees (e.g., 0.001 yuan per call), and a billing cycle configuration defining the billing generation period (e.g., billing by calendar month or calendar day).

[0063] Furthermore, the system will perform multi-dimensional cost calculations based on the acquired usage data and billing model parameters. First, it multiplies the resource usage duration data with the duration-based unit price coefficient to directly obtain the duration-based cost value. Second, for traffic costs, the system will execute a more complex calculation process that supports tiered pricing: first, it multiplies the network traffic consumption data with the traffic-based unit price coefficient to obtain an initial traffic cost; then, the system will determine the current network traffic consumption data's pricing tier based on preset tiered pricing rules (e.g., no discount for 0-1TB, 1-5TB with a 10% discount, and over 5TB with a 20% discount), and obtain the corresponding discount coefficient (e.g., 0.9 or 0.8); finally, it will multiply the initial traffic cost with this discount coefficient to obtain the final traffic-based cost value. Third, the system performs a simple multiplication operation on the application programming interface (API) call count data with the call unit price coefficient to obtain the call-based cost value.

[0064] Furthermore, after calculating the cost values ​​for all dimensions, the system will perform a summary and billing generation operation. It will sum the calculated cost values ​​for duration, traffic, and call dimensions to obtain a total cost value. Finally, the system will refer to the billing cycle configuration obtained from the billing rule library to perform time-period aggregation processing on this total cost value. For example, if the billing cycle is a calendar month, the system will accumulate all costs incurred by the order within a calendar month, ultimately generating a structured settlement bill. This bill is detailed and clearly includes the start and end times of the billing cycle, cost details for each dimension (such as duration cost, traffic cost, and call cost), and the final total amount payable.

[0065] Optionally, the method further includes: parsing the service level agreement parameters of the target service product, extracting a set of performance indicator thresholds from the service level agreement parameters, the set of performance indicator thresholds including a latency upper limit threshold, an availability lower limit threshold, and a bandwidth guarantee threshold; according to a preset monitoring and collection cycle, initiating a probe request to the network resources corresponding to the target service product through a network performance detection tool, and collecting real-time latency measurement values, real-time availability measurement values, and real-time bandwidth measurement values; comparing the real-time latency measurement values ​​with the latency upper limit threshold, recording the breach time point when the real-time latency measurement value is greater than the latency upper limit threshold, and calculating the continuous breach duration; when the continuous breach duration reaches a preset threshold... When a default duration threshold is reached, a default record is generated, including a default type identifier, default start time, default end time, and default duration. Based on the compensation rule table defined in the service level agreement parameters, the compensation ratio coefficient corresponding to the default duration is queried. The compensation amount is calculated based on the compensation ratio coefficient and the billing amount of the target service product. The account adjustment interface of the preset settlement system is called to transfer the compensation amount from the service provider's account balance to the buyer's account balance. The default record is associated with the service provider identifier of the target service product, and the cumulative number of defaults and credit score corresponding to the service provider identifier in the service provider credit database are updated.

[0066] To further protect the rights and interests of service purchasers and achieve automated monitoring and management of service provider quality, a preferred implementation method is provided, which integrates a complete automated SLA execution mechanism. This mechanism can proactively monitor service performance and automatically complete the entire chain of processing, from default determination and compensation calculation to financial settlement and credit rating, when service quality fails to meet standards.

[0067] Specifically, the SLA terms stipulated in the service contract are digitally parsed and configured. The system parses the service level agreement parameters associated with the target service product. These parameters are typically stored in structured data (such as JSON or XML format). The core task of parsing is to extract a set of quantified performance indicator thresholds. This set clearly defines the committed boundaries of service quality, and may include, for example, a latency ceiling threshold (e.g., average network round-trip latency must not exceed 50 milliseconds), an availability floor threshold (e.g., monthly service availability must not be lower than 99.95%), and a bandwidth guarantee threshold (e.g., public network egress bandwidth must not be lower than 100Mbps). These parsed thresholds are loaded into the system's real-time monitoring engine as a benchmark for subsequent performance evaluation.

[0068] Furthermore, the system will initiate continuous and proactive service performance probing. Based on a preset monitoring and data collection cycle (e.g., once every minute or every five minutes, which can be flexibly configured according to SLA sensitivity), the system will schedule built-in or integrated network performance probing tools (e.g., using Ping for connectivity and latency testing, using HTTP / S probes to simulate user requests to test service availability, or using tools like iPerf for bandwidth testing). These tools will automatically initiate probing requests to the network resources (such as IP addresses or domain names) corresponding to the target service product and collect a series of key real-time performance data, mainly including real-time latency measurements, real-time availability measurements (usually determined by request success or failure), and real-time bandwidth measurements.

[0069] Furthermore, the monitoring engine compares the collected real-time measurements with preset SLA thresholds in real time. For example, it compares the real-time latency measurement with the latency upper limit threshold. When the real-time latency measurement is found to be consistently greater than the latency upper limit threshold, the system immediately records a breach time and begins accumulating the duration of consecutive breaches. To avoid misjudgments caused by network jitter, the system introduces a preset breach determination duration threshold (e.g., 5 consecutive minutes of non-compliance). Only when the accumulated duration of consecutive breaches reaches this threshold will the system formally determine that an SLA breach event has occurred and generate a structured breach record. This record will contain detailed information including a breach type identifier (e.g., latency exceeding the limit), breach start time, breach end time, and the precise breach duration.

[0070] Furthermore, once a default record is generated, the system automatically triggers the compensation and settlement process. It queries the predefined compensation rule table in the SLA parameters based on the default duration in the record. This table typically uses a tiered mapping, assigning different default durations to different compensation ratios (e.g., 10% of the daily service fee for a default of 1-4 hours, 25% for 4-8 hours, etc.). After obtaining the corresponding compensation ratio, the system combines this with the billing amount of the target service (e.g., monthly fee) and uses multiplication to precisely calculate the specific compensation amount. To complete the compensation, the system interacts with the pre-defined settlement system via a secure API call, executing its provided account adjustment interface. This call carries the compensation amount and both parties' account information, instructing the settlement system to automatically deduct the calculated compensation amount from the service provider's account balance and transfer it to the buyer's account balance. This achieves automated economic compensation without human intervention. To establish a long-term service provider management and credit assessment mechanism, the system also records this default event. It permanently associates the generated default records with the service provider's identifier for the target service product and updates the service provider's credit database. Specifically, the system increments the cumulative number of defaults corresponding to the service provider's identifier by one and adjusts its credit score accordingly based on a preset credit model algorithm (e.g., deducting a certain number of points for each default).

[0071] This embodiment also discloses an electronic device, as shown in the reference. Figure 3 The electronic device may include: at least one processor 301, at least one communication bus 302, a user interface 303, a network interface 304, and at least one memory 305. The communication bus 302 is used to enable communication between these components. The user interface 303 may include a display screen or a camera; optionally, the user interface 303 may also include a standard wired interface or a wireless interface. The network interface 304 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0072] The processor 301 may include one or more processing cores. The processor 301 connects to various parts of the server using various interfaces and lines, and performs various server functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in memory 305, and by calling data stored in memory 305. Optionally, the processor 301 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The processor 301 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content required for display; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the processor 301 and may be implemented as a separate chip.

[0073] The memory 305 may include random access memory (RAM) or read-only memory. Optionally, the memory 305 may include a non-transitory computer-readable storage medium. The memory 305 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 305 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 305 may also be at least one storage device located remotely from the aforementioned processor 301. Figure 3 As shown, the memory 305, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an application program for a multi-cloud network service e-commerce transaction method.

[0074] The foregoing description is merely an exemplary embodiment of this disclosure and should not be construed as limiting the scope of this disclosure. Any equivalent changes and modifications made in accordance with the teachings of this disclosure shall still fall within the scope of this disclosure. Other embodiments of this disclosure will be readily apparent to those skilled in the art upon consideration of the disclosure in this specification. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not described in this disclosure. The specification and embodiments are to be considered exemplary only, and the scope and spirit of this disclosure are defined by the claims.

Claims

1. A method for e-commerce transactions of multi-cloud network services, characterized in that, The method includes: Obtain network service description data, and standardize the network service description data according to the preset network service description specifications to generate standardized service product data; Receive service request data submitted by the buyer, extract the service request features from the service request data, and obtain a request feature vector; The standardized service product data is matched and filtered according to the demand feature vector to obtain a set of candidate service products. Based on the standardized performance parameters, price model parameters and service provider credit data of each service product in the candidate service product set, a comprehensive score is given to each service product to generate a recommended service product ranking list. In response to the buyer's selection of a target service product from the recommended service product sorting list, transaction order data is generated; Obtain the corresponding interface adapter based on the transaction order data, send configuration instructions to the service provider system through the interface adapter, and receive delivery status data returned by the service provider system; Based on the delivery status data, the usage data of the target service product is billed, and settlement bill data is generated.

2. The method according to claim 1, characterized in that, The step of standardizing the network service description data according to a preset network service description specification to generate standardized service product data includes: The network service description specification is parsed to obtain performance parameter mapping rules, service level classification rules, pricing model templates, and interface specification templates. Parse the performance metric field, service commitment field, pricing information field, and interface configuration field in the network service description data; Extract the original performance metrics corresponding to the performance metric fields, and convert the original performance metrics into standardized performance parameters according to the performance parameter mapping rules; Extract the service commitment information corresponding to the service commitment field, classify the service commitment information according to the service level classification rules, and generate service level agreement parameters; Extract the pricing information corresponding to the pricing information field, and convert the pricing information into price model parameters in a unified format according to the price model template; Extract the interface configuration information corresponding to the interface configuration fields, standardize the interface configuration information according to the interface specification template, and generate delivery interface parameters; The standardized performance parameters, service level agreement parameters, pricing model parameters, and delivery interface parameters are structured and encapsulated to generate the standardized service product data.

3. The method according to claim 1, characterized in that, The process involves comprehensively scoring each service in the candidate service product set based on standardized performance parameters, price model parameters, and service provider credit data, generating a recommended service product ranking list, including: Extract standardized performance parameters of each service product in the candidate service product set, and calculate the similarity between the standardized performance parameters and the performance requirement values ​​in the demand feature vector to obtain a service performance matching score. Extract the price model parameters of each service in the candidate service product set, calculate the conformity between the price model parameters and the price constraint values ​​in the demand feature vector, and obtain the price advantage score. Based on a preset service provider credit database, historical transaction success rate data and historical user evaluation data of the service providers corresponding to each service product in the candidate service product set are obtained, and the service provider credit score is calculated based on the historical transaction success rate data and historical user evaluation data. The service performance matching score, the price advantage score, and the service provider credit score are weighted and summed according to preset weight coefficients to obtain the comprehensive matching score of each service product. The service products in the candidate service product set are sorted from high to low according to the comprehensive matching score to generate the recommended service product sorting list.

4. The method according to claim 1, characterized in that, The step of sending configuration instructions to the service provider system through the interface adapter and receiving delivery status data returned by the service provider system includes: Parse the transaction order data to extract service type identifier, resource specification parameters, and deployment region parameters. Based on the service provider identifier of the target service product, query the preset interface adapter configuration library to obtain the parameter mapping rule table and application programming interface call template corresponding to the interface adapter; Based on the parameter mapping rule table, the resource specification parameters and the deployment region parameters are converted into the parameter format defined by the service provider system, and the configuration instructions containing the parameter format are generated by calling the template according to the application programming interface; The configuration command is sent to the service provider system through the interface adapter, and the unique resource identifier and initial status code returned by the service provider system are received. Establish an association mapping relationship between the unique identifier of the resource and the order identifier in the transaction order data, and store the association mapping relationship in a preset order resource mapping table; According to a preset query cycle, a status query request is sent to the service provider system. The status query request carries the unique identifier of the resource. The delivery progress information returned by the service provider system is received. The configuration stage identifier and completion value are extracted from the delivery progress information to generate the delivery status data.

5. The method according to claim 4, characterized in that, After receiving the resource unique identifier and initial status code returned by the service provider system, the method further includes: Determine whether the initial status code is a status code in the preset success status code set; When the initial status code does not belong to the preset success status code set, the error type identifier and error description information are extracted from the response data returned by the service provider system; Based on the error type identifier, query the preset exception handling rule library to obtain the corresponding handling strategy identifier; When the processing strategy identifier is a retry strategy identifier, a preset retry parameter configuration is obtained, which includes the retry interval duration and the maximum number of retries. The parameters in the configuration command are adjusted according to the error description information, and the adjusted configuration command is resent to the service provider system after waiting for the retry interval. Record the current number of retries. When the current number of retries reaches the maximum number of retries, generate a delivery anomaly identifier and send an anomaly alarm message containing the transaction order data and the error description information to the preset operation and maintenance management system.

6. The method according to claim 1, characterized in that, The step of billing based on the usage data of the target service product according to the delivery status data and generating settlement bill data includes: Based on the unique resource identifier in the delivery status data, query the preset resource usage monitoring system to obtain the usage data of the target service product, and extract resource usage duration data, network traffic consumption data and application programming interface call count data from the usage data. The pre-designed fee rule base is queried according to the service type identifier of the target service product to obtain the corresponding billing model parameters. The billing model parameters include the duration unit price coefficient, traffic unit price coefficient, call unit price coefficient, and billing cycle configuration. The resource usage duration data is multiplied by the duration unit price coefficient to obtain the duration-based cost value; The initial traffic cost is obtained by multiplying the network traffic consumption data with the traffic unit price coefficient. The pricing range of the network traffic consumption data is determined according to the preset traffic tier pricing rules. The discount coefficient corresponding to the pricing range is obtained. The initial traffic cost is multiplied by the discount coefficient to obtain the traffic dimension cost value. The application programming interface call count data is multiplied by the call unit price coefficient to obtain the call dimension cost value; The total cost is obtained by summing the cost values ​​for duration, traffic, and invocation. Based on the billing cycle configuration, the total cost value is aggregated over a time period to generate settlement billing data that includes the billing cycle start time, billing cycle end time, cost details for each dimension, and the total cost value.

7. The method according to claim 1, characterized in that, The method further includes: The service level agreement parameters of the target service product are parsed, and a set of performance indicator thresholds is extracted from the service level agreement parameters. The set of performance indicator thresholds includes a latency upper limit threshold, an availability lower limit threshold, and a bandwidth guarantee threshold. According to the preset monitoring and collection cycle, a network performance detection tool is used to initiate a detection request to the network resources corresponding to the target service product, and collect real-time latency measurement values, real-time availability measurement values, and real-time bandwidth measurement values. The real-time delay measurement value is compared with the delay upper limit threshold. When the real-time delay measurement value is greater than the delay upper limit threshold, the default time point is recorded, and the duration of continuous default is calculated. When the duration of continuous default reaches the preset default judgment duration threshold, a default record is generated that includes a default type identifier, default start time, default end time, and default duration. According to the compensation rule table defined in the service level agreement parameters, the compensation ratio coefficient corresponding to the breach duration is queried, and the compensation amount is calculated based on the compensation ratio coefficient and the billing amount of the target service product. The account adjustment interface of the preset settlement system is invoked to transfer the compensation amount from the account balance of the service provider corresponding to the target service product to the account balance of the buyer; The default record is associated with the service provider identifier of the target service product, and the cumulative number of defaults and credit score corresponding to the service provider identifier in the service provider credit database are updated.

8. An electronic device, characterized in that, The device includes a processor, a memory, a user interface, and a network interface. The memory is used to store instructions. The user interface and the network interface are both used to communicate with other devices. The processor is used to execute the instructions stored in the memory to cause the electronic device to perform the method as described in any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores instructions that, when executed, perform the method as described in any one of claims 1-7.

10. A computer program product, characterized in that, When the computer program product is run on an electronic device, it causes the electronic device to perform the method as described in any one of claims 1-7.

Images