Enumeration data conversion method, device, equipment and storage medium

Abstract

The application belongs to the technical field of data processing, and discloses a conversion method, device and equipment of enumeration data and a storage medium. The method comprises the following steps: intercepting response data generated by a backend server; searching for a predefined annotation associated with the response data, analyzing a configuration code defined in the predefined annotation and a code field to be converted; obtaining context information of a current request corresponding to the response data; extracting a code value from the response data according to the code field; and converting the code value into a corresponding enumeration display value according to the configuration code, the code value and a type identifier of a calling end, so as to obtain converted response data. The application can be applied to a business management system such as financial technology and medical health, and solves the technical problem that a business personnel cannot independently complete the addition and adjustment of enumeration mapping relations without modifying the code and redeploying the service.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology and is applied in the fields of financial technology and healthcare. In particular, it relates to a method, apparatus, device and storage medium for converting enumerated data. Background Technology

[0002] In the field of enumeration data transformation, although annotation-based and Aspect-Oriented Programming (AOP)-based dictionary escaping solutions have achieved initial decoupling between transformation logic and business code, these solutions still face a fundamental dilemma in practical applications: business personnel cannot independently add and adjust enumeration mapping relationships without modifying code or redeploying services.

[0003] Specifically, in the existing solution, when business users need to add a new enumeration type, developers must define a new enumeration class in the code or insert a new record into a fixed dictionary table, and write or adjust the corresponding query logic. When business users need to modify the display value corresponding to a certain enumeration code, developers must modify the enumeration class definition or update the record in the dictionary table, and recompile and deploy the service. This rigid process, where "any enumeration change must be handled by developers and redeployed," strongly binds the adjustment cycle of enumeration mapping to the software release cycle.

[0004] Taking the financial insurance business scenario as an example, the claims review process may require different status descriptions at different stages. For instance, at one stage, the claims status "2" needs to be displayed as "Approved"; while at another stage, the business department wants it to be displayed as "Case Closed" to more accurately reflect the actual meaning of the status. In the existing solution, even a simple adjustment to the display wording requires developers to modify code or dictionary tables and redeploy the service, which cannot be done in real time by business personnel through the configuration interface. In addition, when the insurance product line expands, a large number of new policy type enumerations need to be added. Each new enumeration type requires developers to write new query logic, which greatly extends the business launch cycle.

[0005] Taking the healthcare business scenario as an example, drug approval status may change due to policy adjustments, and hospitals may need to update all displayed approval status values ​​within a short period of time. In existing solutions, such changes must wait for developers to modify code, complete testing, and deploy, a process that takes several days or even weeks, failing to meet the business's need for rapid response. Furthermore, different departments or different drug types may require different sets of approval status enumerations. When it's necessary to establish approval status mappings for new drug types, developers must rewrite the query logic, making it difficult to achieve flexible expansion across business lines and data sources.

[0006] The root of the aforementioned dilemma lies in the fact that, in existing technical solutions, once the enumeration mapping configuration is set, any changes require code modification and redeployment to take effect. There is a lack of a mechanism that allows mapping configurations to take effect in real-time without code changes. However, simply storing the mapping relationship in a database table does not solve the problem, because in existing solutions, which data table to query, which field to query, and which field to use as the matching condition are all hardcoded in the code. When business users need to retrieve enumeration mapping data from different data tables, developers still need to modify the code. Summary of the Invention

[0007] This invention provides a method, apparatus, device, and storage medium for converting enumeration data, which can solve the technical problem that business personnel cannot independently complete the addition and adjustment of enumeration mapping relationships without modifying code or redeploying services.

[0008] In a first aspect, the present invention provides a method for converting enumerated data, comprising: Intercepting response data generated by the backend server; Locate the predefined annotations associated with the response data, and parse the configuration codes and code fields to be converted defined in the predefined annotations; Obtain the context information of the current request corresponding to the response data, wherein the context information includes the type identifier of the calling end; Extract the code value from the response data based on the code field; Based on the configuration code, the code value, and the type identifier of the calling end, the code value is converted into the corresponding enumeration display value to obtain the converted response data.

[0009] Secondly, the present invention provides a device for converting enumerated data, comprising: The data interception module is used to intercept response data generated by the backend server; The data parsing module is used to find the predefined annotations associated with the response data, and parse the configuration codes and code fields to be converted defined in the predefined annotations; The information acquisition module is used to acquire the context information of the current request corresponding to the response data, wherein the context information includes the type identifier of the calling end; The code extraction module is used to extract code values ​​from the response data based on the code field; The data conversion module is used to convert the code value into the corresponding enumeration display value according to the configuration code, the code value and the type identifier of the calling end, so as to obtain the converted response data.

[0010] 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 enumeration data conversion method.

[0011] 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 enumeration data conversion method.

[0012] It is understood that this invention explicitly defines the technical feature of parsing the configuration code defined in the predefined annotation. The configuration code is a configuration identifier independent of the business code; it does not point to any specific enumeration class, dictionary, or hard-coded mapping relationship, but rather serves as an abstract configuration index. In practice, the complete enumeration mapping configuration corresponding to the configuration code can be stored independently in a configuration database, configuration file, or configuration center, completely decoupled from the business code. Because the mapping configuration is uniformly managed and referenced through the configuration code, when business personnel need to add an enumeration type or modify the display value corresponding to a certain enumeration code, they only need to modify the mapping configuration content corresponding to the configuration code on the configuration side, without touching any business code. The predefined annotation only stores the configuration code as a reference identifier, not the specific mapping data, which makes changes to the mapping data no longer dependent on code modification and redeployment.

[0013] This invention defines the context information for obtaining the current request corresponding to the response data. This context information includes a type identifier for the calling terminal and a method to convert the code value into a corresponding enumeration display value based on the configuration code, the code value, and the type identifier of the calling terminal. The type identifier is a dynamically obtained request-level parameter, not a fixed constant predefined in the code. This means that for the same configuration code and the same code value, the system can return different enumeration display values ​​based on the terminal type of the current request, without needing to write different conversion logic or develop different interfaces for each terminal type. Business personnel only need to configure different display values ​​for different terminal types under the same configuration code on the configuration side to achieve differentiated display across multiple terminals.

[0014] This invention defines a predefined annotation for finding the associated response data, and parses the configuration codes and code fields to be converted defined in the predefined annotation. The predefined annotations declaratively mark which response data needs to be converted and which set of configuration codes to use for the conversion. The specific conversion logic is executed uniformly, and no enumeration-related statements or utility class call code need to be written in the business code. Therefore, business personnel can adjust the enumerated display values ​​without touching the business code.

[0015] This invention defines the interception of response data generated by the backend server and the conversion of the code value into the corresponding enumeration display value to obtain the converted response data. The interception and conversion are performed uniformly before the response data is returned to the frontend, and all enumeration conversions undergo the same processing logic, eliminating the need for multiple sets of conversion logic maintained separately. When the enumeration display value changes, only the configuration needs to be modified, without requiring individual code modifications.

[0016] In summary, the technical solution of this invention addresses the technical problem that business users cannot independently add or adjust enumeration mapping relationships without modifying code or redeploying services when they need to add enumeration types or modify enumeration display values. This is achieved by introducing an abstract configuration reference (configuration code) into predefined annotations, introducing type identifiers at the calling end to achieve multi-terminal differentiation, using declarative annotations to achieve zero intrusion into business code, and using interceptors to achieve unified processing of conversion logic. When business users need to add enumeration types or modify enumeration display values, they only need to adjust the mapping content corresponding to the configuration code on the configuration side. This allows for real-time application of the enumeration mapping configuration without modifying business code, recompiling and packaging, or restarting the service. Attached Figure Description

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

[0018] Figure 1 This is a flowchart illustrating a method for converting enumerated data in one embodiment of the present invention.

[0019] Figure 2 yes Figure 1 A flowchart of step S150.

[0020] Figure 3 yes Figure 2 A flowchart of step S153.

[0021] Figure 4 This is a schematic diagram of a data conversion device for enumeration in one embodiment of the present invention.

[0022] Figure 5 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention.

[0023] Figure 6 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0024] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0025] Figure 1 A flowchart of the enumeration data conversion method provided in the embodiments of the present invention is shown below. Figure 1 As shown, the method for converting enumerated data provided in this embodiment of the invention includes the following steps.

[0026] Step S110: Intercept the response data generated by the backend server; In some possible implementations, after completing business logic processing, the backend server generates response data for the frontend request, which contains the original enumeration code. An interception point can be set in the backend server's data response chain to intercept the response data before it is returned to the frontend. This interception point can be implemented using AOP technology, or it can be based on filters or interceptors; this application does not limit its implementation in this regard.

[0027] In some examples, within financial insurance scenarios, a user submits a claim application through a front-end application. The back-end server processes the claim and generates response data, which includes a claim status field. The value of this field is a raw enumeration code representing different statuses, such as "1" or "2". However, the front-end application needs to display the corresponding Chinese status values, such as "Pending Review," "Approved," or "Rejected." In this case, the response data can be intercepted before it is returned to the front-end.

[0028] In some examples, a user queries the renewal information of a policy through a front-end application. The back-end server generates response data containing a payment status field, whose value is a primitive enumeration code such as "0" or "1". However, the front-end application needs to display the corresponding Chinese status value such as "not paid" or "paid". In this case, the response data can also be intercepted before it is returned to the front-end.

[0029] In some examples, such as in healthcare scenarios, users book appointments through a front-end application. The back-end server processes the appointment request and generates response data, which includes an appointment status field. The value of this field is a raw enumeration code representing different statuses, such as "0", "1", and "2". However, the front-end application needs to display the corresponding Chinese status values, such as "Pending Confirmation", "Confirmed", and "Cancelled". In this case, the response data can be intercepted before it is returned to the front-end.

[0030] Step S120: Locate the predefined annotation associated with the response data, and parse the configuration code and code field to be converted defined in the predefined annotation; In some possible implementations, predefined annotations can be placed on Application Programming Interface (API) methods, on the return objects of the corresponding API methods, or declared through configuration files or external registry entries. These predefined annotations define configuration codes and code fields to be converted. After intercepting response data, the predefined annotations associated with the response data can be searched based on the API method or return object corresponding to the response data. If found, the predefined annotation is further parsed to obtain the defined configuration codes and code fields to be converted. It is understood that these predefined annotations are used to mark interfaces or objects that require enumeration data conversion; the configuration codes uniquely identify a set of enumeration mapping configurations; and the code fields to be converted indicate one or more fields in the response data that need to be converted.

[0031] In some examples, within financial insurance scenarios, the backend server generates response data in response to a claim application. This response data corresponds to a claim review interface, and the methods of this interface are marked with predefined annotations. After intercepting this response data, the annotation information of the method is obtained through reflection, and the configuration code "CLAIM_STATUS_CONFIG" and the code field "status" to be converted are parsed. This configuration code is used to find the corresponding mapping configuration in subsequent steps, and the "status" field indicates that the value of this field needs to be enumerated and converted.

[0032] In some examples, the backend server generates response data in response to a renewal query. This response data corresponds to a policy query interface, and the returned object of this interface is marked with predefined annotations. After intercepting this response data, the annotation information on the returned object is obtained and parsed to obtain the configuration code "PAYMENT_STATUS_CONFIG" and the code field "payStatus" to be converted. This configuration code is used to find the corresponding mapping configuration in subsequent steps, and the "payStatus" field indicates that the value of this field needs to be enumerated and converted.

[0033] In some examples, within a healthcare scenario, the backend server generates response data in response to appointment registration. This response data corresponds to an appointment management interface, and the methods of this interface are marked with predefined annotations. After intercepting this response data, the annotation information of the method is obtained through reflection, and the configuration code "APPOINTMENT_STATUS_CONFIG" and the code field "apptStatus" to be converted are parsed. This configuration code is used to find the corresponding mapping configuration in subsequent steps, and the "apptStatus" field indicates that the value of this field needs to be enumerated and converted.

[0034] In some embodiments of the present invention, the step of finding the predefined annotation associated with the response data includes: Step S121: Obtain the API interface method corresponding to the response data, and search for the predefined annotations marked on the API interface method; In some possible implementations, after intercepting response data, the corresponding API interface method can be obtained, and the presence of predefined annotations can be checked on that API interface method. An API interface method refers to an API method in the backend server used to process frontend requests and generate response data, such as a specific method in a controller class. It is understood that the currently executing API interface method object can be obtained through AOP pointcuts or interceptor handlers, and all annotations declared on that method can be retrieved to check for predefined annotations. It is understood that predefined annotations can be placed on API interface methods, on the class of API interface methods, or on the parameters of API interface methods; this application does not limit the specific location of the predefined annotations on the method.

[0035] In some possible implementations, checking whether an API interface method is marked with a predefined annotation can be achieved using Java reflection. Specifically, the corresponding method can be called through the method object, passing in the type of the predefined annotation. If a non-null return value, it indicates that the API interface method is marked with a predefined annotation; otherwise, it indicates that it is not marked. It is understood that the search scope can include the API interface method itself, as well as the class containing the API interface method and its parent classes; this application does not limit this.

[0036] In some examples, a claims review interface exists in a financial insurance business system, with the corresponding API method being "ClaimController.submitClaim()". After intercepting the response data of this method through AOP aspects, the currently executing API method object "submitClaim" is obtained, and the method's getDeclaredAnnotation(DictionaryMapping.class) is called to check if it is marked with the predefined annotation @DictionaryMapping. After finding the annotation, the configuration code "CLAIM_STATUS_CONFIG" defined in the annotation and the code field "status" to be converted are parsed.

[0037] In some examples, the financial insurance business system adds a policy query interface, with the corresponding API method "PolicyController.queryPolicy()". This method does not have any predefined annotations, but in subsequent step S122, it may still be able to find the predefined annotations by returning an object. Understandably, if no predefined annotation is found in step S121, step S122 is executed to continue the search.

[0038] Step S122, or, obtain the return object corresponding to the response data, and search for the predefined annotation marked on the return object.

[0039] In some possible implementations, besides searching for predefined annotations on API interface methods, predefined annotations can also be searched on the returned object corresponding to the response data. The returned object refers to the data object returned by the API interface method, i.e., the class definition corresponding to the response data generated by the backend server. For example, a query interface returns a "Result" object, and this "Result" class can be marked with predefined annotations. It is understood that when a predefined annotation is marked on the returned object, it indicates that all fields in the returned object that require enumeration conversion will be uniformly converted. It is also understood that the class definition of the returned object can be obtained through the return type of the API interface method (i.e., the return value type in the method declaration), and then the Java reflection mechanism can be used to find whether the class and its fields, methods, or class level are marked with predefined annotations.

[0040] In some possible implementations, when marking a predefined annotation on the returned object, it can be done at the class level (i.e., on the class declaration) or at the field level (i.e., on the field declaration), and this application does not limit this. When the annotation is at the class level of the returned object, it indicates that the specified field in the returned object is being enumerated; when the annotation is at the field level of the returned object, it indicates that only that field is being enumerated. It is understood that "finding the predefined annotation marked on the returned object" in this step covers any one or more of the above marking positions.

[0041] In some examples, a financial insurance business system has a policy query interface whose API method "PolicyController.queryPolicyDetail()" is not marked with a predefined annotation, but the class definition of its returned object "PolicyDetailResponse" is marked with a predefined annotation. By obtaining the class definition "PolicyDetailResponse.class" of the returned object, the `getDeclaredAnnotation(DictionaryMapping.class)` method of that class is called to check whether there is a predefined annotation at the class level. After finding the annotation, the configuration code "POLICY_TYPE_CONFIG" and the code field "policyType" to be converted are parsed from the annotation.

[0042] In some examples, a healthcare business system has an appointment booking query interface. While the API method itself doesn't have predefined annotations, the class definition of the returned object "AppointmentResponse" does. By retrieving the class definition "AppointmentResponse.class", the `getDeclaredAnnotation(DictionaryMapping.class)` method is called to check if a predefined annotation is present at the class level. Once the annotation is found, the configuration code "APPOINTMENT_STATUS_CONFIG" and the code field "apptStatus" to be converted are parsed from the annotation.

[0043] It is understood that steps S121 and S122 are two parallel optional implementations. In practical applications, only step S121 (i.e., marking the API interface method with predefined annotations) or only step S122 (i.e., marking the returned object with predefined annotations) can be used, or both methods can be supported simultaneously. When both methods are supported simultaneously, the search priority order can be preset, for example, prioritizing the search for predefined annotations on the API interface method, and if not found, continuing to search for predefined annotations on the returned object; or prioritizing the search for predefined annotations on the returned object, and if not found, continuing to search for predefined annotations on the API interface method. It is understood that the specific priority order can be determined according to actual business needs, and this application does not limit it in this regard.

[0044] It is understood that this embodiment obtains the API interface method corresponding to the response data and searches for predefined annotations on that method, or obtains the return object corresponding to the response data and searches for predefined annotations on that return object. This method has the following advantages: First, it provides two flexible annotation marking carriers, which can be marked on either API interface methods or return objects. Developers can choose the most convenient marking method according to their actual business scenarios, improving the usability and flexibility of the method. Second, when marking on API interface methods, different enumeration conversion rules can be configured for different API interfaces, achieving fine-grained control at the interface level. Different interfaces can be configured with their own conversion rules independently without affecting each other. Third, when marking on return objects, unified configuration of the return objects can be achieved. When multiple API interfaces return the same object type, only one predefined annotation needs to be marked on the class of the return object to apply to multiple interfaces simultaneously, avoiding redundant configuration and reducing maintenance costs. Fourth, the two methods complement each other, enabling this method to adapt to different code structure designs. It supports both interface-oriented and object-oriented configuration methods, expanding the applicability of the method.

[0045] Step S130: Obtain the context information of the current request corresponding to the response data, wherein the context information includes the type identifier of the calling end; In some possible implementations, the current request corresponding to the response data can be obtained, and thus the context information of that current request can be acquired. The context information of the current request may include information from the HTTP (Hypertext Transfer Protocol) request header, session information, etc. This context information includes a type identifier for the calling end, which characterizes the type of terminal initiating the current request, such as a computer (PC), mobile application, or tablet. Different terminal types may need to see different enumeration display values, therefore this type identifier is needed as a basis for subsequent conversion. It is understood that the type identifier for the calling end can be actively added to the request header by the client when initiating the request, or it can be automatically added by the gateway or middleware based on client characteristics.

[0046] In some examples, within financial insurance scenarios, users submit claims applications via mobile applications, with the "App-Type: APP" field in the request header. By obtaining the context information of this request, the type identifier of the calling end, "APP," is extracted, indicating that the current request originates from a mobile application.

[0047] In some examples, a user queries policy renewal information through a PC browser. The request header carries "User-Agent" information, which identifies the client type as "PC". The context information of the request is obtained, and the client type identifier "PC" is extracted, indicating that the current request originates from a personal computer. Alternatively, the request header can also include a custom field "Client-Type:PC".

[0048] In some examples, within a healthcare scenario, users make appointments through a mobile application, with the request header containing the "App-Type: APP" field. By retrieving the context information of this request, the type identifier of the calling end, "APP," is extracted, indicating that the current request originates from a mobile application.

[0049] In some embodiments of the present invention, step S130 includes the following steps.

[0050] Step S131: Obtain the current request corresponding to the response data; In some possible implementations, after intercepting the response data generated by the backend server, the current request corresponding to that response data can be obtained. It is understood that when the backend server processes business logic, each response data corresponds to a request, which contains various types of information sent by the client. In AOP or interceptor interception processing, the request object bound to the current thread can be obtained through the API provided by the framework. It is understood that the method of obtaining the current request depends on the specific technology framework, and this application does not limit it.

[0051] In some examples, in financial insurance scenarios, after intercepting the response data of the claims application interface in the framework via AOP, the HttpServletRequest object of the current request is obtained through RequestContextHolder.getRequestAttributes(), which corresponds to the current request sent by the client when submitting the claims application.

[0052] In some examples, in healthcare scenarios, after intercepting the response data of the drug query interface in the framework, the HttpServletRequest object of the current request is obtained through RequestContextHolder.getRequestAttributes(). This object corresponds to the current request sent by the client when querying drug information.

[0053] Step S132: Extract the context information from the protocol header information of the current request; In some possible implementations, after obtaining the current request, context information can be extracted from the request's header information. The header information (e.g., the HTTP header) contains various metadata fields carried by the client when sending the request, such as user agent, acceptance type, and custom header fields. The client can add the caller's type identifier to a custom field in the header (e.g., the "App-Type" field) when initiating the request, or the gateway or middleware can automatically add this field to the header based on client characteristics. During interception processing, the value of this field is read from the header information to obtain the caller's type identifier from the context information. It is understood that the caller's type identifier is used to characterize the type of terminal initiating the current request, such as a PC, mobile app, or tablet.

[0054] In some examples, in financial insurance scenarios, when a client initiates a claim request, it adds a custom field "App-Type: APP" to the HTTP request header. The request header information is retrieved from the HttpServletRequest object of the current request, and the value of this custom field is read by calling request.getHeader("App-Type"), extracting the caller type identifier "APP" from the context information, indicating that the current request originates from a mobile application.

[0055] In some examples, such as in healthcare scenarios, when a client initiates a policy inquiry request, it adds a custom field "Client-Type: PC" to the HTTP request header. The request header information is retrieved from the current request's HttpServletRequest object, and the value of this custom field is read by calling request.getHeader("Client-Type"), extracting the caller type identifier "PC" from the context information, indicating that the current request originates from a personal computer.

[0056] Step S133, or, extract the context information from the session information of the current request; The caller type identifier included in the context information is used to characterize the terminal type that initiated the current request.

[0057] In some possible implementations, in addition to extracting context information from the protocol header, context information can also be extracted from the session information of the current request. Session information is context data saved during the session between the client and the server, and may include user information, device information, etc., stored in the session attributes. Upon the client's first access, the login or authentication interface can store the session-related caller type identifier in the session. During subsequent request processing, this type identifier can be read from the session. It is understood that extracting context information from the protocol header and extracting context information from the session information are two optional implementation methods. In practical applications, one method or both methods can be selected depending on the specific scenario; this application does not impose any limitations on this.

[0058] In some examples, within the financial insurance scenario, when a user logs into an app, the login interface saves the user's terminal type, "APP," into the session. Subsequently, when the user initiates a claim application through the same session, the interface retrieves the session corresponding to the current request, reads the calling terminal type identifier from the session, and extracts "APP," indicating that the current request originated from a mobile application.

[0059] In some examples, within healthcare scenarios, when a user logs into a healthcare platform, the login interface saves the user's terminal type, "PC," into the session. Subsequently, when the user queries the drug approval status through the same session, the system retrieves the session corresponding to the current request, reads the calling terminal type identifier from the session, and extracts "PC," indicating that the current request originated from a personal computer.

[0060] The caller type identifier included in the context information is used to characterize the terminal type that initiated the current request.

[0061] It is understandable that, regardless of whether the context information is extracted from the protocol header or the session information, the obtained context information includes a type identifier for the calling end. This type identifier is used to characterize the terminal type that initiated the current request. Different types of terminals (e.g., PC, application, tablet) may correspond to different display requirements. This type identifier allows the same enumeration code to be converted into different enumeration display values ​​on different terminal types. It is understandable that, in practical applications, context information can be extracted primarily from the protocol header; if the caller type identifier is not present in the protocol header, it can be extracted from the session information; alternatively, both methods can be supported simultaneously, with the priority order specified by the developer in the configuration. This application does not impose any limitations on this approach.

[0062] It is understood that this embodiment obtains the current request corresponding to the response data and extracts context information from the protocol header or session information of the current request. The caller type identifier contained in the context information is used to characterize the terminal type that initiated the current request. This method has the following beneficial effects: First, by extracting context information from the protocol header of the current request, the caller type identifier can be easily obtained. The protocol header information can be carried in each request, making the acquisition method simple and efficient, and suitable for stateless request scenarios. Second, by extracting context information from the session information of the current request, the user device and type information already stored in the session can be reused, without the client having to carry it repeatedly in each request, making it suitable for scenarios that require maintaining user state. Third, the protocol header extraction and session extraction methods complement each other, allowing the selection of an appropriate extraction method based on different business scenarios and technical architectures, thus improving the flexibility and applicability of the method. Fourth, the caller type identifier in the context information provides terminal type dimension input for subsequent enumeration data conversion, enabling the conversion logic to perform differentiated processing according to different terminal types, thereby meeting the business requirements of multi-terminal adaptation.

[0063] Step S140: Extract the code value from the response data according to the code field; In some possible implementations, based on the code field to be converted obtained in step S120, the corresponding field value is extracted from the intercepted response data and used as the code value. When the code field is a single field, the value of that field is extracted directly; when the code field consists of multiple fields, a combination of the values ​​of the multiple fields can be extracted as the code value. This code value is the original enumeration code, which needs to be converted into the corresponding enumeration display value later.

[0064] In some examples, the response data is in JSON (JavaScript Object Notation) format, with the code field "status". The value "1" in the "status" field is extracted from this response data and used as the code value. This code value "1" represents the original enumeration code to be converted, which will later be converted to its corresponding Chinese display value.

[0065] In some examples, the response data is in JSON format with a code field named "payStatus". The value "0" in the "payStatus" field is extracted and used as the code value. This code value "0" represents the original enumeration code for no payment, which needs to be converted to the corresponding Chinese display value later.

[0066] In some examples, the response data is in JSON format with a code field named "apptStatus". The value "0" in the "apptStatus" field is extracted from this response data and used as the code value. This code value "0" indicates the original enumeration code to be confirmed, which will later need to be converted to its corresponding Chinese display value.

[0067] Step S150: Based on the configuration code, the code value, and the type identifier of the calling end, the code value is converted into the corresponding enumeration display value to obtain the converted response data.

[0068] In some possible implementations, the configuration code, code value, and caller type identifier are used as the conversion criteria to convert the code value into the corresponding enumeration display value. The configuration code determines which set of enumeration mapping configurations to use; the code value determines the specific enumeration item to be converted; and the caller type identifier adapts to different display values ​​that may be required for different terminal types. After the conversion, the original code value in the response data is replaced with the corresponding enumeration display value, thus obtaining the converted response data. This converted response data can be returned to the front-end application for display or used for other scenarios such as data export.

[0069] In some examples, within the financial insurance scenario, the configuration code is "CLAIM_STATUS_CONFIG", the code value is "1", and the type identifier is "APP". The corresponding mapping configuration is found based on the configuration code. This mapping configuration indicates that on the APP side, the display value corresponding to code "1" is "Pending Review". The value of the "status" field in the response data is replaced with "Pending Review" to obtain the transformed response data. After this transformed response data is returned to the application (APP), the APP directly displays "Pending Review" instead of "1".

[0070] In some examples, within a healthcare scenario, the configuration code is "PAYMENT_STATUS_CONFIG", the code value is "0", and the type identifier is "PC". The corresponding mapping configuration is found based on the configuration code, indicating that on the PC, the display value corresponding to code "0" is "Unpaid". The value of the "payStatus" field in the response data is replaced with "Unpaid" to obtain the converted response data. When this converted response data is returned to the PC, the PC directly displays "Unpaid" instead of "0".

[0071] In some examples, the configuration code is "APPOINTMENT_STATUS_CONFIG", the code value is "0", and the type identifier is "APP". The corresponding mapping configuration is found based on the configuration code. This mapping configuration indicates that on the APP side, the display value corresponding to code "0" is "Pending Confirmation". The value of the "apptStatus" field in the response data is replaced with "Pending Confirmation" to obtain the converted response data. After this converted response data is returned to the APP side, the APP side directly displays "Pending Confirmation" instead of "0".

[0072] It is understood that the technical feature of parsing the configuration code defined in the predefined annotation is explicitly defined in this embodiment of the invention. The configuration code is a configuration identifier independent of the business code; it does not point to any specific enumeration class, dictionary, or hard-coded mapping relationship, but rather serves as an abstract configuration index. In actual implementation, the complete enumeration mapping configuration corresponding to the configuration code can be stored independently in a configuration database, configuration file, or configuration center, completely decoupled from the business code. Because the mapping configuration is uniformly managed and referenced through the configuration code, when business personnel need to add an enumeration type or modify the display value corresponding to a certain enumeration code, they only need to modify the mapping configuration content corresponding to the configuration code on the configuration side, without touching any business code. The predefined annotation only stores the configuration code as a reference identifier, not the specific mapping data, which makes changes to the mapping data no longer dependent on code modification and redeployment.

[0073] In this embodiment of the invention, the context information for obtaining the current request corresponding to the response data is defined. This context information includes a type identifier for the calling end and a method for converting the code value into a corresponding enumeration display value based on the configuration code, the code value, and the type identifier of the calling end. The type identifier is a dynamically obtained request-level parameter, rather than a fixed constant predefined in the code. This means that for the same configuration code and the same code value, the system can return different enumeration display values ​​based on the terminal type of the current request, without needing to write different conversion logic or develop different interfaces for each terminal type. Business personnel only need to configure different display values ​​for different terminal types under the same configuration code on the configuration end to achieve differentiated display across multiple terminals.

[0074] This invention specifies that the predefined annotations associated with the response data are searched, and the configuration codes and code fields to be converted defined in the predefined annotations are parsed. The predefined annotations declaratively mark which response data needs to be converted and which set of configuration codes to use for the conversion. The specific conversion logic is executed uniformly, and no enumeration conversion-related statements or utility class call code need to be written in the business code. Therefore, business personnel do not need to touch the business code to adjust the enumerated display values.

[0075] This invention defines the interception of response data generated by the backend server and the conversion of the code value into the corresponding enumeration display value to obtain the converted response data. The interception and conversion are performed uniformly before the response data is returned to the frontend, and all enumeration conversions undergo the same processing logic, eliminating the need for multiple sets of conversion logic maintained separately. When the enumeration display value changes, only the configuration needs to be modified, without requiring individual code modifications.

[0076] In summary, the technical solution of this invention addresses the problem that business users cannot independently add or adjust enumeration mapping relationships without modifying code or redeploying services when they need to add enumeration types or modify enumeration display values. This is achieved by introducing an abstract configuration reference (configuration code) into predefined annotations, introducing type identifiers at the calling end to achieve multi-terminal differentiation, using declarative annotations to achieve zero intrusion into business code, and using interceptors to achieve unified processing of conversion logic. When business users need to add enumeration types or modify enumeration display values, they only need to adjust the mapping content corresponding to the configuration code on the configuration side. This allows for real-time application of the enumeration mapping configuration without modifying business code, recompiling and packaging, or restarting the service.

[0077] In some embodiments of the present invention, such as Figure 2 As shown, step S150 includes the following steps.

[0078] Step S151: Obtain the mapping configuration information corresponding to the configuration code according to the configuration code, wherein the mapping configuration information includes a configuration type identifier; In some possible implementations, after parsing the configuration code in step S120, the corresponding mapping configuration information can be retrieved from the configuration database or configuration file based on the configuration code. This mapping configuration information describes how to convert enumeration code values ​​into corresponding enumeration display values, and includes a configuration type identifier, which indicates the configuration type of the mapping configuration information. It is understood that different configuration types correspond to different mapping retrieval methods. For example, when the configuration type identifier is the first identifier, it indicates that the mapping configuration information is a fixed mapping configuration, meaning the mapping relationship between the code value and the enumeration display value is pre-configured and can be directly retrieved from the cache; when the configuration type identifier is the second identifier, it indicates that the mapping configuration information is a dynamic mapping configuration, meaning the mapping relationship between the code value and the enumeration display value needs to be retrieved by dynamically generating a query statement based on the configuration table metadata. It is understood that the mapping configuration information can be stored in a relational database, a non-relational database, or in the form of a configuration file; this application does not limit this.

[0079] In some examples, within the financial insurance scenario, the configuration code is "CLAIM_STATUS_CONFIG". Based on this code, the corresponding mapping configuration information is retrieved from the configuration database. The configuration type identifier in this mapping configuration information is the first identifier, indicating that this is a fixed mapping configuration. This fixed mapping configuration stores a fixed correspondence between all code values ​​and Chinese display values ​​for the claim status.

[0080] In some examples, the configuration code is "PAYMENT_STATUS_CONFIG". Based on this configuration code, the corresponding mapping configuration information is retrieved from the configuration database. The configuration type identifier in this mapping configuration information is the second identifier, indicating that this mapping configuration is a dynamic mapping configuration. This dynamic mapping configuration stores the relevant metadata information of the data table corresponding to the payment status mapping.

[0081] In some examples, within a healthcare scenario, the configuration code is "DRUG_APPROVAL_CONFIG". Based on this code, the corresponding mapping configuration information is retrieved from the configuration database. The configuration type identifier in this mapping configuration information is the second identifier, indicating that the mapping configuration is dynamic. This dynamic mapping configuration stores metadata information related to the data table corresponding to the drug approval status mapping.

[0082] Step S152: When the configuration type identifier is the first identifier, retrieve the enumeration display value that matches the configuration code, the code value, and the type identifier from the cache; In some possible implementations, when the configuration type identifier is the first identifier, it indicates that the mapping configuration is a fixed mapping configuration, meaning the mapping relationship between the code value and the enumeration display value is pre-configured and can be directly queried from the cache. In this case, the configuration code, code value, and the caller's type identifier are used as the joint query key to retrieve the corresponding enumeration display value from the cache. It is understood that the cache can be implemented using in-memory caching (such as Caffeine, GuavaCache, etc.) or distributed caching (such as Redis, etc.), and this application does not limit this. It is understood that using caching for querying can improve data retrieval efficiency and avoid querying the database for each transformation. It is understood that different types of mapping relationships can be stored in the cache in the form of key-value pairs, where the key can be composed of the configuration code, code value, and type identifier, and the value is the corresponding enumeration display value.

[0083] In some examples, within the financial insurance scenario, the configuration code is "CLAIM_STATUS_CONFIG", the configuration type identifier is the first identifier, the code value is "1", and the type identifier is "APP". Using "CLAIM_STATUS_CONFIG_1_APP" as the cache key, a query in the memory cache retrieves the corresponding enumeration display value as "Pending Review", indicating that the display value corresponding to code "1" on the APP side is "Pending Review". This mapping relationship is pre-configured and does not require dynamic querying.

[0084] In some examples, the configuration code is "CLAIM_STATUS_CONFIG", the configuration type identifier is the first identifier, the code value is "2", and the type identifier is "PC". Using "CLAIM_STATUS_CONFIG_2_PC" as the cache key, the corresponding enumeration display value retrieved from the memory cache is "Approved", indicating that the display value corresponding to code "2" on the PC side is "Approved".

[0085] In some examples, within a healthcare scenario, the configuration code is "MED_ORDER_STATUS_CONFIG", the configuration type identifier is the first identifier, the code value is "0", and the type identifier is "APP". Using "MED_ORDER_STATUS_CONFIG_0_APP" as the cache key, a query in the memory cache retrieves the corresponding enumeration display value as "pending medication", indicating that on the APP side, the display value corresponding to code "0" is "pending medication".

[0086] Step S153: When the configuration type identifier is the second identifier, a query statement is generated according to the mapping configuration information, and the enumeration display value is obtained according to the query statement.

[0087] In some possible implementations, when the configuration type identifier is the second identifier, it indicates that the mapping configuration is a dynamic mapping configuration. This means the mapping relationship is not pre-stored and needs to be dynamically generated based on the mapping configuration information. Executing this query retrieves the corresponding enumeration display value from the target data table in real time. In this case, a query is generated based on the mapping configuration information, using the code value and type identifier as query conditions. Executing this query retrieves the corresponding enumeration display value. It is understood that the query can be a Structured Query Language (SQL) statement or a statement from another database query language; this application does not limit this. Dynamic mapping configuration is suitable for scenarios where enumeration display values ​​may change frequently, or where enumeration display values ​​are stored in business data tables and need to be retrieved through dynamic queries. This avoids modifying the cache or redeploying code every time the enumeration value changes, improving the system's flexibility and maintainability.

[0088] In some examples, within the financial insurance scenario, the configuration code is "PAYMENT_STATUS_CONFIG," the configuration type identifier is the second identifier, and the mapping configuration information includes the data table identifier "payment_config," the condition field "code," the query field "display_value," and the sorting field "sort_order." The code value is "0," and the type identifier is "PC." Based on the above mapping configuration information, an SQL query is generated: `SELECT display_value FROM payment_config WHERE code='0' AND app_type='PC' ORDER BY sort_order`. Executing this query retrieves the enumerated display value "Not paid" from the payment configuration table. In this example, the displayed value of the payment status is stored in the business data table and retrieved in real-time through dynamic SQL queries.

[0089] In some examples, the configuration code is "POLICY_TYPE_CONFIG", the configuration type identifier is the second identifier, and the mapping configuration information includes the data table identifier "policy_type_dict", the condition field "type_code", and the query field "type_name". The code value is "01", and the type identifier is "APP". Based on the above mapping configuration information, the following SQL query is generated: SELECT type_name FROM policy_type_dict WHERE type_code='01' AND app_type='APP'. Executing this query statement retrieves the enumerated value "critical illness insurance" from the policy type dictionary table.

[0090] In some examples, within a healthcare scenario, the configuration code is "DRUG_APPROVAL_CONFIG," the configuration type identifier is the second identifier, and the mapping configuration information includes the data table identifier "drug_approval_dict," the condition field "approval_code," and the query field "approval_name." The code value is "A01," and the type identifier is "APP." Based on the above mapping configuration information, an SQL query is generated: SELECT approval_name FROM drug_approval_dict WHERE approval_code='A01' AND app_type ='APP'. Executing this query retrieves an enumerated value of "Approved" from the drug approval dictionary table.

[0091] It is understood that this embodiment obtains the corresponding mapping configuration information through configuration encoding. This mapping configuration information includes a configuration type identifier. When the configuration type identifier is the first identifier, the enumeration display value is retrieved from the cache. When the configuration type identifier is the second identifier, a query statement is dynamically generated and executed to obtain the enumeration display value. This method has the following beneficial effects: First, by distinguishing different mapping retrieval methods through the configuration type identifier, it supports both fast cache queries for fixed mappings and flexible configuration queries for dynamic mappings, balancing conversion efficiency and configuration flexibility. Second, for mapping configurations of the first identifier type, the configuration encoding, code value, and type identifier are used together as the cache key for querying, fully utilizing the high-performance characteristics of the cache and improving enumeration conversion efficiency. Third, for mapping configurations of the second identifier type, the query statement is dynamically generated based on the mapping configuration information, allowing the enumeration display value to be obtained from the business data table in real time, without needing to modify the code or update the cache every time the enumeration value changes, thus improving the maintainability and flexibility of the system. Fourth, the coexistence of two configuration types allows this method to adapt to different business scenarios. Fixed mapping is suitable for scenarios where the enumeration values ​​are relatively stable, while dynamic mapping is suitable for scenarios where the enumeration values ​​may change frequently, thus expanding the applicability of the method.

[0092] In some embodiments of the present invention, the mapping configuration information further includes a data table identifier and a condition field; such as Figure 3 As shown, step S153 includes the following steps.

[0093] Step S15311: Determine the target data table corresponding to the data table identifier based on the data table identifier; In some possible implementations, when the configuration type identifier is determined to be the second identifier in step S153, the mapping configuration information also includes a data table identifier. This data table identifier uniquely identifies the data table storing the enumeration mapping data; for example, it can be the name or number of the data table. Based on this data table identifier, the corresponding target data table can be determined from the database so that the enumeration display value can be queried from the target data table subsequently. It is understood that the data table identifier can be specified by business personnel or developers when configuring the mapping configuration information. Different configuration codes can correspond to different data tables, and different data tables can store different types of enumeration mapping data, thereby achieving flexible configuration under different business scenarios. It is understood that the target data table can be an existing data table in the business system or a dictionary table specifically created for enumeration mapping; this application does not limit this.

[0094] In some examples, within the financial insurance scenario, the configuration code is "PAYMENT_STATUS_CONFIG," and the data table identifier in the mapping configuration information is "payment_config." Based on this data table identifier, the target data table named "payment_config" is located in the database. This data table stores all enumerated mapping data for payment status, including fields such as code value, display value, and applicable terminal type.

[0095] In some examples, within a healthcare scenario, the configuration code is "DRUG_APPROVAL_CONFIG," and the data table identifier in the mapping configuration information is "drug_approval_dict." Based on this data table identifier, the target data table named "drug_approval_dict" is located in the database. This data table stores all enumerated mapping data for drug approval status, including fields such as code value, display value, and applicable terminal type.

[0096] Step S15312: Generate a query statement based on the target data table; The query target of the query statement is the query field in the target data table, and the query conditions of the query statement include: the condition field matches the code value, and the type identifier is used as the query parameter.

[0097] In some possible implementations, after determining the target data table, a query statement can be generated based on the query fields and condition fields in the mapping configuration information. The query target (i.e., the SELECT clause) of the query statement is a query field in the target data table, which indicates the column name storing the enumerated display value. The query condition (i.e., the WHERE clause) includes two conditions: first, the condition field in the target data table matches the code value; second, a type identifier is used as a query parameter, meaning the type identifier participates in the matching as an additional query condition. It is understood that both the query field and condition field are column names in the target data table, specified by business personnel or developers when configuring the mapping configuration information, thus enabling flexible generation of query statements without hard-coding SQL statements in the code. It is understood that the query statement can be implemented using Structured Query Language (SQL) or other database query languages.

[0098] In some examples, within a financial insurance scenario, the query field in the mapping configuration information is "display_value," and the condition field is "code." The target data table is "payment_config," the code value is "0," and the type identifier is "PC." The generated query statement is: SELECT display_value FROM payment_config WHERE code = '0' AND app_type = 'PC'. Executing this query statement retrieves the enumerated display value "Unpaid" corresponding to the payment status "0" on the PC side. This query statement targets the "display_value" field, and the query conditions are that the "code" field matches the code value "0" and the "app_type" field matches the type identifier "PC."

[0099] In some examples, the query field in the mapping configuration information is "type_name", and the condition field is "type_code". The target data table is "policy_type_dict", the code value is "01", and the type identifier is "APP". The generated query statement is: SELECT type_name FROM policy_type_dict WHERE type_code ='01' AND app_type = 'APP'. Executing this query statement can retrieve the enumerated display value "critical illness insurance" corresponding to the policy type code "01" on the APP side. The query statement's query target is the "type_name" field, and the query condition is that the "type_code" field matches the code value "01" and the "app_type" field matches the type identifier "APP".

[0100] In some examples, within a healthcare scenario, the query field in the mapping configuration information is "approval_name," and the condition field is "approval_code." The target data table is "drug_approval_dict," the code value is "A01," and the type identifier is "APP." The generated query is: SELECT approval_name FROM drug_approval_dict WHERE approval_code='A01' AND app_type='APP'. Executing this query retrieves the enumerated display value "Approved" corresponding to the drug approval status code "A01" on the APP. This query targets the "approval_name" field, and the query conditions are that the "approval_code" field matches the code value "A01" and the "app_type" field matches the type identifier "APP."

[0101] It is understood that this embodiment determines the target data table through the data table identifier in the mapping configuration information and generates a query statement based on the target data table. The query target is the query field in the target data table, and the query conditions are the matching of condition fields with code values ​​and the use of type identifiers as query parameters. This method has the following advantages: First, by dynamically determining the target data table through the data table identifier, the same conversion framework can support enumeration mapping queries on different data tables, achieving flexible configuration of the mapping data source. Second, by dynamically generating the SELECT and WHERE clauses of the query statement through the query fields and condition fields in the mapping configuration information, there is no need to pre-write SQL statements in the code, achieving zero-hard-coding generation of query statements. Third, the query conditions simultaneously include the matching conditions of condition fields and code values, as well as the type identifier as additional query parameters, enabling the query statement to return different enumeration display values ​​based on different code values ​​and different terminal types, achieving multi-dimensional accurate matching. Fourth, the entire logic for generating query statements is driven entirely by configuration information. Developers only need to configure the data table identifier, query fields, and condition fields to achieve dynamic querying of enumerated mapping data in different business data tables, which simplifies development work and improves the scalability and maintainability of the system.

[0102] In some embodiments of the present invention, the mapping configuration information further includes a data table identifier, the condition field, and a sorting field; Step S153 includes the following steps.

[0103] Step S15321: Determine the target data table corresponding to the data table identifier based on the data table identifier; In some possible implementations, when the configuration type identifier is determined to be the second identifier in step S153, the mapping configuration information also includes a data table identifier. This data table identifier uniquely identifies the data table storing the enumeration mapping data; for example, it can be the name or number of the data table. Based on this data table identifier, the corresponding target data table can be determined from the database so that the enumeration display value can be queried from the target data table subsequently. It is understood that the data table identifier can be specified by business personnel or developers when configuring the mapping configuration information. Different configuration codes can correspond to different data tables, and different data tables can store different types of enumeration mapping data, thereby achieving flexible configuration under different business scenarios. It is understood that the target data table can be an existing data table in the business system or a dictionary table specifically created for enumeration mapping; this application does not limit this.

[0104] In some examples, within the financial insurance scenario, the configuration code is "PAYMENT_STATUS_CONFIG," and the data table identifier in the mapping configuration information is "payment_config." Based on this data table identifier, the target data table named "payment_config" is located in the database. This data table stores all enumerated mapping data for payment status, including fields such as code value, display value, applicable terminal type, and sorting sequence number.

[0105] In some examples, within a healthcare scenario, the configuration code is "DRUG_APPROVAL_CONFIG," and the data table identifier in the mapping configuration information is "drug_approval_dict." Based on this data table identifier, the target data table named "drug_approval_dict" is located in the database. This data table stores all enumerated mapping data for drug approval status, including fields such as code value, display value, applicable terminal type, and sorting sequence number.

[0106] Step S15322: Generate a query statement based on the target data table, wherein the query target of the query statement is the query field in the target data table, the query conditions of the query statement include: the condition field matches the code value, and the type identifier is used as the query parameter, and the sorting method of the query statement is sorted according to the sorting field.

[0107] In some possible implementations, after determining the target data table, a query statement can be generated based on the query fields, condition fields, and sorting fields in the mapping configuration information. The query target (i.e., the SELECT clause) is a query field in the target data table, indicating the column name storing the enumerated display value. The query condition (i.e., the WHERE clause) includes two conditions: first, the condition field in the target data table matches the code value; second, a type identifier is used as a query parameter, meaning the type identifier participates in the matching as an additional query condition. The query statement is sorted according to the sorting field (i.e., the ORDER BY clause). It is understood that when multiple records meet the query conditions, the sorting field can determine the order in which the records are returned. For example, the query field value of the first sorted record can be used as the enumerated display value, or all retrieved records can be returned for subsequent processing. It is understood that the query fields, condition fields, and sorting fields are all column names in the target data table, specified by business personnel or developers when configuring the mapping configuration information, thus enabling flexible generation of query statements. Understandably, sorting fields can make the retrieval of enumeration display values ​​deterministic and predictable, avoiding inconsistencies in display values ​​caused by the uncertain order of records in the data table.

[0108] In some examples, within a financial insurance scenario, the query field in the mapping configuration information is "display_value", the condition field is "code", and the sorting field is "sort_order". The target data table is "payment_config", the code value is "0", and the type identifier is "PC". The generated query statement is: SELECT display_value FROM payment_config WHERE code='0' AND app_type='PC' ORDER BY sort_order. Executing this query statement and sorting the query results according to the sorting field allows you to obtain the enumerated display value "unpaid" corresponding to the payment status "0" on the PC side. In this example, the sorting field ensures that even if the code value exists in multiple records in the data table, it will return a definite result in a preset order.

[0109] In some examples, the query field in the mapping configuration information is "type_name", the condition field is "type_code", and the sorting field is "sort_order". The target data table is "policy_type_dict", the code value is "01", and the type identifier is "APP". The generated query statement is: SELECT type_name FROM policy_type_dict WHERE type_code='01' AND app_type ='APP' ORDER BY sort_order. After executing this query statement and sorting the query results according to the sorting field, the enumerated display value "critical illness insurance" corresponding to the policy type code "01" can be obtained on the APP.

[0110] In some examples, within a healthcare scenario, the mapping configuration information uses "approval_name" as the query field, "approval_code" as the condition field, and "sort_order" as the sorting field. The target data table is "drug_approval_dict," with the code value "A01" and the type identifier "APP." The generated query is: SELECT approval_name FROM drug_approval_dict WHERE approval_code='A01' AND app_type='APP' ORDER BY sort_order. Executing this query and sorting the results according to the sorting field allows you to obtain the enumerated display value "Approved" corresponding to the drug approval status code "A01" on the APP.

[0111] It is understood that this embodiment determines the target data table through the data table identifier in the mapping configuration information, and generates a query statement based on the target data table. The query target is the query field in the target data table, the query condition is the matching of the condition field with the code value and the type identifier as the query parameter, and the query statement is sorted according to the sorting field. This method has the following advantages: First, by introducing a sorting clause into the query statement, when multiple records meet the query conditions, the return order of the records can be determined according to the preset sorting field, ensuring the deterministic and consistent acquisition of the enumeration display value. Second, the introduction of the sorting clause makes the generation of the query statement more complete and flexible, allowing the sorting field to be freely specified when configuring the mapping configuration information, adapting to different needs for the record return order in different business scenarios. Third, through the cooperation of the sorting field with the query field and condition field, this method can handle more complex data table structures. For example, when the same enumeration code corresponds to multiple possible display values ​​under different conditions, the final returned enumeration display value can be automatically determined by sorting and retrieving the first record. Fourth, the generation of the entire query statement is entirely driven by configuration information. Developers only need to specify the sorting field when configuring the mapping information to automatically generate a query statement containing sorting clauses without writing additional sorting code, which further reduces the workload of development and improves the maintainability of the code.

[0112] In some embodiments of the present invention, the method for converting enumerated data further includes the following steps.

[0113] Step S210: In response to a change in the mapping configuration information, the changed mapping configuration information is stored in the configuration database, and the cache is updated.

[0114] In some possible implementations, when the mapping configuration information changes, in response to the change event, the changed mapping configuration information is stored in the configuration database, and the corresponding mapping data in the cache is updated synchronously. It is understood that changes to the mapping configuration information can include adding a mapping configuration, modifying an existing mapping configuration, deleting a mapping configuration, or adjusting specific mapping relationships within the mapping configuration (e.g., modifying the enumeration display value corresponding to a certain code value, adjusting the applicable terminal type, etc.). It is understood that the configuration database is used to persistently store all mapping configuration information, while the cache is used to provide high-speed mapping query services. When the mapping configuration information changes, both the configuration database and the cache need to be updated simultaneously to ensure data consistency and real-time query performance.

[0115] In some possible implementations, changes to mapping configuration information can be triggered by business personnel or developers through a configuration management interface. For example, the configuration management interface can provide functions for adding, modifying, deleting, and querying enumerated mapping configurations. After a business personnel modifies the display value corresponding to a specific enumeration code on the interface and clicks the save button, the system responds to the change operation by storing the modified mapping configuration information in the configuration database and simultaneously triggering a cache update. It is understood that the configuration management interface can be provided via an HTTP interface or based on a graphical user interface (GUI), and this application does not limit this. It is also understood that storage in the configuration database can be implemented using a relational database or a non-relational database, and this application does not limit this.

[0116] In some possible implementations, updating the cache can employ various strategies. For example, when mapping configuration information changes, the configuration management module can proactively notify the interceptor to update its internal cache. In response to this notification, the interceptor reloads the changed mapping configuration information from the configuration database and updates the cache. Alternatively, when mapping configuration information changes, cache entries related to that information can be directly deleted. When a subsequent query request arrives, the interceptor finds that the corresponding mapping data is missing from the cache, then loads the latest data from the configuration database and writes it to the cache—this is an example of a "cache invalidation" strategy. It is understood that the specific cache update strategy can be determined based on actual business needs, and this application does not impose any limitations on it.

[0117] In some examples, the claims status enumeration value in the financial insurance business system needs to be adjusted. Business personnel change the displayed value corresponding to claims status code "2" from "Approved" to "Closed" through the configuration management interface. In response to this modification, the system stores the updated mapping configuration information in the configuration database and triggers a cache update. Upon receiving the cache update notification, the interceptor reloads the mapping configuration information corresponding to the configuration code "CLAIM_STATUS_CONFIG" from the configuration database and updates it in the memory cache. Subsequently, when the backend server responds to a claims query request again and generates response data containing status code "2", the interceptor retrieves the updated display value "Closed" from the cache and converts it accordingly, so the frontend displays the latest status value.

[0118] In some examples, a new status type needs to be added to the drug approval status in the healthcare business system. Business personnel add a new mapping record for the configuration code "DRUG_APPROVAL_CONFIG" through the configuration management interface, with the code value "A03" and the display value "Under Review," applicable to the "APP" terminal type. In response to this addition, the system stores the new mapping configuration information in the "drug_approval_config" table in the configuration database and triggers a cache update. Upon receiving the cache update notification, the interceptor reloads the complete mapping configuration information corresponding to this configuration code from the configuration database and updates it in the memory cache. Subsequently, when the APP initiates a drug approval status query request, and the backend server returns a response containing the code value "A03," the interceptor can retrieve the corresponding enumeration display value "Under Review" from the cache and return it to the APP for display. Throughout this process, the system does not need to restart, the code does not need to be redeployed, and the change in the enumeration value takes effect in real time.

[0119] It is understood that in this embodiment, in response to changes in mapping configuration information, the changed mapping configuration information is stored in the configuration database, and the cache is updated. This method has the following beneficial effects: First, by persistently storing the changed mapping configuration information in the configuration database, the persistence and reliability of the mapping configuration information are ensured, and the changed mapping configuration information will not be lost even if the system restarts. Second, by synchronously updating the cache when the mapping configuration information changes, the data in the cache is kept consistent with the data in the configuration database, avoiding the problem of incorrect enumeration conversion results due to outdated cache, thus ensuring data consistency. Third, after the configuration change, only the database and cache need to be updated to take effect, without restarting the server or redeploying the code, realizing hot updates of the mapping configuration, which greatly reduces the complexity of system maintenance and downtime. Fourth, changes to the enumeration mapping relationship can be completed through the configuration management interface or configuration interface, and business personnel can adjust the enumeration values ​​without modifying the code, reducing operation and maintenance costs and error probability, and improving the system's flexibility and response speed. Fifth, this mechanism allows changes to the enumeration mapping configuration to take effect in real time, meeting the needs of business scenarios where enumeration values ​​may change frequently, and improving the system's maintainability and business adaptability.

[0120] 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.

[0121] 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.

[0122] In one embodiment, an enumeration data conversion device is provided, which corresponds one-to-one with the enumeration data conversion methods described in the above embodiments. For example... Figure 4 As shown, the data conversion device includes a data interception module 410, a data parsing module 420, an information acquisition module 430, a code extraction module 440, and a data conversion module 450. Detailed descriptions of each functional module are as follows: Data interception module 410 is used to intercept response data generated by the backend server; The data parsing module 420 is used to find the predefined annotations associated with the response data, and parse the configuration codes and code fields to be converted defined in the predefined annotations; The information acquisition module 430 is used to acquire the context information of the current request corresponding to the response data, wherein the context information includes the type identifier of the calling end; Code extraction module 440 is used to extract code values ​​from the response data based on the code field; The data conversion module 450 is used to convert the code value into the corresponding enumeration display value according to the configuration code, the code value and the type identifier of the calling end, so as to obtain the converted response data.

[0123] In one embodiment, the data conversion module 450 is specifically used for: Obtain the mapping configuration information corresponding to the configuration code according to the configuration code, wherein the mapping configuration information includes a configuration type identifier; When the configuration type identifier is the first identifier, retrieve the enumeration display value that matches the configuration code, the code value, and the type identifier from the cache; When the configuration type identifier is the second identifier, a query statement is generated based on the mapping configuration information, and the enumeration display value is obtained based on the query statement.

[0124] In one embodiment, the mapping configuration information further includes a data table identifier and a condition field; The data conversion module 450 is also used for: Determine the target data table corresponding to the data table identifier based on the data table identifier; A query statement is generated based on the target data table, wherein the query target of the query statement is the query field in the target data table, and the query conditions of the query statement include: the condition field matches the code value, and the type identifier is used as the query parameter.

[0125] In one embodiment, the mapping configuration information further includes a data table identifier, the condition field, and a sorting field; The data conversion module 450 is also used for: Determine the target data table corresponding to the data table identifier based on the data table identifier; A query statement is generated based on the target data table, wherein the query target of the query statement is the query field in the target data table, the query conditions of the query statement include: the condition field matches the code value, and the type identifier is used as the query parameter, and the query statement is sorted according to the sorting field.

[0126] In one embodiment, the information acquisition module 430 is specifically used for: Obtain the current request corresponding to the response data; Extract the context information from the protocol header information of the current request; Alternatively, the context information can be extracted from the session information of the current request; The caller type identifier included in the context information is used to characterize the terminal type that initiated the current request.

[0127] In one embodiment, the data conversion module 450 is further configured to: In response to changes in mapping configuration information, the changed mapping configuration information is stored in the configuration database, and the cache is updated.

[0128] In one embodiment, the data parsing module 420 is further configured to: Obtain the API interface method corresponding to the response data, and search for the predefined annotations marked on the API interface method; Alternatively, obtain the return object corresponding to the response data and search for the predefined annotation marked on the return object.

[0129] It is understood that the technical feature of parsing the configuration code defined in the predefined annotation is explicitly defined in this embodiment of the invention. The configuration code is a configuration identifier independent of the business code; it does not point to any specific enumeration class, dictionary, or hard-coded mapping relationship, but rather serves as an abstract configuration index. In actual implementation, the complete enumeration mapping configuration corresponding to the configuration code can be stored independently in a configuration database, configuration file, or configuration center, completely decoupled from the business code. Because the mapping configuration is uniformly managed and referenced through the configuration code, when business personnel need to add an enumeration type or modify the display value corresponding to a certain enumeration code, they only need to modify the mapping configuration content corresponding to the configuration code on the configuration side, without touching any business code. The predefined annotation only stores the configuration code as a reference identifier, not the specific mapping data, which makes changes to the mapping data no longer dependent on code modification and redeployment.

[0130] In this embodiment of the invention, the context information for obtaining the current request corresponding to the response data is defined. This context information includes a type identifier for the calling end and a method for converting the code value into a corresponding enumeration display value based on the configuration code, the code value, and the type identifier of the calling end. The type identifier is a dynamically obtained request-level parameter, rather than a fixed constant predefined in the code. This means that for the same configuration code and the same code value, the system can return different enumeration display values ​​based on the terminal type of the current request, without needing to write different conversion logic or develop different interfaces for each terminal type. Business personnel only need to configure different display values ​​for different terminal types under the same configuration code on the configuration end to achieve differentiated display across multiple terminals.

[0131] This invention specifies that the predefined annotations associated with the response data are searched, and the configuration codes and code fields to be converted defined in the predefined annotations are parsed. The predefined annotations declaratively mark which response data needs to be converted and which set of configuration codes to use for the conversion. The specific conversion logic is executed uniformly, and no enumeration conversion-related statements or utility class call code need to be written in the business code. Therefore, business personnel do not need to touch the business code to adjust the enumerated display values.

[0132] This invention embodiment defines the interception of response data generated by the backend server and the conversion of the code value into the corresponding enumeration display value to obtain the converted response data. The response data is uniformly intercepted and converted before being returned to the frontend. All enumeration conversions undergo the same processing logic, eliminating the need for multiple sets of conversion logic maintained separately. When the enumeration display value changes, only the configuration needs to be modified, without requiring individual code modifications.

[0133] In summary, the technical solution of this invention addresses the problem that business users cannot independently add or adjust enumeration mapping relationships without modifying code or redeploying services when they need to add enumeration types or modify enumeration display values. This is achieved by introducing an abstract configuration reference (configuration code) into predefined annotations, introducing type identifiers at the calling end to achieve multi-terminal differentiation, using declarative annotations to achieve zero intrusion into business code, and using interceptors to achieve unified processing of conversion logic. When business users need to add enumeration types or modify enumeration display values, they only need to adjust the mapping content corresponding to the configuration code on the configuration side. This allows for real-time application of the enumeration mapping configuration without modifying business code, recompiling and packaging, or restarting the service.

[0134] Based on the above-mentioned data conversion method, such as Figure 5 As shown in the diagram, this embodiment of the invention also provides a structural schematic of an apparatus for a data enumeration conversion method. The apparatus includes a processor 51 and a memory 52 coupled to the processor 51. The memory 52 stores a computer program, which, when executed by the processor 51, causes the processor 51 to perform the steps of the data enumeration conversion method described in the above embodiment.

[0135] For further details regarding the implementation of the above technical solution by the processor 51 in the device for the above enumeration data conversion method steps, please refer to the description of the enumeration data conversion method provided in the above embodiments of the invention, which will not be repeated here.

[0136] The processor 51 can also be called a CPU (Central Processing Unit). The processor 51 may be an integrated circuit chip with signal processing capabilities. The processor 51 can also be a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), an FPGA (Field Programmable Gate Array), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor, or the processor 51 can be any conventional processor.

[0137] like Figure 6As shown in the diagram, this embodiment of the invention also provides a schematic diagram of a computer-readable storage medium, on which a readable computer program 61 is stored. The computer program 61 can be stored in the storage medium in the form of a software product, including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processor to execute all or part of the steps of the methods described in various embodiments of the invention. The aforementioned storage medium includes various storage media capable of storing program code, such as USB flash drives, portable hard drives, magnetic disks or optical disks, ROM (Read-Only Memory), RAM (Random Access Memory), or terminal devices such as computers, servers, mobile phones, and tablets.

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

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

[0140] Furthermore, the functional modules in the various embodiments of this invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium.

[0141] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0142] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of the present invention are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available storage medium that a computer can store or a data storage device such as a server or data center that integrates one or more available storage media. The available storage medium may be a magnetic storage medium (e.g., floppy disk, hard disk, magnetic tape, optical storage medium) or a semiconductor storage medium (e.g., SSD (solid state disk)).

[0143] The technical solution provided by the present invention has been described in detail above. Specific examples have been used to illustrate the principle and implementation of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core idea of ​​the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation and application scope based on the idea of ​​the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

[0144] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, optical storage, etc.) containing computer-usable program code.

[0145] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0146] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0147] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0148] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A method for converting enumerated data, characterized in that, include: Intercepting response data generated by the backend server; Locate the predefined annotations associated with the response data, and parse the configuration codes and code fields to be converted defined in the predefined annotations; Obtain the context information of the current request corresponding to the response data, wherein the context information includes the type identifier of the calling end; Extract the code value from the response data based on the code field; Based on the configuration code, the code value, and the type identifier of the calling end, the code value is converted into the corresponding enumeration display value to obtain the converted response data.

2. The method for converting enumerated data according to claim 1, characterized in that, The step of converting the code value into a corresponding enumeration display value based on the configuration encoding, the code value, and the type identifier of the calling end includes: Obtain the mapping configuration information corresponding to the configuration code according to the configuration code, wherein the mapping configuration information includes a configuration type identifier; When the configuration type identifier is the first identifier, retrieve the enumeration display value that matches the configuration code, the code value, and the type identifier from the cache; When the configuration type identifier is the second identifier, a query statement is generated based on the mapping configuration information, and the enumeration display value is obtained based on the query statement.

3. The method for converting enumerated data according to claim 2, characterized in that, The mapping configuration information also includes data table identifiers and condition fields; The step of generating a query statement based on the mapping configuration information includes: Determine the target data table corresponding to the data table identifier based on the data table identifier; A query statement is generated based on the target data table, wherein the query target of the query statement is the query field in the target data table, and the query conditions of the query statement include: the condition field matches the code value, and the type identifier is used as the query parameter.

4. The method for converting enumerated data according to claim 2, characterized in that, The mapping configuration information also includes the data table identifier, the condition field, and the sorting field; The step of generating a query statement based on the mapping configuration information includes: Determine the target data table corresponding to the data table identifier based on the data table identifier; A query statement is generated based on the target data table, wherein the query target of the query statement is the query field in the target data table, the query conditions of the query statement include: the condition field matches the code value, and the type identifier is used as the query parameter, and the query statement is sorted according to the sorting field.

5. The method for converting enumerated data according to claim 1, characterized in that, The step of obtaining the context information of the current request corresponding to the response data includes: Obtain the current request corresponding to the response data; Extract the context information from the protocol header information of the current request; Alternatively, the context information can be extracted from the session information of the current request; The caller type identifier included in the context information is used to characterize the terminal type that initiated the current request.

6. The method for converting enumerated data according to claim 2, characterized in that, Also includes: In response to changes in mapping configuration information, the changed mapping configuration information is stored in the configuration database, and the cache is updated.

7. The method for converting enumerated data according to claim 1, characterized in that, The process of finding the predefined annotation associated with the response data includes: Obtain the API interface method corresponding to the response data, and search for the predefined annotations marked on the API interface method; Alternatively, obtain the return object corresponding to the response data and search for the predefined annotation marked on the return object.

8. A device for converting enumerated data, characterized in that, include: The data interception module is used to intercept response data generated by the backend server; The data parsing module is used to find the predefined annotations associated with the response data, and parse the configuration codes and code fields to be converted defined in the predefined annotations; The information acquisition module is used to acquire the context information of the current request corresponding to the response data, wherein the context information includes the type identifier of the calling end; The code extraction module is used to extract code values ​​from the response data based on the code field; The data conversion module is used to convert the code value into the corresponding enumeration display value according to the configuration code, the code value and the type identifier of the calling end, so as to obtain the converted response data.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the enumeration data conversion method as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the enumeration data conversion method as described in any one of claims 1 to 7.

Images