Now that LightSwitch in Visual Studio 2012 supports the ability to consume OData feeds, there are a wide variety of feeds that can be used to build interesting LightSwitch applications, ranging from NetFlix to Dynamics CRM. However, it’s important to remember that all feeds are not equal – each one may have varying levels of support for the underlying OData query operators that LightSwitch applications rely on.
When a LightSwitch application consumes a feed that doesn’t support one of the OData query operators, typically the data will fail to display. As a result, the user will see a red-X with a tooltip saying “Unable to load data. Please check your network connection and try loading again.” The diagnostics log will also display the error message that is returned by the feed. For more information on how to use the diagnostic log to troubleshoot red-x’s, refer to Eric Erhardt’s blog post: Diagnosing Problems in a Deployed 3-Tier LightSwitch Application.
The good news is that even though few feeds support all of the OData query operators, a majority of LightSwitch's core query features do in fact work with the feeds. Furthermore, design time options can be set to prevent a red-X experience when an operator isn’t supported by a feed. To help with this, the LightSwitch OData Attach wizard does work behind the scenes to set these options appropriately. This wizard is opened by right-clicking the server project and selecting “Add Data Source…”.
Using the feeds that are currently available within the OData ecosystem, you’ll find that many of the feeds:
· Do not support the ability to search entity string properties
· Do not support the ability to eager-load related entity data
Based on this, the OData Attach wizard automatically sets options that correspond to these features to “off” for all feeds (with the exception of LightSwitch produced feeds). This means there may occasionally be a feed that does support these features, yet its design time option is turned “off”. In this case, you still have the ability to turn the feature back “on” by simply changing the corresponding option.
The remainder of this section explains the design time options for these features in further detail and how they are set by the OData Attach wizard.
To perform searches, LightSwitch uses the following query operators from the OData protocol:
· $SubstringOf function
· $Filter query option
· OR-boolean operator
These are used to perform searches on each searchable string property defined on an entity.
If a feed doesn’t support both the $SubstringOf and OR-boolean operator within a $Filter query option, then LightSwitch searches cannot be performed against the feed. Since many feeds don’t support this, the OData Attach wizard automatically turns “off” search by:
· Unchecking the “Is Searchable” option on entities
· Unchecking the “Support Search” option for corresponding screen members
You can turn search back “on” by checking both of the above options.
Note that turning search “on” for fields can impact performance. For further information, refer to Beth Massi’s blog post: LightSwitch Tips and Tricks on Query Performance.
To eager-load related entity data, LightSwitch uses the $Expand query option. This query option is used to eager-load many-to-one and many-to-zero or one navigation properties to related entities. For example, for a screen that displays both Order and related Shipper data, these operators are used to fetch both the Order and Shipper data in the same request to optimize performance.
Since many feeds don’t support the $Expand operator, the OData Attach wizard automatically turns “off” eager-loading by unchecking the “Display by Default” option that is available on navigation properties in the entity designer.
You can turn eager-loading back “on” by checking the “Display by Default” option.
The OData Attach wizard also executes several queries to determine whether a feed supports:
· Requesting a page of data
· Counting how many total pages of data exist
The design time options for these features are only turned “off” if they aren’t supported by the feed; otherwise they are left “on”. These query checks are performed using the first entity that is selected in the “Choose your Entities” screen of the wizard.
To request a page of data, LightSwitch uses the $Top query option.
The OData Attach wizard issues a $Top query to determine whether it is supported by the feed. If the $Top query fails with a 500 error, the “Support Paging” option is unchecked for the screen member. Otherwise, the option is checked.
To count how many pages of data exist, LightSwitch uses the $Count query option. This information is displayed as part of the paging control on a list or grid (refer to screenshot X).
The OData Attach wizard issues a $Count query to determine whether it is supported by the feed. If the $Count query fails with a 500 error, an option in the Common.lsml is set so that the number of total pages isn’t displayed as part of the paging control. This option isn’t surfaced through the design time environment.
The OData Attach wizard includes an option used to specify whether the entire feed is read-only. Since a majority of OData feeds are read-only, this option is checked by default for all feeds, including LightSwitch produced feeds:
Setting this value results in the following:
· Insert, Update, and Delete buttons are disabled on screens
· The *_CanInsert, *_CanUpdate, and *_CanDelete access control methods are removed from the Write Code menu that is available on an entity and these methods will not be called if they are implemented in code
· Insert, updates, and deletes to entities via code is prevented
Although the functionality provided by OData feeds varies, LightSwitch helps with these inconsistencies by setting design time options to prevent a poor runtime experience. And, if needed, you still have the flexibility of setting these options.
Special thanks to Matt Evans for providing some of the content included with this post.
Until next time...