POS cashier system operation log collection and intelligent analysis method
Through the cooperation of the proxy layer and the logging layer, combined with SpEL expressions and large language models, unified collection and intelligent analysis of operation logs in the POS cash register system are achieved, solving the problems of insufficient log granularity and difficulty in adapting to multiple businesses, improving the efficiency and accuracy of log analysis, and meeting the needs of modern retail business.
Patent Information
- Application Number
- CN202510712089.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-05-30
- Publication Date
- 2025-09-26
AI Technical Summary
The operation log management in the existing POS cash register system has problems such as insufficient log granularity, difficulty in multi-business adaptation and low analysis efficiency, which cannot meet the needs of modern retail business for refined operations and risk control.
Through the cooperation of the proxy layer and the logging layer, unified collection and structured storage of logs throughout the entire process are achieved. SpEL expressions are used to dynamically parse parameters, and intelligent analysis is performed in combination with a large language model. Table details and natural language question-and-answer queries are supported.
It realizes the full-process logging of user-level operations, improves the accuracy and scalability of log data, supports diverse log analysis needs, and meets the refined operation and risk management requirements of modern retail business.
Smart Images
Figure CN120705002A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the technical field of POS cash register systems, in particular to a method for collecting and intelligently analyzing operation logs of POS cash register systems. Background Art
[0002] In the existing POS cash register system, operation log management has the following problems:
[0003] Log granularity is insufficient, recording only operational flow (e.g., "item sold") and lacking the ability to capture detailed data changes (e.g., the price difference before and after the change). For example, when a product price is adjusted from 100 yuan to 120 yuan, the log only records the "price change" operation, but lacks the specific comparison of the values before and after the change (old value 100 yuan → new value 120 yuan), making it impossible to trace the specific changes.
[0004] Difficulty adapting to multiple businesses. The log recording formats and storage logic of different business modules (such as products and orders) are scattered, resulting in inconsistent log collection, low query efficiency, and difficulty in querying through a unified interface.
[0005] Analysis efficiency is low, manual log screening is time-consuming and error-prone, and there is a lack of in-depth analysis capabilities for log data. It is difficult to trace business changes and identify abnormal operations through historical operation records.
[0006] Existing solutions usually only implement simple log storage and basic queries, do not form a structured log collection system, and do not combine intelligent analysis technology to mine the value of log data. They cannot meet the needs of modern retail businesses for refined operations and risk management.
[0007] The information disclosed in this background technology section is only intended to deepen the understanding of the overall background technology of the present invention and should not be regarded as an admission or any form of suggestion that the information constitutes the prior art already known to those skilled in the art. Summary of the Invention
[0008] In response to the defects existing in the prior art, the purpose of the present invention is to provide a method for collecting and intelligently analyzing the operation logs of a POS cash register system. Through the cooperation of the proxy layer and the log recording layer, unified collection and structured storage of full-process logs of user add, delete, modify, and query operations are achieved. SpEL expressions are used to dynamically parse parameters and accurately record data differences, decoupling business logic and log processing to improve scalability. At the same time, intelligent analysis is performed with the help of a large language model, and table details display and natural language question-and-answer queries are supported to fully meet diverse log analysis needs.
[0009] In order to achieve the above purpose, the technical solution adopted by the present invention is:
[0010] The method for collecting and intelligently analyzing POS cash register system operation logs is characterized by comprising:
[0011] The proxy layer uses Spring AOP to intercept requests before business methods are executed and pass the operation parameters to the logging layer;
[0012] The logging layer dynamically parses the operation parameters through SpEL expressions and extracts key fields from the parameters;
[0013] The logging layer uses the Java reflection mechanism to call the query interface of the business logic layer to ensure that logging is decoupled from business logic;
[0014] The proxy layer calls the business logic layer to perform business operations, wherein the business operations include at least one of adding, deleting, and modifying data;
[0015] After the operation is completed, the logging layer queries the database again to obtain the modified data;
[0016] Compare the JSON data before and after the modification, generate and store the difference records.
[0017] Based on the above technical solution, transparently passing the operation parameters to the logging layer means: encapsulating the parameters into DTO and then passing them to the logging layer, or passing the parameters directly to the logging layer without encapsulation.
[0018] Based on the above technical solution, the JSON difference comparison tool JSON Diff is used to compare the JSON data before and after the modification to generate a difference record.
[0019] Based on the above technical solution, structured storage is used to store difference records, and the following log storage format is implemented based on the Elasticsearch index template:
[0020] Operator, used to record the name of the user who performs the current operation;
[0021] Timestamp, used to accurately record the time when the operation occurred;
[0022] businessType, business type, used to identify the business module to which the operation belongs;
[0023] Operation: Operation type, used to describe the operation behavior;
[0024] diff, difference data, used to record the changes in specific fields before and after the operation. Each object contains the following subfields:
[0025] Field name field, the name of the field that has changed;
[0026] Old value old, the original value before modification, the type is defined according to the actual field;
[0027] The new value new, the latest value after modification, has the same type as the old value old.
[0028] Based on the above technical solution, the log storage format also includes:
[0029] Unique operation ID, used to uniquely identify each operation record, supporting operation flow tracking and association;
[0030] Business data identifier, used to record specific business data associated with the operation and implement data association query between business modules.
[0031] In addition to the above technical solutions, intelligent query and analysis of logs are also included. The specific steps include:
[0032] The user initiates a query request, which supports two query modes:
[0033] Table mode, filter logs by time, operator, and business type;
[0034] Question-answering mode: input natural language questions and obtain query conditions through dynamic assembly;
[0035] Dynamic assembly refers to the use of a unified interface design. Users submit common query conditions, and the system automatically converts them into syntax that adapts to the underlying storage.
[0036] Receive the query results returned after the query statement is executed, and call the large language model to analyze the log data based on natural language questions.
[0037] Based on the above technical solution, the large language model defaults to the privately deployed GPT-3 model, which inputs query results and user questions to generate analysis conclusions.
[0038] Based on the above technical solution, the table mode specifically includes:
[0039] The log query method based on structured conditions allows users to enter or select query conditions through predefined filter fields, and the system will display the log data that meets the conditions in a table format.
[0040] Based on the above technical solution, the question-answering mode specifically includes:
[0041] The log query method based on natural language processing (NLP) allows users to input natural language questions, parse the key entities and intentions in the user's questions, extract matching information from the log data, and directly return the answer.
[0042] Based on the above technical solution, the logging layer is divided into independent modules according to business type. Each module implements differentiated parameter parsing and data query logic. The proxy layer dynamically routes to the corresponding logging module according to the operation type.
[0043] The POS cash register system operation log collection and intelligent analysis method of the present invention has the following beneficial effects:
[0044] 1. Unified log collection process: Realize the full process log recording of user-level add, delete, modify, and query operations. Through the collaboration of the proxy layer and the logging layer, ensure that the log data of different business modules (products, orders, etc.) are stored in a unified structured form.
[0045] 2. Dynamic parameter parsing and data comparison: Use SpEL expressions to dynamically parse operation parameters, automatically obtain data before and after modification, and compare the differences to achieve accurate recording of log data.
[0046] 3. Decoupling business logic and log processing: By routing requests through the proxy layer, the business logic layer (business layer) can focus on core operations, and the logging layer can independently handle log-related logic (such as parameter parsing, data query, and difference analysis), thereby improving system scalability.
[0047] 4. Intelligent analysis and visualization: Leveraging a large language model, log data is analyzed for operational records in the time dimension, supporting detailed tabular display and natural language question-and-answer queries to meet diverse log analysis needs. BRIEF DESCRIPTION OF THE DRAWINGS
[0048] The present invention has the following accompanying drawings:
[0049] The accompanying drawings are provided for a better understanding of the present invention and are not intended to limit the present invention.
[0050] Figure 1 Flowchart of Example 1 of the method for collecting and intelligently analyzing POS cash register system operation logs according to the present invention. DETAILED DESCRIPTION
[0051] The present invention will be described in further detail below with reference to the accompanying drawings. The detailed description, which is provided for illustrative purposes only and includes various details to aid understanding of the embodiments of the present invention, should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for the sake of clarity and conciseness, descriptions of well-known functions and structures are omitted from the following description.
[0052] like Figure 1As shown, the POS cash register system operation log collection and intelligent analysis method of the present invention includes:
[0053] The proxy layer uses Spring AOP to intercept requests before business methods are executed and pass the operation parameters to the logging layer. For example, the product ID and the modified price are passed to the logging layer. This means that the operation parameters in the user request (such as the product ID and the modified price) are passed intact from the proxy layer to the logging layer to ensure parameter integrity.
[0054] The logging layer dynamically parses operation parameters using SpEL expressions and extracts key fields from the parameters. These key fields refer to the original product data, that is, the complete status information of the product in the system before the user adds, deletes, or modifies the product.
[0055] The logging layer uses the Java reflection mechanism to call the query interface of the business logic layer to ensure that logging is decoupled from business logic;
[0056] The acquisition of product original data is achieved by combining SpEL expressions and reflection calls:
[0057] SpEL dynamically parses parameters and extracts product ID (such as #productId) from user operation parameters;
[0058] Call the getById method of the business layer through the Java reflection mechanism to query the original data;
[0059] Considering the performance optimization of SpEL expression parsing and reflection calls under high-frequency operations, the overhead of repeated parsing can be reduced by caching the SpEL expression parsing results and the Method objects of reflection calls. For example, for high-frequency operation scenarios such as thousands of requests per second, the logging layer optimizes performance in the following ways:
[0060] SpEL expression cache, which stores parsed expressions (such as #productId) and corresponding Method objects in a cache (such as ConcurrentHashMap) to avoid repeated parsing;
[0061] Reflection call preloading: preloading Method objects of high-frequency business methods (such as getById) at system startup to reduce runtime reflection overhead;
[0062] The proxy layer calls the business logic layer to perform business operations, wherein the business operations include at least one of adding, deleting, and modifying data;
[0063] After the operation is completed, the logging layer queries the database again to obtain the modified data;
[0064] Compare the JSON data before and after the modification, generate and store the difference records.
[0065] In this embodiment, the proxy layer is used to intercept and manage access to target objects (such as the business logic layer). Through the proxy layer, additional logic (such as logging and permission verification) can be inserted before or after the execution of business methods, allowing cross-cutting concerns to be added to the system without modifying the original code.
[0066] For example, in the Spring framework, the proxy layer is implemented through Spring AOP, and its underlying layer supports two dynamic proxy mechanisms:
[0067] JDK dynamic proxy: interface-based proxy that requires the target object to implement the interface.
[0068] CGLIB proxy: inheritance-based proxy that generates subclass proxies without interfaces.
[0069] Spring AOP is an aspect-oriented programming module provided by the Spring framework. It is used to decouple system-level functions (such as logging and transactions) from business logic. Spring AOP can achieve non-invasive function extension through dynamic proxy and aspect programming.
[0070] In this example, SpEL (an expression language provided by the Spring Framework) is used to extract key fields (such as product ID and order number) from user operation parameters to query the original data before the operation. Dynamically parsing method parameters, accessing object properties, and calling methods enables flexible data binding and logic processing.
[0071] For example, write expressions in annotations or configuration, for example:
[0072] @Value("#productService.getById(#productId)")
[0073] private Product originalProduct;
[0074] This expression code dynamically injects a Product object into the originalProduct field using Spring Expression Language (SpEL). The specific logic is as follows:
[0075] Call the getById method of the Bean named productService in the Spring container;
[0076] Pass the current method parameter productId as the parameter of the getById method;
[0077] Finally, the queried Product instance is assigned to the originalProduct field.
[0078] @Value: An annotation provided by the Spring framework for injecting the value of an expression into a class field, method parameter, or constructor parameter.
[0079] #productService: Bean reference in the Spring container (reference the Bean in the Spring container in SpEL).
[0080] #productId: productId variable in the method parameter (reference method parameter or local variable in SpEL).
[0081] getById method: Call the Spring Bean method through SpEL (call the getById method of productService Bean).
[0082] In this embodiment, Java reflection mechanism is applied in log records (allowing programs to access, detect and modify class properties and methods at runtime). The query interface (such as getById) of the business layer is called through reflection, without relying on specific business classes, thus decoupling log records from business logic. Its advantages are:
[0083] Decoupling: The logging layer does not need to directly import business classes, reducing dependencies between modules.
[0084] Flexibility: Supports dynamic calling of methods of different business modules.
[0085] For example, the execution process is as follows:
[0086] The proxy layer intercepts the updatePrice(String productId,double newPrice) request;
[0087] The logging layer extracts productId through SpEL and reflects getById to obtain the original price (such as 100 yuan).
[0088] The proxy layer calls the business logic layer to complete the price update (for example, change it to 120 yuan);
[0089] The logging layer reflectively calls getById again to obtain the new price, generates a difference log, and stores it.
[0090] Based on the above technical solution, transparently passing operation parameters to the logging layer means: encapsulating the parameters into structured data objects (such as through a custom data format or a general transfer object) and then passing them to the logging layer, or passing the parameters directly to the logging layer in their original form. For example: encapsulating the parameters into DTOs (Data Transfer Objects) and then passing them to the logging layer, or passing the parameters directly to the logging layer without encapsulation.
[0091] Structured data object encapsulation is suitable for scenarios where complex parameters need to be passed across modules (such as cross-service calls), ensuring data integrity and consistency through a unified format (such as JSON objects);
[0092] Directly passing original parameters is suitable for high-frequency simple operation scenarios (such as internal calls within a single service), reducing serialization and deserialization overhead and improving transmission efficiency.
[0093] Based on the above technical solution, the JSON difference comparison tool JSON Diff is used to compare the JSON data before and after the modification to generate a difference record.
[0094] By using the JSON Diff tool (a Jackson JsonNode-based tool) to identify the differences between two JSON objects (before and after modification), the changed fields, old values, and new values are recorded in a standardized format, providing basic data for logging, data recovery, or version control.
[0095] Taking Jackson JsonNode (Jackson is one of the most popular JSON processing libraries in the Java ecosystem, and JsonNode is the core class provided by Jackson, used to represent the tree structure of JSON data) as an example, the specific comparison steps include:
[0096] Parse JSON data into JsonNode objects, and use the ObjectMapper of the Jackson library to parse the JSON strings before and after modification into JsonNode objects;
[0097] Recursively compare JsonNode differences, for example, by comparing the structure and content of two JsonNodes layer by layer through depth-first traversal (DFS); specific comparisons include primitive types (numbers, strings, Booleans), objects, and arrays;
[0098] Convert the comparison results into a standardized difference record format and output it in JSON format; example:
[0099] {
[0100] "price":{"action":"UPDATE","old":100.00,"new":120.00},
[0101] "stock":{"action":"DELETE","old":50}
[0102] }
[0103] Store the difference records in a database (such as Elasticsearch) for subsequent query and analysis; example:
[0104] {
[0105] "operator":"Zhang San",
[0106] "timestamp":"2025-03-20T23:00:00",
[0107] "diff":{
[0108]
[0109] This example uniformly uses code block format to display the JSON structure. By standardizing the difference record format, the following functions can be achieved:
[0110] Accurate data recovery: restore the data status before the erroneous operation based on the old value;
[0111] Operation flow audit: quickly identify the operation type (such as add, delete, modify) through the action field;
[0112] Business analysis: Count frequently modified fields (such as price change frequency) to optimize operational strategies.
[0113] Based on the above technical solution, structured storage is used to store difference records, and the following log storage format is implemented based on the Elasticsearch index template:
[0114] Operator, used to record the name of the user who performs the current operation, such as "Zhang San";
[0115] Timestamp, used to accurately record the time when the operation occurred, and supports retrieval and sorting by time range;
[0116] businessType, business type, used to identify the business module to which the operation belongs, such as "product", "order" or "inventory";
[0117] Operation: Operation type, used to describe the operation behavior, such as "add", "delete", and "modify";
[0118] diff, difference data, used to record the changes in specific fields before and after the operation. Each object contains the following subfields:
[0119] Field name field, the name of the field that has changed, such as "price" (price), "stock" (inventory);
[0120] Old value: the original value before modification. The type is defined according to the actual field (such as numeric value or string).
[0121] The new value new, the latest value after modification, has the same type as the old value old.
[0122] Exemplarily, the storage difference record is as follows:
[0123]
[0124] Based on the storage difference record, the following functions can be achieved:
[0125] Audit trail: Use operator and timestamp to quickly locate a user's operation records at a specific time, such as "query all operations of Zhang San on March 20, 2025".
[0126] Data recovery: Combined with the old value (old) in the diff, the data state before the erroneous operation can be restored, such as rolling back the price from 120 yuan to 100 yuan.
[0127] Business analysis: Count the frequency of price changes for a product (for example, businessType = product and field = price) and analyze pricing strategies.
[0128] The structured storage supports multiple database engines (such as Elasticsearch and MySQL), and the logging layer dynamically generates adaptive query statements (such as SQL and DSL) based on the configuration; for example:
[0129] Elasticsearch: implements nested field queries through DSL syntax, such as diff.field=price;
[0130] MySQL: Store difference data in JSON type fields and use SQL functions (such as JSON_EXTRACT) for querying;
[0131] The logging layer automatically generates query statements adapted to different databases based on the configuration.
[0132] Furthermore, in order to implement log format version management and compatibility processing, the log storage format includes a version field for identifying the log format version and supporting compatibility analysis of historical data. The version field is an optional extension function.
[0133] Based on the above technical solution, the log storage format also includes:
[0134] A unique operation identifier, operationId, is used to uniquely identify each operation record (e.g., generated based on a timestamp hash or a database auto-increment ID), supporting operation flow tracking and association;
[0135] Business data identifier, businessId, is used to record specific business data associated with the operation (such as product ID, order number, etc.) and implement data association query between business modules.
[0136] In order to further enhance security audit related functions, the log storage format also includes the ability to expand and record operation terminal information, and restrict access to sensitive fields through permission control policies.
[0137] The operation terminal information specifically includes:
[0138] ip, ip address, used to record the operation terminal IP;
[0139] DeviceId, device ID, used for device identification; for example, collect the POS terminal MAC address, CPU serial number, and operating system version, and use SHA-256 hash to generate the device ID for device identification;
[0140] When the log storage format includes IP and deviceId, you can limit access permissions to sensitive fields (such as IP) to meet security audit requirements. For example, the following permission control policy is used for recording terminal information:
[0141] Field desensitization: Partially mask sensitive fields (such as IP addresses) (such as 192.168.***.***);
[0142] Access privilege grading: Only specific roles (such as auditors) are authorized to access complete terminal information;
[0143] Log encryption storage: AES encryption algorithm is used to protect terminal information and prevent unauthorized access.
[0144] The storage example is as follows:
[0145] {
[0146] "operator":"Zhang San",
[0147] "timestamp":"2025-03-20T23:00:00",
[0148] "businessType":"goods",
[0149] "operation":"Modify",
[0150] "diff":[
[0151] {"field":"price","old":100.00,"new":120.00}
[0152] ],
[0153]
[0154] In addition to the above technical solutions, intelligent query and analysis of logs are also included. The specific steps include:
[0155] The user initiates a query request, which supports two query modes:
[0156] Table mode, filter logs by time, operator, and business type;
[0157] In question-and-answer mode, natural language questions are input, such as "Who changed the price of product A on March 20?" Query conditions are then dynamically assembled. Dynamic assembly uses a unified interface design, where users submit common query conditions (such as time and operator), and the system automatically converts them into syntax compatible with the underlying storage. For example, the proxy layer receives common query parameters (such as time range and business type), and the logging layer converts them into specific query statements.
[0158] Receive the query results returned after the query statement is executed, and call the large language model to analyze the log data based on natural language questions.
[0159] The specific query statement refers to: generating query statements that conform to the syntax rules of the underlying database or search engine, such as Elasticsearch DSL and SQL, for the log storage structure of different business modules (business modules are independent units divided by function in the system, and each module handles specific business logic, such as product management, order processing, inventory management, etc.). Elasticsearch DSL is a query language designed specifically for Elasticsearch, which is used to perform complex query, filtering, aggregation and other operations in the search engine. It is suitable for queries of unstructured or semi-structured log data (such as product operation logs and user behavior logs). SQL is a structured query language suitable for relational databases such as MySQL, PostgreSQL, and Oracle. It is a standard language for managing and operating relational databases and supports data query, insertion, update, deletion and other operations. Different business modules may have different log fields and formats. For example, the product log contains price and the order log contains order_amount; the query requirements are also different. For example, the product module needs to query by price range and the order module needs to query by amount or status.
[0160] For example, product logs are stored in Elasticsearch in nested JSON format and require DSL queries, which are suitable for multi-condition combination queries (such as "price > 100 and category = fruit"). Order logs are stored in MySQL in table format and require SQL queries, which are suitable for relational queries and transaction operations (such as "join query between order and user tables").
[0161] Based on the above technical solution, the large language model defaults to the privately deployed GPT-3 model (generative pre-trained model GPT-3), which inputs query results and user questions to generate analysis conclusions.
[0162] For example, the input includes the following information (structured log data) including the operator, timestamp, and diff fields:
[0163] Log data: [
[0164] {"operator":"Zhang San","timestamp":"2025-03-20T23:00:00","diff":[{"field":"price","old":100,"new":120}]}]
[0165] Question (natural language question): Who changed the price of product A on March 20?
[0166] Output result: At 23:00 on March 20, 2025, Zhang San adjusted the price of commodity A from 100 yuan to 120 yuan.
[0167] The default large language model is the GPT-3 model privately deployed within the enterprise. The specific technical implementation examples of the large language model are as follows:
[0168] NLP Models:
[0169] Use pre-trained models (such as BERT) for entity and intent recognition.
[0170] Fine-tune the model to adapt to business terms (e.g., "Product A" corresponds to the system ID PROD-A).
[0171] Large language model integration:
[0172] Call models such as GPT-3 to generate natural language answers and convert the parsed conditions into Elasticsearch DSL, SQL, or graph database queries.
[0173] Based on the above technical solution, the table mode specifically includes:
[0174] The log query method based on structured conditions allows users to enter or select query conditions through predefined filter fields (such as time, operator, business type, etc.), and the system will display the log data that meets the conditions in a table format.
[0175] Table mode supports the following features:
[0176] Multi-condition combination filtering: supports users to filter logs by combining multiple fields.
[0177] Structured display: Log field information (such as time, operator, operation type, data difference, etc.) is clearly presented in rows and columns.
[0178] Interactive operations: support sorting, paging, exporting and other operations to improve data viewing efficiency.
[0179] Exemplarily, the specific data processing steps of the table mode include:
[0180] First, the user enters the query criteria;
[0181] Time range: Select the start and end time (e.g. 2023-10-01 to 2023-10-31);
[0182] Operator: Enter or select the operator's name (such as Zhang San);
[0183] Business Type: Select the business module to which the log belongs (such as product, order);
[0184] Operation type: filter specific operations (such as modify, delete);
[0185] Other fields: Expand according to business needs (such as product ID, order status).
[0186] Secondly, the system generates query statements;
[0187] Dynamically generate query statements for the underlying database or search engine (such as Elasticsearch DSL, SQL) based on the conditions entered by the user.
[0188] Again, return and display the table data;
[0189] The table example is as follows:
[0190] time Operator Business Type Operation Type Modify fields Old value New value 2023-10-05 14:30 Zhang San commodity Revise price 100 120 2023-10-06 09:15 Li Si Order delete Order number O-001 -
[0191] The table mode is applicable when the user specifies the filtering conditions and needs to perform precise queries; the query results are output in the form of a structured table (row and column data).
[0192] Based on the above technical solution, the question-answering mode specifically includes:
[0193] The log query method based on natural language processing (NLP) allows users to input natural language questions, parse the key entities (such as time, operator, business object) and intentions (such as query, statistics) in the user's questions, extract matching information from the log data, and directly return the answer.
[0194] The question-and-answer mode is applicable when the user's needs are vague and they hope to quickly locate records through natural language; the query results are output in the form of natural language answers (such as "Zhang San changed the product price on October 5") or simplified tables.
[0195] The question-and-answer mode supports the processing of complex questions (such as multi-condition combinations and fuzzy queries), which can effectively improve the user experience.
[0196] The question-answering mode uses a pre-trained BERT model to extract entities such as time, operation type, and business object from questions, and uses an intent classification model (such as one based on LSTM) to determine the type of user demand (such as querying the operator and counting the number of operations).
[0197] Exemplarily, the specific data processing steps of the question-answering model include:
[0198] First, the user enters a natural language question:
[0199] Example question:
[0200] “Who changed the price of product A on March 20?”;
[0201] “Which products have been deleted in the past week?”;
[0202] "How many times did Zhang San modify the inventory in October?"
[0203] Secondly, natural language processing (NLP) analysis:
[0204] Entity Recognition: Extracting key information from the question:
[0205] Example: "Who changed the price of Product A on March 20?" Entity extraction results: Time = March 20, Operation Type = Modify, Object = Price of Product A;
[0206] Example: "Which products have been deleted in the past week?" Entity extraction results: Time = Last Week, Operation Type = Delete, Object = Product;
[0207] Further intent recognition is performed to determine user needs, such as querying the operator and counting the number of operations.
[0208] Again, convert it into the underlying query statement;
[0209] Generate query statements that adapt to the log storage structure based on the parsing results;
[0210] Elasticsearch DSL example:
[0211]
[0212] }
[0213] }
[0214] SQL example:
[0215] SELECT operator FROM product_logs
[0216] WHERE operation = 'Modify'
[0217] AND DATE(timestamp)='2025-03-20'
[0218] AND diff_field = 'price';
[0219] Finally, the query is executed and the answer is generated;
[0220] If the query result is a single record (such as the operator "Li Si"), the answer is returned directly.
[0221] If the result is multiple records, aggregate or summarize as needed:
[0222] Statistical questions: return a value (such as "Zhang San modified the inventory 15 times in October").
[0223] List questions: Return a simplified table or natural language list (e.g., "Products deleted in the past week include: apples, bananas").
[0224] The question-answering model described in this embodiment uses a natural language parsing process, dynamic query condition assembly, and query result generation. After the user enters a natural language question, such as "Who deleted the banana on March 20th?", a pre-trained NLP model (such as BERT) is used to perform entity recognition and intent classification:
[0225] Entity recognition: Extract key entities in the question, including time ("March 20"), operation type ("delete"), and business object ("banana");
[0226] Intent classification: Determine the user's need as "query operator";
[0227] Then it is converted into the underlying query statement. For example, the following example generates a DSL query statement adapted to Elasticsearch based on the parsing results:
[0228]
[0229] The system performs a query and generates an answer. Generating an answer means converting the query result into a natural language answer. For example, if the query result is a single record (such as the operator "Li Si"), the system calls a large language model (such as GPT-3) to generate a natural language answer: "On March 20, 2025, Li Si performed a delete operation, and the deleted product was bananas.
[0230] If you need to return and display tabular data, the query result is converted to the following table example:
[0231] time Operator Business Type Operation Type Modify fields Old value New value 2025-03-20 23:00:01 Li Si commodity delete Product Name banana -
[0232] Based on the above technical solution, the logging layer is divided into independent modules according to business type. Each module implements differentiated parameter parsing and data query logic. The proxy layer dynamically routes to the corresponding logging module according to the operation type.
[0233] Exemplarily, the logging layer is divided into independent modules according to business type (product, order), which are responsible for parameter parsing, data query and difference calculation.
[0234] In the POS cash register system, different business modules (such as product management, order processing, and inventory adjustment) have different operating procedures, data structures, and log requirements. For example:
[0235] The product module needs to record operations such as price changes and inventory adjustments, involving fields such as price and stock.
[0236] The order module needs to record order status changes, payment results, etc., involving fields such as orderId and paymentStatus.
[0237] The membership module needs to record the increase or decrease of points, level changes, etc., involving fields such as memberId and points.
[0238] The logging layer is divided into independent modules according to business types. The advantages are:
[0239] Decouple business logic: Log processing logic for different businesses is independent to avoid code coupling;
[0240] Flexible expansion: When adding a new business module, you only need to develop the corresponding log module without modifying the core framework;
[0241] Adapt to different needs: Different businesses can customize parameter parsing rules, data query methods and difference comparison strategies.
[0242] For example, each business log module needs to implement the following core functions:
[0243] (1) Differentiated parameter analysis
[0244] Input: User operation parameters (such as product ID, order number).
[0245] Processing logic:
[0246] Product module: Extract productId from the parameters and call productService.getById(#productId) through the SpEL expression to query the original data.
[0247] Order module: Extract orderId from the parameters and call orderService.getOrder(#orderId) to query the original order status.
[0248] (2) Differentiated data query logic
[0249] Product module:
[0250] Check the current price and inventory of the product.
[0251] Use SQL: SELECT price,stock FROM products WHERE id=?
[0252] Order module:
[0253] Check order status and payment amount.
[0254] Use SQL: SELECT status,amount FROM orders WHERE id=?
[0255] (3) Differentiated comparison and storage strategies
[0256] Product module: Compares price and inventory changes, generates diff fields, and stores them in the product_logs index of Elasticsearch.
[0257] Order module: compares status and amount changes, generates diff fields, and stores them in the order_logs index of Elasticsearch.
[0258] In this embodiment, the proxy layer dynamically routes to the corresponding logging module based on the operation type. This dynamic routing mechanism allows the proxy layer to automatically select the logging module based on the operation type (e.g., ProductService.update). For example, the proxy layer implements dynamic routing by parsing business method signatures or annotations (e.g., @LogCategory("Product")), ensuring decoupling of different business log processing.
[0259] The proxy layer needs to automatically select the corresponding logging module based on the operation type. The implementation methods include:
[0260] (1) Routing based on method signature
[0261] Parse the business method name or class name to match the business type:
[0262] The method name contains Product → routing to the product log module.
[0263] The method name contains Order → routes to the order log module.
[0264] (2) Annotation-based routing
[0265] Add custom annotations (such as @LogCategory("Product")) to business methods, and the proxy layer reads the annotation values through reflection.
[0266] (3) Configuration file or strategy mode
[0267] Define routing rules through configuration files (such as YAML), or use the strategy mode to dynamically select modules.
[0268] Based on the above technical solution, when the logging layer queries for modified data, the proxy layer calls the business logic layer to perform business operations (such as updating product prices). The business logic layer completes the data modification in the database transaction (such as executing an UPDATE statement). After the business logic layer transaction is successfully committed, the modified data is officially persisted to the database.
[0269] When querying modified data at the logging layer, you must wait until the transaction is committed before executing the query operation.
[0270] If you query before a transaction is committed, you may read uncommitted intermediate states (dirty reads), resulting in inaccurate difference records.
[0271] For example, if a query is made before a transaction is committed, suppose the price of a product is updated to 120 yuan in the transaction, but the price is 120 yuan when the transaction is not committed. Then the transaction is rolled back due to an exception, and the actual price remains 100 yuan. At this time, the difference data recorded in the log (100→120) is inconsistent with the actual data (100→100). After the transaction is successfully committed, the final price of 120 yuan is queried in the log recording layer, and the difference record (100→120) is consistent with the actual data.
[0272] In specific implementation, you can use the @Transactional annotation to ensure that business operations are executed in a transaction and trigger queries in the logging layer after the transaction is committed; use @TransactionalEventListener: after the transaction is successfully committed, the query operation of the logging layer is automatically triggered; set the isolation level to READ_COMMITTED: ensure that the logging layer only reads committed data to avoid dirty reads; if the business operation fails or the transaction is rolled back, the logging layer will not trigger a query for the modified data to avoid recording invalid operations. For example: when the product price update fails, logRecorder.logAfterUpdate will not be called, and only the data before the modification (marked as "not effective") will be retained in the difference log.
[0273] On the basis of the above technical solution, the proxy layer verifies the validity of the query conditions input by the user and uses pre-compiled parameter binding (such as Elasticsearch's PreparedStatement) to prevent injection attacks.
[0274] After receiving a user query request, the proxy layer first verifies the validity of the query conditions entered by the user to ensure that the query parameters conform to the predetermined format and range. At the same time, it uses pre-compiled parameter binding technology (such as Elasticsearch's PreparedStatement) to effectively prevent security attacks such as SQL injection, ensuring the security of the query process.
[0275] The contents not described in detail in this specification belong to the prior art known to those skilled in the art.
[0276] The above description is only a preferred embodiment of the present invention, and the protection scope of the present invention is not limited to the above embodiment. Any equivalent modifications or changes made by those skilled in the art based on the contents disclosed in the present invention should be included in the protection scope recorded in the claims.
Claims
1. A method for collecting and intelligently analyzing POS cash register system operation logs, characterized in that: include: The proxy layer uses Spring AOP to intercept requests before business methods are executed and pass the operation parameters to the logging layer; The logging layer dynamically parses the operation parameters through SpEL expressions and extracts key fields from the parameters; The logging layer uses the Java reflection mechanism to call the query interface of the business logic layer to ensure that logging is decoupled from business logic; The proxy layer calls the business logic layer to perform business operations, wherein the business operations include at least one of adding, deleting, and modifying data; After the operation is completed, the logging layer queries the database again to obtain the modified data; Compare the JSON data before and after the modification, generate and store the difference records.
2. The POS cash register system operation log collection and intelligent analysis method according to claim 1, characterized in that: Passing operation parameters to the logging layer means encapsulating the parameters into DTO and passing them to the logging layer, or passing the parameters directly to the logging layer without encapsulation.
3. The POS cash register system operation log collection and intelligent analysis method according to claim 1, characterized in that: Use the JSON Diff tool to compare the JSON data before and after the modification and generate a difference record.
4. The POS cash register system operation log collection and intelligent analysis method according to claim 1, characterized in that: Structured storage is used to store difference records. The following log storage format is implemented based on the Elasticsearch index template: Operator, used to record the name of the user who performs the current operation; Timestamp, used to accurately record the time when the operation occurred; businessType, business type, used to identify the business module to which the operation belongs; Operation: Operation type, used to describe the operation behavior; diff, difference data, used to record the changes in specific fields before and after the operation. Each object contains the following subfields: Field name field, the name of the field that has changed; Old value old, the original value before modification, the type is defined according to the actual field; The new value new, the latest value after modification, has the same type as the old value old.
5. The POS cash register system operation log collection and intelligent analysis method according to claim 4, characterized in that: The log storage format also includes: Unique operation ID, used to uniquely identify each operation record, supporting operation flow tracking and association; Business data identifier, used to record specific business data associated with the operation and implement data association query between business modules.
6. The POS cash register system operation log collection and intelligent analysis method according to claim 1, characterized in that: It also includes intelligent query and analysis of logs. The specific steps include: The user initiates a query request, which supports two query modes: Table mode, filter logs by time, operator, and business type; Question-answering mode: input natural language questions and obtain query conditions through dynamic assembly; Dynamic assembly refers to the use of a unified interface design. Users submit common query conditions, and the system automatically converts them into syntax that adapts to the underlying storage. Receive the query results returned after the query statement is executed, and call the large language model to analyze the log data based on natural language questions.
7. The POS cash register system operation log collection and intelligent analysis method according to claim 6, characterized in that: The large language model defaults to the privately deployed GPT-3 model, which inputs query results and user questions to generate analysis conclusions.
8. The POS cash register system operation log collection and intelligent analysis method according to claim 6, characterized in that: The table mode specifically includes: The log query method based on structured conditions allows users to enter or select query conditions through predefined filter fields, and the system will display the log data that meets the conditions in a table format.
9. The POS cash register system operation log collection and intelligent analysis method according to claim 6, characterized in that: The question-answering mode specifically includes: The log query method based on natural language processing (NLP) allows users to input natural language questions, parse the key entities and intentions in the user's questions, extract matching information from the log data, and directly return the answer.
10. The POS cash register system operation log collection and intelligent analysis method according to claim 1, characterized in that: The logging layer is divided into independent modules according to business types. Each module implements differentiated parameter parsing and data query logic. The proxy layer dynamically routes to the corresponding logging module according to the operation type.