history_subscriptions.xml file

The history_subscriptions.xml file contains filter definitions and object subscription nodes for all the objects that are subscribed for event logging.

Note: Set the value of fetch_audit_lookupDataByID_date property in the $TOP/etc/default/common.properties to date when applied. For more information, see common.properties file parameters.

Object subscription nodes

Object subscription is the mechanism of setting up an object for event logging by the history manager. You need to subscribe Product Master Server objects for which you want to log events. Each object subscription node contains information about the object type, filter, events, and history level for each event.

Object subscription enables you to select the objects for which events should be logged. This is required to avoid the overhead of logging events for all objects. The object must be one of the objects that are supported by the history manager.

This is an example of an object subscription node in the history_subscriptions.xml file. A regular expression filter is used in this subscription node.

<subscription  object_type="ITEM">
	<subscription_filter>regex filter</subscription_filter>    		
	<filter_arguments>regexp^nam.*[0-9]$/regexp</filter_arguments>
   	<subscription_levels>
      	<log event_type="CREATE" history_level="NONE"/>
      	<log event_type="UPDATE" history_level="BASIC_EVENT_INFO"/>
   	</subscription_levels>
  </subscription>

<subscription object_type="object_type">: Indicates the object type that is subscribed. You can log events only for those PIM objects that are supported by the history manager.
<subscription_filter>: Indicates the type of filter to be applied.
filter_arguments: Indicates the argument of the applied filter. The arguments vary based on the filter being used. A named list filter has a list of names as filter_arguments and a regex filter has regular expression as filter_arguments. For a regex filter, the characters ^, * and $ have the same meaning as in UNIX and Linux® environments.
<subscription_levels>: Indicates the events that need to be logged. There can be multiple events on this tag. In the example, the CREATE and UPDATE events are logged.
<log event_type="event_type" history_level="history_level">: Indicates the type of event and the level of history with which the changes need to be logged for that event. The <log> tag is mandatory for the CREATE, UPDATE, and DELETE events. It is optional for the MAPPING and HIERARCHY events. If you define <log> tags for the MAPPING and HIERARCHY events, then the events are logged with the defined history_level. If you do not define the MAPPING and HIERARCHY events, then the logging level of the parent event is used. A parent event is one that causes another event to happen. For example, an UPDATE event causes a MAPPING event to happen.

The history manager enables you to log event details for the object events that are specified for the object in the history_objects.xml file in the $TOP/etc/default directory.

The history manager enables you to log event details at six levels to improve the performance and efficiency of the system by logging only relevant data:

BASIC_EVENT_INFO: At this level, the history manager only logs basic information such as username, current timestamp, object ID, and object primary key.
PRE_EVENT_SNAPSHOT: At this level, the history manager logs a complete snapshot of the object before any changes were made.
POST_EVENT_SNAPSHOT: At this level, the history manager logs a complete snapshot of the object after the changes were made.
PRE_AND_POST_EVENT_SNAPSHOTS:: At this level, the history manager logs a complete snapshot of the object both before and after any changes were made.
DELTA: At this level, the history manager identifies and logs any added, removed, and modified attributes, relationships, or hierarchical_structure.
NONE: At this level, the history manager does not log any changes.