How Is the Business Connectivity Services Client Cache Populated?
Last modified: November 02, 2009
Applies to: SharePoint Server 2010
In the cache, the identities and instance data are stored in separate locations. The identifiers of all entity instances belonging to all the subscriptions installed for the user on the client are stored in one central location. The entity instance data for each entity in a subscription such as ID, Name, Address, etc. are stored in a separate location. For example, if the user has two subscriptions, Customer and Accounts, and each one has 10 entity instances, then all 20 identifiers are centrally stored in one location in the cache. The Customer data such as ID, Name, Address that belong to the subscription are stored in a separate location. The Accounts data is stored in a yet another location in the cache. If the user modifies the subscription to add a query which returns five of the 10 Customer entity instances used by the first query in the subscription, the cache does not duplicate the data for those entity instances again.
To populate the cache for a subscription, the BCS Sync process makes several calls to the external application. For each query defined in the subscription, it makes a Finder call to the external application. If the Finder returns the full view, no additional calls are made and the cache is populated with the data about each entity instance. However, if the Finder does not return the full view, then it populates the cache with the IDs from the Finder. If any of the IDs already exist in the cache, they are not duplicated. Then for each identifier that is returned by the query, it makes a SpecificFinder call to get the fields returned by the query.
Then it makes as many SpecificFinder calls as there are explicit identities in the subscription and populates the cache with the entity instances that are returned by the method instance. Finally, it populates the cache with related entity instances if there are any enabled associations in the subscription. To do this, it makes as many Associate method instance calls as there are entity instances in the cache for this subscription. This returns the IDs of the related entity instances. Then it calls the SpecificFinder on each of the returned IDs to fetch the other fields.
You should consider creating two subscriptions, one for Customers and another for Orders instead of using subscription associations. This will result in less number of calls to the external application and increase application throughput.