Order request processing method and apparatus, storage medium, and terminal

Abstract

The embodiment of the specification discloses an order request processing method and device, a storage medium and a terminal. First, after receiving an external request, it is mapped to a standardized interface predefined according to transaction capability. Each interface is bound to a dedicated idempotent function, converging external diversity into internal standards, achieving separation of concerns at the architecture level and reducing system complexity. According to the definition of the idempotent function of the target interface, the key information field is accurately extracted from the request as the input of generating a unique identifier, laying the foundation for subsequent idempotent calculation. Subsequently, the idempotent function is called, and the extracted elements are calculated according to the preset rules to generate a globally unique order number, providing a reliable index for verification. Finally, the internal system processes the request based on the standardized global number, and returns the result to the external platform after processing is completed, realizing the decoupling of the internal core and external interaction, and improving the scalability and stability of the system.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to an order request processing method, apparatus, storage medium, and terminal. Background Technology

[0002] For enterprises, in the context of extensive collaboration between internal systems and external platforms, significant heterogeneity exists between external platforms in terms of idempotency strategies and communication modes. Traditional customized development typically hard-codes adaptation logic, leading to deep coupling between services and protocols, severely limiting system scalability and maintainability. Furthermore, the lack of a unified idempotency control and state management mechanism can result in duplicate processing of external requests, causing data corruption, and fragmented order data across different scenarios makes it difficult to meet compliance requirements for global auditing and traceability. Therefore, there is an urgent need to build solutions to address these challenges in cross-platform integration scenarios. Summary of the Invention

[0003] This specification provides an order request processing method, apparatus, storage medium, and terminal, which can solve the technical problems of low efficiency and poor effect of cross-platform integration in related technologies.

[0004] Firstly, embodiments of this specification provide an order request processing method, the method comprising: Receive order requests from external platforms, determine the target interface corresponding to the order requests, wherein the target interface is a standardized interface abstracted based on transaction processing capabilities, and each standardized interface corresponds to a dedicated idempotent function; Extract at least one target request element from the order request above, which is the key information field used to identify an order request, that is the target idempotent function corresponding to the target interface above. Call the idempotent function above to generate a global order number corresponding to the order request based on each target request element; The internal system drives the processing of the order request based on the global order number and returns the processing information to the external platform.

[0005] In one possible implementation, generating the global order number corresponding to the order request based on each target request element includes: dynamically generating the global order number corresponding to the order request based on each target request element according to a preset element combination rule on which the idempotent function depends; the preset element combination rule includes at least the number and order of element selection.

[0006] In one possible implementation, after generating the global order number corresponding to the order request based on each target request element, the method further includes: creating a generalized order record for the order request based on the global order number, and storing the generalized order record in a database, wherein the generalized order record contains at least the global order number and the original request data of the order request.

[0007] In one possible implementation, before creating the generalized order record based on the global order number, the method further includes: performing an idempotency check using the global order number as an index to determine whether the order request has been processed; if it has been processed, directly returning the stored processing information.

[0008] In one possible implementation, the idempotency check is implemented through a pre-established key mapping store, which is used to store the correspondence between the external combined serial number and the global order number of the same order request, wherein the external combined serial number is generated by the external platform according to its own idempotency strategy.

[0009] In one possible implementation, the generalized order record also includes an order status, which is one of four predefined standardized states, including initialization status, processing status, success status, and failure status.

[0010] In one possible implementation, the method further includes: obtaining the actual transaction status returned by the internal system; converting the actual transaction status into the target status corresponding to the standardized status according to a preset status mapping rule, and updating the order status in the generalized order record.

[0011] In one possible implementation, the method further includes: persistently storing the original request data of the order request in a database after serialization; when an order request of a preset type is detected, performing a deserialization operation to restore and calculate the original request data, wherein the preset type includes at least one of retry, reconciliation, and audit.

[0012] In one possible implementation, the method further includes: scanning the generalized order records in the above-mentioned processing state through a distributed scheduling framework, triggering a retry process for orders that have not been processed for more than a preset time, and resending the processing request to the above-mentioned internal system.

[0013] In one possible implementation, the aforementioned internal driving system processes the order request based on the aforementioned global order number, including: determining the communication mode required by the aforementioned external platform, wherein the communication mode is synchronous or asynchronous; if the communication mode is synchronous, returning an acceptance response to the aforementioned external platform and encapsulating the order request into a transaction message and sending it to a message queue; if the communication mode is asynchronous, encapsulating the order request into a transaction message and sending it to a message queue, and returning the processing result to the aforementioned external platform through a callback mechanism after the aforementioned internal system has completed processing.

[0014] Secondly, embodiments of this specification provide an order request processing apparatus, the apparatus comprising: The external request receiving module is used to receive order requests from external platforms and determine the target interface corresponding to the order request. The target interface is a standardized interface abstracted based on transaction processing capabilities, and each standardized interface corresponds to a dedicated idempotent function. The capability interface call module is used to extract at least one target request element from the order request, which is the target idempotent function corresponding to the target interface depends on. The request element is a key information field used to identify an order request. The global number generation module is used to call the idempotent function mentioned above to generate the global order number corresponding to the order request based on each target request element. The internal standard processing module is used to drive the internal system to process the order request based on the global order number and return the processing information to the external platform.

[0015] Thirdly, embodiments of this specification provide a computer program product containing instructions that, when run on a computer or processor, cause the computer or processor to perform the steps of the method described above.

[0016] Fourthly, embodiments of this specification provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the steps of the method described above.

[0017] Fifthly, embodiments of this specification provide a terminal including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is adapted to be loaded by the processor and to execute the steps of the method described above.

[0018] The beneficial effects of the technical solutions provided in some embodiments of this specification include at least the following: This specification provides an order request processing method that receives order requests from an external platform, determines the target interface corresponding to the order request, wherein the target interface is a standardized interface abstracted based on transaction processing capabilities, and each standardized interface corresponds to a dedicated idempotent function; extracts at least one target request element from the order request on which the target idempotent function corresponding to the target interface depends, the request element being a key information field used to identify an order request; calls the idempotent function to generate a global order number corresponding to the order request based on each target request element; drives the internal system to process the order request based on the global order number, and returns the processing information to the external platform. Firstly, at the system entry point, a unified operation is performed on massive heterogeneous external requests, directly mapping them to standardized target interfaces based on their essential request actions. Simultaneously, since each standardized interface is bound to a dedicated idempotent function, different idempotent strategies are adopted for different transaction actions. This step, through standardized interfaces, eliminates the need for internal core logic to directly perceive external platforms, reducing overall system complexity and providing a unified context for subsequent processing. Binding idempotent functions to interfaces ensures flexibility while allowing for more refined and centralized configuration and management of idempotent strategies, decoupling them from external platforms. Furthermore, after determining the target interface and corresponding idempotent function, key fields related to idempotency calculations are extracted from the original request as target request elements for subsequent calculations. This improves the accuracy and efficiency of the processing. By extracting only the key information required by the idempotent function, the overhead of processing large amounts of irrelevant data is avoided, and the determinism of the idempotency calculation source data is ensured, guaranteeing that the subsequently generated number accurately reflects the identity of this request. Based on this, the extracted target request elements are used as input for calculation, outputting a globally unique order number. This step dynamically generates a unique identifier for the order request, achieving standardized encapsulation of idempotency control logic. The internal system only needs to verify based on this number without needing to concern itself with the specific details of its generation, providing a reliable and efficient unique index for idempotency verification. Finally, after generating the global order number, the internal core system no longer directly processes the complex formats of external requests. Instead, it relies on the standardized global order number and its associated standardized context information to process requests. This step ultimately achieves efficient decoupling between internal and external systems. Internal systems can focus on their core logic, thereby greatly improving development efficiency and system stability. For external platforms, this results in a clearer and more consistent interactive experience. The entire process ensures efficient, stable, and scalable processing, achieving a highly cohesive and loosely coupled system framework, and enhancing the flexibility, maintainability, and scalability of cross-platform integration. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 An exemplary system architecture diagram of an order request processing method provided in the embodiments of this specification; Figure 2 A flowchart illustrating an order request processing method provided in an embodiment of this specification; Figure 3 A hierarchical architecture example diagram of an order request processing method provided in the embodiments of this specification; Figure 4 A flowchart illustrating an order request processing method provided in an embodiment of this specification; Figure 5 A structural block diagram of an order request processing device provided in the embodiments of this specification; Figure 6 This is a schematic diagram of the structure of a terminal provided in an embodiment of this specification. Detailed Implementation

[0021] To make the features and advantages of the embodiments of this specification more apparent and understandable, the technical solutions of 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 specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the embodiments of this specification.

[0022] In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with those in this specification. Rather, they are merely examples of apparatuses and methods consistent with some aspects of the embodiments in this specification as detailed in the appended claims. Furthermore, in the description of the embodiments in this specification, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the word "and / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist, for example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Additionally, in the description of the embodiments in this specification, "multiple" refers to two or more.

[0023] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0024] In today's context of enterprise digitalization, systems often need to collaborate with other external platforms to expand service boundaries and improve market responsiveness. These external platforms are often technically independent and exhibit significant heterogeneity. That is, different external platforms may use idempotent strategies such as single serial numbers, multi-field key combinations, or even dynamic concatenation rules; communication modes range from synchronous interfaces requiring real-time responses to asynchronous interactions relying on callback notifications; and data models and state definitions differ considerably. The traditional approach is to develop customized interfaces for each external platform, hard-coding adaptation logic in the code. This leads to deep coupling between transaction processing and underlying protocols. This tightly coupled architecture requires significant repetitive development work when facing new platform integration or existing protocol upgrades, severely limiting the overall scalability and maintainability of the architecture.

[0025] Furthermore, customized development models struggle to guarantee cross-platform data consistency and traceability. Due to the lack of a unified idempotent control mechanism, retries, timeouts, or duplicate requests from external platforms may be processed multiple times by the system, leading to data corruption and even financial losses. Simultaneously, independent state management across different scenarios makes it difficult to meet regulatory requirements for data auditing and state traceability in sensitive areas such as permissions and compliance. Taking the financial sector as a typical example, in the context of extensive collaboration with various external institutions (such as traffic platforms, banks, and trusts), the differences between external platforms in various aspects force internal development teams to repeatedly adapt their systems. Moreover, for services involving the entire lifecycle of account opening, credit granting, disbursement, and repayment, traditional scenario-specific customized order systems struggle to form a unified semantic view of orders and states. This necessitates piecing together data from multiple isolated systems for compliance audits, resulting in low efficiency and potential compliance risks.

[0026] It is evident that existing order processing mechanisms suffer from significant problems such as rigidity, low development efficiency, and fragile data consistency. Therefore, this specification provides an order request processing method to address the aforementioned technical issues of low efficiency and poor performance in cross-platform integration.

[0027] Please see Figure 1 , Figure 1 This is an exemplary system architecture diagram of an order request processing method provided in the embodiments of this specification.

[0028] like Figure 1As shown, the system architecture may include a terminal 101, a network 102, and a server 103. The network 102 serves as the medium for providing a communication link between the terminal 101 and the server 103. The network 102 may include various types of wired or wireless communication links, such as wired communication links including fiber optic cables, twisted-pair cables, or coaxial cables, and wireless communication links including Bluetooth communication links, Wireless-Fidelity (Wi-Fi) communication links, or microwave communication links, etc.

[0029] Terminal 101 can interact with server 103 via network 102 to receive messages from or send messages to server 103. Alternatively, terminal 101 can interact with server 103 via network 102 to receive messages or data sent to server 103 by other users. Terminal 101 can be hardware or software. When terminal 101 is hardware, it can be various electronic devices, including but not limited to smartphones, tablets, laptops, and desktop computers. When terminal 101 is software, it can be installed in the aforementioned electronic devices and can be implemented as multiple software programs or software modules (e.g., to provide distributed services) or as a single software program or software module; no specific limitation is made here.

[0030] In the embodiments described in this specification, terminal 101 first receives an order request from an external platform and determines the target interface corresponding to the order request. The target interface is a standardized interface abstracted based on transaction processing capabilities, and each standardized interface corresponds to a dedicated idempotent function. Next, terminal 101 extracts at least one target request element from the order request, which is the key information field used to identify an order request. Further, terminal 101 calls the idempotent function to generate a global order number corresponding to the order request based on each target request element. Finally, terminal 101 drives the internal system to process the order request based on the global order number and returns the processing information to the external platform.

[0031] Server 103 can be a server that provides various services. It should be noted that server 103 can be hardware or software. When server 103 is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When server 103 is software, it can be implemented as multiple software programs or software modules (e.g., used to provide distributed services), or as a single software program or software module; no specific limitations are made here.

[0032] Alternatively, the system architecture may not include server 103. In other words, server 103 may be an optional device in the embodiments of this specification. That is, the method provided in the embodiments of this specification can be applied to a system structure that only includes terminal 101. The embodiments of this specification do not limit this.

[0033] It should be understood that Figure 1 The number of terminals, networks, and servers shown is only illustrative; the number can be any number of terminals, networks, and servers depending on the implementation requirements.

[0034] Please see Figure 2 , Figure 2 This is a flowchart illustrating an order request processing method provided in an embodiment of this specification. The execution entity in this embodiment can be a terminal executing order request processing, a processor within the terminal executing the order request processing method, or an order request processing service within the terminal executing the order request processing method. For ease of description, the following example uses a processor within the terminal as the execution entity to illustrate the specific execution process of the order request processing method.

[0035] like Figure 2 As shown, an order request processing method may include at least: S202. Receive an order request from an external platform and determine the target interface corresponding to the order request. The target interface is a standardized interface abstracted based on transaction processing capabilities, and each standardized interface corresponds to a dedicated idempotent function.

[0036] Optionally, when processing order requests from external platforms, traditional technical solutions typically employ customized development for each external partner. The core drawback of this approach is that the internal system must directly address the differences in interface definitions, data structures, and idempotency strategies among various external platforms, resulting in a large amount of adaptation logic specific to each partner being mixed into the logic code. As the number of external platforms increases or interface protocols are updated, system maintenance costs rise exponentially, and inconsistent idempotency implementations can easily lead to duplicate processing or data corruption. To address this issue, the embodiments in this specification introduce a standardized interface abstraction mechanism at the entry point for receiving order requests. When the system receives an order request from an external platform, it does not directly forward it to the internal functional module for processing. Instead, it first performs an identification and mapping operation, that is, first determines the target interface corresponding to the request.

[0037] In practice, upon receiving an order request from an external platform, the system identifies and locates the request based on a pre-built three-tier architecture model. Please refer to [link / reference]. Figure 3 , Figure 3 This diagram illustrates the hierarchical architecture of an order request processing method provided in an embodiment of this specification. Figure 3 As shown, this three-layer cooperation model abstracts external cooperation into three core layers: the channel layer, the partner layer, and the open product layer. Taking the consumer finance field as an example, the channel layer connects with entry-level partners such as traffic platforms and distribution channels; the partner layer connects with specific financial institutions or service providers, such as a bank or trust company; and the open product layer defines the specific product capabilities for collaboration with external parties. When an order request arrives, the request typically carries information that identifies these three layers, such as channel identifiers, partner codes, and product codes. By parsing this information, the system can accurately determine the context to which the request belongs. This identification process provides a basis for subsequently determining the target interface.

[0038] Please continue reading. Figure 3 After clarifying the transaction context of the request, the system further determines the target interface corresponding to the request based on the architecture design of interface capability segmentation. Interface capability segmentation refers to breaking down the transaction processes contained in the product into standardized interface capability layers based on the open product layer, such as key process nodes like credit granting interfaces, disbursement interfaces, and repayment interfaces. Specifically, this target interface is a standardized interface obtained after logical abstraction based on transaction processing capabilities. To achieve the mapping between requests and interfaces, the system pre-abstracts various transaction operations (such as order creation, status query, credit granting, payment, repayment, etc.) into a finite set of standard interface types. Each standard interface represents a type of action with the same transaction semantics and is used to handle a type of transaction requirement. This abstraction operation can decouple the specific manifestation of external requests from the meaning of internal expectations. Regardless of the data format, field naming, or calling method used by the external platform to express its intent, the system can reduce it to the corresponding standard interface that can handle its current requirement through pre-defined mapping rules. Meanwhile, each standardized interface is configured to be bound to a dedicated idempotent function, which means that different idempotent strategies can be adopted for different transaction scenarios, maintaining flexibility while separating the idempotent control logic from hard-coded logic, thus achieving separation of concerns.

[0039] S204. Extract at least one target request element from the order request that the target idempotent function corresponding to the target interface depends on. The request element is a key information field used to identify an order request.

[0040] Optionally, after determining the standard interface to which the request belongs, the system extracts the target request elements upon which the idempotent function depends from the original request. These request elements refer to key information fields that can uniquely identify an order request, typically including but not limited to external platform identifiers, external order serial numbers, timestamps, and user identification. Please continue reading. Figure 3At the idempotency layer, each standardized interface is bound to a dedicated idempotency function (F1, F2, etc.), which, based on its transaction characteristics, pre-defines the set of key request elements it depends on (X1, X2, ..., Xn). Different idempotency functions may depend on different sets of elements. For example, in some scenarios, only a single partner serial number is needed to ensure idempotency, while in others, a combination of partner identifier and timestamp may be required. Through this step, the system does not need to attempt to understand the entire request message. Instead, based on the definition of the idempotency function bound to the target interface, it precisely extracts the required elements from the request in an "on-demand" manner. The values ​​of these extracted elements will serve as input for subsequently generating a global order number. This process only needs to focus on the core information related to idempotency calculation, while other data in the request is temporarily ignored.

[0041] It's important to note that in practical applications, the specific definitions of the standardized interface can be used to dynamically determine which request elements need to be extracted, rather than using fixed extraction rules. This allows for fine-grained adaptation to the needs of different scenarios. Based on predefined element mapping rules, information that may exist in external requests with different field names or nested structures is uniformly converted into a standard element format that is recognizable internally. This ensures the determinism and purity of the source data upon which subsequent idempotent calculations rely. The introduction of the standardized interface eliminates the complexity caused by external diversity; and the accurate extraction of request elements provides a reliable data foundation for generating globally unique order numbers. This not only achieves decoupling at the transaction semantic level, making the internal system unaware of the differences in external interfaces, but also completes data preprocessing, laying the foundation for unified, reliable, and efficient idempotent control, and ensuring the high scalability and maintainability of the entire system.

[0042] S206. Call the idempotent function to generate the global order number corresponding to the order request based on each target request element.

[0043] Alternatively, please continue reading Figure 3After standardizing the interface mapping for external order requests and extracting idempotent key elements, the system calls the dedicated idempotent function bound to the interface. Following the preset element combination rules upon which the idempotent function depends, it dynamically generates a global order number corresponding to each target request element based on the desired element combination. These preset element combination rules include at least the number and order of elements selected. An idempotent function is a computational logic unit specifically designed to map input elements to a unique output identifier. Its core principle is that for the same set of input elements, the output remains consistent regardless of the number of times it is called. The preset element combination rules define the specific way to organize multiple request elements into the function input, including constraints on at least the number and order of elements selected. For example, in some scenarios, the idempotent function might require concatenating the partner identifier, date, and external serial number in the order of "partner identifier + date + external serial number" to calculate the hash value; while in other scenarios, only a single external serial number might suffice. This design separates the idempotency control logic from the code and embeds it in the idempotent function through declarative configuration, so that the order number generation process also carries the function of idempotency verification.

[0044] Understandably, since the computational logic of idempotent functions is deterministic, the same input request elements will inevitably output the same global order number. This allows the order number to serve as a "digital fingerprint" of the request identity. When duplicate requests occur subsequently, the system only needs to calculate its number for identification, without needing to delve into complex state judgments. On the other hand, by configuring the number and order of selected elements, the same idempotent function framework can adapt to the differentiated needs of different scenarios. For example, for payment requests with high real-time requirements, it may only need to rely on an external serial number to ensure processing speed; while for credit authorization requests involving multi-party collaboration, a combination of multiple elements such as partner identifiers, product codes, and dates may be needed to ensure the accuracy of cross-system traceability. In addition, the generation of this number is dynamic, real-time, and strictly dependent on the input elements. Therefore, the global uniqueness of this order number is jointly guaranteed by the computational logic of the function itself (such as including timestamps, machine IDs, etc.) and the uniqueness of the input elements.

[0045] S208 drives the internal system to process order requests based on the global order number and returns the processing information to the external platform.

[0046] Optionally, after generating a global order number with idempotent semantics, the internal system is driven to process order requests based on this number and return the processing information to the external platform. Traditionally, the internal system often needs to directly parse the original message of the external request, understanding the field definitions, data formats, and semantics of different platforms, resulting in a large amount of adaptation code related to specific partners filling the underlying system logic. However, in the embodiments of this specification, the internal system no longer needs to focus on the complex details of the original request; it only needs to process it based on the global order number and its associated standard context information. Through this design, the development of the internal system can focus entirely on the implementation of the core transaction logic, without having to repeatedly develop adaptation code for each newly connected external platform, significantly improving development efficiency and system stability. Secondly, since all external requests are unified into a standardized format, the system can uniformly monitor, schedule, and manage all orders, for example, by using a distributed scheduling framework to perform timeout scanning and failure retries for orders in the processing state. Furthermore, the abstraction mechanism of the standardized processing interface lays the foundation for subsequent expansion; the access of new transactions only requires defining a new standardized interface and its corresponding idempotent function, without modifying the existing internal system logic code implementation.

[0047] This specification provides an order request processing method that receives order requests from an external platform, determines the target interface corresponding to the order request, wherein the target interface is a standardized interface abstracted based on transaction processing capabilities, and each standardized interface corresponds to a dedicated idempotent function; extracts at least one target request element from the order request on which the target idempotent function corresponding to the target interface depends, the request element being a key information field used to identify an order request; calls the idempotent function to generate a global order number corresponding to the order request based on each target request element; drives the internal system to process the order request based on the global order number, and returns the processing information to the external platform. Firstly, at the system entry point, a unified operation is performed on massive heterogeneous external requests, directly mapping them to standardized target interfaces based on their essential request actions. Simultaneously, since each standardized interface is bound to a dedicated idempotent function, different idempotent strategies are adopted for different transaction actions. This step, through standardized interfaces, eliminates the need for internal core logic to directly perceive external platforms, reducing overall system complexity and providing a unified context for subsequent processing. Binding idempotent functions to interfaces ensures flexibility while allowing for more refined and centralized configuration and management of idempotent strategies, decoupling them from external platforms. Furthermore, after determining the target interface and corresponding idempotent function, key fields related to idempotency calculations are extracted from the original request as target request elements for subsequent calculations. This improves the accuracy and efficiency of the processing. By extracting only the key information required by the idempotent function, the overhead of processing large amounts of irrelevant data is avoided, and the determinism of the idempotency calculation source data is ensured, guaranteeing that the subsequently generated number accurately reflects the identity of this request. Based on this, the extracted target request elements are used as input for calculation, outputting a globally unique order number. This step dynamically generates a unique identifier for the order request, achieving standardized encapsulation of idempotency control logic. The internal system only needs to verify based on this number without needing to concern itself with the specific details of its generation, providing a reliable and efficient unique index for idempotency verification. Finally, after generating the global order number, the internal core system no longer directly processes the complex formats of external requests. Instead, it relies on the standardized global order number and its associated standardized context information to process requests. This step ultimately achieves efficient decoupling between internal and external systems. Internal systems can focus on their core logic, thereby greatly improving development efficiency and system stability. For external platforms, this results in a clearer and more consistent interactive experience. The entire process ensures efficient, stable, and scalable processing, achieving a highly cohesive and loosely coupled system framework, and enhancing the flexibility, maintainability, and scalability of cross-platform integration.

[0048] Please see Figure 4 , Figure 4This is a flowchart illustrating an order request processing method provided in an embodiment of this specification.

[0049] like Figure 4 As shown, an order request processing method may include at least: S402. Receive an order request from an external platform and determine the target interface corresponding to the order request. The target interface is a standardized interface abstracted based on transaction processing capabilities, and each standardized interface corresponds to a dedicated idempotent function.

[0050] S404. Extract at least one target request element from the order request that the target idempotent function corresponding to the target interface depends on. The request element is a key information field used to identify an order request.

[0051] S406. Call the idempotent function to generate a global order number corresponding to the order request based on each target request element.

[0052] For details regarding steps S402-S406, please refer to the detailed descriptions in steps S202-S206, which will not be repeated here.

[0053] S408. Perform idempotency check using the global order number as an index to determine whether the order request has been processed; if it has been processed, directly return the stored processing information.

[0054] Optionally, in the order request processing flow, idempotency verification is a crucial step in ensuring data consistency and preventing risks. Therefore, after generating a global order number, the system can use this number to perform idempotency checks. Specifically, before officially driving the internal system to process the order request, the pre-established key mapping storage is queried using the generated global order number as a unique index to determine whether the order request corresponding to that number has been processed. If the query result shows that the number already exists and has been processed, the stored processing information is directly returned to avoid duplicate execution; if the number does not exist or the corresponding order is in an incomplete state, the subsequent processing flow continues. The key mapping storage is a storage structure specifically used to maintain the correspondence between external request identifiers and internal processing states. Specifically, it can be represented as a mapping table that records the association between the external combined serial number and the global order number, as well as the processing status, of each order request. The external combined serial number of each order request refers to a unique request identifier generated by the external platform according to its own idempotency strategy. It may consist of a single field or a combination of multiple fields, such as the concatenation of a partner identifier and a transaction serial number. This embodiment of the specification does not limit this.

[0055] Understandably, by placing idempotency checks before request processing, the system can quickly identify duplicate requests and avoid invalid logic execution. On the other hand, since the generation rule for the global order number is guaranteed deterministically by an idempotent function, for the same original request, regardless of when it arrives, the calculated global order number will always be the same. Therefore, using the global order number as an index for idempotency checks essentially leverages the idempotent semantics inherent in the number itself to converge complex external heterogeneous idempotency strategies into a unified internal identifier for judgment. Furthermore, the key-mapped storage not only stores the mapping relationship between external combined serial numbers and global order numbers but also records the order processing status. Thus, a single query operation can determine "whether it has been processed" and "what the processing result is," providing a data foundation for directly returning stored processing information. This step standardizes and centralizes the idempotency control logic, enabling the system to handle duplicate requests from all external platforms in a unified manner, eliminating the need to customize idempotency check code for each partner and significantly reducing development and maintenance costs. Secondly, by decoupling idempotency checks from request processing, the internal system can focus on implementing core capabilities, improving code readability and maintainability.

[0056] In practical implementation, key-mapped storage can be implemented using various technologies, such as dedicated idempotent tables in relational databases, distributed caching systems, or persistent key-value stores. Taking a relational database implementation as an example, an idempotent mapping table can be constructed, containing fields such as external combined serial number, global order number, processing status, processing result, and creation time, with the global order number or external combined serial number as a unique index. When a request arrives, the system first attempts to query the table using the global order number. If a record is found and its status is "processed," the processing result field is directly read and returned to the external platform; if the status is "processing," a timeout policy may be used to determine whether to wait or trigger a retry; if no record is found, a new record with a status of "processing" is inserted, and subsequent processing continues. After processing is complete, the record's status is updated to "processed," and the processing result is populated. This database transaction-based implementation leverages ACID properties to ensure consistency between idempotency verification and transaction processing, making it suitable for financial scenarios with high data consistency requirements. For scenarios with higher performance requirements, distributed caching such as Redis can be used, completing verification and status marking in milliseconds.

[0057] S410. Create a generalized order record for the order request based on the global order number, and store the generalized order record in the database. The generalized order record contains at least the global order number and the original request data of the order request.

[0058] Optionally, in the order request processing flow, after completing idempotency verification and confirming that the current request is the first processing, the system first persists the core information of this request to support various scenarios such as subsequent request processing, status tracking, anomaly recovery, and compliance auditing. In traditional implementations, the order table usually only stores parsed and transformed fields, while the original request messages sent by external platforms are either discarded or stored in a scattered manner as unstructured logs. When troubleshooting, reconciliation verification, or regulatory auditing is required, it is often difficult to restore the original request information.

[0059] To address this issue, the embodiments in this specification construct a general order data model decoupled from specific transaction scenarios. After idempotency verification passes, the system creates a generalized order record based on the global order number and persistently stores this record in the database. This record contains at least two core components: the global order number and the original request data of the order request. The global order number serves as a unique identifier throughout the entire lifecycle of the order, while the original request data refers to the raw message sent by the external platform without any processing. In addition, the generalized order record also includes common fields such as order status, acceptance time, and completion time to support order lifecycle management. The generalized order record in the embodiments of this specification refers to a predefined general order data structure that is compatible with multiple transaction scenarios, aiming to achieve unified storage and management of different transaction types while ensuring data integrity. The raw request data refers to the raw message content sent by the external platform without parsing or conversion, usually presented in JSON, XML, or other data exchange formats. Its function is to serve as an authoritative data source for subsequent request processing, problem investigation, and compliance auditing.

[0060] Furthermore, to ensure complete retention of the original request, the original request data is persistently stored in serialized form. When a predefined type of order request is detected, the original request data is recovered through deserialization. The predefined type includes at least one of retry, reconciliation, and auditing to avoid losing critical information due to data conversion. For example, when an audit requires original vouchers, the original request data can be directly extracted from the database to meet compliance requirements; when retrying a failed request, processing parameters can be reconstructed from the original request data to ensure the accuracy and consistency of the retry operation. In other words, when storing the original request data, the system performs serialization to convert it into a persistent format; and when needed, it performs deserialization to restore it to an in-memory request object model. This bidirectional conversion capability supports various transaction scenarios. In addition, the order status stored in the generalized order record can be managed using a standardized four-state model, including initialization, processing, success, and failure. This standardized state definition, together with the original request data, constitutes a complete order lifecycle record, enabling the system to uniformly monitor, schedule, and manage all orders.

[0061] In terms of specific implementation, the creation and storage of generalized order records can be achieved using various technologies. Taking a relational database as an example, a generalized order master table can be designed, containing core fields such as global order number, order status, acceptance time, completion time, and original request data. The original request data is typically stored in CLOB or JSON format. When an order request arrives, the system first inserts a generalized order record with a status of "initialized" or "processing," and writes the complete original request data into the corresponding fields. Subsequently, at different stages of request processing, the system updates the order status and completion time of this record based on the processing results. This relational database-based implementation fully utilizes the ACID properties of transactions to ensure the consistency and durability of order data.

[0062] Furthermore, to address exceptional situations in asynchronous processing scenarios, this embodiment introduces a failure retry mechanism based on a distributed scheduling framework. Specifically, the system periodically scans generalized order records in the "processing" state using the distributed scheduling framework. When the dwell time of some order records exceeds a preset threshold, the distributed scheduling framework automatically triggers a retry process, resending the processing request to the internal system. Specifically, a distributed scheduling framework is a middleware component capable of reliably executing scheduled tasks in a distributed system environment. It typically possesses capabilities such as task sharding, failover, and execution logging, ensuring high availability and accurate execution of retry tasks. The preset threshold is a configurable time parameter, set according to the characteristics of different transaction scenarios. For example, for payment requests with high real-time requirements, the threshold might be set to tens of seconds; while for credit approval requests with longer processing times, the threshold might be set to several minutes. This embodiment does not limit this setting.

[0063] Understandably, this retry mechanism enables proactive monitoring and management of orders in the "processing" state. In distributed systems, due to network jitter, service restarts, resource contention, etc., some orders may fail to proceed automatically. Through proactive scanning and retries, the system can promptly detect and repair these abnormal orders. Secondly, the retry process is triggered based on a time threshold, which effectively avoids frequent retries caused by momentary failures, reducing system load. Furthermore, the processing requests resent during retry are still constructed based on the original request data, ensuring that the transaction semantics of the retry operation are completely consistent with the original request, preventing data deviation due to retries. The order record storage mechanism in this embodiment allows the system to perform global queries and status monitoring of all orders based on a single data source. The complete retention of original request data also provides authoritative data support for problem investigation and regulatory compliance audits, significantly reducing the risks caused by missing information. The retry mechanism based on distributed scheduling provides reliable anomaly recovery capabilities for asynchronous processing scenarios, improving the overall resilience and continuity of the system. Finally, the standardized encapsulation of serialization and deserialization capabilities enables the complete preservation of original request data, thereby supporting the rapid implementation of various scenarios such as reconciliation, auditing, and retries.

[0064] S412. The internal system processes order requests based on the global order number, determines the communication mode required by the external platform (synchronous or asynchronous), and returns an accepted response to the external platform if the communication mode is synchronous, and encapsulates the order request into a transaction message and sends it to the message queue. If the communication mode is asynchronous, the internal system encapsulates the order request into a transaction message and sends it to the message queue, and returns the processing result to the external platform through a callback mechanism after the internal system has finished processing.

[0065] Optionally, in the order request processing flow, after the creation and persistence of the generalized order record are completed, the system needs to deliver the request to the internal core module for substantive processing. However, different external platforms may have different requirements for the communication mode of interaction. For example, some external platforms expect to use a synchronous method, requiring the caller to wait for the processing result in real time and return the final response; some external platforms accept an asynchronous method, allowing the system to accept the request first, and then notify the result through a callback after processing is completed. In traditional technical implementations, adaptation for different communication modes is often done through hard coding. For external platforms that require synchronous interaction, the system will directly call the internal module after receiving the request, block and wait for it to complete processing, and then return the result synchronously. However, in this case, if the internal processing takes a long time, the caller of the external platform may disconnect due to the timeout setting, resulting in an unclear request status; at the same time, synchronous calls will consume a lot of system thread resources, which can easily lead to thread pool exhaustion in high-concurrency scenarios, thereby affecting the overall system availability. For external platforms that require asynchronous interaction, a set of callback logic is usually maintained for each partner, including the storage of callback addresses, the construction of callback messages, and the design of retry mechanisms. This decentralized implementation not only leads to a large amount of duplicate code, but also results in deep coupling between callback logic and core internal processing logic, making it difficult for the system to be managed and monitored in a unified manner.

[0066] In the embodiments described in this specification, to effectively decouple the two, a unified relay mechanism based on a message queue is introduced. Through dynamic identification of communication modes, adaptation to different interaction requirements of external platforms is achieved. Specifically, before driving the internal system to process order requests, the communication mode required by the external platform is first determined. This information is usually carried in the request's metadata. Depending on the communication mode, the system executes differentiated processing logic. However, regardless of whether it is synchronous or asynchronous, the order request is ultimately encapsulated as a transaction message and sent to the message queue, where the internal system consumes and processes it in its own supported manner. This allows the internal system modules to be unaware of the differences in communication modes of the external platform; whether the external requirement is synchronous or asynchronous, the internal system uses the same standardized message processing flow.

[0067] In this step, a message queue is a middleware component used to implement asynchronous communication, capable of temporarily storing messages and reliably delivering them to consumers. The callback mechanism refers to the process of proactively sending a processing result notification to a pre-specified callback address on the external platform after the internal system has completed its processing. It typically needs to support capabilities such as retries and timeout control to ensure the reliability of the notification. In specific implementation, before driving internal processing, the system first reads the preset communication mode configuration. For synchronous mode, after encapsulating the request as a transactional message and sending it to the message queue, the system does not wait for internal processing to complete but immediately returns an "accepted" response to the external platform. This response does not contain the final processing result; it only indicates that the system has successfully received the request and started processing. For asynchronous mode, the system encapsulates the request as a transactional message and sends it to the message queue, but does not immediately return any response. Instead, it waits for internal processing to complete before proactively pushing the processing result to the external platform through the callback mechanism. Regardless of the communication mode, the order request undergoes a local transaction commit process before being sent to the message queue. This local transaction includes operations such as creating generalized order records and initializing their states. Only after these operations are successfully completed will the transaction message be confirmed and sent. This design ensures the atomicity of the "order record storage" and "message delivery" operations, avoiding the risk of request loss due to message sending failure. By converting all requests into messages, the internal system can uniformly pull tasks from the message queue for processing, allowing it to focus on implementing its internal functional logic and simplifying the complexity of its internal logic code. Regardless of the external platform's model, the internal system always faces a standardized data structure and clear transaction semantics; the differences of the external platform are shielded within the generalized order engine.

[0068] In one feasible implementation, for synchronous mode, after sending a transaction message, the system constructs a response object containing a global order number and an "accepted" status, serializes it, and returns it to the external platform. This response may include the address of a query interface, allowing the external platform to proactively query the processing progress later. For asynchronous mode, after sending a transaction message, the system records the callback address and related parameters provided by the external platform, and constructs a callback request after internal processing is complete. The callback process needs to have retry capabilities; for example, when the callback interface returns a non-success status code or times out, the system retryes multiple times according to an exponential backoff strategy until success or the maximum number of retries is reached.

[0069] S414. Obtain the actual transaction status returned by the internal system; according to the preset status mapping rules, convert the actual transaction status into the target status corresponding to the standardized status, and update the order status in the generalized order record.

[0070] Optionally, traditional order status management often employs a customized approach bound to specific transaction scenarios. Taking consumer finance as an example, an account opening request might have statuses such as "identity verification in progress," "payment method binding completed," and "account opening successful"; a credit granting request might have statuses such as "credit inquiry in progress," "credit limit calculation in progress," and "credit grant successful." These statuses not only have different names but also varying numbers; some transactions require three or four statuses, while others may require seven or eight. When order data from these different transactions are stored centrally, the meaning of the status fields becomes ambiguous, making it difficult to achieve unified querying and statistical analysis across transactions, and even more difficult to establish unified monitoring indicators and alarm rules. To address this issue, the embodiments in this specification introduce a standardized status abstraction and dynamic mapping mechanism.

[0071] In the embodiments of this specification, a finite set of standardized states is predefined, including four types: initialization state, processing state, success state, and failure state. These serve as unified state identifiers used in the generalized order record. The internal system further refines the identifiers based on the original state of the specific transaction for the processing of various transactions. The initialization state indicates that the order has just been created and has not yet entered the actual processing flow; the processing state indicates that the order has entered the processing stage but has not yet received a final result; the success state indicates that the processing has been successfully completed; and the failure state indicates that the processing failed to complete for some reason. These four states can cover the complete lifecycle of each request in all scenarios. When the internal system returns the actual transaction state, the system does not directly write this original state into the order record. Instead, it converts it into the corresponding standardized state according to the preset state mapping rules, and then uses this standardized state to update the generalized order record. Here, the actual transaction state refers to the state value with complete transaction semantics returned by the internal system after executing the specific transaction logic, such as "credit limit calculation completed" or "loan disbursement successful." The standardized states refer to the four predefined general states that are independent of specific scenarios. Their function is to serve as identifiers for uniformly identifying the order processing progress at the system level. The state mapping rules define the conversion logic between the actual transaction state and the standardized state. They are usually in the form of configuration tables or rule engines and can be customized according to different transaction types, interface capabilities, or even partner dimensions.

[0072] Specifically, by extracting order status from specific transaction semantics and retaining only its function as an indicator of processing progress, the system gains the ability to uniformly manage all orders. This abstraction allows the system to uniformly monitor, statistically analyze, and govern all orders without concern for the details of transaction processing. Furthermore, the correspondence between actual transaction states and standardized states is not fixed but dynamically transformed through configurable mapping rules. By flexibly configuring these rules, the system maintains the standardization of internal states while accommodating the differentiated needs of various transaction scenarios. Simultaneously, to meet audit traceability requirements, the system can record the complete history of state transitions, including the state before transition, the state after transition, the transition time, and the trigger source, forming a complete chain of order status change information.

[0073] In terms of specific implementation, the configuration of state mapping rules can be achieved using various technologies. A common approach is a state mapper based on a configuration center. For example, the state mapper can primarily be represented as a state mapping configuration table, containing fields such as transaction type, interface identifier, actual state code, and standardized state code. When the internal system returns the actual state, the system queries this table to find the corresponding standardized state code based on the transaction type and interface identifier of the current order, and then performs an update operation. This relational database-based implementation is simple, intuitive, easy to maintain, and extensible. Another approach is dynamic mapping based on a rule engine, suitable for scenarios with more complex state transition logic. For example, some actual states may require combining other contextual information of the order (such as amount, time, user type, etc.) to determine the final standardized state. In this case, conditional judgment logic can be written through the rule engine to achieve more refined state transitions.

[0074] This specification provides an order request processing method in its embodiments. First, by using idempotency verification indexed by the global order number, resource waste and risks associated with redundant processing are avoided, while simultaneously improving system response efficiency and data consistency. Second, by creating generalized order records and persisting the original request data, a unified data foundation is constructed, enabling centralized storage of all orders and significantly enhancing system traceability and compliance. Third, a retry mechanism based on distributed scheduling improves system continuity. Fourth, by dynamically identifying the communication patterns of external platforms and implementing unified relay based on transactional messages, external interaction and internal processing are completely decoupled. Fifth, through a standardized four-state model and dynamic state mapping, the states returned by the internal system are converged into a unified system identifier, achieving unified monitoring, statistical analysis, and anomaly management across transactions. Sixth, configurable mapping rules accommodate differentiated expressions in various scenarios, ultimately ensuring the determinism and traceability of the order lifecycle through controllable state transitions.

[0075] Please see Figure 5, Figure 5 This is a structural block diagram of an order request processing device provided as an embodiment of this specification. Figure 5 As shown, the order request processing device 500 includes: The external request receiving module 510 is used to receive order requests from external platforms and determine the target interface corresponding to the order request. The target interface is a standardized interface abstracted based on transaction processing capabilities, and each standardized interface corresponds to a dedicated idempotent function. The capability interface call module 520 is used to extract at least one target request element from the order request, which is the key information field used to identify an order request. The global number generation module 530 is used to call an idempotent function to generate a global order number corresponding to the order request based on each target request element. The internal standard processing module 540 is used to drive the internal system to process order requests based on the global order number and return the processing information to the external platform.

[0076] Optionally, the global number generation module 530 is also used to dynamically generate a global order number corresponding to the order request based on the preset element combination rules on which the idempotent function depends; the preset element combination rules include at least the number of elements selected and their arrangement order.

[0077] Optionally, the order request processing device 500 further includes: an order storage module, used to create a generalized order record for the order request based on the global order number, and store the generalized order record in the database, wherein the generalized order record contains at least the global order number and the original request data of the order request.

[0078] Optionally, the order request processing device 500 further includes an idempotency verification module, which performs idempotency verification using the global order number as an index to determine whether the order request has been processed; if it has been processed, it directly returns the stored processing information.

[0079] Optionally, idempotency verification is implemented through a pre-established key mapping store, which is used to store the correspondence between the external combined serial number and the global order number of the same order request. The external combined serial number is generated by the external platform according to its own idempotency strategy.

[0080] Optionally, the generalized order record also includes an order status, which is one of four predefined standardized states: initialization status, processing status, success status, and failure status.

[0081] Optionally, the order request processing device 500 further includes: a state transition module, used to obtain the actual transaction state returned by the internal system; according to the preset state mapping rules, convert the actual transaction state into the target state corresponding to the standardized state, and update the order state in the generalized order record.

[0082] Optionally, the order request processing device 500 further includes: a raw data persistence module, used to persistently store the raw request data of the order request in the database after serialization; when an order request of a preset type is detected, the raw request data is obtained by deserialization, and the preset type includes at least one of retry, reconciliation, and audit.

[0083] Optionally, the order request processing device 500 further includes a distributed scheduling module, which scans the generalized order records in the processing state through a distributed scheduling framework, triggers a retry process for orders that have not been processed for more than a preset time, and resends the processing request to the internal system.

[0084] Optionally, the internal standard processing module 540 is also used to determine the communication mode required by the external platform, which is synchronous or asynchronous. If the communication mode is synchronous, it returns an accepted response to the external platform and encapsulates the order request into a transaction message and sends it to the message queue. If the communication mode is asynchronous, it encapsulates the order request into a transaction message and sends it to the message queue, and returns the processing result to the external platform through a callback mechanism after the internal system has finished processing.

[0085] In this embodiment, an order request processing apparatus is provided, comprising: an external request receiving module for receiving order requests from an external platform and determining the target interface corresponding to the order request, wherein the target interface is a standardized interface abstracted based on transaction processing capabilities, and each standardized interface corresponds to a dedicated idempotent function; a capability interface invocation module for extracting at least one target request element from the order request on which the target idempotent function corresponding to the target interface depends, wherein the request element is a key information field used to identify an order request; a global number generation module for invoking the idempotent function to generate a global order number corresponding to the order request based on each target request element; and an internal standard processing module for driving the internal system to process the order request based on the global order number and returning the processing information to the external platform. Firstly, a unified operation is performed on massive heterogeneous external requests at the system entry point, directly mapping them to standardized target interfaces based on their essential request actions. Simultaneously, since each standardized interface is bound to a dedicated idempotent function, different idempotent strategies are adopted for different transaction actions. This step, through standardized interfaces, eliminates the need for internal core logic to directly perceive external platforms, reducing overall system complexity and providing a unified context for subsequent processing. Binding idempotent functions to interfaces ensures flexibility while allowing for more refined and centralized configuration and management of idempotent strategies, decoupling them from external platforms. Furthermore, after determining the target interface and corresponding idempotent function, key fields related to idempotency calculations are extracted from the original request as target request elements for subsequent calculations. This improves the accuracy and efficiency of the processing. By extracting only the key information required by the idempotent function, the overhead of processing large amounts of irrelevant data is avoided, and the determinism of the idempotency calculation source data is ensured, guaranteeing that the subsequently generated number accurately reflects the identity of this request. Based on this, the extracted target request elements are used as input for calculation, outputting a globally unique order number. This step dynamically generates a unique identifier for the order request, achieving standardized encapsulation of idempotency control logic. The internal system only needs to verify based on this number without needing to concern itself with the specific details of its generation, providing a reliable and efficient unique index for idempotency verification. Finally, after generating the global order number, the internal core system no longer directly processes the complex formats of external requests. Instead, it relies on the standardized global order number and its associated standardized context information to process requests. This step ultimately achieves efficient decoupling between internal and external systems. Internal systems can focus on their core logic, thereby greatly improving development efficiency and system stability. For external platforms, this results in a clearer and more consistent interactive experience. The entire process ensures efficient, stable, and scalable processing, achieving a highly cohesive and loosely coupled system framework, and enhancing the flexibility, maintainability, and scalability of cross-platform integration.

[0086] This specification provides a computer program product containing instructions that, when run on a computer or processor, cause the computer or processor to perform the steps of any of the methods described above.

[0087] This specification also provides a computer storage medium that can store multiple instructions adapted for loading by a processor and executing the steps of any of the methods described in the above embodiments.

[0088] Please see Figure 6 , Figure 6 This is a schematic diagram of the structure of a terminal provided in an embodiment of this specification. Figure 6 As shown, terminal 101 may include: at least one terminal processor 601, at least one network interface 604, user interface 603, memory 605, and at least one communication bus 602.

[0089] The communication bus 602 is used to enable communication between these components.

[0090] The user interface 603 may include a display screen and a camera. Optionally, the user interface 603 may also include a standard wired interface and a wireless interface.

[0091] The network interface 604 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0092] The terminal processor 601 may include one or more processing cores. The terminal processor 601 connects to various parts within the terminal 101 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 605, and by calling data stored in the memory 605. Optionally, the terminal processor 601 may be implemented using at least one hardware form selected from Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), and Programmable Logic Array (PLA). The terminal processor 601 may integrate one or a combination of several of the following: a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), and a 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 on the screen; and the modem handles wireless communication. It is understood that the modem may also be implemented as a separate chip without being integrated into the terminal processor 601.

[0093] The memory 605 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 605 may include a non-transitory computer-readable storage medium. The memory 605 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 605 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 605 may also be at least one storage device located remotely from the aforementioned terminal processor 601. Figure 6 As shown, the memory 605, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and an order request processing program.

[0094] exist Figure 6In the terminal 101 shown, the user interface 603 is mainly used to provide an input interface for the user and to obtain the user's input data; while the terminal processor 601 can be used to call the order request processing program stored in the memory 605 and specifically perform the following operations: Receive order requests from external platforms, determine the target interface corresponding to the order request, where the target interface is a standardized interface abstracted based on transaction processing capabilities, and each standardized interface corresponds to a dedicated idempotent function; Extract at least one target request element from the order request, which is the key information field used to identify an order request, that the target idempotent function corresponding to the target interface depends on. Call the idempotent function to generate a global order number corresponding to the order request based on each target request element; The internal system drives the processing of order requests based on the global order number and returns the processing information to the external platform.

[0095] In some embodiments, when the terminal processor 601 generates a global order number corresponding to an order request based on each target request element, it specifically performs the following steps: dynamically generating a global order number corresponding to an order request based on each target request element according to a preset element combination rule on which the idempotent function depends; the preset element combination rule includes at least the number of elements selected and their arrangement order.

[0096] In some embodiments, after the terminal processor 601 generates a global order number corresponding to the order request based on each target request element, it further performs the following steps: creating a generalized order record for the order request based on the global order number, and storing the generalized order record in a database. The generalized order record contains at least the global order number and the original request data of the order request.

[0097] In some embodiments, before creating a generalized order record based on the global order number, the terminal processor 601 further performs the following steps: performing idempotency verification using the global order number as an index to determine whether the order request has been processed; if it has been processed, directly returning the stored processing information.

[0098] In some embodiments, idempotency verification is implemented through a pre-established key mapping store, which is used to store the correspondence between the external combined serial number and the global order number of the same order request. The external combined serial number is generated by the external platform according to its own idempotency strategy.

[0099] In some embodiments, the generalized order record also includes an order status, which is one of four predefined standardized states, including initialization status, processing status, success status, and failure status.

[0100] In some embodiments, the terminal processor 601 further performs the following steps: obtaining the actual transaction status returned by the internal system; converting the actual transaction status into the target status corresponding to the standardized status according to the preset status mapping rules, and updating the order status in the generalized order record.

[0101] In some embodiments, the terminal processor 601 further performs the following steps: persistently storing the original request data of the order request in the database after serialization; when an order request of a preset type is detected, performing a deserialization operation to restore and calculate the original request data, wherein the preset type includes at least one of retry, reconciliation, and audit.

[0102] In some embodiments, the terminal processor 601 further performs the following steps: scanning the generalized order records in the processing state through a distributed scheduling framework, triggering a retry process for orders that have not been processed for more than a preset time, and resending the processing request to the internal system.

[0103] In some embodiments, when the terminal processor 601 executes the following steps when driving the internal system to process an order request based on a global order number: determining the communication mode required by the external platform, which is synchronous or asynchronous; if the communication mode is synchronous, returning an accepted response to the external platform and encapsulating the order request into a transaction message and sending it to the message queue; if the communication mode is asynchronous, encapsulating the order request into a transaction message and sending it to the message queue, and returning the processing result to the external platform through a callback mechanism after the internal system has finished processing.

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

[0105] The modules described as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0106] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this specification are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The aforementioned available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)).

[0107] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments in this specification are not limited to the described order of actions, because according to the embodiments in this specification, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments in this specification.

[0108] Furthermore, it should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, stored data, displayed data, etc.), and signals involved in the embodiments of this specification are all authorized by the user or fully authorized by all parties, and the collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions. For example, order information involved in this specification was obtained under full authorization.

[0109] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0110] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

[0111] The above is a description of an order request processing method, apparatus, storage medium, and terminal provided in the embodiments of this specification. For those skilled in the art, based on the ideas of the embodiments of this specification, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation on the embodiments of this specification.

Claims

1. An order request processing method, characterized in that, The method includes: Receive an order request from an external platform, determine the target interface corresponding to the order request, wherein the target interface is a standardized interface abstracted based on transaction processing capabilities, and each standardized interface corresponds to a dedicated idempotent function; Extract at least one target request element from the order request that the target idempotent function corresponding to the target interface depends on, wherein the request element is a key information field used to identify an order request; The idempotent function is invoked to generate a global order number corresponding to the order request based on each target request element. The internal system drives the processing of the order request based on the global order number and returns the processing information to the external platform.

2. The method according to claim 1, characterized in that, The step of generating a global order number corresponding to the order request based on each target request element includes: According to the preset element combination rules on which the idempotent function depends, the global order number corresponding to the order request is dynamically generated based on each target request element. The preset element combination rules include at least the number of elements selected and their arrangement order.

3. The method according to claim 1, characterized in that, After generating the global order number corresponding to the order request based on each target request element, the method further includes: A generalized order record for the order request is created based on the global order number, and the generalized order record is stored in the database. The generalized order record contains at least the global order number and the original request data of the order request.

4. The method according to claim 3, characterized in that, Before creating the generalized order record based on the global order number, the process also includes: An idempotency check is performed using the global order number as an index to determine whether the order request has been processed. If the information has already been processed, the stored processing information will be returned directly.

5. The method according to claim 4, characterized in that, The idempotency check is implemented through a pre-established key mapping storage, which is used to store the correspondence between the external combined serial number and the global order number of the same order request. The external combined serial number is generated by the external platform according to its own idempotency strategy.

6. The method according to claim 3, characterized in that, The generalized order record also includes an order status, which is one of four predefined standardized states, including initialization status, processing status, success status, and failure status.

7. The method according to claim 6, characterized in that, The method further includes: Obtain the actual transaction status returned by the internal system; According to the preset state mapping rules, the actual transaction state is converted into the target state corresponding to the standardized state, and the order state in the generalized order record is updated.

8. The method according to claim 6, characterized in that, The method further includes: The original request data of the order request is serialized and then persistently stored in the database; When a preset type of order request is detected, the original request data is obtained by deserialization. The preset type includes at least one of retry, reconciliation, and audit.

9. The method according to claim 6 or 8, characterized in that, The method further includes: The distributed scheduling framework scans the generalized order records that are in the processing state, and triggers a retry process for orders that have not been processed for more than a preset time, resending the processing request to the internal system.

10. The method according to claim 1, characterized in that, The internal system of the driver processes the order request based on the global order number, including: Determine the communication mode required by the external platform, wherein the communication mode is synchronous or asynchronous; If the communication mode is synchronous mode, then a response indicating acceptance is returned to the external platform, and the order request is encapsulated as a transaction message and sent to the message queue; If the communication mode is asynchronous, the order request is encapsulated as a transaction message and sent to the message queue. After the internal system completes the processing, the processing result is returned to the external platform through a callback mechanism.

11. An order request processing apparatus, characterized in that, The device includes: An external request receiving module is used to receive order requests from external platforms and determine the target interface corresponding to the order request. The target interface is a standardized interface abstracted based on transaction processing capabilities, and each standardized interface corresponds to a dedicated idempotent function. The capability interface call module is used to extract at least one target request element from the order request on which the target idempotent function corresponding to the target interface depends, wherein the request element is a key information field used to identify an order request; The global number generation module is used to call the idempotent function to generate a global order number corresponding to the order request based on each target request element; An internal standard processing module is used to drive the internal system to process the order request based on the global order number and return the processing information to the external platform.

12. A computer program product containing instructions, characterized in that, When the computer program product is run on a computer or processor, it causes the computer or processor to perform the steps of the method as described in any one of claims 1 to 10.

13. A computer storage medium, characterized in that, The computer storage medium stores a plurality of instructions adapted for loading by a processor and executing the steps of the method as claimed in any one of claims 1 to 10.

14. A terminal, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the method as described in any one of claims 1 to 10.

Images