5.1 About Workflows

An Identity System workflow enables Master Identity Administrators and Delegated Identity Administrators to apply business logic to Identity System functions. A workflow organizes and automates complex procedures, for example, creating benefits and email accounts for new employees or changing user profile attributes in the directory.

Each workflow consists of a sequenced chain of actions. For example, an administrator can add a new user identity in the User Manager, and after submitting the new information, the new information can be routed to various departments for additional information, approvals, and so on. Rather than making a single person responsible for completing all the tasks in the workflow, you can assign each step to the specialist most appropriate to perform that step. When a step is completed, the workflow engine can send the workflow ticket to the person responsible for the next step in the sequence.

In sum, workflows enable you to:

Automate and standardize processes for creating objects, deleting objects, and modifying attributes in the directory.

Configure the Identity System as a data entry system for provisioning back-end applications.

As with user, group, and administrator information, Oracle Access Manager stores information about the workflow definition in the directory. This includes information about the people who can approve a step in a workflow. Workflow definitions are located in the configuration branch of the directory, as opposed to the user or group branch.

5.1.1 How Workflows Are Initiated

Workflows can be initiated by a user. For example, a new employee can initiate a self-registration workflow.

Workflows can also be initiated programmatically. For example, you can initiate the workflowSaveCreateProfile function in IdentityXML to initiate a create user workflow. See Oracle Access Manager Developer Guide for details.

5.1.2 Typical Workflow Examples

Workflows are appropriate for just about any frequently repeated, multi-step task involving any combination of user actions or automated data retrieval. Each workflow is associated with one of the Identity System applications. The following list covers some common workflows:

User Manager: You can define a workflow to permit users to change their department number and phone number pending approval by a manager. You can ensure that when a new user is created, the appropriate people obtain information about this person programmatically from an external system.

A different workflow can add new users to your corporate email application. If you have defined an object template schema, you can use a workflow to send data from an Identity System application to a back-end application for provisioning. See "Sending Non-LDAP Data to External Applications" for details on object templates.

Group Manager: You can create a workflow to route group registration requests to a manager for approval.

Organization Manager: You can give a supplier the ability to create entries for parts, pending manager approval of each entry the supplier adds. You can also create a workflow that first enables a user to add a new part entry, then routes the request to add the data to an appropriate person for approval, and finally, permits the person giving approval to commit the new data to the directory.

5.1.3 Advanced Workflow Options

The Identity System workflows support the following advanced features:

Subflows enable certain workflow activities to occur in parallel.

For instance, if a request to create a new user requires approvals from two different departments, both parties can receive approval requests simultaneously. See "Defining a Subflow" for details.

You can route specific workflow steps to different dynamic participants, who are selected based on attribute values or business logic evaluated at run time.

5.1.4 Workflow Types

Workflows come in various types. For instance, one type of workflow enables you to change one or more attributes for an existing object. Another type of workflow enables you to create a new object. Figure 5-1 illustrates a Create User workflow:

Figure 5-1 Create User Workflow

Note:

The steps to create a user identity depend on how you (the administrator) define the Create User workflow. If there is no Create User workflow defined, even an administrator sees a message saying they do not have enough access rights when they select the Create User Identity tab.

5.1.5 Creating Workflows

The following overview summarizes the high-level steps for creating a workflow. The actual steps vary slightly for Change Attribute workflows and Create User (or Group, or Object) workflows:

Task overview: Creating a workflow definition

Add objects to the tab for the relevant Identity System application.

Configure attributes for the objects.

Configure read and write permissions for LDAP attributes.

Participants in a workflow must have appropriate read and write permissions for LDAP attributes that are viewed and changed during the processing of the workflow. See "Allowing Users to View and Change LDAP Data" for details.

Add the attributes to the application panels.

This applies to both LDAP and template attributes. For Change Attribute workflows, users do not see the attributes from template objects on the profile page that contains the panel. However, the template attributes must be added for the workflow to operate properly.

Configure the workflow.

As discussed in "Defining Step Attributes" for details, when you add attributes for a step in a Change Attribute workflow, the topmost attribute in the list must have been configured on a profile page. The subsequent attributes in the list are added to the page automatically as long as the topmost attribute has been configured correctly.

A workflow definition changes the appearance of its related profile page in the Identity System application for which the workflow was created. For example, when a Modify Attribute workflow has been configured correctly, a Modify button appears next to the attribute on the Modify Profile page for the target object. When a Create User workflow has been configured correctly, the desired attributes appear when you select Create User Identity in the User Manager.

5.1.6 How Users Access Workflows in an Identity System Application

After a workflow definition has been created, an instance of the workflow is initiated in one of several ways, depending on the type of workflow that is being used:

Table 5-1 Methods for initiating Workflows

Workflow Type

User Initiates This Workflow From. . .

Change Attribute

A Request to Modify button on a Modify Profile page for the user

Create User

The Create User Identity page that is accessed from the Create User Identity link in the User Manager.

Deactivate User

An Initiate User Deactivation button on the View Profile page for the user.

Reactivate User

An Initiate User Reactivation button appears on the View Profile page when you have created a Reactive User workflow. You first must find the user from the Deactivated User Identity page in the User Manager.

A Reactivate user operation can be done by a Directory Administrator or a user with reactivate privileges.

Self-Registration

When this type of workflow is created, a URL is generated that initiates this workflow. You must save the URL and use it to initiate the Self-Registration workflow.

Create Group

The Create Group page that is accessed from the Create Group link in the Group Manager.

Delete Group

The View Profile page for the group.

Create Object

Create page in the Organization Manager.

Delete Object

View Profile page for the object.

5.1.6.1 About Workflow Tickets

As program execution reaches a given step in a workflow, the workflow engine creates a ticket for that step instance. During a Create User workflow, for example, a ticket is typically sent to specific participants in IT as soon as the user selects the Create User function in the User Manager.

Each workflow ticket is initially displayed in the form of a link. When the participant clicks this link, he or she is prompted to perform the action associated with that step in the workflow. For example, when someone in IT processes a ticket for a Create User workflow, he or she is typically prompted to supply a login id and password for the new user.

A workflow log is created upon completion of each step in the workflow.

For example, the contents of a Create User Identity page might be based on attributes configured in a Create User workflow.

Once information about a new user is saved on this page, the initiate step of the workflow is complete. The workflow definition generates a ticket for this workflow instance, as illustrated in the following screen shot.

A participant in this workflow can view the ticket generated for this workflow step, and can approve the addition of the new user. You display ticket information by clicking on the ticket number next to the approval label.

Note:

You see different results depending on number of steps involved in the workflow.

Ticket information is displayed only when the workflow includes a step (task) that must be performed after the current step is completed. However, the Enable step is not a task to be completed by any participant. Therefore no ticket is generated for the Enable step. The number of steps in a workflow affect the result that you see on the confirmation page. Here are two examples:

Single Step Workflow: Suppose the workflow has only one step that requires participants, Initiate (the Enable step does not require participants). After the Initiate step is performed no ticket is generated because the next and last step is Enable step, which requires no participant action. In this case, the confirmation screen shows only the following message:

Initiate - Completed
Enable - Completed

Multiple Step Workflow: Suppose the Create User workflow includes three steps (Initiate, Approval, Enable). After a participant performs the Initiate step, a ticket is generated to notify participants that the Approval step can be performed. In this case, a ticket is generated for the Approval step and you might see a message like the following:

5.1.6.2 A Workflow Scenario

Suppose you create a workflow for adding a user in the Identity System. You could define a Create User workflow that performs the following steps. Use caution when you create a user that includes multi-byte charcters in the password. User creation might fail if you are using a non-English keyboard. For more information, see "User Creation Might Fail When You Have Multi-byte Charcters in the Password".

Process overview: Creating and using a Create User workflow

From the User Manager application, you create a new workflow definition.

In this example, the workflow definition has three steps and specifies that anyone in IT who has logged in to the User Manager can create a new user. workflow:

Step 1. Initiate: This step allows anyone who has logged in to the User Manager to input data for a new user.

Step 2.Provide Information and Approval: This step allows the user's manager to approve the data entered for the user.

Step 3. Activate: This step activates the new user.

A user logs in to the User Manager.

The user selects a Create User button.

The workflow instance prompts the user to supply a name, user ID, and password for the new user, plus the user ID and email of the new user's manager.

The workflow instance then routes a request to create the new user, along with information about the new user, to the manager of that user.

The manager clicks the Requests function in the User Manager application to display the request in the form of a link to a job ticket.

The manager clicks the link for the ticket to display the request.

To approve the request, the manager clicks a Process Request button.

In the Process Requests page, the manager clicks an Approve button.

The request is processed and the new user is enabled in the Identity System.

The user is now allowed to log in and use the functions they are entitled to as defined by their directory profile and the rights assigned to attributes in that profile by a Master administrator. See "Allowing Users to View and Change LDAP Data" for details.

5.1.7 LDAP Versus Template Attributes in a Workflow

When you define a workflow, you have a choice of using two types of objects and attributes in most workflow steps:

LDAP Objects and Attributes: You can use a workflow to modify objects and attributes that you have configured for an application profile page. The people who participate in the workflow must have appropriate privileges for viewing and modifying these objects and attributes.

Template Attributes: If you are using a workflow to provision a back-end application, you configure workflow steps for adding information based on a template schema. When template attribute values are committed during the workflow, an Identity Event API plug-in can intercept this data and send it to a back-end application for provisioning. See "Sending Non-LDAP Data to External Applications" and the Oracle Access Manager Developer Guide for details.

As of version 7.0, provisioning allows only for a one-way flow of data from the Identity System to the back-end system. As a result, you might want to configure provisioning workflows to write data to both the LDAP directory and to the back-end system. This enables your users to view the data that has been configured for the workflow target. However, to see the current state of the target in the back-end application, you must access the application or its logs.

For provisioning workflows, you should have separate Commit, Activate, Enable, Delete, Disable, and Deactivate steps for each schema to which the workflow is written.

5.1.8 Workflow Types, Steps, and Actions

A workflow type determines the purpose of the workflow, for example, creating a user. A workflow step is a discreet segment of the workflow. Steps are performed in a series. A workflow action is an activity performed during a step, such as issuing a request for information.

For example, the Create User workflow type enables you to create a directory entry for a user. This type of workflow can have actions for requesting information about the user, actions for collecting the information, actions for approving the request, and so on.

The following table correlates the different types of workflows to the Identity System applications:

Table 5-2 Workflow Types

Application

Workflow Type and Description

User Manager

Create User: Adds a user to the directory.

Self-Registration: Enables users to add themselves to the directory.

Deactivate User: Makes a user unable to log in and unavailable for viewing in the Identity System. Deactivation takes effect once a user has logged out. It removes a user's future access to the system. An administrator with sufficient access privileges can view deactivated users and either permanently delete them or reactivate them.

Reactivate User: Displays the Initiate User Reactivation button on the User Profile page and changes the status of a deactivated user, allowing the user to log in to and use the Identity System again.

Change Attribute: Changes an attribute value on a user profile. Attributes designated on this workflowhave a Request to Modify button on the target profile page.

Group Manager

Create Group: Adds a group to the directory.

Delete Group: Deletes a group from the directory.

Change Attribute: Changes an attribute value on a group profile. Attributes designated on this workflowhave a Request to Modify button on the target profile page.

Organization Manager

Create Object: Adds an object to the directory.

Delete Object: Deletes an object from the directory.

Change Attribute: Changes an attribute value on an object profile. Attributes designated on this workflowhave a Request to Modify button on the target profile page.

Self-Registration: Enables users to add organization objects to the directory.

5.1.9 About Workflow Steps

You must define at least two steps for each workflow: one to initiate an instance of the workflow and one to finish it. A step consists of the following:

A Number: A unique identifier for this step.

All workflow steps have a number.

Actions: An action is an activity can occur in the Identity System or in an outside system.

All workflow steps perform an action. Examples include starting the workflow, providing information, and requesting approval. See "About Step Actions" for details.

Attributes: An attribute value might be added or modified as part of a step.

For example, you might define a step for changing the value of a user's phone number attribute. Step attributes might be required, optional, or supplied by completion of another workflow step.

For values that are used locally within the Identity System, you configure LDAP attributes as part of the workflow. For provisioning to a back-end application, you configure both LDAP and template attributes in a workflow step.

Note:

If Location ID has the Semantic type DN Prefix it is important to note Active Directory and ADAM do not allow multi-valued RDNs (although iPlanet/SunOne do). For Active Directory and ADAM, ensure that the Attribute Value(s) selection is Single in the meta-attribute configuration.

Participants: A participant is a user or users who perform an action.

For example, for a Create User workflow, you can create an Initiate step and configure this step so that anyone who is logged in to the User Manager can start the process for creating a new user. Or you can define a specific participant in a workflow who is responsible for approving a change request. Participants can be assigned based on their role, name, group membership, or another characteristic.

For LDAP attributes, you can also define an LDAP filter that selects participants according to their DN.

Not every step in a workflow requires a participant. For example, in the default Create User workflow, the Enable step does not require participants. The action (enable) is performed automatically by the system when the previous step, for example, Approval, exits. The Commit and External Actions steps also do not use participants.

Target: The person, group, or other LDAP object that is being created, deleted, and so on.

The target in the workflow definition is an LDAP object, not a template object.

Entry Conditions: A step or subflow that must be completed before the present step.

For example, the first step in a workflow may be the Initiate step. The second step in the workflow might have an entry condition of successful completion of the Initiate step. Typically, the entry condition is successful completion of the previous step.

Notifications: Users who receive email notification before or after a step is performed.

Other participants can see pending tickets in their incoming request queues whether or not email notification is configured. See "Descriptions of Step Actions" for details.

Pre and Post Processing: External functions that are executed as part of the workflow.

For example, in a create user workflow you might want to have a Java program that is called after an initiating step to assign a unique login ID.

5.1.11 Descriptions of Step Actions

User Manager only. Activates a new user in the Identity System. An activated user is enabled, and can log in and perform operations granted by administrators. The obuseraccountcontrol attribute in the user's entry controls activated/deactivated status. The Activate action requires a participant, such as a manager, to activate the user.

Approval

This action can be configured with required attributes. At run time, the values for the required attributes are presented to the participant for approval. No information can be changed by this action.

Change Information and Approval

Performs the same function as the Provide Info and Approval actions, but used only when deactivating users.

Change Information

Performs the same role as the Provide Info action, but is used only when deactivating users.

Commit

Writes the information collected in the previous steps to the directory. A commit operation writes information to the location of the e object in the directory. For example, during a Create operation, the Commit action adds a new entry to the directory. If the workflow contains additional Commit action, the information is written to the location in the directory that contains the newly created object. A Commit action can be used more than once in a workflow. No user action is required.

Deactivate

User Manager only. Deactivation takes effect once the user's current session has ended. A deactivated user cannot log in. Others cannot find a deactivated user in the Identity System except when searching for deactivated users. Deactivating does not delete the user from the directory. The obuseraccountcontrol attribute in user's entry controls activated/deactivated status. A participant is required for a deactivate step in a workflow.

Note: To create an .ldif containing deleted users, use the Deactivate or Disable workflow steps instead of Delete. Go to the Deactivated User Identity page, and use the Archive option. This deletes the users from the directory and create a deactivateduser.ldif in the

IdentityServer_install_dir\oblix\data\common directory.

Delete

The delete action in a Create User, Group, or Object workflow permanently removes the target entry from the directory. It is possible for a Create workflow to be rejected after a target entry is created. The Delete step cleans up the directory so that new attempts to create the same user can be made.

Disable

User Manager only. Deactivates a user, which means the user cannot be recognized by the Identity System once the user's current session has ended. Deactivation takes effect the next time the user attempts to log in. Deactivating does not delete the object from the directory. This action does not require a participant.

Enable

User Manager only. An Enable action is a combination of a Commit and an Activate action. Automatically activates the new user, who is then recognized by the Identity System after the previous step is completed. This action does not require a person to activate the user.

Error Report

When a background process encounters a processing error, you can configure an error report to send the error to particular users. You can also configure an error report when a step is rejected, for instance during the approval process.

External Action

An action performed outside of Oracle Access Manager.

Initiate

Starts the Create and Deactivate workflows. This action can be used once in a workflow. It must be the first action. The self-registration action can also be the initiating action of a workflow. All users see the Create Profile button or Initiate Deactivate option on their pages, regardless of whether they have been defined as a participant for this particular workflow. If a user clicks the button or link to the workflow but they have not been defined as a participant in the workflow, an error message is displayed.

Provide Information and Approval

Combines the Provide Info and Approval actions into one action.

Provide Information

Collects information from the user. This action is similar to Initiate, but it cannot be the workflow's first action.

Request

A user's request to change, add, or delete an attribute. Participants for this action see the Request to Modify or Request to Remove button on the Modify Profile page.

Self-Registration

Lets users complete and submit a registration form. Other participants approve the request and activate the user. This action must be the first step in a workflow. The self-registration action does not necessarily require other participants to approve and activate the new user.

Select Groups

Enables the workflow participant to subscribe a target user to a group or groups during a create user workflow. The new user has to meet the subscription policy. Available only after an Enable or Activate step.

Subflow Approval

Reports the current status of a subflow that has been invoked from a main workflow step. It does not apply to subflows invoked from other subflows.

Note:

Email post-notification for a self-registration step requires two parameters in the globalparams.xml, sendMailFromName and sendMailFromEmail. The values for these parameters are placed in the "mail From" or "senders name" and "mail" or "senders email" parts of the SMTP message respectively.

For self registration, these values are provided through globalparams.xml because the target is not yet created. In this case, you must locate the parameters in the globalparmams.xml, then modify the values to suit your environment. For example:

If the target user has been created, then emails are sent to specific participants. In this email, the sender's name and sender's email are determined from the logged in user's profile (the naming attribute and email attribute). If these are empty, then the parameters sendMailFromName and sendMailFromEmail are used to determine senders name and senders email respectively.

Use the UseDefaultOptionsForAllMails parameter in the Identity Server globalparams.xml to configure an email ID to be used to send all email notifications. For example, if:

ParamName="UseDefaultOptionsForAllMails" Value="true"

then for any email that is sent from the Identity Server the:

"Sender's Name" field gets the value from the "sendMailFromName" parameter defined in the globalparams.xml file."Sender's Email" field gets the value from the "sendMailFromEmail" parameter defined in the globalparams.xml file.

Present and True: If the UseDefaultOptionsForAllMails is present and set to true, but values are not defined in the globalparams.xml file, then conditions apply, as follows:

sendMailFromName not defined: An email is sent with the "sendMailFromEmail" parameter's value in the Sender's Name field.sendMailFromEmail not defined: If UseDefaultOptionsForAllMails is true and if sendMailFromEmail is not defined, then no email is sent. Instead, anappropriate message is sent to the user and an error is logged indicating that the notification email could not be sent.

Absent or False: If the UseDefaultOptionsForAllMails parameter is not present, or if it is present and the value is set to false:

5.1.12 About Subflows

In a simple workflow, all steps execute sequentially. If one step is in a pending state, the workflow does not progress to the next step. Because workflows often involve different participants, this can delay completing the workflow. To speed up processing of a workflow, you might want to define subflows that occur in parallel. Subflows lets you break down workflows into chunks. A subflow can trigger subflows of its own. You can trigger multiple subflows from a single workflow.

Note:

A subflow is always a Change Attribute workflow.

Process overview: A Create User workflow example

The hiring manager initiates a Create User workflow.

A request is sent to Facilities for an employee number and badge number.

A request is sent to IT for the login and password.

A request is sent to the hiring manager for final approval and activation of the user.

By using subflows, some of the requests can occur in parallel. The approval waits until the subflows are complete, as illustrated in Figure 5-3.

Figure 5-3 Order of step completion when using subflows

A workflow does not move to the next step until a subflow is complete.

Note:

For a subflow to launch, the target object or attribute must meet any filter criteria specified in the Workflow Domain filter.

5.2 Using the QuickStart Tool

For Master Administrators, the QuickStart tool enables the rapid creation of simple workflows based on default settings.

After completing a workflow definition using QuickStart, you can use workflow tools to modify the workflow definition, for example, you can specify dynamic participants or surrogates.The QuickStart tool enables you to define the following workflows:

Table 5-7 Workflows that Can Be Created with the QuickStart Tool

The workflow named. . .

Contains these steps. . .

Create User, Group or Object (Basic)

Self-Registration or Initiate

Commit

Error Report

Note: For a simple Create User workflow, required attributes are Last Name and Name on most directory servers and Login ID if you use Active Directory.

Create User, Group or Object (Advanced: with Approval)

Initiate

Approval

Commit

Error Report

Self Registration for Users or Objects (Advanced: with Approval)

Self-Registration

Approval

Commit

Error Report

Change Attribute (Basic)

Request

Commit

Error Report

Change Attribute (Advanced: with Approval)

Request

Approval

Commit

Error Report

The QuickStart tool assigns anyone who is logged in to the Identity System as the participant for most steps. For the User Manager, the participant in a Change Attribute workflow is any person who has been assigned the role of Manager. For the Group Manager, any person assigned the role of Group Owner is the participant in the Approval step of a Change Attribute workflow.

Once you create a workflow using the QuickStart tool, you can view and modify the workflow steps, participants, affected attributes, and so on. Information on viewing a workflow definition is provided in "Viewing and Exporting a Workflow Summary". Information on modifying a workflow is provided in "Modifying a Workflow".

You can define a Create workflow and a Change Attribute workflow from the same QuickStart page. Scroll to the bottom of the page to see the Change Attribute fields and options.

You can also provide a name for your workflow. A default name is provided, but it does not change if you use the QuickStart tool to create multiple workflows of this type.

If you select a Create workflow type, you can also specify one target location for the object the workflow creates.

The default target location is the searchbase for the Identity System.

Optionally, you can select additional attributes.

For a Create User, Create Group, or Create Object workflow, these attributes are entered during initiation or self registration steps.

For a Change Attribute workflow, these attributes are modified when running the workflow. A separate workflow is created for each attribute you select. For example, if you select five attributes, the QuickStart tool generates five change attribute workflows.

Click Generate.

View the summary report generated by the QuickStart tool.

To test the workflow, click a link to one of the workflows on the summary report.

After clicking the Generate button, click the link for the newly-created workflow.

When the new workflow appears, copy the URL.

You can use this URL when you set up the user registration page for your Web portal. This URL is the link to the first page of the workflow. See "Creating a Self-Registration Workflow" for other methods of defining self-registration workflows.

5.3 Using the Workflow Applet

In addition to using the QuickStart tool, you can define workflows using configuration pages that allow you to specify multiple options and subflows.

For each step in a workflow, there is an action. Actions are performed by people or by an automated method. You assign one action to each step in a workflow. You also assign participants to each step. See "Defining the First Step in a Workflow" for details.

Associate attributes with the step.

Step actions are performed on one or more attribute values. These attributes can be taken from the directory or from an object template. See "Defining Step Attributes" for details.

Subflows are conditions that must be satisfied for a particular step or workflow to complete. Like main workflow steps, subflows have associated actions, participants, and attributes. See "Defining a Subflow" for details.

Define one or more commit steps to end the workflow.

If you are configuring a workflow using more than one schema (for example, an LDAP schema and a template schema), you should configure separate commit steps for each schema type.

Note:

Template attribute values can be sent to the back-end system, but these values cannot be read back in to the Identity System for display on profile pages. As a result, to check if a workflow configuration was done correctly and an instance of using the workflow was successful, you might have to examine the data in the back-end system.

To access the Workflow Definition applet

From the Identity System Console, select the User, Group, or Organization Manager.

If the Organization Manager has more than one tab, select the appropriate tab.

Click Configuration, then click Workflow Definition.

On some browsers, you might receive a prompt asking if you trust the certificate of the application. If you receive this prompt, select the Trust Always option.

For the User Manager and Organization Manager, a Workflow Definition page is displayed.

If you are using the Group Manager, from the Workflow Definition page, select an appropriate group type if applicable and click Next.

If you do not select a group type, the Basic group type is used for this workflow.

5.3.1 Starting a New Workflow Definition

You can create workflow definitions for different sets of users. For example, you can define different Create User workflows for Engineering and Sales.

For a simple Create User workflow, required attributes are Last Name and Name on most directory servers and Login ID if you use Active Directory.

Note:

By default, the Identity System does not display every object and attribute in the directory. This parameter excludeOCsForTreeInApplet in Identity_install_dir/apps/common/bin/globalparams.xml enables you to expose object classes in the Identity System applications that would otherwise be hidden.

In the Workflow Description field, you can enter an optional description of this workflow.

In the Workflow Domain field, select the starting point in the directory tree from which this workflow is available.

If you want the workflow domain to match a directory entry of the logged in user who initiates the workflow, use substitution syntax. For example, if you want the "ou" of the workflow domain to always match the "ou" of the person who is generating the workflow, you would enter the following:

Do not use full LDAP URL while specifying the filter for workflow domain (or target domain) while creating the workflow. Only the LDAP filter is expected.

You can also select a particular domain where the workflow will be available. For instance, if you have different branches in your directory tree for Engineering and Sales, and you want this workflow to only apply to Engineering, you would select the top node for the Engineering branch of the directory tree. If you have a particularly flat directory tree or if the tree has a particularly high number of branches, you can narrow the workflow domain by entering an LDAP filter. See "Usage of Rules and Filters". For example, if the starting point in the directory tree is ou=people, and you want to create a workflow just for administrators, you might want a filter that contains (title=admin).

Note:

Be sure to test performance when using filters. Filters are evaluated at run time, which can affect performance.

If you are in the Group Manager and you are working with an Advanced Group, specify the Subscription Type, if applicable.

For example, this might be the case when you define a step for selecting a group or for allowing a user to add themselves to a group. Subscription Type options are available to your participants if the obGroupSubscriptionType attribute was configured for the oblixAdvanced Group object class.

The following subscription types are available:

Table 5-8 Workflow Subscription Types

Option

Description

No type selected

No subscription type is defined. Functionally equivalent to the Open policy.

Open

Enrollment is open to anyone who subscribes.

Open with Filter

Enrollment is open to any user who satisfies the Dynamic Filter (LDAP rule) for the group.

Controlled throughWorkflow

To subscribe or unsubscribe, the user must be the target of a select group step of a workflow.

Closed

Member list is closed. No changes are allowed. The default setting for the default_subscription policy parameter is SubscriptionPolicyClosed. This is located in

5.3.2 Defining an LDAP Target for Create Object Workflows

If you selected Create as the type of workflow you are defining, for example, Create User, you must define one or more targets. The target is the location in the directory tree where the object is to be created. For example, a target of ou=bestmotors,o=company,c=us allows objects to be created under the ou=bestmotors container. When a user is created using a workflow with this target, the directory entry might look like cn=John Smith,ou=bestmotors,o=company,c=us.

If the logged in user has an "ou" entry with multiple values, and you want to provide the ability to create the new user under any of these "ou's," you must modify the ResourceFilterSearchScope parameter value to 2 in globalparams.xml. See the Oracle Access Manager Customization Guide for details. In this case, a list of all the possible targets is shown when the workflow is run. The user can then select the precise "ou" under which the new target user is to be created. The targets in the list are obtained from the multiple values of the "ou" attribute of the logged in user. You can restrict this list can be by having other filter components along with (ou=$ou$), such as (objectclass=organizationalUnit).

If you define more than one target, the participant is presented with a selection list when the workflow is run. Workflow targets are always based on the LDAP directory tree. Targets cannot be based on a template schema.

The targets page appears, displaying fields for selecting characteristics of the target.

To define a new target, enter a name in the Target Name field.

For example, if you are creating a target for a dealership, the target name might be Dealer Name.

In the Target Domain field, select the location in the directory tree where the object is to be created and click Add to add the target domain to the Target(s) field.

When you defined the workflow domain, you selected a branch of the directory tree that the workflow applies to. The target domain is a subset of the main workflow domain. You can use a filter to more closely specify the location for the target (any user object in the tree under the node you select).

Note:

Do not use full LDAP URL while specifying the target domain (or workflow domain) while creating the workflow. Only the LDAP filter is expected. For example, cn=Shutterbug Canavan is expected rather than ldap:///ou=Partners,o=Company,c=US??sub?(cn=Shutterbug Canavan).

If you added a filter for the workflow domain, you cannot specify a filter for the target.

Click Add.

To apply the workflow to additional targets:

Click New.

Supply another name and domain.

Click Add.

When you are done supplying target domains, click Next.

5.3.3 Defining the First Step in a Workflow

After naming the workflow and defining a target, if required, you are prompted to create the first workflow step. The page that appears is similar to the following.

Note:

On the step definition page, not all tabs may be available. This is because some tabs are not applicable at a particular time. For example, in the default Create User workflow, the Out of Office tab is not available during the Initiate step, when Out of Office notifications are not needed, and during the Enable step, which is performed automatically and does not involve any participants. See also "Descriptions of Step Actions" for information on UseDefaultOptionsForAllMails.

For a Create Object workflow for the User or Organization Manager, the Initiate and Self Registration actions are available.

For a Create Object workflow for the Group Manager, the Initiate action is available.

Click Participants.

Most steps require participants to perform an action. The exceptions to this are steps with actions that occur automatically such as Commit and Enable, in addition to External Action and the Self Registration action.

Note that for steps that do not require participants, the Out of Office tab is not available.

Use any of the following methods to specify participants.

Roles: Note that the role of Anyone refers to any user who is logged in to the Identity System.

If you chose Select Participants to Prenotify in the Select Participants field, do not choose Next Step Participants as the role. Also note that in the commit step for a Group Manager workflow, you should not check owner or member for post notification. There are no email notifications for owner or member even if they are selected. See also "Descriptions of Step Actions" for information on UseDefaultOptionsForAllMails.

Participant roles (roles for people who can process a step) work only after a commit, enable, or activate step has been completed. The commit, enable, or activate step creates the object's DN from which notification information can be determined.

Click Save Step or Save Workflow, or select step attributes as described in the following paragraphs.

5.3.4 Defining Step Attributes

Step actions are performed on one or more attribute values. When you configure a step action, you indicate if certain attribute values are required, and other configuration options. For example, on a Provide Information action, you can specify the mail attribute to ensure that the step participant is prompted to supply an email address.

Defining step attributes consists of the following:

Selecting the attributes that should be available in this step of the workflow.

Configuring attribute properties.

For attributes based on an object template (.tpl file), when you configure the attribute in the Identity System Console, it might be helpful to indicate the type of schema that the attribute belongs to. For example, for a workflow that sends information to an application that can set up email accounts for new users, you might want to preface the attribute label with the application name. This is helpful when users view this attribute. Since the flow of data is one-way for provisioned attributes, the attribute values are not displayed on the Identity System profile page once the user submits the value. If your users have a question about this, the attribute label helps you determine if this is the expected behavior. See "Configuring Attributes" for details.

From the Available Attributes panel, select one or more attributes to associate with the workflow step.

For a Change Attribute workflow, be sure that the topmost selected attribute has already been added to a panel on a profile page. This ensures that a "Request to Modify" button appears on the appropriate profile page, enabling users to run instances of this workflow.

Required: The workflow participant must provide a value for this attribute.

Note:

A required attribute cannot be hidden or read-only.

Optional: The workflow participant can provide a value for this attribute.

Read-only: The workflow participant can see but cannot modify the attribute.

Hidden: The workflow participant cannot view this attribute value. The attribute is available in the Identity Event Plug-In API and IdentityXML.

Default value: Displays a text string. This text string should helpful information for the participant. For example, a string showing the correct format for entering a phone number could be the default value for the phoneNumber attribute. The value is limited to text display types.

Click OK.

Click Save Step or Save Workflow.

You can now define Mail Notification participants, or you can define additional steps for this workflow.

Note:

When you define Mail Notification participants, if you chose Select Participants to Prenotify in the Select Participants field, do not choose Next Step Participants as the role. Also note that in the Commit step for a Group Manager workflow, you should not check Owner or Member for post notification. There are no email notifications for owner or member even if they are selected. See also "Descriptions of Step Actions" for information on UseDefaultOptionsForAllMails.

A commit, enable, or activate step must be completed for a role selected for pre or post notification to work. Before the commit, enable, or activate step is completed, the object exists only in the workflow instance information in the directory tree. The commit, enable, or activate step creates the object's DN from which notification information can be determined.

5.3.5 Defining Subsequent Steps

A workflow consists of at least an initiating step and a completion step, and may have more steps and subflows. As part of the procedure for creating a second (or third, or more) step in a workflow, you define entry conditions for the step. Entry conditions consist of:

New fields appear on this page appropriate for configuring subsequent steps in a workflow.

From the Previous Step list, select the step that should precede this action.

From the Return Value list, indicate whether the previous step should return a value of True or False in order for this action to execute.

You want the previous step to return a value of True if it completes successfully. Select False to generate an error report when a previous step returns a value of false. Situations that return a value of false include:

A participant rejects a workflow ticket

The commit step fails

The Identity Event Plug-in API or IdentityXML forces a return value of false.

Select Wait for Subflows to delay execution of this action until all subflows from preceding steps are complete regardless of their return value.

Selecting this check box appends the return value entry condition with :true. If you do not select the checkbox, the return value entry condition is appended with :false. See "Defining a Subflow" for details.

Click Add to add the entry conditions to the workflow definition.

The entry conditions appears in the Selected Value field:

The first entry in this field is a number that corresponds to the number for the step that precedes the current one.

The second entry in this field is a value of True or False. This entry indicates whether the current step should be run (True) if the previous step completes successfully.

The last entry in this field is also a value of True or False. This entry indicates whether or not to wait for subflows to complete before running this step. True means wait for subflows to complete.

In the Action list, select the action. You can choose enable, activate, and other actions.

The available actions depend on the action in the previous step. Examples:

Provide Information cannot precede Initiate.

An error report action usually provides a reason for a step failure. For example, rejection of an attribute value or denying a user activation request.

Usually a condition of false is the entry condition for an error report step. For example, if a participant in the step before the error report step rejects an activation operation, the workflow may proceed to an error report step.

Note:

For workflows used for provisioning, you should have at least two commit actions defined for each workflow, one to commit (or enable, or activate, and so on) the data in LDAP, the other to write the provisioning data.

Note: Create user workflows must end with the Enable step or you cannot find users that are added with this workflow.

5.3.6 Committing Workflow Steps

The last step of a workflow commits the data to a particular schema domain. By default, the schema domain is the LDAP directory that the Identity System communicates with. However, if you have configured template attributes in a workflow, you must configure a separate step to commit the data to the schema domain for the template attributes.

Commit steps for attributes in template schema domains can be processed by the Identity Event API and passed to back-end systems for provisioning.

5.3.7 Enabling a Workflow

After you create a workflow, by default it is disabled. When you are ready to allow other participants in the Identity System or external applications, you enable it.

To enable a workflow

Access the User, Group, or Organization Manager.

Click Configuration, then click Workflow Definition.

From the workflows menu, select the workflow.

Click Enable.

Note: if you receive a message that attributes are missing, examine the workflow steps. You must configure participants and attributes at each step.

5.3.8 Testing a Workflow

You must enable the workflow before you can test it. See "Enabling a Workflow" for details. You must also be a workflow participant to be able to test it.

To test a workflow

From the Identity System Console, select the application in which this workflow can be run.

For example, for a Create User workflow, you would open the User Manager.

Initiate the workflow.

For example, if you defined a Create User workflow, the workflow that you want to test should appear in a list on the Create User page. To initiate the workflow, you select from the list.

For Change User workflow, you would select the Request to Modify function in the User Manager, and so on.

Perform the functions indicated in the workflow steps.

The workflow should behave as expected. For example, after completing the Create User workflow, you should be able to find the user that was added during the Create User operation.

To run a workflow in the Group Manager

From the Identity System Console, select Group Manager.

Select the group type panel corresponding to the group type in the workflow definition.

5.3.9 Example of Defining a Workflow

The following is an example of defining a Create User workflow. In this example, you define a workflow that allows anyone who is logged in to the Identity System to create a user. This workflow generates a ticket requesting a name and email address to be provided for this user. When processed, the new user is enabled in the Identity System.

To create this workflow

From the User Manager, Click Configuration, then click Workflow Definition to go to the Workflow Definition page.

Click New.

Name this workflow Test New User Creation Workflow.

In the Workflow Type field, select Create User.

On the Target DN page, enter a name in the Target Name field and accept the default domain by clicking Add.

Click Next to proceed from the Target Domain page to the Workflow Definition Page.

Create an Initiate step for the workflow.

Click the Participants tab and define the participants to be the role of Anyone.

Click the Attributes tab and select the attributes that you want workflow participants to provide, for example, First Name and Last Name.

Click New to create a new step with the Enable action type.

Click Add to add the Initiate step as an entry condition for the Enable step.

Click Participants and select Anyone as a participant.

Click Attributes and add an attribute that is presented during this step.

Save and enable the workflow.

Test the workflow by trying to create a new user in the User Manager.

5.4 Defining a Subflow

Only the Change Attribute workflow type can be a subflow. These workflows must also be explicitly configured as subflows in the workflow definition page. All subflows must also contain an approval step action.

Note:

You must select Use as Subflow on the first page of the workflow definition for a workflow to be usable as a subflow.

To create a subflow

From the Identity System Console, click the User Manager, Group Manager, or Org. Manager application tab.

Click Configuration.

Click Workflow Definition.

Click New.

In the Workflow Name field, enter a name for your workflow.

Click the Use as Subflow checkbox.

From the Workflow Type list, select Change Attribute.

Click Next.

In the first step of the workflow, specify the attribute that the workflow is to change.

Complete the rest of the workflow as you would any other workflow.

Note:

All subflow definitions must contain an approval step action.

5.4.1 Associating a Subflow with a Workflow

You must associate a subflow with a specific workflow step in the main workflow. During workflow run time, any subflows configured for a specific step are invoked after the step action has executed.

In the Defined Steps area of the page, select the place in the workflow sequence where you want to insert a subflow.

In the Select Subflows area of the Subflows tab, select the subflow that you want to be a part of this workflow.

Select the subflow(s) you want to assign to this step and click the right arrow button (>>).

Note:

If you do not see your subflow here, verify that it is marked as a subflow, and it is enabled. The attribute that is the target of the subflow cannot also be used in the workflow to which the subflow is assigned.

Save the step.

On the subsequent step(s), you can optionally indicate whether or not you want to wait for subflows to complete.

Select the step that should be delayed until the subflow is complete and click Modify.

Click the Wait for Subflows checkbox.

5.4.2 Approving Subflow Steps

The Subflow Approval step reports on the current status of subflows triggered from the main flow. By default, the status is set to Approved or Rejected during either an Approval step or a Provide Approval step. This step also allows for the configuration of attributes.

5.5 Advanced Workflow Ticket Routing

Ordinarily, the static participants you specify when you create a workflow step are the users responsible for completing that step. To avoid processing bottlenecks or to ensure that each ticket reaches the participant most appropriate to process it, the following three advanced ticket routing features enable the replacement of static participants under specific circumstances:

Instead of specifying static participants when you create a workflow, you can have a workflow plug-in or application choose dynamic participants according to run-time conditions.

If a static or dynamic participant is going to be out of the office or otherwise unable to process workflow tickets, he or she can set an Out of Office flag in his or her user profile so that all incoming tickets are redirected to a surrogate participant for as long as the flag remains activated.

If the participants receiving a given workflow ticket fail to process it within a specified interval, that ticket can be sent to an escalation participant, who assumes full responsibility for the ticket.

5.5.1 Configuring Workflow Actions for Advanced Ticket Routing

Not all workflow steps can be configured for advanced ticket routing. For instance, the first step in a workflow can never be rerouted. Fortunately, it is never necessary to reroute the first step, because the person who initiates the workflow is also the participant for the first step, which is always workflow initiation.

Steps that do not involve user action cannot be rerouted since, by definition, they do not involve user participants. For instance, a step involving the automatic retrieval of provisioning data from an external database involves no human participants, and therefore, participant replacement is moot.

The following table lists the user actions that can be associated with workflow steps:

Table 5-9 User Actions Available for Advanced Ticket Routing

User Action

Availability

Approval

Available by default for dynamic participants, surrogates, and time-based escalation

Provide information with approval

Initiate

Available by default for dynamic participants and surrogates; can be enabled for time-based escalation by modifying the appropriate workflow parameter file. For details, see "To modify the workflow parameter files".

Self registration

Provide information

Subflow approval

Activate

Deactivate

Error report

Select groups

Requests

Change information

Change information with approval

5.5.2 About Notifying Newly Assigned Step Participants

The Mail Notification tab in the workflow applet enables you to configure email notification for participants who are assigned tasks to complete when workflow tickets are rerouted. You can configure mail notification for each step to which ticket rerouting can apply.

To configure mail notification for any step involving advanced ticket rerouting, complete the following procedure:

5.5.3 Specifying Dynamic Participants

The dynamic participants feature is one of the advanced workflow options that enable the automatic routing of workflow tickets to alternate participants, as determined by circumstances at run time.

5.5.3.1 About Workflow Participants

the Identity System supports the following two types of workflow participants:

Static participants are specified through the workflow applet, usually when you define a workflow step. For example, when you create a workflow to set up network accounts for new employees, you can include an approval step that routes all incoming tickets to the network security manager. Unless you later add a workflow plug-in or application, this pre-designated static participant serves as the primary recipient for all tickets generated by this workflow step.

Dynamic participants must be specified in a workflow plug-in or application, rather than through the workflow applet. These conditional participants are selected based on run-time attribute values or external business logic. For example, your plug-in can specify that all purchase requests greater than $2,500 go to the accounting manager, all requests smaller than $50 go to the petty cash clerk, and all other requests go to any available staff accountant.

5.5.3.2 About Workflow Ticket Routing

As the following graphic illustrates, when a workflow is run and program execution reaches a step that has been enabled for dynamic participants, a workflow plug-in or application selects a set of dynamic participants and sends them a workflow ticket. In cases where the plug-in or application does not select any dynamic participants, the calling application sends the ticket to the original static participants, just as if the workflow plug-in or application had never intervened.

You can define dynamic participants for every step in a workflow, except for the first step, which must be initiated by a static participant.

When step instances are assigned at run time, dynamic participants inherit the same ticket-processing rights that static participants would normally receive. These rights extend only to tickets specifically assigned to the dynamic participant. In other words, the dynamic participant does not receive all the rights assigned to the original participant, as would be the case if the Substitute Rights feature were used to create a delegate. See "Adding Substitute Administrators".

Since the identity of the dynamic participants is not known until the associated workflow step is run, they are not available for certain workflow services, such as post-action email generated by the previous workflow step. However, it is possible to notify dynamic participants through pre-action email generated by the workflow step that selects them. See the procedure "To prepare a workflow step for dynamic participants".

5.5.3.4 About Static Participants

Under normal circumstances, workflow steps use static participants, whom you designate through the workflow applet.

In cases where the oblixpppcatalog catalog file specifies a plug-in or application for a given step, the plug-in or application receives the first opportunity to select dynamic participants according to the run-time values it evaluates. Only if the plug-in or application declines to specify a set of dynamic participants does control pass back to the main application, where the static participants are specified as the primary step participants.

5.5.3.5 About the Static Participants Not Available Button

If you know in advance that a workflow plug-in or application always selects dynamic participants for a given step, you don't have to define static participants for that step. Remain aware, however, that if you do elect not to specify static participants, you must toggle the default Static Participants Available button to Static Participants Not Available. As the following graphic illustrates, these radio buttons appear on the Participants tab of the workflow applet, which is accessible through the User, Group or Organization Manager, as appropriate to the workflow you are configuring.

5.5.3.6 Enabling Dynamic Participants

The dynamic participants feature is not enabled by default. To activate this feature, you must complete the procedures listed in the following task overview:

Task overview: Assigning dynamic participants to a workflow step

Use either the QuickStart tool or the workflow applet to create a workflow containing the steps that utilize dynamic participants.

Create a pre-action plug-in or application to select dynamic participants at run time.

A typical plug-in or application might contain code sections to perform the following:

Specify at least three sets of dynamic participants, the last of which always contains NULL values only

Specify attributes or business logic to be evaluated at run time

Select dynamic participants based on the evaluation

Ensure that the selected participants actually exist in the Identity System directory; otherwise, the dynamic participant selection process can fail, but the workflow engine does not return an error message

Pass the list of dynamic participants back to the calling the Identity System application

If the preceding condition does not apply, or you previously defined static participants for this step, proceed directly to step 4.

If the current workflow step uses a plug-in or application to specify dynamic participants, and there are no conditions under which static participants can ultimately receive the workflow ticket for the current step, activate the Static Participants Not Available button, as described in "About the Static Participants Not Available Button". Otherwise, proceed directly to step 5.

If you want, set up email notification by clicking the Mail Notification tab, clicking the Select Participants to Prenotify button, then selecting Current Step Participants in the Select Role box. If they are ultimately selected, the dynamic participants receive e-mail announcing that workflow tickets have been assigned to them.

Note:

The Select Participants to Prenotify button turns on email notification for static participants when the Static Participants Available switch is active. By contrast, it sends notifications to dynamic participants when the Static Participants Not Available switch is active. See also "Descriptions of Step Actions" for information on UseDefaultOptionsForAllMails.

Commit the step-specific information by clicking Save Step and then clicking OK to dismiss the prompt that asks you to confirm the operation.

Commit the information pertaining to the entire Workflow by clicking Save Workflow and then clicking OK to dismiss the prompt seeking to confirm the operation. If an additional prompt asks whether you want to enable the workflow, click Yes.

To modify oblixpppcatalog.lst

Complete the following sub-steps to determine the workflow ID of the workflow containing the step for which you want to set dynamic participants:

Launch the User, Group, or Organization Manager, as appropriate for the workflow you want to modify.

Click the Configuration tab, then click Workflow Definitions.

Select the workflow you want to modify, then click View.

Make a note of the value reported in the Workflow Definition View for obworkflowid, which appears in a string similar to the following:

Workflow DN : obworkflowid=5985de47196a4a728a629a429b6a5194

Use any plain-text editor to open the file oblixpppcatalog.lst, which is located in the following directory:

IdentityServer_install_dir\identity\oblix\apps\common\bin

where IdentityServer_install_dir is the root installation folder for the Identity Server that runs your workflow.

Use C++ to create a plug-in or application that specifies the dynamic participants selected when program execution reaches the workflow step you specified in "To modify oblixpppcatalog.lst".

You can use various conjunctions of LDAP attributes or proprietary business logic to specify the conditions under which one group of dynamic participants is chosen over the others at run time.

Include in the plug-in or application, the following header files, which enable the pre-action processing necessary for dynamic participant selection:

obppp.h
obpppwf.h
obpppdata.h

Within the application or plug-in, define three or more sets of dynamic participants using any combination of roles, rules, persons, or groups. The final item in each array must always be NULL. For instance:

5.5.4 Specifying Surrogates

You can configure the Identity System applications so that when a static or dynamic participant is not available to perform the actions assigned for a particular workflow step, that participant can set an Out of Office flag in his or her user profile, causing incoming workflow tickets to go to one or more designated surrogate participants. The surrogate is granted whatever rights the original participant had to process the rerouted tickets.

Only tickets created after activation of the Out of Office flag are rerouted to the surrogate. The original participant retains responsibility for processing all tickets created before activation of the Out of Office flag.

When the Out of Office flag is turned on, it applies to all of the steps in all of the workflows for which the participant has been designated as a static participant or potential dynamic participant.

When the Out of Office flag is reset to Off, newly created tickets are once again routed to the original participant. The surrogate retains responsibility for processing all tickets routed to him or her while the Out of Office flag was active, but no new tickets are routed to the surrogate unless the original participant once again activates his or her Out of Office flag.

The same workflow applet setting that sends ticket assignments to original participants also notifies surrogates and others that the workflow ticket has been rerouted because of the Out of Office flag.

Task overview: Enabling surrogates

Associate the attribute of your choice with the Out of Office semantic type through the Common Configuration tab of the Identity System Console.

To associate an Out of Office attribute with the Out of Office semantic type

Choose an attribute in the LDAP directory to associate with the Out of Office semantic type.

It must be an attribute with a boolean value that indicates whether the user is in or out of the office. For convenience, Oracle supplies the attribute obOutofOfficeIndicator, but you can use any suitable attribute in your directory.

Only some attributes have this indicator. For example, for gensiteOrgPerson, the genuserid attribute have this indicator.

In the Display Type box select Boolean, then click Done to commit the change.

Note:

This procedure only needs to be performed once.

To specify a surrogate

As appropriate to the particular workflow containing the step for which you want to specify one or more surrogates, log onto the User, Group, or Organization Manager, then navigate to Configuration, then select Workflow Definitions.

Select the workflow containing the step for which you want to specify surrogates and click Modify.

Click Next once if you are modifying a Change Attribute workflow.

Click Next twice if you are modifying any other type of workflow.

Select the step for which you want to specify surrogates, then click Modify.

The page is refreshed with information about this step. If the page does not refresh, be sure that the step is highlighted. If it is not, click it again, then click Modify.

You can specify a surrogate for any workflow step associated with a user action.

Click the Out of Office tab.

Specify one or more Surrogates using any combination of the Person, Group, Role, and Rule tools.

The Select Indirect Roles box provides check boxes to select whatever roles are currently defined in your directory. These roles are considered indirect, because they apply to the current participant, rather than the workflow target.

Click Save Step to commit the changes for that step.

If you receive a warning to configure attributes, make sure that you have selected attributes for this step.

Repeat the preceding steps for each workflow step for which you want to specify a surrogate.

Click Save Workflow to save the entire workflow.

To make use of the Out of Office flag

Verify that you, as a potential static or dynamic user, have been granted sufficient privileges (search, read, and write) to perform the operations described in this procedure.

Verify that the Out of Office flag has been configured for the attribute.

Navigate to User Manager, select My Profile, then click Modify.

In the Personal Information section, toggle the Out of Office Indicator to True. (This attribute is False, by default).

Click Save to commit the change, then click OK to dismiss the pop up that seeks to confirm the operation.

5.5.5 Enabling Time-based Escalation

If the participant or participants assigned to process a workflow ticket do not do so within a specified interval, you can have the Identity System escalate the ticket by rerouting it to a different participant. The original participant can no longer process the escalated ticket: it must now be processed by the escalation participant, who receives all rights previously given to the original participant for processing the ticket.

If the escalation participant does not process the ticket within the allotted time, the ticket is escalated again, and so on, until it is escalated to the Identity System administrator, who is the last possible participant to be assigned responsibility for the escalated ticket.

By default, you can enable time-based escalation on any workflow step, provided the following two conditions hold true:

The escalated step is not the initial step in the workflow

The action associated with the step has been enabled for escalation. By default, only Approval and Provide Information and Approval are enabled for escalation, but you can enable other actions by adding lines to the appropriate workflow parameter file. See the procedure "To modify the workflow parameter files" for details.

To enable time-based escalation

As appropriate to the particular workflow for which you want to set up time-based escalation, log onto the User, Group, or Organization Manager, then navigate to Configuration, then click Workflow Definitions.

Select the workflow for which you want to set up escalation and click Modify.

If a pop up appears to warn you that only certain settings can be modified while pending tickets exist for the workflow, dismiss it by clicking OK. If you modifying a Change Attribute workflow, click Next once; if you are modifying any other type of workflow, click Next twice.

Highlight the step for which you want to enable escalation, then click Modify.

The page is refreshed with information about this step. If the page does not refresh, be sure that the step is highlighted. If it is not, click it again, then click Modify.

The step you select must be associated with an action that is enabled for escalation. By default Approval and Provide Information and Approval are enabled. To enable additional actions to support time-based escalation, see the procedure "To modify the workflow parameter files" for details.

Click the Escalation tab.

Specify the interval after which the ticket is to be escalated. You can set the interval in days, minutes, or hours. This interval applies to all escalation levels.

Specify the participant or participants to whom the ticket is to be escalated. Roles are indirect in the sense that they are evaluated not with respect to the workflow target, but with respect to the participant who did not process the ticket in time to prevent the most recent escalation. For instance, if Manager is checked in the Select Indirect Roles box, and the accountant who initially receives the ticket does not process it quickly enough, the ticket is escalated to that accountant's manager (and not the manager of the workflow target).

Specify the number of times (levels) a ticket can be escalated. This does not include the final escalation level, which always routes the ticket to the Identity System administrator.

You can only specify one set of escalation participants. This single set applies to all escalation levels. If you specify a unique user, for example, the ticket is escalated to that person each time escalation is triggered. If that escalation participant does not process the ticket at any level, the ticket is ultimately escalated to the Identity System Manager.

If, on the other hand, you specify a role that is held by a different person at each level, the ticket will be escalated to a different person at each level. For instance, if you specify Manager, the ticket will be escalated to the manager of the person to whom the ticket was originally issued, then to the manager of that manager, and then to that manager's manager, and so on.

Click Save Step to commit the setting you have entered on the escalation tab.

Specify the people to be notified about the escalation by clicking the Mail Notification tab.

Click Select escalation notifees

Select the people to be notified by Person, Group, Role, or Rule. The available roles are the following:

Previous step owners: This is the participant who completed the previous step.

Current step participants: These are the people currently assigned to process the just-escalated ticket.

Next step participants: These are the people to be assigned to process the next step. Only the static participants defined for the next step can be notified, since the email notifications are sent before the execution flow reaches the next step, and the identity of the dynamic participants is determined.

Complete this procedure only to enable time-based escalation for a user action other than Approval or Provide Information and Approval. For a list of the user actions that can be enabled for time-based escalation, see Table 5-9.

Using any plain text editor, launch the workflow parameter file appropriate to the workflow containing the actions for which you are enabling time-based escalation.

Table 5-10 lists the workflow parameter files that apply to workflows associated with the various Identity System applications:

where actionName is the name of the action for which you want to enable time-based escalation. For a list of actions that can be enabled to support time-based escalation, see Table 5-9.

Add the following string in the position indicated by the preceding listing:

<NameValPair ParamName="time_based_escalation" Value="true"/>

Repeat the preceding steps for all the user actions you want to support time-based escalation.

Save and exit, the file.

5.6 Performing Asynchronous Operations

An asynchronous workflow moves from step to step without completing pending subflows. An asynchronous operation is pre and post processing code that is part of an Identity Event, as described in the Oracle Access Manager Developer Guide. The asynch_user parameter determines who may resume the pending asynchronous action. The default is Anyone.

To allow a user to perform an asynchronous operation

Open the asynchparams.xml file in:

IdentityServer_install_dir/oblix/apps/asynch/bin/asynchparams.xml

where IdentityServer_install_dir is the directory where you installed the Identity Server.

Set the async_user parameter to one of the following:

Anyone: Anyone can perform asynchronous operations (default).

DN: A particular user can perform asynchronous operations. Provide the DN of a user.

Only one DN can be accepted by the parameter.

Close the asynchparams.xml file.

5.6.1 Notes on Asynchronous Workflows

The User, Group, and Organization Managers are not automatically loaded when an asynchronous workflow is resumed. If there is a request to the Identity Server to resume an asynchronous workflow when the application is not loaded, the workflow engine might not register error conditions.

For example, suppose you create a Deactivate User workflow in the User Manger. This workflow only has Initiate and Disable steps. Suppose also that you create an event plug-in for the workflow that returns STATUS_PPP_WF_ASYNC code to make the workflow instance become asynchronous during the Initiate step, pending a command to instruct the workflow to resume and run the Disable step. If there is an IdentityXML request to resume this workflow while the Identity System is being restarted, the workflow engine would mistakenly return success. The Disable step would return with a status of complete when in fact the user was not disabled.

Note:

Be sure the User Manager, Group Manager, and Organization Managers are pre-loaded when the Identity Server is restarted.

To preload the User, Group, and Organization Managers

Open the Identity System parameter file:

Identity_install_dir/identity/oblix/engine/obengineparams.xml

In this file, find the configuration information for the Identity System applications:

<ValNameList ListName="groupservcenter">

<ValNameList ListName="userservcenter">

<ValNameList ListName="objservcenter">

Change the Dll_Load parameter from 0 to 1 as in following example for Group Manager.

5.7 Using a Workflow

Once a workflow has been defined, users can invoke the workflow from the associated function in the User Manager, Group Manager, or Organization Manager. Participants in steps other than the Initiate step of the workflow can find and process tickets. Users can delete workflow requests, archive requests, and monitor the progress of a workflow.

Note that to be able to perform the actions specified in the workflow definition, participants in a workflow must be granted permission to view and modify the attributes affected by the workflow. See "Allowing Users to View and Change LDAP Data".

5.7.1 Invoking a Workflow

Once a workflow is defined, it becomes a piece of embedded functionality in the User, Group, or Organization Manager. The workflow can be invoked by any user who has been defined as a participant in the Initiate step for this workflow. For example, suppose you define a Create User workflow. Users who are in the domain specified for the workflow can invoke this workflow from the Create User function in the User manager. If multiple workflows have been defined for a create operation, you see a list on the create page for that object.

Users can also initiate a Change Attribute workflow. Change attribute workflows are available on profile pages that the user is permitted to access. For example, suppose a workflow has been defined for the manager attribute displayed on a profile page. When users change departments, they might need to issue a request to change the name of their manager. This request can be handled by a Change Attribute workflow.

To invoke a change attribute workflow

From the User Manager, click My Identity, then click Modify.

Your User Profile page is displayed using editable fields for all attributes that you can change.

For attributes on your profile page that have the Request to Remove or Request to Modify buttons, you can request to remove or change that attribute value.

These buttons are displayed when a Change Attribute workflow or subflow with a Request to Remove or Request to Modify action has been created.

Your request is sent in the form of a ticket. The person who processes this ticket might approve or reject the request. See "Finding and Processing a Ticket" for details.

5.7.2 Finding and Processing a Ticket

Once a workflow has been initiated, subsequent steps are generated by processing a ticket. You can find pending workflow tickets in the User Manager, Group Manager, and Organization Manager.

To find a workflow ticket

From the User Manager, Group Manager, or Organization Manager, click Requests.

From the Requests page, click either Incoming Requests, Outgoing Requests, or Monitor Requests.

Note that outgoing requests are tickets that have already been processed.

In the Search list, select the application for which you want to view requests.

Specify a number of days in the text field, or leave this field blank to view all requests.

Click Go.

A list of workflow tickets is displayed. The list matches your search criteria.

To process a ticket

From the User Manager, Group Manager, or Organization Manager, click Requests.

From the Requests page, click Incoming Requests.

In the Search list, select the application for which you want to view requests.

Specify a number of days in the text field, or leave this field blank to view all requests.

Click Go.

A list of workflow tickets is displayed. The list matches your search criteria.

Click a link for an incoming request.

On the details page for the request, click the Process button.

If you are a participant for this workflow, a page is displayed showing the attributes configured for this step of the workflow.

Supply any required attributes for this workflow.

For example, a Create User step may prompt you to supply an email address for the new user. Any information you must supply on this page is determined by how this step of the workflow was configured.

Click the appropriate button for completing this step of the workflow.

For example, on a Create User request, the detail page for this ticket may contain Approve and Reject buttons.

5.7.3 Deactivating and Reactivating Users

Once a user has been enabled in the Identity System, they can be deactivated and reactivated. Deactivation makes a user unable to log in and unavailable for viewing in the Identity System. It takes effect once the user logs out of the current session. An administrator with Monitor Requests privilege can view deactivated users and either permanently delete them or reactivate them.

Note:

All configured directories are searched to remove references to the Deactivated/Deleted user, including groups to which the user belongs. When you have stored user data and configuration data separately, both directories are searched concurrently.

The steps for defining a workflow for deactivating a user are provided in "Using the Workflow Applet". Once the workflow has been defined, users with sufficient privileges can see an Initiate User Deactivation button on a user's profile page.

The steps for deactivating the user conform to the actions you specified on the user deactivation workflow.

5.7.4 Reactivating a Deactivated User

At times you might want to reactivate a deactivated user. For example, you might want to deactivate an employee during a leave of absence, and reactivate the employee when he or she returns to work.

To reactivate a deactivated user

Define a Reactivate User workflow for this purpose.

For a summary of actions permitted on a reactivation workflow, see "Workflow Types, Steps, and Actions". Once the workflow has been defined, users with sufficient privileges can see an Initiate User Reactivation button on a deactivated user's profile page.

For subflows, if the first step has not been processed, the Date Processed field is empty.

In the Search fields, select your search criteria and click Go.

The results appear after the search fields.

Click Next or Previous as necessary to see other results.

Click a ticket's Request Number to open the Request page for that ticket.

This page lists the workflow's current step number.

To delete an incomplete workflow that is not responding, use the Monitor Requests function to locate the workflow and then click the Terminate button. To terminate a completed workflow, use the Delete button in the Monitor Workflow functionality.

5.7.6 Archiving Requests

Archiving the workflows enables you to keep a record of participants and times but remove a large amount of data from the directory. You might want to archive workflows periodically to prevent the Oblix tree from becoming too large. You can archive only completed workflows. Multiple archive operations add information to this file.

Archived workflows are stored in LDIF format. The default location for storing the archive data is the following:

Identity_Server_install_dir/oblix/data/common/wfinstance.ldif

You might want to change the default location to prevent the archived data from being overwritten during an upgrade. The following files control the archive file location:

Filename

Application

usc_wf_params.xml

User Manager

gsc_wf_params.xml

Group Manager

osc_wf_params.xml

Org. Manager

Oracle recommends that you only archive a maximum of a few hundred workflow instances at a time. If you select a large number of instances, it can take several seconds and consume server resources during the archive operation.

5.7.7 Deleting Requests

When the delete confirmation page appears, click Back to return to the previous page.

5.7.8 Preventing Other Administrators from Working on a Workflow Ticket

At run time, multiple users can receive a workflow ticket. For example, suppose an IT group receives a ticket for a Create Workflow request. An administrator who processes this request can lock the ticket so that other users can view the information on the locked ticket but they cannot work on the ticket. Only the person who locked the Ticket, the Master Identity Administrator, and people who have been granted permission to Monitor Requests can unlock the ticket.

The Lock and Unlock buttons are displayed on the workflow page when you process the workflow ticket.

Select Lock or Unlock, as appropriate.

5.8 Managing Workflows

Once you have defined workflows, you can view, copy, modify, delete, and export them.

5.8.1 Viewing and Exporting a Workflow Summary

You can view a summary of a workflow, including its steps, participants, and so on, and export this report to a comma-delimited value (CSV) file.

Note:

The following is of interest if you use Microsoft Internet Explorer and you are protecting the Identity System interface (WebPass) with a WebGate. To enable the Export to CSV feature, you must configure the following two WebGate parameters as follows:

Enlarge the Workflow Definition View page or scroll to the right to see all of the workflow contents.

Click Export to CSV to save a comma-delimited value file of your workflow.

Click Close to close the page.

A sample CSV file, when opened in a spreadsheet, might appear as follows:

5.8.2 Copying a Workflow

You can use a copy of a workflow as a starting point for a new workflow. You can also copy a workflow if you would like to modify a workflow that has too many pending tickets for the modify function to be practical.

To copy a workflow as a starting point for a new workflow

Access the User, Group, or Organization Manager.

Click Configuration and click Workflow Definition.

From the Workflows menu, select the workflow you want to copy.

Click Copy.

A copy of the workflow appears in the list.

It is named Copy of original name. Oracle recommends renaming the copied workflow, although you are not required to do so.

Change information as necessary to create a new workflow.

To copy a workflow as an alternative to modifying it

Copy the workflow, as described in the previous procedure.

If the workflow has external actions, update the oblixpppcatalog catalog file to reference the new workflow.

If you intend the workflow to only be invoked from the Identity System, you are done.

If the workflow is embedded as a portal insert an another application Web page, update the link for the workflow to point to the new workflow ID.

5.8.3 Modifying a Workflow

After creating a workflow, you can change its parameters. If the selected workflow has pending instances, you can only modify the list of Targets, the Participants for any step, or the Pre/Post Notification recipients for any step.

Note:

Since only certain parts of a workflow can be modified when there are pending tickets, on a very active system you might need to copy the workflow and make changes to it. See "Copying a Workflow" for details.

To modify a workflow

Access the User, Group, or Organization Manager.

Click Configuration and click Workflow Definition.

From the Workflows menu, select the workflow you want to modify.

Click Modify.

The selected workflow information appears. Clicking Modify disables this workflow so that it cannot be used while being modified.

Change the workflow settings as necessary.

Click Save Workflow to save your changes.

Click Yes when prompted to enable the workflow.

5.8.4 Deleting a Workflow

You can delete a workflow unless the workflow has pending requests.

To delete a workflow

Access the User, Group, or Organization Manager.

Click Configuration and click Workflow Definition.

From the Workflows menu, select the workflow you want to delete.

Click Delete.

Click OK at the confirmation message.

5.8.5 Exporting Workflows

You can export all workflows to a comma-delimited value (CSV) file. This is a text file that can be printed.

Note:

The following is of interest if you use Microsoft Internet Explorer and you are protecting the Identity System interface (WebPass) with a WebGate. To enable the Export to CSV feature, you must configure the following two WebGate parameters as follows:

Click Export All to be prompted to save a comma-delimited value file that includes all of your workflows.

5.8.6 Viewing Workflow Panel Settings

As described in "About User, Group, and Organization Manager", you configure what appears in the User, Group, and Organization Manager applications. The User and Group Manager applications consist of one tab and the Organization Manager consists of one or more tabs. Tabs are a collection of profile pages, which themselves are collections of panels. Panels are groups of attributes and values.

You can view and modify the workflow panels that appear on the profile pages for these applications.

To view current workflow panel settings

From the Identity System Console, click Common Configuration.

The Common Configuration page appears.

Click Workflow Panels.

The Workflow Panels page displays configured workflow panels.

The following table describes each panel.

Panel

Description

Workflow monitor table

The columns included in the results page when a user performs a workflow search from the Monitor Requests page.

Workflow profile panel

The information displayed about a workflow instance in the Monitor Requests page.

Workflow steps profile panel

The information displayed about a workflow instance's steps in the Monitor Request page.

Ticket information panel

The information displayed in the Ticket Information page from the Incoming Requests or Outgoing Requests page.

Ticket search table

The information displayed in the results page when a user performs a workflow search from the Incoming Requests or Outgoing Requests page.

Click the panel you want to view.

The View Panel page displays the items that are displayed on the panel.

The details of the workflow panel such as the panel name, description, and attributes are displayed on the page.

Click Translate.

Note:

The Translate button appears only if more than one language pack is installed.

The Summary of Panel Display Names page appears. The language-specific display name for the panel fields and attributes are displayed. Fields that has not been translated for a language are marked as Not Configured.

To configure language-specific workflow panel information

In the Summary of Panel Display Names page, click Modify

The Configure Panel Display Names page appears. This page contains panel information and links for the languages that you have installed

Click the language for which you want to configure the workflow panel.

5.8.9 Workflow Performance

Access to the directory server access can be reduced by setting the WfInstanceNotRequired flag to true in the oblix/data/common/workflowdbparams.xml file. This flag indicates that no workflow instances should be written to the directory server unless necessary. It is set to false by default, which means workflow instances are written to the directory server.

5.8.10 The Identity Administrator's Modify Rights

By default, an Identity Administrator bypasses attribute access controls. As a result, if you define a Change Attribute workflow, the attribute access controls in this workflow are not checked for Identity Administrators. These administrators automatically have modify rights where other users have only the right to request to modify an attribute.

The parameter to control this feature is BypassAccessControlForDirAdmin, located in IdentityServer_install_dir/identity/oblix/apps/common/bin/globalparams.xml. If you want to not automatically provide modify rights to the Directory Administrator, set this flag to false and restart the Identity Server.

You can give the Identity Administrator the right to modify an attribute and request to modify an attribute in a Change Attribute workflow. In each application parameter file, for instance, IdentityServer_install_dir/identity/oblix/apps/userservcenter/bin/userservcenter.xml, you can set the parameter checkChangeAttributeEvenAllowModify to true. This setting provides that even if the administrator is allowed to modify an attribute, this person can see both input and workflow buttons. This parameter applies to administrators who have both modify and initiate workflow rights. Note that this feature can introduce performance overhead.

5.9 Advanced Workflow Options

The following advanced options are available:

Attaching custom code to workflow actions

Configuring the behavior of workflow actions

5.9.1 Pre and Post Actions

You can use the Identity Event Plug-in API to attach custom code to workflow actions. Common scenarios for using the Identity Event Plug-in API with workflows include:

Automatically generating a value (such as a unique ID) from an external system

Validating data for a workflow step

Updating data in an external system

Once you write custom code, you must tell the Identity System to execute it either before the workflow action (pre action), or after the workflow action (post action) in the oblixpppcatalog file.

5.9.3 Customization of Data and Actions in a Workflow

The User, Group, and Organization Manager each have a workflow parameter file that controls the data displayed to participants and the actions that can be selected.

Each parameter file has three sections:

Create Object

Delete Object

Change Attribute

The files are located in

IdentityServer_install_dir/identity/oblix/apps/applicationname/bin/

where IdentityServer_install_dir is the Identity Server installation directory and applicationname is one of the following:

usc_wf_params.xml: User Manager

gsc_wf_params.xml: Group Manager

osc_wf_params.xml: Org Manager

The following table describes each parameter:

Parameter

Description

Sample Setting

occurrence

Indicates how many times this action may be used within a workflow.

[1] [n]

1: action can be used once.

n: Action can be used multiple times.

useraction

Indicates whether or not the step is interactive.

[true] [false]

true: Action requires user interaction.

false: This is a background step and requires no user interaction.

forceCommit

Indicates whether an implicit commit takes place for this step, even though this action is not a commit. An implicit commit writes all collected data to the specific target entry

[true][false]

true: Implicit commit takes place.

false—Implicit commit does not take place.

pre_action

Indicates that the current action can be specified if the previous step's action is in this list.

[list of actions]

exit_condition

Indicates the possible results for the given action.

[list of exit conditions]

For example:

true: 1

false: 0

relevant_data

Indicates which types of relevant data can be configured for this step. Background steps do not contains any relevant data.

[list of relevant data]

Can be any combination of Required, Provisioned or Optional.

initialStep

A parameter you can apply to an initiate, self registration, or approval step.

Values are true and false.

5.9.4 Adding Roles to a Workflow

By default, only the role of Anyone is available in a workflow definition applet. To add the roles that have been defined in the directory to the workflow definition applet, you can modify the workflow parameter files for the User Manager, Group Manager, and Organization manager.

The following procedures cause all DN roles to show up in the workflow applet.

The attribute displays as a role in the workflow applet, provided all roles are enabled as described in the following procedure.

Click Save.

To add roles to a workflow definition applet

Edit the WF parameter file in the following location:

User Manager: Open usc_wf_params.xml.

Group Manager: Open gsc_wf_params.xml.

Organization Manager: Open osc_wf_params.xml.

Go to the section <CompoundList ListName="Roles">

Find the appropriate Workflow Type.

For example, to modify a create object workflow, you would need to find <CompoundList ListName="CREATE_OBJECT">

Find the Participant or Notifee section in this file.

For example, you could edit the section <ValNameList ListName="Participant" >

Add the following line:

<NameValPair ParamName="dns" Value="dns"/>

5.10 Creating a Self-Registration Workflow

Self-registration enables users to add themselves or their organizations to the Identity System directly from a Web page. The Identity System does not provide a user interface for self-registration. You must configure a URL that displays a registration form.

When users self-register, they might be prompted to reset their passwords after their initial login attempt. This depends on settings provided for the Change On Reset field, as described in "Configuring Password Policies". If more than one user self-registers using the same browser session and the Change On Reset option is chosen, all users after the first are prompted to change their passwords after their first login.

If you want users to be automatically logged in to the Identity System after self-registering, you must set the SelfRegGeneratesSSOCookie to true in the basedbparams.xml file. See the Oracle Access Manager Customization Guide for details.

The URL for self-registration must be to a page that does not require authentication. The self-registration URL is not the usual /identity/oblix/apps/userservcenter/bin/userservcenter.cgi. Typically, when a user accesses the Identity System, the Access System asks the user to authenticate. However, the WebGate should be set up to not request authentication for people accessing self-registration and lost password pages.

Replace reserved characters with URL-compatible text substitutes.

When providing a DN path in the dynamic expansion URL, you must encode URL-reserved characters (non-alphanumeric) with a % followed by the character's ASCII hexadecimal equivalent, as follows:

If you are using Sun's iPlanet directory, note that self-registration passwords cannot use UTF-8 characters. If the user supplies UTF-8 characters, the iPlanet directory default 7-bit plug-in fails the operation. By default the 7-bit plug-in requires the uid, mail, and userpassword attribute values to be 7-bit. To resolve this problem, turn off the plug-in or remove the userpassword attribute from the configuration. Note also that this issue applies as well to Create User and Modify Profile operations.

5.11 Creating a Location Workflow

In the Organization Manager, you can create workflows to manage business locations and allow specific users to manage those locations. You can select individual users or users who play a specific role such as Facilities Manager, or you can select specific groups such as IT Operations.

To enable users to view the location of the organization, you can attach .gif images of the location map to the workflow. When users click a location, the location profile displays a map of the area where building is located.

You can create a new location workflow and then create a location object using the new workflow. To do this, use the Create Org Profile feature in the Organization Manager. Alternatively, you can create a location object first and then link it to an existing workflow. Once you create a location object, you can assign other objects such as users to specific locations on the map.

Note:

If Location ID has the Semantic type DN Prefix it is important to note Active Directory and ADAM do not allow multi-valued RDNs (although iPlanet/SunOne do). For Active Directory and ADAM, ensure that the Attribute Value(s) selection is Single in the meta-attribute configuration.

After you have created a location object, you must enable the Location functionality and enable users with the appropriate permissions to view the user or object's location.

Task overview: Enabling Location functionality and users

Modify the Location tab for the Organization Manager, then add location attributes to the Profile pages for User Manager and the Organization Manager.