Data processing method and device, computer device, and storage medium

Abstract

The application discloses a data processing method and device, computer equipment and a storage medium. The application belongs to the technical field of data processing and relates to a data processing method, which comprises the following steps: extracting a specified identification field from request parameters of an order request; splicing the specified identification field to obtain an identification string; performing a matching search operation on the identification string in a data warehouse based on an executor to obtain a target extension implementation object; obtaining an initial business context object of the order request and delivering the initial business context object to the target extension implementation object; calling a general business execution method based on the target extension implementation object to perform common logic on the initial business context object to obtain a business context; calling a target business execution method corresponding to the scene identification field based on the target extension implementation object to perform specific business logic on the business context to obtain target order data; and writing the target order data into a target database. The application can be applied to a business scenario of order data processing in the medical and health field, and can effectively improve the accuracy and efficiency of data processing.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and can be applied to the medical and health field, particularly to data processing methods, devices, computer equipment and storage media. Background Technology

[0002] In traditional data processing models, the processing of requests for multiple types of business data typically employs a factory pattern, which associates order types with corresponding processing services through hard-coded mapping tables. Specifically, developers must manually maintain the mapping relationship between type identifiers and processing service classes. As the number of business types increases, the maintenance cost of the mapping table rises sharply, and human error can easily lead to configuration omissions or mapping errors, thus reducing the efficiency and accuracy of data processing. For example, in a data processing system in the healthcare service field, such as an order system that needs to support more than 30 business types including smart guardians, daily cleaning, age-friendly renovations, nursing services, product delivery, service packages, and travel, if the traditional factory pattern is still used, every time a new business type is added (such as adding a "remote consultation" service), the mapping configuration must be modified and redeployed, resulting in low efficiency in order data processing. Furthermore, in high-concurrency scenarios, any error in the mapping relationship may cause order data to be routed to the wrong processing service, resulting in service delivery failure and thus low accuracy in order data processing.

[0003] Therefore, there is an urgent need to provide an intelligent data processing method to eliminate the drawbacks of manual mapping and improve the efficiency and accuracy of data processing in multiple business scenarios. Summary of the Invention

[0004] The purpose of this application is to provide a data processing method, apparatus, computer equipment, and storage medium to solve the technical problem of low efficiency and accuracy in existing data processing methods.

[0005] Firstly, a data processing method is provided, including: Receive an order request to be processed, and extract a specified identifier field corresponding to a preset field type from the request parameters of the order request; wherein, the number of the specified identifier fields includes multiple fields; The specified identifier field is concatenated to obtain the corresponding identifier string; Based on a preset executor, a step-by-step matching algorithm is used to perform a matching search operation on the identifier string in a preset data warehouse to obtain the corresponding target extended implementation object; Obtain the initial business context object corresponding to the order request, and pass the initial business context object to the target extended implementation object; Based on the target extension implementation object, a preset general business execution method is called to perform common logic execution processing on the initial business context object to obtain the corresponding business context object; Obtain the scene identifier field from the specified identifier field; Based on the target extension implementation object, the target business execution method corresponding to the scene identifier field is called to perform specific business logic execution processing on the business context object to obtain the corresponding target order data; The target order data is written to the target database based on the preset interface.

[0006] Secondly, a data processing apparatus is provided, comprising: The first processing module is used to receive an order request to be processed and extract a specified identifier field corresponding to a preset field type from the request parameters of the order request; wherein, the number of the specified identifier fields includes multiple fields. The concatenation module is used to concatenate the specified identifier field to obtain the corresponding identifier string; The search module is used to perform a matching search operation on the identifier string in a preset data warehouse based on a preset executor and a step-by-step matching algorithm to obtain the corresponding target extended implementation object; The second processing module is used to obtain the initial business context object corresponding to the order request and pass the initial business context object to the target extended implementation object; The first execution module is used to call a preset general business execution method based on the target extended implementation object, perform common logic execution processing on the initial business context object, and obtain the corresponding business context object; The acquisition module is used to acquire the scene identifier field from the specified identifier field; The second execution module is used to call the target business execution method corresponding to the scene identifier field based on the target extended implementation object, perform specific business logic execution processing on the business context object, and obtain the corresponding target order data. The writing module is used to write the target order data to the target database based on a preset interface.

[0007] Thirdly, a computer device is provided, including 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 above-described data processing method.

[0008] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described data processing method.

[0009] In the above-described data processing method, apparatus, computer equipment, and storage medium, the following steps are taken: First, an order request to be processed is received, and a specified identifier field corresponding to a preset field type is extracted from the request parameters of the order request; wherein, the number of specified identifier fields includes multiple fields; then, the specified identifier fields are concatenated to obtain a corresponding identifier string; subsequently, based on a preset executor, a hierarchical matching algorithm is used to perform a matching search operation on the identifier string in a preset data warehouse to obtain a corresponding target extended implementation object; next, an initial business context object corresponding to the order request is obtained and passed to the target extended implementation object; and based on the target extended implementation object, a preset general business execution method is called to perform common logic execution processing on the initial business context object to obtain a corresponding business context object; further, a scene identifier field is obtained from the specified identifier fields; and based on the target extended implementation object, a target business execution method corresponding to the scene identifier field is called to perform specific business logic execution processing on the business context object to obtain the corresponding target order data; finally, the target order data is written to the target database based on a preset interface. Based on the above automated processing flow, this application adopts a data processing method different from the existing factory pattern. When an order request is received, a hierarchical matching algorithm is used to locate the corresponding target extension implementation object from the data warehouse. Then, the located extension implementation is called to perform common logic execution and specific business logic execution on the initial business context object, and the generated target order data is written to the target database. This achieves efficient and accurate automated processing of order request data. The entire order request data processing flow, from order request receipt to data processing completion, requires no conditional branch judgments or manual mapping. It is entirely driven by annotations and a hierarchical matching algorithm, implementing the open / closed principle and zero-intrusion extension, thereby effectively improving the accuracy and efficiency of data processing. Attached Figure Description

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

[0011] Figure 1 This is an exemplary system architecture diagram to which this application can be applied; Figure 2 This is a flowchart of an embodiment of the data processing method according to this application; Figure 3 This is a schematic diagram of the structure of an embodiment of the data processing apparatus according to this application; Figure 4 This is a schematic diagram of the structure of one embodiment of the computer device according to this application. Detailed Implementation

[0012] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains; the terminology used herein in the specification of the application is for the purpose of describing particular embodiments only and is not intended to be limiting of the application; the terms "comprising" and "having," and any variations thereof, in the specification, claims, and foregoing drawings of this application, are intended to cover non-exclusive inclusion. The terms "first," "second," etc., in the specification, claims, or foregoing drawings of this application are used to distinguish different objects, not to describe a particular order.

[0013] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0014] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings.

[0015] like Figure 1 As shown, system architecture 100 may include terminal device 101, network 102, and server 103. Terminal device 101 may be a laptop 1011, tablet 1012, or mobile phone 1013. Network 102 is used as a medium to provide a communication link between terminal device 101 and server 103. Network 102 may include various connection types, such as wired, wireless communication links, or fiber optic cables, etc.

[0016] Users can use terminal device 101 to interact with server 103 via network 102 to receive or send messages, etc. Various communication client applications can be installed on terminal device 101, such as web browser applications, shopping applications, search applications, instant messaging tools, email clients, social media platform software, etc.

[0017] Terminal device 101 can be various electronic devices with a display screen and support web browsing. In addition to laptops 1011, tablets 1012, or mobile phones 1013, terminal device 101 can also be an e-book reader, an MP3 player (Moving Picture Experts Group Audio Layer III), an MP4 player (Moving Picture Experts Group Audio Layer IV), a laptop computer, and a desktop computer, etc.

[0018] Server 103 can be a server that provides various services, such as a backend server that provides support for the pages displayed on terminal device 101.

[0019] It should be noted that the data processing method provided in the embodiments of this application is generally executed by a server / terminal device, and correspondingly, the data processing device is generally located in the server / terminal device.

[0020] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0021] Continue to refer to Figure 2 A flowchart illustrating an embodiment of the data processing method according to this application is shown. The order of steps in the flowchart can be changed, and some steps can be omitted, depending on different needs. The data processing method provided in this application embodiment can be applied to any scenario requiring order processing, and therefore can be applied to products in these scenarios, such as order processing products in the healthcare field. The data processing method includes the following steps: Step S201: Receive an order request to be processed, and extract a specified identifier field corresponding to a preset field type from the request parameters of the order request; wherein, the number of specified identifier fields includes multiple fields.

[0022] In this embodiment, the data processing method runs on an electronic device (e.g., Figure 1The server / terminal device shown can acquire the image to be checked via wired or wireless connection. It should be noted that the aforementioned wireless connection methods may include, but are not limited to, 3G / 4G / 5G connections, WiFi connections, Bluetooth connections, WiMAX connections, Zigbee connections, UWB (ultra-wideband) connections, and other currently known or future-developed wireless connection methods. The executing entity of this application is specifically a data processing system, also known as an order management system, which can be simply referred to as the system. The aforementioned order request specifically refers to an order request submitted by the requesting party. This application can be applied to order processing scenarios in the medical and health field. For example, the order request may include order requests corresponding to various business types in the medical and health service order system, such as smart guardian orders, daily cleaning orders, aging-friendly renovations, nursing services, goods delivery, service packages, and travel orders, etc.

[0023] The specific implementation process of extracting the specified identifier field corresponding to the preset field type from the request parameters of the order request will be further described in detail in subsequent specific embodiments of this application, and will not be elaborated on here.

[0024] In addition, the system initialization phase includes: Phase 1: Extension Annotation Definition and Metadata Preparation. The system first defines an annotation named `@Extend`, which serves as the marker metadata for all business scenario extension implementation classes. This annotation contains three core attributes: the business identifier `bizId`, with a default value of "JARVIS", representing the entire home order business domain; the use case identifier `useCase`, used to distinguish different business operations such as order submission, order refund, and order query; and the scenario identifier `scenario`, used to distinguish different business types under the same use case, such as smart guardian, daily cleaning, and age-friendly renovation. When developers create a new business scenario processing class, they only need to add this annotation to the class and fill in the corresponding three-part identifier, for example, setting `bizId` to "JARVIS", `useCase` to "ORDER_SUBMIT", and `scenario` to "SMART_GUARD". The system will then bind this metadata information to the class during compilation.

[0025] At the same time, the system defines an extension point interface ExtendPointI, which requires all extension implementation classes to implement a method called getUniqueIdentity. The return value of this method is formed by concatenating the three identifiers bizId, useCase, and scenario with dots, forming a globally unique string identifier, such as "JARVIS.ORDER_SUBMIT.SMART_GUARD".

[0026] The system also defines a BizScenario class, which encapsulates the parsing, concatenation, and hierarchical splitting logic of the three-part identifier. When a complete unique identifier is passed in, this class can decompose it into different levels step by step. For example, "JARVIS.ORDER_SUBMIT.SMART_GUARD.CARE" can be decomposed into four levels: complete identifier layer, scenario layer, use case layer, and business domain layer.

[0027] Phase Two: Spring Container Startup and Automatic Scanning and Registration. When the system starts, after the Spring container completes the initialization of Beans, a component named ExtendBootstrap is triggered and executed. This component implements the ApplicationContextAware interface, and therefore is aware of the entire Spring container context.

[0028] The ExtendBootstrap component performs the following data processing operations in its initialization method: First, it uses the capabilities of the Spring container to scan all beans annotated with `@Extend`, obtaining a Map collection where the keys are the bean names and the values ​​are bean instances. Next, it iterates through each bean instance in this Map, casts it to the ExtendPointI interface type, and then calls the ExtendRegister method to complete the registration.

[0029] When ExtendRegister receives an extension implementation object, it performs the following data processing: First, it calls the object's getUniqueIdentity method to obtain the unique identifier string for the extension point, such as "JARVIS.ORDER_SUBMIT.SMART_GUARD". Then, the system constructs an ExtensionCoordinate object as the key based on this unique identifier and the fully qualified name of the extension point interface. Finally, it stores the extension implementation object in the ExtensionRepository, whose underlying data structure is a HashMap, using ExtensionCoordinate as the key and the extension implementation object as the value.

[0030] After this phase, the system has registered all extended implementation classes for all business scenarios into the in-memory data warehouse (i.e., the ExtensionRepository) according to their unique identifiers, forming a complete extension point mapping table. Assuming there are more than thirty business scenarios in the system, there will be more than thirty entries in the warehouse, and each entry can be located in constant time using its unique identifier.

[0031] Step S202: Concatenate the specified identifier field to obtain the corresponding identifier string.

[0032] In this embodiment, the aforementioned identifier string, due to its uniqueness, can also serve as a unique identifier. Furthermore, the specific implementation process of concatenating the specified identifier field to obtain the corresponding identifier string will be described in further detail in subsequent embodiments of this application, and will not be elaborated upon here.

[0033] Step S203: Based on a preset executor, a step-by-step matching algorithm is used to perform a matching search operation on the identifier string in a preset data warehouse to obtain the corresponding target extended implementation object.

[0034] In this embodiment, the executor is specifically an extension point executor. The specific implementation process of using a step-by-step matching algorithm to perform a matching search operation on the identifier string in a preset data warehouse based on the preset executor to obtain the corresponding target extension implementation object will be described in further detail in subsequent embodiments of this application, and will not be elaborated upon here.

[0035] Step S204: Obtain the initial business context object corresponding to the order request, and pass the initial business context object to the target extended implementation object.

[0036] In this embodiment, the specific implementation process of obtaining the initial business context object corresponding to the order request will be further described in detail in subsequent specific embodiments of this application, and will not be elaborated on here.

[0037] In addition, after the extension point executor successfully locates the target extension implementation object through the step-by-step matching algorithm, the system will pass the currently obtained initial business context object OrderSubmitContext corresponding to the order request to the target extension implementation object.

[0038] Step S205: Based on the target extended implementation object, a preset general business execution method is called to perform common logic execution processing on the initial business context object to obtain the corresponding business context object.

[0039] In this embodiment, upon receiving the context, the target extended implementation object does not immediately begin executing its own specific business logic. Instead, it first enters a common logic execution phase driven by inheritance. The triggering mechanism for this phase is as follows: since all extended implementation classes inherit from the abstract base class `AbstractOrderSubmitBaseService` using the `extends` keyword during class definition, and this base class already fully implements a set of common methods that need to be executed in all business scenarios, when the target extended implementation object's business execution method is called, if this method explicitly calls the base class method using the `super` keyword, or if the method itself already has a default implementation in the base class, then the common logic in the base class will be automatically executed.

[0040] The first operation in the common logic is customer information retrieval. The method in the base class extracts the customer ID field from the context, and then, through the customer service query interface encapsulated in the initial business context object, initiates a query request to the customer service department to obtain the customer's complete basic information, including customer name, contact number, home address, and historical order records. This information is fundamental data needed in all business scenarios, and therefore it is extracted and processed uniformly in the base class.

[0041] The second operation in the common logic is supplier information retrieval. The methods in the base class extract supplier-related fields from the initial business context object, and obtain basic information about the suppliers involved in the order, including supplier name, service coverage area, and service capabilities, through the supplier service query interface encapsulated in the initial business context object.

[0042] The third operation in the common logic is basic parameter validation. Methods in the base class execute a set of universal validation rules applicable to all scenarios on the key parameters of the initial business context object. These rules include checking if the customer ID is empty, if the service address is in a valid address format, if the order amount is positive, and if any required fields are missing. If any of these universal validations fail, the base class will throw a validation exception, terminating the business process and preventing further execution of specific logic.

[0043] The fourth operation in the common logic is the preparation of public data. The methods in the base class prepare a set of public data structures needed for all scenarios based on the information in the initial business context object. These include basic metadata for orders, such as order creation time, order origin channel, and user information. This public data is appended to the initial business context object to obtain a business context object for subsequent use by specific logic.

[0044] Before entering the business execution method of the extended implementation object, the business context object has already been populated with some data by the base class during the common logic execution phase, such as customer basic information, supplier information, order basic metadata, and common validation results.

[0045] The key significance of this layer of processing is that developers of extended implementation objects don't need to worry about how to query customer information, supplier information, or how to calibrate basic parameters when writing their own business logic. These tasks are automatically completed by the base class when the extended implementation object's business methods are called. Developers only need to focus on writing the scenario-specific logic in their own classes.

[0046] Step S206: Obtain the scene identifier field from the specified identifier field.

[0047] In this embodiment, the corresponding scene identifier field can be obtained by extracting information corresponding to the scene identifier from the specified identifier field.

[0048] Step S207: Based on the target extended implementation object, call the target business execution method corresponding to the scene identifier field to perform specific business logic execution processing on the business context object to obtain the corresponding target order data.

[0049] In this embodiment, after all the common logic in the base class has been executed and verified, the program execution flow returns to the business execution method overridden by the target extended implementation object itself, and begins to execute the business logic specific to that scenario (i.e., the specific scenario corresponding to the scenario identifier field). This layer of processing is the core value of the entire routing mechanism, because all the differences between different business scenarios are reflected in this layer.

[0050] The aforementioned self-overridden business execution methods are manually written by developers in advance based on specific business scenarios. Specifically, when creating a new business scenario extension implementation class, developers need to do the following: First, create a new Java class, for example, named HardwareOrderSubmitService; Second, add the @Extend annotation above the class name, and fill in the three-part identifier corresponding to the scenario in the annotation, for example, useCase is filled with "ORDER_SUBMIT" and scenario is filled with "SMART_GUARD"; Third, make this class inherit the abstract base class AbstractOrderSubmitBaseService, and establish the inheritance relationship through the extends keyword; Fourth, override the business execution methods defined in the abstract base class in the class, for example, the method named execute, and then manually write the business logic specific to this scenario inside the method body, which are the operations mentioned above such as device SKU verification, service coverage verification, specific data model assembly, VIP discount calculation, etc.

[0051] The reason this overridden business logic execution method is "self-overriding" is that although the abstract base class `AbstractOrderSubmitBaseService` defines the method signature, the method body in the base class is either empty or contains only some default logic common to all scenarios. When developers reimplement this method in subclasses using the `@Override` annotation, they are completely replacing the method body with logic specific to that scenario. When the system locates this extended implementation object through a hierarchical matching algorithm and calls its business logic execution method, it actually executes the few lines of code manually written by the developer in this method body, not the code in the base class.

[0052] Taking the extended implementation object of the smart guardian scenario as an example, when the execution flow enters its unique logic, the first unique operation executed is device SKU verification. This object extracts the SKU code of the smart guardian device from the context, and then calls the device service to query whether the SKU exists in the device library, whether the device model is available for sale, and whether the device supports the network standard of the user's area, etc. This series of verifications is unique to the smart guardian scenario and is completely unnecessary in routine cleaning scenarios.

[0053] The second unique operation is service coverage verification. This object extracts the service address from the context, calls the coverage query interface of the smart guardian service, and verifies whether the address is within the serviceable area of ​​the smart guardian service. If the address is not within the coverage area, a service unreachable exception is thrown, and the process terminates.

[0054] The third unique operation is the assembly of a unique data model. Based on the business rules of the smart guardian scenario, this object extracts relevant information from the context and assembles it into a smart guardian-specific order data model. This data model contains fields unique to the smart guardian scenario, such as device model, device serial number, installation appointment time, bound mobile phone number, and device activation method. These fields are completely absent from the data model of the routine cleaning scenario.

[0055] The fourth unique operation is the calculation of VIP package discounts. If the context indicates that the order is the VIP version of Smart Guardian, the object also needs to execute the VIP package-specific discount calculation logic, extracting discount information from the context according to the VIP package pricing rules and calculating the final discount amount.

[0056] Taking the extended implementation object of the daily cleaning scenario as an example, the specific operations executed after the execution flow enters its unique logic are completely different. The first unique operation is cleaning duration verification, which extracts the cleaning duration selected by the user from the context and verifies whether the duration is within the range supported by the cleaning service. The second unique operation is cleaning staff scheduling query, which extracts the service address and service time from the context and calls the cleaning staff scheduling service to query whether there are available cleaning staff within that time period. The third unique operation is service area coverage verification, which verifies whether the address is within the coverage area of ​​the daily cleaning service. The fourth unique operation is the assembly of a unique data model, which assembles an order data model containing cleaning-specific fields such as cleaning duration, cleaning staff ID, cleaning supplies list, and cleaning service type.

[0057] In particular, after entering the business execution method overridden by the extended implementation object itself, the special logic will continue to add scenario-specific data to the business context object that has already been partially filled. For example, the smart guardian scenario adds fields such as device model, device serial number, and installation appointment time, while the daily cleaning scenario adds fields such as cleaning duration, cleaning staff ID, and cleaning supplies list.

[0058] Furthermore, the key to this layer of processing lies in the fact that each extended implementation object only needs to write the few operations specific to its own scenario. All common logic is automatically handled by the base class, and sub-scenarios can automatically inherit the parent scenario's unique logic through a hierarchical matching mechanism. When adding a new business scenario, developers only need to create a new class, inherit from the base class, override the business execution method, and write the few operations specific to that scenario in the method; all other logic is irrelevant.

[0059] Step S208: Write the target order data to the target database based on the preset interface.

[0060] In this embodiment, after the extended implementation object has completed all processing of the common and specific logic, the context is now filled with complete, validated order data that conforms to the business rules of this scenario. The final operation of the target extended implementation object is to call the persistence layer interface to write this data to the database.

[0061] The specific process of persistence operations includes: the target extended implementation object calls the corresponding persistence layer write method based on its prepared order data model. Since the data model structure differs for different scenarios, the target table and fields to be written also differ. For the smart guardian scenario, the extended implementation object will write data containing fields such as device model, device serial number, installation appointment time, and bound mobile phone number to the smart guardian order table; for the daily cleaning scenario, the extended implementation object will write data containing fields such as cleaning duration, cleaning staff ID, and cleaning supplies list to the daily cleaning order table. The persistence layer interface is responsible for mapping each field in the data model to the corresponding column in the database table and performing insert or update operations.

[0062] After the write operation is complete, the persistence layer returns the write result. The target extended implementation object updates the order status field based on the result, for example, setting the order status to "pending confirmation" or "submitted." At this point, the entire order request processing flow—from receiving, route matching, common logic execution, specific logic execution to data persistence—is complete, and the system can return the processing result to the requester.

[0063] Furthermore, when the persistence layer is finally invoked to write data, it writes all the data in this business context object that has already been populated with both common and specific logic. This constitutes a complete order data model (i.e., the target order data), containing both common fields shared across all scenarios and private fields specific to the current scenario. Different scenarios write to different database tables simply because the complete data models assembled for different scenarios contain different sets of fields. The persistence layer maps the complete data model prepared by the extended implementation object to the corresponding database table to perform the write operation.

[0064] This application first receives an order request to be processed and extracts a specified identifier field corresponding to a preset field type from the request parameters of the order request; wherein the number of specified identifier fields includes multiple fields; then, the specified identifier fields are concatenated to obtain a corresponding identifier string; then, based on a preset executor, a hierarchical matching algorithm is used to perform a matching search operation on the identifier string in a preset data warehouse to obtain a corresponding target extended implementation object; subsequently, an initial business context object corresponding to the order request is obtained and passed to the target extended implementation object; and based on the target extended implementation object, a preset general business execution method is called to perform common logic execution processing on the initial business context object to obtain a corresponding business context object; further, a scene identifier field is obtained from the specified identifier fields; and based on the target extended implementation object, a target business execution method corresponding to the scene identifier field is called to perform specific business logic execution processing on the business context object to obtain the corresponding target order data; finally, the target order data is written to the target database based on a preset interface. Based on the above automated processing flow, this application adopts a data processing method different from the existing factory pattern. When an order request is received, a hierarchical matching algorithm is used to locate the corresponding target extension implementation object from the data warehouse. Then, the located extension implementation is called to perform common logic execution and specific business logic execution on the initial business context object, and the generated target order data is written to the target database. This achieves efficient and accurate automated processing of order request data. The entire order request data processing flow, from order request receipt to data processing completion, requires no conditional branch judgments or manual mapping. It is entirely driven by annotations and a hierarchical matching algorithm, implementing the open / closed principle and zero-intrusion extension, thereby effectively improving the accuracy and efficiency of data processing.

[0065] In some alternative implementations, step S201 includes the following steps: Step S2011: Extract the business identifier field corresponding to the business field type from the request parameters.

[0066] In this embodiment, the aforementioned request parameter refers to the request context of the order request, which carries complete business scenario information. When the order request arrives at the system, the system first extracts the business identifier field bizId corresponding to the business field type from the request parameter. This business identifier field is used to distinguish different business domains; for example, in the home order system, the default value is "JARVIS".

[0067] Step S2012: Extract the use case identifier field corresponding to the use case field identifier from the request parameters.

[0068] In this embodiment, the system also extracts the use case identifier field (useCase) from the request parameters, which corresponds to the use case field identifier. This use case identifier field is used to distinguish different business operation types. For example, "ORDER_SUBMIT" indicates order submission and "ORDER_REFUND" indicates order refund.

[0069] Step S2013: Extract the scene identifier field corresponding to the scene field identifier from the request parameters.

[0070] In this embodiment, the system extracts the scenario identifier field scenario from the request parameters, which is used to distinguish different business scenarios under the same use case. For example, "SMART_GUARD" represents intelligent protection and "DAILY_CLEAN" represents daily cleaning.

[0071] Step S2014: Integrate the business identifier field, the use case identifier field, and the scenario identifier field to obtain the corresponding integrated field.

[0072] In this embodiment, the extracted business identifier field, use case identifier field, and scenario identifier field are integrated, and the resulting integrated field is used as the corresponding designated identifier field.

[0073] Step S2015: Use the integrated field as the designated identifier field.

[0074] In this embodiment, the designated identifier field, which consists of three fields, is the basis for subsequent route matching.

[0075] This application extracts a business identifier field corresponding to the business field type from the request parameters; a use case identifier field corresponding to the use case field identifier from the request parameters; and a scenario identifier field corresponding to the scenario field identifier from the request parameters. Then, it integrates the business identifier field, use case identifier field, and scenario identifier field to obtain the corresponding integrated field. This integrated field is subsequently used as the designated identifier field. Based on the above processing flow, this application improves the intelligence and accuracy of designated identifier field extraction by accurately extracting three-segment identifier fields from the order request and then integrating these three segments to obtain the corresponding designated identifier field.

[0076] In some optional implementations of this embodiment, step S202 includes the following steps: Step S2021: Obtain the preset target symbol.

[0077] In this embodiment, the target symbol mentioned above can specifically be a dot.

[0078] Step S2022: Call the preset identifier splicing rules.

[0079] In this embodiment, the above-mentioned identifier concatenation rule includes: Unique Identifier = bizId + "." + useCase + "." + scenario.

[0080] Step S2023: Based on the identifier splicing rules, the target symbol is used to splice the specified identifier field to obtain the corresponding spliced ​​data.

[0081] In this embodiment, based on the above-mentioned identifier concatenation rules, the system concatenates the extracted bizId, useCase, and scenario fields using periods to construct a complete unique identifier string. For example, when bizId is "JARVIS", useCase is "ORDER_SUBMIT", and scenario is "SMART_GUARD", the concatenated unique identifier is the concatenated data corresponding to "JARVIS.ORDER_SUBMIT.SMART_GUARD".

[0082] Step S2024: Use the concatenated data as the identifier string.

[0083] In this embodiment, if the order request also carries a more granular sub-scenario identifier, such as further distinguishing between the regular and VIP versions in the Smart Guardian scenario, then this sub-scenario identifier will be appended as a fourth segment to the end of the unique identifier. At this point, the complete unique identifier becomes: Unique Identifier = bizId + "." + useCase + "." + scenario + "." + subScenario. For example, the complete identifier corresponding to the VIP version of Smart Guardian is "JARVIS.ORDER_SUBMIT.SMART_GUARD.VIP". The system uses this complete identifier as the target value for subsequent step-by-step matching and searching, and passes it to the extension point executor.

[0084] This application obtains a preset target symbol; then calls a preset identifier concatenation rule; subsequently, based on the identifier concatenation rule, it uses the target symbol to concatenate a specified identifier field to obtain the corresponding concatenated data; this concatenated data is then used as the identifier string. Based on the above processing flow, this application accurately extracts a three-segment identifier from the order request and concatenates it into a unique identifier string. This unique identifier is the core basis for all subsequent matching and search operations. By encoding information from four levels—business domain, use case, scenario, and sub-scenario—into a single string, the system can describe business scenarios of arbitrary granularity in a unified way, providing a clear search target for subsequent hierarchical matching algorithms.

[0085] In some alternative implementations, step S203 includes the following steps: Step S2031: Based on the executor, perform an exact match lookup operation on the data warehouse using the identifier string.

[0086] In this embodiment, the executor is specifically an extension point executor. The specific implementation process of performing an exact match lookup operation on the data warehouse using the identifier string based on the executor will be further described in detail in subsequent specific embodiments of this application, and will not be elaborated on here.

[0087] Step S2032: If the match is successful, the first successfully matched extended implementation object is taken as the target extended implementation object.

[0088] In this embodiment, if an exact match is found, the first extended implementation object in the data warehouse that matches the identifier string is taken as the target extended implementation object.

[0089] Step S2033: If the matching fails, perform a first-level truncation operation on the identifier string to obtain a first identifier, and perform a matching search operation on the data warehouse based on the first identifier.

[0090] In this embodiment, the specific implementation process of performing a first-level truncation operation on the identifier string to obtain a first identifier, and performing a matching search operation on the data warehouse based on the first identifier, will be described in further detail in subsequent specific embodiments of this application, and will not be elaborated on here.

[0091] Step S2034: If the match is successful, the second extended implementation object that has been successfully matched shall be used as the target extended implementation object.

[0092] In this embodiment, if the first-level inheritance match is successful, the second extended implementation object in the data warehouse that matches the first identifier is taken as the target extended implementation object.

[0093] Step S2035: If the matching fails, perform a second-level truncation operation on the first identifier to obtain a second identifier, and perform a matching search operation on the data warehouse based on the second identifier.

[0094] In this embodiment, when the first-level inheritance match also fails, the system continues to perform a second-level truncation operation on the first-level parent identifier (i.e., the first identifier). The truncation rule is the same as the first level: find the last period from the rightmost side of the current identifier and remove that period and all characters to its right. The truncation formula is: second-level parent identifier = first-level parent identifier minus the last "." and all characters after it. For example, the first-level parent identifier "JARVIS.ORDER_SUBMIT.SMART_GUARD" becomes the use case-level identifier "JARVIS.ORDER_SUBMIT" after second-level truncation. Then, the system replaces the unique identifier part in the lookup key with the second-level parent identifier (second identifier), and recombines it with the fully qualified name of the extension point interface to construct a new ExtensionCoordinate object. Subsequently, the system performs a third HashMap lookup operation in the ExtensionRepository.

[0095] The matching result determination includes: if a matching extended implementation object is found, the second-level inheritance matching is considered successful, the system returns the extended implementation object at the use case level, and the matching process ends. If no match is found, the process proceeds to the next step of default implementation matching. The business implication of this step is: if even a scenario-level implementation does not exist, then common logic at the use case level is used, such as common logic shared by all order submission use cases, such as customer information verification, order basic data preparation, and public parameter verification.

[0096] The second-level inheritance matching is the second-layer fallback mechanism of the hierarchical upward search strategy, further elevating the search granularity from the scenario level to the use case level. This level of matching ensures that even if a specific business scenario does not define any extended implementation, the system can still find the general processing logic under that use case, guaranteeing that the business process will not be interrupted due to the lack of scenario implementation. This reflects the system's high degree of abstraction and reuse of common logic in its design.

[0097] Step S2036: If the match is successful, the third extended implementation object that is successfully matched shall be used as the target extended implementation object.

[0098] In this embodiment, if the second-level inheritance match is successful, the third extended implementation object in the data warehouse that matches the second identifier is taken as the target extended implementation object.

[0099] Step S2037: If the matching fails, perform a third-level truncation operation on the second identifier to obtain a third identifier, and perform a matching search operation on the data warehouse based on the third identifier.

[0100] In this embodiment, when second-level inheritance matching still fails, the system performs a final-level truncation operation on the second-level parent identifier, i.e., the third-level stage operation, truncating the identifier to the business domain level. The truncation formula is: Default identifier = Second-level parent identifier minus the last "." and all subsequent characters, retaining only the leftmost business identifier part. For example, the use case-level identifier "JARVIS.ORDER_SUBMIT" becomes the business domain-level identifier "JARVIS" after final truncation. Then, the system uses the default identifier as the unique identifier part and combines it with the fully qualified name of the extension point interface to construct an ExtensionCoordinate object. Subsequently, the system performs a fourth HashMap lookup operation in the ExtensionRepository to check if an extension implementation with "JARVIS" as the unique identifier exists.

[0101] Step S2038: If the match is successful, the matched fourth extended implementation object is taken as the target extended implementation object.

[0102] In this embodiment, if a matching extended implementation object is found, the system determines that the default match is successful and returns the default extended implementation object at the business domain level as the target extended implementation object.

[0103] Step S2039: If the matching fails, obtain a predefined empty implementation object and use the empty implementation object as the target extended implementation object.

[0104] In this embodiment, if the matching fails, that is, even the default implementation does not exist, the system will not throw an exception to interrupt the process. Instead, a predefined empty implementation object is used as a final fallback. This empty implementation object does not execute any business logic but ensures that the process can return normally, thus ensuring the robustness of the system.

[0105] Among these, default implementation matching is the final safeguard mechanism of the hierarchical upward search strategy, raising the search granularity to the highest level of the entire business domain. This mechanism ensures that in any extreme case, even if no exact implementation or inherited implementation exists at any level, the system can still find a fallback default implementation, guaranteeing that order requests will not cause system exceptions due to the inability to find a processor. The entire hierarchical matching process executes at most four HashMap lookups, each with a time complexity of O(1), resulting in minimal overall performance overhead.

[0106] Based on the above processing flow, this application performs matching and search operations on the identifier string in the data warehouse by using a hierarchical matching algorithm. This effectively ensures that the sub-scene can automatically inherit the logic of the parent scene, thereby realizing the open / closed principle and scene reuse at the code level. It fundamentally solves the problems of high code coupling, difficulty in expansion, and poor reusability in traditional solutions, and improves the efficiency and intelligence of matching and search operations.

[0107] In some alternative implementations, step S2031 includes the following steps: Step S20311: Obtain the first fully qualified class name of the preset extension point interface based on the executor.

[0108] In this embodiment, the aforementioned extension point interface refers to the extension point interface to be executed.

[0109] Step S20312: Obtain the preset key construction strategy.

[0110] In this embodiment, the key construction strategy refers to the strategy for constructing a composite lookup key. The corresponding strategy includes: after receiving the complete unique identifier (i.e., the aforementioned identifier string), the extension point executor first uses this complete identifier as the lookup key. Simultaneously, the system combines the fully qualified class name of the extension point interface to be executed with the unique identifier to construct an `ExtensionCoordinate` object, which serves as the composite lookup key in the `ExtensionRepository`. Specifically, the `ExtensionCoordinate` object is constructed as follows: Composite lookup key = Fully qualified class name of the extension point interface + Unique identifier.

[0111] Step S20313: Based on the key construction strategy, the first fully qualified class name and the identifier string are combined to obtain the corresponding composite lookup key.

[0112] In this embodiment, the first fully qualified class name and the identifier string can be combined based on the strategy content of the key construction strategy to construct a corresponding composite lookup key.

[0113] Step S20314: Perform an exact match lookup operation on the data warehouse based on the composite lookup key to obtain the corresponding exact match lookup result; wherein, the exact match lookup result includes exact match success or exact match failure.

[0114] In this embodiment, the data warehouse is specifically the ExtensionRepository. The system uses the constructed ExtensionCoordinate as the key to perform an exact match lookup operation in the ExtensionRepository. The underlying data structure of ExtensionRepository is based on a HashMap, therefore the time complexity of this lookup operation is O(1). The system calculates the hash value of the key in the HashMap, locates the corresponding bucket, and then compares each key for a complete match using the equals method. The matching result determination includes: if an extension implementation object exists in the data warehouse, and its unique identifier bound during registration is completely consistent with the unique identifier in the current composite lookup key, then the exact match is successful, the system directly returns the extension implementation object, the entire matching process ends, and subsequent inheritance lookup steps are not executed. If no completely matching entry exists in the warehouse, the exact match fails, and the system proceeds to the next step of the hierarchical inheritance matching process.

[0115] This application obtains the first fully qualified class name of a preset extension point interface based on the executor; then it obtains a preset key construction strategy; subsequently, it combines the first fully qualified class name and the identifier string based on the key construction strategy to obtain the corresponding composite lookup key; finally, it performs an exact match lookup operation on the data warehouse based on the composite lookup key to obtain the corresponding exact match lookup result. Based on the above processing flow, the exact match lookup in this application is the first priority strategy of the hierarchical matching algorithm, and its purpose is to find the extension implementation object that completely corresponds to the current order request with the highest priority. Since the underlying storage uses HashMap, the exact match lookup is extremely efficient and can be completed in constant time. Only when the scenario identifier of the order request is completely consistent with the identifier of a registered extension implementation will an exact match be hit, effectively ensuring that the processing logic of the finest-grained scenario can be executed first.

[0116] In some optional implementations of this embodiment, step S2033 includes the following steps: Step S20331: Obtain the preset truncation rules.

[0117] In this embodiment, when an exact match fails, the system performs a first-level truncation operation on the complete unique identifier. The truncation rule is as follows: starting from the rightmost side of the unique identifier string, find the position of the last period, remove the period and all characters to its right, and retain the part to the left of the period as the new search identifier. The truncation formula is: First-level parent identifier = Unique identifier minus the last "." and all characters thereafter. For example, the original unique identifier "JARVIS.ORDER_SUBMIT.SMART_GUARD.VIP" becomes the parent identifier "JARVIS.ORDER_SUBMIT.SMART_GUARD" after first-level truncation.

[0118] Step S20332: Perform a truncation operation on the identifier string based on the truncation rule to obtain the corresponding first identifier.

[0119] In this embodiment, the above-mentioned identifier string can be truncated based on the truncation formula in the above-mentioned truncation rules to obtain the corresponding first identifier.

[0120] Step S20333: Obtain the second fully qualified class name of the preset extension point interface.

[0121] In this embodiment, the system obtains the fully qualified class name of the extension point interface to be executed.

[0122] Step S20334: Combine the second fully qualified class name with the first identifier to obtain the corresponding lookup key.

[0123] In this embodiment, the system replaces the unique identifier part in the original identifier with the truncated first-level parent identifier (i.e., the first identifier), and recombines it with the fully qualified class name of the extension point interface to construct a new ExtensionCoordinate object as the lookup key.

[0124] Step S20335: Perform a matching search operation on the data warehouse based on the search key to obtain the corresponding matching search result; wherein, the matching search result includes successful matching or failed matching.

[0125] In this embodiment, the system again performs a HashMap lookup operation in the data warehouse to check if there is an extended implementation object that completely matches the first-level parent identifier. The matching result determination includes: if a matching extended implementation object is found, the first-level inheritance matching is considered successful, the system returns the extended implementation object of the parent scenario, and the matching process ends. If no matching extended implementation object is found, the system proceeds to the next step of second-level inheritance matching. The business meaning of this step is: if the sub-scenario of the current order request (such as "SMART_GUARD.VIP") does not have specifically defined processing logic, it automatically degrades to using the general processing logic of its parent scenario (such as "SMART_GUARD"), realizing the automatic reuse of parent scenario logic by the sub-scenario.

[0126] This application obtains a preset truncation rule; then, based on the truncation rule, it performs a truncation operation on the identifier string to obtain the corresponding first identifier; next, it obtains the preset fully qualified class name of the extension point interface; and combines the second fully qualified class name with the first identifier to obtain the corresponding lookup key; subsequently, it performs a matching lookup operation on the data warehouse based on the lookup key to obtain the corresponding matching lookup result; wherein, the matching lookup result includes successful matching or failed matching. Based on the above processing flow, the first-level inheritance matching provided by this application is the first-level fallback mechanism of the hierarchical upward lookup strategy. When the finest-grained exact match fails, the system automatically moves the search target up one level to find the implementation of the parent scenario. This mechanism allows developers to avoid rewriting the common logic already existing in the parent scenario when adding a new child scenario; the child scenario can automatically inherit all the processing capabilities of the parent scenario, greatly reducing code duplication and improving development efficiency.

[0127] In some optional implementations of this embodiment, step S204 includes the following steps: Step S2041: Obtain business data related to the order request.

[0128] In this embodiment, the aforementioned business data includes all the business data required for the submission of this order corresponding to the order request. This business data may include: Customer ID, used to uniquely identify the user placing the order; Service Address, recording the geographical location where the service needs to be delivered; Service Item List, recording which specific service items the user selected; SKU Information, recording the specific product code corresponding to each service item; Coupon Information, recording which coupons the user used and the discount amount; and Order Amount, recording the total amount to be paid.

[0129] Step S2042: Call the preset initial object.

[0130] In this embodiment, the aforementioned initial object is a pre-constructed blank data model built from scratch.

[0131] Step S2043: The business data is encapsulated in the initial object to obtain the corresponding generated object.

[0132] In this embodiment, the aforementioned business data can be encapsulated into the initial object to obtain a corresponding structured data carrier. Furthermore, during the encapsulation of business data, a set of context methods is also encapsulated within this initial object. Extended implementation objects can indirectly obtain the query capabilities of other services in the system by calling these methods, such as obtaining customer service query interfaces or supplier service query interfaces through the context. This context object is the sole data source for all extended implementation classes when executing business logic; regardless of the business scenario, the processing logic begins with this context object.

[0133] Step S2044: Use the generated object as the initial business context object.

[0134] This application obtains business data related to the order request; then calls a preset initial object; subsequently, it encapsulates the business data in the initial object to obtain a corresponding generated object; and finally, it uses the generated object as the initial business context object. Based on the above processing flow, this application automatically and accurately constructs a structured data carrier containing all the business information required for this order submission by obtaining the business data related to the order request, encapsulating the business data in the called initial object, and using the resulting generated object as the initial business context object, thus ensuring the accuracy of the generated initial business context object.

[0135] In some alternative implementations, the user information obtained is subject to user consent and complies with relevant laws and policies.

[0136] Furthermore, any software tools or components not belonging to our company that appear in the embodiments of this application are merely illustrative examples and do not represent actual use.

[0137] Furthermore, this application has the following innovative features: Effect 1: Satisfies the Open / Closed Principle. Adding new business scenarios only requires creating a new class and adding the `@Extend` annotation, without modifying any existing code, achieving true zero-intrusion extension. Effect 2: Supports scenario inheritance and reuse. Through a hierarchical matching mechanism, sub-scenarios can automatically reuse the common logic of the parent scenario. For example, the new scenario "SMART_GUARD.VIP" can automatically inherit the processing logic of "SMART_GUARD". Effect 3: Automatic registration and discovery. Based on Spring annotation scanning, extension point implementation classes are automatically discovered and registered at startup, eliminating the need for manual maintenance of mapping relationships and reducing the risk of configuration errors. Effect 4: Type safety. Based on generics and interface definitions, type consistency can be checked at compile time, avoiding runtime problems caused by incorrect spelling of scenario identifiers. Effect 5: High performance. Extension point lookup is implemented based on HashMap, with an exact matching time complexity of O(1), and hierarchical matching can complete the lookup in a maximum of 4 steps, resulting in minimal performance loss. Effect 6: Strong versatility. This application is not only applicable to order management systems but can also be extended to any enterprise-level application system requiring dynamic scenario routing.

[0138] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0139] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by instructing related hardware through computer-readable instructions. These computer-readable instructions can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The aforementioned storage medium can be a non-volatile storage medium such as a magnetic disk, optical disk, or read-only memory (ROM), or random access memory (RAM).

[0140] It should be understood that although the steps in the flowcharts of the accompanying figures are shown sequentially as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the accompanying figures may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times, and their execution order is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0141] Further reference Figure 3 As a response to the above Figure 2 To implement the method shown, this application provides an embodiment of a data processing apparatus, which is similar to... Figure 2 Corresponding to the method embodiments shown, this device can be specifically applied to various electronic devices.

[0142] like Figure 3 As shown, the data processing device 300 described in this embodiment includes: a first processing module 301, a splicing module 302, a searching module 303, a second processing module 304, a first execution module 305, an acquisition module 306, a second execution module 307, and a writing module 308. Wherein: The first processing module 301 is used to receive an order request to be processed and extract a specified identifier field corresponding to a preset field type from the request parameters of the order request; wherein, the number of the specified identifier fields includes multiple fields. The splicing module 302 is used to splice the specified identifier field to obtain the corresponding identifier string; The lookup module 303 is used to perform a matching lookup operation on the identifier string in a preset data warehouse based on a preset executor and a step-by-step matching algorithm to obtain the corresponding target extended implementation object; The second processing module 304 is used to obtain the initial business context object corresponding to the order request and pass the initial business context object to the target extended implementation object; The first execution module 305 is used to call a preset general business execution method based on the target extended implementation object, perform common logic execution processing on the initial business context object, and obtain the corresponding business context object; The acquisition module 306 is used to acquire the scene identifier field from the specified identifier field; The second execution module 307 is used to call the target business execution method corresponding to the scene identifier field based on the target extended implementation object, perform specific business logic execution processing on the business context object, and obtain the corresponding target order data. The writing module 308 is used to write the target order data to the target database based on a preset interface.

[0143] In some optional implementations of this embodiment, the first processing module 301 includes: The first extraction submodule is used to extract the business identifier field corresponding to the business field type from the request parameters; The second extraction submodule is used to extract the use case identifier field corresponding to the use case field identifier from the request parameters; The third extraction submodule is used to extract the scene identifier field corresponding to the scene field identifier from the request parameters; The integration submodule is used to integrate the business identifier field, the use case identifier field, and the scenario identifier field to obtain the corresponding integrated field; The first determining submodule is used to use the integrated field as the specified identifier field.

[0144] In some optional implementations of this embodiment, the splicing module 302 includes: The first acquisition submodule is used to acquire preset target symbols; The first submodule is used to invoke the preset identifier concatenation rules; The splicing submodule is used to splice the specified identifier field using the target symbol based on the identifier splicing rules to obtain the corresponding spliced ​​data. The second determining submodule is used to use the concatenated data as the identifier string.

[0145] In some optional implementations of this embodiment, the lookup module 303 includes: The first search submodule is used to perform an exact match search operation on the data warehouse based on the executor and the identifier string; The third determining submodule is used to take the first successfully matched extended implementation object as the target extended implementation object if a match is successful. The second search submodule is used to perform a first-level truncation operation on the identifier string to obtain a first identifier if the match fails, and to perform a matching search operation on the data warehouse based on the first identifier. The fourth determining submodule is used to, if a match is successful, take the second extended implementation object that has been successfully matched as the target extended implementation object; The third search submodule is used to perform a second-level truncation operation on the first identifier to obtain a second identifier if the match fails, and to perform a matching search operation on the data warehouse based on the second identifier; The fifth determining submodule is used to, if a match is successful, take the third extended implementation object that has been successfully matched as the target extended implementation object; The fourth search submodule is used to perform a third-level truncation operation on the second identifier to obtain a third identifier if the match fails, and to perform a matching search operation on the data warehouse based on the third identifier; The sixth determining submodule is used to, if a match is successful, take the matched fourth extended implementation object as the target extended implementation object; The processing submodule is used to obtain a predefined empty implementation object if the matching fails, and use the empty implementation object as the target extended implementation object.

[0146] In some optional implementations of this embodiment, the first lookup submodule includes: The first acquisition unit is used to acquire the first fully qualified class name of the preset extension point interface based on the executor; The second acquisition unit is used to acquire a preset key construction strategy; The first combination unit is used to combine the first fully qualified class name and the identifier string based on the key construction strategy to obtain the corresponding composite lookup key; The first search unit is used to perform an exact match search operation on the data warehouse based on the composite search key to obtain the corresponding exact match search result; wherein, the exact match search result includes exact match success or exact match failure.

[0147] In some optional implementations of this embodiment, the second lookup submodule includes: The third acquisition unit is used to acquire preset truncation rules; A truncation unit is used to perform a truncation operation on the identifier string based on the truncation rule to obtain the corresponding first identifier; The fourth acquisition unit is used to acquire the second fully qualified class name of the preset extension point interface; The second combination unit is used to combine the second fully qualified class name with the first identifier to obtain the corresponding lookup key; The second search unit is used to perform a matching search operation on the data warehouse based on the search key to obtain the corresponding matching search result; wherein the matching search result includes successful matching or failed matching.

[0148] In some optional implementations of this embodiment, the second processing module 304 includes: The second acquisition submodule is used to acquire business data related to the order request; The second calling submodule is used to call the preset initial object; An encapsulation submodule is used to encapsulate the business data in the initial object to obtain the corresponding generated object; The seventh determination submodule is used to use the generated object as the initial business context object.

[0149] To address the aforementioned technical problems, embodiments of this application also provide a computer device. Please refer to [link / reference needed]. Figure 4 , Figure 4 This is a basic structural block diagram of the computer device in this embodiment.

[0150] The computer device 4 includes a memory 41, a processor 42, and a network interface 43 that are interconnected via a system bus. It should be noted that only the computer device 4 with components 41-43 is shown in the figure; however, it should be understood that it is not required to implement all the shown components, and more or fewer components can be implemented alternatively. Those skilled in the art will understand that the computer device described here is a device capable of automatically performing numerical calculations and / or information processing according to pre-set or stored instructions, and its hardware includes, but is not limited to, microprocessors, application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), digital signal processors (DSPs), embedded devices, etc.

[0151] The computer device can be a desktop computer, laptop, handheld computer, or cloud server, etc. The computer device can interact with the user via a keyboard, mouse, remote control, touchpad, or voice control.

[0152] The memory 41 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, magnetic disk, optical disk, etc. In some embodiments, the memory 41 may be an internal storage unit of the computer device 4, such as the hard disk or memory of the computer device 4. In other embodiments, the memory 41 may also be an external storage device of the computer device 4, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the computer device 4. Of course, the memory 41 may include both the internal storage unit and its external storage device of the computer device 4. In this embodiment, the memory 41 is typically used to store the operating system and various application software installed on the computer device 4, such as computer-readable instructions for data processing methods. In addition, the memory 41 can also be used to temporarily store various types of data that have been output or will be output.

[0153] In some embodiments, the processor 42 may be a central processing unit (CPU), a controller, a microcontroller, a microprocessor, or other data processing chip. The processor 42 is typically used to control the overall operation of the computer device 4. In this embodiment, the processor 42 is used to execute computer-readable instructions stored in the memory 41 or to process data, for example, to execute computer-readable instructions for the data processing method.

[0154] The network interface 43 may include a wireless network interface or a wired network interface, which is typically used to establish communication connections between the computer device 4 and other electronic devices.

[0155] This application also provides another embodiment, namely, providing a computer-readable storage medium storing computer-readable instructions that can be executed by at least one processor to cause the at least one processor to perform the steps of the data processing method described above.

[0156] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0157] Obviously, the embodiments described above are merely some embodiments of this application, not all embodiments. The accompanying drawings show preferred embodiments of this application, but do not limit the patent scope of this application. This application can be implemented in many different forms; rather, these embodiments are provided to provide a more thorough and comprehensive understanding of the disclosure of this application. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing specific embodiments, or make equivalent substitutions for some of the technical features. Any equivalent structures made using the content of this application's specification and drawings, directly or indirectly applied to other related technical fields, are similarly within the scope of patent protection of this application.

[0158] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

Claims

1. A data processing method, characterized in that, Includes the following steps: Receive an order request to be processed, and extract a specified identifier field corresponding to a preset field type from the request parameters of the order request; wherein, the number of the specified identifier fields includes multiple fields; The specified identifier field is concatenated to obtain the corresponding identifier string; Based on a preset executor, a step-by-step matching algorithm is used to perform a matching search operation on the identifier string in a preset data warehouse to obtain the corresponding target extended implementation object; Obtain the initial business context object corresponding to the order request, and pass the initial business context object to the target extended implementation object; Based on the target extension implementation object, a preset general business execution method is called to perform common logic execution processing on the initial business context object to obtain the corresponding business context object; Obtain the scene identifier field from the specified identifier field; Based on the target extension implementation object, the target business execution method corresponding to the scene identifier field is called to perform specific business logic execution processing on the business context object to obtain the corresponding target order data; The target order data is written to the target database based on the preset interface.

2. The data processing method according to claim 1, characterized in that, The step of extracting the specified identifier field corresponding to the preset field type from the request parameters of the order request specifically includes: Extract the business identifier field corresponding to the business field type from the request parameters; Extract the use case identifier field corresponding to the use case field identifier from the request parameters; Extract the scene identifier field corresponding to the scene field identifier from the request parameters; The business identifier field, the use case identifier field, and the scenario identifier field are integrated to obtain the corresponding integrated field; Use the integrated field as the designated identifier field.

3. The data processing method according to claim 1, characterized in that, The step of concatenating the specified identifier field to obtain the corresponding identifier string specifically includes: Obtain the preset target symbol; Call the preset identifier splicing rules; Based on the aforementioned identifier concatenation rules, the target symbol is used to concatenate the specified identifier field to obtain the corresponding concatenated data; The concatenated data is used as the identifier string.

4. The data processing method according to claim 1, characterized in that, The step of using a preset executor and a step-by-step matching algorithm to perform a matching search operation on the identifier string in a preset data warehouse to obtain the corresponding target extended implementation object specifically includes: Based on the executor, the identification string is used to perform an exact match lookup operation on the data warehouse; If a match is successful, the first successfully matched extended implementation object will be used as the target extended implementation object. If the match fails, a first-level truncation operation is performed on the identifier string to obtain a first identifier, and a matching search operation is performed on the data warehouse based on the first identifier; If a match is successful, the second extended implementation object that matches successfully will be used as the target extended implementation object; If the match fails, a second-level truncation operation is performed on the first identifier to obtain a second identifier, and a matching search operation is performed on the data warehouse based on the second identifier; If a match is successful, the third extended implementation object that matches successfully will be used as the target extended implementation object; If the match fails, a third-level truncation operation is performed on the second identifier to obtain a third identifier, and a matching search operation is performed on the data warehouse based on the third identifier; If a match is successful, the fourth matching extended implementation object will be used as the target extended implementation object. If the match fails, a predefined empty implementation object is obtained and used as the target extended implementation object.

5. The data processing method according to claim 4, characterized in that, The step of performing an exact match lookup operation on the data warehouse using the identifier string based on the executor specifically includes: The first fully qualified class name of the preset extension point interface is obtained based on the executor; Retrieve the preset key construction strategy; Based on the key construction strategy, the first fully qualified class name and the identifier string are combined to obtain the corresponding composite lookup key; Based on the composite lookup key, an exact match lookup operation is performed on the data warehouse to obtain the corresponding exact match lookup result; wherein, the exact match lookup result includes exact match success or exact match failure.

6. The data processing method according to claim 4, characterized in that, The step of performing a first-level truncation operation on the identifier string to obtain a first identifier, and then performing a matching search operation on the data warehouse based on the first identifier, specifically includes: Retrieve the preset truncation rules; Based on the truncation rule, the identifier string is truncated to obtain the corresponding first identifier; Get the second fully qualified class name of the preset extension point interface; The second fully qualified class name is combined with the first identifier to obtain the corresponding lookup key; A matching search operation is performed on the data warehouse based on the search key to obtain the corresponding matching search result; wherein, the matching search result includes successful matching or failed matching.

7. The data processing method according to claim 1, characterized in that, The step of obtaining the initial business context object corresponding to the order request specifically includes: Obtain business data related to the order request; Call the pre-defined initial object; The business data is encapsulated in the initial object to obtain the corresponding generated object; The generated object is used as the initial business context object.

8. A data processing apparatus, characterized in that, include: The first processing module is used to receive an order request to be processed and extract a specified identifier field corresponding to a preset field type from the request parameters of the order request; wherein, the number of the specified identifier fields includes multiple fields. The concatenation module is used to concatenate the specified identifier field to obtain the corresponding identifier string; The search module is used to perform a matching search operation on the identifier string in a preset data warehouse based on a preset executor and a step-by-step matching algorithm to obtain the corresponding target extended implementation object; The second processing module is used to obtain the initial business context object corresponding to the order request and pass the initial business context object to the target extended implementation object; The first execution module is used to call a preset general business execution method based on the target extended implementation object, perform common logic execution processing on the initial business context object, and obtain the corresponding business context object; The acquisition module is used to acquire the scene identifier field from the specified identifier field; The second execution module is used to call the target business execution method corresponding to the scene identifier field based on the target extended implementation object, perform specific business logic execution processing on the business context object, and obtain the corresponding target order data. The writing module is used to write the target order data to the target database based on a preset interface.

9. A computer device, characterized in that, The method includes a memory and a processor, wherein the memory stores computer-readable instructions, and the processor executes the computer-readable instructions to implement the steps of the data processing method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-readable instructions, which, when executed by a processor, implement the steps of the data processing method as described in any one of claims 1 to 7.

Images