Use AOP to implement the Business Log System

Project Background:

Dragon is a service system used by intelligence agencies to query customer communication records at telecom operators. Because it involves the privacy of telecom customers, all operations such as adding, deleting, and modifying users in the system are required, you can also query operation logs of user data, communication records, and other private content on the page. The operation log records at least the operation time, operator, and operation object attributes.

 

For OperationLog queryPage: After you select object-type, the corresponding action is listed in the Action drop-down list. After you select action, the fields to be recorded in the action are listed for query. If you select the updatewarrant action, fields such as warranttype and warrantid are listed.

Search result page:

Implementation ideas:

This system is implemented through J2EE and follows the regular action-> service-> Dao level.

(1) logs must be recorded for all addition, deletion, modification, and some query/view operations. If the log operation is placed in the Code for addition, deletion, and modification, the coupling is serious, and the workload is huge, so we use Spring AOP to intercept the service layer method, and then according to the expression, such as "user. name to read the parameters or return values of the method to generate business operation logs.

(2) recording operation logs does not affect business processes, and I/O operations that record logs may cause performance problems. Therefore, asynchronous data writing is used, and the core business code will generate the logevent content, and then send the message through JMS, MDB receives the message and then writes it to the database.

(3) User information will be stored in threadlocal.

 

Specific implementation:

1. Database Design:

1.1.Entity:Saves information related to object types in the system, such as warrant and workitem. The specific fields are as follows:

• Entity_id: PK
• Entity_name: object type name
• Enable_flag: Specifies whether to record user operation logs for such entities.
• Description: description.

 1.2. Action:Save User operations, such as deletewarrant (the relationship with action is manytoone)

• Id_action: PK,
• Name: Operation name,
• Description: description,
• Entity_id: FK to entity,
• Action_type: the type of the current operation, such as deletion, modification, and addition. The methods for obtaining data for different types are different.
• Enable_flag: whether to record logs for this operation.

1.3. event:Used to save information such as the method name corresponding to the action. (The relationship with action is manytoone. Because a user-defined operation, such as modifying warrant data, may correspond to multiple methods in the Code, such as updatewarranttype () and updatewarranttime .)

 

• Id_event: PK,
• Id_action: FK to action,
• Method_name: method name.
• Serviceclassname: ServiceInterface.
• Enable_flag: whether to record logs for this method
• Argclasses (varchar2 (1024): The full name of the method parameter type is a string concatenated. This field is mainly used for method overloading. You need to determine whether to record service operation logs based on the parameter type.

1.4. action_detail:Details to be recorded in the log, such as the typename of warrant.

• Id_action_detail: PK
• Id_action: FK to action
• Detail_name: name of the field.
• Detail_order: the order in which the field is displayed on the page.
• Param_index: the order of parameters of the method corresponding to this field (starting from 0 ). If this field is taken from the return value of the method, set it to-1.
• Detail_value_expression: Value expression, for example, user. Name; users [0]. Name.
• Enable_flag: whether to record logs for this field
• Format_provider_calss_name: fullname of the class that implements the formatproviderinterf interface. Used to process deletewarrant (long warrantid), we need to first query the warrant object based on warrantid, and then record its type and other attributes. If the value obtained based on the expression is of the date type, we need to format it before displaying it to the user. These operations are put in the implementation class of formatproviderinterf.
• Format_pattern: format, which is used by the class specified in format_provider_calss_name.
• Update_flag: whether the current field needs to record the values before and after Update (mainly used for update operations ).
• Searchable: whether the customer can query operation logs based on this field.
• Description: description.

 1.5. log_event:Operation logs (excluding specific content ).

• Id_log_event: PK
• Event_date: operation time,
• Id_user: User
• Id_action: FK to action
• Id_object: ID of the affected objec
• Object_name: Object Name.
• Id_status_from: The status before the change.
• Id_status_to: status after change
• CRC: A verification code generated based on the time and content to prevent modification of records through the DB background.

1.6. log_event_detail:Operation Log details.

 

• Id_log_event_detail: PK
• Id_log_event: FK to logevent
• Id_action_detail: FK to action_detail
• Name: redundant field copied from action_detail.
• Value: the value of a field.
• Event_date: Copy redundant fields from log_event.
• CRC: verification code.

 

2. Several Interfaces:

2.1. formatproviderinterf

/* <Br/> * data retention and Guardian online <br/> * copyright (c) 2006-2012 Hewlett-Packard Company <br/> */<br/> package COM. HP. dragon. business. formats. interf; <br/> Public interface formatproviderinterf {<br/> Public string format (Object Data, string formatstring) throws businessexception; <br/>}< br/> 

 3. Spring configuration file:

<Bean id = "advisoreventmanager" class = "org. springframework. AOP. support. regexpmethodpointcutadvisor "> <br/> <property name =" advice "> <br/> <ref bean =" logeventservice "/> <br/> </property> <br/> <property name = "patterns"> <br/> <list> <br/> <value>. */. create. * </value> <br/> <value>. */. insert. * </value> <br/> <value>. */. update. * </value> <br/> <value>. */. delete. * </value> <br/> <value>. */. changestatus. * </value> <br/> <value>. */.. * tracked </value> <br/> </List> <br/> </property> <br/> </bean> 

4. The sequence diagram of logeventseviceimpl. Invoke:

For different operation types: For update operations, you need to reload the objects before update in the beforetracking () method, save the attribute values before update in a local object, and then in aftertracking () record the updated value to generate the logevent information. The create/insert operation must record information in aftertracking (), while the delete operation can only record information in beforetracking.

 

5. Summary

Any errors or exceptions in the log system do not affect the main business process.

Because dragon is sold to different telecom operators in the form of products, the log system is required to have high configuration to meet the requirements of different customers, so there are a lot of configurable options in the system.

Instead of using annotation, the configuration information is stored in the database to facilitate the implementation of the delivery team. You only need to modify the database data to meet the needs of different operators.

Due to the large number of logs, it is recommended that you delete them regularly. At least when querying, you can only query the latest data.

 

Note: The log query and result interfaces are extracted from the user documentation of HP-dragon.