LightSwitch Rocks!

OData Consumption Validation in Visual Studio LightSwitch 2012

2012-07-05T21:18:00Z

OData Feed Query Support

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…”.

“Search” and “Eager-Load” Design Time Options

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.

Performing Searches

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.

Eager-Loading Data

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.

“Paging” and “Page Count” Design Time Options

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.

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.

Requesting Page of Data

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.

Counting Pages of Data

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.

Read-Only OData Feeds

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

Conclusion

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...

Nicole Haugen

How To: Handle Database Concurrency Issues

2011-08-19T02:10:24Z

Concurrency issues are common in multi-user applications that have a database on the backend. Suppose you read a table record and then another user comes along and makes changes to the same record. Unless you re-read (e.g. refresh) your record, the data becomes stale. If you then attempt to make changes to the stale record, the application must detect and handle any data conflicts that may have occurred. For example, the other user may have modified the exact same field or may have even deleted the entire record. Clearly, the task of detecting and handling concurrency issues is not only important, but also quite complicated.

The good news is that LightSwitch makes concurrency very easy to handle. In fact, you might say that LightSwitch turns concurrency issues into concurrency non-issues. Specifically, LightSwitch provides a couple of different mechanisms for handling concurrency:

When a conflict is detected, a “Data Conflict” screen is automatically displayed to the user allowing them to choose how to resolve the conflict
Or, for a more customized solution, code can be written so that the application resolves the conflict without requiring interaction from the user

To see how to use these mechanisms, let’s continue with the Expense Report Tracker application that I discussed in my previous blog posts.

Display “Data Conflict” Screen

First off, let’s look at what we need to do in order to have LightSwitch display the “Data Conflict” screen when a concurrency error occurs in the Expense Report Tracker application. The answer to this is…nothing! LightSwitch automatically does this for you without having to write any additional code.

Since Expense Report Tracker is a multi-user application, it’s possible that two different managers might be reviewing the same expense report. If one of the managers decides to reject the expense report while the other decides to approve it, LightSwitch will detect the conflict. As a result, LightSwitch will display the following screen to the manager who was slowest to save their change:

Or, if instead the first manager deletes an expense report while the second manager attempts to approve it, the second manager will see the following screen when they save:

Write Code to Automatically Handle Conflict Resolution

In some cases you may want your application to automatically handle conflict resolution so that the user never sees the “Data Conflict” screen. Again, LightSwitch makes this very simple by exposing several programming objects that can be used to resolve the conflict.

When a data conflict is detected by LightSwitch’s server, it will throw a ConcurrencyException.

You can then write code in the client that catches this exception and uses it to get the collection of entities that have data conflicts. From there, you have access to all of the entity property values and have the ability to indicate whether a change should be saved or discarded.

With this in mind, suppose in the Expense Report Tracker that when two managers update an expense report to have the same status, that we want the code to automatically resolve the conflict. For example, if both managers set the status for the same expense report to “Approved”, then we don’t want the application to display the “Data Conflict” screen. Instead, we want our application to handle this automatically for the user.

To do this, we will need to write code in the screen’s “Saving” method. This method allows us to override the default behavior that occurs when the user clicks the Save button on the screen. You can add code to this method by opening the screen’s designer and choosing the method from the “Write Code” menu:

Next, let’s add the following code to the “Saving” method. Notice that our code first attempts to save the changes. If no data conflicts are detected, the changes will be saved as normal.

However, if a data conflict is detected, the server will throw a ConcurrencyException. Our code catches this exception and uses it to determine whether a conflict occurred with the Status property. In the case that two different users set the Status property to the exact same value, our code will automatically resolve the conflict by choosing to save the client’s value.

Otherwise, if some other type of data conflict occurred, the user will still be prompted to resolve the conflict by displaying the “Data Conflict” screen.

C#:

  partial void ExpenseReportsListDetail_Saving(ref bool handled)
  {
       //Indicates that our code will call SaveChanges()
       handled = true;
       try
       {
            this.DataWorkspace.ApplicationData.SaveChanges();
       }
       catch (ConcurrencyException e)
       {
            foreach (IEntityObject entityConflict in e.EntitiesWithConflicts)
              {
                    EntityPropertyConflict statusProperty =
    	               entityConflict.Details.EntityConflict.ConflictingProperties.Where(
                       property => property.Property.Name == "Status").Single();
                    if (statusProperty.Property.Value.ToString() == statusProperty.ServerValue.ToString())
                    {
                        statusProperty.EntityConflict.ResolveConflicts(ConflictResolution.ClientWins);
                        //Resave once we’ve resolved the conflicts
                        this.DataWorkspace.ApplicationData.SaveChanges();
                    }
                }
          }
    }

VB:

  Private Sub ExpenseReportDetail_Saving(ByRef handled As Boolean)
       handled = True
       Try
            Me.DataWorkspace.ApplicationData.SaveChanges()
       Catch e As ConcurrencyException
            For Each entityConflict As IEntityObject In e.EntitiesWithConflicts
                Dim statusProperty As EntityPropertyConflict =
                    (From prop In   entityConflict.Details.EntityConflict.ConflictingProperties
               	     Where prop.Property.Name = "Status"
               	     Select prop).Single()
                If (statusProperty.Property.Value.ToString() = statusProperty.ServerValue.ToString()) Then
                    statusProperty.EntityConflict.ResolveConflicts(
                    ConflictResolution.ClientWins)
                    Me.DataWorkspace.ApplicationData.SaveChanges()
                End If
            Next
        End Try
   End Sub

There are a few things worth highlighting in the above code:

Notice that this method accepts a “handled” parameter. When this parameter is set to true, this indicates that the code is responsible for calling SaveChanges() to save any changes that the user has made. Otherwise, if this parameter is false, LightSwitch automatically calls SaveChanges() for us. Since we want to handle saving on our own, the “handled” property is set to true. Also, notice that when a concurrency exception does occur, we must call SaveChanges() again to save the changes after we’ve resolved the concurrency conflicts.
You may have wondered why we didn’t try to catch and resolve the concurrency issue on the server, such as in the SaveChanges_ExecuteFailed method. The issue with this is that it is not valid to re-initiate a new Save from within the save pipeline once a failure has occurred. Instead, you must fix the concurrency issues and re-initiate the save from the client.

Summary

LightSwitch makes concurrency extremely easy to implement. In most cases, you don’t even need to worry about concurrency issues when creating your application because LightSwitch will handle it all for you. However, if there are situations where you want to write code to automatically resolve the data conflicts for the user; LightSwitch provides an easy to use programming model that is accessible through the ConcurrencyException that is thrown from the server.

How To: Using the Created Method to Set Default Property Values

2011-08-09T00:51:00Z

An extremely useful method that I consider to be a “must-have” in almost any type of LightSwitch application is the Created method. The Created method allows us to easily set the default values for an entity’s properties (e.g. fields in a table). To understand this further, let’s dive into an example that shows how to use the Created method.

If you read my first blog post on how to Prevent a Hole with Security Access Control, then you may remember in that scenario that I created a simple application used to track expense reports (which I creatively called the “Expense Report Tracker”). This application consists of two entities sharing a one-to-many relationship, called ExpenseReport and ExpenseItems. There are two types of users that use the application:

Employees that create and save expense reports for approval
Managers that approve or reject employees’ expense reports

In addition, we have a couple of business rules for when an employee creates an expense report – specifically, when an employee creates an expense report:

The ExpenseReport’s Name and UserAlias fields should be automatically set to the employee’s user information
The ExpenseReport’s Status field should be automatically set to a “Pending” status

The Created method allows us to implement both of the above business rules by using it to set the default values for the Name, UserAlias, and Status properties when the ExpenseReport entity is created. It’s important to note that the Created method is executed on both the Client and Server tier. As a result, the Created method is called no matter what mechanism is used to create an entity, regardless if it’s by clicking the “Add” button on a screen or by constructing an entity through code.

To add the ExpenseReport’s Created method to our application, open the ExpenseReport entity in the designer and select the “ExpenseReport_Created” method from the “Write Code” drop-down menu

Once the “ExpenseReport_Created” method’s code is generated, we can access the entity and set the properties’ values using the following code:

C#:

partial void ExpenseReport_Created()

   this.Status = "Pending";

this.Name = this.Application.User.FullName;

   this.UserAlias = this.Application.User.Name.Substring(

   this.Application.User.Name.LastIndexOf("\\") + 1);

VB:

Private Sub ExpenseReport_Created()

    Me.Status = "Pending"

    Me.Name = Me.Application.User.FullName

    Me.UserAlias = Me.Application.User.Name.Substring(

        Me.Application.User.Name.LastIndexOf("\\") + 1

End Sub

Next, let’s add a screen, called CreateNewExpenseReport, The screen is used for creating Expense Reports that display the values of the Name, UserAlias, and Status properties. Since these values are set automatically for the user in the Created method, we don’t want the user to have to enter these values. Essentially, we want these values to be non-editable through the screen.

The easiest way to get this behavior is to use Label controls to display the Name, UserAlias, and Status properties. Label controls allow the user to view a value, but not edit it. To set the Control Type to Label, select the control in the screen designer and change the “Control Type” property to “Label”.

It’s important to note that even though our screen prevents the user from entering values for the Name, UserAlias, and Status properties, these values aren’t protected from modification. To properly secure these values and ensure that an employee cannot modify them, we need to implement security access control checks in the save pipeline methods. Refer to my previous blog post for information on how to do this.

Summary

As you can see from the above scenario, the Created method is extremely useful for setting default values for entity properties. In particular, setting default values in this manner helps save the end-user time so that they don’t have to enter data that the application can automatically detect and set for them.

For a video demonstration of this technique see - How Do I: Set Default Values on Fields when Entering New Data?

Prevent a Security Hole with Access Control - Securing Logic Tier

2011-07-08T18:24:00Z

I recently joined the Visual Studio LightSwitch team and so far have spent most of my time learning about everything that LightSwitch has to offer. With all that I’ve been learning, I thought this blog would be a perfect opportunity to share some of my new found knowledge. I can’t help but be reminded of my childhood and the lessons taught by the Saturday morning cartoon Schoolhouse Rock! Granted, my blog may be missing the colorful animations, upbeat songs, and unforgettable lyrics, but I do promise to share my experiences as a LightSwitch newbie with an occasional attempt at rhyming; hence the title LightSwitch Rocks!

Inspired by Schoolhouse Rock! episodes with catchy titles such as “Conjunction Junction” and “My Hero, Zero”, my first blog post is appropriately called “Prevent a Security Hole with Access Control.” This is the first post focuses on securing data on the logic tier.Scenario: Expense Report Tracker

Let’s begin by creating a LightSwitch project called “ExpenseReportTracker” with two entities that are used to track the status of expense reports; note that ExpenseReport has a one-to-many relationship with ExpenseItems.

Two types of users will use this application:

Employees that create and save expense reports for approval
Managers that approve or reject employees’ expense reports

When an employee creates and saves an expense report, the report’s Status is automatically defaulted to “Pending.” The assigned Approver (e.g. manager) can then change the Status of the report to either “Approved” or “Rejected.”

Based on the above scenario, let’s look at the security rules that we want to enforce depending on the type of user:

An employee cannot delete an expense report
An employee cannot modify an expense report’s Status; this prevents employees from approving\rejecting expense reports
Once a manager has set an expense report’s Status to “Approved” or “Rejected”, an employee can no longer make modifications to the report

Creating Permissions

Since we have two types of users, there are two permissions that we need to create in the Application Properties designer; one that will be assigned to employees and another for managers.

Enforcing Security on the Logic Tier

Now that we have permissions created for employees and managers, let’s look at how to use these permissions to enforce the security rules for our application.

Using Entity Set “Can” Methods

Our first security rule means:

When the current user is assigned to a role with ManageExpenseReportPermission, then the user can delete expense reports; otherwise, the user should be prevented from deleting an expense report

This type of rule applies to all expense reports; not a particular instance of an expense report. Based on this, we can add this permission check to the ExpenseReport entity set’s CanDelete method. This method is added by opening ExpenseReports in the entity designer and selecting “ExpenseReports_CanDelete” from the “Write Code” drop-down menu.

Here’s the code that is written in the “ExpenseReports_CanDelete” method:

C#

partial void ExpenseReports_CanDelete(ref bool result)
{
result = this.Application.User.HasPermission(Permissions.ManageExpenseReportPermission);
}

VB

Private Sub ExpenseReports_CanDelete(ByRef result As Boolean)
    result = Me.Application.User.HasPermission(Permissions.ManageExpenseReportPermission)
End Sub

The benefit of using the “Can” method is two-fold; when it returns false, the user is prevented from performing the Delete operation. In addition, the application will automatically disable the Delete button on a screen that is displayed to the user.

If you need to enforce security for a specific entity instance or check a data value on an entity, then you will need to instead use the save pipeline’s methods.

Using Save Pipeline Methods

Our second and third security rules require us to check data on specific entity instances, therefore we will need to use the save pipeline methods. These security rules can be interpreted as follows:

When the current user is assigned to a role with EmployeeExpenseReportPermission, the user cannot modify the Status property
Similarly, if the user is assigned the EmployeeExpenseReportPermission, the user cannot modify an expense report that has already been approved\rejected

These checks can be added to the ExpenseReports Updating method. This method is added by opening ExpenseReports in the entity designer and selecting “ExpenseReports_Updating” from the “Write Code” drop-down menu. Notice that this method passes in the current entity instance as a parameter.

C#

partial void ExpenseReports_Updating(ExpenseReport entity)
{
    if (Application.Current.User.HasPermission(
        Permissions.EmplyeeExpenseReportPermission))
    {
        if (entity.Details.Properties.Status.IsChanged)
        {
            throw new Exception(
                "Permission denied: Unable to change expense report " + 
                "status. Report Id: " + entity.ReportId);
        }

        if (entity.Details.Properties.Status.Value != "Pending")
        {
            throw new Exception(
                "Permission denied: Unable to change an expense report" + 
                 "that has already been 'Approved' or 'Rejected'." + 
                 "Report Id: " + entity.ReportId);
        }
    }
}

VB

Private Sub ExpenseReports_Updating(entity As ExpenseReport)

If Application.Current.User.HasPermission(
     Permissions.EmployeeExpenseReportPermission) Then If entity.Details.Properties.Status.IsChanged Then Throw New Exception(
               "Permission denied: Unable to change expense " +
               "report status. Report Id: " + entity.ReportId)
          End If If entity.Details.Properties.Status.Value <> "Pending" Then Throw New Exception(
                "Permission denied: Unable to change an expense " +
                "report that has already been 'Approved' or " +
                "'Rejected'. Report Id: " + entity.ReportId)
          End If End If End Sub

You may have also noticed that we have a gap in our security because an employee can still potentially modify ExpenseItems that belong to an ExpenseReport that has already been approved\rejected. To bridge this gap, we need to add the following code to the “ExpenseItems_Inserting”, “ExpenseItems_Updating”, and “ExpenseItems_Deleting” methods. These methods are added via the “Write Code” drop-down menu that is available in the entity designer for ExpenseItems.

partial void ExpenseItems_Inserting(ExpenseItem entity) { if (Application.Current.User.HasPermission( Permissions.EmplyeeExpenseReportPermission) && entity.ExpenseReport.Status != "Pending") { throw new Exception("Permission Denied: Unable to modify " + "expense report that has already been 'Approved' or " + "'Rejected'. Report id: " + entity.ExpenseReport.ReportId); } } partial void ExpenseItems_Updating(ExpenseItem entity) { if (Application.Current.User.HasPermission( Permissions.EmplyeeExpenseReportPermission) && entity.ExpenseReport.Status != "Pending") { throw new Exception("Permission Denied: Unable to modify " + "expense report that has already been 'Approved' or " + "'Rejected'. Expense report id:" + entity.ExpenseReport.ReportId); } } partial void ExpenseItems_Deleting(ExpenseItem entity) { if (Application.Current.User.HasPermission( Permissions.EmplyeeExpenseReportPermission) && entity.ExpenseReport.Status != "Pending") { throw new Exception("Unable to modify expense report that has " + "already been 'Approved' or 'Rejected'. Expense report id: " + entity.ExpenseReport.ReportId); } }

VB

Private Sub ExpenseItems_Inserting(entity As ExpenseItem)

     If Application.Current.User.HasPermission(
        Permissions.EmployeeExpenseReportPermission) And entity.ExpenseReport.ReportId Then Throw New Exception("Permission Denied: Unable to modify " +
            "expense report that has already been 'Approved' or " +
            "'Rejected'. Report id: " + entity.ExpenseReport.ReportId)
     End If End Sub Private Sub ExpenseItems_Updating(entity As ExpenseItem)

     If Application.Current.User.HasPermission(
        Permissions.EmployeeExpenseReportPermission) And entity.ExpenseReport.ReportId Then Throw New Exception("Permission Denied: Unable to modify " +
              "expense report that has already been 'Approved' or " +
              "'Rejected'. Report id: " + entity.ExpenseReport.ReportId)
     End If End Sub Private Sub ExpenseItems_Deleting(entity As ExpenseItem)

      If Application.Current.User.HasPermission(
         Permissions.EmployeeExpenseReportPermission) And entity.ExpenseReport.ReportId Then Throw New Exception("Permission Denied: Unable to modify " +
             "expense report that has already been 'Approved' or " +
             "'Rejected'. Report id: " + entity.ExpenseReport.ReportId)

      End If End Sub

This check prevents employees from inserting, updating, and deleting ExpenseItems for a report that already has the Status set to either “Approved” or “Rejected”.

It is important to note that when an exception is thrown in the save pipeline methods that the changes are rolled back and the user is displayed a dialog box with the specified exception message.

Summary

The first step to properly securing an application is to secure your data on the logic tier by adding permission checks. This post has shown how to do this by adding permission checks to both the entity set “Can” methods and save pipeline methods.

Next time I will extend the “Expense Report Tracker” scenario to show how you can customize the appearance of screens according to the underlying security permissions for the user.

Thanks for joining me for my first blog post!