How to: Improve Business Connectivity Services Solution Performance When Using the Cache
Last modified: June 30, 2010
Applies to: SharePoint Server 2010
In this article
Using a version field to minimize trips to the external data source
Only enable associations if you absolutely need them
If you need related data, consider using two subscriptions instead of one
Specify the items to synchronize by using explicit identities in the subscription
Specify filters to reduce the amount of data that is downloaded by the client application
When designing a Business Connectivity Services solution that will use the cache, you can keep the following best practices in mind to make the best use of the cache and to ensure optimal performance of your application:
Make use of a version field if available to minimize trips to the external application.
Only enable associations if needed by the application and make sure that end users do not enable associations by mistake.
If you need related data, consider using two subscriptions instead of one subscription with a subscription association.
Specify the items to synchronize by using explicit identities in the subscription.
Specify filters to reduce the amount of data that is downloaded by the client application.
Let’s look each of the above best practices in detail.
By using a version field in the external data source, you can greatly minimize the calls to the external data source. A version field can be an incrementing number field that denotes the version of the entity instance or a LastModified timestamp that specifies when the entity instance was last updated in the external data source. If such a field is available, it should be part of the return parameter of the Finder and SpecificFinder methods in the model. If a version field is available, then the sync process gets both ID and version from the external application and only makes SpecificFinder calls if the version is different from what is in the cache.
If a subscription contains enabled associations, the sync process populates the cache with the related entity instances. 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. Therefore, you should only enable associations if you absolutely need them as they are a lot of overhead in the cache and may affect the performance of the application severely.
As mentioned in the above topic, associations add a lot of overhead in the cache and may affect the performance of the application severely. If you need related data in your application, 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.
If you know exactly which items to synchronize, you can just add their identities to the subscription individually. This is much easier to do programmatically because you have to put the serialized identity on the subscription XML file.
To get the serialized identity, you instantiate an Identity object with the appropriate identifier values, and call its Serialize method. For more information, see the documentation for Identity.Serialize().
After you have the identity’s serialized string, you add it in an <Identity> tag within the <Identities> tag, as is shown in an example later in this topic (see Example.)
The obvious way to optimize synchronization is to reduce the amount of data that is downloaded by the client, and the easiest way to do this is by using filters. The filters supported by the synchronization framework that can be used to reduce the number of items downloaded are Wildcard, Comparison, and Limit filters. For example, you can use a Wildcard filter to download all employees whose names start with the letter "M" by using "M*" as the filter value. Or you can select all customers that have their zip code equal to "98052" by using a comparison filter. A Limit filter can be used to limit the number of products to 100.
The following is an example of a subscription whose explicit identities are above 11003 and 11020, and a filter that returns only customers with CustumerIDs greater than 11050.
<?xml version="1.0" encoding="utf-8"?> <Subscription LobSystemInstanceName="AdventureWorksContosoLOBInstance" EntityNamespace="AdventureWorksContoso" EntityName="Customer" Name="AdventureWorksContosoCustomerSubscription" View="GetCustomerById" IsCached="true" RefreshIntervalInMinutes="360" xmlns="http://schemas.microsoft.com/office/2006/03/BusinessDataCatalog"> <Identities> <Identity>i+yoAAA==</Identity> <Identity>iDCsAAA==</Identity> </Identities> <Queries> <Query Name="AdventureWorksContosoCustomerQuery" MethodInstanceName="GetCustomers" DefaultDisplayName="Customer Read List" RefreshIntervalInMinutes="180" IsCached="true" Enabled="true"> <FilterValues> <FilterValue FilterDescriptorName="MinCustomerId" FilterIndex="0" Type="System.Int32">11050</FilterValue> </FilterValues> </Query> </Queries> </Subscription>
The following are some important notes: