oracle identity governance 11g r2 ps1 - creating a … identity governance 11g r2 ps1 - creating a...

Copyright © 2013, Oracle and/or its affiliates. All rights reserved.

Oracle Identity Governance 11g R2 PS1 - Creating a Parallel Approval Process CUSTOMIZING OIG - PARALLEL APPROVAL WORKFLOW.DOCX

Effective 06/05/12 of 97 Rev 1

Oracle Identity Governance 11g R2 PS1 - Creating a Parallel Approval Process

Overview




Overview of Creating a Parallel Approval Processes

In this tutorial, you learn to generate a SOA composite application template that is designed to integrate with the Oracle Identity Manager 11g request approval process requirements through the use of an approval policy.

While you can manually create a SOA composite from scratch to meet the interface definition and processing requirements for approval processing, the tutorial guides you through using the much quicker and easier approach of generating a template composite application by using the

new_project.xml Ant script supplied with Oracle Identity Manager 11g installations.

Tutorial tasks include:

Generating the SOA composite template application using the Ant script

Opening the generated application workspace in the Oracle JDeveloper 11g Composite Editor and modifying the BPEL Process and Human Task to implement a parallel task assignment scenario for approval processing.

Creating an ADF-based Taskflow (effectively, Web application form) for the human workflow process for the Oracle Identity Manager request data to be visible to assignee’s to whom the approval task is routed.

Deploying the SOA composite application and Taskflow application to the Oracle Identity Manager environment

Create an Approval Policy to use the custom SOA approval process for new requests made in Oracle Identity Manager 11g.

Testing the custom approval process by configuring users, roles, and other data in Oracle Identity Manager to make a request that is subject to custom approval processing and observing the implementation in action.

Prerequisites

This tutorial assumes have downloaded, installed and configured the following software:

Oracle Identity Governance 11gR2 PS1

Note: This tutorial assumes you have installed Oracle Identity Governance 11gR2 PS1

in a directory structure called /u01/app/Oracle/Middleware/Oracle_IDM1 and

that your WebLogic Server domain name is called base_domain. If your installation

path and the instance name are different, make a note of the values. You may set an

environment variable called $OIM_HOME to this directory structure.

Oracle JDeveloper 11.1.1.6.0

Note: This tutorial assumes you have installed this product in a directory structure

called /u01/app/jdeveloper. If your installation path is different, make a note of the

value. You need this information in a step later in this tutorial.

Oracle JDeveloper allows you to define an environment variable called

JDEV_USER_DIR that can be defined to specify the default location where Oracle

JDeveloper will create and store application workspace and project folders and files. If the environment variable is not defined Oracle JDeveloper uses the

$HOME/jdeveloper folder on Linux systems (or the C:\JDeveloper folder on

Windows platforms). This tutorial uses the JDEV_USER_DIR environment variable to

refer to the path where Oracle JDeveloper workspace and project are located.




Approval Workflow, Approval Policies, and Human Workflow Processes

An Oracle Identity Manager can make a request for access to a resource, role, and other items in the request catalog. A request can either be fulfilled immediately (known as a direct operation) or require manual intervention through an approval process (known as request-based operation).

When a user performs an operation, based on the authorization policies of the logged-in user, Oracle Identity Manager determines whether it is a direct operation or request-based operation. Request-based operations are subject to approval workflows.

The terminology used around “workflows” can get confusing because the Oracle Identity Manager documentation refers to the request-level and operational-level approval processes as workflow processes, and Oracle SOA Suite refers to human task workflows as workflow processes too. To avoid confusion and facilitate some clarity, this tutorial makes the distinction by qualifying the word workflow in the following way:

Approval workflow is the term used to refer to the Oracle Identity Manager request-level and operational-level approval workflow levels.

Human workflow is the term used to refer to the Oracle SOA Suite Human Task component within a SOA composite application. The SOA Suite Human Task component when used in a composite application implements all the logic for managing manual approval through human interaction based on declarative and programmatic constructs defined in the composite application.

Approval Workflow Levels (in Oracle Identity Manager)

Before a request-based operation can proceed through to fulfillment it has to go through the following two independent approval processes:

The request-level approval, which are primarily used for bulk requests, which involve multiple target users or multiple requested entities or any combination of both.

The operational-level approval, which are always for a single target user and a single operation or requested entity.

Note: Request-level approvals are invoked before the operational-level approvals.

In simple terms, each (request-level and operational-level) approval workflow must specify a specific human workflow enabled composite application process for implementing approval processing. Each SOA composite application uses the combination SOA components that work together to complete the approval process.

Approval Policies (in Oracle Identity Manager)

An approval policy is a rule that allows the request engine to specify a SOA composite that is used to process that approval policy. Approval policies can be configured at request-level and operational-level. By default, Oracle Identity Manager does not provide any approval policies. Therefore, default approval processing as described next takes place.

Human Workflows (in SOA Composite Applications)

Most Oracle SOA composite applications implement approval processing by combining a BPEL Process component with a Human Task component, as illustrated in the following diagram:




Typically, a SOA composite application that implements human workflow processing for each approval workflow level includes:

A BPEL Process component to receive the request information, from Oracle Identity Manager, for approval and returns the outcome of the approval processing determined by orchestrating the data process through the use of a Human Task component.

A Human Task component, which implements the human workflow services (inherent in Oracle SOA Suite) to coordinate the human interaction for manual approval. The Human Task configuration defines how the request data is routed and assigned as task for designated approvers to act on. When the human workflow process is complete an outcome is returned to the BPEL Process that in turn uses a callback to notify Oracle Identity Manager of the result from approval processing.

Note: These concepts are illustrated in the diagram above, which depicts default (out-of-the-box) request approval processing in Oracle Identity Manager 11g, without any approval policies defined. The basic processing steps are:

1. A user submits a request for a resource, entitlement, or combination thereof.

2. The request is routed to the DefaultRequestApproval SOA composite application,

which notifies a SYSTEM ADMINISTRATOR user that an approval task is waiting their

manual intervention for approval or rejection. If the SYSTEM ADMINISTRATOR action for

request-level approval is a reject action the request is not provisioned, and handling of the reject action is performed in Oracle Identity Manager.

3. If the request-level action is approved the request is passed to the operational-level

approval process by sending the request to the DefaultOperationalApproval SOA

composite, which again notifies a SYSTEM ADMINISTRATOR that an operational-level

approval task waits for their action. If the request is approved at the operational-level,




then the approval outcome is passed back to Oracle Identity Manager, which starts the provisioning process for the requested items, otherwise rejection handling is initiated.

While there is much more to the Oracle Identity Manager request processing than is depicted by the diagram and the associated diagram shown above, this tutorial concentrates on the approval processing and customization thereof.

In summary, without any approval policies defined in Oracle Identity Manager, by default,

request-level approvals are handled by the DefaultRequestApproval SOA composite, and

operational-level approvals are managed by the DefaultOperationalApproval SOA

composite application that are supplied with all Oracle Identity Manager installations

Note: The DefaultRequestApproval and DefaultOperationalApproval SOA

composite applications are almost identical in their process flow and design. The diagram approximates (although not completely accurate) their internal structure within the Oracle SOA Suite component of the diagram. Each composite application includes a Human Task

component that is configured to assign the approval request to a designated SYSTEM

ADMINISTATOR user. This is the default behavior of these processes. One of the differences

between the DefaultRequestApproval and DefaultOperationalApproval SOA

composite applications is that their respective email notifications message text indicates that the assigned task is either for a request-level or operational-level approval. By default the assignee

for default request-level and operational-level approvals is any user assigned the SYSTEM

ADMINISTRATOR role.

Tip: You can find the SOA source code in their respective Zip files for the

DefaultRequestApproval and DefaultOperationalApproval SOA composite

applications in the IDM_HOME/server/workflows/composites folder for your Oracle

Identity Manager installation, where IDM_HOME refers to the folder path in which you have

installed the Oracle Identity Manager software.

Customizing Approval Processes

Now that you have a basic understanding of the Oracle Identity Manager Approval Process workflows we can look at the different ways you can implement approval processing customizations.

Your approaches (choices) for customizing Oracle Identity Manager approval workflows are:

Modifying the supplied composite application code for the default request-level

(DefaultRequestApproval) and operational-level

(DefaultOperationalApproval), respectively. This approach means that you

replace default approval processing with your own custom implementation and eliminates the need to create any approval policies. Note: Oracle SOA Suite allows you to deploy new versions of a composite application without removing the older versions. Support for multiple versions of a composite application allows Oracle SOA Suite clients to use the versions that are applicable to their needs.

Creating an approval policy, that defines a request-level and operational-level approval workflow, with each level invoking a customized SOA composite application to handle the human workflow approval implementation. This approach allows you finer grained control over how different types of request can be associated with different approval processes requirements.

Combining the above two approaches.




This tutorial takes the approach of creating an approval policy that uses a custom SOA composite application for handling the approval workflow for the request-level approval process of role (or entitlement) requests.




Task 1: Generating the Custom SOA Composite Template

Overview

In this tutorial, you create a SOA composite template application source, by executing the

new_project.xml Ant script in the Oracle Identity Manager binary folders. You then copy the

generated SOA composite application workspace, project, and source files into your JDeveloper

mywork folder. The generated composite application contains the basic structure needed for:

Receiving input about the Oracle Identity Manager 11g request data.

Processing the request using a BPEL component that invokes a Human Task to manage the human workflow interaction using the beneficiary (requestor) manager as a single approver. This can be changed by altering the Human Task parameter settings, which is the objective of this tutorial.

Waiting for the Human Task approval process outcome (response) that is returned to Oracle Identity Manager to complete the request process depending on the outcome returned by using Web service callback operations.

Tasks

1. To create a new SOA composite template workspace, project, and source files, perform the following steps:

a. In a new Terminal window, enter the following commands:

$ export OIM_HOME=/u01/app/Oracle/Middleware/Oracle_IDM1

$ cd $OIM_HOME/server/workflows/new-workflow

$ ant –f new_project.xml

Note: Use the following table to provide the case-sensitive values for each prompt displayed by the utility:

Prompt Value entered

[input] Please enter application name ParallelApproval

[input] Please enter project name ParallelApproval

[input] Please enter the service name for the composite. This needs to be unique across applications

ParallelApproval

Note: The commands used are perform in a Linux environment. The equivalent commands are similar on a Windows platform. The folder paths used are based in typical default installation choices. Modify the paths to match your installed environment.




Hint: Use the above image and following listing as a guide to the information displayed in the Terminal window when you execute the Ant command:

$ export OIM_HOME=/u01/app/Oracle/Middleware/Oracle_IDM1

$ cd $OIM_HOME/server/workflows/new-workflow

$ ant –f new_project.xml

Buildfile: new_project.xml

new_project:

[unzip] Expanding:

/u01/app/Oracle/Middleware/Oracle_IDM1/server/workflows/new-

workflow/process-template/ApprovalApp.zip into


workflow/process-template

[input] Please enter application name

ParallelApproval

[input] Please enter project name

ParallelApproval

[input] Please enter the service name for the composite.

This needs to be unique across applications

ParallelApproval




[mkdir] Created dir:


workflow/process-template/ParallelApproval

[copy] Copying 49 files to



[copy] Copied 21 empty directories to 2 empty directories

under



[move] Moving 1 file to



[move] Moving 46 files to


workflow/process-template/ParallelApproval/ParallelApproval

[move] Moving 1 file to


workflow/process-template/ParallelApproval/ParallelApproval

BUILD SUCCESSFUL

Total time: 1 minute 1 second

Note: The new_project.xml tool generates a JDeveloper workspace that is created in

the $OIM_HOME/server/workflows/new-workflow/process-

template/ParallelApproval folder.

2. To copy the generate workspace folder and related files to your

$HOME/jdeveloper/mywork folder (on Windows the folder is usually located in

C:\JDeveloper\mywork) , execute the following command in the Terminal window:

$ cp –r process-template/ParallelApproval \

$HOME/jdeveloper/mywork

Note: If the jdeveloper/mywork folder does not exist then create it. The command

here uses a backslash as a line continuation indicator for technical correctness due to the command being wrapped over two lines when formatted in this document. On Windows, use Windows Explorer to copy and paste the folder tree. On Linux, the entire command can be entered on a single line. Use the following image as an example:

3. To verify that the workspace has been copied correctly, execute the following command in the Terminal window:

$ ls -l $HOME/jdeveloper/mywork/ParallelApproval

Note: Listing the contents of the ParallelApproval folder shows the

ParallelApproval subfolder (for the project files), the ParallelApproval.jws

workspace file, and the src subfolder, similar to the following image:




.

Tip! You can define an environment variable called JDEV_USER_DIR that

defines the location of the jdeveloper folder, in which the mywork and

application workspaces etc can be located.

From this point on, in this tutorial, to keep paths relatively generic across

platforms the string JDEV_USER_DIR is used to refer to the location of

jdeveloper folder path, whether the environment variable is set or not.




Task 2: Creating Department and User Data for Approval Processes

In this section of the tutorial, you sign into to the Oracle Identity Manager 11g Self Service

console as a system administrator by using the user xelsysadm and password you have

configured for your environment (in this tutorial we use the password Welcome1). As the system

administrator, you create the Sales and Finance departments. Then you create several users some of which are in the sales and others in the finance departments.

Tip: Consider creating your own custom department, roles, user names, and email addresses for your environment, and substitute accordingly to match this tutorial. This document was developed with a local email server configured with email addresses to meet the instructive objectives designed in this tutorial. The email server is configured to demonstrate the notification messages that are exchanged when tasks are assigned (routed) to users as part of functionality that is built-in to Oracle SOA human workflow.

Note: By default, the Oracle SOA Suite human workflow email notification services are not configured. Therefore, you must login in to the Oracle Enterprise Manager 11g System Administration console as a WebLogic Server administration user and configuration the email driver settings to specify the mail server host and ports in order for Oracle SOA Suite notification services to exchange email messages with task participants.

Tasks

1. To sign in to the Oracle Identity Self Service console, perform the following steps:

b. In a web browser, access the Oracle Identity Self Service console by accessing the

URL https://localhost:14001/identity, and log in using the User ID xelsysadm with

Password Welcome1.

c. On the Oracle Identity Self Service page, expand the Administration section (if needed) and click Organizations.

Creating the Organization Structure

At this stage, you need to create more users in Oracle Identity Manager for subsequent provisioning operations. You manually create the following organization tree:

2. To create the organizational hierarchy, perform the following steps:

a. To create the Sales organization and its Consulting sub-organization, use the following steps:

1) On the Organizations page, click Create.

Tip: Before creating an organization, if an organization entry is not selected from the list shown the organization Top becomes the parent of the new organization by default. Alternatively, first select the organization row entry you wish to be the parent of the new organization you are creating.




Note: The image shows a collapsed Search section after a general search had been executed to display the list of default organizations (Xellerate Users, Top, and Requests) already in the system.

2) On the Create Organization page, enter (or select) the following field values, and click Save.

Field Name Value

Organization Name Sales

Type Department

Note: If the Parent Organization Name is empty before you click Save, the organization Top is used by default. Otherwise, populate or accept the specified value as the parent of the new organization.

Hint: Use the following image as a guide:

3) Close the “Organization: Sales” tab page.




b. To create the Finance organization, use the following steps:

1) On the Organizations page, click Search or click the Refresh icon, select the Top organization entry, and click Create.

2) On the Create Organization page, enter (or select) the following field values and click Save.

Field Name Value

Organization Name Finance

Type Department

Note: The Parent Organization Name should contain the value Top. By default, if the Parent Organization Name is not entered it is set to Top when you click Save. Use the following image as a guide:

3) Close the “Organization: Finance” tab page.




c. On the Organization page, click Refresh and verify that you have the two new organizations listed in the system. Use the following image as your guide:

d. Close the Organizations tab page.

Creating the Manager and Consultant Roles for Sales and Finance Departments

In the section, you create the following four roles:

Sales Manager

Sales Consultant

Finance Manager

Finance Officer

These roles are assigned to users that are created later, and the roles are added to the request catalog so that new employees can request those roles.

3. Using Oracle Identity Self Service console you can create the roles, by performing the following steps:

a. On the Oracle Identity Self Service console page, click Roles under the Administration menu.




b. On the Roles tab page, click Create.

Note: The Search section has been collapsed in the preceding image.

c. On the Create Role tab page, enter Sales Manger in the Name and Display Name

fields and click Save.

d. On the Sales Manager tab page, click the close icon.




Note: The close icon may be obscured by an informational message indicating that the role has been created. You can just click on the page to dismiss the message and then access the close icon by positioning the mouse pointer over the right-hand edge of the tab page heading.

e. To create another role, on the Roles tab page, and click Create.

f. On the Create Role tab page, enter Sales Consultant in the Name and Display

Name fields and click Save.

g. Repeat the steps above to create the following two roles:

1) On the Create Role page, enter Finance Manger in the Name and Display


2) On the Create Role tab page, enter Finance Officer in the Name and Display





h. After closing all the role specific tab pages, return to the Roles tab and click Refresh to display the new role entries. Use the following image as a guide:

Note: On your system, the row numbers listed for each entry are likely to be different to those shown in the image above.

Creating Users in the Sales and Finance Departments

In this section, you create the user hierarchy show in the following image:




In the image diagram, Aime McBeth is the main manager (or CEO), who manages the Sales and Finance departments.

In the Sales department: Bettina MacElwee is a Sales Manager who reports to Aime. Celine Dayberry is a Sales Consultant who reports to Bettina.

In the Finance department: Constantine Drenan is the Finance Manager who also reports to Aime. Clarence Saladna is a Finance Officer that reports to Constantine

This simple hierarchy structure gives you the basis from you can experiment with different participant type configuration patterns available in the Assignments tab in the Human Task editor.

While the user roles are listed next to their names, the roles have to be added either by a

SYSTEM ADMINISTRATOR or requested by the individual themselves through the request

catalog and shopping cart provided by the Oracle Identity Self Service console application. The user hierarchy illustrates the following relationships and roles to be implemented:

4. To create the user Aime McBeth, perform the following steps:

a. On the Oracle Identity Self Service page, click Users under the Administration heading.

b. On the Users tab page, click Create.




Note: The Search section has been collapsed in the above image because it is not required for user creation, unless you wish to verify that the user does not exist.

c. On the Create User tab page, enter (or select from supplied browse iconic buttons or drop-down boxes) the following data field values, leaving all other fields with their default values, and click Submit.

Field Name Value

First Name Aime

Last Name McBeth

E-mail [email protected]

Organization Top (set with search icon)

User Type Full-Time Employee

Display Name Aime McBeth

User Login AMCBETH

Password Welcome1

Confirm Password Welcome1

Note: If required, use the following image as a guide:




Note: The Manager field value is optional and left empty for Aime because she is the top level manager in this scenario. A field marked with an asterisk is mandatory. This includes the Last Name, Organization, User Type. The Confirm Password is marked mandatory after you enter a value in the Password field.

d. Observe the “User created successfully” message that is displayed above the “User Details: Aime McBeth” tab and click on the tab title to dismiss the message.

e. Close the “User Details: Aime McBeth” tab page, by positioning the mouse over the right side of the tab page label and clicking the Close Tab icon.

5. To create the user Bettina MacElwee, perform the following steps:

a. Return to (or open) the Users tab page, click Create.

b. On the Create User tab page, enter (and choose) the following data field values, leaving all other fields with their default values, and click Submit.

Field Name Value

First Name Bettina

Last Name MacElwee


Manager Aime McBeth (set with search icon)

Organization Sales (enter manually or use the search

icon)


Display Name Bettina MacElwee

User Login BMACELWEE

Password Welcome1


Note: The Manager field is now filled in with the name of the manager in this case Aime McBeth (which is selected from dialog displayed after clicking the field’s search icon.) Use the following image as a guide:




c. Close the “User Details: Bettina MacElwee” tab page.

6. To create the user Celine Dayberry, perform the following steps:



Field Name Value

First Name Celine

Last Name Dayberry


Manager Bettina MacElwee (set with search icon)

Organization Sales (enter manually or use the search

icon)

User Type Contractor

Display Name Celine Dayberry

User Login CDAYBERRY

Password Welcome1


Note: Use the following image as a guide:




c. Close the “User Details: Celine Dayberry” tab page.

7. To create the user Constantine Drenan, perform the following steps:



Field Name Value

First Name Constantine

Last Name Drenan


Manager Aime McBeth (set with search icon)

Organization Finance (set with search icon)


Display Name Constantine Drenan

User Login CDRENAN

Password Welcome1






c. Close the “User Details: Constantine Drenan” tab page.

8. To create the user Clarence Saladna, perform the following steps:



Field Name Value

First Name Clarence

Last Name Saladna


Manager Constantine Drenan (set with search icon)

Organization Finance (set with search icon)


Display Name Clarence Saladna

User Login CSALADNA

Password Welcome1






c. Close the “User Details: Clarence,Saladna” tab page.

9. On the Users page, expand the Search section and click Search to update the Search Results section of the page and verify that the users are created as shown in the following image:

Note: Do not be concerned if the row numbers for each entry is different for your environment to the values shown in the above image.




Tip! To make sure that you can test and observe email notification messages that are sent by Oracle SOA Suite for approval task assignments, ensure that the following additional tasks are performed:

Configure the Human Workflow notification service with the outgoing mail server details for your mail server.

Create the user email accounts that match the email addresses you chose when creating each user.

Create an account for each user in your email client to be able to receive the messages from the mail server.

If the mail server configuration settings have been set before you create each user account a notification email message is sent to each user indicating that their account has been created. For example: Here is the default “Congratulations – New Account has been created” email account creation message received in a Thunderbird email client for Aime McBeth:

Update the Request Catalog with new Roles

Now that you have created the users, the Oracle Identity Self Service console can be used to assign roles to users. Roles can be directly assigned to a user by a SYSTEM ADMINISTRATOR user, or the users themselves can request the role assignment. In either case, the roles must be searchable in the request catalog before they can be assigned or requested. By default, the Catalog Synchronization Job in Oracle Identity Manager scheduler does not copy new roles to the request catalog. Therefore, in this section you learn how to search for, modify, and run the Catalog Synchronization Job to synchronize roles into the request catalog.

Note: When a role is requested by the user, the default approval processing is invoked. However, if the SYSTEM ADMINISTRATOR assigns the role no approval process is required. Therefore, for this tutorial you sign in as the SYSTEM ADMINISTRATOR to assign a role to two of the users, and you later create an approval policy for users requesting a role assignment to initiate the custom composite application you create and deploy.

In this section you perform the following tasks:

Access the System Administration console

Search for the Catalog Synchronization Job

Modify the parameters of the Catalog Synchronization Job to include role processing.

Run the modified Catalog Synchronization Job.

Verify that roles are visible through the request catalog.




10. To access the System Administration console, perform the following steps:

a. In a web browser page, if required sign in to the Oracle Identity Manager System

Administration console as the SYSTEM ADMINISTRATOR user xelsysadm using the

password (for example: Welcome1) you assigned to the user when Oracle Identity

Manager was installed.

b. On the Oracle Identity Manager System Administration console page, click Scheduler under the System Management heading.

c. On the Identity Manager System Administration page, ensure that the System Management > Scheduler tab page is selected.

11. To search for and modify the Catalog Synchronization Job parameters, and run the job to synchronize roles into the request catalog, perform the following steps:

a. On the System Management > Scheduler tab page, center the text Cat* in the Search

Scheduled Jobs search field and click the search arrow icon to the right of the field.




b. On the System Management > Scheduler tab page, in the Search Scheduled Jobs section click the Catalog Synchronization Job entry that appears in the results table.

c. On the “Job Details > Job Details: Catalog Synchronization Job” page, scroll down to locate the Process Roles option and click Yes and then click Apply.

d. On the “Job Details > Job Details: Catalog Synchronization Job” page, click Run Now.

Note: While the On the Catalog Synchronization Job is scheduled to periodically execute every 15 minutes, by default Roles are not synchronized. If you execute it immediately then you don’t have to wait for the next scheduled execution.




e. On the “Job Details > Job Details: Catalog Synchronization Job” page, a message confirmation that the “Job is running” is displayed.

Note: You can scroll down the “Job Details > Job Details: Catalog Synchronization Job” page to the Job History section to view the job status. For example, in this case it is still running.

f. On the “Job Details > Job Details: Catalog Synchronization Job” page, scroll up to the top and click Refresh.

g. On the “Job Details > Job Details: Catalog Synchronization Job” page, scroll down to the Job History section and verify that the job status indicates it has stopped and that the execution status indicates it was successful.




h. Close the web browser window containing the scheduler page.

12. To verify that the roles are searchable in the request catalog, perform the following steps:

a. In a web browser page, sign in to the Oracle Identity Manager Self Service console as

the SYSTEM ADMINISTRATOR user xelsysadm using the password (for example:

Welcome1) you assigned to the user when Oracle Identity Manager was installed.

b. On the Oracle Identity Manager Self Service page, under Requests click Catalog.

c. On the Catalog tab, enter sale* in the search field and click the search arrow icon on

the right to verify that the list of Catalog Items displays the two roles Sales Manager and Sales Consultant.

d. On the Catalog tab, replace the search text sale* with fin* in the search field and

click the search arrow icon on the right to verify that the list of Catalog Items displays the two roles Finance Manager and Finance Officer.




e. Close the Catalog tab page.

Assigning the Roles to Users

In this section, using the above image as a guide, as a SYSTEM ADMINSTRATOR you assign the Sales Manager role to Bettina MacElwee, and the Finance Manager role to Constantine Drenan. The users Celine Dayberry and Clarence Saladna later make a catalog request for their respective roles, subject to an approval policy that you create to ensure the custom SOA application handles the approval process.

13. In a web browser page, sign in to the Oracle Identity Manager Self Service console as the

SYSTEM ADMINISTRATOR user xelsysadm using the password (for example:

Welcome1) you assigned to the user when Oracle Identity Manager was installed.

14. To assign the Sales Manager role to Bettina MacElwee, perform the following steps:

a. On the Oracle Identity Manager Self Service page, if the Users tab is not open, click Users under the Administration heading.

b. On the Users tab, Refresh or click the Search button in the Search section.




Note: In this case, the Search section is collapsed and Refresh is clicked.

c. On the Users tab, locate and click the BMACELWEE user entry link.

d. On the “User Details: Bettina MacElwee” tab page, click the Roles tab and within that Roles tab click Request Roles.

e. On the Catalog tab page, enter sale* in the search field, click the search arrow icon,

and when the Sales roles appear, click “Add to Cart” for the Sales Manager entry.




f. On the Catalog tab page, verify that there is one item in the Cart, and click Checkout.

g. On the Catalog > Cart Details tab page, confirm that the Target Users table contains Bettina MacElwee and that the Cart Items contains the Sales Manager role, and click Submit.

Note: Observe that the Status for the Sales Manager entry in the Cart Items table indicates that it is “Ready to submit”.

h. On the Catalog > Cart Details tab page, when the “Successful Completed the operation” message appears, click the Close Tab icon to close the Catalog tab page.

i. Return to the “User Details: Bettina MacElwee” > Roles tab page, and click Refresh.




Note: After you click Refresh verify that the Sales Manager role appears as an entry in the Role Name column.

Note: In this case because a SYSTEM ADMINISTRATOR requested the role there was no need for any approval processing to take place.

j. Close the “User Details: Bettina MacElwee” tab page.

15. Repeat the steps you performed in previous task (step 14) and assign the Finance Manager role to the user Constantine Drenan. If needed use the following steps (with minimal screen shots to support a few of the steps):

a. On the Users tab, Refresh or click the Search button in the Search section, and in the Search Results section click the CDRENAN entry link.




b. On the “User Details: Constantine Drenan” tab page, click the Roles tab and within that Roles tab click Request Roles.

c. On the Catalog tab page, enter fin* in the search field, click the search arrow icon,

and when the Finance roles appear, click “Add to Cart” for the Finance Manager entry.

d. On the Catalog tab page, verify that there is one item in the Cart, and click Checkout.

e. On the Catalog > Cart Details tab page, confirm that the Target Users table contains Constantine Drenan and that the Cart Items contains the Finance Manager role, and click Submit.

f. On the Catalog > Cart Details tab page, when the “Successful Completed the operation” message appears, click the Close Tab icon to close the Catalog tab page.

g. Return to the “User Details: Constantine Drenan” > Roles tab page, and click Refresh, and verify that the Finance Manager role appears as an entry in the Role Name column.

h. Close the “User Details: Constantine Drenan” tab page.

Now you have create the basic meta data required for completing the approval processing configuration task followed by deploying the SOA application containing human task approval configuration for parallel approval, and then create the approval policy to consume the custom SOA composite application to handle the approval process.




Task 3: Customize the SOA Composite

Overview

In this section of the tutorial, you start Oracle JDeveloper, open the generated SOA template application workspace, examine the default composite application structure and identity components, and then customize the ApprovalTask Human Task component’s configuration to implement a parallel approval scenario.

Tasks

1. To open the ParallelApproval workspace in JDeveloper, perform the following steps:

a. If your desktop has a JDeveloper icon, double-click the JDeveloper icon, otherwise either using the command line or file navigator application browser to the folder where JDeveloper executable is installed in your environment and start the application.

Note: When you start JDeveloper, particularly the first time, after the splash screen is displayed you may see the following dialog boxes:

1) In the Select Role dialog box, for choosing the technology types you intend to develop with, accept the Default Role option, and click OK.

Note: If you don’t want to see this dialog appear every time you start JDeveloper, deselect the “Always prompt for role selection on startup” check box before you click OK.

2) In the Confirm Import Preferences dialog box, click No, unless you do have preferences from previous JDeveloper installations that you wish to import.




3) On the Oracle Usage Tracking dialog box (if it appears), accept the default selection, or deselect, the “Allow automated usages reporting to Oracle” check box (according to your preferences) and click OK.

4) On the Tip of the Day dialog box, deselect the “Show tips at startup” option in the status bar at the bottom left of the dialog box, and close the dialog box.




b. In the JDeveloper window, in the Application Navigator panel, click Open Application.

Note: Alternatively, select File > Open.

c. In the Open Application(s) dialog box, navigate to the

JDEV_USER_DIR/mywork/ParallelApproval folder, select the

ParallelApproval.jws file, and click Open.




d. To open and view the composite.xml application assembly model, in the JDeveloper

Application Navigator panel, expand the ParallelApproval > SOA Content nodes, and

right-click the composite.xml file entry and select Open.

e. On the composite.xml tab page (that opens in the middle panel of the JDeveloper

window), verify that it resembles the following image:




Note: The composite application contains the following components:

1) In the Exposed Services column (called a swim lane): An entry point called RequestApprovalService should exist. The composite service entry point component is connected to the ApprovalProcess BPEL component, which is the primary component for managing the processing requirements. The service entry point is as an asynchronous service (long running process due to the human interaction requirements) that accepts a variety of data as input from the client (in this case: Oracle Identity Manager).

Hint: Hold the mouse pointer over a component to get a more detailed description of the component.

2) In the Components column:

a) The ApprovalProcess BPEL component, which is wired to the ApprovalTask Human task component, the CallbackServer_2 web service component, and RequestWSPartnerLink service (the latter two are located in the External References column).

b) The ApprovalTask Human Task component, which is wired to the ApprovalProcess BPEL component.

c) The ChallengeTask Human Task component, which is not wired to any other component and would not be part of the implementation unless it is wired with the BPEL process or used in a meaningful way.

Note: The ChallengeTask component is seeded into the template in preparation for implementing a challenge workflow with the beneficiary and their manager to handled closed-loop remediation in the context of identity certification use cases. Because identity certification and closed-loop remediation is not part of this




tutorial, the ChallengeTask component can be left untouched or it can be deleted. In this tutorial, the ChallengeTask component is retained and not used.

3) In the External References column: The CallbackService_2 and RequestWSPartnerLink web service components exist and are wired to the ApprovalProcess BPEL component. The callback service is used to notify Oracle Identity Manager of the outcome of the approval processing so that the provisioning engine can take action based on the response. The RequestWSPartnerLink web service references the Oracle Identity Manager Request Web Service that provides operations to obtain more information about the request if additional data is needed to help the composite application complete its function.

Configure the ApprovalTask Human Task

In this section, you configure the settings for the ApprovalTask Human Task component to handling the human interaction for parallel approvals. To configure a Human Task component

you edit the metadata in the task file, in this case a file called ApprovalTask.task file that

appears in the generated composite project. The following image shows the two locations where you can open the ApprovalTask.task file for editing:

Note: To open the ApprovalTask.task file, either double-click the ApprovalTask component

in the composite editor or double-click the ApprovalTask.task file name in the Application

Navigator panel. The structure of the .task file is shown in the following image:




The key items to be configured in the SOA Human Task component include:

The Outcomes: These are specified as a comma-separated list of strings representing an action that an approver can make to assigned tasks. As shown in the image above, the Outcomes are configured in the General section of the task metadata file.

The Assignment: This configures the participant assignment (who the approval task is assigned to for selecting an action defined by the list of outcomes) and routing policy to be implemented by the Human Task. An example of the default assignment configuration generated is shown in the next image below:

Note: The Assignment section provides a graphic way to configure a human workflow pattern composed of different combinations of patterns that use the following constructs:

Stage: defines a unit of workflow processing, a step or stage, which defines a group of one or more participant blocks, each of which specifies a list of participants to which tasks are routed. When a stage completes the next stage is processed, if any are present. Stages can be arranged in a serial or parallel sequence, and combination of both. The image above has one stages with one participant block.




Participant block defines Participant Type and a Participant List.

o The Participant Type defines one part of how the outcome is determined for an assigned task. Possible types are:

Single, specifies that only one of the participants in the list can claim the assigned task and act (approve, reject, etc) on the task.

Serial, means the task is assigned participants in the sequence that they appear in the list. Each participant can perform an action on the task when the task is routed to them. Participants later in the sequence can override the outcome chosen from previous participants.

Parallel, means each participant in the list is assigned the task and they can act on the task. Each action performed is counted and calculated as a percentage of the total number of participants in the list. The outcome is determined based on a configuring the participant type to terminate either when the number participants that vote exceeds the percentage threshold specified for one of the outcomes, or when all of the participants in the list have voted.

FYI, defines a participant list that is assigned the task as form of notification. There is no action associated with an FYI task.

Management Chain, is a special case for any of the above types where the participant list is derived from a specified line of management.

o The Participant List, can be defined as a static list of users, groups, and application roles. Alternatively, the list participants can be dynamically determined from runtime constructs and by using business rules.

In summary, the structure of the Assignment section of the human task can be comprised of stages and participant blocks arranged in serial and parallel sequence, where each participant block is defined by a type and participant list as shown in the following image:




As stated, you may have multiple stages arranged in serial, parallel sequence, and a combination of both. In addition, each stage can have more than one participant block. Within a stage the participant blocks can also be arranged in serial or parallel sequence and a combination of both. These variations enable configuration of the human workflow to be simple or quite complex. The stage construct is useful to separate the different types of participant blocks and for more complex scenarios.

There are several possible ways to implement a simple parallel approval workflow. For example, you can use either of the following two workflow patterns (and there are other variations):

The two implementations above for parallel approval workflows are the same semantically even though they are different in implementation. The icon on the left side of a participant block visually indicates the participant type:

The icon with a single head indicates the participant type is a single approver, that is, only one person from the participant list can claim and approve (or reject) the task.

The icon with a multiple heads (each under their own arrow) indicates a parallel participant type configuration. For a parallel participant type, you configure a percentage of votes received from the participant list that can approve (or reject) the task.

The two implementation structures above are:

A. One stage containing two participant blocks arranged in parallel sequence. Where, each participant block is a serial participant type. This approach allows you to create participant lists that are quite different and operate independently of each other, while the end result is the combination of each.

B. Two stages, each with their own participant block is another way to implement parallel approve where the participant blocks (and their lists) are in different stages. The stages are executed in parallel, and the construct can be figure to wait for all stages to complete.

Note: Keep in mind that each participant block (within each stage) can also be parallel participant type, meaning that you can have parallel approval lists within either of the parallel patterns above. For example: the simplest implementation of a parallel approval is a single stage with a one participant block containing a parallel participant type, as shown in the following image:




For simplicity, this is the pattern you are about to configure in the generated SOA composite. Because there is already one stage and one participant block in the generated composite application, all you need to do is to change the participant type from Single to Parallel and then configure the appropriate settings for the Parallel Participant type parameters.

Therefore, to configure the ApprovalTask component Human Task settings you edit the

ApprovalTask.task file, by performing the following steps:

2. To edit the Human Task configuration, perform either (one) of the following actions:

a. On the Composite Editor page, right-click the ApprovalTask component and click Edit.

Note: Alternatively, you can double-click ApprovalTask component.

b. In the Application Navigator tab page, in the ParallelApproval > SOA Content folder, right-click the ApprovalTask.task file, and select Open.

3. To select and configure a parallel approval pattern for the ApprovalTask Human Task, perform the following steps:

a. On the ApprovalTask.task tab page, click the Assignment tab.




Note: The Assignment tab page is where you design the task routing and assignment details for human workflow patterns. You can create a combination of serial and parallel flows as discussed earlier on in this tutorial.

b. On the ApprovalTask.task > Assignment tab page, select the Stage1.Participant1 box inside the Stage1 stage, and click Edit.

Note: The composite generation tool, you used to create this composite application, creates (by default) a single stage with a single participant who is a SYSTEM ADMINISTRATOR. You alter this to become a parallel participant type and configure different participants.

c. In the Edit Participant Type window, change the Type from Serial to Parallel.




Note: When you change the Type value the settings associated with the previous Type are lost and the configuration choices are changed to provide settings suitable for the selected Type. The following image shows the various configuration options for the Parallel Type in the Edit Participant Type window:

Note: The following main configuration settings you can change are numbered in the above image.

In the Vote Outcome section, you can create multiple entries for each of the possible outcome for tasks or any of them based on a percentage value. The percentage value can be hardcoded (fixed) or dynamic, the latter is determined from data available in the composite application – usually the task payload or a BPEL process variable. For each voted outcome row you can set:

1) The Voted Outcome: as shown in the image allows you to select any of the outcome values such as APPROVE, REJECT, or Any.

2) The Outcome Type, where By Percentage specifies a fixed value, such as 50% as shown by default, or By Expression, where the expression calculates the percentage of the votes needed for the selected Voted Outcome entry to be satisfied.

3) The Default Outcome, which defines the outcome value returned by default when any of the voted outcome criteria are not satisfied. This field can be set dynamically through an expression.

In the Participant List section, you select the type participant list builder you want to use and configure the specific participants for the type of builder selected by using the following fields:

4) The “Build a list of participants using:” field, which allows you to build a list comprised of “Names and expressions”, Management Chain, or Rule-based. The subsequent configuration options change depending on your selection.




5) The Participant Names table appears if the Build a list of participants using:” field is set to “Names and expressions” as shown, in which case, you can click the Add button to add participants that is a specific User, Group, or Application Role and multiple entries of each.

Note: For example, if you have two participants added to the Participant Names section for a Parallel Type and the Voted Outcome is set to APPROVE when a 50% of the votes are received, then only one of the two participants need to select the APPROVE action to complete the task that returns an APPROVE result. This is the configuration you create in subsequent steps.

Therefore, if you have three participants with a 50% percentage vote for the APPROVE outcome, then at least two of the assignees must select the APPROVE action to get an approximate 60% vote for the APPROVE outcome to become the result.

Effectively, the number of votes needed for the selected outcome is the specified percentage of the total number of participants configured.

d. To start configuring the Parallel Type approval with a 50% vote for the APPROVE outcome with two named participants, Edit Participant Type window, make or check the following settings:

1) In the Voted Outcomes table of the Vote Outcome section, select the APPROVE outcome.

2) Accept By Percentage as the Outcome Type, and ensure the Value column contains a value of 50.

3) Select REJECT as the value for the Default Outcome.

4) Ensure the “Immediately trigger voted outcome when minimum percentage is met” option is selected. What this means, is that as soon as 50% of the votes are for the APPROVE outcome is received the workflow task processing completes and returns an APPROVE result. In this case, either one of the participants can select APPROVE and this will be the result. Alternatively, you can select the “Wait until all the votes are in before triggering outcome” option, which means that the task does not complete until everyone votes. The first option (to immediately trigger based on percentage reached) potentially reduces the time to wait for a completed outcome to be received.

5) In the Participant List section, accept “Names and expressions” for the “Build a list of participants using:” field and accept the Value-based option for the “Specify attributes using:” field.

6) In the Participant Names table heading, click the Add icon and select Add User.




Note: When you select Add User (Add Group, or Add Application Role) a new row is added to the Participant Names table. In each row you can alter your initial choice by change the value for each column that appears in a row. For example, the Identification Type column value can be User, Group, or Application Role. Data Type can by By Name or By Expression. Changes to these affect the way you specify the Value column. The value specified, such as the actual user, group, or application role name, in the Value column can be directly entered as a comma separated list of values. Alternatively, you can add multiple rows of the same Identification type and they are consolidated into a comma separated list. If you do not know the specific values for the selected Identification type you can click the ellipsis icon in the Value column to open an Identity Lookup dialog box.

e. To enter the value for the User participant name, in the Value column click ellipsis icon as shown in the following image:

Note: In the Value column when you click the ellipsis icon the Identity Lookup dialog box is opened where you can search for the user, group, or application roles. The search mechanism requires a connection to the application server running the WebLogic Administration Server used to manage the Oracle Identity Manager 11g




domain, to be able to look up the identities from the Oracle Identity Manager 11g identity store. The subsequent steps take you through this process.

f. When the Identity Lookup dialog box is opened, click the Create icon to the right of the Application Server field.

Note: Clicking the Create icon starts the Create Application Server Connection wizard.

g. On the Create Application Server Connection – Name and Type page (Step 1 of 5), enter a name for your connection, such as appserver, select WegLogic 10.3 for the Connection Type (or if needed, select your application server type), and click Next.

h. On the Create Application Server Connection – Authentication page (Step 2 of 5), enter the Username and Password values for the administrator username you specified when you configured the Oracle WebLogic Server domain for your Oracle Identity Manager 11g installation, and click Next.




Note: In the example, the Username is weblogic and Password Welcome1.

i. On the Create Application Server Connection – Configuration page (Step 3 of 5), enter

the hostname (or IP address) of the Administrator Server (for example localhost),

the Port (7001) and SSL Port (7002) configured for your administration server and the

name of the WebLogic Domain (in the example base_domain), and click Next.

Note: The “Always use SSL” check box is not selected in this example. For more secure interactions with the application server select the “Always use SSL” check box.

j. On the Create Application Server Connection – Test page (Step 4 of 5), click Test Connection, and after you have ensure that you get a “success” result for each of the entries listed in the image below, click Next.

Note: If you do not get success values when you test the connection, click Back to check and change the settings in the Authentication page or verify that the application server instance is actually running, and try the test again.




k. On the Create Application Server Connection – Finish page (Step 5 of 5), click Finish.

Note: After you click Finish, you are returned to the context of the Identity Lookup dialog box from where you launched the connection wizard and the new connection entry you created should be the selected value in the Application Server field.

l. Now that you have an application server connection established, you can observe that the Realm is also automatically selected. By default there is usually only one Realm

(the jazn.com realm) in WebLogic Application Servers. In addition, the Search

Pattern field contains an asterisk (*) wildcard, which does not work as search criteria for Oracle Identity Manager 11g identity stores. Therefore, to search for and select the

participant amcbeth as the participant, perform the following actions in the Identity

Lookup dialog box:

1) In the Search Pattern field, replace the * with a % character. The % character is a wildcard that works for Oracle Identity Manager 11g identity searches.

2) Accept the User Name selection and click the search icon on the far right of the Search Pattern field. This populates the Search User table with values.

3) Select the amcbeth entry from the Seach User list, and click Select to move the

entry into the Selected User list.

4) Click OK. Use the following image as a guide:




m. Back in the Edit Participant Type window, under the Participant Names heading the

Value should contain amcbeth in the first row. Now click the Add icon and select Add

Group to specify the second participant in the parallel approval pattern.

n. In the Edit Participant Type window, under the Participant Names heading a new row with an Identification Type of Group appears. Accept the Data Type value of By Name, and click the ellipsis icon on the right of the Value field for the new row.

o. In the Identity Lookup dialog box:

1) In the Search Pattern field, replace the * with a % character.

2) Accept the Group Name selection and click the search icon on the far right of the Search Pattern field. This populates the Search Group table with values.




3) Select the Finance Manager entry from the Seach Group list, click Select to

move the entry into the Selected Group section, and click OK. Use the following image as a guide:

p. In the Edit Participant Type window, all the configuration selections for the Parallel Type should now be specified. Use the following image as a guide to verify your selections, and click OK when done.




Note: Even though the Finance Manager is a group it represents one vote regardless of the number of people assigned to the group.

q. On the ApprovalTask.task > Assignment tab page, verify that the icon for the participant block represents the Parallel type confirming you configuration changes have been made.




Note: All configuration changes are made in JDeveloper memory and are not saved to the .task file until you explicitly save the changes. An italic filename in the tab label for a page indicates the file contents have been modified in memory and contains unsaved changes.

r. To save your configuration changes, in the JDeveloper toolbar, click the Save All icon. Alternatively, select File > Save All.

Note: While you have the ApprovalTask.task > Assignment tab page open, you can click the “Task will go from starting to final participant” icon to view and potentially change additional workflow configuration settings. For example:

1) Click the “Task will go from starting to final participant” icon.

2) On the Configure Assignment dialog box, you can change additional Routing and Assignment parameters. In this case, we observe the Routing options for your awareness, and do not make any changes.

Note: The Routing options allow you to enable participants to invite additional participants, and to configure early completion of a task when a specific outcome is selected among other settings that are enabled based on your selections.

Before you deploy the composite application it may be important to become aware of the payload (data) that is provided to the workflow process at runtime by examining the Data tab in




the ApprovalTask.task page. For example, the following image shows all the parameters that are supplied to the human workflow as task payload parameters:

Note: For example, the RequestID and RequesterDetails are XML data structures that can be used as information to include in Task Forms that the assignees of approval tasks can view to help them make decisions about the assigned task. Without this kind of data, and the Task Form the assignees would be acting blind on their task assignments. Most of the data for these parameters are obtained from the BPEL Process that initiates the human task workflow. The BPEL Process itself obtains the values from the request payload sent by Oracle Identity Manager when the approval composite application is invoked as a web service.

In addition, the BPEL Process can call the Oracle Identity Manager Request Web Service to obtain more information if required and supply that information as parameters in the Data tab for the human workflow processing to make use of.

In addition to all the previous human task configuration settings already covered, on the ApprovalTask.task > Notification tab page, you can view the default notification settings configured. Use the following image as an example:




Note: By default the Assignees are all sent a notification with the message text shown in the Edit Notification Message dialog box in the image. You add, remove, and change the notification row entries shown. You can also change the Notification Message text using the expression language shown in the Edit Notification Message dialog box to contain a mix of static text with dynamic information derived from task payload data.

A Word a About Notifications

Notifications, by default, are sent by email provided that you have configured the email driver settings for Oracle SOA Suite Workflow by using Oracle Enterprise Manager. If you have installed other notification drivers, such as the chat server driver, notifications can be configured to be delivered as instant messages.

Generating a Task Form

The assignees of a task are usually notified by email that they are assigned the task that needs attention. Assignees can then login to the Oracle Identity Self Service application and find the assigned task in their Inbox or access the Oracle BPM Worklist application, which also provides functions to view and manage assigned tasks.

When the users click on an assigned task a web form is displayed providing (APPROVE, REJECT, and other) actions that can be performed by the user. However, the details displayed in the task form is minimal by default and may not contain enough pertinent information for the assignee to make a decision whether to approve or reject the task.

As a developer of the composite application you can generate (or manually create) a task form that can be populated with fields containing information derived from the data values supplied, as the task payload, to the human task workflow composite application. Even if you auto-generate the task form, you can freely customize (edit) the task form to meet your requirements.

A generated (or manually created) Task Form is saved in its own JDeveloper project within the same application workspace as the associated composite application. By having the two projects in the same application workspace, it is easy to deploy the composite and its associated task form directly from JDeveloper to the application server. Otherwise, you have to create a SOA Archive (SAR) file for the composite and a Web Archive file wrapped in an Enterprise Archive (EAR) file for the Task Form, and then deploy the archive files separately through the Oracle Enterprise Manager 11g Administration console.

4. In this section, you auto-generate the task from for the ApprovalTask.task configuration, by performing the following steps:

a. On the ApprovalTask.task > Assignment tab page, click Create Form > Auto-Generate Task Form.

Note: The Create Form button appears in a toolbar on the ApprovalTask.task tab page.

b. In the Create Project dialog box, set the Project Name to your preferred string, such as ParallelApprovalTaskForm, and click OK.




Note: The last path name in Directory field forms the name of a sub-directory, whos value mirrors Project Name field, which contains the generate source code.

c. Be patient while JDeveloper generates the Task Form project and the project files, it does take some time. During the generation process you may receive one or more of the following Edit Table Columns dialog boxes. In the Edit Table Columns dialog box, if you are aware of the ramifications of you choices make changes and click OK, alternatively as in this example, click Cancel if you wish to accept the default values.

d. On the ApprovalTask_TaskFlow.xml tab page, you can view the Task Flow design, make modifications to generated model and save the changes. In this case, we just save the changes and close the ApprovalTask_TaskFlow.xml file.




Note: In the Application Navigator, you can verify that the ParallelApprovalTaskForm project appears in the ParallelApproval application Workspace in addition to the ParallelApproval SOA project. Use the following image as a guide.




Task 3: Build and Deploy the SOA Composite

Overview

In this tutorial, you create an Application Server connection that is used to deploy the SOA composite application. The SOA application is automatically compiled and built before it is packaged into the SOA Archive (SAR) file that is deployed to the application server identified by the connection properties you choose when creating the Application Server connection.

Assumptions The SOA composite application has been generated and modified as described in

Tutorial 12-3 and Tutorial 12-4.

The Request Web Service has been deployed during installation of Oracle Identity Manager.

The Oracle WebLogic Server instances for the AdminServer, SOA Server, and Oracle Identity Manager server are running.

Tasks

The two tasks to be performed are:

Creating an Application Server connection

Note: The application server connection you create for Identity Lookup purposes in the previous section can be used for deployment if the connection details references the application server to which you wish to deploy you application.

Deploying the ParallelApproval composite application to the Application Server

Creating the Application Server Connection

This section is optional, if you wish to use the application server connection created earlier in this tutorial for Identity Lookup purposes. However, the steps to create an application server connection is repeated here (if needed).

1. To create the application server connection, perform the following steps:

a. On the JDeveloper menu, click View > Application Server Navigator.

b. On the Application Server Navigator tab page, right-click the Application Servers node and click New Application Server. For example:




c. On the “Create Application Server Connection – Step 1 of 3: Usage” page, ensure the Standalone Server option is selected, and click Next.

d. On the “Create Application Server Connection – Step 2 of 6: Name and Type” page,

enter localhost in Connection Name, and click Next.

e. On the “Create Application Server Connection – Step 3 of 6: Authentication” page,

verify the Username contains weblogic, enter Welcome1 in Password, and click

Next.




f. On the “Create Application Server Connection – Step 4 of 6: Authentication” page,

verify Weblogic Hostname contains localhost, Port contains 7001, modify the

Weblogic Domain value to be base_domain, and click Next.

Note: Accept the default value of 7002 for the SSL Port.

g. On the “Create Application Server Connection – Step 5 of 6: Test” page, click Test Connection, verifying that all the tests produce a Success result, and click Next.




h. On the “Create Application Server Connection – Step 6 of 6: Finish” page, Click Finish.

2. On the Application Server Navigator tab page, expand the Application Servers node, and verify that the localhost connection is present. For example:

Deploying the SOA Composite Application from JDeveloper

The SOA Composite application should still be open in JDeveloper at this stage. If it is not open,

perform the actions needed to open the ParallelApproval.jws file in the

JDEV_USER_DIR/mywork/ParallelApproval folder.

3. To deploy the ParallelApproval composite application, perform the following steps:

a. On the JDeveloper Application Navigator tab page, right-click the ParallelApproval project node, and click Deploy > ParallelApproval.




Note: This action starts the Deployment wizard.

b. On the Deploy ParallelApproval > Deployment Action page, select "Deploy to Application Server", and click Next.

c. On the Deploy ParallelApproval > Deploy Configuration page, accept the default settings and click Next.




d. On the Deploy ParallelApproval > “Task flow deployment” page, select the check box for the ParallelApprovalTaskForm Project that appears in the Deployable Taskflow Projects table, and click Next.

e. On the Deploy ParallelApproval > Select Server page, select appserver (or used the

connection name you created) in the Application Servers list, and click Next.




Note: The appserver entry is the Application Server connection created in the either

the section titled “Creating the Application Server Connection” or section titled “Configure the ApprovalTask Human Task” of this tutorial. At this point JDeveloper searches the WebLogic domain for configured SOA servers. Be patient because this step may take a few minutes.

Tip! If an error such as the following is displayed, ensure that SOA Server is started, and then click Back, and click Next to retry the SOA server lookup.

f. On the Deploy ParallelApproval > SOA Servers page, accept the default selection of the soa_server1, and click Next.

Note: soa_server1 is the name of the SOA Suite server in the WebLogic domain.

g. On the Deploy ParallelApproval > Summary page, click Finish to complete the deployment of the SOA composite.




h. On the JDeveloper window, select the Deployment - Log tab, and verify that the deployment is successful. Use the following image as a guide:

Note: The Deployment Log tab displays messages regarding deployment. You may need to right-click in the Deployment – Log tab page and select Wrap to get similar visual results to the image above.

4. To verify that the SOA composite has been successfully deployed, perform the following steps:

a. In a web browser window, and enter the URL http://localhost:8001/soa-infra.

b. When the Authentication Required dialog box is display, in User Name enter

weblogic and in Password enter Welcome1, and click OK. For example:




c. On the “Welcome to the Oracle SOA Platform on WebLogic” page, verify that the

ParallelApproval composite appears in the list of deployed composites.


Deploying the SOA Composite Application by Using Oracle Enterprise Manager

The steps in this section are optional because you have already deployed the applications. However, this section has been added to document the steps required to deploy a SOA composite application by using Oracle Enterprise Manager Fusion Middleware Control. Before you deploy the SOA composite and Task Form using Oracle Enterprise Manager Fusion Middleware Control, you must first package the SOA composite application into a SOA Archive (SAR) file format. You can use JDeveloper to create the archive files. If you have a Task Form, the Task Form is deployed separately in an Enterprise Archive (EAR) file after you have deployed the SOA composite application. In summary, the key tasks are:

Packaging up the application code by using JDeveloper

Deploying the archive files by using Enterprise Manager Fusion Middleware Control. The Task Form application is deployed after deploying the SOA composite application.

5. To package the SOA application in a SAR file format, perform the following steps:

a. In the JDeveloper window, right-click the ParallelApproval project, and click Deploy > ParallelApproval.




b. On the Deploy ParallelApproval > Deployment Action page, select “Deploy to SAR,” and click Next.

c. On the Deploy ParallelApproval > Deploy Configuration page, accept the default settings (or change settings according to your requirements), and click Next.

d. On the Deploy ParallelApproval > Task flow deployment page, select the ParallelApprovalTaskForm check box, and click Next.




e. On the Deploy ParallelApproval > Deployment Summary page, click Finish.

f. On the JDeveloper Deployment – Log > Deployment tab page, verify that the

sca_ParallelApproval_rev1.0.jar files is generated. The sca*.jar file is the

SOA archive, called a SAR file. In addition, the ParrallelApprovalTaskForm.war file should be generated as well as the ParallelApproval.ear file. Use the following image as a guide:




6. To sign into to Oracle Enterprise Manager Fusion Middleware Control and deploy the composite application, perform the following steps:

a. In a web browser, access the Oracle Enterprise Manager Fusion Middleware Control using a URL of the form http://localhost:7001/em, where localhost should be substituted with the name of the host running your Oracle Identity Manager 11g domain.

b. On the Oracle Enterprise Manager Fusion Middleware Control login page, login as the

WebLogic Server administrator (for example: weblogic) and password (for example:

Welcome1).

c. On the Oracle Enterprise Manager Fusion Middleware Control page, expand the WebLogic Domain folder, right-click the domain name entry (base_domain, in this example), and click SOA Deployment > Deploy.

Note: You must select SOA Deployment to deploy the SOA archive file.




d. On the Oracle Enterprise Manager Fusion Middleware Control > Deploy SOA Composite page, for the Select Archive step, select the “Archive is on the machine where the web browser is running” (if applicable), and click Browse.

Note: For the initial deployment, leave all other options unchanged.

e. In the File Upload dialog box, browse or navigate to the JDEV_USER_DIR/mywork/ParallelApproval/ParallelApproval/deploy

folder, select the sca_ParallelApproval_rev1.0.jar file, and click Open.




f. On the Oracle Enterprise Manager Fusion Middleware Control > Deploy SOA Composite page, in the Select Archive step with the archive file listed, click Next.

g. On the Oracle Enterprise Manager Fusion Middleware Control Deploy SOA Composite

page, in the Select Target step, in the SOA Partition section select default from the

drop-down box, and click Next.

h. On the Oracle Enterprise Manager Fusion Middleware Control Deploy SOA Composite page, in the Confirmation step, click Deploy.




Note: Because this is the first deployment of the SOA application, it becomes the default revision, and therefore you can leave the Default Revision section unchanged. In addition, after you click Deploy, a Deploy Progress dialog box is displayed for you to monitor the progress of the deployment process. When deployment is completed, you either get an confirmation (see next step) or error message.

i. On the Oracle Enterprise Manager Fusion Middleware Control page, the SOA folder in the navigator panel is expanded to show the soa-infra (soa_server1) > default (partition) folder expanded with the successfully deployed ParallelApproval application listed and selected. In addition, the ParallelApproval application page is displayed in the right-hand panel with a success confirmation messages. Use the following image as a guide:




7. To sign into to Oracle Enterprise Manager Fusion Middleware Control and deploy the task form application, perform the following steps:

a. On the Oracle Enterprise Manager Fusion Middleware Control page, if needed, expand

the WebLogic Domain folder, right-click the base_domain entry (or your domain

name) and click Application Deployment > Deploy.

Note: You must select Application Deployment for WAR or EAR file being deployed.




b. On the Oracle Enterprise Manager Fusion Middleware Control > Deploy Java EE Application page, in Select Archive step, select the appropriate option for your environment, such as “Archive is on the machine where the web browser is running”, and click Browse.

c. On the File Upload dialog box, navigate to the

JDEV_USER_DIR/mywork/ParallelApproval/deploy folder, select the

ParallelApproval.ear file, and click Open.

Note: The Enterprise Archive (EAR) file is located in the deploy subfolder of the JDeveloper workspace folder. However, you may have been sent the files from the developer and placed them in a consistent location for deployment.




d. On the Oracle Enterprise Manager Fusion Middleware Control > Deploy Java EE Application page, in Select Archive step, with the EAR file selected, click Next.

e. On the Oracle Enterprise Manager Fusion Middleware Control > Deploy Java EE Application page, in Select Target step, select the soa_server1 check box, and click Next.




f. On the Oracle Enterprise Manager Fusion Middleware Control > Deploy Java EE Application page, in Application Attributes step, accept the default settings and click Deploy.

Note: The Processing: Deploy dialog box is displayed during deployment, as shown in the following image:




g. After deployment is completed, the Deployment Succeeded dialog box is displayed. Click Close.




Task 4: Test the ParallelApproval SOA Composite

Overview

In this tutorial, the following tasks to test the approval process managed by the ParallelApproval composite application are performed:

Creating an approval policy that has a automatic request-level and a manual operational-level approval policy pattern.

Note: The operational-level approval is configured to use of the ParallelApproval composite application for the approval processing.

Initiating the approval process by requesting the role that requires the approval processing to be performed.

Assumptions

The Sales Consultant and Finance Offer roles and the users listed in the section titled “Creating Department and User Data for Approval Processes” have been created.

Tasks

Creating the Approval Policies

In this section you create a request-level and operational-level approval policy that uses the ParallelApproval composite application that you deployed to the application server.

1. In the web browser window, access the Oracle Identity System Administration console URL

https://localhost:14001/sysadmin, and sign in as the user xelsysadm with password

Welcome1.

2. To create the request-level access policy, perform the following steps:

a. On the Oracle Identity System Administration console page, under Policies click Approval Policies.

b. On the Oracle Identity System Administration > Policies tab page, click the Create icon.




c. On the Oracle Identity System Administration > Policies > Create Approval Policy tab page, use the following table to set the field values listed, and click Next.

Field Name Value

Policy Name ParallelRL

Request Type Assign Roles

Level Request Level

Auto Approval [SELECTED]


d. On the Create Approval Policy tab “Step 2: Set Approval Rule and Component” page, create a Rule Name AssignRolesRule, and click Add Simple Rule.




e. In the Add Simple Rule dialog box, enter the following values to create the Approval Rule, and click Save.

Field Name Value

Entity Request

Attribute Request Type

Condition Equals

Value Assign Roles


f. On the Create Approval Policy tab “Step 2: Set Approval Rule and Component” page, under Rule Components expand the Approval Rule (OR) to confirm the condition “Request.Request Type Equals Assign Roles” is visible, and click Next.

Note: Use the following images as a guide:




g. On the Create Approval Policy tab “Step 3: Summary” page, click Finish.

h. In the Message dialog box, click OK.

3. To create the operational-level access policy, perform the following steps:

a. On the Oracle Identity System Administration > Policies tab page, click the Create icon.

b. On the Create Approval Policy tab page, use the following table to assign field values

for the ParallelOL policy, and click Next.




Field Name Value

Policy Name ParallelOL

Request Type Assign Roles

Level Operation Level

Auto Approval [NOT SELECTED]

Approval Process default/ParallelApproval!1.0

Note: See the steps shown below the next image.

Scope Type Role

All Scope [SELECTED]


Note: Before clicking Next, to select the Approval Process, perform the following steps:

1) On the Create Approval Policy tab page, in the Approval Process Configuration section, click the search icon.

2) In the “Search and Select : Approval Process” dialog box, enter Parallel in the Search field, click the search arrow icon, select default/ParallelApproval!1.0, and click Confirm.




c. On the Create Approval Policy tab “Step 2: Set Approval Rule” page, enter the Rule

Name ParallelOLRule, and click Add Simple Rule.

d. On the Create Approval Policy tab “Step 2: Set Approval Rule and Component” page, use the following table and image as a guide for creating the condition: “Role.Role Name Begins with Finance”, and click Save.

Field Name Value

Entity Role

Attribute Role Name

Condition Begins with

Value Finance





e. On the Create Approval Policy tab “Step 2: Set Approval Rule” page, expand the Approval Rule (OR) entry in the Rule Components section, and click Add Simple Rule.

Note: Keep the (OR) operation for combining the simple rules to form a compound condition, such that, the rule applies for roles beginning with the name Finance OR Sales.

f. On the Create Approval Policy tab “Step 2: Set Approval Rule and Component” page, use the following table and image as a guide for creating the condition: “Role.Role Name Begins with Sales”, and click Save.

Field Name Value

Entity Role

Attribute Role Name

Condition Begins with

Value Sales


g. On the Create Approval Policy tab “Step 2: Set Approval Rule and Component” page, expand the Approval Rule (OR) container to view the two simple rules, and click Next.




h. On the Create Approval Policy tab “Step 3: Summary” page, verify the settings and click Finish.

i. In the Message dialog box, click OK.




4. To confirm the two new policies are in the system, perform the following steps:

a. On the Policies > Approval Policies tab page, enter Parallel in the Search Approval Policies search field, click the search arrow icon.

b. On the Policies > Approval Policies tab page, confirm that the ParallelRL and ParallelOL entries appear in the search result table below the search field.

5. Close the window containing the Policies tab, and sign out of the Oracle Identity System Administration application.

Testing Approval Workflow

Remember the following user hierarchy diagram:

In this section, you sign into the Oracle Identity Manager Self Service application as Clarence Saladna (with user ID: CSALADNA), and make a catalog request for the Finance Officer role.




This should initiate the Approval Policies we created in the previous section and cause the ParallelApproval SOA process to be invoked to manage the approval for the operational-level approval step.

Note: Recall that the ParallelApproval composite application selected either the user Aime McBeth or a Finance Manager as possible approvers. This means that you can log in as Aime McBeth (with user ID:AMCBETH) or Constantine Drenan (with user ID: CDRENAN) to approve (or reject) the role request.

6. To sign in as the user CSALADNA and request the Sales Officer role, perform the following

steps:

a. Sign into the Oracle Identity Self Service console as the user CSALADNA and password

Welcome1.

Note: Enter any values you desire for the challenge questions and answers, and keep

the new password as Welcome1, and click Submit.




b. On the Oracle Identity Self Service console page, under My Profile click My Access.

c. On the My Access > Roles tab page, click Request Roles.

Note: CSALADNA is presently assigned the ALL USERS role.

d. On the Catalog tab page, search for Fin*, and click Add to Cart in row with the

Finance Officer role.

e. On the Catalog tab page, with 1 item in the cart, click Checkout.




f. On the Catalog page, with the Cart Details displayed click Submit.

Note: You should get a message indicating that the request is submitted for approval.

g. Sign out of the Oracle Identity Self Service application.

7. To approve the role assignment request as the user AMCBETH, perform the following steps:

a. Sign into the Oracle Identity Self Service console as the user AMCBETH and password

Welcome1.

Note: Enter any values you desire for the challenge questions and answers, and keep

the new password as Welcome1, and click Submit.

Addition Note: If you have set the mail server settings in Oracle SOA Suite Workflow configuration then in the email client application for Aime McBeth should show an email that resembles the following message:




b. On the Oracle Identity Self Service page, click the Inbox link.

c. On the Inbox page, click in the row for the Approval task (and not the link in the Title column) to select the entry.

Note: If you are not using a fully qualified host name to access Oracle Identity Self Service application, you may see the following tab page appear the first you click the task entry:

Tip! If you receive this Error page response, close the page, and repeat the action of selecting the Approval task row.

d. On the Inbox tab page, with the Approval task row selected, click Actions > Approve to approve the request.




e. On the Information dialog box, click OK, while observing that the task entry has been removed from the Inbox.

f. Sign out of the Oracle Identity Self Service application.

8. To verify that the role has been assigned to CSALADNA, perform the following steps:

a. Sign into the Oracle Identity Self Service console as the user CSALADNA and password

Welcome1.

b. On the Oracle Identity Self Service console page, click on My Access.

c. On the My Access > Roles tab page, confirm that the Finance Officer role appears as a new entry in the Role Name column.




Note: If you have an email server routing notification messages to the participants in the human workflow, the user csaladna’s email inbox would receive a message similar to the following image:

Tip! While the message body indicates a task requires attention, in this case, it is not necessary. However, the message subject and body can be controlled by editing the notification message details in the ApprovalTask.task configuration file.




Experiments: Setting Expiration and Escalation Policies

In the section of the tutorial, information is provided to show you where you can set an expiration policy for the human task processing, and in addition where and how to configure an escalation policy.

1. To set an expiration or escalation policy for a human task (approval) process, perform the following steps:

a. In the JDeveloper application, open the ApprovalTask.task file.

b. In the ApprovalTask.task tab page, click Deadlines and click the Task Duration Setting drop-down box to view the options available.

Note: Your Task Duration Setting choices are:

Never Expire (the default). Tasks never expire and remain in the system until appropriate actions cause the task to complete.

Expire after. This setting allows you to specify a fixed or dynamic (expression driven) duration in Days, Hours, Minutes, or a combination of these.

Note: If you choose an Expression to provide the value, the value must conform to XML date time format.

In the example the expression result could be a string such as: P5Y2M10DT15H,

which represents a period of five years, two months, 10 days, and 15 hours. Typically, this would be calculated by constructing an expression that obtains the value from some task variable instead of a manually entered string, which is shown in the example as a sample date format string.

Renew after. This setting is similar to the Expire after, with the addition of being able to specify the number of renewals permitted.




Escalate after. This setting causes the workflow engine to escalate a task that has not been acted on after 5 minutes (for example). The number of Escalation levels is based on hierarchical reporting structure, and optionally the Title of the Highest Approver can be specified.

Note: All choices, except the Never Expire selection, provide a way to specify a Custom Escalation Java Class that can be used for custom handling for the selection choice. However, writing a Custom Escalation Java Class is not in scope of this tutorial,

c. Save the changes you make, and redeploy the SOA composite application. Test the changes by initiating an approval as you have seen in this Tutorial.

Final Note: In addition, in the Assignment tab page of the ApprovalTask.task file, select the in the edit the participant block (for example Stage1.Participant1) and click Edit.

In the Edit Participant Type dialog box, you can scroll down to the Advanced section, click the icon to expand the section where you can configure a limit for the task duration. The




effect is that of no action is performed even after escalation or renewal, then the Default Outcome you specified is returned after the time limit expires.

Tip! In addition to limits already discussed, if you select the “Specify skip rule” check box you can create an expression that forms a condition. If the condition evaluates to true then the approval process is skipped. This is another form of conditional approval processing that can be done within the Human Task configuration in addition to the conditional processing that can be done in the BPEL Process.

oracle identity governance 11g r2 ps1 - creating a … identity governance 11g r2 ps1 - creating a...

Documents