Extending the Database User Management Connector

7 Extending the Database User Management Connector

You can extend the functionality of the connector to address your specific business requirements.

7.1 Modifying the Predefined Queries or Creating New Queries

Learn about the predefined queries for provisioning and reconciliation, and how to update them or create new ones to suit your requirements.

7.1.1 Understanding the Predefined Queries for Oracle Database

Learn about predefined queries, the syntax of the queries used for provisioning and reconciliation operations, the syntax of the list of values queries used for lookup field synchronization, and the guidelines that you must apply while modifying the predefined queries or creating new queries.

7.1.1.1 About the Predefined Queries for Oracle Database

The connector provides predefined SQL queries and stored procedures to reconcile target system user records, synchronize lookup field values with Oracle Identity Governance, and for provisioning operations. You can modify these predefined queries or add your own queries.

For example, to locate the reconciliation query file, you can extract the /bundle/org.identityconnectors.dbum-1.0.1116.jar file in the connector installation package and then open the /scripts/oracle/Search.queries file.

The connector includes the following types of queries:

Provisioning Queries

They are used for create, update, and delete operations. The query file is scripts/oracle/Provisioning.queries.
List of Values Search Queries

They are used for reconciliation of lookup definitions. A list of value query operates on a set of values for fields such as profiles, privileges, roles, and tablespaces. The query file is scripts/oracle/LoVSearch.queries.
Account Search Queries

They are used for full, incremental, and delete reconciliation operations. An account search query operates on account and group searches with various conditions. The query file is scripts/oracle/Search.queries.

The following are the predefined queries for Oracle Database:
- SEARCH_USER
  
  This query is used to fetch all user records from the DBA_USERS table.
- BATCHED_SEARCH_USER
  
  This query is used to fetch from the DBA_USERS table user records that are present within the specified range. It is used to perform batched reconciliation on a target system that is configured as a target resource.
- SEARCH_USER_ROLE
  
  This query is used to fetch all user roles from the DBA_ROLE_PRIVS table.
- SEARCH_USER_PRIVILEGE
  
  This query is used to fetch all user privileges from the DBA_SYS_PRIVS table.

Note:

The stored procedure OUT parameters cannot be configured for write-back on the process form. The returned values cannot be used for any connector operations.
Update operations for Oracle Database users are processed based on the create time-stamp, which is assigned to a user when the user is created. During incremental reconciliation, only the users created after this time-stamp are fetched. However, the users updated after the time-stamp are not fetched.

7.1.1.2 Syntax of Provisioning Queries for Oracle Database

The following is the syntax of the queries used for provisioning operations:

QUERYID {

Query="QUERY"

QueryType="QUERYTYPE"

Parameters=["PARAM1":"PARAMDEFN1", "PARAM2":"PARAMDEFN2"...]

ExtensionJoin="EXTENSIONJOIN"

ExtensionSeparator="EXTENSIONSEPARATOR"

QueryExtensions=["EXTENSION1","EXTENSION2"...]

}

For example:

CREATE_EXTERNAL_USER {
    Query="CREATE USER {__NAME__} IDENTIFIED EXTERNALLY"
    QueryType="SQL"
    Parameters=["__NAME__":"Type:String,TAGS:DOUBLEQUOTES"]
    ExtensionJoin=","
    ExtensionSeparator=", "
    QueryExtensions=["TEMP_TABLESPACE_QUERY","TABLESPACE_QUERY","PROFILE_QUERY"]
}

In this syntax:

QUERYID refers to the unique name of the query.

For example: CREATE_EXTERNAL_USER

For CREATE provisioing queries, the format of QUERYID is CREATE_AUTHENTICATIONTYPE_ACCOUNTTYPE. The default account type is USER. For other provisioning queries, the format is the OPERATIONTYPE_ATTRIBUTE, such as UPDATE_GLOBALDN.
QUERY refers to the main query.

For example: Query="CREATE USER {__NAME__} IDENTIFIED EXTERNALLY"
QueryType refers to the type of the main query, either an SQL query or a stored procedure. The value of QUERYTYPE can be SQL or StoredProc.

For example: QueryType="SQL"
Parameters refers to the list of comma separated parameters and parameter definitions used with the main query, represented by "PARAM1":"PARAMDEFN1", "PARAM2":"PARAMDEFN2", and so on.

For example: Parameters=["__NAME__":"Type:String,TAGS:DOUBLEQUOTES"]

A parameter can have the following attributes:
- Type is the type of the parameter.
- Direction is the flow of data from the query to or from the parameter. It can have a value of IN, OUT, or INOUT.
- TAGS is the enclosure characters that are applied to each parameter before the query is processed. It can have a value of DOUBLEQUOTES, QUOTES, UPPERCASE, or LOWERCASE.
  
  If you want to use multiple tags, you must encapsulate the tags in escaped quotes and separate them by commas. However, you must not use DOUBLEQUOTES with QUOTES or UPPERCASE with LOWERCASE in the same query.
  
  For example: "Type:String,TAGS:\"DOUBLEQUOTES,UPPERCASE\"
ExtensionJoin (optional) refers to the operator, represented by EXTENSIONJOIN, used to join the main query with query extensions.

For example: ExtensionJoin=","
ExtensionSeparator (optional) refers to the delimiter between query extensions, represented by EXTENSIONSEPARATOR.

For example: ExtensionSeparator=", "
QueryExtensions (optional) refers to the extensions that must be appended to the main query, represented by EXTENSION1, EXTENSION2, and so on.

For example: QueryExtensions=["TEMP_TABLESPACE_QUERY","TABLESPACE_QUERY","PROFILE_QUERY"]

During a provisioning operation, the connector combines all these components to the following query:

QUERY PARAM1, PARAM2... [EXTENSIONJOIN [EXTENSION1 EXTENSIONSEPARATOR EXTENSION2 EXTENSIONSEPARATOR...]]

For example:

CREATE USER {__NAME__} IDENTIFIED EXTERNALLY, TEMP_TABLESPACE_QUERY, TABLESPACE_QUERY, PROFILE_QUERY

Table 7-1 lists the script selection logic of the provisioning queries:

Table 7-1 Script Section Logic for Oracle Provisioning Queries

Operation	Selection Logic	Query IDs
CREATE	CREATE_AUTHTYPE_OBJECTYPE	CREATE_PASSWORD_USER CREATE_GLOBAL_USER CREATE_EXTERNAL_USER
DELETE	DELETE_OBJECTTTYPE	DELETE_USER
ENABLE	ENABLE_OBJECTTYPE	ENABLE_USER
DISABLE	DISABLE_OBJECTTYPE	DISABLE_USER
RESET PASSWORD	SET_PASSWORD	SET_PASSWORD
UPDATE	UPDATE_ATTRIBUTE	UPDATE_TABLESPACE UPDATE_DEFAULTQUOTA UPDATE_GLOBALDN UPDATE_PROFILE UPDATE_TEMPTABLESPACE
ADD CHILD VALUES	UPDATE_ADD_ATTRIBUTE	UPDATE_ADD_ROLES UPDATE_ADD_PRIVILEGES
REMOVE CHILD VALUES	UPDATE_REVOKE_ATTRIBUTE	UPDATE_REVOKE_ROLES UPDATE_REVOKE_PRIVILEGES

7.1.1.3 Syntax of Reconciliation Queries for Oracle Database

The following is the syntax of the search queries used during reconciliation operations:

QUERYID {

Query="QUERY"

QueryType="QUERYTYPE"

Parameters=["PARAM1":"PARAMDEFN1", "PARAM2":"PARAMDEFN2"...]

ExtensionJoin="EXTENSIONJOIN"

ExtensionSeparator="EXTENSIONSEPARATOR"

QueryExtensions=["EXTENSION1","EXTENSION2"...]

}

For example:

SEARCH_USER {
    Query="SELECT {__UID__}, {authType}, {externalname}, {tablespace}, {status}, {tempTableSpace}, {profile}," +
        " {defaultQuota}, {tmpQuota}, {lastModified} FROM  DBA_USERS dba {filter}"
    QueryType="SQL"
    Parameters=["__UID__":"Type:String,Direction:OUT,ColName:USERNAME",
            "authType":"Type:String,Direction:OUT,ColName:PASSWORD,ColQuery:\"DECODE(PASSWORD, 'EXTERNAL', 'EXTERNAL', 'GLOBAL', 'GLOBAL', 'PASSWORD')\"",
            "tablespace":"Type:String,Direction:OUT,ColName:DEFAULT_TABLESPACE",
            "tmpQuota":"Type:String,Direction:OUT,ColName:TEMPORARY_TABLESPACE_QUOTA,ColQuery:(SELECT MAX_BYTES FROM DBA_TS_QUOTAS WHERE dba.USERNAME = USERNAME AND TABLESPACE_NAME = dba.TEMPORARY_TABLESPACE)",
            "defaultQuota":"Type:String,Direction:OUT,ColName:DEFAULT_TABLESPACE_QUOTA,ColQuery:(SELECT MAX_BYTES FROM DBA_TS_QUOTAS WHERE dba.USERNAME = USERNAME AND TABLESPACE_NAME = dba.DEFAULT_TABLESPACE)",
            "externalname":"Type:String,Direction:OUT,ColName:EXTERNAL_NAME",
            "status":"Type:String,Direction:OUT,ColName:ACCOUNT_STATUS",
            "tempTableSpace":"Type:String,Direction:OUT,ColName:TEMPORARY_TABLESPACE",
            "profile":"Type:String,Direction:OUT,ColName:PROFILE",
            "lastModified":"Type:long,Direction:OUT,ColName:TIMESTAMP, ColQuery:\"((CREATED - TO_DATE('01011970','ddmmyyyy')) *24*60*60*1000)\""]
    QueryExtensions=["SEARCH_USER_ROLE", "SEARCH_USER_PRIVILEGE"]
}

In this syntax:

QUERYID refers to the unique name of the query.

For example: SEARCH_USER

QUERYID can be one of the following values:
- SEARCH_USER
- BATCHED_SEARCH_USER
- SEARCH_USER_ROLE
- SEARCH_USER_PRIVILEGE
QUERY refers to the main query.

For example: Query="SELECT {__UID__}, {authType}, {externalname}, {tablespace}, {status}, {tempTableSpace}, {profile}," + " {defaultQuota}, {tmpQuota}, {lastModified} FROM DBA_USERS dba {filter}"
QueryType refers to the type of the main query, either an SQL query, a stored procedure, or a query extension. The value of QUERYTYPE can be SQL, StoredProc, or QUERYEXTENSION.

For example: QueryType="SQL"
Parameters refers to the list of comma separated parameters and parameter definitions used with the main query, represented by "PARAM1":"PARAMDEFN1", "PARAM2":"PARAMDEFN2", and so on.

For example:

Parameters=["__UID__":"Type:String,Direction:OUT,ColName:USERNAME",

"authType":"Type:String,Direction:OUT,ColName:PASSWORD,ColQuery:\"DECODE(PASSWORD, 'EXTERNAL', 'EXTERNAL', 'GLOBAL', 'GLOBAL', 'PASSWORD')\""]

A parameter can have the following attributes:
- Type is the type of the parameter.
- Direction is the flow of data from the query to or from the parameter. It can have a value of IN, OUT, or INOUT.
- ColName is the column name in the target system corresponding to the parameter in the query.
- ColQuery is the query used to fetch values for the corresponding query parameter.
ExtensionJoin (optional) refers to the operator, represented by EXTENSIONJOIN, used to join the main query with query extensions.

For example: ExtensionJoin=","
ExtensionSeparator (optional) refers to the delimiter between query extensions, represented by EXTENSIONSEPARATOR.

For example: ExtensionSeparator=", "
QueryExtensions (optional) refers to the extensions that must be appended to the main query, represented by EXTENSION1, EXTENSION2, and so on.

For example: QueryExtensions=["SEARCH_USER_ROLE", "SEARCH_USER_PRIVILEGE"]

During a reconciliation operation, the connector combines all these components to the following query:

QUERY PARAM1, PARAM2... [EXTENSIONJOIN [EXTENSION1 EXTENSIONSEPARATOR EXTENSION2 EXTENSIONSEPARATOR...]]

For example:

SELECT {__UID__}, {authType}, {externalname}, {tablespace}, {status}, {tempTableSpace}, {profile}, {defaultQuota}, {tmpQuota}, {lastModified} FROM DBA_USERS dba {filter}, SEARCH_USER_ROLE, SEARCH_USER_PRIVILEGE

7.1.1.4 Syntax of List of Values Queries for Oracle Database

If a search query is performed on account types, such as User Name, then the query is considered as a reconciliation query. If a search query is performed on any other object, then the query is considered as a list of values query.

The following is the syntax of the list of values queries used for lookup field synchronization:

OBJECTTYPE = "QUERY"

For example:

__PROFILE__="SELECT DISTINCT profile FROM dba_profiles"

In this syntax:

OBJECTTYPE refers to the lookup field attribute.

For example: __PROFILE__
QUERY refers to the query used for fetching a lookup field attribute.

For example: SELECT DISTINCT profile FROM dba_profiles

The list of values queries return values that are used as lookup field entries. By default, the connector includes dedicated scheduled job for each lookup definition. To use a custom lookup definition, you must add custom fields in the query file.

7.1.1.5 Guidelines for Configuring Search Queries Used in Reconciliation from Oracle Databases

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.

If there are any read-only attributes, then you must disable updates to the read-only attributes in the respective process forms.
In the query properties file, you must not change the names of the predefined queries.
Some of the predefined queries use inner queries. If you add or remove a column from the outer query, you must make corresponding changes in the inner queries.
You cannot remove columns corresponding to the User Name resource object attribute.
You must ensure that the following condition included in the Parameters list is not removed:
```
"lastModified":"Type:long,Direction:IN,ColQuery:\"((CREATED - TO_DATE('01011970','ddmmyyyy')) *24*60*60*1000)\""]
```
This condition is used to determine if a target system record was added or updated after the time-stamp stored in the Incremental Recon Attribute scheduled job attribute.
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').
When you add or remove columns from the SELECT clause of the queries in the properties file, then you must update the attribute mapping lookup definition that holds mappings between child attributes and the target system column names. In addition, you must update other OIM objects.
Before you modify or add a query in the Search.queries 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.

7.1.2 Understanding the Predefined Queries for MySQL

Learn about predefined queries, the syntax of the queries used for provisioning and reconciliation operations, and the syntax of the list of values queries used for lookup field synchronization.

7.1.2.1 About the Queries for MySQL Database

For example, to locate the reconciliation query file, you can extract the/bundle/org.identityconnectors.dbum-1.0.1116.jar file in the connector installation package and then open the /scripts/mysql/Search.queries file.

The connector includes the following types of queries:

Provisioning Queries

They are used for create, update, and delete operations. The query file is /scripts/mysql/Provisioning.queries.
List of Values Search Queries

They are used for reconciliation of lookup definitions. A list of value query operates on a set of values for fields such as profiles, privileges, roles, and tablespaces. The query file is /scripts/mysql/LoVSearch.queries.
Account Search Queries

They are used for full and delete reconciliation operations. An account search query operates on account and group searches with various conditions. The query file is /scripts/mysql/Search.queries.

The following are the predefined queries for Oracle Database:
- SEARCH_USER
  
  This query is used to fetch all user records from the mysql.user table.
- BATCHED_SEARCH_USER
  
  This query is used to fetch from the mysql.user table user records that are present within the specified range. It is used to perform batched reconciliation on a target system that is configured as a target resource.
- SEARCH_USER_ROLE
  
  This query is used to fetch all user roles from the information_schema.SCHEMA_PRIVILEGES table.
- SEARCH_USER_PRIVILEGE
  
  This query is used to fetch all user privileges from the DBA_SYS_PRIVS table.

Note:

The stored procedure OUT parameters cannot be configured for write-back on the process form. The returned values cannot be used for any connector operations.

7.1.2.2 Syntax of Provisioning Queries for MySQL Database

The following is the syntax of the queries used for provisioning operations:

QUERYID {

Query="QUERY"

QueryType="QUERYTYPE"

Parameters=["PARAM1":"PARAMDEFN1", "PARAM2":"PARAMDEFN2"...]

ExtensionJoin="EXTENSIONJOIN"

ExtensionSeparator="EXTENSIONSEPARATOR"

QueryExtensions=["EXTENSION1","EXTENSION2"...]

}

For example:

CREATE_USER {
    Query="CREATE USER {__NAME__} IDENTIFIED BY {__PASSWORD__}"
    QueryType="SQL"
    Parameters=["__NAME__":"Type:String","__PASSWORD__":"Type:GuardedString,TAGS:QUOTES"]
    QueryExtensions=[]
}

In this syntax:

QUERYID refers to the unique name of the query.

For example: CREATE_USER
QUERY refers to the main query.

For example: Query="CREATE USER {__NAME__} IDENTIFIED BY {__PASSWORD__}"
QueryType refers to the type of the main query, either an SQL query or a stored procedure. The value of QUERYTYPE can be SQL or StoredProc.

For example: QueryType="SQL"
Parameters refers to the list of comma separated parameters and parameter definitions used with the main query, represented by "PARAM1":"PARAMDEFN1", "PARAM2":"PARAMDEFN2", and so on.

For example: Parameters=["__NAME__":"Type:String","__PASSWORD__":"Type:GuardedString,TAGS:QUOTES"]

A parameter can have the following attributes:
- Type is the type of the parameter.
- Direction is the flow of data from the query to or from the parameter. It can have a value of IN, OUT, or INOUT.
- TAGS is the enclosure characters that are applied to each parameter before the query is processed. It can have a value of DOUBLEQUOTES, QUOTES, UPPERCASE, or LOWERCASE.
  
  If you want to use multiple tags, you must encapsulate the tags in escaped quotes and separate them by commas. However, you must not use DOUBLEQUOTES with QUOTES or UPPERCASE with LOWERCASE in the same query.
  
  For example: "Type:String,TAGS:\"DOUBLEQUOTES,UPPERCASE\"
ExtensionJoin (optional) refers to the operator, represented by EXTENSIONJOIN, used to join the main query with query extensions.

For example: ExtensionJoin=","
ExtensionSeparator (optional) refers to the delimiter between query extensions, represented by EXTENSIONSEPARATOR.

For example: ExtensionSeparator=", "
QueryExtensions (optional) refers to the extensions that must be appended to the main query, represented by EXTENSION1, EXTENSION2, and so on.

During a provisioning operation, the connector combines all these components to the following query:

QUERY PARAM1, PARAM2... [EXTENSIONJOIN [EXTENSION1 EXTENSIONSEPARATOR EXTENSION2 EXTENSIONSEPARATOR...]]

For example:

CREATE USER {__NAME__} IDENTIFIED BY {__PASSWORD__}

Table 7-2 lists the script selection logic of the provisioning queries:

Table 7-2 Script Section Logic for MySQL Provisioning Queries

Operation	Selection Logic	Query IDs
CREATE	CREATE_OBJECTYPE	CREATE_USER
DELETE	DELETE_OBJECTTTYPE	DELETE_USER
RESET PASSWORD	SET_PASSWORD	SET_PASSWORD
ADD CHILD VALUES	UPDATE_ADD_ATTRIBUTE	UPDATE_ADD_PRIVILEGES
REMOVE CHILD VALUES	UPDATE_REVOKE_ATTRIBUTE	UPDATE_REVOKE_PRIVILEGES

7.1.2.3 Syntax of Reconciliation Queries for MySQL Database

The following is the syntax of the search queries used during reconciliation operations:

QUERYID {

Query="QUERY"

QueryType="QUERYTYPE"

Parameters=["PARAM1":"PARAMDEFN1", "PARAM2":"PARAMDEFN2"...]

ExtensionJoin="EXTENSIONJOIN"

ExtensionSeparator="EXTENSIONSEPARATOR"

QueryExtensions=["EXTENSION1","EXTENSION2"...]

}

For example:

SEARCH_USER {
    Query="SELECT {__UID__} FROM MYSQL.USER {filter}"
    QueryType="SQL"
    Parameters=["__UID__":"Type:String,Direction:OUT,ColName:USER"]
    QueryExtensions=["SEARCH_USER_PRIVILEGE"]
}

In this syntax:

QUERYID refers to the unique name of the query.

For example: SEARCH_USER

QUERYID can be one of the following values:
- SEARCH_USER
- BATCHED_SEARCH_USER
- SEARCH_USER_PRIVILEGE
QUERY refers to the main query.

For example: Query="SELECT {__UID__} FROM MYSQL.USER {filter}"
QueryType refers to the type of the main query, either an SQL query, a stored procedure, or a query extension. The value of QUERYTYPE can be SQL, StoredProc, or QUERYEXTENSION.

For example: QueryType="SQL"
Parameters refers to the list of comma separated parameters and parameter definitions used with the main query, represented by "PARAM1":"PARAMDEFN1", "PARAM2":"PARAMDEFN2", and so on.

For example:

Parameters=["__UID__":"Type:String,Direction:OUT,ColName:USER"]

A parameter can have the following attributes:
- Type is the type of the parameter.
- Direction is the flow of data from the query to or from the parameter. It can have a value of IN, OUT, or INOUT.
- ColName is the column name in the target system corresponding to the parameter in the query.
- ColQuery is the query used to fetch values for the corresponding query parameter.
ExtensionJoin (optional) refers to the operator, represented by EXTENSIONJOIN, used to join the main query with query extensions.

For example: ExtensionJoin=","
ExtensionSeparator (optional) refers to the delimiter between query extensions, represented by EXTENSIONSEPARATOR.

For example: ExtensionSeparator=", "
QueryExtensions (optional) refers to the extensions that must be appended to the main query, represented by EXTENSION1, EXTENSION2, and so on.

For example: QueryExtensions=["SEARCH_USER_PRIVILEGE"]

During a reconciliation operation, the connector combines all these components to the following query:

QUERY PARAM1, PARAM2... [EXTENSIONJOIN [EXTENSION1 EXTENSIONSEPARATOR EXTENSION2 EXTENSIONSEPARATOR...]]

For example:

SELECT {__UID__} FROM MYSQL.USER {filter} SEARCH_USER_PRIVILEGE

7.1.2.4 Syntax of List of Values Queries for MySQL Database

The following is the syntax of the list of values queries used for lookup field synchronization:

OBJECTTYPE = "QUERY"

For example:

__PRIVILEGES__="SELECT CONCAT(p.PRIVILEGE_TYPE, ' ON ',s.SCHEMA_NAME) SchemaPrivilege FROM INFORMATION_SCHEMA.SCHEMATA s,INFORMATION_SCHEMA.SCHEMA_PRIVILEGES p"

In this syntax:

OBJECTTYPE refers to the lookup field attribute.

For example: __PRIVILEGES__
QUERY refers to the query used for fetching a lookup field attribute.

For example: SELECT CONCAT(p.PRIVILEGE_TYPE, ' ON ',s.SCHEMA_NAME) SchemaPrivilege FROM INFORMATION_SCHEMA.SCHEMATA s,INFORMATION_SCHEMA.SCHEMA_PRIVILEGES p

7.1.3 Configuring Queries to Add Support for Custom Parameters and Lookup Fields

The connector uses preconfigured queries for connector operations such as create, delete, and search. You can add custom parameters and lookup definition fields as per your requirements.

The following sections provide the procedure to add a parameter or a lookup definition field to a query file:

7.1.3.1 Updating the Query Files

To update the query files for Oracle Database or MySQL:

Run the Oracle Identity Governance Download JARs utility to download the connector bundle JAR file from the Oracle Identity Governance database. This utility is copied into the following location when you install Oracle Identity Governance:

Note:

Before you use this utility, verify that the WL_HOME environment variable is set to the directory in which Oracle WebLogic Server is installed.

For Microsoft Windows:

OIM_HOME/server/bin/DownloadJars.bat

For UNIX:

OIM_HOME/server/bin/DownloadJars.sh

When you run the utility, you are prompted to enter the login credentials of the Oracle Identity Governance administrator, URL of the Oracle Identity Governance host computer, context factory value, type of JAR file being downloaded, and the location from which the JAR file is to be downloaded. Select ICFBundle as the JAR type.
Copy the bundle JAR file in a temporary directory.

Sample JAR file: bundle/org.identityconnectors.dbum-12.3.0.jar

Sample temporary directory: c:\temp
Run the following command to extract the connector bundle JAR file:
```
jar -xvf org.identityconnectors.dbum-12.3.0.jar
```
Note:

You can also run the WinZip or WinRAR utility to extract the contents from the JAR file.
Delete the bundle JAR file in the temporary directory.
Depending on your requirement, update the query files with new parameters as per the query syntax.
- For Oracle Database:
  
  For example, if you want to add a new parameter, tmpQuota, to the CREATE_USER provisioning query, then:
  1. Open the provisioning query file in a text editor.
    
    Sample query file: c:\temp\bundle\org.identityconnectors.dbum-12.3.0\scripts\oracle\Provisioning.queries
  2. Add the parameter, tmpQuota, to the CREATE_USER query.
    
    The following is a sample updated query:
```
CREATE_USER {
    Query="CREATE USER {__NAME__} IDENTIFIED BY {__PASSWORD__} TEMPORARY QUOTA {tmpQuota} ON {tempTableSpace}"
    QueryType="SQL"
    Parameters=["__NAME__":"Type:String,TAGS:DOUBLEQUOTES", "__PASSWORD__":"Type:GuardedString,TAGS:DOUBLEQUOTES", "tmpQuota":"Type:String", "tempTableSpace":"Type:String,Tags:EXCLUDE_VALIDATION"]
    QueryExtensions=["TABLESPACE_QUERY","TEMP_TABLESPACE_QUERY","PROFILE_QUERY","DEFAULTS_QUOTA_QUERY","TEMPTS_QUOTA_QUERY"]
}
```
  3. Save and close the query file.
- For MySQL:
  
  For example, if you want to add a new parameter, CUSTOM_ATTRIBUTE, to the CREATE_USER provisioning query, then:
  1. Open the provisioning query file in a text editor.
    
    Sample query file: c:\temp\bundle\org.identityconnectors.dbum-12.3.0\scripts\mysql\Provisioning.queries
  2. Add the parameter, CUSTOM_ATTRIBUTE, to the CREATE_USER query.
    
    The following is a sample updated query:
```
CREATE_USER {
    Query="CREATE USER {__NAME__} IDENTIFIED BY {__PASSWORD__}, {CUSTOM_ATTRIBUTE}"
    QueryType="SQL"
    Parameters=["__NAME__":"Type:String", "__PASSWORD__":"Type:GuardedString,TAGS:QUOTES", "CUSTOM_ATTRIBUTE":"Type:String,Direction:IN"]
    QueryExtensions=[]
}
```
  3. Save and close the query file.
Create a new bundle JAR file that contains the updated manifest file and the provisioning query file as follows:
1. Open the command prompt and navigate to the temporary directory c:\temp.
2. Regenerate the connector bundle (org.identityconnectors.dbum-12.3.0.jar) by running the following command:
```
jar -cvfm org.identityconnectors.dbum-12.3.0.jar META-INF/MANIFEST.MF * 
```
  Note:
  While updating the connector bundle, ensure that META-INF\MANIFEST.MF file is unchanged.
In the case of a remote connector server, copy the new bundle JAR file in the bundles directory of the remote connector server, instead of posting the JAR file to the Oracle Identity Governance database.
Run the Oracle Identity Governance Upload JARs utility to upload the regenerated connector bundle to Oracle Identity Governance database. This utility is copied into the following location when you install Oracle Identity Governance:
Note:
Before you use this utility, verify that the WL_HOME environment variable is set to the directory in which Oracle WebLogic Server is installed.
- For Microsoft Windows:
  
  OIM_HOME/server/bin/UploadJars.bat
- For UNIX:
  
  OIM_HOME/server/bin/UploadJars.sh
When you run the utility, you are prompted to enter the login credentials of the Oracle Identity Governance administrator, URL of the Oracle Identity Governance host computer, context factory value, type of JAR file being uploaded, and the location from which the JAR file is to be uploaded. Specify 4 (ICF Bundle) as the value of the JAR type.

7.1.3.2 Configuring Oracle Identity Governance for Custom Parameters

Add the custom parameters that you added to the query files to the Schema form in Oracle Identity Governance.

Note:

Skip this procedure if the parameter you added already exists as a default form field in Oracle Identity Governance.

To add the parameters that you added to the query files to the Schema form in Identity Self Service, see Providing Schema Information for Target Application or Providing Schema Information for Authoritative Application in Oracle Fusion Middleware Performing Self Service Tasks with Oracle Identity Governance.

For example, if you are using Oracle Database as the target system and you added the tmpQuota parameter to the CREATE_USER provisioning query, then update the Schema form corresponding to your application in Identity Self Service to include details of the newly added parameter. The following are some sample values:

Display Name: Temporary Quota
Target Name: tmpQuota
DataType: String
Provisioning Field?: Yes

7.2 Configuring Transformation and Validation of Data

Configure transformation and validation of user account data by writing Groovy script logic while creating your application.

You can configure transformation of reconciled single-valued user data according to your requirements. For example, you can use First Name and Last Name values to create a value for the Full Name field in Oracle Identity Governance.

Similarly, you can configure validation of reconciled and provisioned single-valued data according to your requirements. For example, you can validate data fetched from the First Name attribute to ensure that it does not contain the number sign (#). In addition, you can validate data entered in the First Name field on the process form so that the number sign (#) is not sent to the target system during provisioning operations.

To configure transformation or validation of user account data, you must write Groovy scripts while creating your application. For more information about writing Groovy script-based validation and transformation logic, see Validation and Transformation of Provisioning and Reconciliation Attributes of Oracle Fusion Middleware Performing Self Service Tasks with Oracle Identity Governance.

7.3 Configuring Action Scripts

You can configure Action Scripts by writing your own Groovy scripts while creating your application.

These scripts can be configured to run before or after the create, update, or delete an account provisioning operations. For example, you can configure a script to run before every user creation operation.

For information on adding or editing action scripts, see Updating the Provisioning Configuration in Oracle Fusion Middleware Performing Self Service Tasks with Oracle Identity Governance.

7.4 Configuring the Connector for Multiple Installations of the Target System

You must create copies of configurations of your base application to configure it for multiple installations of the target system.

The following example illustrates this requirement:

The London and New York offices of Example Multinational Inc. have their own installations of the target system, including independent schema for each. The company has recently installed Oracle Identity Governance, and they want to configure it to link all the installations of the target system.

To meet the requirement posed by such a scenario, you must clone your application which copies all configurations of the base application into the cloned application. For more information about cloning applications, see Cloning Applications in Oracle Fusion Middleware Performing Self Service Tasks with Oracle Identity Governance.