Control method and device of e-commerce transaction system, and storage medium

Abstract

The invention discloses a control method and device of an e-commerce transaction system and a storage medium, and relates to the technical field of e-commerce, and the control method of the e-commerce transaction system comprises the steps: building a business scene object according to a business code and a scene corresponding to a current request after a controller receives a front-end request; when the extension executor intercepts a calling intention corresponding to the business scene object, business coordinates are determined based on the business scene object, and the business coordinates are triples formed by business codes, use case identifiers and scene codes; after the extension executor determines target implementation through the configuration center according to the service coordinates, a method call triggered by the service scene object is entrusted to the target implementation for execution, and an execution result is obtained; and generating response content corresponding to the front-end request based on the execution result, and sending the response content to the front end. The technical effect that configuration can be arranged during operation can be achieved.

Description

Technical Field

[0001] This application relates to the field of e-commerce technology, and in particular to a control method, device and storage medium for an e-commerce transaction system. Background Technology

[0002] Currently, existing e-commerce transaction systems primarily implement various functions through hard coding. Core logic such as order processing, discount calculation, and subsidy verification are all directly written into the underlying code, deeply bound to the system architecture. When temporary events occur, such as national subsidies or major promotions, the implementation of system functions requires global adjustments, leading to low efficiency. Summary of the Invention

[0003] The main purpose of this application is to provide a control method, device and storage medium for an e-commerce transaction system, which aims to solve the technical problem of low efficiency in function implementation caused by hard coding.

[0004] To achieve the above objectives, this application provides a control method for an e-commerce transaction system, the control method comprising: After the controller receives a request from the front end, it constructs a business scenario object based on the business code and scenario corresponding to the current request. When the extended executor intercepts the call intent corresponding to the business scenario object, it determines the business coordinates based on the business scenario object. The business coordinates are a triple consisting of the business code, the use case identifier, and the scenario code. After the extended executor determines the target implementation based on the business coordinates through the configuration center, it delegates the method calls triggered by the business scenario object to the target implementation for execution and obtains the execution results. The response content corresponding to the front-end request is generated based on the execution result, and the response content is sent to the front-end.

[0005] In one embodiment, after determining the business coordinates based on the key parameters corresponding to the current request, the control method of the e-commerce transaction system further includes: Send business coordinates and extension point information to the configuration center; After receiving the business coordinates and extension point information, the configuration center determines the implementation code corresponding to the business coordinates and extension point information, and sends it to the extension executor so that the extension executor can determine the target implementation based on the implementation code.

[0006] In one embodiment, after the configuration center receives the service coordinates and extension point information, the step of determining the implementation code corresponding to the service coordinates and extension point information and sending it to the extension executor includes: After receiving the business coordinates and extension point information in the configuration center, if there is a first implementation that completely matches the business coordinates and extension information, the implementation code of the first implementation is sent to the extension executor. If no first implementation exists, then determine whether a second implementation matching the business code exists, and if a second implementation exists, send the implementation code of the second implementation to the extended executor; If no second implementation exists, obtain the third implementation associated with the use case identifier and send the implementation code of the third implementation to the extended executor, where the third implementation is the default configuration associated with the use case identifier; If no third implementation exists, the implementation code of the default implementation corresponding to the extended executor will be sent to the extended executor.

[0007] In one embodiment, before the step of delegating the method call triggered by the business scenario object to the target implementation for execution and obtaining the execution result after the extended executor determines the target implementation based on the business coordinates through the configuration center, the control method of the e-commerce transaction system further includes: In response to the login operation of the configuration platform, the control terminal displays the configuration interface; Based on the configuration operations received from the configuration interface, update the corresponding configuration rules in the configuration center.

[0008] In one embodiment, before the step of delegating the method call triggered by the business scenario object to the target implementation for execution and obtaining the execution result after the extended executor determines the target implementation based on the business coordinates through the configuration center, the control method of the e-commerce transaction system further includes: Get the current time point; Determine the target configuration rules corresponding to the current time point based on the time period in which the current time point is located; If the configuration rules currently being executed in the configuration center are inconsistent with the target configuration rules, the configuration rules currently being executed in the configuration center will be updated to the target configuration rules.

[0009] In one embodiment, after the controller receives a front-end request, the step of constructing a business scenario object based on the business code and scenario corresponding to the current request includes: Parse the front-end request and determine the business code and scenario code based on the parsed request parameters; Determine use case identifiers based on predefined content; Construct a business scenario object based on the business code, scenario code, and use case identifier.

[0010] In addition, to achieve the above objectives, this application also provides a control device for an e-commerce transaction system. The control device for the e-commerce transaction system includes: a memory, a processor, and a computer program stored in the memory and executable on the processor. The computer program is configured to implement the steps of the control method for the e-commerce transaction system described above.

[0011] In addition, to achieve the above objectives, this application also provides a storage medium, which is a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the steps of the control method for the e-commerce transaction system described above.

[0012] This application provides a control method for an e-commerce transaction system. After the controller receives a front-end request, it constructs a business scenario object based on the business code and scenario corresponding to the current request. When the extended executor intercepts the call intent corresponding to the business scenario object, it determines the business coordinates based on the business scenario object. The business coordinates are a triple consisting of the business code, the use case identifier, and the scenario code. After the extended executor determines the target implementation through the configuration center based on the business coordinates, it delegates the method call triggered by the business scenario object to the target implementation for execution and obtains the execution result. Based on the execution result, it generates the response content corresponding to the front-end request and sends the response content to the front-end. Since the response to the request is based on the call implementation, it achieves the purpose of functional plug-in on the one hand. On the other hand, when determining the implementation corresponding to the call, it is not determined directly by the extended executor based on the business coordinates, but based on the rules configured by the configuration center. Therefore, by issuing configuration rules at runtime through the configuration center, the technical effect of runtime configuration orchestration is achieved. Attached Figure Description

[0013] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0014] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 This is a schematic diagram of the processing logic of the Taiyi framework involved in this application; Figure 2 This is a flowchart illustrating an embodiment of the control method for the e-commerce transaction system of this application. Figure 3 This is a flowchart illustrating the second embodiment of the control method for the e-commerce transaction system of this application. Figure 4 This is a flowchart illustrating the control method of the e-commerce transaction system in Embodiment 4 of this application. Figure 5 This is a flowchart illustrating the fifth embodiment of the control method for the e-commerce transaction system of this application. Figure 6 This is a schematic diagram of the processing thread based on the order scenario in this application; Figure 7 This is a schematic diagram of the hardware operating environment involved in the control method of the e-commerce transaction system in this embodiment of the application.

[0016] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0017] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of this application and are not intended to limit this application.

[0018] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0019] Currently, existing e-commerce transaction systems primarily implement various functions through hard coding. Core logic such as order processing, discount calculation, and subsidy verification are all directly written into the underlying code, deeply bound to the system architecture. When temporary events occur, such as national subsidies or major promotions, the implementation of system functions requires global adjustments, leading to low efficiency.

[0020] The main solution of this application is as follows: This application provides a control method for an e-commerce transaction system. After the controller receives a front-end request, it constructs a business scenario object based on the business code and scenario corresponding to the current request. When the extended executor intercepts the call intent corresponding to the business scenario object, it determines the business coordinates based on the business scenario object. The business coordinates are a triple consisting of the business code, the use case identifier, and the scenario code. After the extended executor determines the target implementation based on the business coordinates through the configuration center, it delegates the method call triggered by the business scenario object to the target implementation for execution and obtains the execution result. Based on the execution result, it generates the response content corresponding to the front-end request and sends the response content to the front-end. Since the response to the request is based on the call implementation, it achieves the purpose of functional plug-in on the one hand. On the other hand, when determining the implementation corresponding to the call, it is not determined directly by the extended executor based on the business coordinates, but based on the rules configured by the configuration center. Therefore, by issuing configuration rules at runtime through the configuration center, the technical effect of runtime configuration orchestration is achieved.

[0021] It should be noted that the executing entity in this embodiment can be an e-commerce transaction system, or a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or a control device for an e-commerce transaction system capable of performing the above functions. This embodiment does not specifically limit the specific implementation. The following uses an e-commerce transaction system as the executing entity to describe this embodiment and the subsequent embodiments.

[0022] Reference Figure 1 , Figure 1 This is a flowchart illustrating the Taiyi framework of the control method for the e-commerce transaction system of this application. In the Taiyi framework, businesses are categorized based on the company's products, including vertical and horizontal businesses. Vertical businesses include things like flash sales, flower warehouses, offline stores, and sales through off-site channels, while horizontal businesses include things like government subsidies. Businesses are globally defined, such as "VIP" or "VIPshop." Business Scenarios are used to locate different implementations of various extensions. A unique identifier is defined for each business scenario, and it is identified and located through multiple dimensions. Initially, fixed dimensions (business, channel, product, customer type) and extended dimensions (scenario) are envisioned. Business identities are defined in different domains. Domains are divided into different domains based on product lines and core entities. Domain division is hierarchical, ranging from e-commerce platforms, supply chain platforms, people-goods-place middleware platforms, and personalized platforms, to more specific front-end, transaction, payment, customer service, user, and goods middleware platforms. The goods middleware platform is further refined (products, inventory, prices, promotional offers, etc.), and finally, it is subdivided into deployment-level domains. A domain is a virtual concept that contains one or more related deployment units (business domains). A use case is a complete function provided by a domain to satisfy a specific business scenario. For example, for a C-end user, "submitting an order" on the checkout page is a complete use case, implemented as a complete external function. In the Taiyi business framework, a use case is an entity concept, usually marked with `@UseCase` or a similar annotation. A capability is a basic ability provided by a domain object or entity. For example, the `Order` entity in the `Order` domain can have basic capabilities such as creating an order, querying the order list, querying order details, modifying an order, and deleting an order. Extensions can be defined based on capabilities. A capability is a virtual concept, usually expressed by an extension. An extension decorates a capability, defining an extension that can be used to extend the capability's implementation under different business scenarios. In the Taiyi business framework, extensions are usually marked with `@Extension` or a similar annotation. An implementation is the realization / implementation of an extension. Based on different implementations of an extension, they can be orchestrated through configuration, and different implementations can be decoupled and dynamically deployed independently as JAR packages. In the Taiyi business framework, implementations are usually marked with `@Realization` or a similar annotation. Configuration orchestration (mapping) is the visual and configurable management of business logic, domains, use cases, capabilities, and extensions. A unified business framework requires the separation of configuration and runtime. Configuration orchestration is a key feature of Taiyi's "runtime orchestration," allowing for runtime changes to the implementation of routes under specified business coordinates, thereby enabling runtime behavior modifications. Configuration orchestration is typically expressed in JSON files, with a structure such as... Figure 1 As shown.

[0023] The entire process involves triggering a business scenario, identifying extension points, mapping implementations, and applying configurations. First, after a user requests access to the system, a business scenario coordinate system (BizScenario) is generated, containing a bizId (business code), usecase, and scenario. This business scenario coordinate system is then mapped to the current use case, locating the extension points (Extension A, Extension B). The management backend configures the mapping from extension points to implementations, identifying extension points under the use case. The SDK (Software Development Kit) automatically records all configurable extension points under a specific use case in the management backend; for example, usecase1 has extension points Extension1, Extension2, and Extension3. The management backend allows viewing all implementations corresponding to each extension point, such as Realization11~15 under Extension1. Finally, a coordinate-implementation mapping is established. Based on the business scenario coordinates (bizId, usecase, scenario), the extension points are associated with their corresponding implementations, and this mapping relationship is stored in the coordinate-implementation mapper. After configuration, the coordinate <-> implementation mapper will synchronize the mapping rules to the system. When subsequent requests trigger the corresponding business scenario coordinates, the system will automatically match the mapped implementation and execute the corresponding extended logic. Since the request response is based on the implementation call, it achieves the goal of functional plug-in on the one hand, and on the other hand, when determining the corresponding implementation call, it is not determined directly by the extended executor based on the business coordinates, but based on the rules configured in the configuration center. Therefore, by distributing configuration rules at runtime through the configuration center, the technical effect of runtime configuration orchestration is achieved.

[0024] Based on this, Embodiment 1 of this application proposes a control method for an e-commerce transaction system. Please refer to... Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the control method for an e-commerce transaction system according to this application. The control method for the e-commerce transaction system includes steps S10 to S40: Step S10: After the controller receives the front-end request, it constructs a business scenario object based on the business code and scenario corresponding to the current request.

[0025] The controller is the core component of an e-commerce transaction system, connecting the front-end and back-end business logic. It is responsible for receiving and parsing front-end requests, scheduling back-end business resources to process the requests, and returning the processing results to the front-end. A front-end request is an operation instruction initiated by the e-commerce platform's front-end, containing user-triggered business operations and request parameters. A business code (bizCode) is a unique code used to identify different business types. A scenario (scenario) refers to the specific business application context corresponding to the front-end request; it is a further subdivision of the basic business type identified by the business code. For example, under the order payment business code, scenarios can be divided into national subsidy-added payment, promotional discount payment, and regular daily payment. A business scenario object (BizScenario) is a structured data object encapsulated based on the business code, scenario information, and use case identifiers extracted from the front-end request.

[0026] In this embodiment, after receiving a front-end request, the controller parses it, extracts request parameters, determines the business code and scenario from the parameters, and constructs a complete business scenario object based on the current request's business code and scenario. Through parameter extraction and dynamic encapsulation, it adapts to diverse business scenarios, enhancing system flexibility.

[0027] In a first feasible implementation, step S10 may include: after receiving a front-end request, the controller verifies the request's validity through a parameter parsing module, performs data format and business semantic verification, filters invalid parameters, extracts the `bizCode` and `scenario` field values ​​from the request parameters, encapsulates the `bizCode`, `scenario`, and request metadata into a business scenario object, performs integrity verification on the business scenario object, and completes the construction after confirming that no core fields are missing. Verifying the request's validity before extracting parameters reduces invalid data processing and lowers the failure rate of business scenario object construction.

[0028] For example, e-commerce scenarios are prone to malicious requests, such as coupon fraud, order manipulation, and API attacks. To proactively intercept illegal sources and high-frequency abnormal requests, and reduce the invalid load of subsequent parameter parsing, the controller, upon receiving a frontend request, first performs basic network layer filtering to verify the legality of the request protocol, such as HTTPS, and the request source whitelist, such as the official domain of the e-commerce app or mini-program. It also verifies the request frequency, such as blocking high-frequency requests from the same IP or user within a short period to prevent malicious API manipulation.

[0029] Furthermore, to address the issue of diverse e-commerce parameters, the data format of parameters is validated. For example, prices must be numeric, and product types must be string-based. Numerical ranges are also validated, such as order amount > 0 and product quantity ≥ 1 and ≤ purchase limit. Business logic consistency is verified, including checking the matching between scenario and bizCode. When bizCode = PRESALE, scenario must be PRESALE_DEPOSIT or PRESALE_SETTLEMENT, not a typical order scenario. The validity of associated fields is also validated. For example, when scenario = PRESALE_DEPOSIT, the existence of preSaleId and its validity within the pre-sale period are checked. All parameters that fail format or semantic validation are filtered out, and only compliant parameters are retained for the next stage.

[0030] Furthermore, to ensure that subsequent business scenario objects can be matched with the corresponding processing logic, the `bizCode` and `scenario` fields are accurately extracted from the compliance parameters. If a field is missing, it is first attempted to be supplemented from the request context, such as obtaining `bizCode` from the business identifier field in the request header. If it is still missing after supplementation, it is assigned values ​​according to e-commerce default rules, such as `bizCode` defaulting to `ORDER_COMMON` and `scenario` defaulting to `DEFAULT`. The extracted fields are standardized and converted, such as uniformly converting to uppercase and removing special characters, to avoid `order_submit` and `ORDER_SUBMIT` being judged as different values.

[0031] In a second feasible implementation, step S10 may include: the controller parses the message structure of the front-end request, separates business parameters from non-business parameters, maps business parameters to standard bizCodes through a bizCode mapping rule base, supports mapping of multi-source business parameters to standard bizCodes, and determines the scenario by combining the request context, such as activity ID, user level, product type, channel identifier, and time dimension; instantiates the BizScenario class, and assigns bizCode, scenario, and key request parameters in sequence; generates a unique identifier for the business scenario object, completes object construction, and caches it locally. By generating a unique identifier and caching it, subsequent fast invocation is facilitated, and the overhead of repeated construction is reduced.

[0032] In a third feasible implementation, step S10 may include: after receiving a request, the controller calls a unified parameter extraction interface to obtain the `bizCode` and `scenario` from the current request, and populates the standardized `bizCode`, `scenario`, and request context information based on the business scenario object template. When a scenario field is missing, the order is downgraded according to the scenario; for example, if a pre-sale order lacks a deposit amount, it is converted to a regular order. Extracting parameters through a unified interface standardizes the extraction process and reduces development and maintenance costs.

[0033] The above are only three feasible implementation methods of step S10 provided in this embodiment. This embodiment does not specifically limit the specific implementation method of step S10.

[0034] Step S20: When the extended executor intercepts the call intent corresponding to the business scenario object, it determines the business coordinates based on the business scenario object.

[0035] The extended executor is a core scheduling component in e-commerce systems that intercepts business scenario objects and parses their call logic. It interfaces with the BizScenario object passed by the controller, capturing business requests from various scenarios and triggering subsequent processing. The call intent is the core user business request parsed from the business scenario object, corresponding to a specific operation. The business coordinate is a triple combining the business code, scenario code, and use case identifier, uniquely locating the specific business processing logic. The business code (bizCode) is a unique code identifying the core business type, such as VIP referring to membership services. The use case identifier is usually automatically generated by the interface method receiving the request, identifying the specific business execution logic framework under the same business code. The scenario code (scenario) is a standardized identifier for a business context, such as presale referring to a pre-sale scenario.

[0036] In this embodiment, the extended executor intercepts business scenario objects, parses their invocation intent, and extracts business codes, scenario codes, and use case identifiers from these objects. The extracted business codes, use case identifiers, and scenario codes are then combined to form business coordinates in the form of triples. By combining these triples to form a unique business identifier, it can directly match the corresponding extended implementation or processing rule in the configuration center, avoiding business logic matching errors and improving processing accuracy.

[0037] In a first feasible implementation, step S20 may include: The extended executor intercepts business scenario objects, distinguishing between core e-commerce scenarios (such as order submission and payment) and non-core scenarios (such as product browsing and favorites). A priority interception and real-time processing mechanism is used for core scenario objects, while a batch interception and asynchronous processing mechanism is used for non-core scenarios. The request context encapsulated within the object is parsed to clarify the calling intent, and the business code, scenario code, and use case identifier are extracted from the business scenario object. Triples are combined according to a fixed format of business code, use case identifier, and scenario code to generate business coordinates. Combining triples in a fixed format avoids chaotic business coordinate formats and ensures the accuracy of subsequent matching with the configuration center.

[0038] For example, to address resource allocation issues arising from the tidal nature of e-commerce traffic, a pre-configured e-commerce scenario layering rule is implemented. A core scenario list and a non-core scenario list are established within the extended executor. Core scenarios include those directly impacting transactions, such as order submission, payment, inventory deduction, pre-sale deposit locking, flash sale qualification verification, and refund applications. Non-core scenarios include auxiliary scenarios such as product browsing, favorites, adding to cart, viewing reviews, and following stores. Differentiated interception strategies are provided, allowing for priority interception and real-time processing for core scenarios (e.g., allocating the highest thread priority and an independent thread pool), and batch interception and asynchronous processing for non-core scenarios (e.g., setting batch interception thresholds such as 100 objects or batches and an asynchronous thread pool). A fallback plan is also pre-defined for extended executor cluster anomalies. Core scenarios trigger local cache interception (e.g., temporarily storing objects in the server's local cache and resending them after cluster recovery), while non-core scenarios trigger delayed interception (e.g., extending the batch interception period to prevent request loss).

[0039] In a second feasible implementation, step S20 may include: after the extended executor intercepts the invocation intent corresponding to the business scenario object, it extracts the business code, scenario code, and use case identifier from the business scenario object, combines the business code, scenario code, and use case identifier into business coordinates, and records metadata such as the coordinate generation time and associated request ID. By combining the request ID with the coordinate generation time, the complete processing chain of a certain business request can be accurately located, facilitating subsequent traceability.

[0040] Step S30: After the extended executor determines the target implementation based on the business coordinates through the configuration center, it delegates the method call triggered by the business scenario object to the target implementation for execution and obtains the execution result.

[0041] The configuration center is a core component in e-commerce systems that stores the mapping relationship between business coordinates and target implementations. Extended executors can quickly find the processing solutions corresponding to business coordinates by searching the configuration center. Implementation (Realization) is the specific business processing logic carrier that corresponds one-to-one with the business coordinates; it is usually a specific business processing class, method, or plugin. Method calls refer to specific business operation instructions triggered by business scenario objects that need to be executed. Originally, these would be handled by the system's default logic, but the extended executor will forward this call to the matched target implementation for execution, rather than executing the system's hard-coded default logic.

[0042] In this embodiment, the extended executor queries the configuration center based on business coordinates. The configuration center matches and returns the corresponding target implementation based on the business coordinates, obtaining the implementation code. After obtaining the implementation code, the extended executor searches for the instance corresponding to that code in an internal implementation registry. Once the extended executor finds the instance, it delegates the method call to this specific implementation instance for execution and obtains the execution result. By associating the implementation code with instances in the registry, there is no need to hard-code the business logic, significantly improving system scalability.

[0043] In a first feasible implementation, step S30 may include: the extended executor encapsulates the business coordinates into a standardized query request and sends it to the configuration center. The configuration center retrieves the business coordinate-implementation code mapping table based on exact matching rules, and the business coordinate-implementation code mapping table is updated in real time. It returns a uniquely corresponding target implementation code. The extended executor calls the query interface of its internal implementation registry, passes in the implementation code to obtain the corresponding business processing instance, the extended executor delegates the execution of the target method to the instance, the target implementation instance executes the business logic, returns the execution result, and the extended executor receives the result. The configuration center is searched based on exact matching rules to ensure that the business coordinates and target implementation codes correspond completely without any matching deviation.

[0044] For example, to reduce retrieval time in core scenarios, the configuration center loads the retrieval rule base in real time, prioritizing matching complete business coordinates. When monitoring mapping table change events, such as adjustments by operations personnel, the new mapping relationship is loaded into the retrieval memory to ensure the rules take effect in real time. Mapping relationships for high-frequency e-commerce business coordinates are preprocessed with hotspot caching and cached in the configuration center's local memory to avoid accessing the database for every retrieval. If a newly updated mapping rule causes a conflict where one business coordinate corresponds to multiple implementation codes, an alarm is automatically triggered, the old rule is retained, and only the validated new rule takes effect.

[0045] In addition, to enable the extended executor to quickly locate instances and avoid cross-domain searches, such as when payment instances do not need to search the order partition and business domains are stored in partitions, the extended executor receives the implementation code returned by the configuration center and calls the query interface of the internal implementation registry. The registry is stored in partitions according to e-commerce business domains, such as orders, payments, and pre-sales. First, the business domain is located by the prefix of the implementation code. For example, if the prefix of PresaleDepositCalculator is Presale, the pre-sale partition is located. Then, the business processing instance is accurately retrieved in the corresponding partition by the implementation code.

[0046] In a second feasible implementation, step S30 may include: the extended executor hierarchically decomposes the business coordinates, that is, it initiates hierarchical matching queries to the configuration center based on the business code, use case identifier, and scenario code respectively. The configuration center prioritizes accurate matching of complete coordinates; if no matching result is found, it performs a downgraded matching and returns the optimal matching target implementation code. The extended executor loads the implementation instance from the registry through the implementation code, delegates method calls to the implementation instance for execution, and obtains the execution result. Through hierarchical matching and downgrade rules, the problem of inaccurate matching of implementations in edge or temporary business scenarios is solved, avoiding business interruption.

[0047] Step S40: Generate the response content corresponding to the front-end request based on the execution result, and send the response content to the front-end.

[0048] The response content is structured data generated by the backend in response to the frontend request, conforming to preset interaction specifications. The frontend can directly parse this content and display and process it.

[0049] In this embodiment, the extended executor receives the execution result returned by the target implementation and returns it to the use case. After receiving the result, the use case continues to execute the subsequent process and finally returns the complete order result to the client.

[0050] In a first feasible implementation, step S40 may include: the extended executor receiving the raw execution result returned by the target implementation, performing structured parsing on the result, and extracting core business data. The extended executor sends the parsed result back to the corresponding business use case, and the use case executes subsequent closing logic, such as updating order transaction records and recording business logs. The use case calls the system response template component, encapsulates the complete order result into standardized response content according to the JSON format agreed upon by the front end, and sends it to the front end. The extended executor directly parses the result and sends it back to the use case, resulting in a short execution chain and low response latency.

[0051] For example, to ensure the accuracy of core data extraction, e-commerce-specific result parsing rules are constructed. Parsing templates are defined according to business type, such as orders, payments, promotions, and inventory. For instance, for order submission results, parsing includes order number, order status, payment amount, discount amount, and inventory lock ID. For payment results, parsing includes payment transaction number, payment status, payment channel, payment time, and refund identifier.

[0052] Furthermore, to avoid developing dedicated interfaces for different platforms, we have built dedicated response templates for multiple e-commerce platforms, such as apps, mini-programs, H5 pages, and merchant backends. Template fields are tailored to the characteristics of each platform. For the app, it includes complete fields, such as order details, recommended products, and after-sales access. For the mini-program, it uses simplified fields, including core order information. The merchant backend adds operational fields, such as user order channels and risk control flags.

[0053] In a second feasible implementation, step S40 may include: the extended executor marking the execution result of the target implementation with a business dimension and asynchronously pushing it to the result processing queue and the test case detection result processing queue, employing a dual mode of real-time detection and proactive retrieval to ensure no results are missed, with real-time detection taking priority and proactive retrieval performed periodically as a fallback. After obtaining the complete execution result, the test case adapts the response content format according to the front-end terminal type and pushes the adapted response content to the corresponding front-end terminal. By asynchronously pushing the result to the queue, the extended executor can release resources without waiting for subsequent processing, supporting higher concurrency request processing.

[0054] This embodiment provides a control method for an e-commerce transaction system. After receiving a front-end request, the controller constructs a business scenario object based on the corresponding business code and scenario. When the extended executor intercepts the call intent corresponding to the business scenario object, it determines the business coordinates based on the business scenario object. The business coordinates are a triple consisting of the business code, use case identifier, and scenario code. After the extended executor determines the target implementation based on the business coordinates through the configuration center, it delegates the method call triggered by the business scenario object to the target implementation for execution and obtains the execution result. Based on the execution result, it generates the response content corresponding to the front-end request and sends the response content to the front-end. Since the response to the request is based on the call implementation, it achieves the purpose of functional plug-in on the one hand. On the other hand, when determining the implementation corresponding to the call, it is not determined directly by the extended executor based on the business coordinates, but based on the rules configured by the configuration center. Therefore, by issuing configuration rules at runtime through the configuration center, the technical effect of runtime configuration orchestration is achieved.

[0055] Based on Embodiment 1, in Embodiment 2 of this application, the content that is the same as or similar to that in Embodiment 1 can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 3 , Figure 3 This is a flowchart illustrating a second embodiment of the control method for an e-commerce transaction system according to this application. After determining the business coordinates based on the key parameters corresponding to the current request, the control method for the e-commerce transaction system further includes: Step S21: Send the service coordinates and extension point information to the configuration center.

[0056] An extension point is an abstract declaration of a business capability; it's an interface used to integrate differentiated business implementations. For example, in the pre-sale order creation process, the calculation of the national subsidy amount is an extension point. Different scenarios can integrate different national subsidy calculation logic without modifying the core order creation process.

[0057] In this embodiment, the extension point information is predefined by the system and strongly bound to specific business scenarios. The extension executor does not need to be manually configured; it only needs to read it from pre-configuration, annotations, or rules according to the current business scenario. The extension executor sends the business coordinates and extension point information to the configuration center. Simultaneously transmitting the business coordinates and extension point information provides the configuration center with a dual matching dimension of business scenario and node, avoiding implementation confusion caused by single-dimensional matching and improving the accuracy of implementation matching.

[0058] Step S22: After receiving the service coordinates and extension point information, the configuration center determines the implementation code corresponding to the service coordinates and extension point information and sends it to the extension executor so that the extension executor can determine the target implementation based on the implementation code.

[0059] In this embodiment, after receiving the business coordinates and extension point information, the configuration center matches the corresponding implementation code and sends it to the extension executor. The extension executor then determines the target implementation based on the implementation code. The extension executor only needs to receive the implementation code to obtain the target implementation, without needing to know the details such as the class name and path of the specific implementation, which facilitates subsequent implementation replacement or upgrade.

[0060] In this embodiment, by querying both business coordinates and extension point information, the configuration center can accurately locate the implementation code of a specific extension point in the corresponding business scenario, avoid implementation matching errors, and improve the accuracy of business logic execution.

[0061] Based on any of the above embodiments of this application, Embodiment 3 of this application proposes a control method for an e-commerce transaction system, which can be referred to the above description and will not be repeated hereafter. Based on this, after the configuration center receives the business coordinates and extension point information, the steps of determining the implementation code corresponding to the business coordinates and extension point information and sending it to the extension executor include: Step S221: After the configuration center receives the business coordinates and extension point information, if there is a first implementation that completely matches the business coordinates and extension information, the implementation code of the first implementation is sent to the extension executor.

[0062] The first implementation is the target implementation in the configuration center that fully matches the business coordinates and extension point information, that is, the target implementation that fully matches the business code, scenario code, use case identifier, and extension point information.

[0063] In this embodiment, the configuration center determines whether a first implementation exists that perfectly matches the business coordinates and extension point information. If so, it extracts the encoding of the first implementation and sends it to the extension executor. Assuming the current request has the business name "VIP," the use case name "Place Order," and the scenario name "Pre-sale," it needs to find the implementation of the payment calculation extension point. For example, if the configuration specifies that the pre-sale scenario uses the pre-sale deposit calculator, the query is complete and ends. If no match is found, the query is moved to the next level. Prioritizing matching accurate implementations reduces the intervention of fallback logic, shortens the matching chain, and improves the processing efficiency of core or high-frequency business scenarios.

[0064] Step S222: If the first implementation does not exist, determine whether there is a second implementation that matches the business code, and if there is a second implementation, send the implementation code of the second implementation to the extended executor.

[0065] The second implementation is the target implementation that matches the business code in the configuration center, used for accurate matching when the first implementation is missing, and for fallback matching.

[0066] In this embodiment, if the first implementation is not found, a query is performed to determine if a second implementation matches the business code, i.e., a match is made with the business code, use case identifier, and extension point information. If a match is found, the code of the second implementation is extracted and sent to the extension executor. If there are no special rules in the pre-sale scenario, a query is performed to determine if a globally default rule is configured for payment calculation across the entire VIP business, such as specifying that the VIP business uses the VIP member calculator by default. Once this is complete, the query ends. If no match is found, the query continues down to the next level. When a precise implementation is missing, a general implementation is matched by downgrading the business code to ensure that edge scenarios within the same business domain are not interrupted and to avoid business errors.

[0067] Step S223: If there is no second implementation, obtain the third implementation associated with the use case identifier and send the implementation code of the third implementation to the extended executor.

[0068] The third implementation is the target implementation corresponding to the default configuration associated with the use case identifier, used for further downgraded matching when the business code is missing the second implementation.

[0069] In this embodiment, if no second implementation is found, a query is performed to determine if a third implementation matches the use case identifier, i.e., a match is made between the use case identifier and the extension point information. If a third implementation exists, its code is extracted and sent to the extension executor. If the VIP service has no default rules, a query is performed to determine if a default payment calculation rule exists for the entire order placement use case. For example, if the configuration specifies that all order placement operations use the standard calculator by default, the query is complete and ends. If no rule is found, the query continues down to the next level. When the service code matching fails, the default configuration of the use case identifier serves as a fallback, ensuring the stable execution of the basic logic of the specific service use case and further improving system fault tolerance.

[0070] Step S224: If no third implementation exists, send the implementation code of the default implementation corresponding to the extended executor to the extended executor.

[0071] In this embodiment, if no third implementation is found, the configuration center retrieves the global default implementation corresponding to the extended executor, extracts the encoding of the default implementation, and sends it to the extended executor. When all level matching fails, the default implementation of the extended executor is used to avoid business interruption and ensure minimum system availability.

[0072] In this embodiment, by accurately matching the four-layer degradation logic that provides a global safety net, all situations from core scenarios to extreme abnormal scenarios are covered, ensuring that any request can be matched with an available implementation, avoiding business interruption and improving system stability.

[0073] Based on any of the above embodiments of this application, Embodiment 4 of this application proposes a control method for an e-commerce transaction system, which can be referred to the above description and will not be repeated hereafter. Based on this, please refer to... Figure 4 , Figure 4 This is a flowchart illustrating the control method of the e-commerce transaction system in Embodiment 4 of this application. Before the steps of the extended executor determining the target implementation based on the business coordinates through the configuration center, delegating the method call triggered by the business scenario object to the target implementation for execution, and obtaining the execution result, the control method of the e-commerce transaction system further includes: Step S23: In response to the login operation of the configuration platform, the control terminal displays the configuration interface.

[0074] In this embodiment, a login request to the configuration platform initiated by a user on the terminal is received, triggering the rendering logic of the configuration interface. A preset interface template is loaded from the configuration platform, and the terminal is controlled to display the rendered configuration interface to the user, completing the interface loading. Based on the preset template, the interface can be rendered to adapt to different user roles and display interface content with different configuration permissions, achieving refined configuration management.

[0075] Step S24: Update the configuration rules corresponding to the configuration center based on the configuration operations received from the configuration interface.

[0076] In this embodiment, based on the user operations on the configuration interface, the configuration data submitted by the user is collected, and the new configuration data is synchronized to the storage module of the configuration center to update the corresponding configuration rules. For example, an authorized person logs in to the business configuration platform supporting the Taiyi framework. On the platform interface, find the configuration path to be modified: PlaceOrderUseCase->vip service->presale scenario->PaymentCalculateExt extension point, change the currently bound implementation from PresaleDepositCalculatorV1 to PresaleDepositCalculatorV2, and update the corresponding configuration rules in the configuration center. Through the real-time update of the configuration rules, the new rules can take effect without restarting the system, improving the efficiency of configuration adjustment.

[0077] In this embodiment, dynamic update of the configuration rules is supported, which can quickly respond to business changes and improve the system's adaptability to business requirements.

[0078] Based on any of the above embodiments of the present application, Embodiment 5 of the present application proposes a control method for an e-commerce trading system, which can be referred to the above introduction and will not be elaborated hereinafter. On this basis, please refer to Figure 5 , Figure 5 is the schematic flowchart provided for Embodiment 5 of the control method of the e-commerce trading system of the present application. Before the step of the extended executor determining the target implementation through the configuration center according to the business coordinates, delegating the method call triggered by the business scenario object to the target implementation for execution, and obtaining the execution result, the control method of the e-commerce trading system further includes: Step S25, obtaining the current time point.

[0079] In this embodiment, the system time interface is called to read the current system time of the server, including year, month, day, hour, minute, and second, and format the current time into a unified format, such as yyyy-MM-dd HH:mm:ss, for subsequent period judgment. A timing task is configured in the system, such as executing once every 10 minutes, for subsequent execution period matching and rule update. By calling the system standard time interface to obtain the time, the accuracy and consistency of the time source are ensured, avoiding incorrect period judgment caused by local time deviation, and providing a reliable time basis for subsequent rule matching.

[0080] Step S26, determining the target configuration rule corresponding to the current time point according to the period in which the current time point is located.

[0081] In this embodiment, the target configuration rule corresponding to the current time period is extracted based on the time period to which it belongs. The configuration rule is automatically matched based on the time period, enabling intelligent switching of configuration rules over time to meet the business needs of different time periods; for example, holiday rules are used for holiday periods.

[0082] Step S27: If the configuration rule currently being executed in the configuration center is inconsistent with the target configuration rule, update the configuration rule currently being executed in the configuration center to the target configuration rule.

[0083] In this embodiment, the configuration rules currently being executed in the configuration center are compared with the target configuration rules. If they are inconsistent, the currently executed rules are replaced with the target configuration rules, and the changes are synchronized to the configuration center. Updates are only performed when the current rules and target rules are inconsistent, avoiding unnecessary repetitive operations, reducing system resource consumption, and ensuring that the configuration rules accurately match the time-related requirements.

[0084] In this embodiment, time-based automatic rule updates are achieved through scheduled task triggering. By configuring time-period rules, rules can be customized for traffic and business characteristics in different time periods, thereby optimizing system resource allocation and operating efficiency.

[0085] Based on any of the above embodiments of this application, Embodiment Six of this application proposes a control method for an e-commerce transaction system, which can be referred to the above description and will not be repeated hereafter. Based on this, after the controller receives a front-end request, the steps of constructing a business scenario object according to the business code and scenario corresponding to the current request include: Step S11: Parse the front-end request and determine the business code and scenario code based on the parsed request parameters.

[0086] In this embodiment, a request sent by the front end is received, the parameters in the request are parsed, and feature fields related to the business type and scenario are extracted from the parsed parameters. According to the system mapping rules, the final business code and scenario code are matched and determined. By parsing the request parameters and extracting feature fields to determine the business code and scenario code, the business and specific scenario to which the request belongs can be quickly located, laying the foundation for subsequent business logic matching.

[0087] Step S12: Determine the use case identifier based on the predefined content.

[0088] In this embodiment, annotation information from predefined interface methods is read, such as `@UseCase(code="PlaceOrderUseCase")`. This `code` is the unique identifier of the use case, serving as the use case identifier for the current request. Alternatively, the code for the current use case can be directly written when creating the `BizScenario` object. The use case identifier is extracted from the matching results and used as the use case identifier for the current request. Relying on predefined annotations, the use case identifier can be determined without manual intervention, improving development efficiency.

[0089] Step S13: Construct a business scenario object based on the business code, scenario code, and use case identifier.

[0090] In this embodiment, the business code, scenario code, and use case identifier are filled into the corresponding attributes of the business scenario object using the tools and methods provided by the framework, thus completing the construction of the business scenario object. Integrating the business code, scenario code, and use case identifier into the business scenario object facilitates unified reading and transmission by subsequent extended executors, avoiding processing chaos caused by scattered parameters.

[0091] In this embodiment, the business code and scenario code are determined by parsing the request parameters, and the use case identifier is determined by combining the predefined content. This allows for the rapid location of the business, specific scenario, and corresponding business use case to which the request belongs, laying the foundation for accurate matching of business logic in the future.

[0092] For example, to help understand the implementation flow of the control method for the e-commerce transaction system obtained in this embodiment in conjunction with the above embodiments, please refer to... Figure 6 In the order-based processing example: When a user clicks the "Submit Order" button on the front end, the front-end application or gateway constructs a request object, such as `OrderRequest`, and explicitly sets key parameters identifying the business identity of this request, forming business coordinates. The request enters the backend system, is received by the corresponding controller, and the entry method of the `PlaceOrderUseCase` use case is called. During the execution of the use case, when a pluggable business operation is required, such as calculating the payment amount, it does not directly call a specific class. Instead, it constructs a complete `BizScenario` object based on the current request's `bizCode` and `scenario`, and initiates a managed call through the extension executor. The use case only initiates the call intent, declaring that the `calculate` method of the `PaymentCalculateExt` extension point will be executed, but it does not directly execute the method. After the extension executor intercepts the call intent, it obtains the `BizScenario` passed by the caller, resulting in a triple (`vip`, `PlaceOrderUseCase`, `presale`). Based on this triple, the extension executor initiates a query to the configuration center. In the presale scenario of the PlaceOrderUseCase test case for VIP business, the query determines which implementation (Realization) should handle the extension point named PaymentCalculateExt. The configuration center returns a pre-configured unique code for the implementation class, such as PresaleDepositCalculator. After obtaining the implementation code PresaleDepositCalculator, the extension executor searches for the corresponding instance from an internal implementation registry. Once the executor finds the PresaleDepositCalculator instance, it delegates the initial method call, extension.calculate(orderRequest), to this specific implementation instance. The PresaleDepositCalculator implementation class then executes its encapsulated, specific pre-sale deposit calculation logic. After execution, the result is returned to the extension executor. The extension executor then returns the calculation result of PresaleDepositCalculator to PlaceOrderUseCase. The test case, receiving the result, continues with subsequent processes, ultimately returning the complete order result to the client.

[0093] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the humidity data correction method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0094] This application provides a control device for an e-commerce transaction system. The control device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the control method of the e-commerce transaction system in the first embodiment described above.

[0095] The following is for reference. Figure 7 The diagram illustrates a structural schematic of a control device suitable for implementing an e-commerce transaction system according to embodiments of this application. The control device for the e-commerce transaction system in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, personal digital assistants (PDAs), tablets, and in-vehicle terminals, as well as fixed terminals such as digital TVs and desktop computers. Figure 7 The control device of the e-commerce transaction system shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0096] like Figure 7 As shown, the control device of the e-commerce transaction system may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to the program stored in the read-only memory (ROM) 1002 or the program loaded from the storage device 1003 into the random access memory (RAM) 1004. The random access memory 1004 also stores various programs and data required for the operation of the control device of the e-commerce transaction system. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the control equipment of the e-commerce transaction system to communicate wirelessly or wiredly with other devices to exchange data. Although the figure shows a control equipment for an e-commerce transaction system with various systems, it should be understood that it is not required to implement or possess all the systems shown. More or fewer systems can be implemented or possessed alternatively.

[0097] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0098] The control device for the e-commerce transaction system provided in this application, employing the control method of the e-commerce transaction system in the above embodiments, can solve the technical problem of low efficiency in function implementation caused by hard coding. Compared with the prior art, the beneficial effects of the control device for the e-commerce transaction system provided in this application are the same as those of the control device for the e-commerce transaction system provided in the above embodiments, and other technical features in the control device for the e-commerce transaction system are the same as those disclosed in the method of the previous embodiment, and will not be repeated here.

[0099] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0100] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0101] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the control method of the e-commerce transaction system in the above embodiments.

[0102] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), or any suitable combination thereof.

[0103] The aforementioned computer-readable storage medium may be included in the control equipment of the e-commerce transaction system; or it may exist independently and not be assembled into the control equipment of the e-commerce transaction system.

[0104] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the control device of the e-commerce transaction system, the control device of the e-commerce transaction system: after receiving a front-end request, constructs a business scenario object based on the business code and scenario corresponding to the current request; when the extended executor intercepts the call intent corresponding to the business scenario object, it determines the business coordinates based on the business scenario object, wherein the business coordinates are a triple consisting of the business code, the use case identifier, and the scenario code; after the extended executor determines the target implementation through the configuration center based on the business coordinates, it delegates the method call triggered by the business scenario object to the target implementation for execution and obtains the execution result; based on the execution result, it generates the response content corresponding to the front-end request and sends the response content to the front-end.

[0105] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0106] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0107] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0108] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the control method of the e-commerce transaction system described above. This solves the technical problem of low efficiency in function implementation caused by hard coding. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the control method of the e-commerce transaction system provided in the above embodiments, and will not be elaborated upon here.

[0109] This application provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the control method for an e-commerce transaction system as described above.

[0110] The computer program product provided in this application can solve the technical problem of low efficiency in function implementation caused by hard coding. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the control method of the e-commerce transaction system provided in the above embodiments, and will not be repeated here.

[0111] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent scope of this application.

Claims

1. A control method for an e-commerce transaction system, characterized in that, The control method for the e-commerce transaction system includes: After the controller receives a request from the front end, it constructs a business scenario object based on the business code and scenario corresponding to the current request. When the extended executor intercepts the call intent corresponding to the business scenario object, it determines the business coordinates based on the business scenario object, wherein the business coordinates are a triple consisting of the business code, the use case identifier, and the scenario code; After the extended executor determines the target implementation based on the business coordinates through the configuration center, it delegates the method call triggered by the business scenario object to the target implementation for execution and obtains the execution result. Based on the execution result, generate the response content corresponding to the front-end request, and send the response content to the front-end.

2. The control method for an e-commerce transaction system as described in claim 1, characterized in that, After the step of determining the business coordinates based on the key parameters corresponding to the current request, the control method of the e-commerce transaction system further includes: Send the service coordinates and extension point information to the configuration center; After receiving the service coordinates and the extension point information, the configuration center determines the implementation code corresponding to the service coordinates and the extension point information, and sends it to the extension executor so that the extension executor can determine the target implementation based on the implementation code.

3. The control method for an e-commerce transaction system as described in claim 2, characterized in that, The step of determining the implementation code corresponding to the service coordinates and the extension point information after receiving them from the configuration center, and sending it to the extension executor, includes: After the configuration center receives the service coordinates and the extension point information, if there is a first implementation that completely matches the service coordinates and the extension information, the implementation code of the first implementation is sent to the extension executor. If no first implementation exists, then determine whether a second implementation matching the business code exists, and if a second implementation exists, send the implementation code of the second implementation to the extended executor; If the second implementation does not exist, obtain the third implementation associated with the use case identifier, and send the implementation code of the third implementation to the extended executor, wherein the third implementation is the default configuration associated with the use case identifier; If no third implementation exists, the implementation code of the default implementation corresponding to the extended executor is sent to the extended executor.

4. The control method for an e-commerce transaction system as described in claim 2, characterized in that, Before the step of delegating the method call triggered by the business scenario object to the target implementation for execution and obtaining the execution result after the extended executor determines the target implementation based on the business coordinates through the configuration center, the control method of the e-commerce transaction system further includes: In response to the login operation of the configuration platform, the control terminal displays the configuration interface; Based on the configuration operations received from the configuration interface, the configuration rules corresponding to the configuration center are updated.

5. The control method for an e-commerce transaction system as described in claim 2, characterized in that, Before the step of delegating the method call triggered by the business scenario object to the target implementation for execution and obtaining the execution result after the extended executor determines the target implementation based on the business coordinates through the configuration center, the control method of the e-commerce transaction system further includes: Get the current time point; Based on the time period in which the current time point is located, determine the target configuration rule corresponding to the current time point; If the configuration rule currently being executed by the configuration center is inconsistent with the target configuration rule, the configuration rule currently being executed by the configuration center shall be updated to the target configuration rule.

6. The control method for an e-commerce transaction system as described in claim 1, characterized in that, The step of constructing a business scenario object based on the business code and scenario corresponding to the current request after the controller receives the front-end request includes: Parse the front-end request and determine the business code and the scenario code based on the parsed request parameters; The use case identifier is determined based on predefined content; The business scenario object is constructed based on the business code, the scenario code, and the use case identifier.

7. A control device for an e-commerce transaction system, characterized in that, The control device of the e-commerce transaction system includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the control method of the e-commerce transaction system as described in any one of claims 1 to 6.

8. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the computer-readable storage medium. When the computer program is executed by a processor, it implements the steps of the control method of the e-commerce transaction system as described in any one of claims 1 to 6.

Images