Step 5: Defining Request Approvals

23-30 Oracle Fusion Middleware Developers Guide for Oracle Identity Manager

23.6 Step 6: Creating Request Templates

A request template lets you customize a request type for a purpose. In other words, it allows you to control the attributes of the request by controlling the various capabilities in the UI. See Managing Request Templates in the Oracle Fusion Middleware Developers Guide for Oracle Identity Manager for details about creating and managing request templates.

23.7 Extending Request Management Operations

You can customize certain aspects of request management operations to allow greater flexibility and implement customized logic for additional functionality. To achieve this, you can use request management plug-ins. There are plug-in points that you can use to implement customization. This section discusses the plug-in points in the following topics: ■ Running Custom Code Based on Request Status Change ■ Validating Request Data ■ Prepopulation of an Attribute Value During Request Creation

23.7.1 Running Custom Code Based on Request Status Change

In Oracle Identity Manager, a request undergoes change in status at each stage of its lifecycle. The request engine exposes a plug-in point that allows running of custom code during request status change. A plug-in with custom code that extends this plug-in point can be implemented and registered for running the code. The plug-in point is the oracle.iam.request.plugins.StatusChangeEvent interface with the public void followUpActionsString reqId method. This method consists of the request id parameter, using which the request details can be obtained with the help of request management APIs. Any code that is to be run during the status change must be implemented in the followUpActions method in a plug-in class that implements the oracle.iam.request.plugins.StatusChangeEvent interface. You must specify at which request status change this plug-in is to be run in the plugin.xml file. For example, when a request in Oracle Identity Manager moves to the Request Failed status, you want to run a custom code that sends a notification to an administrator. To do so: 1. Create a new plug-in class with name RequestFailedChangeEvent that implements the oracle.iam.request.plugins.StatusChangeEvent interface. This class must have See Also: ■ Managing Requests in the Oracle Fusion Middleware Users Guide for Oracle Identity Manager for detailed information about the concepts and tasks related to requests ■ Creating and Searching Requests in the Oracle Fusion Middleware Users Guide for Oracle Identity Manager for detailed information about creating and managing requests in Oracle Identity Manager See Also: Chapter 7, Developing Plug-ins for detailed information about plug-ins and plug-in points Configuring Requests 23-31 the logic of sending a notification to the administrator in the followUpActionsString reqId method. 2. Define plugin.xml in following standard format, as specified by the plug-in framework: oimplugins xmlns:xsi=http:www.w3.org2001XMLSchema-instance plugins pluginpoint=oracle.iam.request.plugins.StatusChangeEvent plugin pluginclass=com.mycompany.RequestFailedChangeEvent version=1.0 name=RequestFailedChangeEvent metadata name=status valueRequest Failedvalue metadata plugin oimplugins In this XML definition, the metadata part specifies at which stage the plug-in must be run. This is done by specifying the metadata value as Request Failed, which means that the com.mycompany.RequestFailedChangeEvent plug-in will run when a request moves to the Request Failed status. 3. Register the plug-in with Oracle Identity Manager. See Registering Plug-ins on page 7-6 for information about registering plug-ins in Oracle Identity Manager.

23.7.2 Validating Request Data

You can use the RequestDataValidator plug-in to add custom validation of request data after submission. The plug-in point for this is the oracle.iam.request.plugins.RequestDataValidator interface with public void validateRequestData requesterData method. See The DataSetValidator Element on page 23-4 for information about the DataSetValidator element.

23.7.3 Prepopulation of an Attribute Value During Request Creation

Prepopulation plug-in is associated with an attribute reference or attribute in request dataset. This can be used to prepopulate an attribute value by running custom code during request creation. Requester can modify the value that is prepopulated if required. The plug-in point for this is oracle.iam.request.plugins.PrePopulationAdapter with public Serializable prepopulateRequestData requestData method. Use this plug-in only for the following request types: Provision Resource, Self-Request Resource, Create User, Self-Register User. See The PrePopulationAdapter Element on page 23-9 for more details. 23-32 Oracle Fusion Middleware Developers Guide for Oracle Identity Manager 24 Understanding Approval Process Development in Oracle SOA Suite 24-1 24 Understanding Approval Process Development in Oracle SOA Suite Workflow-based provisioning is a key feature of Oracle Identity Manager that enables you to automate the business processes that manage user access in an organization. Oracle Identity Manager leverages services enabled and managed by Oracle Service-Oriented Architecture SOA Suite to provide an interactive environment to request, approve, and manage user access. Oracle SOA Suite provides the back-end services and management capabilities required to implement SOA. Oracle Identity Manager makes use of the following components of the SOA Suite: ■ BPEL Process Manager, which provides the end-to-end solution for creating and managing business processes ■ Human Workflow, which manages the lifecycle of human tasks, including creation, assignment, deadlines, expiration, and notifications ■ Oracle Business Rules, which allows you to define complex business rules to support request assignment, process selection, and approver resolution This chapter contains the following sections: ■ Integration with Oracle SOA Suite ■ Predefined SOA Composites ■ Developing an Approval Process for Oracle Identity Manager ■ Monitoring Oracle Identity Manager SOA Composites ■ Enabling Oracle Identity Manager to Connect to SOA

24.1 Integration with Oracle SOA Suite

In Oracle Identity Manager, SOA composites are used as approval processes. Integration of Oracle Identity Manager with Oracle SOA Suite is described in the following sections: ■ Integration Prerequisites ■ Integration Components

24.1.1 Integration Prerequisites

Before developing SOA composites for Oracle Identity Manager, the following prerequisites are recommended: ■ Knowledge of XML and XPath 24-2 Oracle Fusion Middleware Developers Guide for Oracle Identity Manager ■ Knowledge of Oracle Identity Manager APIs. ■ Knowledge of developing and deploying SOA composites. See Chapter 25, Developing SOA Composites for details. ■ Knowledge of using JDeveloper and the SOA Composite Editor. For details about using the JDeveloper IDE, see the JDeveloper Tutorial Series at following URL: http:www.oracle.comtechnetworkdeveloper-toolsjdevovervi ewindex.html

24.1.2 Integration Components

The integration of Oracle Identity Manger with Oracle SOA Suite consists of the following components: ■ SOA Suite installation as a part of installing Oracle Identity Manager. ■ One or more SOA composites. You can either extend the default composites shipped with Oracle Identity Manager or develop your own composites. ■ The SOA composite, which consists of: – The request payload. Oracle Identity Manager provides the SOA composite the details of the request by using XML. This is called the request payload. The SOA composite can use all or part of the payload to determine the next steps to take in the approval process. The payload format is fixed. – Oracle Identity Manager API calls optional. Oracle Identity Manager provides only the most essential information to the SOA composite to keep the payload small and also to ensure security. If the business process requires additional data, then you can use a Java embedding step to obtain more information about the requester, the beneficiary, or what is being requested. For information on how to invoke Oracle Identity Manager APIs, see Chapter 31, Using APIs . – One or more Human Tasks. Human tasks are steps in the overall business process where manual intervention, in the form of approvals, is required. A human task can consist of multiple steps, serial or parallel or a combination of both, where the task is assigned to one or more users or roles or a combination of both. You can define these human tasks and add notification, deadlines, and escalation rules. For information about how to design human tasks, see Oracle Fusion Middleware Developers Guide for Oracle SOA Suite. See Also: Oracle Fusion Middleware Tutorial for Running and Building an Application with Oracle SOA Suite for information about working with Oracle SOA Suite See Also: Oracle Fusion Middleware Developers Guide for Oracle SOA Suite for information about developing SOA composites Understanding Approval Process Development in Oracle SOA Suite 24-3 – One or more rulesets. There are specific business requirements that must be met when fulfilling requests. SOA composites leverage Oracle Business Rules to satisfy these requirements. A collection of rules developed by using Oracle Business Rules is called a ruleset. A composite can have one or more rulesets. Human tasks can also leverage these rules to determine the participants and the task routing. For information about how to design human tasks, see Oracle Fusion Middleware Developers Guide for Oracle SOA Suite. ■ A certified version of JDeveloper, for example, JDeveloper 11.1.1.3. ■ The SOA Design Time, also known as the SOA Composite Editor Extension for JDeveloper.

24.2 Predefined SOA Composites

Table 24–1 lists the predefined SOA composites in Oracle Identity Manager that can be used as approval processes. Note: In most approval scenarios, the composite contains only one human task. In some instances, additional human tasks may be required if the routing rules cannot be satisfied by using Oracle Business Rules. For example, the composite for resource request type contains multiple human tasks, one per resource. As a best practice, you must try to streamline the approval rules to facilitate reuse of the composites and human tasks. Table 24–1 Predefined Workflow Composites Workflow Composite Description DefaultRequestApproval This is the default request-level approval. By default, the request-level approval goes to the System Administrator, xelsysadm, for request-level approval. DefaultOperationalApproval This is the default operation-level approval. By default, the approval task is assigned to the System Administrator, xelsysadm, for operation-level approval. BeneficiaryManagerApproval This acquires approval from the beneficiarys manager. This can be associated with the following: ■ The request types that have a beneficiary. Examples of such request types are Provision Resource and Assign Roles. ■ All user models except Create User and Self-Register User. This composite must be associated at the operational level of approval because a request can have multiple beneficiaries at the request level. DefaultRoleApproval This SOA composite creates a single approval task that is assigned to the SYSTEM ADMINISTRATORS role for approval. RequesterManagerApproval This SOA composite creates a single approval task that is assigned to the requesters manager for approval. Note: This cannot be associated with unauthenticated request types, such as Self Register User.