| Oracle® Access Manager Identity and Common Administration Guide 10g (10.1.4.3) Part Number E12489-01 |
|
|
View PDF |
| Oracle® Access Manager Identity and Common Administration Guide 10g (10.1.4.3) Part Number E12489-01 |
|
|
View PDF |
This chapter includes the following topics:
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.
Apply data integrity and rule checking when creating objects, deleting objects, and modifying attributes.
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.
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.
You can also copy a link to a URL for the workflow and embed it in a page from another application, and access it as a portal insert. See the Oracle Access Manager Customization Guide for details.
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.
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.
See "Specifying Dynamic Participants" for details.
You can designate surrogates to assume responsibility for a step when the primary participant assigned to that task is out of the office or otherwise unavailable to process incoming tickets.
See "Specifying Surrogates" for details.
You can configure time-based escalation so that a workflow ticket is routed to a different participant if the original participant does not complete the assigned step within a specific period.
See "Enabling Time-based Escalation" for details.
You can invoke a workflow from any Web page as a portal insert or application using IdentityXML.
See the Oracle Access Manager Developer Guide for details.
Workflow auditing enables you to monitor the state of a workflow and to determine exactly who performed particular actions at each step in the process.
See "Monitoring a Workflow" for details.
For actions that do not require human intervention, you can configure workflow steps so that the Identity System automatically obtains the required data from external sources.
See the Oracle Access Manager Developer Guide for details.
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:
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.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.
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. . . |
|---|---|
|
A Request to Modify button on a Modify Profile page for the user |
|
|
The Create User Identity page that is accessed from the Create User Identity link in the User Manager. |
|
|
An Initiate User Deactivation button on the View Profile page for the 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. |
|
|
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. |
|
|
The Create Group page that is accessed from the Create Group link in the Group Manager. |
|
|
The View Profile page for the group. |
|
|
Create page in the Organization Manager. |
|
|
View Profile page for the object. |
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.
See "Using a Workflow" for more information.
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:
Confirmation Initiate--Completed Ticket generated for next step < step action > < link >."
Ticket information appears only if the next step of the workflow must be performed by a participant (Enable is excluded).
For more information on workflow steps and actions, see "Workflow Types, Steps, and Actions".
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.
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.
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:
| Application | Workflow Type and Description |
|---|---|
|
|
|
|
|
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.
A workflow process illustration is shown in Figure 5-2.
You assign one action to each step in a workflow. Actions are performed by people or by an automated method.
For example, required actions in a workflow to create a user include:
Initiating the request.
Enabling or activating the user.
Available actions depend on the workflow type and the action defined in the previous step. For example, the Initiate action is available for only the first step of a workflow.
Table 5-3 lists the actions that you can associate with steps in User Manager workflows.
Table 5-3 Actions Permitted in User Manager Workflows
| Workflow Type | Actions |
|---|---|
|
Request (required) Provide Information Approval Provide Information and Approval Subflow Approval Commit (required) External Action Error Report |
|
|
Initiate or Self Registration (one of these two is required) Provide Information Provide Information and Approval Approval Subflow Approval Commit Enable or Activate (one of these two is required) Select Groups Delete Error Report External Action |
|
|
Initiate (required) Change Information Disable or Deactivate (one of these two is required) Approval Subflow Approval Change Approval Commit Delete Error Report External Action |
|
|
Initiate Change Information Approval Change Information and Approval Commit External Action Error Report Deactivate Disable Delete |
|
|
Initiate Provide Information Approval Provide Information and Approval Subflow Approval Commit External Action Error Report Activate Enable |
Table 5-4 lists the actions available in Group Manager workflows:
Table 5-4 Actions Permitted in Group Manager Workflows
| Workflow Type | Actions |
|---|---|
|
Request (required) Provide Information Approval Provide Information and Approval Subflow Approval External Action Commit (required) Error Report |
|
|
Initiate (required) Provide Information Provide Information and Approval Approval Commit (required) Subflow Approval Delete External Action Error Report |
|
|
Initiate (required) Change Information Change Approval Subflow Approval Approval Commit (required) Delete Error Report External Action |
Organization Manager workflow actions are described in Table 5-5:
Table 5-5 Actions in Organization Manager Workflows
| Workflow Type | Actions |
|---|---|
|
Request (required) Provide Information Approval Provide Information and Approval Subflow Approval External Action Commit (required) Error Report |
|
|
Initiate (required) Self Registration Provide Information Provide Information and Approval Approval Subflow Approval Commit Delete Error Report External Action |
|
|
Initiate (required) Change Information Approval Change Approval Subflow Approval Commit (required) Delete Error Report External Action |
Table 5-6 describes the actions available in workflows.
Table 5-6 Workflow Step Actions
| Action | Description |
|---|---|
|
Activate |
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:
IdentityServer_install_dir/apps/common/bin/globalparams.xml
<SimpleList> <NameValPair ParamName="sendMailFromName" Value="SelfRegistration"> </NameValPair> </SimpleList> <SimpleList> <NameValPair ParamName="sendMailFromEmail" Value="SelfRegistration@Oracle.com"> </NameValPair> </SimpleList>
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:
ParamName="UseDefaultOptionsForAllMails" Value="false"
the earlier behavior is followed. See the Oracle Access Manager Customization Guide.
To add the UseDefaultOptionsForAllMails parameter
Locate the Identity Server globalparams.xml file. For example:
IdentityServer_install_dir/identity/oblix/apps/common/bin/globalparams.xml
Use 10g (10.1.4.3) Behavior: Add the UseDefaultOptionsForAllMails parameter with a value of true above the sendMailNotificationEnabled parameter, if it is not there already. For example:
<SimpleList> <NameValPair ParamName="UseDefaultOptionsForAllMails" Value="true" /> </SimpleList>
Restore Earlier Behavior: Set the UseDefaultOptionsForAllMails parameter to a value of false. For example:
<SimpleList> <NameValPair ParamName="UseDefaultOptionsForAllMails" Value="false" /> </SimpleList>
Repeat for each Identity Server in the deployment.
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.
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.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".
Note:
Your ability to define a workflow depends on your administrative privileges.To define a workflow using the QuickStart tool
From the Identity System Console, select the User, Group, or Organization Manager.
Click Configuration, then click Workflow Definition.
By default, only Master Administrators, Master Identity Administrators, and Delegated Identity Administrators have permission to view configuration information.
Click the link labeled "Click here".
This launches the QuickStart tool.
Select the type of workflow you want to create.
Note:
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.
This initiates a workflow instance. For information on the process for using a workflow, see "How Users Access Workflows in an Identity System Application".
Note:
To use a workflow as a portal insert, copy the resulting URL from your browser. See the Oracle Access Manager Customization Guide for more information on creating portal inserts.Click Done.
To provide a user registration page for your Web portal, you can define a self-registration workflow and capture the resulting URL of the workflow. This URL can be used as a portal insert.
To define a self-registration workflow using the Quickstart tool
Create a self-registration workflow as described in "To define a workflow using the QuickStart tool".
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.
In addition to using the QuickStart tool, you can define workflows using configuration pages that allow you to specify multiple options and subflows.
You must have permissions to define workflows. See "About Delegating Administration" for more information.
Typically, workflows contain at least two steps: one step to initiate the workflow and another step to commit the changes.
Task overview: Defining a workflow using the workflow applet
Invoke the Workflow Definition applet.
See "To access the Workflow Definition applet" for details.
Select New to start creating a new workflow definition.
If you selected a Create workflow type, identify a workflow target.
The target is the location in the directory tree where the object is to be created. See "Defining an LDAP Target for Create Object Workflows" for details.
Define a workflow step and action.
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.
Define entry conditions for subsequent steps.
See "Defining Subsequent Steps" for details.
Define the subsequent steps.
Define one or more subflows.
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, indicate the appropriate Group Type, if applicable. The available group types depend on your configuration, as described in "Adding Auxiliary and Template Object Classes to a Group Tab".
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.
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.
See the parameter reference chapter in Oracle Access Manager Customization Guide for details.
To begin a new workflow definition
Invoke the workflow definition tool as described in "Using the Workflow Applet".
Click New and wait for all buttons except the New button to become deactivated.
In the Workflow Name field, enter a name for your workflow.
From the Workflow Type list, select the type of workflow you want to create.
For more information on workflow types, see "Workflow Types, Steps, and Actions".
If you are creating a subflow, see "Defining a Subflow".
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:
(ou=$ou$)
See "Substitution Syntax: Returning Targets that Match the DN of the Logged In User" for examples.
Note:
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 User or Organization Manager, click Next.
Depending on your workflow type, you are prompted to select a target as described in "Defining an LDAP Target for Create Object Workflows", or you are prompted to define the first step in the workflow as described in "Defining the First Step in a Workflow".
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 IdentityServer_install_dir/identity/oblix/data/common/groupdbparams.xml where IdentityServer_install_dir is the directory where you installed the Identity System. |
Click Add, then click Next.
Depending on your workflow type, you are either prompted to select a target as described in "Defining an LDAP Target for Create Object Workflows", or you are prompted to define the first step as described in "Defining the First Step in a Workflow".
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.
You can also use substitution syntax when defining the workflow target. This would ensure, for example, that in a Create User workflow the "ou" entry of the new user would always match the "ou" entry of the logged in user who initiates the workflow. See "Substitution Syntax: Returning Targets that Match the DN of the Logged In User" for examples. Note that when using substitution syntax, you might need to modify the ResourceFilterSearchScope parameter value in globalparams.xml. See the Oracle Access Manager Customization Guide for details.
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.
If you are defining another type of workflow, clicking Next on the initial workflow definition page brings you to the step definition page described in "Defining the First Step in a Workflow".
Note:
The default only displays immediate child nodes of the searchbase. See "Modifying the Default Searchbase Scope" for details.If you have not already done so, start a new workflow as described in "To begin a new workflow definition".
From the first Workflow Definition page, click Next.
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).See "Usage of Rules and Filters" for more information.
Note:
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.
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.To define the first step in a workflow
If you have not already done so, start a new workflow as described in "To begin a new workflow definition".
If you have not already done so, for a Create workflow type, define a target as described in "To define a workflow target".
From the Select action to be performed list, select an action.
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.
Roles are defined in the workflow parameter files gsc_wf_param.xml, usc_wf_param.xml, and osc_wf_param.xml. See "Customization of Data and Actions in a Workflow" for details.
Note:
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.
Select Person: See "Search Functionality" for details on using the Selector, and see "Search Filters for the Object Selector Display Type" for information on how the Selector can be configured.
Select Group: See "Search Functionality" for details on using the Selector, and see "Search Filters for the Object Selector Display Type" for information on how the Selector can be configured.
Build Filter: See "Writing LDAP Filters Using Query Builder" for information on creating an LDAP filter.
Click Save Step or Save Workflow, or select step attributes as described in the following paragraphs.
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.
To select attributes available for a step
If you have not already done so, start a new workflow as described in "To begin a new workflow definition".
If you have not already done so, for a Create workflow type, define a target as described in "To define a workflow target".
Begin defining a workflow step as described in "To define the first step in a workflow".
After selecting participants for the workflow step, click Attributes.
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.
For information on making multiple selections, see "Keys for Selecting Multiple Attributes".
Click the right arrow button (>>) to add the selected attributes to the Selected Attributes window.
By default for a Create Object workflow, the attribute that defines the Relative Distinguished Name (RDN) appears in the Selected Attributes window.
By default for a Change Attribute workflow, the attribute you selected as the basis for the workflow appears in the Selected Attributes window.
Save the step or configure attribute properties, if applicable, as described in the following paragraphs.
Note:
You cannot save a workflow until all required attributes (as defined in the object class schema) are configured for the workflow.To configure attribute properties
From the Selected Attributes window, select one or more attributes that you want to configure.
For information on making multiple selections, see "Keys for Selecting Multiple Attributes".
Click Properties.
An Attribute Properties dialog appears:
Select one or more properties for these attributes:
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.
Note:
For information on customizing email notifications, see the Oracle Access Manager Customization Guide See also "Descriptions of Step Actions" for information on UseDefaultOptionsForAllMails.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:
Identifying what step precedes this one.
Identifying the required outcome for the previous step.
To define subsequent steps in a workflow
After completing the first step in a workflow, as described in "To define the first step in a workflow", click New in the Defined Steps area.
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.As needed, add participants and configure attributes as described in "Defining the First Step in a Workflow".
Save the step or the workflow.
Note: Create user workflows must end with the Enable step or you cannot find users that are added with this workflow.
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.
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.
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.
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.
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.
For example, you may have different group type panels for the structural group object class and the oblixAdvancedGroup object class. See "Adding Auxiliary and Template Object Classes to a User or Org. Manager Tab" for details.
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.
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.
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.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.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.
To associate a subflow with a workflow
Invoke the workflow application, as described in "To access the Workflow Definition applet".
Select a workflow to which you want to assign a subflow.
Click Modify.
The page refreshes and shows the step definitions page.
Click the Subflows tab.
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.
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.
Note:
You can set the subflow status programmatically using Identity Event Plug-in API or IdentityXML. See the Oracle Access Manager Customization Guide for information on the Identity Event Plug-in API.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.
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 |
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:
To configure email notification for advanced workflow ticket rerouting
As appropriate for the workflow you are modifying, navigate to the User, Group, or Organization Manager, point to Configuration, then click Workflow Definitions.
Select the Workflow you want to modify, then click Modify.
If you are modifying a Change Attribute workflow, click Next once. For any other type of workflow, click Next twice.
Select the step for which you want to set mail notification, then click Modify.
Click the Mail Notification tab.
To enable notification for static, dynamic, and surrogate participants, click Select Participants to Prenotify or Select Participants to Postnotify.
You cannot select Participants to Prenotify for the first step of a workflow.
Specify by Person, Group, Role, or Rule, the users to notify.
You can use the Selector or the Filter Builder as the mechanism for specifying who should be notified.
Notify Escalation Participants: Click Select Escalation Notifees, then repeat step 7.
Click Save Step to commit your step-specific changes.
Click Save Workflow to save the entire workflow.
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.
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.
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 designate dynamic participants using the same criteria you use to specify static participants. This includes specification by person, by group, by role, and by rule. For details, see the procedure step "Use any of the following methods to specify participants.".
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".
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.
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.
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.
See "Using the QuickStart Tool" and "Using the Workflow Applet" for details.
If any possibility exists that a given step will use static participants, you must define static participants for that step as described in "Use any of the following methods to specify participants.".
On the other hand, if you know in advance that a given step will always use dynamic participants, you don't need to define static participants for that step. See "About the Static Participants Not Available Button" for details.
If you want, set up email notification for dynamic participants.
See "To prepare a workflow step for dynamic participants" for details.
Add a pointer to the oblixpppcatalog catalog file so that the proper plug-in or application is called at run time to select dynamic participants.
See "To modify oblixpppcatalog.lst" for details.
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
See "Task overview: Creating a plug-in or application to select dynamic participants" for details.
WARNING:
Plug-ins and applications that enable dynamic participants must be of type "pre-action." They can never be of type "post-action."
To prepare a workflow step for dynamic participants
In the User Manager, Group, Manager, or Organization Manager, navigate to Configuration, then click Workflow Definitions.
From the list marked Workflows, select the workflow containing the step being prepared for dynamic participants, then click Modify.
If any possibility exists that the current workflow step can ultimately use static participants, define static participants by Role, Rule, Persons, or Group, as described in "Use any of the following methods to specify participants.".
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.
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.
Add one of the following strings to oblixpppcatalog.lst:
obworkflowid_workflowstep_preaction;lib;; Component_install_dir\identity\oblix\path\pluginName.dll; functionName; Or obworkflowid_workflowstep_preaction;exec;; Component_install_dir\identity\oblix\path\applicationName.exe; functionName;
where:
obworkflowid is the workflow identification number you noted in step 1d of this procedure
workflowstep is the step for which you want to define dynamic participants
path is the path under Component_install_directory\identity\oblix\ leading to pluginName.dll or applicationName.exe, which are the code objects that select the dynamic participants at run time
functionName—If you specify a plug-in, you must also specify functionName, which is the function within the dynamic link library plug-in that sets the criteria for the dynamic participants.
You insert the first line of code if you are using a plug-in to specify the dynamic participants; you insert the second line if you are using an executable program, instead of a plug-in.
In any case, the line you insert must end with a semi-colon, and you can place it anywhere in the oblixpppcatalog.lst file, as long as that line does not interrupt an existing line.
The line you insert should be similar to the following:
wfqs20040901T17251953156_2_preaction;lib;;
Component_install_dir\identity\oblix
\unsupported\ppp\ppp_dll\ppp_dll.dll;
WorkflowPreActionSetDynamicParticipantsTest;
Save oblixpppcatalog.lst in its original location.
See also Oracle Access Manager Developer Guide for details about the oblixpppcatalog.lst file.
Task overview: Creating a plug-in or application to select dynamic participants
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:
To specify persons, insert lines similar to the following:
PPPSetVals[0] = "cn=Van Oman, ou=Sales, ou=Dealer1k1,
ou=Latin America, ou=Ford, o=Company,c=US";
PPPSetVals[1] = "cn=Fabien Esser, ou=Sales, ou=Dealer1k1,
ou=Latin America, ou=Ford, o=Company,c=US";
PPPSetVals[2] = NULL;
data->Set("DynamicParticipant.Persons", PPPSetVals);
To specify groups, insert lines similar to the following:
PPPSetVals[0] = "cn=Basic group1k1, ou=Groups, ou=Dealer1k1,
ou=Latin America, ou=Ford, o=Company,c=US";
PPPSetVals[1] = "cn=Basic group1k2, ou=Groups, ou=Dealer1k1,
ou=Latin America, ou=Ford, o=Company,c=US";
PPPSetVals[2] = NULL;
data->Set("DynamicParticipant.Groups", PPPSetVals);
To specify roles, insert lines similar to the following:
PPPSetVals[0] = "ob_self";
PPPSetVals[1] = "manager";
PPPSetVals[2] = NULL;
data->Set("DynamicParticipant.Roles", PPPSetVals);
Remember, of course, that only certain roles are valid for particular workflow types. See page 200.
To specify rules, insert lines similar to the following:
PPPSetVals[0] = "(cn=rohit*)";PPPSetVals[1] = "(cn=beth*)";PPPSetVals[2] = NULL;data->Set("DynamicParticipant.Rules", PPPSetVals);
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.
You only do this once. See "To associate an Out of Office attribute with the Out of Office semantic type" for details.
Specify one or more surrogates through the Out of Office tab in the workflow applet.
See "Use any of the following methods to specify participants." for details.
Individual users activate their Out of Office flags in their User Profiles.
See "To make use of the Out of Office flag" for details.
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.
Navigate to Identity System Console, select Common Configuration, select Object Class, select the person object class (for example, gensiteorgperson), then select Modify Attributes.
From the attribute list, select the attribute you want to associate.
In the Semantic Type field, select "Out of Office - Indicator."
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.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.
See "Use any of the following methods to specify participants." for details.
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.
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.
See Also:
"Descriptions of Step Actions" for information on UseDefaultOptionsForAllMails.Initiator: This is the user who initiated the work flow.
To modify the workflow parameter files
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:
Table 5-10 Workflow parameter file names and paths
| Application | Workflow parameter file name and path |
|---|---|
|
User Manager |
|
|
Group Manager |
|
|
Organization Manager |
|
Locate the compound list for the action you want to support time-based escalation. The first half of this compound list should resemble the listing in Example 5-1:
Example 5-1 The workflow parameter compound list (partial listing only)
<CompoundList ListName="actionName">
<SimpleList >
<NameValPair ParamName="occurrence" Value="n"/>
<NameValPair ParamName="useraction" Value="true"/>
<NameValPair ParamName="initialStep" Value="false"/>
<NameValPair ParamName="time_based_escalation" Value="true"/>
</SimpleList>
. . .
</CompoundList>
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.
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.
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.
<ValNameList ListName="groupservcenter" > <NameValPair ParamName="Dll_Name" Value="groupservcenter"/> <NameValPair ParamName="Dll_Dir" Value="oblix/apps/groupservcenter/bin"/> <NameValPair ParamName="Dll_Load" Value="1"/> <NameValPair ParamName="Work_Dir" Value="oblix/apps/groupservcenter/bin"/>
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".
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.
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.
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.
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.
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.
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.
In the User Manager, click the Deactivated User Identity sub-tab to display the Search Deactivated Users page.
Search for, then select the deactivated user name for the identity you want to reactivate.
The View Profile page appears.
Click the Initiate User Reactivation button on the View Profile page.
The user is reactivated.
Note:
When you reactivate a user, you must manually add the user to any groups he or she belonged to, and re-set attribute policies and the searchbase for the user.Users who have the right to monitor a workflow can view the progress of a workflow, including request tickets owned by others.
Only requests within your management domain are listed. See "Delegating Administration" for details.
In User, Group, or Organization Manager, click Requests.
Click Monitor Requests.
Note:
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.
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.
View workflow requests, as described in "Monitoring a Workflow".
Select requests in the Select All column.
Click Archive.
When the archive confirmation page appears, click Back to return to the previous page.
Note:
You must restart the Identity Server after changing parameter files.You can remove workflow requests.
View requests as described in "Monitoring a Workflow".
Select requests in the Select All column and click Delete.
When the delete confirmation page appears, click Back to return to the previous page.
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.
Open a ticket as described in "To process a ticket".
The Lock and Unlock buttons are displayed on the workflow page when you process the workflow ticket.
Select Lock or Unlock, as appropriate.
Once you have defined workflows, you can view, copy, modify, delete, and export them.
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:CachePragmaHeader: Leave blank
CacheControlHeader: Specify Private or leave blank
See Oracle Access Manager Access Administration Guide for details.
To view and export a workflow summary
Access the User, Group, or Organization Manager.
Click Configuration, then click Workflow Definition.
From the workflows menu, select the workflow you want to view.
Select View.
The Workflow Definition View page appears.
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:
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.
See Oracle Access Manager Developer Guide for details.
Modify the copy.
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.
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.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.
You can delete a workflow unless the workflow has pending requests.
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.
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:CachePragmaHeader: Leave blank
CacheControlHeader: Specify Private or leave blank
See Oracle Access Manager Access Administration Guide for details.
Access the User, Group, or Organization Manager.
Click Configuration, then click Workflow Definition.
From the workflows menu, select the workflow to export.
Click Export All to be prompted to save a comma-delimited value file that includes all of your workflows.
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.
| Panel field | Description |
|---|---|
| Panel Label | Name of the panel as displayed in the Identity System.
This field can be localized. |
| Description | Description of what this panel does.
This field can be localized. |
| Attributes | Attributes used for the panel columns and their display names.
This field can be localized. |
You can modify, but cannot delete, workflow panels.
From the Identity System Console, click Common Configuration.
The Common Configuration page appears.
Click Configure Workflow Panels.
The Configure Workflow Panels page displays configured workflow panels.
Click the panel you want to view.
Click Modify.
The Modify Panel page appears.
In the Panel Label field, type a new name for this panel as it is to appear in the application.
In the Description field, type a description.
In the Attributes fields, select attributes to display on the application in the order in which they are to appear.
Click Save.
You can localize workflow panels to display the panel information in more than one language. To do this, you must do the following:
Install the appropriate language packs.
Manually enter the panel display information in the Administration Console for each language that you installed.
See "Making Schema Data Available to the Identity System" and "Configuring User, Group, and Organization Manager" for information on localizing attributes.
To view language-specific workflow panel information
From the Identity System Console, click Common Configuration.
The Common Configuration page appears.
Click Configure Workflow Panels.
The Configure Workflow Panels page displays configured workflow panels.
Click the panel you want to view.
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.
The Configure Panel Display Names page for the selected language appears.
Enter the following information:
Panel Label: Enter the language-specific display name for the panel.
Description: Enter a brief description of the panel. This is optional.
Attributes: Enter the language-specific text for each attribute display name.
Click Save to save your changes; click Cancel to exit the page without saving your changes.
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.
For more information about workflow performance see Oracle Access Manager Deployment Guide.
As defined in "Specifying Identity System Administrators", only an Identity Administrator can manage the User, Group, and Organization Manager.
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.
The following advanced options are available:
Attaching custom code to workflow actions
Configuring the behavior of workflow 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.
See the Oracle Access Manager Developer Guide for more information.
An external action serves the same purpose as pre and post actions, but differ from Identity Event Plug-in API actions in two ways:
An external action is not attached to an existing action.
Routing paths can be fully configured based on the external action's exit condition.
You implement the external action code as a hook in the oblixpppcatalog file. See the Oracle Access Manager Developer Guide for more information.
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. |
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.
Open the Modify Attributes applet as described in "Configuring Attributes".
For a person object class or an auxiliary object class associated with the person object class, select an attribute with a DN data type.
For example, you might select the Manager attribute.
From the Display Type list, select the Object Selector display type for this attribute.
Select the person object class, for example, gensiteOrgPerson, in the Target Object Class list.
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"/>
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.
Additional information on customizing self-registration pages is provided in the Oracle Access Manager Customization Guide.
The following procedure illustrates a self-registration workflow for Basic authentication.
To create a self-registration workflow
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.
Define a Create User or a Create Organization workflow using self-registration as the first step.
Access this workflow and record the workflow's Distinguished Name and the target domain.
You add this information to the self-registration URL.
Add the self-registration URL to an HTML document as follows:
https://domain_name:port/identity/oblix/apps/userservcenter/bin/ userservcenter.cgi?program=workflowSelfRegistration&ObWorkflowName=workflow_DN &ObDomainName=target_domain
Variables are as follows:
Domain_name:port: host system's domain name and port number.
Workflow_DN: the DN for the workflow.
Target_domain: the target path, without a name.
The value of ObDomainName target_domain is a target domain that was defined in the self-registration workflow. See "Defining an LDAP Target for Create Object Workflows" for details.
For organization self-registration, use this format:
https://domain_name:portnumber/identity/oblix/apps/objservcenter/ bin/objservcenter.cgi?program=workflowSelfRegistration&tab_id=tab_name&ObWorkflowName=workflow_DN&ObDomainName=target_domain
Variables are as follows:
Domain_name:portnumber: host system
Tab_name: the name of the tab
Workflow DN: the workflow's DN
Target_domain: the target path, without name
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:
%3D: Equal sign (=)
%2C: Comma
%20: Space
For example:
cn=Engineering Team, ou=Engineering, o=Company, c=US
is replaced by:
cn%3DEngineering%20Team%2C%20ou%3DEngineering%2C%20o%3DCompany%2C%20c%3DUS
Save the HTML file.
The following is an example of a self-registration URL:
http://silicon/identity/oblix/apps/userservcenter/bin/userservcenter.cgi?program=workflowSelfRegistration&obdomainname=o%3DCompany%2Cc%3DUS&obworkflowname=obworkflowid%3D20020605T1132216476%2CobcontainerId%3Dworkflowdefinitions%2co%3Doblix%2Co%3Dconfigdata
Note:
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.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.
See "Enabling the Location Tab in Organization Manager" and "Configuring Tab Profile Pages and Panels" for details.
Configure read permissions for location attributes.
See "Allowing Users to View and Change LDAP Data" for details.
Define a Create Location workflow as described in "Task overview: Defining a Create Location workflow" on page 5-66.
Create a new location and establish the location's hierarchy in relation to other locations if applicable.
See "Adding Object Classes" for details.
Assign a value for the Location attribute for a user or object profile.
See "Using the Workflow Applet" for details.
Note:
Attribute values can also be added and modified on object profile pages in addition to through a workflow.Task overview: Defining a Create Location workflow
Initiate a workflow as described in "Starting a New Workflow Definition".
Create one or more subflows, if necessary, as described in "About Subflows".
Note:
You must create subflows before you initiate the main workflow. This enables you to link a subflow to the main workflow.Select the attributes that you want to associate with the workflow as described in "Defining Step Attributes".
The available default location attributes are Location ID, Location Name, Location Title, and Map Image. Location ID and Location Name are required attributes.
Specify participants as described in "Defining the First Step in a Workflow".
Define the workflow process as described in "About Step Actions".
Save the workflow.
Enable the workflow as described in "Enabling a Workflow".
Test the workflow to ensure its validity as described in "Testing a Workflow".
|
 Copyright © 2000, 2009, Oracle. All rights reserved. Legal Notices |
|