Using the Sun Java System Identity Manager IDE, you can edit the default Identity Manager processes to follow a custom set of steps. The Identity Manager workflow capability includes a library of default workflow processes, which includes:
User workflows— Define the steps for tasks related to Identity Manager users, including creating, deleting, updating, enabling, disabling, and renaming users.
Identity Manager object workflows— Define the steps for all tasks related to Identity Manager objects, including resources, resource groups, organizations, and organizational units. For example, some workflows, such as the Manage Role and Manage Workflows workflows, simply commit view changes to the repository, while providing hooks for approvals and other customizations.
Miscellaneous workflows— Define the steps for various Identity Manager features and objects such as reconciliation, Remedy templates, and other custom tasks.
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’/> <FormRef> <ObjectRef type=’UserForm’ id=’#ID#UserForm:ApprovalForm’/> </FormRef> <ReportTitle> <concat> <s>Awaiting approval from \n</s> <ref>APPROVER</ref> </concat> </ReportTitle> </ManualAction> <Transition to=’Escalate’> <eq> <ref>WF_ACTION_TIMEOUT</ref> <s>true</s> </eq> </Transition> <Transition to=’Approved’> <eq> <ref>APPROVED</ref> <s>true</s> </eq> </Transition> <Transition to=’Rejected’/> </Activity> |
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 |
Description |
---|---|
approval |
Indicates that the work item represents an approval. |
wizard |
Indicates that the work item represents an arbitrary interaction with the user. |
suspend |
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.
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:
complete (WorkItem attribute)
variables.* (task variables)
variables.<view>.accounts[*].*
variables.<view>.waveset.*
variables.<view>.accountInfo.*
:display.session (session for Owner)
Applies to both custom tasks and administrator approvals.
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’>
To specify an item type in the ManualAction definition, set the itemType attribute as shown in this example:
<ManualAction itemType=’approval’>
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:
Define new authorization types that extend the WorkItem type. For example, define the RoleApproval type.
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.
Assign the Role Approver capability to an administrator rather than the general Approver capability
Set appropriate authorization types in each manual action in your workflows.
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:
One of the following two attributes:
accountId– Specifies the name of the user for whom you want to get delegation information
accountIdList– Lists the user names for whom you want to get delegation information.
delegateWorkItemType - Specifies the work item type for which you want to get delegation information (that is, approval, roleApproval or attestation). Valid work item types are defined in the WorkItemTypes configuration object.
delegateWorkItemTypeObjectName - Specifies the name of the object for which delegation information is to be gathered. Note that this argument is valid only if the delegateWorkItemType is either organizationApproval, resourceApproval, roleApproval or any extensions of those types.
delegateWorkItemTypeObjectType - Specifies the type of object for which delegation information is to be gathered. Note that this argument is valid only if the delegateWorkItemType is either organizationApproval, resourceApproval, roleApproval or any extensions of those types.
The service returns a list of delegate objects in the delegateObjects argument.
Each delegateObject contains the following attributes:
approver– Specifies the approver of this work item.
delegator– Specifies the initial, or first delegator, for the work item. This user is set as the <WorkItemDelegator> for the work item.
delegators– Lists delegator names ordered from first to last (before the final approver). This list of users is set as the <WorkItemDelegators> element for a manual action. If no delegation was found, this value is null.
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.