Interface mapping system and transaction processing system

By loading the open point logic implementation class into the target virtual machine and using the interface mapping system, the problems of code verbosity and version inconsistency in large systems are solved, enabling flexible expansion and efficient maintenance of interfaces, and improving system compatibility and performance.

CN115080274BActive Publication Date: 2025-11-18BEIJING JINGDONG TUOXIAN TECH CO LTD
View PDF 1 Cites 0 Cited by

Patent Information

Application Number
CN202210800862.7
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-07-08
Publication Date
2025-11-18
Estimated Expiration
2042-07-08

AI Technical Summary

Technical Problem

In large systems, when the same backend service supports multiple callers, hard-coding the business logic results in lengthy and difficult-to-maintain code. Furthermore, different versions of the app may call different interfaces, making it difficult to guarantee compatibility and maintenance efficiency.

Method used

By loading the open point logic implementation class corresponding to the fully qualified name of the interface into the target virtual machine, and executing the open point logic implementation class according to the request parameters, the interface can be flexibly extended. The interface mapping system enables communication between the caller and the server, decoupling the version mapping logic from the business system.

Benefits of technology

It enables flexible expansion of interfaces, reduces redundant development, improves production efficiency, supports dynamic horizontal expansion, ensures system compatibility and performance, and enhances the integration efficiency for callers.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN115080274B_ABST
    Figure CN115080274B_ABST
Patent Text Reader

Abstract

The application discloses a service processing method, device and system, and an interface mapping system, and relates to the technical field of computers. A specific embodiment of the method comprises the following steps: determining a target invoker identifier, an interface fully qualified name and request parameters according to a received service request; judging whether an open point logic implementation class corresponding to the interface fully qualified name is loaded in a target virtual machine corresponding to the target invoker identifier; and in the case that the open point logic implementation class corresponding to the interface fully qualified name is loaded in the target virtual machine, executing the open point logic implementation class in the target virtual machine according to the request parameters, and generating a response result corresponding to the service request. The embodiment can more flexibly support interface expansion, hand over customizable content to a specific invoker, more greatly avoid repeated development of interfaces, facilitate code maintenance, and improve production efficiency.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of application development technology, and in particular to a business processing method, apparatus and system, and interface mapping system. Background Technology

[0002] For a large system, a single backend service can support multiple callers. For example, a backend service might simultaneously support enterprise business apps, enterprise business H5 pages, enterprise health apps, and internet hospitals, some of which have similarities but also differences. Hard-coding these business logics would result in verbose and difficult-to-maintain code. Summary of the Invention

[0003] In view of this, embodiments of the present invention provide a business processing method, apparatus and system, and an interface mapping system. By loading an open point logic implementation class corresponding to the fully qualified name of the interface in the target virtual machine, the open point logic implementation class in the target virtual machine is executed according to the request parameters. This can more flexibly support the extension of the interface, hand over the customizable content to the specific caller, avoid the repeated development of the interface to a greater extent, facilitate code maintenance, and improve production efficiency.

[0004] To achieve the above objectives, according to one aspect of the present invention, a business processing method is provided, comprising:

[0005] Determine the target caller identifier, fully qualified interface name, and request parameters based on the received business request;

[0006] Determine whether the open point logic implementation class corresponding to the fully qualified name of the interface is loaded in the target virtual machine corresponding to the target caller identifier;

[0007] If the open point logic implementation class corresponding to the fully qualified name of the interface is loaded in the target virtual machine, the open point logic implementation class in the target virtual machine is executed according to the request parameters to generate a response result corresponding to the business request.

[0008] Optionally, before determining whether the open point logic implementation class corresponding to the fully qualified name of the interface is loaded in the target virtual machine corresponding to the target caller identifier, the method further includes: in response to receiving the open point logic implementation class implemented by the target caller based on the open point interface protocol, loading the open point logic implementation class into the target virtual machine; wherein the open point interface protocol is pre-set for the interface.

[0009] Optionally, the open point interface protocol includes a caller identification method, and at least one of the following: sorting rule method, callback interface method, business logic method, and extension method.

[0010] Optionally, the business request is generated through the following steps: parsing the target caller identifier, method name, and version number from the call request issued by the target caller; determining the business system interface information corresponding to the method name and the version number based on the pre-entered interface details; and generating a business system initiating a business request based on the target caller identifier and the business system interface information.

[0011] According to a second aspect of the present invention, a business processing apparatus is provided, comprising:

[0012] The business request receiving module determines the target caller identifier, the fully qualified name of the interface, and the request parameters based on the received business request.

[0013] The business logic judgment module determines whether the target virtual machine corresponding to the target caller identifier has loaded the open point logic implementation class corresponding to the fully qualified name of the interface;

[0014] The business logic execution module, if the open point logic implementation class corresponding to the fully qualified name of the interface is loaded in the target virtual machine, executes the open point logic implementation class in the target virtual machine according to the request parameters, and generates a response result corresponding to the business request.

[0015] Optionally, the apparatus further includes a logic definition module, configured to: in response to receiving an Open Point logic implementation class implemented by the target caller based on the Open Point Interface protocol, load the Open Point logic implementation class into the target virtual machine; wherein the Open Point Interface protocol is pre-set for the interface.

[0016] Optionally, the open point interface protocol includes a caller identification method, and at least one of the following: sorting rule method, callback interface method, business logic method, and extension method.

[0017] According to a third aspect of the present invention, an interface mapping system is provided, comprising:

[0018] The call request receiving module receives the call request sent by the target caller and parses the target caller identifier, method name and version number from the call request;

[0019] The interface information determination module determines the business system interface information corresponding to the method name and the version number based on the pre-entered interface details.

[0020] The business request generation module generates a business request based on the target caller identifier and the business system interface information, and initiates the business request to the business processing device provided in the second aspect of the present invention.

[0021] Optionally, the interface mapping system of this embodiment further includes a call request statistics module, used for at least one of the following:

[0022] If the target caller identifier exists in a preset first caller list, or does not exist in a preset second caller list, the call request is intercepted;

[0023] If the number of call requests issued by the target caller exceeds a preset threshold, the call requests will be intercepted, or a preset alarm strategy will be triggered.

[0024] The target caller is authenticated, and the call request is intercepted if authentication fails.

[0025] According to a fourth aspect of the present invention, a business processing system is provided, including a business processing apparatus and an interface mapping system; wherein,

[0026] The interface mapping system receives a call request from the target caller, parses the target caller identifier, method name, and version number from the call request, determines the business system interface information corresponding to the method name and version number based on the pre-entered interface details, generates a business request based on the target caller identifier and the business system interface information, and initiates the business request to the business processing device.

[0027] The business processing device determines the target caller identifier, the fully qualified name of the interface, and the request parameters based on the received business request. It then determines whether the open point logic implementation class corresponding to the fully qualified name of the interface is loaded in the target virtual machine corresponding to the target caller identifier. If the open point logic implementation class corresponding to the fully qualified name of the interface is loaded in the target virtual machine, the device executes the open point logic implementation class in the target virtual machine according to the request parameters to generate a response result corresponding to the business request.

[0028] The business processing device returns the response result to the interface mapping system, and the interface mapping system returns the response result to the target caller.

[0029] According to a fifth aspect of the present invention, an electronic device for business processing is provided, comprising:

[0030] One or more processors;

[0031] Storage device for storing one or more programs.

[0032] When the one or more programs are executed by the one or more processors, the one or more processors implement the method provided in the first aspect of the embodiments of the present invention.

[0033] According to a sixth aspect of the present invention, a computer-readable medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method provided in the first aspect of the present invention.

[0034] One embodiment of the above invention has the following advantages or beneficial effects: By loading the open point logic implementation class corresponding to the fully qualified name of the interface in the target virtual machine, and executing the open point logic implementation class in the target virtual machine according to the request parameters, it can more flexibly support the extension of the interface, hand over the customizable content to the specific caller, avoid repeated development of the interface to a greater extent, facilitate code maintenance, and improve production efficiency. This embodiment of the invention, by using an interface mapping system to realize communication between the caller and the server, can decouple the version mapping logic from the business system, reducing the complexity of the business system; multiple callers benefit from a single deployment, as the version mapping system is extracted and can be accessed by multiple business systems and multiple callers, improving production efficiency; it does not affect the original business, and the business system can be seamlessly integrated, ensuring system compatibility; it supports dynamic horizontal scaling, ensuring system performance; the interface version can be flexibly configured and take effect in real time, increasing the system's elasticity; it supports multi-protocol calls, and the caller is unaware of it, improving the caller's integration efficiency.

[0035] The further effects of the aforementioned unconventional alternative methods will be explained below in conjunction with specific implementation methods. Attached Figure Description

[0036] The accompanying drawings are provided to better understand the invention and are not intended to unduly limit the scope of the invention. Wherein:

[0037] Figure 1 This is a schematic diagram of the main flow of the business processing method according to an embodiment of the present invention;

[0038] Figure 2 This is a flowchart illustrating the implementation of the open point logic class in an optional embodiment of the present invention;

[0039] Figure 3 This is a schematic diagram of the Open Point Interface Protocol in an optional embodiment of the present invention;

[0040] Figure 4 This is a schematic diagram of the architecture of the business processing method in an optional embodiment of the present invention;

[0041] Figure 5 This is a schematic diagram of the interface version number mapping table in an optional embodiment of the present invention;

[0042] Figure 6 This is a schematic diagram of the main process of interface mapping in an optional embodiment of the present invention;

[0043] Figure 7This is a schematic diagram of the main flow of the business processing method in an optional embodiment of the present invention;

[0044] Figure 8 This is a schematic diagram of the main modules of the business processing device according to an embodiment of the present invention;

[0045] Figure 9 This is a schematic diagram of the main modules of the interface mapping system according to an embodiment of the present invention;

[0046] Figure 10 This is a schematic diagram of the main components of the business processing system according to an embodiment of the present invention;

[0047] Figure 11 This is an exemplary system architecture diagram in which embodiments of the present invention can be applied;

[0048] Figure 12 This is a schematic diagram of the structure of a computer system suitable for implementing terminal devices or servers of the present invention. Detailed Implementation

[0049] The following description, in conjunction with the accompanying drawings, illustrates exemplary embodiments of the present invention, including various details to aid understanding. These details should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0050] For a large system, a single backend service can support multiple callers, some of whom have similar but distinct business functions. For example, a backend service might simultaneously support an enterprise business app, an enterprise business H5 page, an enterprise health app, and an internet hospital. While some of these functions are similar, they also have differences. Hard-coding these functions would result in lengthy and difficult-to-maintain code. This invention addresses this by using open points to support scenarios where the business functions are the same but the processes differ.

[0051] For example, a business system provides family doctor services. The process for querying a user's signed-up family doctor (also known as a family physician, a personalized healthcare service) is as follows: ① Obtain the current user's family doctor service package (including activation status and service package type) through the user ID; ② Query the contract status of the current service package; ③ Query the contracted doctor team information for the current service package; ④ Query the contracted doctor manager information for the current service package; ⑤ Query the most recent IM message information for the current service package. Wherein:

[0052] The business process of the enterprise business APP is: steps ①②③④⑤. After the query is completed in step ①, filtering is required to keep only the activated service packages and not display the inactive service packages. Therefore, the process becomes ① (filtering) ②③④⑤.

[0053] The business process of the Enterprise Health APP is: ①②③ (obtain the last consultation time based on the doctor) ④⑤. The difference from the enterprise business is that the Enterprise Health APP does not need to filter the activation status, and after obtaining the doctor information, it needs to add the consultation time information.

[0054] The business process of an internet hospital is as follows: ① (filtering service packages of mutual medical type) ②③ (obtaining the corresponding department based on doctor information) ④⑤. This process adds a filtering step and an additional information acquisition step to the original service.

[0055] The underlying logic of the family doctor service for the different callers mentioned above remains unchanged. If the filtering of the service package and the additional information of the doctor data can be made into two open points for the corresponding callers to implement themselves, and the family doctor only provides the basic capabilities ①②③④⑤, then different callers can find their own open point logic implementation class to execute and return customized result information.

[0056] In view of this, according to one aspect of the present invention, a business processing method is provided.

[0057] Figure 1 This is a schematic diagram of the main flow of the business processing method according to an embodiment of the present invention, as shown below. Figure 1 As shown, the business processing method includes steps S101, S102 and S103.

[0058] Step S101: Determine the target caller identifier, fully qualified interface name, and request parameters based on the received business request.

[0059] The caller refers to the system that intends to invoke the business system. The caller identifier is used to uniquely identify a caller. The caller identifier can be a system identifier, such as an application (APP) identifier, or it can be the identifier of the system user. In practical applications, both the caller identifier and the system identifier can be used as the caller identifier. For example, if system user D corresponds to four applications (the corresponding application identifiers are APP1, APP2, APP3, and APP4), then the corresponding caller identifiers can be D-APP1, D-APP2, D-APP3, and D-APP4, respectively.

[0060] The fully qualified name of an interface includes the class name and method name. Request parameters refer to the data that the business interface of the business system requires to be passed in; these are the input parameters of the business interface, and the data returned by the business interface are the output parameters. For example, when querying an employee's personal information by name, the input parameter is the name, and the output parameter is the personal information.

[0061] Step S102: Determine whether the target virtual machine corresponding to the target caller identifier has loaded the open point logic implementation class corresponding to the fully qualified name of the interface.

[0062] An open point is a functionality that allows the caller to implement it themselves. After the caller implements and publishes the open point, they configure its class name. In this embodiment of the invention, open points are implemented using SPI (Service Provider Interface, a set of interfaces that can be implemented or extended by third parties, enabling framework extensions and component replacements). In practical applications, some interfaces can be defined as open points according to actual needs. An implementation class is specific to an interface and refers to the implementation of the content agreed upon in the interface. An open point logic implementation class refers to the business execution rules or related program code that can implement the caller's custom logic. Before determining whether the open point logic implementation class corresponding to the fully qualified name of the interface is loaded in the target virtual machine corresponding to the target caller identifier, if the interface has been defined as an open point and the open point logic implementation class implemented by the target caller has been uploaded to the business system, this embodiment of the invention can directly load the corresponding open point logic implementation class. Before determining whether the open point logic implementation class corresponding to the fully qualified name of the interface has been loaded in the target virtual machine corresponding to the target caller identifier, if the interface has been defined as an open point, but the open point logic implementation class implemented by the target caller itself has not been uploaded to the business system, or the target caller intends to update its open point logic implementation class, then in response to receiving the open point logic implementation class implemented by the target caller, the open point logic implementation class can be loaded into the target virtual machine.

[0063] Figure 2 This is a flowchart illustrating the implementation of the open point logic class in an optional embodiment of the present invention. For example... Figure 2 As shown, the business system is the interface provider, and the caller is the interface invoker. After the business system defines the open points, if the caller needs to customize the open points, it implements the open point logic implementation class on the defined open points. Then, it pushes the service package of the implemented open point logic implementation class to the business system's server. When the service is called, the business system loads the JVM (Java Virtual Machine) level class file (a binary file that can run on the JVM's hardware platform and operating system) through the fully qualified name of the interface and the class loader, and executes the custom open point logic.

[0064] For example, provider A provides an interface `interfaceA` and defines open points. Consumer A, the caller, pulls the interface definition, implements the open point logic class locally (the open point logic implementation class contains a consumerA caller identifier to distinguish it from other consumers), and then packages it into a JAR file, loading it into provider A's JVM via a classloader (effective immediately). Consumer A initiates a call to interface A, provider A executes the business logic and the open point logic implementation class. The caller identifier ensures that the business system accurately executes the logic code implemented by consumer A when executing the open point logic implementation class. This completes the entire call chain without relying on any middleware to store data and state, making it very convenient to use. The caller only needs to focus on its own business logic implementation without requiring additional configuration on any platform.

[0065] When a caller implements an open point logic implementation class, it needs to configure a caller identification method to locate the corresponding open point logic implementation class based on the caller identifier. In practical applications, a standard protocol can be pre-configured on the interface, and the caller implements its own logic according to this protocol. Figure 3 This is a schematic diagram of the Open Point Interface protocol in an optional embodiment of the present invention. Figure 3 In this implementation, the caller identification method is used to find the corresponding open point logic implementation class based on the caller identifier, and the business logic method is used to define the implementation methods of each business. The caller needs to implement both of these methods when implementing the open point logic implementation class. The open point interface protocol may also include at least one of the following: sorting rule method, callback interface method, business logic method, and extension method. The sorting rule method defines the implementation order of each business implementation method, the callback interface method defines the callback method after the method execution is complete, and the extension method defines other methods (specific methods can be customized, such as adding data filtering or filtering methods between multiple business implementation methods). The sorting rule method, callback interface method, and extension method can be selectively set according to actual needs. In this embodiment, a standard protocol is set up. After the caller implements the business logic according to the constraints of this standard protocol, a general adaptation of the open point is achieved. After implementing the open point logic implementation class according to this protocol specification, unified constraints and management of the open point logic implementation class can be achieved, while flexibly supporting various business scenarios.

[0066] Step S103: If the open point logic implementation class corresponding to the fully qualified name of the interface is loaded in the target virtual machine, the open point logic implementation class in the target virtual machine is executed according to the request parameters to generate a response result corresponding to the business request.

[0067] In this embodiment of the invention, when the open point logic implementation class corresponding to the fully qualified name of the interface is loaded in the target virtual machine, the open point logic implementation class in the target virtual machine is executed according to the request parameters. This can more flexibly support the extension of the interface, hand over the customizable content to the specific caller, avoid the repeated development of the interface to a greater extent, facilitate code maintenance, and improve production efficiency.

[0068] It should be noted that the business requests in the embodiments of the present invention can be sent directly from the caller to the business system, or they can be sent from the caller to the business system through other systems.

[0069] With the increasing frequency of app updates, each new version requires review, and the review periods vary across app stores. It can take several days from release to client download, and forced upgrades are not feasible. This leads to the coexistence of different app versions. For the backend, different app versions may call different APIs, and there are also cases where the APIs are the same but the logic is different. If the code determines different business logic based on different versions—for example, the client calls the backend application with version information (version=xxx), and the backend API receives the client request and determines the appropriate business logic based on the version number—it becomes difficult to maintain the code later on, and it's impossible to guarantee that new logic will affect old logic.

[0070] If a project includes an interceptor or aspect that routes requests to different business logic based on a unified version, for example, a client calls a backend application with version information (version=xxx). Upon receiving the client request, the backend API calls a unified logic handler on the specific API level. This handler uses a unified method to handle the version logic. While this extracts the version number determination from each API into a unified method, reducing redundant code, implementing unified version routing control in a project is highly intrusive and lacks flexible dynamic configuration.

[0071] If service calls are made through an RPC framework, dynamic aliases can be added. Different versions can be distinguished by these aliases and routed to different application containers. For example, when a client initiates a call to a backend application, different app versions correspond to different gateway interfaces. For instance, version 1.0 of the app corresponds to the gateway interface f1_prodA, while version 2.0 corresponds to f1_prodB. Different gateway interfaces correspond to different applications. Each new version release requires configuring a new set of gateway interfaces. The new version calls the corresponding gateway interface, while the old interfaces are retained. This approach relies on the client app including the alias when initiating the call, and the gateway routes to different application containers based on the alias. This solution is relatively simple and crude because most companies have gateways. However, this solution requires applying for a new gateway interface and deploying a new application instance for each version release. Each alias corresponds to a set of application containers, which wastes container resources with each iteration, resulting in low resource utilization and high maintenance costs. Moreover, each new version release requires manually configuring a new alias on the gateway, leading to low reliability.

[0072] Based on this, in some embodiments of the present invention, the caller and the business system communicate through an interface mapping system. Specifically, the interface mapping system parses the target caller's identifier, method name, and version number from the call request issued by the target caller, determines the business system interface information corresponding to the method name and version number based on pre-entered interface details, and initiates a business request based on the business system interface information generated by the business system using the target caller's identifier and the business system interface information. The caller only interacts with the interface mapping system; the interface mapping system communicates with the business system and returns the result to the caller. The caller is unaware of the specific business system behavior.

[0073] Figure 4 This is a schematic diagram of the architecture of the business processing method in an optional embodiment of the present invention. Figure 4 In the illustrated embodiment, the caller is a client, such as an iOS client, Android client, or Windows client. The interface mapping system sets up interface details (in this embodiment, the interface version mapping table `interface-version-mapping`), a local cache `localCache`, a distributed cache `jimdb`, a database (e.g., an SQL database), and a calling strategy (e.g., a JSF calling strategy `jsfClient`, an HTTP calling strategy `httpClient`, etc.). In this embodiment, the interface details can be stored in the form of an interface version number mapping table. Figure 5 This is a schematic diagram of the interface version number mapping table in an optional embodiment of the present invention. Figure 5In the illustrated embodiment, `type` specifies the specific invocation method (e.g., JSF, HTTP); `request_path` is the specific method name or path; `version` is the supported version number (supporting ranges, greater than, less than, and equal to); `fun_label` is an open point identifier used to identify the open points supported by the current interface, and the system determines at which stage the open point logic implementation class is executed through the open point identifier; `class_path`, `alias`, and `token` are the necessary information required for JSF generic invocation. `class_path` is the fully qualified class name of the interface used in JSF generic invocation, used to specify the class where the interface is located (class name + method name is required to initiate JSF generic invocation); `alias` is a service alias used to specify the specific invocation container or environment, different aliases correspond to different containers or environments; `token` is a secret key, one alias corresponds to one secret key, used for security authentication. In this embodiment, the invocation request only needs to carry the specific method name and version number, and does not need to carry `class_path`, `alias`, `token`, etc. The interface mapping system can query this information through the method name and version number, and then initiate an invocation to the real service.

[0074] After the interface details are entered into the database, the interface mapper can query the interface details from the database. Of course, after the interface details are entered into the database, they can also be synchronized to the distributed cache and the local cache. The interface mapper can then query the interface details from the distributed cache or the local cache to improve the performance of subsequent queries.

[0075] Figure 6 This is a schematic diagram of the main process of interface mapping in an optional embodiment of the present invention. Figure 7 This is a schematic diagram of the main flow of the business processing method in an optional embodiment of the present invention. For example... Figure 6 and 7As shown, after a user accesses the client (APP), the APP obtains the current client version number, carrying the method name (request name), version number, and the current caller identifier (the caller identifier is used to match which caller's open point logic implementation class is being executed). The interface mapping system checks the local cache for the corresponding interface details based on the current method and version number. If it exists, it retrieves it directly; otherwise, it retrieves it from the distributed cache. If it doesn't exist in the distributed cache, it retrieves it from the database. If the corresponding interface details are not found in the local cache, distributed cache, or database, a prompt message is returned to the client. Interface details refer to the information required by the interface mapping system to initiate a business request, as well as the aforementioned database configuration information, including interface type (type), request path (request_path), class name (class_path), alias (alias), and key (token). The version mapper obtains the actual interface and type based on the current interface protocol and finds the corresponding request strategy (request client) based on the request type. For HTTP requests, the API mapping system calls `HttpClient` to initiate the request to the business system. For JSF requests, it uses a generic JSF call. This system is also extensible; for example, if a web service call is needed, a web service call utility class can be added to the strategy factory. The API mapping system initiates specific business requests through its built-in client. These requests mainly include the request method, request parameters, and response results. For example, if the current business request is to retrieve user information using a user's PIN (a unique user ID), the request method would be JSF, the parameter would be the user's PIN, and the response would include the user's avatar, nickname, gender, and account. The business system executes the method's logic implementation class, generates the corresponding response, and returns it to the API mapping system. The API mapping system then returns the response to the business request to the app.

[0076] In this embodiment of the invention, the interface mapping system does not depend on any specific business system, thus supporting dynamic horizontal scaling and adaptable to various business scenarios of different scales. Because it provides a unified calling method to callers, while the specific calling protocol of the business system is handled by the interface mapping system, callers do not need to concern themselves with the specific calling method and protocol of the business; they only need to focus on the specific methods and input / output parameters. The interface mapping system only initiates business requests and does not perform any logical processing, therefore it is applicable to both new and old systems and can be implemented without the business system's awareness.

[0077] This embodiment unifies the call entry point for the caller and facilitates the expansion of data statistics functions, such as counting the call volume of different app versions, counting the call volume of a specific interface, and even performing some customized functions. Optionally, the interface mapping system of this embodiment can also be used for at least one of the following:

[0078] If the target caller's identifier exists in a preset first caller list, the call request is intercepted. For example, if a user is detected to have engaged in fraudulent order-brushing behavior and has a high risk value (risk value is a system that identifies the risk level of a user), the user ID can be added to the first caller list in the version mapping system. When the system accesses the interface, it will first verify the first caller list. If the user is in the first caller list, it will directly return a fallback status code without making a specific interface call, thus reducing the pressure on the business system.

[0079] If the target caller identifier does not exist in the preset second caller list, the call request is intercepted. For example, in practical applications, if the business service corresponding to the business request is a special function used only by specific personnel—for instance, the health ranking of all employees can only be viewed by certain employees—then the user IDs of these personnel are configured in the second caller list. When accessing the interface, the second caller list is first verified. If the user is not in the second caller list, a permission denied message is returned directly, and no specific interface call is performed. If the user is found in the second caller list, the specific interface call is performed.

[0080] Interface rate limiting: If the number of call requests issued by the target caller exceeds a preset threshold, the call requests are blocked. For example, only 10,000 accesses per second are allowed for the interface; if this number is exceeded, no specific business call is initiated or a preset alarm policy is triggered, thereby effectively preventing machine-generated fraudulent activities.

[0081] Interface Alarms: When an interface encounters an error or exceeds the call limit, preset alarm strategies can be triggered (email, internal system notification, instant messaging notification, etc.).

[0082] Interface authentication: Authenticate the target caller and intercept the call request if authentication fails. For example, when only authorized callers can initiate calls to business interfaces, a unified authentication mechanism can be implemented. Before each interface call, it checks whether the current caller has passed authentication; if not, it returns "no permission".

[0083] This invention employs an interface mapping system to facilitate communication between the caller and the server. This decouples the version mapping logic from the business system, reducing its complexity. A single deployment benefits multiple callers, as the version mapping system can be extracted and accessed by multiple business systems and callers, improving production efficiency. It does not impact existing business processes, allowing seamless integration and ensuring system compatibility. Dynamic horizontal scaling is supported, guaranteeing system performance. Interface versions can be flexibly configured and take effect in real time, increasing system resilience. Multi-protocol calls are supported without the caller's awareness, improving the caller's integration efficiency.

[0084] According to a second aspect of the present invention, an apparatus for implementing the above-described business processing method is provided. Figure 8 This is a schematic diagram of the main modules of the service processing device according to an embodiment of the present invention, such as... Figure 8 As shown, the service processing device 800 includes:

[0085] The business request receiving module 801 determines the target caller identifier, the fully qualified name of the interface, and the request parameters based on the received business request.

[0086] The business logic judgment module 802 determines whether the target virtual machine corresponding to the target caller identifier has loaded the open point logic implementation class corresponding to the fully qualified name of the interface;

[0087] The business logic execution module 803, when the open point logic implementation class corresponding to the fully qualified name of the interface is loaded in the target virtual machine, executes the open point logic implementation class in the target virtual machine according to the request parameters and generates a response result corresponding to the business request.

[0088] Optionally, the apparatus further includes a logic definition module, configured to: in response to receiving an Open Point logic implementation class implemented by the target caller based on the Open Point Interface protocol, load the Open Point logic implementation class into the target virtual machine; wherein the Open Point Interface protocol is pre-set for the interface.

[0089] Optionally, the open point interface protocol includes a caller identification method, and at least one of the following: sorting rule method, callback interface method, business logic method, and extension method.

[0090] According to a third aspect of the present invention, an interface mapping system is provided. Figure 9 This is a schematic diagram of the main modules of the interface mapping system according to an embodiment of the present invention, such as... Figure 9 As shown, the interface mapping system 900 includes:

[0091] The call request receiving module 901 receives the call request sent by the target caller and parses the target caller identifier, method name and version number from the call request;

[0092] The interface information determination module 902 determines the business system interface information corresponding to the method name and the version number based on the pre-entered interface details.

[0093] The business request generation module 903 generates a business request based on the target caller identifier and the business system interface information, and initiates the business request to the business processing device provided in the second aspect of the present invention.

[0094] Optionally, the interface mapping system of this embodiment further includes a call request statistics module, used for at least one of the following:

[0095] If the target caller identifier exists in a preset first caller list, or does not exist in a preset second caller list, the call request is intercepted;

[0096] If the number of call requests issued by the target caller exceeds a preset threshold, the call requests will be intercepted, or a preset alarm strategy will be triggered.

[0097] The target caller is authenticated, and the call request is intercepted if authentication fails.

[0098] According to a fourth aspect of the present invention, a business processing system is provided. Figure 10 This is a schematic diagram of the main components of the business processing system according to an embodiment of the present invention, such as... Figure 10 As shown, the service processing system 1000 includes a service processing device 800 and an interface mapping system 900; wherein,

[0099] The interface mapping system 900 receives a call request from the target caller, parses the target caller identifier, method name, and version number from the call request, determines the business system interface information corresponding to the method name and version number based on the pre-entered interface details, generates a business request based on the target caller identifier and the business system interface information, and initiates the business request to the business processing device.

[0100] The business processing device 800 determines the target caller identifier, the fully qualified name of the interface, and the request parameters based on the received business request. It then determines whether the open point logic implementation class corresponding to the fully qualified name of the interface is loaded in the target virtual machine corresponding to the target caller identifier. If the open point logic implementation class corresponding to the fully qualified name of the interface is loaded in the target virtual machine, the device executes the open point logic implementation class in the target virtual machine according to the request parameters to generate a response result corresponding to the business request.

[0101] The business processing device 800 returns the response result to the interface mapping system 900, and the interface mapping system 900 returns the response result to the target caller.

[0102] According to a fifth aspect of the present invention, an electronic device for business processing is provided, comprising:

[0103] One or more processors;

[0104] Storage device for storing one or more programs.

[0105] When the one or more programs are executed by the one or more processors, the one or more processors implement the method provided in the first aspect of the embodiments of the present invention.

[0106] According to a sixth aspect of the present invention, a computer-readable medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method provided in the first aspect of the present invention.

[0107] Figure 11 An exemplary system architecture 1100 is shown that can be applied to the business processing method or business processing apparatus of the present invention.

[0108] like Figure 11 As shown, system architecture 1100 may include terminal devices 1101, 1102, and 1103, network 1104, and server 1105. Network 1104 is used as a medium to provide communication links between terminal devices 1101, 1102, and 1103 and server 1105. Network 1104 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0109] Users can use terminal devices 1101, 1102, and 1103 to interact with server 1105 via network 1104 to receive or send messages, etc. Various communication client applications can be installed on terminal devices 1101, 1102, and 1103, such as shopping applications, web browser applications, search applications, instant messaging tools, email clients, social media platform software, etc. (for example only).

[0110] Terminal devices 1101, 1102, and 1103 can be various electronic devices with displays and web browsing capabilities, including but not limited to smartphones, tablets, laptops, and desktop computers.

[0111] Server 1105 can be a server that provides various services, such as a backend management server that supports shopping websites browsed by users using terminal devices 1101, 1102, and 1103 (for example only). The backend management server can analyze and process data such as received product information query requests, and feed back the processing results (such as target push information, product information - for example only) to the terminal devices.

[0112] It should be noted that the business processing method provided in this embodiment of the invention is generally executed by server 1105, and correspondingly, the business processing device is generally located in server 1105. In addition, in this embodiment, terminal devices 1101, 1102, and 1103 may not communicate directly with server 1105, but may communicate with server 1105 through an interface mapping system.

[0113] It should be understood that Figure 11 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.

[0114] The following is for reference. Figure 12 It shows a schematic diagram of the structure of a computer system 1200 suitable for implementing a terminal device of the present invention. Figure 12 The terminal device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0115] like Figure 12 As shown, the computer system 1200 includes a central processing unit (CPU) 1201, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 1202 or programs loaded from storage section 1208 into random access memory (RAM) 1203. The RAM 1203 also stores various programs and data required for the operation of the system 1200. The CPU 1201, ROM 1202, and RAM 1203 are interconnected via a bus 1204. An input / output (I / O) interface 1205 is also connected to the bus 1204.

[0116] The following components are connected to I / O interface 1205: an input section 1206 including a keyboard, mouse, etc.; an output section 1207 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1208 including a hard disk, etc.; and a communication section 1209 including a network interface card such as a LAN card, modem, etc. The communication section 1209 performs communication processing via a network such as the Internet. A drive 1210 is also connected to I / O interface 1205 as needed. Removable media 1211, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1210 as needed so that computer programs read from them can be installed into storage section 1208 as needed.

[0117] In particular, according to the embodiments disclosed in this invention, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this invention include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1209, and / or installed from removable medium 1211. When the computer program is executed by central processing unit (CPU) 1201, it performs the functions defined above in the system of this invention.

[0118] It should be noted that the computer-readable medium shown in this invention can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this invention, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this invention, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

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

[0120] The modules described in the embodiments of the present invention can be implemented in software or hardware. The described modules can also be housed in a processor; for example, a processor can be described as including: a business request receiving module, a business logic judgment module, and a business logic execution module. The names of these modules do not necessarily limit the module itself; for example, the business logic judgment module can also be described as "a module that executes the open point logic implementation class in the target virtual machine according to the request parameters."

[0121] In another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiments; or it may exist independently and not assembled into the device. The computer-readable medium carries one or more programs, which, when executed by the device, cause the device to: determine a target caller identifier, a fully qualified interface name, and request parameters based on a received service request; determine whether an open point logic implementation class corresponding to the fully qualified interface name is loaded in a target virtual machine corresponding to the target caller identifier; and, if the open point logic implementation class corresponding to the fully qualified interface name is loaded in the target virtual machine, execute the open point logic implementation class in the target virtual machine according to the request parameters to generate a response result corresponding to the service request.

[0122] According to the technical solution of this invention, by loading the open point logic implementation class corresponding to the fully qualified name of the interface in the target virtual machine, and executing the open point logic implementation class in the target virtual machine according to the request parameters, the extension of the interface can be supported more flexibly. Customizable content is handed over to specific callers, greatly avoiding redundant interface development, facilitating code maintenance, and improving production efficiency. This invention, by employing an interface mapping system to realize communication between the caller and the server, can decouple the version mapping logic from the business system, reducing the complexity of the business system; it allows multiple callers to benefit from a single deployment, extracting the version mapping system for access by multiple business systems and multiple callers, improving production efficiency; it does not affect existing business operations, allowing seamless integration and ensuring system compatibility; it supports dynamic horizontal scaling, ensuring system performance; the interface version can be flexibly configured and take effect in real time, increasing system elasticity; it supports multi-protocol calls without the caller's awareness, improving the caller's integration efficiency.

[0123] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can occur depending on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. An interface mapping system, characterized in that, include: The call request receiving module receives the call request sent by the target caller and parses the target caller identifier, method name and version number from the call request; The interface information determination module determines the business system interface information corresponding to the method name and the version number based on the pre-entered interface details. The business request generation module generates a business request based on the target caller identifier and the business system interface information, and sends the business request to the business processing device. The business processing device is configured to: determine the target caller identifier, the fully qualified name of the interface, and the request parameters based on the received business request; determine whether the target virtual machine corresponding to the target caller identifier has loaded the open point logic implementation class corresponding to the fully qualified name of the interface; if the target virtual machine has loaded the open point logic implementation class corresponding to the fully qualified name of the interface, execute the open point logic implementation class in the target virtual machine according to the request parameters, and generate a response result corresponding to the business request.

2. The interface mapping system as described in claim 1, characterized in that, The business processing device is also used for: Before determining whether the target virtual machine corresponding to the target caller identifier has loaded the open point logic implementation class corresponding to the fully qualified name of the interface, in response to receiving the open point logic implementation class implemented by the target caller based on the open point interface protocol, the open point logic implementation class is loaded into the target virtual machine; wherein, the open point interface protocol is pre-set for the interface.

3. The interface mapping system as described in claim 2, characterized in that, The open point interface protocol includes a caller identification method, and at least one of the following: sorting rule method, callback interface method, business logic method, and extension method.

4. The interface mapping system as described in any one of claims 1-3, characterized in that, It also includes a call request statistics module, for at least one of the following: If the target caller identifier exists in a preset first caller list, or does not exist in a preset second caller list, the call request is intercepted; If the number of call requests issued by the target caller exceeds a preset threshold, the call requests will be intercepted, or a preset alarm strategy will be triggered. The target caller is authenticated, and the call request is intercepted if authentication fails.

5. A business processing system, characterized in that, include: Business processing equipment and interface mapping system; among which, The interface mapping system receives a call request from the target caller, parses the target caller identifier, method name, and version number from the call request, determines the business system interface information corresponding to the method name and version number based on the pre-entered interface details, generates a business request based on the target caller identifier and the business system interface information, and initiates the business request to the business processing device. The business processing device determines the target caller identifier, the fully qualified name of the interface, and the request parameters based on the received business request. It then determines whether the open point logic implementation class corresponding to the fully qualified name of the interface is loaded in the target virtual machine corresponding to the target caller identifier. If the open point logic implementation class corresponding to the fully qualified name of the interface is loaded in the target virtual machine, the device executes the open point logic implementation class in the target virtual machine according to the request parameters to generate a response result corresponding to the business request. The business processing device returns the response result to the interface mapping system, and the interface mapping system returns the response result to the target caller.

Citation Information

Patent Citations

  • Method and device for processing call request

    CN113448679A