public interface ReconTransportProvider
ReconFormatProvider interface, which would then parse the extracted data/metadata.
All the methods of this interface throw ProviderException. The implementations of this
interface should utilize this fact to wrap all possible exceptions ultimately in an instance
of a ProviderException. Rich provider implementation layers are expected to be modular with
the main implementation methods calling a number of methods, which would internally be invoking
more internal layers of business logic. In such a case
it is recommended that you wrap all the possible Exceptions from all internal layers in instances
of ReconciliationTransportException. The main methods of the implementation (which
are actually the ones defined in this interface) would then just have the try-catch blocks
with catch portion for only ReconciliationTransportException and this Exception instance
could then be wrapped in a ProviderException.
One important point to consider is that in most of the cases, ReconTransportProvider
is expected to be intelligent enough to also understand the target data format (which is actually the
job of a ReconFormatProvider and parse it. Let us try to understand it better using an example.
The requirement is to write an implementation for reconciling identity accounts by picking up data from
CSV files stored in a directory on the Oracle Identity Manager server and pass the output collection of TargetRecord to the
reconciliation format provider. It is most likely to write the functionalities
assuming that reconciliation would be frequently configured to work in a paged manner. Another frequent event
is the presence of multi-valued attributes for the target parent identity
account schema. The data for such attributes for any identity account would not be stored in the files
where the single valued parent attributes are stored. It will be stored in a separate set of files,
the entries of which might be related to the parent file entries through some method. Therefore, if the
ReconTransportProvider implementation is supposed to function for paged reconciliation, it should
bring all records in the page with all their complete information which could be the values for their
single-valued as well as multi-valued attributes. Thus, it becomes the responsibility of the transport
provider implementation itself to understand the format of the data present in these files so that it
is capable of relating the parent records in one file to their child records in other files.| Modifier and Type | Method and Description |
|---|---|
java.lang.String |
end()
This method resets the provider to start again.
|
TargetRecord[] |
getFirstPage(int pagesize,
java.lang.String timestamp)
If reconciliation is configured to be paged, then this method fetches the first page of data.
|
TargetSchema |
getMetadata()
This method fetches the metadata definition of identity accounts, from the target system.
|
TargetRecord[] |
getNextPage(int pagesize)
If reconciliation is configured to be paged, this method fetches the pages of data next to
what is fetched by
ReconTransportProvider.getFirstPage(int, String). |
void |
initialize(Provider providerdata)
This method initializes the provider
|
void initialize(Provider providerdata) throws ProviderException
providerdata - A value object that represents a provider instance.
It can also be considered as a collection of provider parameter specifications.
Provider parameters, runtime as well as design could be obtained from this value object instance.
Check the API documentation for Provider for more details.ProviderExceptionProviderTargetSchema getMetadata() throws ProviderException
TargetSchema for more details.ProviderExceptionTargetSchemaTargetRecord[] getFirstPage(int pagesize, java.lang.String timestamp) throws ProviderException
pagesize - Page size. Provider implementations need not honor the page size arguments and the
callers must deal with the size of returned records. For non-paged reconciliation,
the pagesize value provided by the generic technology connector framework in the provider invocation is -1.timestamp - Timestamp for the last reconciliation execution. It can be null for the very first
reconciliation, or if ReconTransportProvider.end() didn't return any timestamp.TargetRecord for more details.ProviderExceptionTargetRecordTargetRecord[] getNextPage(int pagesize) throws ProviderException
ReconTransportProvider.getFirstPage(int, String). For non-paged reconciliation (i.e. a pagesize of -1),
this method should ideally return a null value. If reconciliation execution is executing
for a particular page of records, by one thread and another thread wants to initiate reconciliation,
the business logic should reset the current state and go to the first page.pagesize - Page size. Provider implementations need not honor the page size arguments and the
callers must deal with the size of returned records. For non-paged reconciliation,
the pagesize value provided by the generic technology connector framework in the provider invocation is -1.TargetRecord for more details. When running out of records, or reached the end,
this Array would be null.ProviderExceptionTargetRecordjava.lang.String end()
throws ProviderException
ProviderException