The Integration Repository is designed to help integrate Oracle Commerce Platform applications with remote systems. It assumes that your business maintains data on a remote system and you want to expose and possibly modify this data within your Oracle Commerce Platform application in the form of Oracle Commerce Platform repository items. There are several ways you can set up such an integration, depending on the demands of your Oracle Commerce Platform application and the characteristics of the remote system and the data maintained there. Here are four possible approaches for getting remote data. Which approach to choose depends on balancing your need for consistent data and best performance.
Remote Only
In this case, the data is maintained only on the remote system. Each time that the Oracle Commerce Platform application needs to access the data, a command is issued to the remote system. The local repository is configured to use transient repository items.
Advantages:
You are always sure that the data returned to the Oracle Commerce Platform is up to date.
Disadvantages:
If the remote system is unavailable, then no form of the data is available to the Oracle Commerce Platform application.
Frequent queries to the remote system can affect the performance of the remote system, which may also be serving functions other than the Oracle Commerce Platform application.
The need to query the remote system will tend to slow the performance of the Oracle Commerce Platform application.
See Configuring the Remote-Only Model for more details about how this approach could be configured.
Remote then Local
In this case, the primary source for the data is the remote system. Each time that the Oracle Commerce Platform application needs to access the data, a command is issued to the remote system. If the command fails to return, then the command is issued to the local repository.
Advantages:
You are sure that the data returned to the Oracle Commerce Platform is up to date, except in cases where the remote system is unavailable. In addition, the existence of the local repository can provide a backup form of the data, in case the remote system is inaccessible.
Disadvantages:
Frequent queries to the remote system can affect the performance of the remote system, which may also be serving functions other than the Oracle Commerce Platform application.
The need to query the remote system will tend to slow the performance of the Oracle Commerce Platform application.
See Configuring the Remote-then-Local Model for more details about how this approach could be configured.
Local then Remote
In this case, a version of the data is maintained in a local repository. Only if the data is not available locally, or if the local copy has been marked invalid or has expired, does the Integration Repository query the remote system for the data.
You might use this integration model if you need to make sure the system is as fast as possible, and you do not have to worry so much about data consistency because the data does not change that often. When the remote system is down, you can block changes to the data (updates, creating and removing items), but you make the data available from the local system, so that your users can continue to work.
Advantages:
The Oracle Commerce Platform’s performance is as fast as possible.
There are fewer queries to the remote system, so less burden is placed on the remote system.
You can configure the lifetime of items in the local repository, so you can be assured that the data is not out of date by more than a specified amount of time.
Disadvantages:
You have less assurance that the data returned from the local repository is consistent with the data in the remote system.
See Configuring the Local-then-Remote Model for more details about how this approach could be configured.
Local Only
This approach does not need to use the Oracle Commerce Platform Integration Framework. In this case, we periodically dump data from the remote system into the relational database used by the Oracle Commerce Platform application. The data is accessed by the SQL repository. Since this approach does not need to issue commands against the remote system in real time, there does not need to be an Integration Repository.
Advantages:
The Oracle Commerce Platform’s performance is as fast as possible.
The only interaction with the remote system is a periodic batch data transfer, which probably can be scheduled to place a minimal burden on the remote system.
Disadvantages:
The local repository is not updated in real time, so any changes in the remote system are reflected in the local repository and therefore in your Web application only after the scheduled data transfer.
