System and method for annotation-driven business object change identification and log generation

Abstract

The application discloses an annotation-driven business object change recognition and log generation system and method, and the system is based on a four-layer architecture design and comprises an annotation-driven module, a type strategy module, a reflection processing module and an ID conversion module.The annotation-driven module is configured to compare annotation-related parameters and support log output and field comparison.The type strategy module is configured to realize a strategy mode through comparison enumeration, and each data type corresponds to a comparison function interface.The reflection processing module is configured to obtain all fields of a current class and parent classes through recursive scanning, support complete field scanning of inheritance relationships, avoid repeated reflection operations through a class field cache mechanism, and the ID conversion module is configured to define a unified ID conversion specification through a functional conversion interface, provide a plurality of conversion implementation classes, and configure a conversion interface singleton cache mechanism.The scheme realizes automatic recognition of business field changes, type conversion and log generation, supports unified processing of a plurality of data types, and significantly improves development efficiency and system maintainability.

Description

Technical Field

[0001] This invention relates to the field of enterprise business data change tracking technology, and in particular to a system and method for identifying and generating logs of business object changes based on annotations. Background Technology

[0002] Enterprise business data change tracking aims to record "who, when, what data, and what changes were made" to meet needs such as problem investigation, audit compliance, and data rollback. Current enterprise-level business systems have the following technical deficiencies in handling business data change tracking:

[0003] (1) Low efficiency of change identification: Traditional solutions require manual writing of field comparison logic in each business method, which is inefficient. In complex business objects with 50+ fields, the amount of manual comparison code can reach 500+ lines, increasing development time by 3-5 times.

[0004] (2) High code coupling: The business logic and change monitoring logic are tightly coupled, resulting in poor code maintainability. When the business fields change, multiple change monitoring codes need to be modified simultaneously, increasing maintenance costs by more than 40%.

[0005] (3) Complex type conversion: When dealing with changes in different data types (strings, numbers, dates, dictionary values, associated objects, etc.), existing technologies require writing a large amount of type judgment and conversion logic, which results in high code complexity and is prone to conversion errors.

[0006] (4) Insufficient extensibility: When it is necessary to support new data types or change rules, the core comparison logic needs to be modified, which violates the open / closed principle. The system has poor extensibility, and adding a new data type requires modifying multiple core classes.

[0007] (5) Inconsistent log formats: The change log formats of different business modules are inconsistent, making it difficult to conduct unified data analysis and auditing, which affects the manageability and compliance requirements of the system.

[0008] These shortcomings lead to problems such as high development costs, maintenance difficulties, and poor scalability when enterprises implement business data change tracking, which seriously affects the development efficiency and operation and maintenance quality of the system. Summary of the Invention

[0009] To address the aforementioned technical problems, this invention provides a system and method for identifying and generating logs of business object changes based on annotations. By constructing an annotation-driven framework for identifying business object changes and combining Java reflection and functional programming concepts, the system achieves automatic identification, type conversion, and log generation of changes to business fields. The system employs strategy and factory patterns, supports unified processing of multiple data types, and significantly improves development efficiency and system maintainability.

[0010] This invention is achieved using the following technical solution:

[0011] Firstly, the annotation-driven business object change identification and log generation system is based on a four-layer architecture and includes the following modules:

[0012] Annotation-driven module: Configures parameters related to CompareAnnotation annotations and supports log output and field comparison;

[0013] The CompareAnnotation is declared using the @Target(ElementType.FIELD) and @Retention(RetentionPolicy.RUNTIME) meta-annotations. Its relevant parameters include columnName, compareEnum, timeType, dictionaryCodeEnum, transitionClass, and enableFunction (i.e., field display name, comparison type, time format, dictionary type, ID conversion class, and enabled function).

[0014] Type strategy module: Implements the strategy pattern through the CompareEnum comparison enumeration, with each data type corresponding to a comparison functional interface;

[0015] The CompareEnum comparison enumeration data types include STRING, NUMBER, DATE, SELECT, OTHER_ID, RELATION, BOOLEAN, and CUSTOM enumeration constants, and are compared through EnumMap. <CompareEnum, BiFunction<Object, Object, CompareResult> The data structure uses enumerated constants as keys to store the corresponding comparison functional interface implementations.

[0016] Reflection processing module: Retrieves all fields of the current class and its parent classes through recursive scanning, supporting complete field scanning of inheritance relationships; avoids repeated reflection operations through a class field caching mechanism;

[0017] The recursive scan iterates through `clazz.getSuperclass()` until it reaches `Object.class`, and the class field caching mechanism uses a globally static `ConcurrentHashMap`. <Class<?> List <field>The cache container uses Class objects as keys and a list of fields as values. When a target Class object is received, it is first searched in the cache container. If the target Class object is not found, a recursive scan is performed and the result is stored in the cache.

[0018] ID conversion module: Defines a unified ID conversion standard through a functional conversion interface, provides multiple conversion implementation classes, and configures a singleton caching mechanism for the conversion interface;

[0019] The singleton caching mechanism of the conversion interface uses ConcurrentHashMap. <Class<?> The `TransitionInterface` is a cache container that uses the Class object of the transformation class as the key and the singleton instance of the transformation class as the value. When an ID transformation is required, the transformation class instance is first retrieved from this cache container. If the ID is not found, it is instantiated through reflection and stored in the cache.

[0020] Specifically, the parameters related to the CompareAnnotation annotation in the annotation-driven module include: the field display name supported by CompareAnnotation, comparison type, time format, dictionary type, ID conversion class, and enabled function.

[0021] Specifically, the four-layer architecture includes:

[0022] Annotation definition layer: Defines the annotation class of CompareAnnotation, defines the configuration parameters including field name, comparison type, time format, dictionary enumeration and conversion class, and uses Java meta-annotations to declare the field-level scope and runtime retention strategy of CompareAnnotation;

[0023] Type processing layer: Implements processing strategies for different data types through CompareEnum comparison enumeration, supporting STRING, NUMBER, DATE, SELECT, OTHER_ID, RELATION, BOOLEAN and CUSTOM data types;

[0024] Reflection Execution Layer: Utilizes comparison utility classes to dynamically obtain object field values ​​through Java reflection, achieving precise field-level comparison;

[0025] Log output layer: Generates standardized change logs and persists them to the updated field entity table.

[0026] Specifically, the update field entity table in the log output layer includes at least the following fields: business object ID, field display name, value before change, value after change, operator ID, and operation time.

[0027] Specifically, the processing of the data type includes:

[0028] STRING type: Implements unified handling of null values ​​and empty strings, and determines whether non-empty strings are equal;

[0029] NUMBER type: Converts the numeric value to Double type, retains 2 decimal places, and then compares the results.

[0030] DATE type: Converts the date object to a string according to the format specified by the timeType parameter and then compares the results.

[0031] SELECT type: The dictionary lookup interface is called through the configuration service to convert the dictionary encoding into Chinese names and then compare them;

[0032] OTHER_ID type: Converts the ID to the corresponding name through the conversion class interface specified by the ID conversion class;

[0033] RELATION type: Identifies add, delete, and modify operations on associated objects and generates formatted logs;

[0034] BOOLEAN type: Convert the boolean value to Chinese descriptions for comparison;

[0035] CUSTOM type: Reserves a custom processing interface, allowing users to extend the processing logic by implementing specific functions.

[0036] On the other hand, the annotation-driven method for identifying and logging changes to business objects includes the following steps:

[0037] Step S1: Initialize the change log;

[0038] Step S2: Field scanning and reflection;

[0039] In a preferred embodiment, the Class object of the business entity object is used as the key to retrieve the data from a globally static ConcurrentHashMap. <Class<?> List <field>The corresponding field list is searched in the cache container; if not found, a recursive scan is performed, using clazz.getSuperclass() as the iteration condition until Object.class, to obtain the declared fields of the current class and all its parent classes, form a field list and store it in the cache container;

[0040] Step S3: Change comparison, iterate through the annotation fields, call the corresponding processing strategy according to the CompareEnum comparison enumeration type, and generate change logs;

[0041] In a preferred embodiment, the value of the compareEnum parameter of the CompareAnnotation annotation on the field is used to retrieve the value from the EnumMap. <CompareEnum, BiFunction<Object, Object, CompareResult> The corresponding two-parameter comparison function is retrieved from the `compareEnum` parameter, and the value of the field in the old and new business entity objects is passed to the two-parameter comparison function to obtain the comparison result. When the value of the `compareEnum` parameter is `OTHER_ID`, the `transitionClass` parameter value is used to retrieve the value from the `ConcurrentHashMap` with the `Class` object of the transformation class as the key. <Class<?> Retrieve the corresponding singleton instance of the transformation class from the TransitionInterface cache container, call its convert(String id) method to convert the ID to the name, and update the comparison result;

[0042] Step S4: Log persistence, encapsulate the change information into an update field entity object, and save it to the database through the Java persistence layer API interface;

[0043] Step S5: Cache update, update field cache and transformation interface cache;

[0044] In a preferred embodiment, the ConcurrentHashMap is updated. <Class<?> List <field>>Cache container and the ConcurrentHashMap <Class<?> , TransitionInterface> caching container.

[0045] Specifically, step S1 includes the following steps:

[0046] Step S11: The business service calls the start update log method of the operation business log service, passing in the business objects and main codes before and after the change;

[0047] Step S12: Call the change log merging method, which in turn calls the Java object comparison utility class to execute the core comparison logic;

[0048] Step S13: Based on the comparison results, if there are no changes, generate a content change log; if there are changes, generate a detailed change log and a change list in JSON format.

[0049] Step S14: Determine the commit status. If it is true, write directly to the database; if it is the default false, store the log object in the Redis cache.

[0050] Specifically, step S2 includes the following steps:

[0051] Step S21: Receive the target class Class object and check if the class's field list exists in the CLASS_FIELD class field cache;

[0052] Step S22: If the cache is hit, return the field list directly; if the cache is not hit, obtain the declared fields of the current class and all its parent classes recursively and store the results in a list.

[0053] Step S23: Return the complete list of fields.

[0054] The beneficial effects of this invention are as follows:

[0055] (1) Significantly improved development efficiency: Through the annotation-driven approach, developers only need to add the @CompareAnnotation annotation to the field to achieve change monitoring. Compared with the traditional manual coding method, the development efficiency is improved by more than 70%, and the amount of code for change monitoring of complex business objects is reduced from 500+ lines to 10+ lines of annotation configuration.

[0056] (2) The system maintainability is greatly improved: the business logic and change monitoring logic are completely decoupled. When the business field changes, only the annotation configuration needs to be adjusted, without modifying the core comparison logic, and the maintenance cost is reduced by more than 60%.

[0057] (3) Enhanced type handling capabilities: Supports automatic identification and conversion of 8 common data types, including complex dictionary value conversion, ID conversion, and associated object processing, with a type conversion accuracy of nearly 100%;

[0058] (4) Significantly improved system scalability: By adopting the strategy pattern and functional programming design, adding new data types only requires extending the CompareEnum enumeration, without modifying the core logic, which fully complies with the open / closed principle and reduces the cost of expansion by 80%;

[0059] (5) Significant performance optimization: By using field caching and object caching mechanisms, repeated reflection and instantiation operations are avoided, the system processing performance is improved by more than 30%, and it performs stably in high-concurrency scenarios;

[0060] (6) High degree of log standardization: Generates change logs in a unified format, supporting multiple log templates such as "Change from A to B", "Add association C", and "Delete association D", which facilitates subsequent data analysis and auditing work. Attached Figure Description

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

[0062] Figure 1 This is an overall flowchart of log processing when a business object changes, as shown in this embodiment of the invention.

[0063] Figure 2 This is a flowchart of the change log initialization process in an embodiment of the present invention;

[0064] Figure 3 This is a flowchart of field scanning and reflection in an embodiment of the present invention. Detailed Implementation

[0065] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0066] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0067] The following is in conjunction with the appendix Figure 1 ~Attached Figure 3 The following describes some embodiments of the present invention in detail. Unless otherwise specified, the following embodiments and features can be combined with each other.

[0068] This invention proposes an annotation-driven system and method for identifying and generating logs of business object changes. In a preferred embodiment, the annotation-driven system for identifying and generating logs of business object changes adopts a four-layer architecture design:

[0069] Annotation definition layer: Defines the core annotation CompareAnnotation, including configuration parameters such as field name, comparison type, time format, dictionary enumeration, and conversion class;

[0070] Type processing layer: The CompareEnum enumeration is used to implement processing strategies for different data types, supporting 8 data types including STRING, NUMBER, DATE, SELECT, OTHER_ID, RELATION, BOOLEAN, and CUSTOM;

[0071] Reflection Execution Layer: Utilizes the CompareUtils utility class to dynamically obtain object field values ​​through Java reflection, achieving precise field-level comparison;

[0072] Log output layer: Generates standardized change logs and persists them to the GsbmsUpdateColumn (update field entity) table.

[0073] In this embodiment, the core modules of the system include:

[0074] Annotation-driven module: The CompareAnnotation annotation supports configuration of parameters such as columnName (field display name), compareEnum (comparison type), timeType (time format, default "yyyy-MM-dd"), dictionaryCodeEnum (dictionary type), transitionClass (ID conversion class), and enableFunction (enable function); it supports two functional modes:

[0075] CompareFunctionEnum.COMPARE_LOG (log output);

[0076] CompareFunctionEnum.COMPARE_UPDATE (Field Comparison).

[0077] Type Strategy Module:

[0078] The strategy pattern is implemented using CompareEnum (a comparison enumeration), with one function corresponding to each data type.<CompareFunctionVo,CompareFunctionResult> (Comparison Function) The functional interface STRING type handles boundary cases of null values ​​and empty strings. The specific data type is:

[0079] The NUMBER type supports Double precision control, retaining two decimal places;

[0080] The DATE type supports custom time formatting;

[0081] SELECT types are converted by obtaining dictionary values ​​through ConfigureService.

[0082] The OTHER_ID type uses the TransitionInterface interface to convert ID to name.

[0083] The RELATION type supports the generation of logs for adding, deleting, and modifying related data.

[0084] Reflection processing module:

[0085] The getFieldByClass field scanning method recursively retrieves all fields of a class and its parent classes, supporting complete field scanning of inheritance relationships; the CLASS_FIELD (class field cache) caching mechanism avoids repeated reflection operations, improving performance by more than 30%.

[0086] ID conversion module:

[0087] TransitionInterface is a functional interface that defines a unified ID conversion standard; it provides 20+ specific conversion implementation classes such as UserName, OrgName, and CityName; and a pseudo-singleton caching mechanism, TRANSITION_INTERFACE_SINGLE, avoids duplicate instantiation.

[0088] In this embodiment, the system is also equipped with two key algorithms:

[0089] Field change identification algorithm: Obtain all fields of the business object through reflection; traverse fields annotated with CompareAnnotation; obtain the current and historical values ​​of the fields; select the corresponding processing strategy according to the compareEnum type configured in the annotation; execute type-specific comparison logic; generate standardized change logs.

[0090] Type conversion algorithm: Adopting functional programming concept, each data type corresponds to a conversion function; supports complex scenarios such as null value handling, formatting, dictionary conversion, ID conversion, etc.; input parameters are encapsulated by CompareFunctionVo and output results are encapsulated by CompareFunctionResult.

[0091] Based on the above system design, this invention also proposes an annotation-driven method for identifying business object changes and generating logs. The overall interaction process is as follows: Figure 1 As shown, it includes:

[0092] (1) Change log initialization process (OperateBusLogService.initChangeLog)

[0093] like Figure 2 The business service calls the initChangeLog method of OperateBusLogService, passing in the business objects before and after the change (last, current) and the principal code (principalSn).

[0094] The initChangeLogMerge method is called (with isSubmit=false), which in turn calls CompareUtils.objCompareLog (a Java object comparison utility class) to execute the core comparison logic;

[0095] Based on the comparison results: if there are no changes, generate a "No changes to content" log; if there are changes, generate a detailed change log and a change list in JSON format.

[0096] Determine the commit status (isSubmit): If true, write directly to the database via operateBusLogRepository (operation log data access interface, responsible for interacting with the operation log data database table); if false (default), store the log object in the Redis cache (key: pendingLog+principalSn), valid for 60 minutes.

[0097] (2) Field scanning and reflection process (CompareUtils.getFieldByClass)

[0098] Field scanning and reflection, such as Figure 3 As shown, the function receives the target class object (Class) and checks if the CLASS_FIELD (class field cache) contains a list of fields for that class. If the cache is hit, the field list is returned directly; otherwise, the getDeclaredFieldsByObj method is called. The getDeclaredFieldsByObj method recursively retrieves the declared fields (DeclaredFields) of the current class and all its parent classes (up to the Object class), stores the results in a list, and returns the complete field list.

[0099] (3) Change comparison stage: Iterate through the annotation fields, call the corresponding processing strategy according to the compareEnum type, and generate change logs.

[0100] (4) Log persistence stage: The change information is encapsulated into a GsbmsUpdateColumn (update field entity) object and written to the database through GsbmsUpdateColumnRepository (change field record data access interface, responsible for interacting with the change field record database table);

[0101] (5) Cache update stage: Update field cache and conversion interface cache to improve subsequent processing performance.

[0102] In one specific embodiment, the annotation-driven business object change identification and log generation system proposed in this invention is applied. The system is implemented based on the Java technology stack, and the development and running environment must meet the following requirements:

[0103] Programming language: Java 8 or above;

[0104] Framework dependencies: Spring Boot 2.0+, Spring AOP (Aspect-Oriented Programming);

[0105] Database: MySQL 5.7+ (used to store change logs);

[0106] Caching: Local memory cache (implemented based on ConcurrentHashMap).

[0107] Build tool: Maven 3.6+ (project build tool).

[0108] In this embodiment, the specific implementation of each level / module includes:

[0109] (1) Implementation of annotation definition layer

[0110] Define the CompareAnnotation annotation class, using Java meta-annotations to declare its scope (field level) and retention strategy (runtime). The core code logic (natural language description) is as follows:

[0111] Annotation parameter definitions: include columnName (String type, required, field display name), compareEnum (CompareEnum type, required, data type identifier), timeType (String type, default value "yyyy-MM-dd", date format), dictionaryCodeEnum (DictionaryCodeEnum type, optional, dictionary type), and transitionClass (Class).<?extendsTransitionInterface> Type (optional, ID conversion class), enableFunction (CompareFunctionEnum type, default COMPARE_LOG, function mode).

[0112] Annotation usage constraints: @Target(ElementType.FIELD) specifies that it only applies to fields, and @Retention(RetentionPolicy.RUNTIME) ensures that annotation information can be obtained through reflection at runtime.

[0113] (2) Implementation of type processing layer

[0114] Define the CompareEnum enumeration class, which contains enumeration constants for 8 data types, and each constant is associated with a corresponding processing function (implemented as a functional interface):

[0115] STRING type: Implements unified handling of null values ​​and empty strings, and determines whether non-empty strings are equal;

[0116] NUMBER type: Converts the numerical value to Double type, retains 2 decimal places before comparison, avoiding precision differences;

[0117] DATE type: Converts the date object to a string according to the format specified by the timeType parameter before comparison;

[0118] SELECT type: The dictionary lookup interface is called through ConfigureService to convert the dictionary encoding into Chinese names and then compare them;

[0119] OTHER_ID type: The ID is converted to the corresponding name (e.g., user ID → username) by the transformation class specified by transitionClass (which implements the TransitionInterface interface).

[0120] RELATION type: Identifies add, delete, and modify operations on associated objects, and generates logs in the format of "Add associated XX" or "Delete associated XX";

[0121] BOOLEAN type: Converts Boolean values ​​to Chinese "Yes / No" descriptions for comparison;

[0122] CUSTOM type: Reserves a custom processing interface, allowing users to extend the processing logic by implementing specific functions.

[0123] Functional interface design: Define the CompareFunction interface, declare the apply(CompareFunctionVovo) method, and implement the interface through anonymous inner classes or lambda expressions for the processing logic of each data type.

[0124] (3) Implementation of the reflection execution layer

[0125] The core methods of the CompareUtils utility class include:

[0126] getFieldByClass(Class<?> clazz: Recursively scans all fields of the current class and its parent classes, storing them in the CLASS_FIELD (class field cache) cache (ConcurrentHashMap). <Class<?> List <field>>), to avoid repeated reflections;

[0127] getFieldValue(Objectobj, Fieldfield): Sets the field accessibility (setAccessible(true)) through reflection, retrieves the current and historical values ​​of the field, and handles field access permission issues;

[0128] -compareField(Fieldfield,ObjectoldObj,ObjectnewObj): Parses the CompareAnnotation on the field, obtains the corresponding processing function based on compareEnum, passes in CompareFunctionVo (encapsulating field information, old and new values, and annotation parameters), executes the comparison logic, and returns CompareFunctionResult (containing whether it has changed, the value before the change, and the value after the change).

[0129] Cache optimization: The CLASS_FIELD (class field cache) cache is valid indefinitely (unless the application is restarted) to avoid performance loss caused by frequent reflection; when the business class structure changes, the cache needs to be updated by manually triggering the cache refresh interface.

[0130] (4) Implementation of ID conversion module

[0131] Define the functional interface TransitionInterface and declare the convert(String id) method to convert the ID to the corresponding name;

[0132] Implement 20+ specific transformation classes: such as UserNameTransition (retrieves username by querying user table with user ID), OrgNameTransition (retrieves organization name by querying organization table with organization ID), and CityNameTransition (retrieves city name by querying dictionary table with city ID). All transformation classes implement the TransitionInterface interface.

[0133] Caching mechanism: Caching via TRANSITION_INTERFACE_SINGLE (conversion interface singleton cache) (ConcurrentHashMap) <Class<?> The `TransitionInterface` class stores a singleton instance of the transformation class, avoiding repeated instantiation and improving transformation efficiency.

[0134] (5) Log output layer implementation

[0135] Database table design: The GsbmsUpdateColumn (update field entity) table is used to store change logs. The field names, field types, and descriptions of the core fields are as follows:

[0136] Id, VARCHAR(32), primary key (generated from UUID);

[0137] business_type, VARCHAR(64), business type (e.g., "user management");

[0138] business_id, VARCHAR(32), business object ID;

[0139] column_name, VARCHAR(64), is the display name of the field;

[0140] old_value, VARCHAR(255), the value before the change;

[0141] new_value, VARCHAR(255), the changed value;

[0142] operate_time, DATETIME, operation time;

[0143] operator_id, VARCHAR(32), operator ID;

[0144] operator_name, VARCHAR(64), operator name;

[0145] log_type, VARCHAR(32), log type (e.g., "field change").

[0146] In this embodiment, persistence is implemented through the GsbmsUpdateColumnRepository interface of Spring Data JPA (Java Persistence Layer API), which calls the save() method to save the change log entity class to the database, supporting batch insertion optimization (when multiple fields are changed at once, INSERT statements are executed in batches).

[0147] The technical solution presented in this application has strong business adaptability and has been successfully applied in multiple business module areas, demonstrating versatility and practicality. For example:

[0148] In the field of opportunity management: it enables precise tracking of changes in "opportunity stage" (textual type), "success probability" (numerical type, rounded to two decimal places) and "related customers" (relationship type), effectively supporting the dynamic analysis of the sales funnel;

[0149] In the area of ​​project initiation, the system resolved the issue of identifying changes to complex fields such as "project location" and "project team members," ensuring the historical traceability of project files.

[0150] In the equity investment field: audit-level logging has been implemented for key sensitive information such as "registered capital" (large numerical value), "establishment time" (date type), and "partners" (one-to-many relationship type);

[0151] In the asset management field: automatic monitoring of changes in "investment amount" and "province of origin" has been achieved.

[0152] For the foregoing embodiments, in order to simplify the description, they are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, because according to this application, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to this application.

[0153] The above embodiments describe the basic principles, main features, and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited to the above embodiments. The embodiments and descriptions in the specification are merely illustrative of the principles of the invention. Modifications and variations made by those skilled in the art without departing from the spirit and scope of the invention should be within the protection scope of the appended claims.< / field> < / field> < / field> < / field>

Claims

1. A business object change identification and log generation system based on annotation-driven methods, characterized in that, Based on a four-layer architecture, it specifically includes the following modules: Annotation-driven module: Based on the @Target and @Retention meta-annotations, configure CompareAnnotation to compare annotation-related parameters, and support log output and field comparison; Type Strategy Module: The strategy pattern is implemented through CompareEnum comparison enumeration. Each data type enumeration constant corresponds to a comparison functional interface. The CompareEnum comparison enumeration includes STRING, NUMBER, DATE, SELECT, OTHER_ID, RELATION, BOOLEAN, and CUSTOM enumeration constants. The corresponding comparison functional interfaces are stored in a preset data structure with the enumeration constants as keys. The reflection processing module: It obtains all fields of the current class and its parent classes through recursive scanning, and supports complete field scanning of inheritance relationships; it avoids repeated reflection operations through a class field caching mechanism. The recursive scanning is set with iteration conditions. The class field caching mechanism adopts a global static cache container with Class objects as keys and field lists as values. When the target class Class object is received, it first searches in this cache container. If it is not found, it performs a recursive scan and stores the result in the cache. ID conversion module: Defines a unified ID conversion specification through a functional conversion interface, provides multiple conversion implementation classes, and configures a conversion interface singleton caching mechanism; the conversion interface singleton caching mechanism is based on a cache container, uses the Class object of the conversion class as the key and the singleton instance of the conversion class as the value, and when ID conversion is required, it first retrieves the conversion class instance from the cache container, and if it is not found, it is instantiated through reflection and stored in the cache; The four-layer architecture specifically includes: Annotation definition layer: Defines the annotation class of CompareAnnotation, defines the configuration parameters including field name, comparison type, time format, dictionary enumeration and conversion class, and uses Java meta-annotations to declare the field-level scope and runtime retention strategy of CompareAnnotation; Type processing layer: Implements different data type processing strategies through the CompareEnum comparison enumeration, supporting STRING, NUMBER, DATE, SELECT, OTHER_ID, RELATION, BOOLEAN, and CUSTOM data types; specific data type processing includes: STRING type: Implements unified handling of null values ​​and empty strings, and determines whether non-empty strings are equal; NUMBER type: Converts the numeric value to Double type, retains 2 decimal places, and then compares the results. DATE type: Converts the date object to a string according to the format specified by the timeType parameter and then compares the results. SELECT type: The dictionary lookup interface is called through the configuration service to convert the dictionary encoding into Chinese names and then compare them; OTHER_ID type: Converts the ID to the corresponding name through the conversion class interface specified by the ID conversion class; RELATION type: Identifies add, delete, and modify operations on associated objects and generates formatted logs; BOOLEAN type: Convert the boolean value to Chinese descriptions for comparison; CUSTOM type: Reserves a custom processing interface, allowing users to extend the processing logic by implementing specific functions. Reflection Execution Layer: Utilizes comparison utility classes to dynamically obtain object field values ​​through Java reflection, achieving precise field-level comparison; Log output layer: Generates standardized change logs and persists them to the updated field entity table.

2. The annotation-driven business object change identification and log generation system as described in claim 1, characterized in that, The parameters related to the CompareAnnotation annotation in the annotation-driven module include: the field display name, comparison type, time format, dictionary type, ID conversion class, and enabled function.

3. The annotation-driven business object change identification and log generation system as described in claim 1, characterized in that, The update field entity table in the log output layer shall contain at least the following fields: business object ID, field display name, value before change, value after change, operator ID, and operation time.

4. A method for identifying and generating logs of business object changes based on annotations, implemented based on the system for identifying and generating logs of business object changes based on annotations as described in any one of claims 1 to 3, characterized in that, Includes the following steps: Step S1: Initialize the change log; Step S2: Field scanning and reflection. Receive the target class Class object and check if the field list of the class exists in the CLASS_FIELD class field cache in the global static cache container. If the cache is hit, return the field list directly. If not, obtain the declared fields of the current class and all its parent classes through recursive scanning combined with iteration conditions, store the results in a list, and return the complete field list. Step S3: Change comparison, iterate through the annotation fields, call the corresponding processing strategy according to the CompareEnum comparison enumeration type, and generate change logs; Step S4: Log persistence, encapsulate the change information into an update field entity object, and save it to the database through the Java persistence layer API interface; Step S5: Cache update, update field cache and conversion interface cache.

5. The annotation-driven business object change identification and log generation method as described in claim 4, characterized in that, Step S1 specifically includes the following steps: Step S11: The business service calls the start update log method of the operation business log service, passing in the business objects and main codes before and after the change; Step S12: Call the change log merging method, which in turn calls the Java object comparison utility class to execute the core comparison logic; Step S13: Based on the comparison results, if there are no changes, generate a content change log; if there are changes, generate a detailed change log and a change list in JSON format. Step S14: Determine the commit status. If it is true, write directly to the database; if it is the default false, store the log object in the Redis cache.

6. The annotation-driven business object change identification and log generation method as described in claim 5, characterized in that, Step S3 further includes: Based on the CompareEnum comparison enumeration parameter value of the CompareAnnotation field, obtain the corresponding two-parameter comparison function, and pass the value of this field in the old and new business entity objects into the two-parameter comparison function to obtain the comparison result; When the CompareEnum comparison enumeration parameter value is OTHER_ID, the corresponding singleton instance of the transformation class is retrieved from the cache container based on the transitionClass ID parameter value, using the Class object of the transformation class as the key, the ID is converted to the name, and the comparison result is updated.

Images