Enabling Workflow Auditing

Workflow auditing is similar to regular auditing, except that workflow auditing stores additional information to enable time computations. Regular auditing reports that an event occurred, but does not indicate when the event started and ended. See the Business Administrator's Guide book for more information about Waveset auditing.

Workflow auditing operations store predefined attribute names and their values per audit event. You can use this feature to instrument a workflow by putting auditWorkflow events at the beginning and at the end of workflows, processes, and activities.

When instrumenting a workflow or process, you are not permitted to put anything in an end activity. You must create a pre-end activity that performs the final auditWorkflow event, and then unconditionally transitions to the end event.

To enable workflow auditing, you add the audit attribute to a workflow or one or more of its Activities. Once the attribute is in place, activate workflow auditing by selecting the Audit entire workflow checkbox in the appropriate task template of the Administrator interface. See the chapter titled “Task Templates” in Business Administrator's Guide for procedural information about turning on auditing in a task template.

In addition, you must provide an appropriate value for the following actions, which are defined in the auditconfig.xml file to allow auditWorkflow event pairings. (You can define additional actions.)

• StartWorkflow

• EndWorkflow

• StartProcess

• EndProcess

• StartActivity

• EndActivity

The following as an example call showing just the information the caller must provide:

<Action application=’com.waveset.session.WorkflowServices’>
   <Argument name=’op’ value=’auditWorkflow’/>
   <Argument name=’action’ value=’StartWorkflow’/>
</Action>

Waveset actually stores more information than is shown in the preceding example. Continue to the next section for details.

Workflow auditing operations store predefined attribute names and their values per audit event. You can enable auditing within a workflow by adding the audit attribute (set to true) to the WFProcess element or to one or more Activity elements. Setting the attribute at the WFProcess level causes the entire workflow to be audited, while adding the attribute to individual Activity elements causes only certain activities to be audited. If the audit attribute is not set, then auditing is disabled. In addition, auditing must be enabled from within task template that calls the workflow.

What Information Is Stored and Where Is It?

By default, workflow auditing collects most of the information stored by a regular audit event, including the following attributes:

These attributes are stored in the logattr table and are derived from auditableAttributesList.

Waveset also checks whether the workflowAuditAttrConds attribute is defined.

You can call certain activities several times within a single instance of a process or a workflow. To match the audit events for a particular activity instance, Waveset stores a unique identifier within a workflow instance in the logattr table.

To store additional attributes in the logattr table for a workflow, you must define a workflowAuditAttrConds list (assumed to be a list of GenericObjects). If you define an attrName attribute within the workflowAuditAttrConds list, Waveset pulls attrName out of the object within the code— first using attrName as the key, and then storing the attrName value. All keys and values are stored as uppercase values.