content_image/871263.jpg
 <COMMAND_CLASS>user</COMMAND_CLASS>  <COMPONENT>component_text</COMPONENT>  <PRODUCER>producer_text</PRODUCER>  <MESSAGE>message_text</MESSAGE>  <MAP> <ELEMENT> <KEY>key1</KEY> <VALUE>value1</VALUE> </ELEMENT> <ELEMENT> <KEY>key2</KEY> <VALUE>123</VALUE> </ELEMENT> <ELEMENT> <KEY>key3</KEY> <VALUE/> </ELEMENT>  </MAP> </AUDIT_RECORD> 

•Old-style XML format ( audit_log_format=OLD ): 

<AUDIT_RECORD ... NAME="Message" ... COMMAND_CLASS="user" COMPONENT="component_text" PRODUCER="producer_text" MESSAGE="message_text"/> 

<img src='content_image/871263.jpg'>

## Note 

Message events logged in old-style XML format do not include the key-value map due to representational constraints imposed by this format. 

Messages posted by audit_api_message_emit_udf()  have an event class of MYSQL_AUDIT_MESSAGE_CLASS  and a subclass of MYSQL_AUDIT_MESSAGE_USER . (Interally generated audit messages have the same class and a subclass of MYSQL_AUDIT_MESSAGE_INTERNAL ; this subclass currently is unused.) To refer to such events in audit_log  filtering rules, use a class  element with a name  value of message . For example: 

{ "filter": { "class": { "name": "message" } } } 

Should it be necessary to distinguish user-generated and internally generated message events, test the subclass  value against user  or internal . 

Filtering based on the contents of the key-value map is not supported. 

For information about writing filtering rules, see Section 6.4.5.7, “Audit Log Filtering” . 

## 6.4.7 MySQL Enterprise Firewall 

