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 don’t 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:
ATG’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.