LightSwitch as a Data Source
In addition to using LightSwitch to create applications, you can also use it as the middle tier to provide data to other applications. When you publish application data from LightSwitch to a web server or to Windows Azure, that data is exposed as an Open Data Protocol (OData) service. OData provides a standard for communicating with data services over the web. Many enterprises today use OData to exchange data between systems and partners, in addition to providing access into their data stores. Because OData is a standard protocol, other client applications on almost any platform or device can access the data that you create or expose through LightSwitch.
An OData service is automatically created for each data source in your application, with a separate endpoint for each data source. This capability applies not only to the tables that you define in the intrinsic database but also to any attached data source, such as a SQL Server database, a SharePoint list, or even another OData service.
Any business logic and user permissions that you’ve defined for your entities will execute when the endpoint is accessed, no matter what client is accessing the services. Rather than writing business logic and defining user permissions for each client application, you can use the LightSwitch middle tier as a place to centralize your code.
When you deploy a LightSwitch application in a three-tier configuration (hosting the middle tier in either Internet Information Services or Windows Azure), the service endpoints are exposed. The names of the services correspond to the names of your data sources. For example, the sample application in Walkthrough: Creating the Vision Clinic Application exposes two service endpoints because it has two data sources: the ApplicationData database, which is intrinsic, and the PrescriptionContoso SQL database, which is attached. If the application were deployed to a website that’s named “www.contoso.com,” the service endpoints would be http://www.contoso.com/ApplicationData.svc and http://www.contoso.com/PrescriptionContoso.svc.
Within each service, you can navigate to all entity sets that are modeled in the data designer. OData defines a set of query operations that you can perform on the data by using a set of URI conventions. You can query a service with an HTTP-GET request, and the service will return a feed with the results in the response. For example, you can query the Vision Clinic’s PrescriptionContoso service with the URI http://www.contoso.com/PrescriptionContoso.svc/Products to return a result set that contains all records from the Products entity.
To view the raw feed data in Internet Explorer, you must disable the Turn on feed reading view check box.
OData queries are case sensitive; if you specify products instead of Products, the query will return no results. You can further refine your OData queries in several ways. For example, you can use the http://www.contoso.com/PrescriptionContoso.svc/Products(1) query to return only the product that has a ProductID of 1. To return all products in the Lens Care category, you can use the http://www.contoso.com/PrescriptionContoso.svc/Products?Category='Lens Care’ query. Any business rules or permissions that you defined in LightSwitch still apply. Therefore, users who want to run the previous queries need permission to view Products.
Similarly, the OData protocol defines a standard way of navigating relationships through navigation properties. For example, you can use the http://www.contoso.com/PrescriptionContoso/Products(1)/ProductRebates query to find rebates for a product that has a ProductID of 1 in the related ProductRebates table. OData supports many other query operations such as OrderBy, Top, Skip, and Sort. For more information, see OData: URI Conventions.
In most cases, you will want to control who can access and update the data in your OData service. You can control access for a LightSwitch application by using its settings. LightSwitch supports three authentication settings: None, Forms, and Windows.
If you choose Forms authentication, LightSwitch enables two modes of authentication. One mode is a custom protocol that the Login dialog box uses and that uses a custom API for a web service to pass credentials and obtain a forms-authentication cookie. If a request for data doesn’t have a valid forms-authentication cookie, LightSwitch responds with an HTTP Basic challenge. This response allows clients that weren't developed in LightSwitch to pass credentials over a standard HTTP protocol. If you choose Windows authentication, LightSwitch requires an authenticated Windows user to provide credentials. For more information, see LightSwitch Authentication and Authorization.
Whatever authentication mechanism you use, you should consider using transport-level security over HTTPS to secure credentials, tokens, and data. Without HTTPS, forms, basic credentials, and forms-authentication tokens are transported as plain text. Windows authentication is more secure, but, without HTTPS, any data that's passed between client and server will still be plain text. To mitigate this, LightSwitch has an HTTPS setting in the Publish Wizard that causes the application to require a secure connection. With this setting enabled, requests will be redirected from HTTP to HTTPS, but you still must obtain and configure a HTTPS certificate on your website. For more information, see Security Considerations for LightSwitch.
In addition to securing access to the application, you can also use the role-based security in LightSwitch to restrict access to specific entities. For example, you might allow all authenticated users to display order data, but only supervisors can display payroll data. For more information, see LightSwitch Authentication and Authorization.
LightSwitch doesn’t provide a direct mechanism for hiding or excluding entity sets or entity properties from the OData endpoint. Whatever you connect to on the data tier will be visible on the endpoint of your service. You can control access to those resources by using the built-in access control methods in your data service code. For more information, see Performing Data-Related Tasks by Using Code.
The following example shows code that prevents a user from updating or deleting data in a Products entity:
Namespace LightSwitchApplication Public Class PrescriptionContosoService Private Sub Product_CanUpdate(ByRef result As Boolean) result = False End Sub Private Sub Product_CanDelete(ByRef result As Boolean) result = False End Sub Private Sub Product_CanInsert(ByRef result As Boolean) result = False End Sub End Class End Namespace
LightSwitch also provides row-level filtering with the EntitySet_Filter method. By using this method, you can return a smaller set of records from an entity. The following example returns only Customer records that have a TerritoryID of 5:
Any application that supports OData on any platform can consume OData feeds from LightSwitch. The methods for connecting to an OData feed vary by application, but you typically supply only the LightSwitch service endpoint.
The LightSwitch documentation contains several examples of applications that consume OData.
For information about how to consume OData from another LightSwitch application, see Walkthrough: Exposing and Consuming an OData Service in LightSwitch.
For information about how to consume OData from a Windows Store app, see Walkthrough: Using LightSwitch Data in a Windows Store App.
For information about how to consume OData from Microsoft Excel, see Walkthrough: Consuming LightSwitch Services in Excel Using PowerPivot.