20 Creating Custom Providers for Generic Technology Connectors

You will need to create custom providers to address provider requirements that cannot be addressed by the predefined providers. This chapter discusses the steps to create custom providers.

Topics in this chapter include:

Role of Providers
Creating Custom Providers
Reusing Providers
Deploying the Custom Providers

20.1 Role of Providers

The following sections discuss the role of providers during generic technology connector creation and use:

Role of Providers During Generic Technology Connector Creation
Role of Providers During Reconciliation
Role of Providers During Provisioning

20.1.1 Role of Providers During Generic Technology Connector Creation

You create a generic technology connector by using the Administrative and User Console. Defining data sets and the flow of data between these data sets is one of the tasks of the connector creation procedure. The metadata detection process facilitates this task.

In the generic technology connector context, the term metadata refers to the set of identity fields that constitute the user account information. The term metadata detection refers to the reading and parsing of target system metadata by the providers.

The metadata detection feature is supported for all the provider types. In other words, when you create a custom provider, you can incorporate into the provider the capability to read metadata.

Note:

The Javadocs use the term metadata definition instead of metadata detection.

Figure 20-1 shows the metadata detection process.

Figure 20-1 Metadata Detection Process

The following sequence of steps describe the process of metadata detection. This sequence of steps is based on the assumption that you select both the Reconciliation and Provisioning options while creating the generic technology connector. If you do not select either option, the corresponding steps are not performed.

20.1.2 Role of Providers During Reconciliation

Figure 20-2 shows the role of providers during reconciliation.

Figure 20-2 Role of Providers During Reconciliation

The following steps describe the role of providers during reconciliation:

If an instance of the reconciliation transport provider is not available in cache, the initialize method is called to create an instance of that provider.
If an instance of the reconciliation format provider is not available in cache, the initialize method is called to create an instance of that provider.
While using the Administrative and User Console to create a generic technology connector, you can specify a batch size for the reconciliation run. By using this parameter, you break the total number of records that the reconciliation engine fetches from the target system, during each reconciliation run, into batches. The default value of this parameter is All.

If you do not specify a batch size, at this stage of reconciliation, the getFirstPage method of the reconciliation transport provider is called to fetch the entire set of target system records that are ready for reconciliation.

If you specify a batch size, the getFirstPage method of the reconciliation transport provider is called to fetch the first batch of target system records for reconciliation. The getNextPage method of the same provider is called (multiple times, if required) if there are more batches of target system records for reconciliation.
The parseRecords method of the reconciliation format provider is called to process each record of the TargetRecord value objects array. The output of this method is an array of OIMRecord value objects.
While creating the generic technology connector, if you select validation providers to validate data while it is in transit from the Source data sets to the reconciliation staging data sets:
1. An instance of the validation provider is created.
2. The validate method of each validation provider is run on the specified attribute of each record of the OIMRecord value objects array.
If you do not select validation providers while creating the generic technology connector, Step 5 is not performed and each element of the OIMRecord value objects array is passed on to Step 6.
While creating the generic technology connector, if you selected transformation providers to modify data that is in transit from the Source data sets to the reconciliation staging data sets:
1. An instance of the transformation provider is created.
2. The transformData method of the transformation providers processes the OIMRecord value objects array that was generated as the output of one of the following:
  - The validate method of each validation provider (if you selected validation providers)
  - The parseRecords method of the reconciliation format provider (if you did not select validation providers)
If you do not select transformation providers while creating the generic technology connector, Step 6 is not performed and each element of the OIMRecord value objects array from the previous step (Step 4 or 5) is passed on to Step 7.
At this stage, the OIMRecord value objects array corresponds to the reconciliation staging data sets discussed in Section 18.2.1, "Providers and Data Sets of the Reconciliation Module" . Each element of the OIMRecord value objects array is passed on to the reconciliation engine.
At the end of the reconciliation procedure, the end method of the reconciliation transport provider is called. This method returns a string value, which the generic technology connector framework stores in the Timestamp parameter of the IT resource. The framework uses the Timestamp parameter to track the stage at which the reconciliation run was completed.

20.1.3 Role of Providers During Provisioning

Figure 20-3 shows the role of providers during provisioning.

Figure 20-3 Role of Providers During Provisioning

The following steps describe the role of providers during provisioning:

If an instance of the provisioning transport provider is not available in cache, the initialize method is called to create an instance of that provider.
If an instance of the provisioning format provider is not available in cache, the initialize method is called to create an instance of that provider.
The generic technology connector adapter is one of the connector objects created when you create the generic technology connector. This adapter converts the provisioning data record into a hashmap of name-value pairs. This hashmap contains process instance data. Each hashmap is converted into an element of the OIMRecord value object. At this stage, the OIMRecord value object corresponds to the Oracle Identity Manager data sets discussed in Section 18.2.3, "Oracle Identity Manager Data Sets".
While creating the generic technology connector, if you select transformation providers to modify data that is in transit from the Oracle Identity Manager data sets to the provisioning staging data sets:
1. An instance of the transformation provider is created.
2. The transformData method of the transformation providers processes the specified attributes of the input OIMRecord value object and converts these records into an output OIMRecord value object. At this stage, the OIMRecord value object corresponds to the provisioning staging data sets discussed in Section 18.2.2, "Providers and Data Sets of the Provisioning Module" .
The formatData method of the provisioning format provider is called to process the OIMRecord value object. The output of this process is the TargetOperation value object.
The sendData method of the provisioning transport provider is called to send the TargetOperation value object to the target system.
If the provisioning operation is a Create request, the outcome is one of the following events:
- On successful completion of the Create operation on the target system, the ID field value assigned to the newly created user account is returned by the sendData method. This value is passed on to the generic technology connector framework, which posts this value to the database.
- If the ID field value is not returned, it is assumed that the Create operation has failed. An error message is displayed on the Administrative and User Console.
- If the operation fails at any stage after the name-value pairs are created, an error message is displayed on the Administrative and User Console.
If the provisioning operation is an Update or Delete request, the ID field is one of the name-value pairs. When this type of provisioning request is sent, the outcome is one of the following events:
- If the operation fails at any stage after the name-value pairs are created, an error message is displayed on the Administrative and User Console.
- On successful completion of the Update or Delete operation, the ID field value may or may not be returned depending on the implementation of the provisioning transport provider.
  
  In either case, the generic technology connector framework does not need the ID field value.

20.2 Creating Custom Providers

The procedure to create custom providers consists of the following steps:

Determining Provider Requirements
Identifying the Provider Parameters
Developing Java Code Implementations of the Value Objects
Developing Java Code Implementations of the Provider SPI Methods
Developing Java Code for Logging and Exception Handling
Creating the Provider XML File
Creating Resource Bundle Entries for the Provider
Deploying the Provider

20.2.1 Determining Provider Requirements

Guidelines for determining provider requirements are as follows:

Determining the Reconciliation Provider Requirements
Determining the Provisioning Provider Requirements

20.2.1.1 Determining the Reconciliation Provider Requirements

Apply the following guidelines to determine the reconciliation provider requirements:

If you want to use the target system only as a source of user account information for Oracle Identity Manager, you need only the reconciliation transport provider and reconciliation format provider. You do not need the provisioning transport provider and provisioning format provider.

If you are going to include the reconciliation module in the generic technology connector, you must include both the reconciliation transport provider and the reconciliation format provider, even if you do not need any one of these providers.

The function of the reconciliation format provider is to convert target system data into a format that is supported by Oracle Identity Manager. Even if the target system generates data in a format supported by Oracle Identity Manager, you must include the reconciliation format provider when you create the generic technology connector.
You must create custom providers only to address provider requirements that are not addressed by the predefined providers.

The types of providers you must include in the generic technology connector depend on the data formats and data transport mechanisms that your target system supports. If any combination of the data formats and data transport mechanisms are compatible with any combination of the predefined providers, you need not create custom providers.

For example, if your target system can generate reconciliation data files in comma-delimited format, you can use the shared drive reconciliation transport provider and CSV reconciliation format provider. You need not create custom reconciliation providers.

See Also:

Section 20.3, "Reusing Providers"

20.2.1.2 Determining the Provisioning Provider Requirements

Apply the following guidelines to determine the provisioning provider requirements for the provisioning module:

If you want to use the target system only as a target for provisioning operations initiated on Oracle Identity Manager, you need only the provisioning transport provider and provisioning format provider. You do not need the reconciliation transport provider and reconciliation format provider.

If you are going to include the provisioning module in the generic technology connector, you must include both the provisioning transport provider and the provisioning format provider, even if you do not need any one of these providers. This guideline is illustrated by the following example:

The function of the provisioning format provider is to convert Oracle Identity Manager data into a format that is supported by the target system. Even if the target system supports the output data format of Oracle Identity Manager, you must include the provisioning format provider when you create the generic technology connector.
You must create custom providers only to address provider requirements that are not addressed by the predefined providers.

The types of providers you must include in the generic technology connector depend on the data formats and data transport mechanisms that your target system supports. If any combination of the data formats and data transport mechanisms are compatible with any combination of the predefined providers, you need not create custom providers.

For example, if your target system is a Web service that can accept and parse SPML-based provisioning requests packaged in SOAP messages, you can use the SPML provisioning format provider and Web Services provisioning transport provider. You need not create custom provisioning providers.

See Also:

Reusing Providers

20.2.2 Identifying the Provider Parameters

Provider parameters are the values that a provider must have in order to perform its intended function. For example, a provisioning transport provider that copies provisioning request files to a target system server will need the connection parameters required to connect to the target system.

While creating a generic technology connector, you specify values for the parameters of the providers that you select for the generic technology connector.

For the custom provider that you are creating, you must identify all the parameters required for the provider to function. You must also categorize these parameters as run-time and design parameters.

A run-time parameter represents a value that is not constrained by the design of the provider. For example, the location of the directories containing data files that you want to reconcile is a run-time parameter. A design parameter represents a value or set of values that is defined as part of the provider design. For example, the character set encoding formats that can be parsed by a reconciliation format provider are a design parameter for that provider.

20.2.3 Developing Java Code Implementations of the Value Objects

Develop the Java code implementations of the value objects listed in Table 20-1. As described earlier, these value objects are used at various stages of provider operations.

Note:

You need not develop Java code implementations of the value objects that you are not going to include in the generic technology connector.

Table 20-1 Value Objects Used During Provider Operations

Area of Use	Value Object	Javadocs Package
Metadata Detection	`TargetSchema`	`com.thortech.xl.gc.vo.designtime`
	`OIMSchema`	`com.thortech.xl.gc.vo.designtime`
Provisioning	`TargetOperation`	`com.thortech.xl.gc.vo.runtime`
Reconciliation	`TargetRecord`	`com.thortech.xl.gc.vo.runtime`
	`OIMRecord`	`com.thortech.xl.gc.vo.runtime`

20.2.4 Developing Java Code Implementations of the Provider SPI Methods

Develop the Java code implementations of the SPI methods that are used during provider operations. As described earlier, these SPI methods are called at various stages of provider operations. See the Package com.thortech.xl.gc.spi page of the Javadocs for links to information about the SPI methods of each provider.

Note:

You need not develop Java code implementations of SPI methods for the providers that you are not going to include in the generic technology connector.

20.2.5 Developing Java Code for Logging and Exception Handling

Oracle recommends that you to incorporate logging in the Java code implementations of the value objects and SPI methods. By doing this, you can simplify troubleshooting errors that may occur when you use the providers.

The logging modules for the generic technology connector framework are an extension of the logging functionality of Oracle Identity Manager. Table 20-2 lists the modules that are specific to the supported provider types.

Table 20-2 Logging Modules Specific to the Supported Provider Types

Logging Module	Functional Module of the Generic Technology Connector Framework
`XELLERATE.GC.PROVIDER.PROVISIONINGFORMAT`	Provisioning format provider
`XELLERATE.GC.PROVIDER.PROVISIONINGTRANSPORT`	Provisioning transport provider
`XELLERATE.GC.PROVIDER.RECONCILIATIONTRANSPORT`	Reconciliation transport provider
`XELLERATE.GC.PROVIDER.RECONCILIATIONFORMAT`	Reconciliation format provider
`XELLERATE.GC.PROVIDER.TRANSFORMATION`	Transformation Provider
`XELLERATE.GC.PROVIDER.VALIDATION`	Validation Provider

See Oracle Fusion Middleware Java API Reference for Oracle Identity Manager for information about incorporating exception handling in the custom provider.

20.2.6 Creating the Provider XML File

The provider XML file contains the data required to register the provider with the generic technology connector framework. You must create the provider XML file. Table 20-3 describes the elements that you can include in the provider XML files for custom providers.

Note:

You can use a single provider XML file to define any number of providers. Alternatively, you can create a provider XML file for each provider that you create.

You must ensure that the provider XML file adheres to the schema definition provided in MDS. The locations for schema and provider definition XML files are as follows:

PROVIDER_DEF_XSD_LOCATION = "/db/GTC/Schema";

PROVIDER_DEF_XML_LOCATION = "/db/GTC/ProviderDefinitions";

Table 20-3 Elements of the Provider XML File

Element	Description
`Provider`	Root element of the provider XML file
`Reconciliation`	Parent element of the configuration elements that are used to describe reconciliation providers
`Provisioning`	Parent element of the configuration elements that are used to describe provisioning providers
`Transformation`	Parent element of the configuration elements that are used to describe transformation providers
`Validation`	Parent element of the configuration elements that are used to describe validation providers
`ReconTransportProvider`	Parent element of the configuration elements that are used to describe a reconciliation transport provider This element has the following attributes: `name`: Name of the provider `class`: Name of the Java class of the provider implementation
`ReconFormatProvider`	Parent element of the configuration elements that are used to describe a reconciliation format provider This element has the following attributes: `name`: Name of the provider `class`: Name of the Java class of the provider implementation
`ProvFormatProvider`	Parent element of the configuration elements that are used to describe a provisioning format provider This element has the following attributes: `name`: Name of the provider `class`: Name of the Java class of the provider implementation
`ProvTransportProvider`	Parent element of the configuration elements that are used to describe a provisioning transport provider This element has the following attributes: `name`: Name of the provider `class`: Name of the Java class of the provider implementation
`TransformationProvider`	Parent element of the configuration elements that are used to describe a transformation provider This element has the following attributes: `name`: Name of the provider `class`: Name of the Java class of the provider implementation
`ValidationProvider`	Parent element of the configuration elements that are used to describe a validation provider This element has the following attributes: `name`: Name of the provider `class`: Name of the Java class of the provider implementation
`Configuration`	Parent element of the configuration elements of any type of provider
`Parameter`	Element that provides information about a parameter of a provider The `Parameter` element has the following attributes: `type`: Type of parameter, either `Runtime` or `Designtime` `datatype`: Data type of parameter, either `String` or `Boolean`. Any parameter whose data type is not Boolean must be represented as a string. `required`: Specifies whether or not the parameter is mandatory `encrypted`: Specifies whether or not the parameter display must be encrypted `name`: Name of the parameter `datalength`: Character length of the parameter value
`DefaultAttribute`	Child element of the `Configuration` element This element must be included only in the `ProvFormatProvider` element. It has the following attributes: `datatype`: Data type of parameter, either `String` or `Boolean`. Any parameter whose data type is not Boolean must be represented as a string. `name`: Name of the parameter `encrypted`: Specifies whether or not the parameter display must be encrypted `size`: Size of the default attribute Some data attributes included in the provisioning request are essential for the provisioning operation to be successfully completed. Because the provisioning format provider generates the final provisioning input data format, the definition of this provider must include these mandatory data attributes. Therefore, if such attributes are required by a target system, they must be defined by using the `DefaultAttribute` element in the provisioning format provider XML file.
`Response`	Child element of the `Configuration` element This element must be included only in the `ProvFormatProvider,` `ProvTransportProvider,` `TransformationProvider,` and `ValidationProvider` elements. It represents the response returned from the providers that are called by the provisioning engine. This response is displayed on the Oracle Identity Manager Administrative and User Console. This element has the following attributes: `code`: Corresponds to the Oracle Identity Manager process task response code to be generated `description`: Corresponds to the description of the Oracle Identity Manager process task response code to be generated Note: For a provisioning format provider or provisioning transport provider, you must ensure that the sum of the number of characters of the `name` attribute of the `ProvFormatProvider` or `ProvTransportProvider` element and the number of characters of the `Response` element is less than or equal to 70. If the sum of the number of characters exceeds 70, the response code cannot be stored in the database and an error is thrown.

20.2.7 Creating Resource Bundle Entries for the Provider

A resource bundle is a file containing locale-specific text strings. At run time, Oracle Identity Manager reads these text strings and displays them as GUI element labels and messages on the Administrative and User Console. The file extension of a resource bundle is .properties.

During installation of Oracle Identity Manager, resource bundles for each of the supported languages are copied to the Oracle Identity Manager server. These include the resource bundles for the predefined providers.

For a custom provider, you must create resource bundle entries for each locale that you plan to use. The following is a summary of the steps involved in creating a resource bundle:

Open a new file in a text editor.
In this file, create entries for the following text strings:
Note:
- In the resource bundle, you must provide localized text for the part of each line that follows the equal sign (=).
- The Provider_Type, Parameter_Name, and RESPONSE_CODE values mentioned in this section must be the same as the values you specify in the provider XML file while performing the procedure described in Section 20.2.6, "Creating the Provider XML File".
- Provider names
  
  The format for provider names is as follows:
```
gc.provider.Provider_Type.Provider_Name=Label_string_in_the_required_language
```
  The following is an English-language example of the provider name entry for a provisioning format provider:
```
gc.provider.ProvFormatProvider.SPML=SPML
```
- Provider parameter labels and description
  
  The format for provider parameter labels and parameter descriptions is as follows:
```
gc.Provider_Type.Provider_Name.Parameter_Name.label=Parameter_label_in_the_required_language
gc.Provider_Type.Provider_Name.Parameter_Name.description=Parameter_description_in_the_required_language
```
  The following is an English-language example of the provider parameter label and parameter description entries for a provisioning format provider:
```
gc.ProvFormatProvider.SPML.targetID.label=Target ID
gc.ProvFormatProvider.SPML.targetID.description=Target ID of the provisioning target
```
- Response codes and descriptions
  
  The format for response codes and descriptions is as follows:
```
GC.GCPROV.PROVIDER_TYPE.PROVIDER_NAME.RESPONSE_CODE=Response_code_in_the_required_language
GC.GCPROV.PROVIDER_TYPE.PROVIDER_NAME.RESPONSE_CODE.description=Description_in_the_required_language
```
  The following is an English-language example of the response code and description entries for a provisioning format provider:
```
GC.GCPROV.ProvFormatProvider.SPML.SPML_VELOCITY_PROPERTIES_NOT_READ=SPML Velocity Properties Not Read
GC.GCPROV.ProvFormatProvider.SPML.SPML_VELOCITY_PROPERTIES_NOT_READ.description=Necessary SPML template properties could not be read.
```
- Metadata detection error messages
  
  The format for metadata detection error messages is as follows:
```
gc.error.Provider_Type.Provider_Name.ERROR_CODE=Error_Description
```
  Here, ERROR_CODE must be the same as the value of the errorCode string passed as an argument to the constructor of the exception class. For example, the following is one of the constructors of the ReconciliationTransportException class:
```
ReconciliationTransportException(java.lang.String errorCode, java.lang.String isMessage)
```
  You must add lines in the resource bundle for all possible values of the errorCode string.
  
  The following is an English-language example of the metadata detection error message for a reconciliation transport provider:
```
gc.error.ReconTransportProvider.SharedDrive.NO_READ_FILE=There are no readable files to detect metadata.
```
Save and close the resource bundle.

20.2.8 Deploying the Provider

To deploy the provider:

Deploy the JAR files as follows:
1. Compile and package all the Java code files in a JAR file.
2. Copy the JAR file into the following directory:
```
OIM_HOME/JavaTasks
```
  In addition, upload the JAR files to Oracle Identity Manager database. See "Deploying the Custom Providers" for details.
Note:

In a clustered environment, you must copy each file that you create to the corresponding directory on each node of the cluster.
Deploy the provider XML files as follows:
1. Upload the provider XML file to MDS at the following location:
  
  PROVIDER_DEF_XML_LOCATION = "/db/GTC/ProviderDefinitions":
2. Restart Oracle Identity Manager.
3. To check if the provider XML file has been correctly registered:
  
  i. Log in to the Administrative and User Console.
  
  ii. Expand Generic Technology Connector, and click Create. If there are any errors in the provider XML file, an error message is displayed.
  
  If an error message is displayed, fix the problem in the XML file, restart Oracle Identity Manager, and repeat Steps i and ii.
  
  Repeat this procedure until no error messages are displayed when you click Create.
Deploy the provider resource bundles as follows:
1. Upload the resource bundles to the MDS by using the UploadResourceBundles.sh utility present in the OIM_HOME/bin/ directory. See "Upload Resource Bundle Utility" for information about running the utility.
2. For the new resource bundle entries to take effect, either run the PurgeCache script or restart the application server. See "Purging the Cache" in the Oracle Fusion Middleware Administrator's Guide for Oracle Identity Manager for information about running the PurgeCache utility.

20.3 Reusing Providers

Format providers and transport providers work in pairs. During reconciliation, the output of the reconciliation transport provider is passed on to the reconciliation format provider. During provisioning, the output of the provisioning format provider is passed on to the provisioning transport provider. This means that the implementation of the transport providers and format providers is linked through the implementation of the value objects that are passed between them. This dependency forms the basis of guidelines on reusing format providers and transport providers.

In contrast, a validation provider or transformation provider does not have any such dependency on other providers. Therefore, there are no guidelines on reusing validation Providers and transformation Providers. You can reuse both predefined and custom transformation and validation providers, because their action is not specific to the data format or data transport mechanism of the target system.

Guidelines on reusing format providers and transport providers are dividing into the following sections:

Reusing Reconciliation Providers
Reusing Provisioning Providers

20.3.1 Reusing Reconciliation Providers

As described in Section 20.1.2, "Role of Providers During Reconciliation", the TargetRecord value object is used to exchange data between the reconciliation transport provider and the reconciliation format provider. The reconciliation transport provider creates an array of TargetRecord value objects for the target system records fetched during reconciliation. The reconciliation format provider processes the data in the value objects array and passes it on to the reconciliation engine.

Suppose the operating environment of your organization contains two target systems, TS1 and TS2. TS1 offers a Web-based interface for extracting data during reconciliation. TS2 provides APIs for enabling other applications to read data from its identity store. Both target systems support the same data format. If you want to reconcile user data from both target systems, you must create one generic technology connector for each target system. For each generic technology connector, you must create a reconciliation transport provider. However, instead of creating a reconciliation format provider for each generic technology connector, you can create and reuse a single reconciliation format provider. Similarly, if TS1 and TS2 supported the same data transport mechanism (even if they do not support the same data format), you can reuse the reconciliation transport provider and create different reconciliation format providers.

If you want to reuse a reconciliation transport provider, you must ensure that the implementation of the TargetRecord value object does not contain code that is specific to the function performed by the reconciliation format provider. If you want to reuse a reconciliation format provider, you must ensure that the implementation of the TargetRecord value object does not contain code that is specific to the function performed by the reconciliation transport provider.

Reusing the Predefined Reconciliation Providers

The implementation of the shared drive reconciliation transport provider and CSV reconciliation format provider is such that these predefined providers are built for a fixed combination of data formats and a single data transport mechanism. The shared drive reconciliation transport provider reads data from flat files and passes an array of TargetRecord value objects to the CSV reconciliation format provider.

Implementation of the shared drive reconciliation transport provider is based on two factors: paged reconciliation and multivalued (child) data reconciliation. These factors require the provider to be able to parse target system data before it can create an array of TargetRecord value objects. In other words, the ability of the shared drive reconciliation transport provider to parse certain types of target system data and the ability of the CSV reconciliation format provider to use only the output provided by the shared drive reconciliation transport provider makes them interdependent. Therefore, the parameters of the CSV reconciliation format provider are bundled along with those of the shared drive reconciliation transport provider.

For this reason, you cannot use the shared drive reconciliation transport provider with a custom reconciliation format provider and you cannot use the CSV format provider with a custom reconciliation transport provider.

20.3.2 Reusing Provisioning Providers

As described in Section 20.1.3, "Role of Providers During Provisioning", the TargetOperation value object is used to exchange data between the provisioning transport provider and the provisioning format provider. The provisioning format provider creates a TargetOperation value object out of the provisioning data to be sent to the target system. The provisioning transport provider passes this value object to the target system.

Suppose the operating environment of your organization contains two target systems, TS1 and TS2. TS1 offers a Web-based interface for accepting provisioning request data. TS2 provides APIs for enabling provisioning data to be written to the identity store. Both target systems support the same data format. If you want to perform provisioning operations on both target systems, you must create one generic technology connector for each target system. For each generic technology connector, you must create a provisioning transport provider. However, instead of creating a provisioning format provider for each generic technology connector, you can create and reuse a single provider.

If TS1 and TS2 supported the same data transport mechanism but different data formats, you can reuse the provisioning transport provider and create different provisioning format providers.

If you want to reuse the provisioning transport provider, you must ensure that the implementation of the TargetOperation value object does not contain code that is specific to the function performed by the provisioning format provider. If you want to reuse the provisioning format provider, you must ensure that the implementation of the TargetOperation value object does not contain code that is specific to the function performed by the provisioning transport provider.

Reusing the Predefined Provisioning Providers

If the target system is a Web service, you can use the Web Services provisioning transport provider along with any custom provisioning format provider that you create. This is illustrated by the following example:

As mentioned earlier in this guide, the SPML provisioning format provider supports only a subset of the provisioning operations that are described in the SPML specification. You can develop a custom provisioning format provider that supports all the SPML provisioning operations. If the target system is a Web service, you can use the Web Services provisioning transport provider to carry SPML requests from your custom provisioning format provider to the target system.

Similarly, you can use the SPML provisioning format provider along with a custom provisioning transport provider to send SPML requests to an SPML-based target system.

The following is the implementation of the TargetOperation value object that is created by the SPML provisioning format provider and used as an input for the Web Services provisioning transport provider:

com.thortech.xl.gc.impl.prov.WSTransportTargetOperation

See Oracle Fusion Middleware Java API Reference for Oracle Identity Manager for information about this class.

If you want to reuse the SPML provisioning format provider, you must create a custom transport provider that can accept an instance of this class as input and call the relevant set method. Similarly, if you want to reuse the Web Services provisioning transport provider, you must create a custom provisioning format provider that can create an instance of this class and call the relevant get method.

20.4 Deploying the Custom Providers

To deploy the custom providers:

Upload the Provider definition XML file to the MDS location /db/GTC/ProviderDefinitions. Oracle Identity Manager provides utilities to export/import data to and from MDS repository.

See Chapter 33, "MDS Utilities and User Modifiable Metadata Files" for information about the MDS utilities.
The provider resource bundles and JAR files need to be uploaded to Oracle Identity Manager database. Utilities are available in OIM_HOME/bin/ directory for uploading resource bundles and JAR files to Oracle Identity Manager database.

See Chapter 35, "Upload JAR and Resource Bundle Utilities" for information about the upload resource bundles and JAR utilities.