Business data change configuration processing method, device, equipment and medium

Abstract

The application relates to the technical field of research and development management, and discloses a business data change configuration processing method, device, equipment and medium, which comprises the following steps: configuring the association relationship between a business operation item and a data change element, a field identifier and an attribute constraint strategy; after receiving a change request, extracting a target business class identifier, a field identifier and an attribute constraint strategy; loading a target business class through a reflection mechanism and obtaining a reflection operation object; performing legality verification on a to-be-changed parameter value; after the verification is passed, locating a target business object instance and completing parameter updating. The application can be applied to a financial technology business scene, configured association business rules and execution logic are combined, data verification and updating are completed at runtime through a reflection mechanism, the business change demand can be adapted without modifying codes, the system flexibility is improved, and the maintenance cost is reduced.

Description

Technical Field

[0001] This invention relates to the field of R&D management technology, and in particular to a method, apparatus, equipment and medium for processing business data change configurations. Background Technology

[0002] In the financial industry, business operations involve numerous changes to customer information, credit contracts, and risk parameters. Existing systems typically employ static coding, hard-coding field definitions, validation rules, and processing logic into specific service classes. For example, the name of the "loan interest rate" field, its database column name, value validation rules, and interest recalculation method are all directly written into the code. When regulatory requirements necessitate adjustments to interest rate caps or the addition of a "loan purpose description" field, the source code must be modified, recompiled, and redeployed, resulting in slow response times and difficulty adapting to rapidly changing financial scenarios.

[0003] In existing technologies, modified fields and their validation rules are often scattered across multiple locations, including database table structures, independent configuration files, and program code, lacking unified management. The correspondence between business operation items, field identifiers, validation rules, and execution logic relies on manual agreement or decentralized maintenance, which can easily lead to inconsistent configurations. For example, if a new field is added to the database but not synchronized with the front end, or if business logic validation is missed after the configuration file is updated, data errors or process interruptions may occur.

[0004] Furthermore, the system has written dedicated code for different change scenarios. For example, "customer mobile number change" is achieved by directly updating the field, while "adjustment of wealth management product yield" requires calling a separate service method. Field assignment and business method calls use different technical paths, lacking a unified execution engine. Expanding to include new change elements requires simultaneous code modifications in the front-end, validation layer, and business logic layer to ensure data flow consistency with rules. This results in high system coupling, high development costs, and frequent code changes, which also increases the risk of system instability. Summary of the Invention

[0005] The main objective of this invention is to provide a method, apparatus, device, and storage medium for processing business data change configurations, aiming to solve the technical problem that existing technologies cannot achieve dynamic association and runtime effectiveness of business change rules and underlying data processing logic without modifying program code.

[0006] To achieve the above objectives, the present invention provides a method for processing business data change configurations, comprising: The mapping relationship between business operation items and data change elements, the target field identifier and attribute constraint strategy of the data change elements, and the target business class identifier corresponding to the business operation items are stored in the configuration information. In response to a change request for the business operation item, the target business class identifier corresponding to the business operation item, the target field identifier of at least one associated data change element, and the attribute constraint strategy corresponding to the data change element are obtained from the configuration information. The change request includes a target business object identifier and a parameter value to be changed. Based on the target business class identifier, the target business class is loaded using a reflection mechanism; Based on the target field identifier and the business operation item, the target reflection operation object is obtained from the target business class through reflection mechanism; The validity of the parameter value to be changed is verified according to the attribute constraint strategy. After the legality verification is passed, the target business object instance is located based on the target business object identifier, and the change operation is performed using the target reflection operation object through the reflection mechanism to update the parameter value to be changed to the target business object instance.

[0007] Furthermore, to achieve the above objectives, the present invention provides a business data change configuration processing apparatus, comprising: The configuration building module is used to store the mapping relationship between business operation items and data change elements, the target field identifier and attribute constraint strategy of the data change elements, and the target business class identifier corresponding to the business operation item in the configuration information; The configuration parsing module is used to respond to a change request for the business operation item by obtaining from the configuration information the target business class identifier corresponding to the business operation item, the target field identifier of at least one associated data change element, and the attribute constraint strategy corresponding to the data change element. The change request includes the target business object identifier and the parameter value to be changed. The class loading module is used to load the target business class through reflection based on the target business class identifier. The reflection object location module is used to obtain the target reflection operation object from the target business class through the reflection mechanism based on the target field identifier and the business operation item. The rule verification module is used to verify the legality of the parameter value to be changed according to the attribute constraint strategy. The instance change module is used to locate the target business object instance based on the target business object identifier after the legality verification is passed, and to perform a change operation using the target reflection operation object through the reflection mechanism to update the parameter value to be changed to the target business object instance.

[0008] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a business data change configuration processing program stored in the memory and executable on the processor, wherein when the business data change configuration processing program is executed by the processor, it implements the steps of the business data change configuration processing method as described above.

[0009] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a business data change configuration processing program, wherein when the business data change configuration processing program is executed by a processor, it implements the steps of the business data change configuration processing method described above.

[0010] Beneficial Effects: This invention relates to the field of R&D management technology and discloses a method, apparatus, device, and medium for processing business data change configurations. The method includes: configuring the association between business operation items and data change elements, field identifiers, and attribute constraint strategies; extracting the target business class identifier, field identifier, and attribute constraint strategy after receiving a change request; loading the target business class and obtaining the reflection operation object through a reflection mechanism; validating the value of the parameter to be changed; and locating the target business object instance and updating the parameters after successful verification. This invention can be applied to business scenarios such as fintech. By configuring and associating business rules and execution logic, and combining a reflection mechanism to complete data verification and updates at runtime, it enables adaptation to business change requirements without code modification, improving system flexibility and reducing maintenance costs. Attached Figure Description

[0011] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for a business data change configuration processing method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the business data change configuration processing method of the present invention; Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the business data change configuration processing device of the present invention; Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0013] The business data change configuration processing method provided in this embodiment of the invention can be applied to, for example, Figure 1 In this application environment, the client communicates with the server via a network. The server can configure the association between business operation items and data change elements, field identifiers, and attribute constraint strategies through the client; upon receiving a change request, it extracts the target business class identifier, field identifier, and attribute constraint strategy; loads the target business class and obtains the reflection operation object through reflection; verifies the validity of the parameter values ​​to be changed; and after successful verification, locates the target business object instance and completes the parameter update. This invention can be applied to business scenarios such as fintech. By configuring associated business rules and execution logic, and combining reflection mechanisms to complete data verification and updates at runtime, it can adapt to business change requirements without modifying the code, improving system flexibility and reducing maintenance costs. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The following detailed description of the invention uses specific embodiments.

[0014] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the business data change configuration processing method provided by the present invention. It should be noted that although a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0015] like Figure 2 As shown, the business data change configuration processing method proposed in this invention includes the following steps: S10, the mapping relationship between business operation items and data change elements, the target field identifier and attribute constraint strategy of the data change elements, and the target business class identifier corresponding to the business operation items are stored in the configuration information; In this embodiment, a business operation item is a specific business action that is predefined in the system and can be uniquely identified and triggered. In software implementation, it typically corresponds to a function point code with a clear business meaning. For example, in a customer relationship management system, "modify customer level" or "update contact address" can both be independent business operation items. Each business operation item is assigned an identifier, which is used as a key parameter in internal and external interface calls to indicate what business action is intended to be performed. The establishment of this identifier provides a retrieval entry point for accurately locating all rules related to this operation from massive configuration information.

[0016] Data change elements refer to the specific business data entries that need to be added, modified, or deleted when the aforementioned business operations are triggered. A business operation may be associated with one or more data change elements. For example, the data change element associated with the "Modify Customer Level" operation is the "Customer Level" data; while the "Update Contact Address" operation may be associated with multiple data change elements such as "Province," "City," and "Detailed Address." Each data change element needs to specify two core attributes at the configuration level: the target field identifier and the attribute constraint strategy. The target field identifier is a string used for precise matching at the program source code level, directly corresponding to the name of a member variable in the backend business object entity class. For example, assuming there is a Customer class where the private field representing customer level is defined as private String customerLevel;, then the target field identifier corresponding to this data change element would be configured as "customerLevel". This identifier establishes a bridge between configurable business terms and immutable program code elements.

[0017] An attribute constraint policy is a set of rules bound to a data change element, used to determine the validity of its value before data is written. These policies are independent of the main business logic code and define the requirements for input data in a declarative manner. Each attribute constraint policy contains a rule type and corresponding constraint parameters. For example, for "customer level" data, its attribute constraint policy can be defined to include "enumerated value validation" with parameters "gold, silver, bronze"; for "detailed address" data, a policy can be defined to include "maximum string length validation" with a parameter of "200". These policies provide dynamically parsed execution criteria for subsequent general validation logic.

[0018] The mapping relationship between business operation items and data change elements is a static association record explicitly declared in the configuration information, representing the connection between the operation and the data. This relationship is not implicitly reflected in code structures such as function parameters or class member variables in programming languages, but exists in the form of external lists, sets, or key-value pairs. For example, the configuration information can record: the business operation item "Update Contact Address" is mapped to the data change element set ["Province", "City", "Detailed Address"]. This configurable mapping relationship allows the system to adjust the range of data to be processed by an operation without modifying any business logic code. For example, adding a "Postal Code" element to the "Update Contact Address" operation simply requires expanding the mapping list in the configuration.

[0019] The target business class identifier is a locational information pointing to a specific programming language class definition. In the Java language system, it is typically represented by a fully qualified class name, such as "com.abc.crm.service.CustomerProfileService". This identifier indicates which specific class carries the key capabilities related to performing the business operation. This class could be a service class containing business processing methods or an entity class defining data structures. In the configuration, this identifier is directly associated with the business operation, and its significance lies in knowing precisely which class to start with when the system processes the business operation, loading the class definition through reflection, and further exploring its internal structure.

[0020] Configuration information serves as a persistent storage medium for all the aforementioned business operation item definitions, data change element definitions, mapping relationships, and target business class identifiers. It is a structured dataset whose organization must balance human readability and machine parsing. The core function of configuration information is to serve as the sole authoritative source for dynamically acquiring business rule information during system runtime, thereby completely separating the volatile, business-domain-specific rule decision logic from the stable, general-purpose program execution engine. Before initializing or processing business operations, the system reads and parses this configuration information, loading its contents into memory to form a data structure that can be quickly queried.

[0021] Configuration information can be defined and stored using a variety of widely used structured data serialization formats. JSON is a common choice, as it clearly expresses hierarchical relationships using nested objects and arrays. For example, a JSON array can be designed to store all business operation items, where each operation item is a JSON object containing "operationId," "targetClassName," and an array of "dataElements." Each data element object further contains fields such as "fieldName" and "constraints."

[0022] The persistent storage medium for configuration information can be chosen based on the system architecture and operational needs. The configuration content can be written to a separate text file, such as business_rules.json, and deployed in a specific directory on the application server's file system. The application reads and parses this file upon startup.

[0023] This embodiment achieves physical separation between business rule definition and program execution code by extracting and embedding all business operation items, data change elements, their corresponding program field identifiers, data validation rules, the relationship between operations and data, and implementation class identifiers into external configuration information. This ensures that any adjustment to business rules, including adding operations, modifying data items involved in operations, changing data validation logic, or switching the underlying implementation class, does not require touching, modifying, or recompiling and deploying the program source code.

[0024] S20, in response to the change request for the business operation item, obtain from the configuration information the target business class identifier corresponding to the business operation item, the target field identifier of at least one associated data change element, and the attribute constraint strategy corresponding to the data change element, wherein the change request includes the target business object identifier and the parameter value to be changed; In this embodiment, a change request is an instruction initiated from outside the system, requesting the execution of a configured business operation and providing specific data. This request is typically transmitted to the system via an application programming interface (API), message queue, or user interface form submission. The request payload must contain several key data elements. The business operation item identifier explicitly specifies the specific business action to be triggered by this request, such as "update customer contact information." The target business object identifier is a code used to uniquely identify the specific business entity instance targeted by this operation within the system, such as a customer number "CUST-1001" or a policy number "POL-2024-001," indicating which specific business object the data change will be applied to. The parameter value to be changed is the new data content associated with the business operation item that the user or external system wants to set. Its format and content must match the data change elements defined in the configuration, such as a new address in string format, "No. 100, XX Road, XX District, XX City."

[0025] When the system receives a change request, it first needs to parse the request payload to extract the aforementioned key data elements. The parsing process depends on the request's transport protocol and serialization format. For example, if the request is an HTTP POST request with a JSON body, the parsing process involves using a JSON parsing library to extract the corresponding field values ​​representing the business operation item identifier, the target business object identifier, and the parameter values ​​to be changed from the JSON object.

[0026] Subsequently, the system uses the parsed business operation item identifier as the search key to query the configuration information previously loaded into memory. The configuration information in memory is typically organized as a dictionary or mapping structure with the business operation item identifier as the key to achieve efficient lookup. The purpose of the query is to locate and read all relevant configuration metadata pre-bound to the specific business operation item from the configuration information.

[0027] The target business class identifier is one of the key metadata elements retrieved first. It is read directly from the corresponding configuration node of the business operation item in the configuration information and is a predefined fully qualified class name string. Retrieving this identifier means that the system knows which specific backend business class needs to be loaded and manipulated subsequently via reflection.

[0028] The target field identifier of at least one associated data change element is also retrieved from the configuration information. Since a business operation item may map to multiple data change elements, a list or set of target field identifiers is obtained here. Each target field identifier is a string read from the corresponding data change element definition in the configuration, and they precisely indicate which member variable fields in the target business class or its associated entity class will accept data changes.

[0029] The attribute constraint strategies corresponding to each data change element are also retrieved. These strategies are stored in a structured form in the configuration information and are read into memory along with the definition of the data change element. Retrieving these strategies provides a complete set of rule definitions for the subsequent dynamic data validity verification process, independent of business logic. The entire process enables the dynamic identification of operation intent based on requests and the real-time assembly of all the guidance information required to execute the operation based on externalized configuration. The core lies in the dynamic association and parsing of runtime requests with pre-configured settings.

[0030] This embodiment dynamically parses the business operation item identifier from external requests and uses this identifier as an index to query and extract all relevant execution metadata from externalized configuration information in real time, including the target business class identifier, target field identifier, and attribute constraint strategy. This achieves complete decoupling between business requests and execution logic. The system does not need to pre-code any processing branch for each possible business operation item. It can guide any request to the correct business class and data field and prepare the corresponding validation rules through a unified configuration query and assembly process.

[0031] S30, Load the target business class through reflection mechanism according to the target business class identifier; In this embodiment, the target business class identifier is a string that uniquely identifies a class definition within a specific programming language runtime environment. In a Java environment, this is typically represented by a fully qualified class name, such as "com.example.service.OrderProcessingService". The string structure follows the convention of "package name.class name", precisely indicating the logical location of the class definition within the project's codebase and dependent libraries. This identifier originates from the query results of configuration information in the preceding steps and serves as a core input parameter for the reflection loading operation.

[0032] Loading a target business class via reflection refers to the process during program execution where, based on the target business class identifier (in string form), the corresponding class bytecode is dynamically located, read, interpreted, and initialized, ultimately generating a `java.lang.Class` object representing that class in memory. This process is fundamentally different from static class references and instantiation using the `new` keyword in the source code. Reflection allows programs to operate on specific classes without needing to know them at runtime, instead determining them based on configuration or user input. Its core operation involves calling reflection APIs; for example, in Java, this can be done by calling the `Class.forName(className)` method or by calling the `loadClass(className)` method through the current thread's context class loader. The system passes the target business class identifier as a parameter to these methods, and the Java Virtual Machine (JVM) searches for a matching `.class` file in all directories and JAR files defined in the classpath. Once found, the JVM loads the bytecode of that file, performs linking (verification, preparation, and resolution), and initializes the class if necessary. Upon successful completion, a `Class` object representing the class definition is returned. This Class object is the cornerstone of reflection operations. It contains complete structural metadata about the class, such as declared fields, methods, constructors, and parent classes. Classes loaded in this way can have their subsequent instance creation, method calls, and field access dynamically completed through the same reflection mechanism, thus enabling the on-demand determination and assembly of business logic execution units at runtime.

[0033] The specific techniques for implementing reflection-based loading can be adjusted based on performance requirements, environment isolation needs, and deployment models. The most basic implementation is to directly use the `Class.forName(String className)` method. This method loads the class using the caller's class loader and, by default, triggers the execution of the class's static initialization block. This is suitable for scenarios where it is necessary to ensure that the class is fully initialized.

[0034] When more granular control over the class loading process is needed, or when default initialization needs to be avoided, the class loader can be explicitly specified and its `loadClass(String name)` method called. For example, the context class loader of the current thread can be obtained (`Thread.currentThread().getContextClassLoader()`), or the class loader that loaded the current class can be used (`getClass().getClassLoader()`). This approach is particularly important in modular environments such as web application containers or OSGi, as it respects the class loader hierarchy and isolation rules of that environment.

[0035] To improve performance, especially in scenarios involving frequent execution of the same business operations, a class object caching mechanism can be introduced. After successfully loading and retrieving a Class object based on the target business class identifier for the first time, this object is stored in an in-memory cache with the target business class identifier as the key and the Class object as the value, for example, using a ConcurrentHashMap. Subsequent times when the same class needs to be loaded again, this cache is checked first. If it exists in the cache, the cached Class object is returned directly, thus completely avoiding duplicate disk I / O, bytecode verification, and class initialization overhead. Cache management strategies can include setting a maximum capacity, expiration time, or providing a manual refresh interface.

[0036] This embodiment utilizes reflection to dynamically load class definitions based on a string-based target business class identifier obtained from external configuration, completely eliminating the hard-coded dependency on specific business implementation classes in the program source code. The specific implementation classes of the business logic can be freely replaced, upgraded, or added, as long as their fully qualified class names are updated accordingly in the configuration information. The core execution flow of the system can adapt without any modification. This decouples changes to underlying business components from the system's core execution engine, greatly improving the flexibility and maintainability of the system architecture.

[0037] S40, Based on the target field identifier and the business operation item, obtain the target reflection operation object from the target business class through a reflection mechanism; In this embodiment, the target field identifier is a string that precisely corresponds to the name of a member variable (field) declared in the target business class or its associated entity class. For example, in an Order class representing an order, if there is a field `private BigDecimal amount;`, the corresponding target field identifier might be "amount". This identifier originates from the definition of data change elements in the configuration information, and its function is to uniquely determine a data storage location at the program code level. The business operation item is a string encoding that identifies a specific business function, such as "UPDATE_ORDER_AMOUNT". It also originates from the configuration and is specified in the change request to indicate the intent of the current request. At this stage, the system holds both the target field identifier and the business operation item information, which together determine what reflection operation object needs to be obtained from the target business class.

[0038] The target business class is a `java.lang.Class` object previously loaded into memory via reflection. It contains complete metadata about the class, such as information about all fields and methods. Obtaining the target reflection operation object from this class via reflection is a process of dynamically probing the class structure and extracting reflection references to specific members. The target reflection operation object is an object obtained through the reflection API that points to a specific member (field or method) in the target business class. In Java, this is typically an instance of the `java.lang.reflect.Field` or `java.lang.reflect.Method` class. This object encapsulates the ability to manipulate the field or method it refers to, such as reading / setting field values ​​or calling methods.

[0039] The retrieval process is based on the target field identifier and the semantics implied by the business operation item. A common scenario is that the business operation item directly corresponds to a modification operation on a specific field. In this case, the system uses the target field identifier as a parameter to call the `getDeclaredField(String name)` method of the target business class's `Class` object. This method searches for a field whose name exactly matches the target field identifier among all declared fields of the class and returns its corresponding `Field` object. This `Field` object is the target reflection operation object, providing the ability to dynamically modify the field's value subsequently.

[0040] Another scenario is that a business operation item might correspond to a more complex business logic method, and the target field identifier might be used to indicate key parameters or related fields involved in that method. In this case, the system needs to deduce the specific method name to be called based on the business operation item. For example, the configuration might stipulate that the business operation item "APPROVE_ORDER" corresponds to a method named "approveOrder". The system will then call the getDeclaredMethod(String name, Class) method of the target business class's Class object, using the deduced method name as a parameter.<?> ...the parameterTypes method. When calling this method, the parameter type list needs to be explicitly specified. This can be determined by analyzing the field type represented by the target field identifier or other configuration information. Upon successful invocation, the corresponding Method object will be returned as the target reflection operation object, providing the ability to dynamically invoke the business method.

[0041] Regardless of the type of object obtained, since fields or methods in the target business class may be declared as private or protected, direct access via reflection may be subject to Java's access control restrictions. Therefore, after obtaining the Field or Method object, it is usually necessary to call its setAccessible(true) method to set the accessibility flag to true, thereby bypassing access control checks and ensuring that subsequent assignment or invocation operations can proceed smoothly. The entire process is completed dynamically based on runtime string information, without needing to know the specific class member details at compile time.

[0042] This embodiment dynamically retrieves and obtains specific field or method reflection objects from the loaded target business class based on the target field identifier and business operation item using a reflection mechanism, thus achieving runtime binding between business operation intent and the underlying code structure. The system does not need to write hard-coded logic branches for every possible field access or method call; instead, it uses a unified reflection retrieval process to convert abstract configuration identifiers into executable operation handles.

[0043] S50, the legality of the parameter value to be changed is verified according to the attribute constraint strategy; In this embodiment, the attribute constraint strategy is a predefined set of logical conditions used to determine whether data values ​​conform to business or technical rules. It exists in a structured form, independent of the main business logic code, and typically contains two core components: rule type identifiers and rule parameters. The rule type identifier is a string keyword used to classify the validation type, such as "Required," "MaxLength," "NumberRange," or "RegexPattern." Each rule type identifier corresponds to a specific data validation algorithm. The rule parameters are the specific numerical values ​​or conditions that the validation algorithm needs to refer to when executing. For example, for the "MaxLength" rule, the parameter might be an integer "100"; for the "NumberRange" rule, the parameter might be an object containing "min" and "max" keys. The parameter value to be changed is new data passed in from an external request, expected to be applied to the target business object. Its form is usually a string, number, or other basic data type, or a simple object. Legality verification refers to the process by which the system automatically checks the attribute constraint policy before allowing the parameter value to be changed to be applied to a business object, and then draws a "pass" or "reject" conclusion.

[0044] The verification process begins with parsing the attribute constraint policy. The system reads the attribute constraint policy associated with the currently changed data feature and converts it from a storage format (such as a JSON string) into an in-memory, operable data structure, such as a list containing multiple "rule type-parameter" pairs. This process may involve using a specific parsing library to deserialize the configuration data.

[0045] Next comes the dynamic matching and execution of the validation logic. The system maintains a validation logic registry or factory, which maps different rule type identifiers to specific, executable validation functions or classes. These validation functions are independently encapsulated, single-function code units, such as a function to check the length of a string or a function to determine if a number is within a range. When validation begins, the system iterates through the parsed list of rules, and for each rule, retrieves the corresponding validation function instance from the registry based on its rule type identifier. Then, the system passes the parameter value to be changed, along with the current rule's parameter, to the validation function. The validation function internally performs its own judgments based on its proprietary logic. For example, a length validation function calculates the length of the parameter string and compares it to the maximum allowed length; a numeric range validation function determines whether the parameter value is between the specified minimum and maximum values. Each validation function produces a Boolean result (true or false) or a validation response object containing the result.

[0046] Finally, the system aggregates and determines the validation results. It collects the results of all executed validation functions. If all validation results indicate true, the system determines that the validity validation has passed, meaning the parameter value to be changed meets all preset constraints and can proceed to the next step. If any validation result indicates false, the system immediately determines that the validity validation has failed. In cases of failure, the system typically interrupts the current change process and can selectively collect and return specific reasons for the failure, such as "value exceeds the allowed range" or "this field is required."

[0047] The implementation of validation logic units can be diverse. They can be implemented as stateless static functions that directly receive parameter values ​​and rule parameters for computation. Alternatively, they can be encapsulated as classes that implement a unified interface, such as a `Validator` interface that defines a `validate(input, ruleParam)` method. Using an interface approach facilitates unified management through a dependency injection framework. The validation logic registry can be a simple hash table, initialized at system startup, storing rule type identifier strings as keys and corresponding validation function or validation class instances as values.

[0048] The storage and parsing methods for attribute constraint strategies can be adjusted. Strategies can be embedded within the configuration of data change elements as a JSON array field. The system uses JSON libraries such as Fastjson and Jackson for parsing. In a more structured configuration, strategies can also be stored in a separate database table, with each record associated with a data element ID, and loaded via a dedicated query. For scenarios requiring extremely high flexibility, the rule parameters themselves can support complex expression languages, such as SpEL (Spring Expression Language), allowing logical expressions like "value>0&&value<100" to be written directly in the parameters. These expressions are then dynamically calculated at runtime by the expression interpretation engine, eliminating the need to create separate rule types for each simple logic.

[0049] There are several ways to optimize the verification execution process. One approach is a short-circuit evaluation strategy, where verifications are executed sequentially, and if a verification fails, subsequent verifications are immediately terminated and a failure result is returned. This is suitable for situations where verification costs are high or there are logical dependencies. Another approach is a parallel verification strategy. When multiple independent verifications need to be executed and system resources allow, these verifications can be executed concurrently to improve throughput, and the results can be aggregated at the end.

[0050] This implementation achieves complete separation between data validation rules and core business processing logic by abstracting data validity requirements into configurable attribute constraint policies and dynamically parsing these policies at runtime and matching them with corresponding independent validation logic units for execution. Changes to business rules, whether adding new validation types, adjusting numerical thresholds, or modifying logic combinations, do not require touching or recompiling the main program code; only updating the external policy configuration is needed for immediate effect.

[0051] S60, after the legality verification is passed, the target business object instance is located based on the target business object identifier, and the change operation is performed using the target reflection operation object through the reflection mechanism to update the parameter value to be changed to the target business object instance.

[0052] In this embodiment, the target business object identifier is a unique code or string within a specific business domain, used to precisely identify the runtime object corresponding to a specific business data record that has been persistently stored. For example, in a customer management scenario, this might be a customer ID "CUST-2024001"; in an order processing scenario, it might be an order number "ORDER-20240321001". This identifier originates from an externally received change request and is the sole basis for locating the specific operation target. Locating the target business object instance based on this identifier means that the system uses this identifier as a query condition to retrieve the corresponding complete business data record from persistent data storage (such as a relational database, NoSQL database, or distributed cache), and then rehydrates or reconstructs this data into a programming language object that can be directly manipulated in the application's memory. This process typically relies on data access layer components, such as performing a database query through an object-relational mapping framework, or calling a basic service method to retrieve an entity object based on its ID. Once the target business object instance is successfully located, it is a specific object that carries the current business state, such as an instance of the Customer or Order class that has already been populated with the original attribute values. The change operation will be applied to this specific instance.

[0053] The target reflection operation object is a Field or Method object previously obtained through reflection, pointing to a specific field or method in the target business class. It represents the specific type of operation to be performed, whether it's modifying a field value or calling a business method. Utilizing this object to perform the change operation through reflection is a dynamic invocation process. Its core is combining the target business object instance in memory with the parameter value to be changed, and then using the reflection API to change the instance's internal state or trigger its behavior.

[0054] If the target reflection operation object is a Field object, then performing the operation means calling the `set(Object obj, Object value)` method of that Field object. Here, the `obj` parameter is the located target business object instance, and the `value` parameter is the value to be changed. This method call directly modifies the value of the member variable represented by the Field object within the target business object instance, assigning the new value to the instance. This is a direct data state update.

[0055] If the target reflection operation object is a Method object, then performing the operation means calling the `invoke(Object obj, Object... args)` method of that Method object. The `obj` parameter is also passed as the target business object instance, and the `args` parameter is a variable array of arguments, typically with the values ​​of the parameters to be changed as the sole elements of this array. This method call dynamically executes the method logic represented by the Method object within the target business object instance. The method usually contains more complex business processing, which may perform a series of calculations and state transitions based on the new parameter values, ultimately updating some internal states of the instance, thereby indirectly changing the business data.

[0056] Regardless of the method, the essence of performing an operation is to leverage the dynamic binding capabilities provided by reflection to determine the specific semantics of the operation (assignment or invocation) at runtime and apply it to a specific memory object. Before execution, it is usually necessary to ensure that the accessibility of the target reflection operation object is set to allowed to bypass access restrictions on private members. After execution, the state of the target business object instance in memory is updated, reflecting the result of this change. The entire process dynamically and precisely connects abstract identifiers, configurable operation instructions, and concrete memory object instances.

[0057] The specific technical means for locating the target business object instance can vary depending on the data access architecture adopted by the system. When using ORM frameworks such as JPA or Hibernate, it can be done through EntityManager's find(Class) method. <t>The `entityClass(Object primaryKey)` method or the `findById` method of the corresponding repository interface can be used to directly retrieve the instance of the target business object by passing in its class type and identifier. In a more lightweight architecture, parameterized SQL queries can be written using tools such as JdbcTemplate to query the database based on the identifier and map the result set to objects. If the business object is stored in a key-value database such as Redis, the identifier can be used directly as the key for reading, and the retrieved data can be deserialized into an object instance. In some microservice architectures, locating an instance may require calling another service specifically managing that entity via RPC.

[0058] The performance and security details of reflection-based change operations can be optimized. For frequently executed change operations, caching the reflection call process can be considered. For example, a MethodHandle or reflection caller can be pre-created and cached for specific business operation items. This caller is bound to a specific Method object and parameter conversion logic, and subsequent execution can directly pass in the instance and parameter values, reducing the overhead of reflection lookups and parameter boxing. In environments with high security requirements, a whitelist can be performed on fields or methods that are allowed to be modified via reflection before executing reflection calls, preventing access to sensitive internal methods through configuration errors or malicious requests. Furthermore, reflection operations should generally be performed within a unified transaction management boundary to ensure the atomicity of data changes.

[0059] This implementation dynamically locates specific business object instances based on the target business object identifier and uses a pre-acquired reflection operation object to perform precise assignments or method calls on those instances. This achieves lossless application of externally configured change intentions to the correct in-memory object carrying the real-time business state. This process completely eliminates the hard-coded dependency on specific object retrieval logic and specific update statements in the business processing code. The system can handle changes to any type of business object with a unified mechanism, as long as its identifier and the correct reflection operation object are provided. This significantly improves the versatility and reusability of the core data change process, making the operation of supporting new business object types or modifying existing objects mainly a configuration and domain model level task, without requiring modification of the general execution engine, and significantly reducing the system's coupling and maintenance complexity.

[0060] In one embodiment, step S10 above includes: S101, Construct a metadata model containing data change elements, and define the target field identifier corresponding to the data change elements and the attribute constraint strategy for verifying data legality in the metadata model; S102, Create a configuration node for the business operation item, and specify the corresponding fully qualified class name as the target business class identifier for the business operation item; S103, Select at least one data change element from the metadata model and include it in the configuration node to establish a mapping relationship between the business operation item and the data change element; S104, serialize the data structure containing the mapping relationship, the target field identifier, the attribute constraint strategy and the target business class identifier to obtain configuration information, and save the configuration information to the storage medium.

[0061] In this embodiment, constructing a metadata model containing data change elements means creating a structured definition framework for formally describing data items and their attributes. This model is a logical container used to hold standardized descriptions of all data elements that need to be changed in business operations. Each data change element is represented in the model as an independent record or entry, which contains the definition of two core attributes. The first attribute is the target field identifier, a string used to precisely match the name of a specific member variable in a business object class at the program code level, such as associating the data element "Customer Name" with the field name in the entity class Customer. The second attribute is the attribute constraint strategy, which defines a series of independently executable validation rules for any new value passed to the data element. These strategies are defined in a structured form, such as a list containing "rule type" and "rule parameters." The rule type can be "length limit," "numerical range," or "regular expression matching," etc., and the rule parameters provide the specific thresholds or patterns required for rule execution. The process of building a metadata model is essentially about abstracting, summarizing, and encoding scattered business data requirements into a standardized description that can be recognized and processed by machines, providing a unique and clear input source for subsequent automated processing.

[0062] Creating a configuration node for a business operation item refers to assigning an independent configuration unit within the configuration system to a specific, triggerable business function unit. This configuration node serves as the central point for all relevant configuration information for that business operation item, and its identifier is typically consistent with the name or code of the business operation item. A key operation within this node is specifying the target business class identifier for the business operation item, given in the form of a fully qualified class name. The fully qualified class name is a string following the "package name.class name" convention, uniquely identifying which specific Java class in the application's classpath carries the core logic for executing the business operation or holds the data structure to be modified. For example, specifying the target business class identifier as "com.example.service.CustomerService" for the "update customer information" operation. This specification establishes a static reference relationship between the business function semantics and the specific technical implementation class, enabling the system to accurately navigate to the corresponding implementation class at runtime based on the operation item.

[0063] Selecting at least one data change element from the metadata model and assigning it to a previously created configuration node is an operation that establishes a two-way association. This operation uses the explicitly defined data change elements in the metadata model as an optional pool. Based on business rules, elements logically related to the business operation item are added to the association list of the configuration node by referencing or copying their identifiers. For example, for the "Create Order" business operation item, data change elements such as "Product Number," "Purchase Quantity," and "Shipping Address" can be selected from the metadata model and assigned to the configuration node for that operation item. This assignment explicitly declares the scope of data that must be processed to execute the business operation at the configuration level, thus forming a mapping relationship between the business operation item and the data change elements. This mapping relationship is not hard-coded into the program logic but exists as configurable and changeable associated data, allowing dynamic adjustments to the data items involved in an operation without affecting the code.

[0064] Serializing a data structure containing mapping relationships, target field identifiers, attribute constraint strategies, and target business class identifiers refers to the process of converting a composite data structure organized in memory, containing all the above configuration information, into a standardized byte stream or text format suitable for persistent storage or network transmission. This data structure is typically a nested object graph, such as a JSON or XML object. Its top-level structure represents business operation item configuration nodes, internally containing target business class identifiers and a list of associated data change elements. Each element node contains its target field identifier and attribute constraint strategy. The serialization process uses a specific serialization library (such as Jackson, Gson, or XStream) to convert this object graph into a JSON string, XML document, or other binary format. The resulting serialized byte stream or text is the final configuration information. Subsequently, this configuration information is saved to storage media, meaning the serialized data is written to a physical carrier, such as a configuration file in a specific path in the file system, inserted as a record into a database configuration table, or submitted to a distributed configuration service center. The saving operation ensures the persistence of the configuration information, making it available even after a system restart, and provides a foundation for unified management and distribution of configurations.

[0065] Through the above steps, any adjustment to business rules—whether it's adding operations, modifying data items associated with operations, changing data validation rules, or replacing the underlying implementation class—can be made effective by modifying this configuration information and reloading it, without requiring any changes, compilation, or redeployment to the system's core execution code. This fundamentally decouples business flexibility from technical stability, greatly improving the system's agility and maintainability in response to changes.

[0066] In one embodiment, step S20 above includes: S201, Receive a data packet carried by the network transmission protocol as a change request, and parse the data packet to distinguish the target service object identifier, the parameter value to be changed, and the operation code used to index the service operation item; S202, using the operation code as the index key, query and locate the corresponding business operation item configuration node in the configuration information; S203, Read the fully qualified class name string from the business operation item configuration node as the target business class identifier; S204, traverse the association list under the configuration node of the business operation item, obtain the target field identifier and attribute constraint strategy defined for each data change element, and establish the correspondence between the parameter value to be changed and the target field identifier.

[0067] In this embodiment, a data packet carried by a network transmission protocol is received as a change request. This data packet is then parsed to distinguish the target business object identifier, the parameter value to be changed, and the operation code used to index business operation items. This is a deserialization and structured extraction process that converts external input into internally processable data. The network transmission protocol defines the format specifications and transmission rules of the data packet, such as HTTP / HTTPS, TCP sockets, or message queue protocols. The data packet is a byte sequence carried according to the protocol specification, and its payload is typically encoded using structured data serialization formats such as JSON, XML, or Protocol Buffers. The receiving action is completed by a network service endpoint, such as a web server controller, RPC service stub, or message listener. The parsing process first deconstructs the packet according to the protocol specification, extracting the payload byte stream. Then, it calls the parsing library corresponding to the serialization format to restore the byte stream into a data structure in memory, such as a JSON object or a Protobuf Message object. From this data structure, based on pre-defined field names or position indexes, three key data elements are extracted: the target business object identifier is a string used to uniquely identify a specific business entity instance; the parameter value to be changed is new data related to the request intent, and its type and structure are related to subsequent configuration definitions; the operation code is a string key specifically used for indexing and retrieving predefined business operations within the system. This parsing process achieves adaptation and conversion between external heterogeneous requests and the internal unified processing model.

[0068] Using the operation code as the index key, querying and locating the corresponding business operation item configuration node in the configuration information is a precise key-value pair retrieval operation. After system initialization, the configuration information is typically loaded and organized in memory, forming an efficient query data structure, such as a hash mapping with the operation code as the key and the complete configuration node object as the value. The operation code serves as the query input, directly passed as the key to the query interface of this mapping. Internally, the query interface calculates the hash value of the key using a hash function, locates the corresponding bucket, and then finds or confirms that no associated configuration node object exists. Successful location means that a pre-configured business rule set entry point that perfectly matches the current request intent has been found. This configuration node is a structured data container that encapsulates all static definition information related to the business operation.

[0069] Reading the fully qualified class name string from the business operation item configuration node as the target business class identifier is the process of accessing a specific attribute of a located configuration node. The configuration node object contains multiple fields, one of which stores the target business class identifier, which is saved as a fully qualified class name string. The fully qualified class name follows the naming convention of "package name.class name", such as "com.domain.service.OrderProcessor". The reading action is completed by accessing the object's attribute or calling its getter method. The obtained string clearly identifies the specific Java class that needs to be loaded and interacted with in subsequent reflection operations.

[0070] Traversing the association list under the business operation item configuration node to obtain the target field identifier and attribute constraint strategy defined for each data change element is an iterative process of accessing a complex data structure. The configuration node object contains an association list field, which stores summary information or reference identifiers of all data change elements bound to this business operation item. The traversal operation initializes an iterator, sequentially accessing each element in the list. Each element is an object representing a data change element, from which two core attributes can be directly read or further queried through its identifier: the target field identifier, i.e., the field name string in the business entity class corresponding to this data element; and the attribute constraint strategy, i.e., a set of rules describing how to validate the value of this data element, usually represented by a rule type and parameter list structure. The traversal process collects this information one by one, forming a set of data element definitions.

[0071] Establishing a mapping between parameter values ​​to be changed and target field identifiers is a process of logically pairing incoming request data with data elements defined in the configuration, based on data organization rules. Parameter values ​​to be changed may exist in various forms in the request, such as a JSON object containing multiple key-value pairs, or an array of values ​​related to the order of data elements. Establishing this mapping requires consistent matching logic; for example, when the parameter is a key-value object, its key name is matched against the target field identifier; when the parameter is an ordered array, its index position is matched against the order of elements in the associated list. This process outputs a mapping result, clearly specifying which specific business object field each parameter value to be changed should be applied to, providing a clear input mapping for subsequent field-by-field validation and assignment operations.

[0072] This embodiment, through the aforementioned steps, eliminates the need for the system's receiving end to perform hard-coded preprocessing or routing decisions for any specific business operations. The core processing engine relies solely on general parsing, querying, and mapping logic to assemble all the necessary metadata for any compliant request. This achieves extreme generalization of business interfaces and complete externalization of business rule management. Adding or modifying business operations only requires extending the configuration and conforming to the interface protocol, without altering any code in the request processing pipeline. Thus, while ensuring the stability of the core engine, near-infinite business scalability is achieved.

[0073] In one embodiment, step S30 above includes: S301, using the target business class identifier as the index key, query in the preset class object cache container whether the corresponding business class object already exists; S302, if a corresponding business class object already exists in the class object cache container, then the existing business class object is determined as the target business class; S303, if the corresponding business class object does not exist in the class object cache container, the runtime class loading interface is called through reflection mechanism to load the corresponding business class object according to the target business class identifier, and the loaded business class object is determined as the target business class and the target business class is stored in the class object cache container.

[0074] In this embodiment, using the target business class identifier as the index key, the query to see if a corresponding business class object already exists in the preset class object cache container is a retrieval operation that utilizes memory caching to accelerate class object retrieval. The target business class identifier, as a string key, is typically the fully qualified class name. The preset class object cache container is a data structure maintained in memory with key-value pair storage characteristics, such as a ConcurrentHashMap. Its key is designed as the target business class identifier in string form, and the value is a previously successfully loaded and cached business class object, which is an instance of type java.lang.Class. The query action is implemented by calling the get method of the cache container and passing in the target business class identifier string. The cache container internally uses a hash function to map the key to a specific storage location, thereby quickly determining whether the key has an associated cached Class object. The purpose of this query operation is to prioritize retrieving the existing class definition from high-speed memory before actually performing the resource-intensive reflection class loading, thereby avoiding the performance overhead caused by repeated loading.

[0075] If a corresponding business class object already exists in the class object cache container, the existing business class object is identified as the target business class, which is a cache hit process. When the query operation returns a non-null Class object reference, it indicates that the same target business class identifier has been processed in the system before, and the bytecode of that class has been loaded, linked, and initialized, and its Class object reference has been actively stored in the cache. At this time, the system does not need to trigger any disk I / O, bytecode verification, or class initialization process again, and directly outputs the cached Class object reference as the "target business class" required by the current process. This identification action is essentially assigning the internally cached Class object reference to the variable representing the "target business class" or passing it to subsequent processing steps, completing the fast resolution from identifier to class object.

[0076] If the corresponding business class object does not exist in the class object cache container, the runtime class loading interface is invoked through reflection to load the corresponding business class object based on the target business class identifier. This is a dynamic class loading process when the cache misses. When the cache query returns null, the system needs to perform a complete reflection class loading. This process is initiated through the reflection API provided by the programming language runtime, such as calling the `Class.forName(String className)` method or the `ClassLoader.loadClass(String name)` method in Java, passing the target business class identifier string as a parameter. After receiving the loading request, the runtime environment delegates it to the corresponding class loader, which locates the `.class` bytecode file matching the fully qualified class name in the file system, network location, or JAR package according to the classpath settings. Subsequently, the class loader reads the bytecode, performs necessary verification, preparation, and parsing, and finally completes the class initialization, generating a `Class` object representing the class. This newly generated `Class` object is the loaded business class object. Next, the system identifies this newly loaded business class object as the target business class, assigning it the same role as the cache hit path for use in subsequent steps. Simultaneously, the system performs a crucial cache write operation, storing the newly loaded Class object into the class object cache container using the target business class identifier as the key. This write operation needs to consider thread safety in concurrent scenarios. For example, the `putIfAbsent` method of `ConcurrentHashMap` can be used to ensure that loading the same class identifier under high concurrency requests does not lead to multiple threads repeatedly loading and caching multiple identical Class object instances, thereby ensuring cache consistency and avoiding resource waste.

[0077] This embodiment introduces a memory cache container with the target business class identifier as the key, and queries this cache first before reflection loading. When the cache is hit, the existing class object is directly reused; only when the cache is not hit is a full reflection loading performed and the result is backfilled into the cache. This constructs an efficient, self-filling class object retrieval mechanism. This mechanism persistently resides frequently used class definitions in high-speed memory, avoiding the systemic overhead of disk I / O, bytecode verification, class initialization, and security permission checks caused by repeated reflection loading operations for the same business class. This significantly reduces the processing latency of individual requests and improves the overall system throughput. At the same time, the introduction of caching reduces the pressure of repeated access to the underlying class loader and file system, enhancing the stability and resource utilization efficiency of the system in concurrent scenarios.

[0078] In one embodiment, step S40 above includes: S401, determine the target object type identifier based on the target field identifier and the business operation item; S402, combine the target field identifier, the business operation item, and the target object type identifier to obtain a combined index key; S403, use the combined index key to query whether a corresponding reflection object exists in the reflection member cache; S404, if there is no corresponding reflection object in the reflection member cache, then when the target object type identifier indicates a field object, the field object is obtained from the target business class using the reflection mechanism with the target field identifier as a parameter, and the field object is used as the target reflection operation object; when the target object type identifier indicates a method object, the method name is determined according to the business operation item, the method object matching the method name is obtained from the target business class using the reflection mechanism, and the method object is used as the target reflection operation object; S405, Set the accessibility of the target reflection operation object to an allowed access state; S406, the target reflection operation object is stored in the reflection member cache using the combined index key.

[0079] In this embodiment, determining the target object type identifier based on the target field identifier and the business operation item is a decision-making process based on configuration rules or predefined strategies. The target field identifier specifies the name of the specific field to be operated on in the business class, while the business operation item describes the business function to be performed. By analyzing the combination of these two, it can be deduced whether the current operation intent is to be achieved by directly modifying the field value or by calling a specific business method. The target object type identifier is a classification marker, such as an enumeration value or a specific string constant, used to explicitly indicate whether the reflection operation object to be obtained this time is a java.lang.reflect.Field object representing a class field or a java.lang.reflect.Method object representing a class method. This determination process may be based on explicit declarations in the configuration information, such as specifying the operation type for each data change element in the mapping relationship; it may also be based on naming conventions or implicit rules of business logic, such as operation items with certain specific prefixes always corresponding to method calls.

[0080] Combining the target field identifier, business operation item, and target object type identifier to obtain a composite index key is an operation that constructs a unique identifier. These three elements together constitute a complete context describing a specific reflection operation scenario. The combination method typically involves concatenating these three strings into a new string using a specific delimiter, such as the format "business operation item:target field identifier:type identifier". This combination ensures that even the same target field identifier and business operation item will produce different keys under different operation types (such as field access and method call), thus distinguishing them as different entries in the cache. The generation of the composite index key must follow deterministic rules to ensure that the same input always produces the same output, providing a reliable key value for subsequent cache queries.

[0081] Checking the reflection member cache for the existence of a corresponding reflection object using the composite index key is a key step in improving the efficiency of retrieving reflection objects using memory caching. The reflection member cache is a key-value pair storage structure maintained in the application's memory, such as a thread-safe ConcurrentHashMap. Its key is the composite index key mentioned above, and its value is a Field or Method object instance that has been successfully retrieved previously and may have undergone preprocessing (such as setting accessibility). The query is performed by calling the get method of the cached data structure and passing in the composite index key. If an entry associated with that key exists in the cache, the corresponding reflection object is returned directly, avoiding the need to repeatedly perform the costly reflection lookup operation.

[0082] If the corresponding reflection object does not exist in the reflection member cache, it is processed according to the path indicated by the target object type identifier. When the target object type identifier indicates a field object, the system calls the `getDeclaredField` method of the `Class` object of the target business class, passing the target field identifier string as a parameter. This method searches for a field with an exact name match among all declared fields of the target business class and returns its corresponding `Field` object. Then, this `Field` object is assigned to the variable representing the target reflection operation object. When the target object type identifier indicates a method object, the system first parses or maps the specific method name according to the business operation item. This can be done by looking up a preset mapping table or by deriving it from the business operation item according to certain naming conversion rules. Then, the system calls the `getDeclaredMethod` method of the `Class` object of the target business class, passing the method name string and an optional array of method parameter types to obtain the corresponding `Method` object, and assigns this object to the target reflection operation object.

[0083] Setting the accessibility of the target reflection object to an allowed state is a necessary preparatory operation for the obtained Field or Method object. Since fields and methods in business classes are often declared as private to encapsulate their internal implementation, direct access or invocation via reflection will be blocked by Java's access control mechanism. By calling the `setAccessible(true)` method of the reflection object, this access check can be temporarily suppressed, allowing subsequent assignment or invocation operations to proceed smoothly. This operation must be completed before the first substantive operation is performed using the reflection object.

[0084] Storing the target reflection operation object in the reflection member cache using a composite index key is a data backfilling operation that provides a fast path for future identical requests after the reflection object has been acquired and preprocessed. The system uses the same composite index key as the key and the newly acquired Field or Method object with its accessibility already set as the value, placing it into the reflection member cache data structure. In a concurrent environment, this write operation must be thread-safe, typically using ConcurrentHashMap's putIfAbsent method or similar atomic methods to prevent resource waste or inconsistencies caused by multiple threads simultaneously loading and caching the same reflection object.

[0085] This embodiment determines the object type based on the operation context, constructs a composite cache key, and establishes a reflection object caching mechanism that includes type differentiation, dynamic loading, and access permission preprocessing. This removes the high-cost class structure exploration and permission setting overhead of reflection operations from each request. Repeated reflection requests under the same business scenario are directly satisfied through caching, enabling the reflection-based dynamic dispatch mechanism to achieve performance close to static code compilation and execution, while maintaining the flexibility and dynamism of the architecture.

[0086] In one embodiment, step S50 above includes: S501, the attribute constraint strategy is parsed to identify the verification strategy type identifier and the corresponding verification threshold parameter contained in the attribute constraint strategy. S502, based on the data type of the parameter value to be changed, convert the parameter value to be changed into a target data format value that is compatible with the verification strategy type identifier; S503, the verification logic factory calls the corresponding logic verification unit according to the verification strategy type identifier; S504, The target data format value and the verification threshold parameter are passed to the logical verification unit for comparison processing; S505, based on the result of the comparison process, determine whether the legality verification of the parameter value to be changed has passed; S506, if the comparison process results show that the target data format value meets the requirements of the attribute constraint strategy, then the validity verification of the parameter value to be changed is determined to be passed; S507, if the result of the comparison process indicates that the target data format value does not meet the requirements of the attribute constraint strategy, then it is determined that the validity verification of the parameter value to be changed has failed.

[0087] In this embodiment, parsing the attribute constraint policy to identify the validation policy type identifier and corresponding validation threshold parameter is a process of converting declarative configuration rules into an interpretable data structure in memory. The attribute constraint policy is initially stored in serialized form, such as a JSON string array, whose structure might be [{"type":"MaxLength","params":"100"},{"type":"NumberRange","params":{"min":0,"max":100}}]. The parsing process calls the appropriate data binding library (such as Jackson's ObjectMapper) to deserialize the string into a list of rule objects. Each rule object contains two key fields: a validation policy type identifier, a string keyword used to uniquely distinguish different validation algorithms; and a validation threshold parameter, a value object bound to the type identifier and used to specify the validation conditions. The result of the parsing is an internal program object containing an ordered list of rules, which precisely describes all the validation logic that needs to be executed sequentially and its specific parameters.

[0088] Based on the data type of the parameter value to be changed, converting it into a target data format value that matches the validation strategy type identifier is a data preprocessing and type adaptation operation. The parameter value to be changed originates from an external request, and its original form is usually a string. However, the validation logic units corresponding to different validation strategy type identifiers may have different expected input data types. For example, the "NumberRange" validation unit expects a numeric object (such as Integer or BigDecimal) as input, while the "DateAfter" validation unit expects a date object (such as LocalDate). The conversion operation first analyzes the validation strategy type identifier of the first rule to be executed to determine its expected target data type. Subsequently, the system calls the converter corresponding to the target data type to transform the original string parameter value. For example, converting the string "150" to the integer 150, or parsing the string "2024-01-01" into a LocalDate object using a date formatter. This conversion ensures that the original parameter value can be correctly understood and processed by subsequent validation logic units, serving as a necessary bridge connecting general inputs and dedicated validation logic.

[0089] The validation logic factory invokes the corresponding logical validation unit based on the validation strategy type identifier, which is a dynamic service location and instance acquisition process based on identifiers. The validation logic factory is a registry center managing all available validation units. Internally, it maintains a mapping table where the keys are various validation strategy type identifier strings, and the values ​​are the corresponding validation unit instance or the factory method that creates that instance. A validation unit is an independent class that implements a unified validation interface (such as Validator), for example, MaxLengthValidator or NumberRangeValidator, and each class encapsulates a specific validation algorithm. When a validation strategy type identifier is passed in, the factory queries its internal mapping table to find the corresponding validation unit class and instantiates or returns a cached singleton instance. This process achieves pluggable validation logic; adding a new validation rule only requires developing a new validation unit class and registering its type identifier in the factory, without modifying any of the main flow code that calls the factory.

[0090] The core step in executing the specific validation algorithm is to pass the target data format value and the validation threshold parameter to the logical validation unit for comparison. After obtaining the validation unit instance, the system calls the validation method of that instance, such as `validate(Object input, Object ruleParam)`. The target data format value is passed as the first parameter `input`, and the validation threshold parameter is passed as the second parameter `ruleParam`. The internal logic of the validation unit is entirely defined by its algorithm. Taking `NumberRangeValidator` as an example, its internal logic will forcibly convert `input` to a numeric type, extract the minimum and maximum values ​​from the `ruleParam` object, and then execute the `if (inputValue>= min&&inputValue<= max)` condition. The execution of the validation unit is purely functional, depends only on the input parameters, does not produce side effects, and ultimately returns a boolean result indicating success or failure, or a validation result object containing the result and detailed information.

[0091] Based on the comparison results, determining whether the validity verification of the parameter value to be changed passes is a decision-making process based on the rule execution results. After the system has driven the verification units of all relevant rules (there may be multiple rules) to complete execution, it will collect a result set. The judgment logic traverses this result set. If all results in the set indicate success, the overall judgment is that the verification has passed. This judgment signifies that the parameter value to be changed satisfies all predefined external constraints.

[0092] If the comparison results indicate that the target data format value meets the requirements of the attribute constraint strategy, then the validity verification is deemed successful. This is the specific output of the successful verification conclusion. The system passes this conclusion as a status flag to subsequent processing flows, allowing subsequent reflection assignments or method calls to continue execution.

[0093] If the comparison results indicate that the target data format value does not meet the requirements of the attribute constraint policy, the validity verification is deemed to have failed. This is the specific output of the verification failure conclusion. Once the verification unit of any rule returns a failure result, the system can immediately interrupt the execution of the remaining rules (short-circuit logic) and directly make this judgment. Simultaneously with the judgment failing, it is usually necessary to construct an error object containing information such as the failed rule type identifier, expected value, and actual value, and based on this, interrupt the entire change process, feeding back the specific reason for the business violation to the requesting party.

[0094] This embodiment constructs a highly modular and scalable declarative data verification framework by linking the parsing of verification strategies, the type adaptation of input data, the dynamic factory-based positioning of verification logic, and the result-based decision mechanism into a complete process. Changes in business constraints are entirely transformed into the management of configuration data and independent verification units, while the core verification process remains stable. This allows data verification rules to evolve, test, and deploy independently in a completely decoupled manner from business logic. The system can quickly respond to changes in compliance requirements, while ensuring the consistency and maintainability of verification behavior, and guaranteeing processing efficiency through mechanisms such as short-circuit decision.

[0095] In one embodiment, step S60 above includes: S601, Call the query interface to retrieve and load the current target business object instance from the database using the target business object identifier as the index key; S602, Set the accessibility of the target reflection operation object to an allowed access state; S603, determine the type of the target reflection operation object; S604, if the target reflection operation object is a field object, then the set method of the field object is called through the reflection mechanism, the target business object instance is used as the operation target parameter of the set method, and the parameter value to be changed is used as the input value parameter of the set method; S605, if the target reflection operation object is a method object, then the invoke method of the method object is called through the reflection mechanism, the target business object instance is used as the operation target parameter of the invoke method, and the parameter value to be changed is used as the input parameter of the invoke method; S606, call the update interface to save the target business object instance with the modified state to the database to complete the change.

[0096] In this embodiment, calling the query interface to retrieve and load the current target business object instance from the database using the target business object identifier as the index key is a process of rematerializing persistent data state into an operable program object in memory. The query interface is an abstract method provided by the data access layer, whose implementation encapsulates the details of interacting with a specific database, such as using the `find` method of JPA EntityManager, parameterized SQL queries executed by JdbcTemplate, or the `findById` method of an ORM framework repository. The target business object identifier serves as the core input parameter of this method, and its value is constructed as a condition part of the database query statement, such as `id=?` in the SQL WHERE clause. After executing the query, the database returns a result set of records matching the identifier. The system then maps the column data in the result set to the corresponding fields of the target business class, that is, by calling the constructor or setter method, populating a complete business object instance that carries the current state stored in the database. This instance is the concrete memory carrier for subsequent reflection operations; its successful loading ensures that the change operation has a clear target.

[0097] Setting the accessibility of the target reflection object to an allowed state is a necessary pre-access permission action before executing reflection operations. The target reflection object (Field or Method) typically points to a private member in a business class. Java's runtime access control mechanism by default prohibits external code from directly accessing these private members via reflection. Calling the `setAccessible(true)` method of the reflection object requests the virtual machine to temporarily disable access checks for this specific object. This operation modifies a flag within the reflection object, allowing it to bypass access permission verification in subsequent `set` or `invoke` calls. This is a crucial balance between security and functionality, enabling configuration-driven general change mechanisms to apply to the internal state of business classes designed according to encapsulation principles.

[0098] Determining the type of the target reflection object is a decision point based on the object's runtime type information. Using built-in language type checking operators (such as Java's `instanceof`) or comparing the object's Class information, it can be determined whether the object is an instance of the `java.lang.reflect.Field` class or the `java.lang.reflect.Method` class. This determination directly determines the specific reflection API branch to be invoked during subsequent modification operations, i.e., whether to choose a field assignment path or a method call path. The determination logic is deterministic and depends entirely on the nature of the reflection object determined during the previous configuration and retrieval stages.

[0099] If the target object for reflection is a field object, the `set` method of that field object is called via reflection. The target business object instance is used as the target parameter of the `set` method, and the value to be changed is used as the input parameter. The `set(Object obj, Object value)` method of the field object requires two parameters. The first parameter, `obj`, specifies the specific object instance to which this field belongs. Here, a loaded target business object instance is passed, meaning the operation will be applied to this specific instance rather than the class template. The second parameter, `value`, is the new value to be set for this field. Here, a validated value to be changed is passed. When the method is executed, the reflection mechanism directly finds the storage location corresponding to the field in the memory layout of the passed-in target business object instance and writes the new value to that location, thereby directly modifying the field state of the instance.

[0100] If the target object for reflection is a method object, the `invoke` method of that method object is invoked via reflection. The target business object instance is passed as the target parameter of the `invoke` method, and the value of the parameter to be changed is passed as the input parameter of the `invoke` method. In the `invoke(Object obj, Object... args)` method of the method object, the first parameter `obj` specifies the object instance on which this method is called. Passing the target business object instance here ensures that the context of the method call is a specific business entity. The second variable parameter `args` is used to pass the actual parameters required for the method call. Here, a single value of the parameter to be changed is usually encapsulated as an array and passed in. The execution of the `invoke` method triggers the original logic of the method in the target business object instance. The passed parameter values ​​are consumed by the code inside the method, which usually leads to complex calculations and updates of the instance's internal state. This is an indirect, behavior-triggered method of state change.

[0101] Calling the update interface to save the modified target business object instance to the database to complete the change is the final step in achieving data persistence. The update interface is another abstraction provided by the data access layer, used to synchronize the state of in-memory objects back to persistent storage. Its implementation may call the `merge` method of `EntityManager`, or construct and execute an SQL `UPDATE` statement containing the update fields. This operation takes the target business object instance modified by reflection as input; the system or framework automatically detects the change in instance state and generates the corresponding data update command. This step is typically within the same database transaction context as the initial query load operation, ensuring the atomicity of the entire "read-modify-write" sequence, thereby maintaining data consistency.

[0102] For example, in an insurance business management system, the system pre-defines various policy maintenance operations (i.e., business operation items) and their related rules through configuration information. First, during the configuration process, the system constructs a metadata model containing all potentially changeable elements. For instance, the model defines a data change element called "Renewal Date," with its target field identified as "renewalDate," and configures attribute constraint policies for it, including the rule type identifier "DateAfter" and the parameter "Effective Date," as well as the rule type identifier "Required." Simultaneously, the model also defines an element called "Premium Adjustment Amount," with its target field identified as "premiumAdjustment," and attribute constraint policies including the rule type identifier "NumberRange" and the parameter "min:0," and the rule type identifier "DecimalScale" and the parameter "scale:2." Next, the system creates a separate configuration node for the policy maintenance item "Policy Renewal," and specifies its target business class identifier as "com.insurance.service.PolicyRenewalService" within this node. Then, the system selects two data change elements, "renewal date" and "premium adjustment amount," from the metadata model and adds them to the association list of the "policy renewal" configuration node, thus establishing a mapping relationship between this policy item and the specific data change element. Finally, the system serializes the entire data structure, including this mapping relationship, all target field identifiers, attribute constraint policies, and target business class identifiers, into a JSON format configuration file and stores it in the server's file system, completing the fully externalized configuration of the business rules.

[0103] When an insured submits a policy renewal application through a mobile application, the application frontend constructs a change request. This request is sent to the system backend as an HTTP POST request data packet. The packet body is in JSON format and contains the business operation item identifier "policyRenewal", the target business object identifier (i.e., the policy number) "POL-20240001", and the parameter value object to be changed, such as {"renewalDate": "2025-12-31", "premiumAdjustment":1500.00}. After receiving this data packet, the backend service gateway calls the JSON parsing library to parse it, accurately identifying the target business object identifier "POL-20240001", the parameter value object to be changed, and the operation code "policyRenewal" used to index the business operation item.

[0104] Subsequently, the system uses the parsed operation code "policyRenewal" as the index key to query the configuration information hash map already loaded into memory, quickly locating the configuration node for the business operation item named "Policy Renewal". From this configuration node, the system directly reads the fully qualified class name string "com.insurance.service.PolicyRenewalService", which is the target business class identifier. Next, the system traverses the associated list under this configuration node, which contains references to two data change elements: "Renewal Date" and "Premium Adjustment Amount". For each item in the list, the system obtains its predefined target field identifiers ("renewalDate" and "premiumAdjustment") and the corresponding attribute constraint policy. At the same time, based on the key name of the parameter value object to be changed, the system establishes a one-to-one correspondence between the specific values ​​("2025-12-31" and 1500.00) and their respective target field identifiers, preparing for subsequent processing.

[0105] Next, the system needs to load the specific class that executes the business logic. It first queries a pre-defined class object cache container (a ConcurrentHashMap) using the target business class identifier "com.insurance.service.PolicyRenewalService" as the key. Assuming this is the first time the system has processed a "policy renewal" operation since startup, the cache is not found. Therefore, the system uses Java reflection to call the `loadClass` method of the current thread's context class loader, loading the corresponding bytecode based on the fully qualified class name. Upon success, a `Class` object representing the `PolicyRenewalService` class is generated in memory. The system immediately identifies this `Class` object as the "target business class" required for this step and simultaneously stores it in the class object cache container with the key "com.insurance.service.PolicyRenewalService" for quick reuse in subsequent requests.

[0106] Next, the system needs to obtain the reflection operation object that actually performs the change. Based on the current business scenario (target field identifier and business operation item), it determines that the target object type identifier is "field object" because the "policy renewal" operation is configured to directly modify entity fields. The system combines the target field identifier "renewalDate", the business operation item "policyRenewal", and the target object type identifier "FIELD" to obtain the composite index key "policyRenewal:renewalDate:FIELD". The system uses this composite index key to query whether the corresponding reflection object is cached in a dedicated reflection member cache. The first query naturally fails. Therefore, the system uses the reflection mechanism, with "renewalDate" as the parameter, to call the getDeclaredField method from the associated entity class Policy of the loaded PolicyRenewalService class to obtain the Field object representing the renewal date. The system uses this Field object as the target reflection operation object and immediately calls its setAccessible(true) method to set its accessibility to an allowed state. Finally, the system stores this prepared Field object in the reflection member cache using the composite index key "policyRenewal:renewalDate:FIELD". For the "premium adjustment amount" field, the system repeats this process, generating the index key "policyRenewal:premiumAdjustment:FIELD", and retrieving and caching the corresponding Field object.

[0107] After obtaining the target reflection operation object, the system performs strict validity verification on the parameter value to be changed. For the value "2025-12-31" of "renewal date", the system first parses the rule list from its attribute constraint policy: rule one is identified as "DateAfter" with the parameter "effective date"; rule two is identified as "Required". Next, based on the data type (string) of the value to be verified and the first rule type identifier "DateAfter", the system converts the string "2025-12-31" into a target data format value of type LocalDate using a date formatter. Then, the system uses a verification logic factory to obtain the corresponding date post-verification unit instance based on the "DateAfter" identifier, and passes the target data format value (LocalDate object) and the rule parameter "effective date" to the verification unit for comparison. The verification logic will determine whether the new date is after the effective date. Subsequently, the factory obtains the required verification unit based on the "Required" identifier. Since the value is not empty, the verification passes. All rules pass the verification, and the system determines that the validity verification of "renewal date" is successful. For the "Premium Adjustment Amount" value of 1500.00, the system also performs parsing, conversion (to BigDecimal), and comparison by calling the numerical range verification unit and precision verification unit. After all checks pass, the verification is deemed successful.

[0108] After all legality verifications pass, the system begins to execute the substantive changes. First, it calls the query interface of the data access layer, using the target business object identifier "POL-20240001" as the index key, sends a query to the database, retrieves the corresponding policy record, and waters it into an instance of a Policy entity class—the current target business object instance. The system ensures that the accessibility of the two previously obtained Field reflection operation objects (corresponding to `renewalDate` and `premiumAdjustment`) is allowed. Since the target reflection operation objects are both field objects, the system uses reflection to call the `set` method on the first Field object, passing the target business object instance (Policy object) and the converted `LocalDate` value as parameters, directly modifying the `renewalDate` field value of that instance. Next, it calls the `set` method on the second Field object, passing the same instance and a `BigDecimal` value, modifying the `premiumAdjustment` field. The state of the business object instance in memory is thus updated. Finally, within a database transaction, the system calls the update interface to synchronously save the modified target business object instance to the database, thus persistently completing the policy renewal change. The entire process is configuration-driven and dynamically executed through reflection, eliminating the need to write any hard-coded specific processing logic for the "policy renewal" operation.

[0109] This embodiment constructs a complete closed-loop operation chain from identification to instance, from configuration to execution, and from memory to storage by combining precise database object loading, necessary reflection access permission preparation, explicit reflection type branch judgment, and parameterized reflection calls for fields or methods, ultimately culminating in transactional data persistence. This chain transforms dynamically determined change intentions into lossless and precise modifications to the memory state or triggering of actions for specific business object instances through reflection, ensuring the persistent storage of modification results. This allows data update operations on any business entity, whether simple field assignments or complex method logic triggers, to be driven by the same robust mechanism, achieving extreme generalization and high reusability of business change execution logic, while ensuring the eventual consistency and reliability of core business data changes through database transactions.

[0110] In one embodiment, a business data change configuration processing apparatus is provided, which corresponds one-to-one with the business data change configuration processing method in the above embodiments. (Refer to...) Figure 3 , Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the business data change configuration processing device of the present invention. The modules include a configuration construction module 10, a configuration parsing module 20, a class loading module 30, a reflection object location module 40, a rule validation module 50, and an instance change module 60. Detailed descriptions of each functional module are as follows: The configuration building module 10 is used to store the mapping relationship between business operation items and data change elements, the target field identifier and attribute constraint strategy of the data change elements, and the target business class identifier corresponding to the business operation items in the configuration information. The configuration parsing module 20 is used to respond to a change request for the business operation item by obtaining from the configuration information the target business class identifier corresponding to the business operation item, the target field identifier of at least one associated data change element, and the attribute constraint strategy corresponding to the data change element. The change request includes the target business object identifier and the parameter value to be changed. The class loading module 30 is used to load the target business class through reflection mechanism according to the target business class identifier; The reflection object positioning module 40 is used to obtain the target reflection operation object from the target business class through the reflection mechanism based on the target field identifier and the business operation item. The rule verification module 50 is used to verify the legality of the parameter value to be changed according to the attribute constraint strategy. The instance change module 60 is used to locate the target business object instance based on the target business object identifier after the legality verification is passed, and to perform a change operation using the target reflection operation object through the reflection mechanism to update the parameter value to be changed to the target business object instance.

[0111] In one embodiment, the configuration building module 10 is specifically used for: Construct a metadata model containing data change elements, and define the target field identifiers corresponding to the data change elements and the attribute constraint strategies for verifying data legality in the metadata model; Create a configuration node for the business operation item, and specify the corresponding fully qualified class name as the target business class identifier for the business operation item; At least one data change element is selected from the metadata model and assigned to the configuration node to establish a mapping relationship between the business operation item and the data change element; The data structure containing the mapping relationship, the target field identifier, the attribute constraint strategy, and the target business class identifier is serialized to obtain configuration information, and the configuration information is saved to the storage medium.

[0112] In one embodiment, the parsing module 20 is configured to: The system receives data packets carried by the network transmission protocol as change requests and parses the data packets to distinguish the target service object identifier, the parameter value to be changed, and the operation code used to index the service operation item. Using the operation code as the index key, query and locate the corresponding business operation item configuration node in the configuration information; Read the fully qualified class name string from the business operation item configuration node as the target business class identifier; Traverse the associated list under the configuration node of the business operation item, obtain the target field identifier and attribute constraint strategy defined for each data change element, and establish the correspondence between the parameter value to be changed and the target field identifier.

[0113] In one embodiment, the class loading module 30 is specifically used for: Using the target business class identifier as the index key, query whether the corresponding business class object already exists in the preset class object cache container; If a corresponding business class object already exists in the class object cache container, then the existing business class object is determined as the target business class; If the corresponding business class object does not exist in the class object cache container, the runtime class loading interface is called through reflection mechanism to load the corresponding business class object according to the target business class identifier, and the loaded business class object is identified as the target business class and stored in the class object cache container.

[0114] In one embodiment, the reflection object positioning module 40 is specifically used for: The target object type identifier is determined based on the target field identifier and the business operation item; The target field identifier, the business operation item, and the target object type identifier are combined to obtain a composite index key; Use the combined index key to query whether a corresponding reflection object exists in the reflection member cache; If the corresponding reflection object does not exist in the reflection member cache, then when the target object type identifier indicates a field object, the reflection mechanism is used to obtain the field object from the target business class with the target field identifier as a parameter, and the field object is used as the target reflection operation object; when the target object type identifier indicates a method object, the method name is determined according to the business operation item, the reflection mechanism is used to obtain the method object matching the method name from the target business class, and the method object is used as the target reflection operation object. Set the accessibility of the target reflection operation object to an allowed access state; The target reflection operation object is stored in the reflection member cache using the combined index key.

[0115] In one embodiment, the rule verification module 50 is specifically used for: The attribute constraint strategy is parsed to identify the verification strategy type identifier and the corresponding verification threshold parameter contained in the attribute constraint strategy; Based on the data type of the parameter value to be changed, convert the parameter value to be changed into a target data format value that is compatible with the verification strategy type identifier; The corresponding logical verification unit is invoked using the verification logic factory based on the verification strategy type identifier. The target data format value and the verification threshold parameter are passed to the logical verification unit for comparison processing; Based on the results of the comparison process, it is determined whether the validity verification of the parameter value to be changed has passed. If the comparison process results in that the target data format value meets the requirements of the attribute constraint strategy, then the validity verification of the parameter value to be changed is deemed to have passed. If the comparison process results in that the target data format value does not meet the requirements of the attribute constraint strategy, then the validity verification of the parameter value to be changed is deemed to have failed.

[0116] In one embodiment, the instance change module 60 is specifically used for: Call the query interface to retrieve and load the current target business object instance from the database using the target business object identifier as the index key; Set the accessibility of the target reflection operation object to an allowed access state; Determine the type of the target reflection operation object; If the target reflection operation object is a field object, then the set method of the field object is called through the reflection mechanism, with the target business object instance as the operation target parameter of the set method and the parameter value to be changed as the input value parameter of the set method; If the target reflection operation object is a method object, then the invoke method of the method object is called through the reflection mechanism, with the target business object instance as the operation target parameter of the invoke method and the parameter value to be changed as the input parameter of the invoke method; Call the update interface to save the target business object instance with the modified state to the database to complete the change.

[0117] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4 As shown. The computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a business data change configuration processing method on the server side.

[0118] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements the client-side functions or steps of a business data change configuration processing method.

[0119] In one embodiment, 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 perform the following steps: The mapping relationship between business operation items and data change elements, the target field identifier and attribute constraint strategy of the data change elements, and the target business class identifier corresponding to the business operation items are stored in the configuration information. In response to a change request for the business operation item, the target business class identifier corresponding to the business operation item, the target field identifier of at least one associated data change element, and the attribute constraint strategy corresponding to the data change element are obtained from the configuration information. The change request includes a target business object identifier and a parameter value to be changed. Based on the target business class identifier, the target business class is loaded using a reflection mechanism; Based on the target field identifier and the business operation item, the target reflection operation object is obtained from the target business class through reflection mechanism; The validity of the parameter value to be changed is verified according to the attribute constraint strategy. After the legality verification is passed, the target business object instance is located based on the target business object identifier, and the change operation is performed using the target reflection operation object through the reflection mechanism to update the parameter value to be changed to the target business object instance.

[0120] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, and a computer program is stored thereon, which, when executed by a processor, performs the following steps: The mapping relationship between business operation items and data change elements, the target field identifier and attribute constraint strategy of the data change elements, and the target business class identifier corresponding to the business operation items are stored in the configuration information. In response to a change request for the business operation item, the target business class identifier corresponding to the business operation item, the target field identifier of at least one associated data change element, and the attribute constraint strategy corresponding to the data change element are obtained from the configuration information. The change request includes a target business object identifier and a parameter value to be changed. Based on the target business class identifier, the target business class is loaded using a reflection mechanism; Based on the target field identifier and the business operation item, the target reflection operation object is obtained from the target business class through reflection mechanism; The validity of the parameter value to be changed is verified according to the attribute constraint strategy. After the legality verification is passed, the target business object instance is located based on the target business object identifier, and the change operation is performed using the target reflection operation object through the reflection mechanism to update the parameter value to be changed to the target business object instance.

[0121] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0122] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0123] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0124] It should be noted that if any software tools or components not belonging to our company appear in the embodiments of this application, they are merely for illustrative purposes and do not represent actual use.

[0125] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.< / t>

Claims

1. A method for processing business data change configurations, characterized in that, Includes the following steps: The mapping relationship between business operation items and data change elements, the target field identifier and attribute constraint strategy of the data change elements, and the target business class identifier corresponding to the business operation items are stored in the configuration information. In response to a change request for the business operation item, the target business class identifier corresponding to the business operation item, the target field identifier of at least one associated data change element, and the attribute constraint strategy corresponding to the data change element are obtained from the configuration information. The change request includes a target business object identifier and a parameter value to be changed. Based on the target business class identifier, the target business class is loaded using a reflection mechanism; Based on the target field identifier and the business operation item, the target reflection operation object is obtained from the target business class through reflection mechanism; The validity of the parameter value to be changed is verified according to the attribute constraint strategy. After the legality verification is passed, the target business object instance is located based on the target business object identifier, and the change operation is performed using the target reflection operation object through the reflection mechanism to update the parameter value to be changed to the target business object instance.

2. The business data change configuration processing method as described in claim 1, characterized in that, The mapping relationship between business operation items and data change elements, the target field identifier and attribute constraint strategy of the data change elements, and the target business class identifier corresponding to the business operation item are stored in the configuration information, including: Construct a metadata model containing data change elements, and define the target field identifiers corresponding to the data change elements and the attribute constraint strategies for verifying data legality in the metadata model; Create a configuration node for the business operation item, and specify the corresponding fully qualified class name as the target business class identifier for the business operation item; At least one data change element is selected from the metadata model and assigned to the configuration node to establish a mapping relationship between the business operation item and the data change element; The data structure containing the mapping relationship, the target field identifier, the attribute constraint strategy, and the target business class identifier is serialized to obtain configuration information, and the configuration information is saved to the storage medium.

3. The business data change configuration processing method as described in claim 1, characterized in that, In response to a change request for the business operation item, the system obtains from the configuration information the target business class identifier corresponding to the business operation item, the target field identifier of at least one associated data change element, and the attribute constraint policy corresponding to the data change element. The change request includes a target business object identifier and parameter values ​​to be changed, including: The system receives data packets carried by the network transmission protocol as change requests and parses the data packets to distinguish the target service object identifier, the parameter value to be changed, and the operation code used to index the service operation item. Using the operation code as the index key, query and locate the corresponding business operation item configuration node in the configuration information; Read the fully qualified class name string from the business operation item configuration node as the target business class identifier; Traverse the associated list under the configuration node of the business operation item, obtain the target field identifier and attribute constraint strategy defined for each data change element, and establish the correspondence between the parameter value to be changed and the target field identifier.

4. The business data change configuration processing method as described in claim 1, characterized in that, Based on the target business class identifier, the target business class is loaded via reflection, including: Using the target business class identifier as the index key, query whether the corresponding business class object already exists in the preset class object cache container; If a corresponding business class object already exists in the class object cache container, then the existing business class object is determined as the target business class; If the corresponding business class object does not exist in the class object cache container, the runtime class loading interface is called through reflection mechanism to load the corresponding business class object according to the target business class identifier, and the loaded business class object is identified as the target business class and stored in the class object cache container.

5. The business data change configuration processing method as described in claim 1, characterized in that, Based on the target field identifier and the business operation item, the target reflection operation object is obtained from the target business class through reflection mechanism, including: The target object type identifier is determined based on the target field identifier and the business operation item; The target field identifier, the business operation item, and the target object type identifier are combined to obtain a composite index key; Use the combined index key to query whether a corresponding reflection object exists in the reflection member cache; If the corresponding reflection object does not exist in the reflection member cache, then when the target object type identifier indicates a field object, the reflection mechanism is used to obtain the field object from the target business class with the target field identifier as a parameter, and the field object is used as the target reflection operation object; when the target object type identifier indicates a method object, the method name is determined according to the business operation item, the reflection mechanism is used to obtain the method object matching the method name from the target business class, and the method object is used as the target reflection operation object. Set the accessibility of the target reflection operation object to an allowed access state; The target reflection operation object is stored in the reflection member cache using the combined index key.

6. The business data change configuration processing method as described in claim 1, characterized in that, The validity of the parameter value to be changed is verified according to the attribute constraint strategy, including: The attribute constraint strategy is parsed to identify the verification strategy type identifier and the corresponding verification threshold parameter contained in the attribute constraint strategy; Based on the data type of the parameter value to be changed, convert the parameter value to be changed into a target data format value that is compatible with the verification strategy type identifier; The corresponding logical verification unit is invoked using the verification logic factory based on the verification strategy type identifier. The target data format value and the verification threshold parameter are passed to the logical verification unit for comparison processing; Based on the results of the comparison process, it is determined whether the validity verification of the parameter value to be changed has passed. If the comparison process results in that the target data format value meets the requirements of the attribute constraint strategy, then the validity verification of the parameter value to be changed is deemed to have passed. If the comparison process results in that the target data format value does not meet the requirements of the attribute constraint strategy, then the validity verification of the parameter value to be changed is deemed to have failed.

7. The business data change configuration processing method as described in claim 1, characterized in that, After the legality verification is passed, the target business object instance is located based on the target business object identifier, and a change operation is performed using the target reflection operation object through a reflection mechanism to update the parameter value to be changed to the target business object instance, including: Call the query interface to retrieve and load the current target business object instance from the database using the target business object identifier as the index key; Set the accessibility of the target reflection operation object to an allowed access state; Determine the type of the target reflection operation object; If the target reflection operation object is a field object, then the set method of the field object is called through the reflection mechanism, with the target business object instance as the operation target parameter of the set method and the parameter value to be changed as the input value parameter of the set method; If the target reflection operation object is a method object, then the invoke method of the method object is called through the reflection mechanism, with the target business object instance as the operation target parameter of the invoke method and the parameter value to be changed as the input parameter of the invoke method; Call the update interface to save the target business object instance with the modified state to the database to complete the change.

8. A business data change configuration processing device, characterized in that, The business data change configuration processing device includes: The configuration building module is used to store the mapping relationship between business operation items and data change elements, the target field identifier and attribute constraint strategy of the data change elements, and the target business class identifier corresponding to the business operation item in the configuration information; The configuration parsing module is used to respond to a change request for the business operation item by obtaining from the configuration information the target business class identifier corresponding to the business operation item, the target field identifier of at least one associated data change element, and the attribute constraint strategy corresponding to the data change element. The change request includes the target business object identifier and the parameter value to be changed. The class loading module is used to load the target business class through reflection based on the target business class identifier. The reflection object location module is used to obtain the target reflection operation object from the target business class through the reflection mechanism based on the target field identifier and the business operation item. The rule verification module is used to verify the legality of the parameter value to be changed according to the attribute constraint strategy. The instance change module is used to locate the target business object instance based on the target business object identifier after the legality verification is passed, and to perform a change operation using the target reflection operation object through the reflection mechanism to update the parameter value to be changed to the target business object instance.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a business data change configuration processing program stored in the memory and executable on the processor. When the business data change configuration processing program is executed by the processor, it implements the steps of the business data change configuration processing method as described in any one of claims 1-7.

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

Images