Resource based workflows must follow the same guidelines outlined in Section 6.5, Guidelines for Creating Workflows. In addition, resource based workflows have the unique requirements described in the following sections:
Resource approval workflows are specialized workflows that provide support for resource approval and revocation on the User Application’s
tab. The Roles Based Provisioning Module includes a read-only Resource Approval workflow (named Resource Approval) whose design pattern supports:The ability to process resource approvals in either serial or quorum mode.
The retrieval of approver DNs from the resource object (nrfResourceRequest). If you create a custom workflow, the approvers must be defined in the workflow; however, this might lead to addressee evaluation problems and less security concerning who can approve a resource.
The ability to display the resource using localized display names.
All nrfResourceRequest object mappings for request and approval forms.
Logging and reporting functions.
Read-only display of request information. The resource approval workflow does not allow changes to the request. Approvers have only the ability to approve or deny the resource request.
An e-mail notification is sent to all approvers of resource approval workflows. A completed notification e-mail is sent upon completion of the resource approval workflow. The recipient e-mail address is used when the workflow is intended to be assigned to a user identity.
This pattern is shown in Figure 6-11.
Figure 6-11 Default Resource Approval Workflow
The components of this workflow, and their responsibilities are summarized in Table 6-13.
Table 6-13 Standard Resource Approval Activities
To use the standard Resource Approval workflow in your user application, you must specify your own users as Trustees. For information on setting the Trustees property, see Section 4.2.6, Modifying Settings of a Provisioning Request Definition.
If the standard resource approval workflow does not support your business needs, and cannot be customized to do so, you can write your own. At a minimum, a custom resource approval workflow must:
Contain two Resource Request Binding activities
One Resource Request Binding activity must be set to approved and the other set to denied. You must link each of the Resource Request Binding activities to the Finish activity. If the workflow does not meet this requirement, it is invalid, and Designer prevents you from deploying it. The Role and Resource Service driver needs these values to set the status for the workflow and to then apply the logic to associate the resource to the identity.
Contain the following control in the request form:
Form Field Name: nrfResourceRequestDN
Data Type: Resource Request
Control Type: Text
Instantiate the nrfResourceRequestDN in the Pre Activity Data Item Mapping.
Contain the following in the Post Activity Data Item Mapping:
Source Form Field: nrfResourceRequestDN
Target Expression: flowdata.nrfResourceRequestDN
Data Type: dn
Not contain the following ECMA expressions in the Data Item Mapping or Properties definitions because they might return null:
getApprovalDN()
getAllApproversDN()
getAllSodApproversDN()
Because Designer and the User Application user interface do not allow entry of approvers for custom resource approval workflows, you must specify the approvers in the workflow itself. Therefore, if you create a custom workflow based on a copy of the Resource Approval provisioning request definition, you must remove the ECMA methods from Data Item Mapping or Properties definitions.
In the following example, a user requests a resource and the user’s manager approves it.
Figure 6-12 Sample Custom Resource Approval Workflow
The components of this workflow, and their responsibilities are summarized in Table 6-14.
Table 6-14 Sample Custom Workflow Components
The data item mapping for the sample custom resource approval workflow is defined in Table 6-15
Table 6-15 Sample Custom Resource Approval Workflow Data Item Mapping