4 Extending the Functionality of the Connector

This chapter describes procedures that you can perform to extend the functionality of the connector for addressing your specific business requirements. This section discusses the following topics:

Section 4.1, "Guidelines on Extending the Functionality of the Connector"
Section 4.2, "Adding or Removing Attributes for Reconciliation"
Section 4.3, "Adding or Removing Attribute Mappings for Provisioning"
Section 4.4, "Adding Filter Parameters in a Reconciliation Query"
Section 4.5, "Modifying Field Lengths on the Process Form"
Section 4.6, "Configuring Validation of Data During Reconciliation"
Section 4.7, "Configuring Transformation of Data During User Reconciliation"
Section 4.8, "Configuring Validation of Data During Provisioning"
Section 4.9, "Configuring the Connector for Multiple Installations of the Target System"
Section 4.10, "Customizing the Connector to Handle Timezone Differences"

4.1 Guidelines on Extending the Functionality of the Connector

Note:

In Oracle Identity Manager releases 11.1.x and 11.1.2.x, a scheduled job is an instance of a scheduled task. In this guide, the term scheduled task used in the context of Oracle Identity Manager release 9.1.0.x is the same as the term scheduled job in the context of Oracle Identity Manager releases 11.1.x and 11.1.2.x.

See Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for more information about scheduled tasks and scheduled jobs.

As mentioned earlier in this guide, predefined queries are provided for fetching target system user records for reconciliation and entitlement lookup field values for synchronization with Oracle Identity Manager. These predefined queries are in the ebsUMQuery.properties and ebsUMLookupQuery.properties files, respectively.

You can modify the predefined queries. In addition, you can add your own queries in the same file or a different properties file. The query whose name you specify in the scheduled task is applied during reconciliation or lookup field synchronization.

The following sections discuss guidelines that you must apply while modifying the predefined queries or creating new queries:

Section 4.1.1, "Guidelines for Configuring Queries Used in Lookup Field Synchronization"
Section 4.1.2, "Guidelines for Configuring Queries Used in Reconciliation"
Section 4.1.3, "Guidelines Common to Configuring Both Types of Queries"

The following section discusses guidelines that you must apply while modifying the predefined attribute mappings for provisioning:

Guidelines on Modifying Predefined Attribute Mappings for Provisioning

4.1.1 Guidelines for Configuring Queries Used in Lookup Field Synchronization

The following are guidelines that you must apply while modifying or creating queries for lookup field synchronization:

You must not change the SELECT clause of the predefined query. In other words, the set of target system attributes from which values are fetched for synchronization cannot be modified.
You must not change existing conditions in the WHERE clause of the predefined query.
You can add conditions to the WHERE clause of the predefined query.
If you create a new query, then you must mention the name of the query as the value of the Query Name attribute in the scheduled task.
If you want to use a new properties file instead of the predefined ebsUMLookupQuery.properties file, then specify the name of the file as the value of the Query Properties File attribute in the reconciliation scheduled task. See Section 3.2, "Scheduled Task for Lookup Field Synchronization" for information about this scheduled task.

4.1.2 Guidelines for Configuring Queries Used in Reconciliation

The following are examples of scenarios in which you might want to modify a reconciliation query:

You want to add a column in the SELECT clause of the reconciliation query.
You want to remove a column from the SELECT clause of the reconciliation query. For example, you might watnt to remove the usr.DESCRIPTION column.
You want to add conditions to the WHERE clause of the reconciliation query so that only a specified subset of the target system records are considered for reconciliation.

For example, you might want to reconcile records of users with a certain last name.

The following are guidelines that you must apply while modifying or creating queries for reconciliation:

By adding or removing a column from the SELECT clause of a reconciliation query, you add or remove an attribute from the list of target system attributes for reconciliation. To enable the connector to process a change (addition or removal) in the list of reconciled attributes, you must make corresponding changes in the provisioning part of the connector. The procedures are described later in this guide.
You cannot remove columns for attributes that are marked as mandatory attributes in the following tables:
The queries use inner queries, joins, unions, and the GROUP BY clause. If you add or remove a column from the outer query, you must make corresponding changes in the inner queries, joins, and union queries and the GROUP BY clauses.
You must ensure that the following conditions are included in the WHERE clause of the inner queries:

Note:
The queries for target resource reconciliation contain inner queries, joins, and unions.
```
WHERE((LAST_UPDATE_DATE -TO_DATE('01011970', 'DDMMYYYY')) *24 *60 *60 *1000) > :lastExecutionTime)  \
ROUND((respgrp.LAST_UPDATE_DATE -TO_DATE('01011970','DDMMYYYY')) *1440 *60 *1000) > :lastExecutionTime \
((rolegrp.LAST_UPDATE_DATE -TO_DATE('01011970', 'DDMMYYYY')) *1440 *60 *1000) > :lastExecutionTime \
```
These conditions are used to determine if a target system record, role, or responsibility was added or updated after the time stamp stored in the Last Execution Time scheduled task attribute.
In the WHERE clause, you must ensure that formats for date literals are specified by the use of the TO_DATE function. For example, instead of specifying a date value as '31-Dec-4712' use TO_DATE('31-Dec-4712','DD-Mon-YYYY').
Changes in attribute mappings for child table (multivalued) data are not supported. Therefore, you must not add or remove columns from the SELECT clause of the UM_USER_RESPONSIBILITIES and UM_USER_ROLES queries in the properties file.
Before you modify or add a query in the properties file, you must run the query by using any standard database client to ensure that the query produces the required results when it is run against the target system database.
If you want to use a new properties file instead of the predefined ebsUMQuery.properties file, then specify the name of the file as the value of the Query Name attribute in the reconciliation scheduled task. See Section 3.3.4, "Reconciliation Scheduled Tasks" for information about this scheduled task.

4.1.3 Guidelines Common to Configuring Both Types of Queries

The following are guidelines that you must apply while modifying or creating queries for either reconciliation or lookup field synchronization:

The name of the query must not be the same as the name of any other query in the properties file.
The name of the query must not contain spaces.
Before you modify or add a query in the properties file, you must run the query by using any standard database client to ensure that it produces the required results.
Use the number sign (#) to begin each comment line in the properties file.

Add comments to describe changes that you make in existing queries and also to describe new queries that you add in the file.

See existing comments in the properties file for an example.
If you want to introduce line breaks in the query (to improve readability), then add a backslash (\) at the end of each line.
You must ensure that the reconciliation does not contain any clause or SQL keyword that modifies or can be used to modify data in the database. For example, an error message is written to the log file if the following keywords are encountered:
- ALTER
- CREATE
- DELETE
- DROP
- EXECUTE
- INSERT
- UPDATE
If you create your own reconciliation query or modify an existing query, then you must ensure that the User Name (that is, the login ID), User ID, Effective Start Date From, and Effective Start Date To columns are present in the query. These are mandatory attributes for reconciliation.

4.1.4 Guidelines on Modifying Predefined Attribute Mappings for Provisioning

Apply the following guidelines before you start removing attributes for provisioning:

You must not remove attributes that are not marked as mandatory in Section 1.7.2, "Attribute Mappings for Provisioning".
You must not remove the process form fields (attributes) that are used during SoD validation of entitlement provisioning operations. These fields are listed in Section 1.7.2, "Attribute Mappings for Provisioning".
The connector supports both direct provisioning and request-based provisioning. To enable request-based provisioning, there are resource object forms corresponding to all the process forms.

Note:
As mentioned earlier in the guide, if you enable request-based provisioning, then direct provisioning is automatically disabled.

As part of the procedure described in this section, you must modify only the process form or both the process form and object form. If the attribute is to be added only on the process form, then ensure that the attribute is populated automatically during provisioning operations either by a pre-populate adapter or by a default value for the attribute.

4.2 Adding or Removing Attributes for Reconciliation

This section discuses the following topics:

Section 4.2.1, "Adding New Attributes for Reconciliation"
Section 4.2.2, "Removing Attributes Used for Reconciliation"

4.2.1 Adding New Attributes for Reconciliation

By default, the attributes listed in Section 1.6.2, "Target System Columns Used in Reconciliation" are mapped for reconciliation between Oracle Identity Manager and the target system. If required, you can add new attributes for target resource reconciliation.

To add a new attribute for reconciliation:

4.2.2 Removing Attributes Used for Reconciliation

By default, the attributes listed in Section 1.6.2, "Target System Columns Used in Reconciliation" are mapped for reconciliation between Oracle Identity Manager and the target system. From that list of attributes, you must ensure that mappings for the following attributes are not modified or removed:

User Management connector

Person ID
User ID
User name
Effective Date From
Effective Date To

User Management with HR Foundation connector

Attributes of the FND_USER record:

User ID
User name
Effective Date From
Effective Date To

Attributes of the HR Foundation record:

Employee Number
First Name
Last Name
Gender
Person Type ID
Business Group ID
Hire Date
Person ID

User Management with TCA Foundation connector

Attributes of the FND_USER record:

User ID
User name
Effective Date From
Effective Date To

Attributes of the TCA Foundation record:

First Name
Last Name
Party ID

To remove an attribute from the list of attributes for reconciliation:

4.3 Adding or Removing Attribute Mappings for Provisioning

By default, the attributes listed in Section 1.7.2, "Attribute Mappings for Provisioning" are mapped for provisioning between Oracle Identity Manager and the target system. If required, you can add new attributes for provisioning.

Note:

Attributes marked as mandatory in Section 1.7.2, "Attribute Mappings for Provisioning" cannot be modified or removed.

You cannot add, modify, or remove child form attributes for provisioning.

The connector uses custom stored procedures during User Create and User Update operations. These stored procedures are used to validate and transform data that is sent to the target system APIs. Wrapper packages are used to hold the custom stored procedures. Table 1-10, "Provisioning Functions" lists these wrapper packages.

Attributes used for provisioning are defined as parameters of both the custom and the target system stored procedures. If you add or remove an attribute (parameter) from a custom stored procedure, then you must make the same change in the target system stored procedure. This guideline forms the basis of one of the steps that you perform while adding or removing attributes for provisioning.

The original packages on the target system are part of the APPS user's schema. If you use the APPS user for connector operations, then the wrapper packages become part of the APPS user's schema at the end of the connector deployment procedure. If you use a different user account for connector operations, then the wrapper packages are part of that user's schema. You use this information to locate the wrapper package to be modified while adding or removing attributes for provisioning.

The rest of this section describes the following procedures:

Section 4.3.1, "Adding New Attributes for Provisioning"
Section 4.3.2, "Removing Attributes for Provisioning"

4.3.1 Adding New Attributes for Provisioning

To add a new attribute for provisioning:

Add the attribute as a field on the process form or object form as follows:

Note:
Proceed to the next step if you have already added the field to the process form while performing the procedure described in Section 4.2.1, "Adding New Attributes for Reconciliation".
1. Expand Development Tools, and then double-click Form Designer.
2. Search for and open the process form for the connector that you are using:
  
  See Section 4.9, "Configuring the Connector for Multiple Installations of the Target System" for a listing of the process definitions for each connector.
3. Click Create New Version to create a version of the form. Then, enter a version name and click the Save icon.
4. Click Add. The following screenshot shows this page:
5. Specify the properties of the attribute according to your requirement.
6. Click the Save icon.
7. Click Make Version Active to activate the new version of the process form.
To add the attribute as a parameter in the custom stored procedure:
1. Determine the name of the wrapper package that holds the custom stored procedure in which you must add the attribute. See Section 1.7.3, "Provisioning Functions" for a listing of the wrapper packages.
2. Add the parameter in the custom stored procedure.
  
  You can use a PL/SQL editor to open and edit the custom stored procedure. Alternatively, you can edit the custom stored procedure in the wrapper script provided on the connector installation package. To modify the stored procedure by using this script:
  
  See Also:
  Section 2.1.2.2, "Compiling Custom Wrapper Packages" for information about the script
  
  i. Open the package (.pck file) in a text editor.
  
  ii. Add the parameter in the appropriate stored procedure.
  
  iii. Save and close the file.
  
  iv. Compile the package. See Section 2.1.2.2, "Compiling Custom Wrapper Packages" for information.
Modify the configurations lookup definition as follows:

Signatures of the custom stored procedures are stored in the following lookup definitions:
- For the User Management connector: Lookup.EBS.UM.Configuration
- For the User Management with HR Foundation connector: Lookup.EBS.UMHRMS.Configuration
- For the User Management with TCA Foundation connector: Lookup.EBS.UMTCA.Configuration
Depending on the stored procedure in which you add the parameter, you must make the required change in the corresponding lookup definition as follows:
1. On the Design Console, expand Administration and then double-click Lookup Definition.
2. Search for and open one of the following lookup definitions:
  - Lookup.EBS.UM.Configuration
  - Lookup.EBS.UMTCA.Configuration
  - Lookup.EBS.UMHRMS.Configuration
3. Search for the entry containing the stored procedure signature that you modified earlier.
4. In the Decode column, add a question mark (?) to the list of question marks.
  
  Note:
  Each question mark in the signature value of the Decode column stands for a parameter of the stored procedure.
5. Click the Save icon.
Add an entry in the lookup definition for provisioning attribute mappings as follows:

Note:
Perform this step only if you are using FND user attributes as extended attributes.
1. On the Design Console, expand Administration, and then double-click Lookup Definition.
2. Search for and open the lookup definition for the connector that you are using:
  
  For the User Management connector: Lookup.EBS.UM.UserProvisioning
  
  For the User Management with HR Foundation connector: Lookup.EBS.UM.UserHRMSProvisioning
  
  For the User Management with TCA Foundation connector: Lookup.EBS.UM.UserTCAProvisioning
3. To add a row, click Add.
4. In the Code Key column, enter the field name (column name) for the attribute on the process form. See Step 1 for information about this field name.
5. In the Decode column, enter the stored procedure argument metadata.
6. Click the Save icon.
If you are using Employee record fields as extended attributes, then:
- Add an entry in the Lookup.EBS.UM.CreateEmployee and Lookup.EBS.UM.UpdateEmployee lookup definitions as follows:
  1. On the Design Console, expand Administration, and then double-click Lookup Definition.
  2. Search for and open the Lookup.EBS.UM.CreateEmployee lookup definition.
  3. To add a row, click Add.
  4. In the Code Key column, enter the process form field name added in Step 1.
  5. In the Decode column, enter information about the corresponding argument in the stored procedure used for HRMS person record provisioning.
  6. Click the Save icon.
  7. Repeat steps 5.b through 5.f with the following difference:
    
    While performing step 5.b, search for and open the Lookup.EBS.UM.UpdateEmployee lookup definition, instead of Lookup.EBS.UM.CreateEmployee.
- Add an entry in the Lookup.EBS.UMHRMS.EmployeeInfoMapping lookup definition as follows:
  1. In the Code Key column, enter the name of the process form column for information about the HR Foundation person record.
  2. In the Decode column, enter the name of the column used for fetching the person record data from the target system database.
- Modify the Lookup.EBS.UMHRMS.Configuration lookup definition as follows:
  1. On the Design Console, expand Administration, and then double-click Lookup Definition.
  2. Search for and open the Lookup.EBS.UMHRMS.Configuration lookup definition.
  3. Search for the GET_EMPLOYEE_DATA_QUERY code key entry.
  4. In the Decode column, modify the SELECT statement to include the newly added attribute (in Step 1).
  5. Click the Save icon.
If you are using person party record fields as extended attributes, then add an entry in the Lookup.EBS.UM.PartyProvisioning and Lookup.EBS.UM.UpdateParty lookup definitions as follows:
1. On the Design Console, expand Administration, and then double-click Lookup Definition.
2. Search for and open the Lookup.EBS.UM.PartyProvisioning lookup definition.
3. To add a row, click Add.
4. In the Code Key column, enter the process form field name added in Step 1.
5. In the Decode column, enter information about the corresponding argument in the stored procedure used for HRMS person record provisioning.
6. Click the Save icon.
7. Repeat steps 6.b through 6.f with the following difference:
  
  While performing step 6.b, search for and open the Lookup.EBS.UM.UpdateParty lookup definition, instead of Lookup.EBS.UM.PartyProvisioning.
Add the attribute as a reconciliation field in the resource object:
1. On the Design Console, expand Resource Management, and then double-click Resource Objects.
2. Search for and open the resource object for the connector that you are using.
  
  See Section 4.9, "Configuring the Connector for Multiple Installations of the Target System" for a listing of the process forms for each connector.
3. Click Add Field.
4. Enter the field name and field type
5. If you want make this a mandatory field for reconciliation, then select the Required check box.
6. Click the Save icon.
To enable updates of the attribute, add an update process task in the process definition as follows:

Note:
Ensure that the stored procedure in which you add the attribute (parameter) must be able to post updates of this attribute to the target system database.

To add an update process task:
1. On the Design Console, expand Process Management, and then double-click Process Definition.
2. Search for and open the process definition for the connector that you are using:
  
  For the User Management connector: eBusiness Suite User
  
  For the User Management with HR Foundation connector: eBusiness Suite User HRMS
  
  For the User Management with TCA Foundation connector: eBusiness Suite User TCA
3. On the Tasks tab, click Add.
4. On the General tab of the dialog box that is displayed, enter a name and description for the task. The following screenshot shows this page:
  
  Note:
  The name must be in the PROCESS_FORM_FIELD_NAME Updated format.
5. Click the Save icon.
6. On the Integration tab, attach the adapter. Depending upon the category of the user record adapter for adapter mapping to which the attribute is being added, use one of the following adapters:
  
  If the new attribute belongs to the FND_USER, then integrate with the adpEBSUPDATEUSER adapter.
  
  If the new attribute belongs to the HRMS Person record, then integrate it with the adpEBSUPDATEEMPLOYEE adapter.
  
  If the new attribute belongs to the TCA Party record, then integrate it with the adpEBSUPDATEPARTY adapter.
  
  Note:
  Do not use the adapter used for Username Updated task
7. Click the Save icon.
8. On the Response tab, add appropriate responses.
  
  For sample responses, see an existing process tasks such as the Password Updated process task.
9. Click the Save icon.
10. If you added the attribute in both the resource object and the process form, then go to the Data Flow tab and perform the instructions up to Step r.
11. Click Add Field Map.
12. Select the name of the field, from the second select box, for the object form field that you added.
13. Select the name of the corresponding field, from the third select box, for the process form field that you added.
14. Click the Save icon.
15. On the Reconciliation Field Mapping tab, click Add Field Map.
16. In the dialog box that is displayed, select one from the Field name drop-down box; this field name corresponds to the attribute name in Resource Object.
17. Double-click the Process Data Field, a new pop-up will appear. The entries in the pop-up correspond to the process form fields.
18. Select the corresponding newly added field from the pop-up.
19. If the field mapping is a key field for matching the process data, then check the key Field for Reconciliation matching check box.
20. Click the Save icon, and then close the dialog box.
Adding the attribute for reconciliation.

When you add an attribute on the process form, you must also enable reconciliation of values for that attribute from the target system. See Section 4.2.1, "Adding New Attributes for Reconciliation" for more information.
Note:
- Perform steps 10 and 11 only if you want to perform request-based provisioning.
Update the request dataset.

When you add an attribute on the process form, you also update the XML file containing the request dataset definitions. To update a request dataset:
1. In a text editor, open the XML file located in the OIM_HOME/DataSet/file directory for editing.
2. Add the AttributeReference element and specify values for the mandatory attributes of this element.
  
  See Also:
  The "Configuring Requests" chapter of the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager guide for more information about creating and updating request datasets
  
  For example, while performing Step 1 of this procedure, if you added City as an attribute on the process form, then enter the following line:
```
<AttributeReference
name = "City"
attr-ref = "City"
type = "String"
widget = "text"
length = "50"
available-in-bulk = "false"/>
```
  In this AttributeReference element:
  - For the name attribute, enter the value in the Name column of the process form without the tablename prefix.
    
    For example, if UD_EBSH_USR_CITY is the value in the Name column of the process form, then you must specify CITY as the value of the name attribute in the AttributeReference element.
  - For the attr-ref attribute, enter the value that you entered in the Field Label column of the process form while performing Step 1.
  - For the type attribute, enter the value that you entered in the Variant Type column of the process form while performing Step 1.
  - For the widget attribute, enter the value that you entered in the Field Type column of the process form, while performing Step 1.
  - For the length attribute, enter the value that you entered in the Length column of the process form while performing Step 1.
  - For the available-in-bulk attribute, specify true if the attribute must be available during bulk request creation or modification. Otherwise, specify false.
  While performing Step 1, if you added more than one attribute on the process form, then repeat this step for each attribute added.
3. Save and close the XML file.
Run the PurgeCache utility to clear content related to request datasets from the server cache.

See Oracle Fusion Middleware System Administrator's Guide for Oracle Identity Manager for more information about the PurgeCache utility.
Import into MDS, the request dataset definitions in XML format.

See the "Importing Request Datasets into MDS" section for detailed information about the procedure.

Note:
This step is only required for release 11.1.2 and request datasets are not required for it.
If you are using Oracle Identity Manager release 11.1.2 or later, create a new UI form and attach it to the application instance to make this new attribute visible. See Section 2.3.3.2.2, "Creating a New UI Form"" and Section Section 2.3.3.2.6, "Updating an Existing Application Instance with a New Form" for the procedures.

4.3.2 Removing Attributes for Provisioning

By default, the attributes listed in Section 1.7.2, "Attribute Mappings for Provisioning" are mapped for provisioning between Oracle Identity Manager and the target system. From that list of attributes, you must ensure that mappings for the following attributes are not modified or removed:

User Management connector

Person ID
User ID
User name
Effective Date From
Effective Date To

User Management with HR Foundation connector

Attributes of the FND_USER record:

User ID
User name
Effective Date From
Effective Date To

Attributes of the HR Foundation record:

Employee Number
First Name
Last Name
Gender
Person Type ID
Business Group ID
Hire Date
Person ID

User Management with TCA Foundation connector

Attributes of the FND_USER record:

User ID
User name
Effective Date From
Effective Date To

Attributes of the TCA Foundation record:

First Name
Last Name
Party ID

All three connectors support direct provisioning and request-based provisioning. There are resource object forms corresponding to all the process forms. During request-based provisioning, if the end user is not allowed to enter data for the attribute (field) that you want to remove, then only the process form must be modified. If the end user is allowed to enter data for the attribute, then the attribute must be removed from both the resource object form and the process form.

To remove the attribute (field) from the process form or resource object form:

Note:

If the attribute is to be removed only from the process form, then you must also remove any pre-populate adapter that is associated with the attribute.

To remove an attribute for provisioning:

Remove the attribute as a field on the process form or object form as follows:

Note:
Directly proceed to the next step if you have already added the field to the process form while performing the procedure described in Section 4.2.2, "Removing Attributes Used for Reconciliation".
1. Expand Development Tools, and then double-click Form Designer.
2. Search for and open the process form for the connector that you are using:
  
  See Section 4.9, "Configuring the Connector for Multiple Installations of the Target System" for a listing of the process definitions for each connector.
3. Click Create New Version to create a version of the form. Then, enter a version name and click the Save icon.
4. Select the attribute to be deleted, and then click Delete.
5. Click the Save icon.
6. Click Make Version Active to activate the new version of the process form.
To remove the attribute (parameter) from the custom stored procedure:
1. Determine the name of the wrapper package that holds the custom stored procedure in which you must add the attribute. See Section 1.7.3, "Provisioning Functions" for a listing of the wrapper packages.
2. Remove the parameter from the custom stored procedure.
  
  You can use a PL/SQL editor to open and edit the custom stored procedure. Alternatively, you can edit the custom stored procedure in the wrapper script provided on the connector installation package. To modify the stored procedure by using this script:
  
  See Also:
  Section 2.1.2.2, "Compiling Custom Wrapper Packages" for information about the script
  
  i. Open the package (.pck file) in a text editor.
  
  ii. Add the parameter in the appropriate stored procedure.
  
  iii. Save and close the file.
  
  iv. Compile the package. See Section 2.1.2.2, "Compiling Custom Wrapper Packages" for information.
Modify the configurations lookup definition as follows:

Signatures of the custom stored procedures are stored in the following lookup definitions:
- For the User Management connector: Lookup.EBS.UM.Configuration
- For the User Management with HR Foundation connector: Lookup.EBS.UMHRMS.Configuration
- For the User Management with TCA Foundation connector: Lookup.EBS.UMTCA.Configuration
Depending on the stored procedure in which you add the parameter, you must make the required change in the corresponding lookup definition as follows:
1. On the Design Console, expand Administration and then double-click Lookup Definition.
2. Search for and open one of the following lookup definitions:
  - Lookup.EBS.UM.Configuration
  - Lookup.EBS.UMTCA.Configuration
  - Lookup.EBS.UMHRMS.Configuration
3. Search for the entry containing the stored procedure signature that you modified earlier.
4. In the Decode column, remove a question mark (?) from the list of question marks. The following screenshot shows this page:
  
  Note:
  Each question mark in the signature value of the Decode column stands for a parameter of the stored procedure.
5. Click the Save icon.
Remove the entry from the lookup definition for provisioning attribute mappings as follows:
1. On the Design Console, expand Administration, and then double-click Lookup Definition.
2. Search for and open the lookup definition for the connector that you are using:
  
  For the User Management connector: Lookup.EBS.UM.UserProvisioning
  
  For the User Management with HR Foundation connector: Lookup.EBS.UM.UserHRMSProvisioning
  
  For the User Management with TCA Foundation connector: Lookup.EBS.UM.UserTCAProvisioning
3. To remove the row corresponding to the attribute that you want to remove, select the row and then click Delete.
4. Click the Save icon
If you are removing attributes specific to Employee record fields, then:
1. Remove the entry for the attribute from the Lookup.EBS.UM.CreateEmployee, Lookup.EBS.UM.UpdateEmployee, and Lookup.EBS.UMHRMS.EmployeeInfoMapping lookup definitions.
2. Modify the Lookup.EBS.UMHRMS.Configuration lookup definition by removing the attribute from the SELECT statement of the GET_EMPLOYEE_DATA_QUERY code key entry.
If you are removing attributes specific to person party record fields, then remove the entry for the attribute from the Lookup.EBS.UM.PartyProvisioning and Lookup.EBS.UM.UpdateParty lookup definitions.
Remove the attribute (reconciliation field) from the resource object:
1. On the Design Console, expand Resource Management, and then double-click Resource Objects.
2. Search for and open the resource object for the connector that you are using.
  
  See Section 4.9, "Configuring the Connector for Multiple Installations of the Target System" for a listing of the process forms for each connector.
3. Select the field that you want to remove, and then click Delete Field.
4. Click the Save icon.
From the appropriate provisioning process definition, delete the process task corresponding to the attribute that you want to delete as follows:

Note:
Ensure that the stored procedure in which you add the attribute (parameter) is able to post updates of this attribute to the target system database.
1. On the Design Console, expand Process Management, and then double-click Process Definition.
2. Search for and open the process definition for the connector that you are using:
  
  For the User Management connector: eBusiness Suite User
  
  For the User Management with HR Foundation connector: eBusiness Suite User HRMS
  
  For the User Management with TCA Foundation connector: eBusiness Suite User TCA
3. On the Tasks tab, select the process task to be deleted and then click Delete.
4. Click the Save icon.
5. If the fields must be deleted from both the process form and the resource object form, then:
  
  Select the mapping to be deleted.
  
  Click Delete Field Map.
  
  Click the Save icon.
6. If there is more than one data flow mapping to be deleted, repeat the preceding step.
7. On the Reconciliation Field Mapping page, select the mapping to be deleted.
8. Click Delete Field Map.
9. If there are multiple mappings to be removed, then repeat the preceding two steps.
10. Click the Save icon.
Remove the attribute for reconciliation as follows:

See Section 4.2.2, "Removing Attributes Used for Reconciliation" for more information.
Note:
- Perform steps 10 and 11 only if you want to perform request-based provisioning.
Update the request dataset.

When you remove an attribute on the process form, you also update the XML file containing the request dataset definitions. To update a request dataset:
1. In a text editor, open the XML file located in the OIM_HOME/DataSet/file directory for editing.
2. Remove the AttributeReference element corresponding to the attribute removed from the process form while performing Step 1. If you remove more than one attribute from the process form, then repeat this step for each attribute that you remove.
  
  For example, while performing Step 1 of this procedure, if you remove the City attribute from the process form, then remove the following line:
```
<AttributeReference
name = "City"
attr-ref = "City"
type = "String"
widget = "text"
length = "50"
available-in-bulk = "false"/>
```
  See Also:
  The "Configuring Requests" chapter of the Oracle Fusion Middleware Developer's Guide for Oracle Identity Manager guide for more information about creating and updating request datasets
3. Save and close the XML file.
Run the PurgeCache utility to clear content related to request datasets from the server cache.

See Oracle Fusion Middleware System Administrator's Guide for Oracle Identity Manager for more information about the PurgeCache utility.
Import into MDS, the request dataset definitions in XML format.

See the "Importing Request Datasets into MDS" section for detailed information about the procedure.

4.4 Adding Filter Parameters in a Reconciliation Query

You can add a parameter in the WHERE clause of a reconciliation query and specify a value for the parameter in the reconciliation scheduled task. For example, you can add a parameter in the WHERE clause of the UM_USER_RECON query so that it returns records of users whose user name is the one that you specify in the scheduled task.

To add a parameter in a reconciliation query:

Note:

Before you modify a query in the properties file, you must run the query by using any standard database client to ensure that the query produces the required results when run against the target system database.

Modify the query as follows:
1. Open the properties file in a text editor.
2. Add the parameter condition in the WHERE clause of the query that you want to modify. Use the :PARAMETER_NAME format to represent the parameter for which a value is provided in the scheduled task.
  
  Note:
  
  The parameter name must begin with the colon (:) as a prefix. In addition, there must be no space between the colon and parameter name and within the parameter name.
  
  You can add multiple parameters in a single query.
  
  In the following example, the condition highlighted in bold has been added to the WHERE clause of the UM_USER_RECON query:
```
WHERE ((LAST_UPDATE_DATE - TO_DATE('01011970','ddmmyyyy')) *24*60*60*1000) > :lastExecutionTime) \
AND UPPER(user_name)=UPPER(:userName) \
```
  Note:
  The UPPER function has been used in this example because the target system stores the user names in uppercase letters.
3. Save and close the properties file.
Configure the Lookup.EBS.UM.QueryFilters lookup definition as follows:
1. Log in to the Design Console.
2. Expand the Administration folder, and then double-click Lookup Definition.
3. Search for and open the appropriate lookup definition:
  - Lookup.EBS.UM.QueryFilter
  - Lookup.EBS.UMHRMS.QueryFilter
  - Lookup.EBS.UMTCA.QueryFilter
4. To add a row, click Add.
5. In the Code Key column, enter the variable name that you specified in the properties file. Do not include the colon (:) character. For example, enter username in the Code Key column.
6. In the Decode column, enter the value that you want to assign to the parameter for subsequent reconciliation runs. Use one of the following formats to specify a value:
  - value|STRING
    
    Sample value: jdoe|STRING
    
    Note:
    For the USER NAME example, you can enter the preceding sample value.
  - value|DATE|DATE_FORMAT
    
    Sample value: 24-Mar-09|DATE|DD-Mon-YY
  - value|NUMBER
    
    Sample value: 33|NUMBER
7. Click the Save icon.

When you next run the query that you have modified, the condition that you add is applied as an additional filter during reconciliation.

4.5 Modifying Field Lengths on the Process Form

You might want to modify the lengths of fields (attributes) on the process form. For example, if you use the Japanese locale, then you might want to increase the lengths of process form fields to accommodate multibyte data from the target system.

If you want to modify the length of field on the process form, then:

Log in to the Design Console.
Expand Development Tools, and double-click Form Designer.
Search for and open the process form.

See Section 4.9, "Configuring the Connector for Multiple Installations of the Target System" for a listing of process forms for each connector. The following screenshot shows this page:
Modify the length of the required field.
Click the Save icon.

4.6 Configuring Validation of Data During Reconciliation

You can configure validation of reconciled and provisioned single-valued data according to your requirements. For example, you can validate data fetched from the Email attribute to ensure that it does not contain the number sign (#).

Note:

This feature cannot be applied to the Locked/Unlocked status attribute of the target system.

To configure validation of data:

Write code that implements the required validation logic in a Java class.

The validation class must implement the oracle.iam.connectors.common.validate.Validator interface and the validate method.

The following sample validation class checks if the value in the Email attribute contains the number sign (#):

package oracle.iam.connectors.common.validate;
import java.util.HashMap;
public class TestValidator implements  Validator {
public boolean validate(HashMap hmUserDetails,
              HashMap hmEntitlementDetails, String field) {
            /*
         * You must write code to validate attributes. Parent
         * data values can be fetched by using hmUserDetails.get(field)
         * For child data values, loop through the
         * ArrayList/Vector fetched by hmEntitlementDetails.get("Child Table")
         * Depending on the outcome of the validation operation, 
         * the code must return true or false.
         */
         /*
         * In this sample code, the value "false" is returned if the field
         * contains the number sign (#). Otherwise, the value "true" is
         * returned.
         */
            boolean valid=true;
            String sEmail=(String) hmUserDetails.get(field);
            for(int i=0;i<sEmail.length();i++){
              if (sEmail.charAt(i) == '#'){
                    valid=false; 
                    break;
              } 
            }
            return valid;
      }

Create a JAR file to hold the Java class.
If you are using Oracle Identity Manager release 9.1.0.x, then copy the JAR file into the OIM_HOME/xellerate/ScheduleTask directory:

See Also:
The Java documents shipped with the connector for more information about this interface
If you are using Oracle Identity Manager release 11g, then use UploadJars utility to upload the JAR file into the database.
Log in to the Design Console.
Search for and open the Lookup.EBS.UM.Validation lookup definition. If it does not exist, create one.
In the Code Key column, enter the resource object attribute name. In the Decode column, enter the class name that is implementing the validation logic.

For example, if you want to perform validation of the Email attribute, then you must enter the following values in the Code Key and Decode columns:
- Code Key: Email
- Decode: oracle.iam.connectors.common.validate.TestValidator
Here, the Code Key specifies the name of the resource object attribute that you want to validate and Decode is the complete package name of the Implementation class.
Save the changes to the lookup definition.
To enable validation in the scheduled task for your database, set the value of the Use Validation For Reconciliation entry to yes, and then save your changes.

Note:

Follow the similar procedure for HRMS and TCA connectors with the lookup names Lookup.EBS.UMHRMS.Validation and Lookup.EBS.UMTCA.Validation.

4.7 Configuring Transformation of Data During User Reconciliation

You can configure transformation of reconciled single-valued account data according to your requirements. For example, you can use email to create a different value for the Email field in Oracle Identity Manager.

Note:

This feature cannot be applied to the Locked/Unlocked status attribute of the target system.

To configure transformation of single-valued account data fetched during reconciliation:

Write code that implements the required transformation logic in a Java class.

The transformation class must implement the oracle.iam.connectors.common.transform.Transformation interface and the transform method.

The following sample transformation class creates a value for the Email attribute by using values fetched from the Email of the target system:

package oracle.iam.connectors.common.transform;
import java.util.HashMap;
public class TestTransformer implements Transformation {
     /*
      Description:Abstract method for transforming the attributes
      param hmUserDetails<String,Object>
      HashMap containing parent data details
      param hmEntitlementDetails <String,Object>
      HashMap containing child data details
    */
    public Object transform(HashMap hmUserDetails, HashMap
 hmEntitlementDetails,String sField) {
        /*
         * You must write code to transform the attributes.
         * Parent data attribute values can be fetched by using
         * hmUserDetails.get("Field Name").
         * To fetch child data values, loop through the
         * ArrayList/Vector fetched by hmEntitlementDetails.get("Child Table")
         * Return the transformed attribute.
         */
         String sEmail= "trans" + (String)hmUserDetails.get(sField);
              
         return sEmail;
    }

Create a JAR file to hold the Java class.
If you are using Oracle Identity Manager release 9.1.0.x, then copy the JAR file into the following OIM_HOME/xellerate/ScheduleTask directory.

See Also:
The Java documents shipped with the connector for more information about this interface
If you are using Oracle Identity Manager release 11g, then use UploadJars utility to upload the JAR file into the database.
Log in to the Design Console.
Search for and open the Lookup.EBS.UM.Transformation lookup definition. If it does not exist, create one.
In the Code Key column, enter the resource object attribute name. In the Decode column, enter the class name that is implementing the validation logic.

For example, if you want to perform validation of the Email attribute, then you must enter the following values in the Code Key and Decode columns:
- Code Key: Email
- Decode: oracle.iam.connectors.common.trasform.TestTransformer
Here, the Code Key specifies the name of the resource object attribute that you want to validate and Decode is the complete package name of the Implementation class.
Save the changes to the lookup definition.
To enable transformation in the scheduled task for your database, set the value of the Use Transformation For Reconciliation entry to yes, and then save your changes.

Note:

Follow the similar procedure for HRMS and TCA connectors with the lookup names Lookup.EBS.UMHRMS.Transformation and Lookup.EBS.UMTCA.Transformation.

4.8 Configuring Validation of Data During Provisioning

Note:

This feature cannot be applied to the Locked/Unlocked status attribute of the target system.

To configure validation of data:

Write code that implements the required validation logic in a Java class.

The validation class must implement the oracle.iam.connectors.common.validate.Validator interface and the validate method.

The following sample validation class checks if the value in the Email attribute contains the number sign (#):

package oracle.iam.connectors.common.validate;
import java.util.HashMap;
public class TestValidator implements  Validator {
  public boolean validate(HashMap hmUserDetails,
              HashMap hmEntitlementDetails, String field) {
            /*
         * You must write code to validate attributes. Parent
         * data values can be fetched by using hmUserDetails.get(field)
         * For child data values, loop through the
         * ArrayList/Vector fetched by hmEntitlementDetails.get("Child Table")
         * Depending on the outcome of the validation operation, 
         * the code must return true or false.
         */
         /*
         * In this sample code, the value "false" is returned if the field
         * contains the number sign (#). Otherwise, the value "true" is
         * returned.
         */
            boolean valid=true;
            String sEmail=(String) hmUserDetails.get(field);
            for(int i=0;i<sEmail.length();i++){
              if (sEmail.charAt(i) == '#'){
                    valid=false; 
                    break;
              } 
            }
            return valid;
      }

Create a JAR file to hold the Java class.
If you are using Oracle Identity Manager release 9.1.0.x, then copy the JAR file into the OIM_HOME/xellerate/ScheduleTask directory:

See Also:
The Java documents shipped with the connector for more information about this interface
If you are using Oracle Identity Manager release 11g, then use UploadJars utility to upload the JAR file into the database.
Log in to the Design Console.
Search for and open the Lookup.EBS.UM.Prov.Validation lookup definition. If it does not exist, create one.
In the Code Key column, enter the resource object attribute name. In the Decode column, enter the class name that is implementing the validation logic.

For example, if you want to perform validation of the Email attribute, then you must enter the following values in the Code Key and Decode columns:
- Code Key: UD_EBS_USER_EMAIL
- Decode: oracle.iam.connectors.common.validate.TestValidator
Here, the Code Key specifies the name of the resource object attribute that you want to validate and Decode is the complete package name of the Implementation class.
Save the changes to the lookup definition.
To enable validation, set the value of the Use Validation For Provisioning entry to yes in the lookup definition Lookup.EBS.UM.Configuration and then save the changes.

Note:

Follow the similar procedure for HRMS and TCA connectors with the lookup names Lookup.EBS.UMHRMS.Prov.Validation, Lookup.EBS.UMTCA.Prov.Validation, Lookup.EBS.UMHRMS.Configuration, and Lookup.EBS.UMTCA.Configuration.

4.9 Configuring the Connector for Multiple Installations of the Target System

You may want to configure the connector for multiple installations of the target system. The following example illustrates this requirement:

The Tokyo, London, and New York offices of Example Multinational Inc. have their own installations of the target system. The company has recently installed Oracle Identity Manager, and they want to configure Oracle Identity Manager to link all the installations of the target system.

To meet the requirement posed by such a scenario, you must configure the connector for each installation of the target system. To do so, create copies of the connector objects listed in the following table:

Connector Object	User Management	User Management with HR Foundation	User Management with TCA Foundation
Resource Objects
	eBusiness Suite User	eBusiness Suite User HR Foundation	eBusiness Suite User TCA Foundation
	eBusiness Suite User Responsibility	eBusiness Suite User HR Foundation Responsibility	eBusiness Suite User TCA Foundation Responsibility
	eBusiness Suite User Role	eBusiness Suite User HR Foundation Role	eBusiness Suite User TCA Foundation Role
Process Definitions
	eBusiness Suite User	eBusiness Suite User HRMS	eBusiness Suite User TCA
	eBusiness Suite User Request	eBusiness Suite User HRMS Req	eBusiness Suite User TCA Req
	EBS User Responsibility	EBS UM HRMS Responsibility	EBS UM TCA Responsibility
	EBS User Responsibility Req	EBS UM HRMS Responsibility Req	EBS UM TCA Responsibility Req
	EBS User Role	EBS UM HRMS Role	EBS UM TCA Role
	EBS User Role Request	EBS UM HRMS Role Req	EBS UM TCA Role Request
Process and Object Forms
	UD_EBS_UO	UD_EBSH_UO	UD_EBST_UO
	UD_EBS_RSO	UD_EBSH_RSO	UD_EBST_RSO
	UD_EBS_RLO	UD_EBSH_RLO	UD_EBST_RLO
	UD_EBS_USER	UD_EBSH_USR	UD_EBST_USR
	UD_EBS_RESP	UD_EBSH_RSP	UD_EBST_RSP
	UD_EBS_RLS	UD_EBSH_RLS	UD_EBST_RLS
	UD_EBS_RLPO	UD_EBH_RLPO	UD_EBT_RLPO
	UD_EBS_RLCO	UD_EBH_RLCO	UD_EBT_RLCO
	UD_EBS_RLPP	UD_EBH_RLPP	UD_EBT_RLPP
	UD_EBS_RLCP	UD_EBH_RLCP	UD_EBT_RLCP
	UD_EBS_RSPO	UD_EBH_RSPO	UD_EBT_RSPO
	UD_EBS_RSCO	UD_EBH_RSCO	UD_EBT_RSCO
	UD_EBS_RSPP	UD_EBH_RSPP	UD_EBT_RSPP
	UD_EBS_RSCP	UD_EBH_RSCP	UD_EBT_RSCP
Process Task Type Adapters
	EBS Create User	EBS Create User HRMS	EBS Create User TCA
	EBS Update Employee	EBS Update Party
Lookup Definitions
	Lookup.EBS.UM.UserProvisioning	Lookup.EBS.UM.UserHRMSProvisioning	Lookup.EBS.UM.UserTCAProvisioning
	Lookup.EBS.UM.UserRecon	Lookup.EBS.UM.UserHRMSRecon	Lookup.EBS.UM.UserTCARecon
	Lookup.EBS.UM.Configuration	Lookup.EBS.UMHRMS.Configuration	Lookup.EBS.UMTCA.Configuration
	Lookup.EBS.Roles.Mapping	Lookup.EBS.UM.CreateEmployee	Lookup.EBS.UM.PartyProvisioning
	Lookup.EBS.Responsibility.Mapping	Lookup.EBS.UM.UpdateEmployee	Lookup.EBS.UM.UpdateParty
	Lookup.EBS.UM.QueryFilters	Lookup.EBS.UMHRMS.EmployeeInfoMapping	Lookup.EBS.UserTCAResponsibility.Mapping
		Lookup.EBS.HRMSRole.Mapping	Lookup.EBS.UserTCARoles.Mapping
		Lookup.EBS.HRMSResponsibility.Mapping	Lookup.EBS.UMTCA.QueryFilters
		Lookup.EBS.UMHRMS.QueryFilters
Scheduled Tasks
	eBusiness UM Target Resource User Reconciliation	eBusiness UM Target Resource User-HRMS Reconciliation	eBusiness UM Target Resource User-TCA Reconciliation
IT Resources
	EBS-APPS12	EBSHF-APPS12	EBSTCAF-APPS12

4.10 Customizing the Connector to Handle Timezone Differences

If Oracle Identity Manager and the target system are running in different timezones, then fields storing date values must be converted from the Oracle Identity Manager timezone to the timezone of the target system. This must be done using custom wrapper packages that are shipped with connector.

The following example shows the procedure that must be followed while handling the employee hire date field, when Oracle Identity Manager and the target system are running in two different timezones:

Open the OIM_EMPLOYEE_WRAPPER.pck file in a text editor.
Edit the create_emp_api stored procedure by ensuring that the hire date which is passed to hr_employee_api.create_employee() is in the timezome of the target system than the timezone of Oracle Identity Manager. In other words, convert p_hire_date value from the Oracle Identity Manager timezone value to the target system timezone value.
Declare the l_hire local variable by adding the following entry to the "Declare cursors and local variables" section:

l_hire_date per_all_people_f.original_date_of_hire%type;
Initialize the l_hire local variable with appropriate TIMEZONE_DIFF_HOURS as follows:
- If the timezone of Oracle Identity Manager is ahead of the timezone of the target system, then add the following entry:
  
  l_hire_date:= trunc(p_hire_date-TIMEZONE_DIFF_HOURS/24)
  
  In this entry, replace TIMEZONE_DIFF_HOURS with the difference in the number of hours between the timezone of Oracle Identity Manager and the target system.
- If the timezone of the target system is ahead of the timezone of Oracle Identity Manager, then add the following entry:
  
  l_hire_date:= trunc(p_hire_date+TIMEZONE_DIFF_HOURS/24)
  
  In this entry, replace TIMEZONE_DIFF_HOURS with the difference in the number of hours between the timezone of Oracle Identity Manager and the target system.
For example:

l_hire_date:= trunc(p_hire_date-12.5/24);

In this example, Oracle Identity Manager is in a timezone that is 12 hours and 30 minutes ahead of the timezone of the target system. Therefore, the timezone difference has been mentioned as "-12.5".

Note:
The conversion in the preceding example is a sample. You can customize it according to the requirements in your production environment.
Pass the local variable l_hire date value to hr_employee_api.create_employee() API by replacing p_hire_date with l_hire_date. The following is a code snippet that highlights the change:

Start of API

hr_employee_api.create_employee

(p_hire_date => l_hire_date
Save and close the OIM_EMPLOYEE_WRAPPER.pck file.
Import the OIM_EMPLOYEE_WRAPPER.pck file into the target system database for the changes to take effect.

Note:

Perform similar steps for any date fields used in the connector by changing appropriate wrapper package and modifying the configuration lookup definition to use the cuatom wrapper package, for the changes to take effect.
After performing this procedure, values in the date fields in the process form still hold values in the Oracle Identity Manager timezone. Therefore, perform a target reconciliation run to set the values in the date fields to values in the target system timezone.