You could turn on the dm_all_workflow Audit trail event. In this case all workflows events are recorded in the dm_audittrail records. Timestamps are recorded in milliseconds, only Documentum Administrator does not return that so you have to analyze the results with an SQL client (SQL Developer for example) directly in the database (looking at dm_audittrail_s table).
select * from dmi_registry (to see the events that are being audited)
audit,c,dm_all_workflow (to audit all workflow events
How can I make sure that my documents will be audited correctly when I register
Keep in mind that auditing is designed for registering events for documents that are either a subtype of dm_document or dm_sysobject .
1) For verification create a subtype of dm_document and register an event against this subtype.
2) Then create a document whose attribute has this subtype.
3) Next register the events you would like to monitor.
- Launch Documentum Administrator
- Select auditing
- Clicking on the selection, "Register Events for all objects of a type". It is important that when this step is done, that you navigate to the correct folder such as dm_document and highlight the dm_type which you are registering the event against.
Then launch Intranet Client and trigger an event such as check in or check out. You should now have generated an event and possibly an email if your email service has been properly configured.
An event may not be viewable on the Audit Detail page in Workflow Reporting unless you turn on auditing for workflow template.
To turn on the workflow template audit, check Template Audit Record Setting option on Properties dialog box which is from File > Template Properties in Web Workflow Manager.
In addition, to turn on the workflow template audit, the user must have 'Config Audit' privilege. If the user does not have this privilege then this option is not available for this user on the workflow template properties dialog box.
System Event: System-recognized actions performed on specific documents, folders, cabinets, or other objects. Content Server supports a large number of system-defined events, representing operations such as checkins, promotions, and demotions. Refer to the Audit section of the Content Server API Reference Manual for tables listing all System Events. Also, Appendix B (System Events) of the Content Server API Reference provides an exhaustive list of the System Events.
Application Event: Actions which are not inherently recognized by the Content Server. Applications decide which of these non-system actions need to support audit and add code to specifically handle those actions. For example, an application may choose to provide audit capability for an advanced search function, capturing useful data in the audit such as the user executing the search and the search parameters.
Event Target: The primary entity acted upon by an event. Examples of targets for System Events include specific instances of an object, types of an object, users, groups, policies, methods, workflows, activites, etc. Application Events have their targets defined by their application.
Audit Event: An Audit Event is either a System Event or an Application Event. The term Audit Event is introduced as a generalization for convenience.
Audit Method: An Audit Method is used to request an audit of a specific event. The arguments to the Audit Method specify the event to audit, the target of the event, and the names of the attributes whose values are to be audited. Audit methods can be used to request audits for System Events or Application Events. A user must have the extended privilege Config Audit in order to invoke an Audit Method.
Audit Trail: An Audit Trail is the history of instances of an Audit Event. Each instance of an Audit Event results in the creation of one Audit Trail entry which stores information about the event (such as the time of the event, which objects were involved, who performed the actions, and which values were affected).
Tamper-Evident Auditing: The Content Server provides the ability to "sign" each Audit Trail entry, which will cause a cryptographic hash to be computed for the contents of the entry. The hash itself is then encrypted using the Application Encryption Key (AEK) for the Content Server and stored back in the audit_signature attribute of the entry. At any point in the future, a client can validate the entry, which will recompute the hash and compare it to the hash stored in the attribute. Due to the way hashes work, if any information in the entry has been changed since the original hash was computed, then the new hash will not match the original, and the client knows that the entry has been tampered.
Audit Trail is docbase specific
dmc_completed_workflow - completed workflow object stores information from audit trail records about a completed workflow. The objects are created by the dm_WfReporting job and used by Webtop’s aggregrate workflow reporting tool.
To fully populate the attributes in these objects, you must be auditing all workflow events.
The object type is created by a script when Content Server is installed.
When you clone, the Audit info will not be cloned because it is specific to the docbase. Setup auditing and perform a WF, you should see the results
What is the difference between Register and Audit API?
Register API: Registers the current user to receive notification when the specified event occurs.
When you register for an event, the server puts a notification in your inbox when the
event occurs. With two exceptions (dm_fetch and dm_acquire), you receive notification
each time the event occurs in the same or different repository sessions. For dm_fetch
and dm_acquire, you receive only one notification in a repository session even if the
event occurs multiple times in the session.
If you register for an event on an object type, you receive a notification every time that
event occurs for an object of the type.
Registering for an event doesn't create audit trail entries when the event occurs. To create
audit trail entries for an event, you must use an Audit method to initiate auditing. You
can both register for an event and audit the event. (Using Audit requires Config_audit
privileges.)
Audit API: Initiates auditing of an event.
You must have Config_audit privileges to use this method.
Executing Audit creates a dmi_registry object that records the auditing request. The
values you include in the Audit arguments are recorded in the registry object. Thereafter,
if the event is a system event, Content Server creates an audit trail entry whenever
the event occurs. If the event is an application event, the application can examine the
registry to determine whether to create an audit trail entry for the event.
Both API create a dmi_registry entry but have different purposes.
To check what are events are registered for a user or audited run this DQL:
DQL > select r_object_id, user_name, registered_id, event, is_audittrail from dmi_registry
If the event is audited, is_auditrail should be set to 1 and when the event occurs an entry will be created in the dm_audittrail table.
No comments:
Post a Comment