With the Audit trail feature, you can find out a certain configured number of Context Store operations performed on a context during the lifecycle of the context.

Audit trail records all successful interactions with a context and stores the information inside the context object as an extra field. If you enable the Audit trail feature, you can find out which application created or updated the context. You can also track the operation types, such as Create, Read, Update, and Delete that were performed on the context. The audit entry of a context also provides information such as the time at which the operations were performed and the version of the context.

The ContextStoreRest API accepts touchpoint, which is any application that can interact with ContextStoreRest APIs, as a parameter for each interaction. The touchpoint parameter is an alphanumeric ID.

If you add or modify a context without providing the touchpoint parameter, the touchpoint value of the audit entry is set as undefined.

The versionId of a context increases with each interaction, such as UPDATE, GET, PUT, and DELETE, with a context.

For more information about the touchpoint parameter, see Avaya Context Store Snap-in Developer Guide.

If you enable persistence to an EDM and set Persistence Type to Audit, then the full context for each audit entry is written to the EDM. You can then query and retrieve these audits through the ContextStoreQuery service. For more information about persistence types, see External Data Mart persistence.

In Context Store with Avaya Oceana® deployments, GET operations without a specified touchpoint do not get replicated to EDM.

REST URL paths

You can retrieve the audit entries of a context using the contextId or aliasId of the context. When you provide the correct parameters, the system displays the audit data. For example, the URL to retrieve audit data using contextId is https://{clusterIP}/services/ContextStoreRest/cs/contexts/audit/{contextId}/?rid={routingId}.

Avaya Context Store Snap-in Developer Guide has more detailed usage examples.

Setting a limit on audit entries

The number of audit entries increases the size of the contexts, and that is why it reduces the number of contexts you can store in the data grid. Therefore, you must set a limit on the number of audit entries that can exist for a context.

Setting the audit entry limit to 0 means that the audit feature is disabled. To enable the feature, set the number of audit entries for a context by selecting a value ranging between 1 and 50. If you set the limit to 10, then Context Store records the 10 most recent interactions as entries for the context. When the number of audit entries reaches the maximum limit, the system removes the oldest audit entry each time a new entry is added.

Note:

If you enable the Audit trail feature in a geo-redundant deployment, the CS Audit: Event limit attribute must be set identically in both clusters. For Context Store with Avaya Oceana® deployments, Context Store stores only 1 audit trail within a context object by default.

Audit trail and capacity planning

The number of audit entries configured for a context affects the size of the context object and the number of contexts in the data grid. Therefore, you must consider the size of the audit data trail while planning the Context Store capacity.

For more information about Audit trail and capacity planning, see Avaya Context Store Snap-in Developer Guide.