Modifying Workflows to Log Timing Audit Events

Workflows can be modified to log timing events in support of Workflow Reports (Workflow Reports). Standard audit events only log that an event occurred; Timing audit events log when an event started and stopped, making it possible to perform time computations. In addition to timing event data, most of the information logged by standard audit events is also stored. See What Information Do Timing Audit Events Store? for more information.

To log timing audit events, you must first activate workflow auditing for each workflow type that you plan to audit.

• For workflows that you can configure in the Administrator interface using task templates, first enable the task template that corresponds to the workflow that you want to audit. See Enabling the Task Templates for instructions.

  Next, turn on workflow auditing by selecting the Audit entire workflow checkbox. See Configuring the Audit Tab for instructions.

• For workflows that do not have task templates, instead define a variable named auditWorkflow and set its value to true.

Note that auditing workflows degrades performance.

The Example 10–3 example shows the code required to create timing audit events. To log timing audit events, the op argument must be set to auditWorkflow.

The action argument is also required and must be set to one of the following values:

• StartWorkflow

• EndWorkflow

• StartProcess

• EndProcess

• StartActivity

• EndActivity

Additional action arguments may be defined in auditconfig.xml.

Examples: Starting and Stopping Audit Events in a Workflow

Example 10–3 illustrates enabling timing audit events in a workflow. To instrument a workflow, auditWorkflow events should be added at the beginning and end of workflows, processes, and activities.

The auditWorkflow operation is defined in com.waveset.session.WorkflowServices. See The com.waveset.session.WorkflowServices Application for more information.

Example 10–3 Starting Timing Audit Events in a Workflow

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

To stop logging timing audit events in a workflow, add the code in Example 10–4 to a pre-end activity near the conclusion of the workflow. Note that, 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 transition to the end event.

Example 10–4 Stopping Timing Audit Events in a Workflow

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

What Information Do Timing Audit Events Store?

By default, timing audit events log most of the information stored by regular audit events, including the following attributes:

The above attributes are stored in the logattr table and they come from auditableAttributesList. Identity Manager also checks whether the workflowAuditAttrConds attribute is defined.

It is possible to call some activities several times within a single instance of a process or a workflow. To match the audit events for a particular activity instance, Identity Manager 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, which is assumed to be a list of GenericObjects. If you define an attrName attribute within the workflowAuditAttrConds list, Identity Manager 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.