Oracle Waveset 8.1.1 Deployment Reference

Chapter 1 Workflow

This chapter describes Sun Waveset workflow. It provides information about the following topics:

Note –

To better understand a typical workflow, use the Oracle Waveset Integrated Development Environment plug-in to view, run, and debug sample workflows. Instructions for installing and configuring the Identity Manager IDE are provided on

Understanding Workflow

Waveset workflow defines a sequence of actions and tasks that are performed consistently according to a defined rule set. Using the Identity Manager IDE graphical interface, you can customize each workflow launched by Waveset.

Before working with workflow, develop an understanding of:

What is Workflow?

In general terms, a workflow is a logical, repeatable process during which documents, information, or tasks are passed from one participant to another for action, according to a set of procedural rules. A participant is a person, machine, or both.

In Waveset, this concept is specifically implemented as the Waveset workflow component, which comprises multiple processes (workflows) that control creation, update, enabling, disabling, and deletion of user accounts.

Depending upon where you are in the product interface, workflows are referred as workflows, tasks, process, or TaskDefinitions.

When is Workflow Used?

Most Waveset tasks you perform are defined as a set of workflow processes. When you create a user in Waveset, for example, the corresponding workflow process defines and conducts activities that:

Workflows can run automatically without any user interaction or require user interaction in the form of an approval.

Workflows are typically launched as a side effect of checking in a view. Views are checked in when you click Save on a page that implements forms and views.

Workflows in the Repository

Within the Waveset repository, a workflow exists as a configuration object, typically of Type WFProcess. (The single exception to this object definition is the Create User workflow, which is defined as a ProvisioningTask object.) The taskType is always Workflow.

Note –

Waveset does not lock the repository object (that is, the User) while a workflow is executing. This is because workflows can run for days, and the repository object cannot remain unlocked for that long. However, Waveset prevents you from launching another update workflow on the same user.

Task Definitions and Task Instances

The launched instance of a TaskDefinition is represented as a TaskInstance object. You can view both object types from the Debug page.

ProcedureTo Access Task Definitions or Task Instances

  1. From the Debug page of the Waveset Administrator Interface, select TaskDefinition from the Type menu adjacent to the List Objects button

  2. Click List Objects. Waveset displays a list of the available object types that you have access to.

  3. Select an object (for example, TaskDefinition). Waveset displays all instances of that object type that you have permission to see.

    Once a workflow task is launched, the workflow engine creates a TaskInstance in the repository. A TaskInstance is an object in the repository that holds the runtime state of an executing workflow process. It stores context variables and immediate transition information for the TaskDefinition from which it was spawned.

    The TaskInstance references the descriptive TaskDefinition object through the TaskDefinition object’s generated ID. If you edit a TaskDefinition, TaskInstances already in execution will continue to use the old TaskDefinition object, but new ones will use the modified TaskDefinition with its newly generated ID.

When Are Task Instances Deleted?

The life of a TaskInstance is determined by the resultLimit parameter. If the result limit is zero, the task will be deleted immediately after completion. If it is positive, the value is the number of minutes that the TaskInstance is kept.

ProcedureTo Delete a Suspended Workflow TaskInstance

  1. Click the Manage Tasks tab in the Waveset Administrator Interface.

  2. Select View All Tasks.

  3. Select the suspended TaskInstance, then click Terminate.

Task Definition Parameters

The following table lists the standard configuration parameters.

Table 1–1 Standard Workflow Configuration Parameters




Specifies the user-supplied name of the workflow as presented in the Waveset interface. Names should be unique among objects of this type, but objects of different types can have the same name. 


Used for filtering purposes only 


Identifies the name of the class that implements the task. By default, for workflows this class is com.waveset.workflow.WorkflowExecutor.


(Boolean) Indicates that the task can be suspended and resumed. Default is true. 


(Boolean) Indicates whether the user is permitted to request synchronous or asynchronous execution. Default is true. 


Specifies the type of execution we should use by default. Default is sync. 

If this value is null, or set to ExecMode.DEFAULT, we treat it as ExecMode.ASYNC. 


Specifies the limit in seconds that the task is allowed to execute. The task can specify a limit on the amount of time it is allowed to execute. If it exceeds this limit, the scheduler is allowed to terminate it. A limit of zero means there is no limit. 

Default is 0. 


Specifies the limit in seconds that a task instance is allowed to live after the task has completed. Default is 0. 

Once a task has completed or terminated, the TaskInstance containing the task result is typically kept in the repository for a designated period of time, after which it is automatically deleted. 

0. Indicates that the TaskInstance will be deleted immediately after the task is complete. 

-1. Indicates that the TaskInstance will never be automatically deleted, though it can be manually deleted by the user. 

This parameter is typically set to a value that is equivalent to a few days for tasks that generate reports for later analysis. Set to zero for tasks that are run only for side effect and do not generate any meaningful result. 


(Boolean) If set to true and if resultLimit is non-zero, then the task will be persisted only if there was an error or warning. Note that if ResultLimit is 0, then the task will not be persisted, even if SaveOnlyOnError is true and an error or warning occurred. The default is false.


(String) Specifies the options how the results of prior executions of repetitive tasks are handled. This object defines that data, and how to ask for it. Default is delete.

wait. Prevents the task from being run until the old result is manually deleted or expires. If this is a nonscheduled task, it results in an error at the time it is launched. If this is a scheduled task, the scheduler simply ignores it.

delete. Automatically deletes old results before executing the task. The old tasks must be in a finished state.

rename. Renames old results before executing the task. The old task must be in a finished state.

terminate. Terminates and deletes any currently executing task. This is similar to the DELETE option, but it also automatically terminates the task if it is running.


When set to true, specifies that the workflow continues to run after the completion of the action until the next manual action, and displays the next work item to the user immediately. This setting supports wizard-style workflows. 

When set to false, the workflow continues execution in the background, and the user must go to a different page (typically the approvals page) when he needs to perform the next step in the workflow. 


(String) Declares the visibility of this task definition. Default is run schedule. Other options include invisible, run task, and schedule task.


Specifies the interval in milliseconds that Waveset should check for progress updates. 

The task can specify an interval at which the task will be updating its progress. Defaults to 5000 milliseconds (five seconds). Specifying a shorter interval will give you more current task status, but increases the load on the server. 

Using the Variable Element

Waveset assigns a scope to all <Variable> elements when the element is declared. If you do not assign a value to the scope attribute, Waveset assigns it a value of local, which means that the variable can be accessed only within the XPRESS section that it is declared in.

Additional Variable attributes that define scope include:

Workflow Engine

The workflow engine is a software service that provides the run-time execution for a workflow process. The functions provided by the workflow engine to support a workflow process include:

Waveset captures activity-level variables for activities that contain a manual action. To minimize the storage needed for a workflow task, the workflow engine removes all other variables (before export) for completed activities.

Workflow Process Components Overview

Each workflow process is defined by one or more of the following components. These components are discussed at greater length below.

Workflow Activity

An activity is a single step in the workflow process. An activity can contain multiple components, including transitions, variables, and actions, but must contain start and end activities.

Neither start nor stop activities have associated actions. A start activity has one or more transitions to the activity that begins the process, but end activities should have no actions associated with them.

Workflow Action

A workflow action describes an operation that is performed within a workflow Activity. Each activity can contain multiple actions. Waveset provides the following types of actions.

Workflow Action Variables

Table 1–2 Workflow Action Variables

Workflow Action Variable  



(Optional) inherited from WorkflowComponent. Action names are typically null. 


Identifies each action by a unique numeric ID. This is currently the index into the action array of the activity. 


(Optional) Used to calculate a title for this action in the Workflow summary diagram. By default, the title is name, but this variable can include information such as variable values. 


Indicates whether the action is manual (flag). This value has priority over all other action type fields. 


Used to calculate the request string for a manual action’s work item. This text is displayed in the product interface, should be brief, and should clearly describe what is requested of the user (for example, Approve Role Engineering, Supply account ID, and Answer a question. If no request is supplied, Waveset uses the result of the title. If there is no title, Waveset generates a string based on the name and/or title of the Activity.


Used to calculate the requester string for a manual action’s work item. This text is displayed in the product interface. It should be the name of a user or administrator that is considered to be the originator of the request. When null, Waveset assumes that the requester is the subject that launched the workflow case. 


Used to calculate the description string for a manual action’s work item. This text is displayed in the product interface. It is typically larger than the request string. 


Specifies one of the following options:

  • For manual actions, defines the maximum number of minutes that Waveset waits for this action to be performed. If the timeout is reached, the workflow executor considers the action completed. Variables must be used to determine the control flow after a timeout

    The workflow engine sets the WF_TIMEOUT variable to true in the scope of this activity if the item was completed due to timeout.

  • Specifies an expression that yields a timeout value.


Specifies the root of the expression tree that defines the action. If this value is set, it takes priority over the subprocess, and application fields. 


Specifies one of the following options:

  • Specifies the name of a subprocess to invoke. This can either be an internal or external subprocess. If external, it can be a type-qualified name, for example, TaskDefinition:example or Configuration:example.

  • Specifies a rule that generates a subprocess name. The returned object can be a String or an ObjectRef. If a String, it can identify an internal or external process such as subprocess.


Specifies the name of an application that is to be called. This can either be the abstract name of a built-in application, or may be a fully qualified class name of a class that implements the WorkflowApplication interface. 

The names of the built-in applications are defined by WorkflowExecutor. 


If the action type is manual, this field must hold the name of the owner for whom the WorkItem will be created. 

It can be an Administrator name, or use variable reference syntax (for example, $(ADMIN_NAME)). 


Specifies an expression used to calculate the delegator string for a manual action’s work item. This text is displayed in the GUI, it should be the name of a user or administrator that is considered to be the delegator of the request. 


Specifies an expression that will calculate the work item name. Usually the name will be a randomly generated unique identifier, but in some cases it is desirable to pre-compute the name so that it may be used in email notifications, embedded in a URL that will jump directly to the work item. 


Specifies an expression that will calculate the work item name. Typically, the name will be a randomly generated unique identifier, but in some cases you might want to pre-compute the name so that it can be used in email notifications, embedded in a URL that will jump directly to the work item. 


Manual actions can define a form object that can be used by the work list application to prompt the user for the variables expected to be returned when the action is complete. 

There are three ways to specify a form: 

  • set a self-contained form in _localForm

  • set a reference to a form in _formRef

  • have an XPRESS rule that generates a name.


Specifies a reference to an object containing a Form to use when editing the work item for a manual action. 


Specifies a rule that will generate the name of a form or a Form object itself. 


For all action types, a list of arguments can be specified. These are similar to Variables, but they live in a different namespace, sort of like a local Action variable so you don’t have to worry about collision with variable names. 


A list of locally defined action variables used by manual actions. This is needed when iteration is being used. 


A list of declarations of action return values. This defines a mapping between variables defined within the action result, and variables defined in the activity/process. 

This needs more thought, but its the only reasonably simple way I could come up with to perform the mapping without having variable chaos, or introducing path expressions to reference variables created in other scopes (for example, activity.action.variable) 


Specifies an object that defines optional iteration settings for the action. 


Specifies a list of result declarations for this action. 


Indicates that the action is to be hidden from the workflow summary diagram. (Boolean) 


Specifies an optional conditional expression. If this is set, the value of the expression must be true, in order to execute the action, if false, the action is ignored. 


Indicates whether the action will be run. When true, the action will be run only if the value of WF_ACTION_ERROR is null. This is shorthand for a very common <Condition>. 


(Optional) Contains arbitrary comments. 


Indicates that the WorkItem created for a manual action should have the synchronous execution flag set. As a result, when the owner checks in a change to the work item, the workflow should be advanced synchronously rather than scheduled for background execution. 

This is true for “wizard” style workflows where a workflow controls a sequence of pages. 


For manual actions, lists the variables that are to be included in the work item. The names can be GenericObject path expressions. If this list is null, then all variables are included. 


Lists variables that can be edited in the work item and assimilated back into the case (manual actions only). If this list is null, then any variable in the exposedVariables list is considered editable. If exposedVariables is null, then all workflow variables are editable.

Use to avoid collisions where many variables must be exposed to multiple approvers, but each approver is allowed to modify only a subset of the variables. 


Lists variables that contain views. Inclusion of a view on this list causes Waveset to refresh the view when the work item is refreshed. 


Typically, when a work item times out and is deleted while the user is viewing or editing the item, Waveset throws an exception and displays an error page. Occasionally, though, Waveset uses a work item only to display (not edit) summary information. These work items can have a short time-out to allow the workflow to continue processing. 

Setting this option to true causes the Work Item View handler to avoid throwing an exception. It does not affect the behavior of the process. 


Specifies an authorization type to be assigned to the WorkItem that is created for a manual action. Use this variable if you want work items to be authorized differently (for example, granting someone the rights to approve Resource requests but not Organization request.). 


Specifies a user-defined type name for the WorkItem created for a manual action. Use this variable to assign custom categories of work items (for example, “approval” or “wizard”). 


Optional. Contains the Waveset ID of the object being acted on by the work item. 


Optional. Contains the Waveset Name of the object being acted on by the work item. 


Optional. Contains the objectclass name of the object being acted on. 

What is an Application Action?

Application actions permit you to invoke more complex Java calls than you can invoke with script actions.

What is a Manual Action?

A manual action is part of the workflow process definition that defines a manual interaction. When the Workflow Executor processes a manual action, Waveset creates a WorkItem object in the Repository. The work item must be marked complete before the workflow can proceed. You must associate an owner with a Manual Action. An owner can be an expression that determines an owner.

Because most manual actions are used to solicit approvals, the work item table is located under the Approvals tab of the Administrator Interface. Any manual action that belongs to a workflow is represented by a WorkItem object in the Repository. The WorkItem view contains a few attributes that pertain to the WorkItem object itself, as well as values of selected workflow variables copied from the workflow task. These include attributes, such as owners of pending approvals, and the form used to approve the WorkItem. Waveset incorporates ManualActions in the standard workflow and allows approvals for organizations, roles, and resources.

You can assign a time-out to a manual action.

Default Workflow Processes

Using the Sun Identity Manager IDE, you can edit the default Waveset processes to follow a custom set of steps. The Waveset workflow capability includes a library of default workflow processes, which includes:


The following Create User workflow has been modified to call an escalate activity if a timeout value is reached. If the time out is not reached, then the results of the APPROVED variable are evaluated. The results of the evaluation determines whether to transition to the approved or rejected activity.

<Activity name=’Wait’>
   <ManualAction name=’approve’ timeout=’180’>
   <Owner name=’$(APPROVER)’/>
   <Variable name=’APPROVAL’ value=’false’/>
   <Return from=’APPROVAL’ to=’APPROVED’/>
     <ObjectRef type=’UserForm’ id=’#ID#UserForm:ApprovalForm’/>
       <s>Awaiting approval from \n</s>
   <Transition to=’Escalate’>
   <Transition to=’Approved’>
   <Transition to=’Rejected’/>

WorkItem Types

Manual actions have the ability to assign a type to the work item that is generated when the manual action is executed by the workflow engine. You can assign the work item type in a customization to filter the set of values to be displayed or operated upon.

The following work item types are recognized by the system.

Table 1–3 Work Item Types

Work Item Type  



Indicates that the work item represents an approval. 


Indicates that the work item represents an arbitrary interaction with the user. 


Indicates that the work item is temporary. Use this type to force a workflow into background execution. 

In addition, you can assign customized work item types. For example, you might set the work item type to resource to represent a resource approval and role to represent a role approval.

WorkItem Context

Work items are launched using the <ManualAction> directive. The form associated with a specified workflow can set the base context to variables.user. This eliminates the need to put user.variables in the variable name.

The WorkItem is the name space, so typical attribute names of the form:

Applies to both custom tasks and administrator approvals.

Authorization Types

Manual actions can also specify the authorization type of the WorkItem to be created. The authorization type differs from the item type in that the system automatically filters the work items returned in a query to exclude those for which the current administrator is not authorized. Typically, any administrator with the Approver capability is authorized to view all work items in the organizations they control.

To specify a work item authorization type in the manual action, use the authType attribute as follows:

<ManualAction authType=’RoleApproval’>

Assigning WorkItem Types

To specify an item type in the ManualAction definition, set the itemType attribute as shown in this example:

 <ManualAction itemType=’approval’>

Restricting Administrative View Capabilities for WorkItems

Typically, any administrator with the Approver capability is authorized to view all work items in the organizations they control. If you want an administrator to view only a subset of the work items in an organization, follow these steps:

ProcedureTo Restrict Administrative View Capabilities

  1. Define new authorization types that extend the WorkItem type. For example, define the RoleApproval type.

  2. Define new capabilities that have rights on the new authorization types rather than WorkItem itself. For example, define a Role Approver capability that has rights on the RoleApproval type.

  3. Assign the Role Approver capability to an administrator rather than the general Approver capability

  4. Set appropriate authorization types in each manual action in your workflows.

Work Item Delegation

To enable delegation of work items (manual actions) in your workflow, you will need to pass delegator and delegators as input arguments and reference them in the <WorkItemDelegator> and <WorkItemDelegators> elements of the <ManualAction>, respectively.

You can obtain the value of delegator and delegators by invoking the com.waveset.provision.getDelegateObjects workflow service method, which takes the following arguments:

The service returns a list of delegate objects in the delegateObjects argument.


Each delegateObject contains the following attributes:

Creating Transitions

Transitions define the rules by which an activity moves to one or more other activities. A transition can be conditional, which means that it will be taken only if certain conditions are met. Simple activities can contain only one unconditional transition that is taken as soon as the actions within the activity are complete.

Updating a Process for Waveset Use

If you customize a process, validate and save your changes to ensure that the workflow process completes correctly and as you expect. After saving, import the modified workflow for use in Waveset. You can also use the Sun Identity Manager IDE debugger. .

Editing a Workflow in Production

Do not customize a workflow process in a production environment.

Problems can emerge if you edit workflow activities or actions while instances of the original workflow are running. Specifically, the TaskInstance contains a reference to the workflow TaskDefinition and stores the current activity or action by ID. Changing these IDs may prevent the task from restarting where expected when execution resumes.

If you cannot avoid editing a workflow in a production environment, use the following procedure. It will help prevent the loss of pending work items from task instances that are using the old definition.

ProcedureTo Edit a Workflow in Production

  1. Rename the current TaskDefinition to include a time stamp. For example, to modify the Create User workflow, rename the TaskDefinition from Create User to Create User 20080701. You can rename a workflow TaskDefinition with the Sun Identity Manager IDE.

  2. Save and import the edited workflow.

    Following this procedure will help prevent problems with existing Create User tasks that may be in a suspended state within Waveset. This allows the TaskDefinition to keep its unique ID, which is referenced inside suspended tasks.

Standard Workflows

Waveset ships with standard workflows that are mapped to used processes. See Default Workflow Activities for a brief introduction to these default workflows.

ProcedureTo Display and Edit a Default Workflow

  1. Open the Sun Identity Manager IDE.

  2. Select File > Open Repository Object > Workflow Processes. The Sun Identity Manager IDE displays the Workflow Processes list, which contains the standard workflow processes and any custom workflows in your deployment.

  3. Double-click on the name of the workflow you want to display or edit.

    You can view process mappings by selecting Configure > Form and Process Mappings from the Waveset Administrator Interface.

Customizing a Process

You can change one or more of the Waveset processes to eliminate steps, include new steps, or customize existing steps. Each step in the process is represented by an activity.

The Workflow Toolbox facilitates workflow changes by providing pre-defined activities you can use when editing or creating a workflow.

To open the toolbox, right-click in the diagram view and select the toolbox option.

Default Workflow Activities

By category, these default activities are available.

Table 1–4 Default Workflow Activities



Add Deferred Task 

Adds deferred task scanner information to an object. 

Audit Object 

Creates audit log records. 

Authenticate User Credentials 


Authorize Object 

Tests authorization for a subject on an object in the repository. 

Checkin Object 

Commits changes to an object. 

Checkin View 

Commits an updated view. 

Checkout Object 

Locks and retrieves a repository object for editing. 


Adds deferred task scanner information to an object. 

Checkout View 

Gets an updateable view. 

Create Resource Object 

Creates a resource object. 

Create View 

Initializes a new view. 

Delete Resource Object 

Deletes a resource object. 

Deprovision Primitive 

Deprovisions resource accounts. 

Disable Primitive 

Disables resource accounts. 

Disable User 

Disables an Waveset user account, resource accounts, or both. 

Email Notification 

Sends email notification of an action. 

Enable Primitive 

Enables resource accounts. 

Enable User 

Enables an Waveset user account, resource accounts, or both. 

Get Object 

Retrieves a repository object. 

Get Property 

Retrieves a property. 

Get View 

Gets a read-only view. 

List Resource Objects 


Query Object Names 

Searches for objects with matching attributes. 

Query Objects 

Searches for objects with matching attributes. 

Query Reference 


Refresh View 

Refreshes a view that was previously checked out. 

Remove Deferred Task 

Removes deferred task scanner information from an object. 

Remove Property 

Removes an extended property on an object. 

Reprovision Primitive 

Reprovisions resource accounts. 

Run Resource Actions 


Set Property 

Adds an extended property to an object. 

Unlock Object 

Unlocks an object that was previously checked out. 

Unlock View 

Unlocks a view that was previously checked out. 

Update Resource Object 

Modifies an object managed by a resource. 

Table 1–5 Default Approval Workflows




Performs the fundamental single approver process. 

Approval Evaluator 

Recursively evaluates an Approval Definition Object to implement a complex approval process. 

Allows the form and template to be used to be passed in, but those can be overridden if specified in the set. 

Lighthouse Approval 

Performs the default Waveset approval process for assigned organizations, roles, and resources. Uses the Approval Evaluator process. 

Multi Approval 

Distributes approvals among multiple approvers. Users the Approval process for each approver. 

Notification Evaluator 

Recursively evaluates an Approval Definition Object to implement a complex notification process. The structure is expected to be the same as that defined for Approval Evaluator. In the standard workflow, approval definitions and notification definitions are maintained in the same structure. This is not required for a customized workflow. 

Provisioning Notification 

Standard process for notifying administrators after a provisioning operation has completed. 

Table 1–6 Default User Workflows




Performs the standard steps to deprovision an existing Waveset user, with granular control over resource account deletion, Waveset user deletion, unlinking, and de-assignment. Individual resource operations are re-tried until successful. 


Performs the standard steps to create a new Waveset user and provision resource accounts. Individual resource operations are re-tried until successful. 

Set Password 

Changes the password of the Waveset account and resource accounts. 

Update User Object 

Checks out a WSUser object, applies a set of changes, and checks in the object. 

Update User View 

Checks out the user view, applies a set of supplied updates, and checks in the user view. 

Update View 

Applies a collection of changes to any view. 

Table 1–7 Default End User Workflows



End User Update Groups 

Updates the group assignments on resources (that support groups) assigned to one of a manager’s reports. 

End User Update My Groups 

Updates the group assignments on resources (that support groups) assigned to the logged-in account. 

End User Update Roles 

Updates the role assignments for one of a manager’s reports. 

End User Update My Roles 

Updates the role assignments assigned to the logged-in account. 

End User Update Resources 

Updates the resource assignments and associated attributes for one of a manager’s reports. 

End User Update My Resources 

Updates the resource assignments and associated attributes for the logged-in account. 

Table 1–8 Default Compliance Workflows



Access Review Remediation 

Remediation for a single remediator working with a single UserEntitlement 


Creates a work item for each Attestor, and marks the User entitlement record as APPROVED when all work items complete with approved status, or REJECTED as soon as the first work item rejects. When one work item rejects, all other work items are canceled. 

Launch Access Scan 

Either launches or schedules an Access Scan Task, depending upon the setting provided by the Access Review task. It is directly called from the Access Review Workflow/Task. 

Launch Entitlement Rescan 

Launch a rescan of an Access Scan for a single user 

Launch Violation Rescan 

Launch a rescan of an Audit Policy Scan for a single user 

Multi Remediation 

Remediation for a single Compliance Violation and multiple remediators 


Remediation for a single Remediator working with a single Compliance Violation 

Scan Notification 

Notifies Attestors at the end of each Access Scan that they have pending Attestation work items. Sends one notification to each Attestor, regardless of the number of pendng work items. Also notifies the can owner (if any) that the scan has started and completed. This workflow takes the following input: 

scanName -- name of access scan

scanOwner -- name of access scan owner

recipients -- list of Waveset user names which should be notified

notificationType --Valid types include begin, end, attest

userCount -- number of users to be scanned (only on begin)

Standard Attestation 

Creates an Attestation Subprocess for each attestor specified. 

Standard Attestation 

Creates an Attestation Subprocess for each attestor specified. 

Test Auto Attestation 

Facilitates testing new Review Determination rules without creating Attestation work items. This workflow does not create any work items, and simply terminates shortly after it starts. It leaves all User Entitlement objects in the same state that they were created in by the access scan. Use the Terminate and Delete options to clean up the results from access scans run with this workflow. 

Update Compliance Violation 

Mitigates a Compliance Violation 

Scan Task Variables

The Audit Policy Scan Task and Access Scan Task task definitions both specify the forms to be used when initiating the task. These forms include fields that allow for most, but not all, of the scan task variables to be controlled.

Table 1–9 Scan Task Variables

Variable Name  

Default Value  



Identifies the number of concurrent users to work at one time for a single scanner. Increase this value to potentially increase throughput when scanning users with accounts on very slow resources. 



Indicates time (in mS) spent trying to obtain lock on user to be scanned. If several concurrent scans are scanning the same user, and the user has resources that are slow, increasing this value can result in fewer lock errors, but a slower overall scan. 


Indicates time (in mS) to delay between issuing new scan threads. Can be set to a positive number to force Scanner to be less CPU-hungry. 

Workflow Task

Table 1–10 Workflow Activities



Add Result 

Adds a named data item to the task result. 

Add Result Error 

Adds an error message to the task result. 

Add Result Message 

Adds an informational message to the task result. 

Background Task 

Forces the workflow into the background if it was launched from the Waveset Administrator interface. 

Get Resource Result 

Retrieves the result object returned by a resource adapter on the last provisioning operation. 

Get Resource Result Item 

Retrieves one result item from the result object returned by a resource adapter on the last provisioning operation. 

Rename Task 

Renames the task instance in the repository. 

Scripted Task Executor 

Executes BeanShell or JavaScript based on a provided script. As a task, it can be scheduled to run periodically. For example, you can use it to export data from the repository to a database for reporting and analysis. Benefits include the ability to write a custom task without writing custom Java code. (Custom Java code requires a re-compile on every upgrade and must be deployed to every server because the script is embedded in the task there is no need to recompile or deploy it.) 

Set Result 

Adds an entry to the task entrance result. This will appear in the workflow summary report. 

Set Result Limit 

Sets the number of seconds the task instance should be retained in the repository when it finishes. A non-negative value indicates that the task instance will be kept for this many seconds after the task has completed. 

A negative value indicates that the task instance will never be removed automatically. However, you can remove it manually. 

Using the Default Rename Task

To use the default rename task without customization, include the following action in your workflow:

<Action process=’Rename Task’>
   <Argument name=’name’ value=’New Task Name’/>

Using the Handle Native Change To Account Attributes Workflow

Whenever Waveset detects a native change (that is, a change not performed through the Waveset) to the values of an auditable attribute of a resource account, it responds by running the handleNativeChangeToAccountAttributes workflow. This workflow is associated with this System Configuration object attribute:

<Attribute name='process'>
     <Attribute name='handleNativeChangeToAccountAttributes' value='Audit Native
                      Change To Account Attributes'/>

This workflow logs the native change events to the event log if you have enabled the Changes Outside Lighthouse audit filter. Otherwise, Waveset ignores the event. Warning: Be careful which methods you call from any workflow that replaces the default workflow listed above.

Because Waveset launches this workflow whenever a resource account fetch reveals a native change, it must not invoke any method or workflow that would trigger another fetch of the same resource account. For example, an infinite loop will result if you call any workflow services method that assembles the User view: getView(User), checkoutView(User), and possibly checkinView(User).

The fact that Waveset handles each native change by running a workflow allows you to hook the native change event, and to handle that native change however you see fit by replacing or adding to the default native change workflow. For example, you might choose to send email to an administrator or a user, to record the event in a database, to queue an update that would back out the native change, or even to pull that native change into Waveset and push it back out to the other resources.

Specifying the Administrator for a Source Adapter Task

You can assign a subject or administrator to a Source adapter task and designate the server on which it runs by editing the sources.subject and attributes of the System Configuration object. For more information, see Editing the System Configuration object in Deployment Guide.

Implementing the Waveset Whitelist Feature

You can use the whitelist feature to check forms and workflows that use the SaveNoValidate action against a list of IDs or form names. Waveset checks the whitelist for either form names or form-owner IDs. The list of IDs, called saveNoValidateAllowedFormsAndWorkflows, is located in the security attribute in the System Configuration object. If the form name or owner ID is on the whitelist, the form or workflow can use the SaveNoValidate action. If the form name or the owner ID is not on the list, the form or workflow is processed using a Save action. If the list is not present, all forms and workflows can be processed as SaveNoValidate.

To implement this feature in your deployment, you must add any forms or workflows using SaveNoValidate to the saveNovalidateAllowedFormsAndWorflows list in the System Configuration object. To see the IDs or form names that you must add, check the syslog or turn trace level 4 on for com.waveset.ui.util.GenericEditForm and submit any custom forms or workflows that use SaveNoValidate. Waveset will log a warning including the ID. If you are getting “null” form names in the syslog, confirm that the form in the TaskDefinition that was run has a name attribute.

Tracking Workflow Progress

The designated owner of a task can always check on the status of a Workflow task. The owner is usually the person that initiated the task, but ownership can be redefined. Because tasks are objects in the repository, they will also be visible to anyone else with sufficient permissions.

Workflow status is typically represented in the Task List State column by the strings executing, pending, creating, and suspended. You can add additional, more informative strings summarizing workflow status to this column display.

Implement this feature by adding one of two possible expressions to the WFProcess file:

<WFProcess name=’queryRoleTask’ maxSteps=’0’>
     <s>Customized Status</s>
     <Activity id=’0’ name=’start’>
       <Transition to=’GetReferencingRoles’/>
     <Activity name=’GetReferencingRoles’>
       <Action id=’0’>

<Status> can be any XPRESS statement that results in a string. For example,

   <s>custom string</s>


     <s>not appearing</s>
     <s>custom string</s>

The results of this expression, if any, are displayed in the Status column when a result is pending (for example, pending (custom status)).

Configuring Workflow Properties

The System Configuration object controls workflow configuration properties. The following table lists the most frequently configured properties.

Table 1–11 Workflow Properties in System Configuration Object

Attribute Name  

Data Type  

Default Value  



























Specifies whether trace messages are emitted to the console. When set to true, trace messages are emitted. Default is false.


Specifies whether trace messages are emitted to a named file. To send trace messages to a specific file, enter the file name.


Specifies the maximum number of steps allowed in any workflow process or subprocess. Once this level is exceeded, Waveset terminates the workflow. This setting is used as a safeguard for detecting when a workflow is stuck in an infinite loop. The default value set in the workflow itself is 0, which indicates that Waveset should pull the actual setting value from the global setting stored in the System Configuration object’s workflow.maxSteps attribute. The value of this global setting is 5000.


Specifies whether trace messages should be retained in the task’s result object. When set to true, trace messages accumulate in the task’s result object.


Indicates whether the entire history should be returned after the task has completed. When set to true, Waveset returns the entire case history. Although it can useful to examine the history when diagnosing process problems, complete results can be large.


Indicates whether generic objects should be included in workflow trace operations.


Specifies the level of detail included in workflow trace. An unspecified or 0 value generates the most detail. The default is 1.


Identifies the level of strictness that is applied when validating workflows prior to running them. Errors of this level or greater will result in the workflow not being run. Valid values are CRITICAL, ERROR, WARNING, or NONE, where NONE turns off validation completely.

The default is CRITICAL.

serverSettings.default.reconciler Attributes

You can use these two reconciler attributes to tune per-account workflows:

The product of these two values should be at least the time required for the customer’s per account workflows to succeed. This interval will allow for lock-contention issues to resolve internally in the reconciler.

Consider the following scenario:

The total time spent retrying will be 15 seconds (3 x 5000 milliseconds).

This configuration is not optimal because the total time spent retrying (15 seconds) is less than 30. The customer in this example scenario should increase the lockwaitThreshold and maxRetries values so that their product exceeds total per-account workflow time.

Using Workflow Services

Waveset contains default workflows to define the process for provisioning and manipulating user accounts. When customizing Waveset, you can modify these workflows to reflect the business rules that are unique to your deployment environment. Workflow allows you to implement unique business rules for account provisioning in Waveset.

This section provides a high level discussion of the following workflow service-related topics:

For information on specific workflow methods, see <distribution>\REF\javadoc, where <distribution> is your installation directory.

Understanding Method Context

The Lighthouse context represents an authenticated session to access the Waveset repository, which is subject to authorization checking to enforce visibility and action restrictions. Creating, modifying, and deleting users and other Waveset objects requires authenticated access to the repository provisioner. This access is established by a context object, typically a LighthouseContext, or a WorkflowContext. Each of these context objects contains an authenticated session object that gives the caller access to the repository.

A context (or Session) is fairly intuitive when operating in the context of a logged in environment -- specifically, in a web browser. But within Waveset, a workflow is a separate process (actually a TaskInstance), and independent from any browser session, must still access the Waveset repository. This is possible because the executing workflow has an active context that is assigned to the workflow when it starts and can be persisted/restored with the workflow when it suspends/resumes.

When a user interacts with a workflow (typically through a WorkItem or ManualAction), the workflow maintains its own context. It does not assume the context of the user interacting with the WorkItem (although that user must possess a context that gives them appropriate access to the WorkItem). If the user interacting with the WorkItem causes a form to be loaded, Waveset processes the form with the context of the user, not the context of the workflow. To be more precise, the user interacting with the WorkItem is not interacting with the workflow at all. The user is simply interacting with the WorkItem. After the user modifies the WorkItem, the Scheduler will restart the workflow if appropriate.

Built-In Workflow Variables

The workflow engine uses several built-in variables. Most of these variables do not need to be declared in the workflow. However, you can use built-in variables to find out the state of the workflow execution. In addition, many variables are set as a side effect of workflow services.

Note –

Workflow variables are case-sensitive. For example, WF_ACTION_ERROR is not the same as wf_action_error.

Table 1–12 Built-In Variables




A built-in variable that will be set to true if the previously executed action returned a result containing an error or a thrown exception.


A built-in variable that will be set to the WavesetResult object returned by the previous action. Use this variable when you want to capture the action’s WavesetResult and process it without adding it to the global TaskInstance result. This variable was originally added to support resource retries, where you do not necessarily want to keep adding the resource error messages to the task result on every retry. It is not used often, but can be useful if you ever want to tweak the action result before adding it to the task result. 


This built-in variable will be set to true if the action was suppressed due to a <Condition> expression evaluating to false. 


A built-in variable that will be set to true if the previously executed action timed out. 


A built-in variable that contains the name of the administrator who launched the workflow task. 


A built-in variable that contains the WavesetResult of the TaskInstance. This can be used in actions implemented in XPRESS or JavaScript to retrieve the result. For actions that are implemented as WorkflowApplication classes, they can obtain the result through the WorkflowContext. Because the entire WorkflowContext is exposed through the WF_CONTEXT variable, this is not absolutely necessary, but convenient. 


A built-in variable that contains a WorkflowContext object. You can use this in actions implemented in XPRESS or JavaScript to retrieve the WorkflowContext. For actions that are implemented as WorkflowApplication classes, the context is passed in. 

General Session Workflow Services

The com.waveset.session.WorkflowServices class contains a set of services that support a range of operations, including general operations (get, checkout, checkin, etc.) on views and objects.

General Session Workflow Services Call Structure

Workflows have an internal hierarchical structure that constrain both flow of control and scope of variables. A workflow (also called a Case or WFCase) contains a list of workflow Activity elements. A workflow activity contains a list of Action elements. A variable declared at the WFCase is visible to all Activity and Action elements. If a variable named color is declared at the WFCase level, and then again in an Action, they are effectively two different variables, such that changing the value of the color variable in the Action will not affect the value of the color variable from the WFCase.

Workflow services are called from workflow actions. WorkflowServices provides a set of operations that are selected through the value of the op Argument. Each operation can have a different set of arguments, so the calling ’signature’ must match the specified service itself. The general form of a workflow service action is shown in the following code example:

<Action class=’com.waveset.session.WorkflowServices’>
   <Argument name=’op’ value=workflowServiceOp/>
   <Argument name=argname1>
   <Argument name=argname2>
   <Argument name=argnameN>

Each of the supported workflow services has a variable number of required and optional arguments. The op argument to the session workflow services call must specify one of the provided services. This is similar to calling a method by reflection, where the name of the method to be called is similar to the name of the workflow service to be executed.

If an op argument is given that is not on the following list, the workflow services return:

’Unknown WorkflowServices op’

and the workflow context variable WF_ACTION_ERROR will be non-null.

If an op argument is given that is not on the preceding list, a workflow service returns:

’Unknown WorkflowServices op’

and the workflow context variable WF_ACTION_ERROR will be non-null.

Supported Session Workflow Services

The com.waveset.session.WorkflowServicesJavadoc for workflow services documents the internal Waveset Java string fields rather than the nomenclature required by XPRESS. For example, the documentation for the workflow services operation addDeferredTask is provided by the Javadoc for the WorkflowServices OP_ADD_DEFERRED_TASK string field. In general, to find the Javadoc for an operation, take the operation name, capitalize and separate with an underscore the words making the operation name, and prefix the result with the OP_. Operation argument names are treated similarly, but prefixed with ARG_.

Provision Workflow Services

The com.waveset.provision.WorkflowServices class also contains a set of services, although they are used less often than the methods in com.waveset.session.WorkflowServices. These are the low-level primitives for performing account management, and they are primarily called by the default workflows. In a custom workflow, you might want to use these services, or you might prefer to use the higher level views with checkoutView and checkinView, which will in turn launch the stock workflows.

The primary purpose of the provision services is to give workflows access to the Provisioner, which in turn has access to resources and resource accounts. These are the services that actually perform the read/write operations on the resources themselves.

General Provision Workflow Services Call Structure

Workflows have an internal hierarchical structure that constrain both flow of control and scope of variables. A Workflow (also called a Case or WFCase) contains a list of Workflow Activity. A Workflow Activity contains a list of Actions. A variable declared at the WFCase is visible to all Activity and Action elements. If a variable named ’color’ is declared at the WFCase level, and then again in an Action, there are effectively two different variables, such that changing the value of the ’color’ variable in the Action will not affect the value of the ’color’ variable from the WFCase. Workflow services are called from workflow actions. WorkflowServices provides a set of ’operations’ that are selected through the value of the ’op’ Argument. Each operation may have a different set of arguments, so the calling ’signature’ must match the service itself. The general form of a session workflow service action is shown in the following code example:

<Action class=’com.waveset.provision.WorkflowServices’>
   <Argument name=’op’ value=workflowServiceOp/>
   <Argument name=argname1>
   <Argument name=argname2>
   <Argument name=argnameN>

Each supported workflow services will have a variable number of required and optional arguments.

Supported Provision Workflow Services

The com.waveset.provision.WorkflowServices Javadoc contains information about currently supported provision workflow services. The op argument to the workflow services call must be one of these values.

If an unsupported op argument is given, a workflow service returns:

”Unknown WorkflowServices op’

and the workflow context variable WF_ACTION_ERROR will be non-null. Provision and session workflow services map XPRESS operations to argument names in the same way.

Understanding the View Operation Methods

Because most workflow processing involves views, the most common view-related methods used in workflows are the checkoutView and checkinView methods. Checking out a view object will lock the underlying object such that no other user can write to it. This is especially important in workflow processing because a workflow may check out (lock) a user, and then suspend due to a manual action, leaving the user locked until the manual action is serviced (which could be hours or days later). By default, locks on objects expire in 5 minutes, which poses a second concern for workflows. A check in of an object requires that the caller already have the object locked. So a workflow that checks out a view (implicitly locking the object), suspends for 10 minutes, and the checks in the view will fail because the callers lock will have been aborted due to the 10 minute delay.

The following example shows a typical checkout operation:

<Action id=’-1’ application=’com.waveset.session.WorkflowServices’>
   <Argument name=’op’ value=’checkoutView’/>
   <Argument name=’type’ value=’User’/>
   <Argument name=’id’ value=’mfairfield’/>
     <Variable name=’view’/>
   <Return from=’view’ to=’user’/>

Using map of options with Checkout and Checkin Calls

It can be challenging to determining which options you can use as optional arguments (which are defined as part of the UserViewConstants class) for these check out and check in calls. The Javadocs list options in this format:




Instead of hard-coding these literal strings in your code when checking for options, Waveset provides constants that you can use throughout your code to represent a string. While this is a good coding practice, you cannot reference the static fields of UserViewConstants, such as OP_TARGET_RESOURCES, through XPRESS or workflow.

To identify valid strings that you can pass in the correct value, you can write a test rule that reveals the true string. For example, the following rule returns TargetResources.

   <set name=’wf_srv’>
      <new class=’com.waveset.provision.WorkflowServices’/>

      var wfSvc = env.get( ’wf_srv’ );
      var constant = wfSvc.OP_TARGETS;

Although handy for finding out a string, this rule is not appropriate for production deployment because it returns the same string for every call made to it. To minimize this problem, Waveset constants that are used in view processing are never changed. Once you have coded the constant in your workflow, the view’s interpretation of that constant will not change from release to release.

One you have identified valid strings, you can update your checkout view call as follows. The following code checks out a view that propagates only changes to Waveset and Active Directory.

<Action id=’-1’ application=’com.waveset.session.WorkflowServices’>
   <Argument name=’op’ value=’checkoutView’/>
   <Argument name=’type’ value=’User’/>
   <Argument name=’id’ value=’mfairfield’/>
   <Argument name=’options’>
<Variable name=’view’/>
<Return from=’view’ to=’user’/>

Best Practices

From a performance perspective, best practice suggests limiting the size of the User view whenever possible. A smaller view means less data is pulled from the resource and sent over the network. Because the view is held as a variable in the workflow, any time the workflow task is suspended the view must be written to the TaskInstance object. If a system is running thousands of workflows concurrently, and each workflow contains large views, the amount of time spent transferring the view to/from the repository (which includes serialization/deserialization) becomes a significant bottleneck.

The best use of a view is to carry only enough data necessary to allow changes to the user to be made and approved intelligently. If the intent of the caller is to change a user’s password on a set of resources, all that is necessary to know to drive this process is a list of accounts associated with the user. Specific account data would not typically be necessary for this process.

Sample Scenario One

A customer might decide to implement a custom workflow so that users can request access to a particular resource, that workflow should check out the User view to allow a change to be submitted to it (pending the appropriate approval). In this example, the only information that probably must be available is the Waveset User portion of the view so that the waveset.resources list and the accountInfo object can be updated appropriately. In this situation, use the TargetResources option when checking out the User view to check out only the Waveset User portion of the User view with an option map similar to the following:


You can reduce the size of the User view in the WorkItem view. Work items are the objects that represent a task assigned to an individual such as an approval, a delegation, or simply an interruption in a workflow to allow a user to input additional information. Custom workflows create approvals and interact with forms through manual actions. In short, a manual action copies all Workflow variables that are in the scope of the current <ManualAction> element. In addition to the task context, into a variables object within the WorkItem object. In terms of approvals, you rarely need the full User view and context variables. As a result, consider reducing the WorkItem size by specifying the ExposedVariables argument when defining a ManualAction.

The <Exposed Variables> element tells the workflow exactly which variables are necessary to capture in the WorkItem for subsequent processing. Remember that if a single workflow supports multiple approvers, Waveset will create multiple work items (one for each approver).

Sample Scenario Two

The preceding scenario shows a relatively uncomplicated implementation of single manual action. But typical deployments involve more complicated scenarios. For example, a customer might require that when a user is created, an approval goes to a ”bucket’, where one of approximately 25 approvers can select the approval. To mimic a bucket, you can create a work item for each approver in the bucket. All an approver must do is accept the action. Once accepted, Waveset can discard the remaining 24 work items, and generates the actual approval work item for the approver who accepted the bucket request.

Consider that there are a total of three buckets that act as escalation tiers. When the approval is processed through Bucket 1, Waveset escalates a new request into Bucket 2, and the process begins again. This process results in approximately 26 work items per bucket (25 + 1) multiplied by three (for three buckets). One user request would create 78 work items, granted not all at once. But then consider this occurring in a deployment environment containing a user base of 500,000 users with hundreds of these requests flowing in each day. Had the implementer of this scenario not bothered to size the WorkItem views by using the ExposedVariables argument, Waveset would store a large amount of bit of non-essential data in the work items and being passed over the JDBC connection.

<Activity id=’0’ name=’activity1’>
   <ManualAction id=’-1’>
         <ObjectRef type=’UserForm’ name=’Access Review Abort Confirmation Form’/>
   <WorkflowEditor x=’53’ y=’111’/>

Sample Scenario Three

You must write a custom user provisioning request workflow for users to execute. This type of workflow might be handy when customers want managers to submit provisioning requests for their direct reports but prefer to avoid making every manager in the organization an Waveset administrator.

With these requirements in mind, you create a custom workflow that:

You will also need to refresh the view. Refreshing the view means that Waveset re-examines the assigned resource information and re-fetches that information from the native resources to update the User view with the latest information (if it changed since view check-out).

You can ensure that Waveset refreshes the view by specifying a ViewVariables element within the manual action that instructs Waveset which variables in the WorkItem’s variables object should be treated as a view and thus refreshed when requested. See the preceding example for an example of specifying the variable user as a ViewVariable.

Using WorkItem Variables: Summary

As you can see from the preceding scenarios, you can control the size of WorkItem objects through the careful use of top-level variables. Waveset creates a WorkItem object for each manual action that is processed in a workflow. By default, these objects contain a copy of all top level variables from the executing workflow. There are three ways to control the variables that are passed into and assimilated back from WorkItem objects:


You can use ExposedVariables to control which variables from the workflow are copied into the WorkItem object. If you have defined ExposedVariables, only those variables in the list are copied to the WorkItem. Using this option controls the size of WorkItem objects reducing memory usage, database size, and CPU processing time. The definition should be a list containing string representations of the workflow variables. Two example definitions follow.

<!-- Pass the entire view object but no other WF variables -->

<!-- More optimized to only pass the Lighthouse attributes and 
     email value -->
<!-- Note the definition of a partial GenericObject path and a complete 
     GenericObject path -->

Passing only the data that the UserForm requires to operate optimizes the WorkItem processing time. This reduces the time required when processing the workItemEdit.jsp and also reduces total memory consumption and GC activities for the JVM. Without this option, the system can quickly consume a large amount of CPU time during concurrent user operations.


You can use EditableVariables to control which variables from the WorkItem object are assimilated back into the workflow. The classic usage of this definition is to control which variables can be edited by the approver. EditableVariables is most useful during parallel approvals to prevent two approvers from overwriting the same data. Make sure you read the note regarding ExposedVariables.

<!-- Only the firstname, lastname fields should be assimilated 
     from the WorkItem -->
<-- Note the inclusion of the formButton variable which is used to 
    store the button value -->
<Field button='true'>
   <Display class='Button'>
      <Property name='name' value='variables.formButton'/>
      <Property name='label' value='Submit'/>
      <Property name='command' value='Save'/>
      <Property name='value' value='submit'/>

To debug, see workflow.fileTrace attribute of the System Configuration object to identify which variables are being assimilated back into Workflow from the view. ViewVariables is used to control which variables represent view objects which should be refreshed when a refreshView operation is executed from the workItemEdit.jsp page. In general a refreshView operation reloads the view data from all of its sources such as resource adapters.


You can use ViewVariables to control which variables represent view objects that should be refreshed when a refreshView operation is executed from the workItemEdit.jsp page. In general, a refreshView operation reloads the view data from all of its sources such as resource adapters.

<!-- The userView variable should be refreshed during a refreshView -->

Tip –

Use ViewVariables only when absolutely necessary for correct form and user interaction. This is option is seldom used.

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.

Note –

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.)

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’/>

Note –

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:




Name of the workflow being executed 


Name of the current process being executed 


Unique instance ID of the workflow being executed 


Activity in which the event is being logged 


Unique identifier within a workflow instance 


The name of the user’s organization 

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.

Adding Applications

You can register your own Java methods so that they can be accessed from the Sun Identity Manager IDE.

ProcedureTo Register Methods

  1. Edit the idm/config/workflowregistry.xml file.

  2. Add the application definition, in a form similar to this example:

    <WorkflowApplication name=’Increment Counter’
      class=’com.waveset.util.RandomGen’ op=’nextInt’>
       <ArgumentDefinition name=’start’ value=’10’>
          <Comments>Get the next counter</Comments>
  3. Restart the Sun Identity Manager IDE.

    The new application is added to the application menu.