Lightswitch for the Enterprise

Setting up an integrated build and deploy pipeline for LightSwitch applications (part 2)

paul van bladel — Wed, 15 May 2013 16:51:45 +0000

Introduction

We continue in this article the deployment of a LightSwitch application from a build server. Basically, the approach can be used for any other web application type, so not only for LightSwitch applications.

I have written already a whole series of articles in preparation of this one:

SETTING UP AN INTEGRATED BUILD AND DEPLOY PIPELINE FOR LIGHTSWITCH APPLICATIONS (PART 1)

AUTOMATICALLY DEPLOY A LIGHTSWITCH-READY HOSTING WEBSITE WITH ABILITY TO SET THE HTTPS CERTIFICATE.

AUTOMATICALLY DEPLOY A LIGHTSWITCH-READY APPLICATION POOL WITH ABILITY TO SET THE APP POOL IDENTITY.

What will we cover in this article?

The first part of this series explained how we can correctly setup a build server and the build script to get everything built and to get a generated webdeploy package.

In this article we will elaborate a command file that will be eventually called from the build server in order to deploy the site, app pool and application on the target server.

So basically we are skipping, for the time being, the step in between: a dedicated TFS build server process template which will call this command file.

The advantage of this approach is that you can already start with manually executing this script. Anyhow, if things go wrong on the build server, the best approach is to call the script manually so that you can find out if things are going wrong with the process template or with the deployment script.

The big picture

Let’s first depict which servers are involved:

What’s the process?

Which files do we need?

This ones:

Let’s explore them one by one:

The LightSwitch package (LSFullDeployment.zip): obviously, we will not need to provide this file, because it will be generated by the build server. It’s the same file that would be generated by visual studio on your development machine, when you publish your application. Of course we make sure that on the build machine the “release” build is built.
TemplateAppPoolPackage: this is a fixed zip file, you need to create it once. This is explained in detail here: AUTOMATICALLY DEPLOY A LIGHTSWITCH-READY APPLICATION POOL WITH ABILITY TO SET THE APP POOL IDENTITY. Since the file is the same for all deployments, it could make sense to store it on the build server in a dedicated place, in such a way the build process template processing could pick it up.
TemplateWebSitePackage: basically the same logic as for the TemplateAppPoolPackage. If you want to know how to create it: AUTOMATICALLY DEPLOY A LIGHTSWITCH-READY HOSTING WEBSITE WITH ABILITY TO SET THE HTTPS CERTIFICATE. Since the file is the same for all deployments, it could make sense to store it on the build server in a dedicated place, in such a way the build process template processing could pick it up.
RemoteDeployFromBuildserver.cmd: this is the main process. This will be the command file that will be called from the build server process template on the build server and it will trigger the remote deployment. We’ll see later in this article the further details. This command file is also generic for all applications, but you could also decide to keep it specific per project.
RunOnIISServer.cmd: this is an “auxiliary” command file which is called from RemoteDEployFromBuildServer. This file will be triggered from the build server but directly executed on the target IIS server. So, in practice this file is transferred from the build server to the target server and executed there locally. The reason why we need this functionality is because it contains some AppCmd commands which can not be executed remotely. . This command file is also generic for all applications but have as well the option to make it specific per application.
SetWebAppAndAppPoolParameters.xml: this xml files contains the application and application pool parameters used during deployment. This file should be provided inside your visual studio solution and should be checked-in in TFS. Obviously, this xml file is specific per application.
WebAppDeclareParameters: there are occasions where you want to have more application specific parameters and corresponding parameter values in your web.config. This mechanism is explained here: TWEAKING THE LIGHTSWITCH WEBDEPLOY PACKAGE WITH A SIMPLE SCRIPT. The parameters that you want additionally are stored in WebAppDeclareParameters.xml. The WebAppDeclareParameters file is optional and should be provided inside your visual studio solution and should be checked-in in TFS. Obviously, this xml file is specific per application.

Let’s explore RemoteDeployFromBuildServer.cmd

Schematically I goes as follows:

And here is the script:

rem ******************************
rem deployment specific parameters
rem ******************************

SET "SiteName=TESTSITE"
SET "AppName=LSFullDeployment"
SET "AppPoolName=TESTAppPool"
SET "SiteHttpsPort=*:123:"
SET "WebAppSourcePackageName=LSFullDeployment.zip"

rem *************************************
rem  server specific params
rem *************************************
SET _httpsSiteCertificate="de0e36943ab3fab29322ee58edebb2e304a48370"
SET _dummyPassword="secret"  
SET "_physicalRootPath=D:\Inetpub\"
SET "_computerName=https://myserver.cloudapp.net:8172/msdeploy.axd,UserName='administrator',Password='mysecretpassword',AuthType='Basic' -allowUntrusted"

rem ********************
rem invariant parameters
rem ********************

SET "_appPoolParametersFile=SetWebAppAndAppPoolParameters.xml"
SET "_webAppParametersFile=SetWebAppAndAppPoolParameters.xml"
SET "_webAppTargetpackageName=DEPLOY.%WebAppSourcePackageName%
SET "_destinationWebSitePhysicalPath=%_physicalRootPath%%SiteName%"

net start msdepsvc

rem ***********************
rem prereqs RUNCOMMAND deletion of web app and website
msdeploy -verb:sync -source:runcommand=RunOnIISServer.cmd -dest:auto,ComputerName=%_computerName%
rem ***********************

rem **********************************************
rem ***************create app pool****************
rem **********************************************

msdeploy.exe -verb:sync -source:package="TemplateAppPoolPackage.zip",encryptpassword=%_dummyPassword% -dest:appPoolConfig=%AppPoolName%,computerName=%_computerName% -setParamFile=%_appPoolParametersFile%

rem **********************create web site*************
rem **************************************************
rem **************************************************

rem todo add  

msdeploy  -verb:sync -source:package="TemplateWebSitePackage.zip",encryptpassword=%_dummyPassword% -dest:appHostConfig=%SiteName%,ComputerName=%_computerName% -replace:objectName=virtualDirectory,targetAttributeName=physicalPath,match="^D:\\inetpub\\PreTemplateWebSite",replace=%_destinationWebSitePhysicalPath%  -setParam:"Application Pool"=%AppPoolName% -replace:objectName=httpCert,targetAttributeName=hash,replace=%_httpsSiteCertificate% -setParam:"Site-https"=%SiteHttpsPort%

rem *********************************************************
rem **********************create web application*************
rem *********************************************************

msdeploy.exe -verb:sync -source:package=%WebAppSourcePackageName% -dest:package=%_webAppTargetPackageName% -declareParamFile="WebAppDeclareParameters.xml"

msdeploy.exe -verb:sync -source:package=%_webAppTargetPackageName%  -dest:auto,ComputerName=%_computerName% -setParamFile=%_webAppParametersFile% -skip:ObjectName=dbFullSql

What’s in RunOnIISServer.cmd?

This command will completely destroy the site and the application. That’s just one approach is it’s the brute force approach.

rem ******************************
rem deployment specific parameters
rem ******************************

SET "SiteName=TESTSITE"
SET "AppName=LSFullDeployment"

rem *********************************************
rem ***********remove site and app **************
rem *********************************************
SET appPath=

FOR /F %%s in ('c:\windows\System32\inetsrv\appcmd list app /path:/%AppName% /Site.Name:%SiteName%') do SET  appPath=%%s

IF /I "%appPath%" EQU "" (
 echo "Great,nothing to delete... app %SiteName%/%AppName% does't exist"
 ) ELSE (
 c:\windows\System32\inetsrv\appcmd delete app /app.name:%SiteName%/%AppName%
 )

SET siteID=

FOR /F %%s in ('c:\windows\System32\inetsrv\appcmd.exe list sites %SiteName% /text:id') do SET  siteID=%%s

IF /I "%siteid%" EQU "" (
 echo "Great,nothing to delete... Site %SiteName% does't exist"
) ELSE (
 echo SiteName=%SiteName% && echo SiteID=%SiteID%
c:\windows\System32\inetsrv\appcmd delete site /site.name:%SiteName%
 )

As you can see, we use AppCmd, and that can not be execute remotely. That’s why in the RemoteDeployFromBuildServer.cmd command, we execute this file as a webdeploy ‘RunCommand’. The command file is simply transfered to the IIS server and executed over there locally (where it has access to AppCmd).

What about the parameter file?

In fact I put both the web application parameters and the application parameters in the same file:

What should be installed on my build server?

Visual studio ! Theoretically it is not necessary, but I strongly advice to simply install visual studio and check if everything works fine, e.g. building a LightSwitch project.

What should be installed on the IIS web server?

Webdeploy obviously. Also worth mentioning that IIS should be installed as well

In order to be able to run the msdeploy RunCommand execute the following from the command line:

sc privs wmsvc SeChangeNotifyPrivilege/SeImpersonatePrivilege/SeAssignPrimaryTokenPrivilege/SeIncreaseQuotaPrivilege

Don’t forget to restart the WmSvc service afterwards. I can assure you, If you don’t know the above, it can take weeks…

You will need also an administrator account on the IIS server which you can use in the deployment script. Remember this line in the deploy command:

SET "_computerName=https://myserver.cloudapp.net:8172/msdeploy.axd,UserName='administrator',Password='mysecretpassword',AuthType='Basic' -allowUntrusted"

The userName here is the administrator account on the IIS Server. The allowUntrusted parameter tells webdeploy to trust also an https connection without a valid certificate.

Finally, port 8172 should be accessible on your IIS server. That’s the port that webdeploy uses.

Conclusion

We have now everything in place to call from the build server in order to trigger a full blown deployment based on parameters.

The above can also be interesting if you don’t use a build server, but simply want to deploy from the command line. In a next article we’ll integrate everything in the build process template.

A new RIA approach in LightSwitch: the ServerApplicationContext RIA Service.

paul van bladel — Mon, 13 May 2013 14:59:24 +0000

Introduction

Ria Services are in the LightSwitch community very popular. They are interesting because they allow me to reshape my data in a very elegant way.

In this article I’ll introduce another way to use RIA Services based on the LightSwitch V3 ServerApplicationContext.

How are RIA services traditionally used in LightSwitch?

As you know, when it comes to databases, we distinct in LightSwitch 2 basic approaches

the intrinsic database approach or
the external database approach.

In contrast to the external approach, when working intrinsically, LightSwitch takes all responsibility for the (intrinsic) database scheme.

Now, what’s the role of RIA Services in this picture. Basically, a RIA service is a service layer on top of a data layer (in most cases, but not necessarily, based on entity framework).

Why are they interesting?

Also RIA services allows 2 approaches

they allow me to connect to and reshape an external data source: this can be really anything, I can even provide an Iqueryable “connection” to an xml file.
they allow me to reshape my existing LightSwitch data model. Classic example (remember this, I’ll refer to soon): I have a customer and an order table and I want to have a DTO (data transfer object) composed of CustomerName and OrderCount. This is called an aggregation and this is not out-of-the-box available in LightSwitch. So, thank you RIA services ! I tend to call this type of RIA Service: an intrinsic database RIA Service.

In most cases the second approach, the intrinsic database RIA Service is used. There is a handy Nuget package available for injecting the necessary functionality directly in a .Net 4.0 Class Library:

What are the drawbacks?

The LightSwitch application domain logic is completely ignored.

Although this might be desired behavior in some very particular cases, the intrisic database RIA service completely ignores your application domain logic. An example can illustrate: if in my above “classic” example, my customer table has a Filter method (e.g. only show customers from Belgium), this rule will be completely ignored in my intrinsic database RIA Service. In other words when I retrieve the Customer/OrderCount DTO I get all customers, also the ones not living in Belgium.

Project compilation will trigger hundreds of compilation warning.

This is a rather annoying side-effect of including the ApplicationDataObjectContext.cs (which is one the LightSwitch auto generated files) into the RIA Service project. This is because the imported types conflict with the existing LightSwitch types.

Tata, a new approach: the ServiceApplicationContext RIA Service

In order to grasp the idea quickly, simply start with generating a classic Ria Service (e.g. based on my nuget package) and update the LightSwitch domain service base class (I prefer to isolate this logic in a base class)

using System.Linq;
using System.ServiceModel.DomainServices.Server;
using Microsoft.LightSwitch.Server;
using Microsoft.LightSwitch;
using Microsoft.LightSwitch.Details;

namespace RiaService
{
    public class LightSwitchDomainServiceBase : DomainService
    {
        IServerApplicationContext _context = ServerApplicationContextFactory.Current;

        public IServerApplicationContext Context
        {
            get
            {
                return _context;
            }
        }

        protected override int Count(IQueryable query)
        {
            return query.Count();
        }
        internal IDataServiceQueryable GetEntitySetDataService(string dataSourceName, string entitySetName)
        {
            IDataService dataService 
                = Context.DataWorkspace.Details.Properties[dataSourceName].Value as IDataService;

            var entitySet = dataService.Details.Properties.All()
                .OfType()
                .Where(n => n.Name == entitySetName).SingleOrDefault().Value;

            return dataService.Details.Properties[entitySet.Details.Name].Value as IDataServiceQueryable;
        }
    }
}

Note that you need a binary reference to Microsoft.LightSwitch.dll (from C:\Program Files (x86)\Microsoft SDKs\LightSwitch\v3.0\Client\Microsoft.LightSwitch.dll) and Microsoft.LightSwitch.Server.dll (from C:\Program Files (x86)\Microsoft SDKs\LightSwitch\v3.0\Server\Microsoft.LightSwitch.Server.dll).

So, what’s different here? Well, in a traditional RIA service we would make a connection to the intrinsic database by reusing the ObjectContext:

public ApplicationData Context 
        {
            get
            {
                if (this.m_context == null)
                {
                    string connString =
                        System.Web.Configuration.WebConfigurationManager
                        .ConnectionStrings["_IntrinsicData"].ConnectionString;
                    EntityConnectionStringBuilder builder = new EntityConnectionStringBuilder();
                    builder.Metadata =
                        "res://*/ApplicationData.csdl|res://*/ApplicationData.ssdl|res://*/ApplicationData.msl";
                    builder.Provider =
                        "System.Data.SqlClient";
                    builder.ProviderConnectionString = connString;
                      //for a lightSwitch V2 project change in the next line ApplicationData to ApplicationDataObjectContext
                    this.m_context = new ApplicationData(builder.ConnectionString);
                }
                return this.m_context;
            }
        }

In our new approach we won’t longer use this! Instead of setting up the ObjectContext we simply setup an IServerApplicationContext ! There is one helper method included in the base class, which allows us to retrieve easily a DataService based on name of an entitySet (e.g. Customers). It’s not at all mandatory to use this, the base class provides easy access to the ServerApplicationContext via the “Context” property. As a result: full access to everything, and much more than in a regular Ria Service !

So far so good. Let’s create now a domain service based on the above base class for following data transfer object:

  public class ExampleCustomerDTO
    {
        [Key]
        public int Id { get; set; }
        public string CustomerName { get; set; }
    }

The domain services goes as follows:

namespace RiaService.Services
{
    using System.Linq;
    using RiaService.DTO;
    using System.ServiceModel.DomainServices.Server;
    using Microsoft.LightSwitch;

    public class ExampleCustomerDomainService : LightSwitchDomainServiceBase
    {
        [Query(IsDefault = true)]
        public IQueryable GetCustomersDTO()
        {
            string dataSourceName = "ApplicationData";
            string entitySetName = "Customers";
            var query = this.GetEntitySetDataService(dataSourceName, entitySetName);//as IDataServiceQueryable;

            return GetCustomQuery(query);
        }

        private IQueryable GetCustomQuery(IDataServiceQueryable query)
        {
            var dtoQuery = from IEntityObject c in query
                           select new ExampleCustomerDTO
                           {
                               Id = (int)c.Details.Properties["Id"].Value,
                               CustomerName = c.Details.Properties["LastName"].Value.ToString()
                           };

            return dtoQuery.AsQueryable();
        }
    }
}

Basically, rather similar to a classic domain service. We split the call in two steps:

first, we retrieve an IDataServiceQueryable based on “Customers” and secondly, we massage the data into the ExampleCustomerDTO structure.

What are the advantages of the ServerApplicationContext RIA approach?

The application domain logic is fully respected: if I have a filter (row level security) on Customers, the ServerApplicationContext RIA Service is fully respect these rules !
Since we don’t share any generated files with the LightSwitch server project, we got rid of all compilation warnings.
We have full access to the Server application object: this means that we can access also other datasources inside the Application model and do aggregations between data sources !

What’s the disadvantage?

We lose strongly typed access when doing the DTO projection:

var dtoQuery = from IEntityObject c in query
                           select new ExampleCustomerDTO
                           {
                               Id = (int)c.Details.Properties["Id"].Value,
                               CustomerName = c.Details.Properties["LastName"].Value.ToString()
                           };

As you can see, we access the EntityObject by means of the weakly typed API. This can unfortunately not be solved by adding a file reference to ApplicationDataObjectContext class because the “EntityObjects” inside this class are based on material inside LightSwitchApplication.Implementation, which differ from the types present in “LightSwitchApplication”.

Nonetheless, I’m convinced there is a workaround for this.

Try it out.

Here is a sample : RiaServerApplicationContext

The sample has both the classic RIA service and the ServerApplicationContext RIA service. It has a customer table with a simple row level security rule (only customers with last name starting with ‘x’ are returned). You can easily verify the different behavior and play with it, in case you like it

Note that my project has still compilation warnings, but that’s because of the classic RIA service.

Flexible CSV exports over web-api with server side MEF – discover the export formats. (part 4)

paul van bladel — Wed, 08 May 2013 13:17:59 +0000

Introduction

Our previous post showed how we can consume an export by clicking a button. But let’s presume now that we want to present the user with a list of available export formats. Since we use MEF server side that’s a piece of cake. At the end of the post you’ll find a zip with the full code.

I’ll focus here only on the server side. I simply provide the list of potential export formats in a textbox. I leave it to the reader to invent a decent client side implementation

My client side implementation goes as follows:

I provide a list of available exports for the customer type.

The controller

In order to keep things a bit clean, I designed a separate controller for this:

using Microsoft.LightSwitch;
using Microsoft.LightSwitch.Details;
using Microsoft.LightSwitch.Server;
using Microsoft.VisualStudio.ExtensibilityHosting;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.Http;
using System.Net.Http;
using System.Net;

namespace LightSwitchApplication.LightSwitchToolbox.ExportModule
{
    public class ExportMetaDataController : ApiController
    {
        [HttpPost]
        public HttpResponseMessage GetProjectors(GetMetaDataCommandParameters requestParams)
        {

            string dataServiceName = requestParams.DataServiceName;
            string entitySetName = requestParams.EntitySetName;
            using (IServerApplicationContext ctx = ServerApplicationContextFactory.CreateContext())
            {
                IDataService dataService =
                    ctx.DataWorkspace.Details.Properties[dataServiceName].Value as IDataService;

                var entitySet = dataService.Details.Properties.All()
                    .OfType()
                    .Where(n => n.Name == entitySetName).SingleOrDefault().Value;
                Type entityType = entitySet.Details.EntityType;

                var projections = VsExportProviderService
                    .GetExports()
                    .Where(p => p.Metadata.SourceEntityType.Equals(entityType));

                List result = new List();
                foreach (var item in projections)
                {
                    result.Add(item.Metadata.ProjectionName);
                }

                var response = Request.CreateResponse>(HttpStatusCode.Accepted, result);

                return response;
            }
        }
    }
}

The VsExportProviderService gives us a list of potential export types (projection strategies) for our source type (in my case here: customers).

This time I get in the request parameters via a dedicated class:

 public class GetMetaDataCommandParameters
    {
        public string DataServiceName { get; set; }
        public string EntitySetName { get; set; }
    }

How can we consume this in the SilverLight client?

I’m basically using my nuget package for web-api based commanding. By doing so the client side call is very simple is robust:

partial void GetProjectors_Execute()
        {
            this.StartWebApiCommand>("api/ExportMetaData/GetProjectors",
                new GetMetaDataCommandParameters { DataServiceName = "ApplicationData", EntitySetName = "Customers" },
                 (error, response) =>
                 {
                     if (error != null)
                     {
                         this.ShowMessageBox("error = " + error.Message);
                     }
                     else
                     {
                         string text = "Available export formats : " + Environment.NewLine;
                         foreach (var item in response)
                         {
                             text = text + item.ToString() + Environment.NewLine;
                         }
                         this.ShowMessageBox(text);
                     }
                 }
                 );
        }

Conclusion

Here is the full code: CSVExport

The above is a prototype. Of course, what you want is that the user can select a certain export projection strategy by means of a fancy selection screen. But it should be clear the MEF has also for LightSwitch a very prominent place.

Flexible CSV exports over web-api with server side MEF – the silverlight and html client. (part 3)

paul van bladel — Wed, 08 May 2013 13:02:24 +0000

Introduction

We want to consume now the MEF based export functionality from the silverlight client.

Let’s first take a look at a potential screen where we use it:

So, we have a bunch of customer (with orders) data and there are some buttons where we can select a specific export strategy:

As you can see, we can ask for customers with orders count and customers with full name only.

How do we initiate the web-api call in the silverlight client?

 partial void CustomersWithOrderCountExport_Execute()
        {
            string projectionName = "Customers with order count";
            GetExport(projectionName);
        }

        private static void GetExport(string projectionName)
        {
            Dispatchers.Main.Invoke(() =>
            {
                Uri baseAddress = new Uri(new Uri(System.Windows.Application.Current.Host.Source.AbsoluteUri), "../../");
                string url = baseAddress.AbsoluteUri
                    + @"api/CSVExport/GetExport/?dataServiceName=ApplicationData&entitySetName=Customers&projectionName=" + projectionName;
                HtmlPage.Window.Navigate(new Uri(url), "_blank");
            });
        }

We only need to provide the dataService (ApplicationData), the entity set type (e.g. Customers) and the name of the specific projection strategy (in my example: Customers with order count).

How do we initiate the web-api call in the html client?

Place a button on the browse customer screen, and provide following code:

myapp.BrowseCustomers.GetCustomersWithOrderCountExport_execute = function (screen) {

    var baseAddress = window.location + "../..";
    window.open(baseAddress +
        "/api/CSVExport/GetExport/?dataServiceName=ApplicationData&entitySetName=Customers&projectionName=Customers with order count");
};

Why do I believe this is cool?

That’s of course a difficult question to answer for me since I designed the above

I think it’s cool because the heavy lifting of export generation is completely moved to the infrastructure level (assumed you can inject it via nuget). Adding a new export type is only a matter of writing the lamdba expression for the projection and providing it a meaningful name.

Furthermore, since we use web-api, the whole infrastructure works both in the html client and the silverlight client !

Enjoy !

Flexible CSV exports over web-api with server side MEF. (part 2)

paul van bladel — Wed, 08 May 2013 12:36:35 +0000

Introduction

In a previous post I introduced the usage of MEF (the managed extensibility framework) for making the management of the CSV exports more simple.

The basic idea is to have an approach with which we can easily create a new CSV export, by means of the strictest minimum of code :

public class CustomerCSV3
    {
        public string FullName { get; set; }
        public int OrderCount { get; set; }
    }

    [Export(typeof(IProjection))]
    [ProjectionMetadata(typeof(Customer), "Customers with order count")]

    public class CustomerWithOrderCountProjection : IProjection
    {
        public Expression> GetProjection()
        {
            return (Customer c) => new CustomerCSV3 { FullName = c.FirstName + " " + c.LastName, OrderCount = c.Orders.Count() };
        }
    }

But, … making this possible, requires quite a lot of infrastructure code. I’ll try to make this available via a Nuget package so that it’s a matter of seconds to have it available.

As you can see in the following view on my solution folder (of the server project), we really need quite some classes and interfaces:

This post is about MEF, where the notation of Exports is key. Now, from a functional perspective this post is also about exporting data. This can be a source of confusion for the reader who is not familiar with MEF. The concept of Export in MEF has really nothing to do with exporting data

The CSV Export Controller

All request for a report will pass through one specific method in a specific controller:

using Microsoft.LightSwitch;
using Microsoft.LightSwitch.Server;
using Microsoft.VisualStudio.ExtensibilityHosting;
using System;
using System.Linq;
using System.Collections;
using System.Collections.Generic;
using System.ComponentModel.Composition;
using System.IO;
using System.Net;
using System.Net.Http;
using System.Net.Http.Headers;
using System.Text;
using System.Web.Http;
using Microsoft.LightSwitch.Details;

namespace LightSwitchApplication
{
    public class CSVExportController : ApiController
    {
        private static readonly MediaTypeHeaderValue _mediaType = MediaTypeHeaderValue.Parse("text/csv");

        [HttpGet]
        public HttpResponseMessage GetExport(string dataServiceName, string entitySetName, string projectionName)
        {
            IProjector projector = new Projector();

            IEnumerable data = projector.ApplySourceDataProjection(dataServiceName, entitySetName, projectionName);

            CSVExportEngine exportEngine = new CSVExportEngine();

            StringBuilder stringBuilder = exportEngine.GenerateExport(data);

            System.Text.UTF8Encoding encoding = new System.Text.UTF8Encoding();

            MemoryStream memStream
                = new MemoryStream(encoding.GetBytes(stringBuilder.ToString()));
            HttpResponseMessage fullResponse = Request.CreateResponse(HttpStatusCode.OK);
            fullResponse.Content = new StreamContent(memStream);
            fullResponse.Content.Headers.ContentType = _mediaType;
            string fileName = String.Format("data-{0}.csv", DateTime.Now.ToString("yyyy-MMM-dd-HHmmss"));
            fullResponse.Content.Headers.ContentDisposition = new ContentDispositionHeaderValue("fileName") { FileName = fileName };
            return fullResponse;
        }

}

So, the GetExport method handles a request for a specific report based on a specific projection name. We apply as good as we can seperation of concerns. The retrieval of the data which we want to export is handled by the Projector (based on IProjector) class, whereas the generation of the export itself is done by the CSVExportEngine. The rest of the controller method is boilerplate code for pushing the export to the client, simple basic web-api.

The Projector

using Microsoft.LightSwitch;
using Microsoft.LightSwitch.Details;
using Microsoft.LightSwitch.Server;
using Microsoft.VisualStudio.ExtensibilityHosting;
using System;
using System.Collections;
using System.Collections.Generic;
using System.ComponentModel.Composition;
using System.Linq;
using System.Linq.Expressions;

namespace LightSwitchApplication
{
    public class Projector: IProjector
    {
        public IEnumerable ApplySourceDataProjection(
           string dataServiceName,
           string entitySetName,
           string projectionName)
        {
            using (IServerApplicationContext ctx = ServerApplicationContextFactory.CreateContext())
            {
                IDataService dataService =
                   ctx.DataWorkspace.Details.Properties[dataServiceName].Value as IDataService;
                var entitySet = dataService.Details.Properties.All()
                  .OfType()
                  .Where(n => n.Name == entitySetName).SingleOrDefault().Value;
                Type entityType = entitySet.Details.EntityType;

                var projections = VsExportProviderService.GetExports().Where(m => m.Metadata.SourceEntityType.Equals(entityType));
                if (projections == null || projections.Count() == 0)
                {
                    throw new ArgumentException("No suitable projection found");
                }

                dynamic projection
                    = projections.Where(c => c.Metadata.ProjectionName == projectionName)
                    .FirstOrDefault().Value;
                dynamic sourceQuery
                    = dataService.Details.Properties[entitySetName].Value;
                var destinationQuery
                    = DataServiceQueryable.Select(sourceQuery, projection.GetProjection()); //dyn invok
                return destinationQuery.Execute();
            }
        }
    }
}

The most important part here it the retrieval of the projection strategy based on the projection name:

VsExportProviderService.GetExports()

Since our projections are decorated with the Export attribute, they can be easily resolved. We use also specific meta data attributes:

using System;
using System.ComponentModel.Composition;
namespace LightSwitchApplication
{
    
    public interface IProjectionMetaData
    {
        string ProjectionName { get; }
        Type SourceEntityType { get; }
    }


    [MetadataAttribute]
    [AttributeUsage(AttributeTargets.Class, AllowMultiple = false)]
    public class ProjectionMetadataAttribute : ExportAttribute
    {
        public ProjectionMetadataAttribute(Type sourceEntityType,string projectionName)
            : base(typeof(IProjectionMetaData))
        {
            ProjectionName = projectionName;
            SourceEntityType = sourceEntityType;
        }

        public string ProjectionName { get; set; }
        public Type SourceEntityType { get; set; }
    }
}

The CSV Export class

We call in our CSV export controller a specific CSV exporter:

using System;
using System.Linq;
using System.Text;
using System.Collections;

namespace LightSwitchApplication
{
    public class CSVExportEngine
    {
        public StringBuilder GenerateExport(IEnumerable data)
        {
            StringBuilder stringBuilder = new StringBuilder();
            Type itemType = data.GetType().GetGenericArguments()[0];
            string header = string.Join(",", itemType.GetProperties().Select(x => x.Name));
            stringBuilder.AppendLine(header);
            foreach (var entity in data)
            {
                var vals = entity.GetType().GetProperties().Select(
                        pi => new
                        {
                            Value = pi.GetValue(entity, null)
                        });

                string _valueLine = string.Empty;

                foreach (var val in vals)
                {

                    if (val.Value != null)
                    {
                        var _val = val.Value.ToString();

                        //Check if the value contans a comma and place it in quotes if so
                        if (_val.Contains(","))
                            _val = string.Concat("\"", _val, "\"");

                        //Replace any \r or \n special characters from a new line with a space
                        if (_val.Contains("\r"))
                            _val = _val.Replace("\r", " ");
                        if (_val.Contains("\n"))
                            _val = _val.Replace("\n", " ");

                        _valueLine = string.Concat(_valueLine, _val, ",");
                    }
                    else
                    {
                        _valueLine = string.Concat(string.Empty, ",");
                    }
                }

                stringBuilder.AppendLine(_valueLine.TrimEnd(','));
            }
            return stringBuilder;
        }
    }
}

This class is really nothing special, just a simple CSV generator

Remember the the projections must derive from:

using Microsoft.LightSwitch;
using System;
using System.Linq.Expressions;

namespace LightSwitchApplication
{
    public interface IProjection : IProjection
        where T : IEntityObject
        where S : class,new()
    {
        Expression> GetProjection();
    }
    public interface IProjection
    {
    }

}

Conclusion

This was the difficult part. Now, we only need to consume this functionality from the client: both the silverlight and html client.

I’ll cover that in a next post !

State driven security in LightSwitch (part 6): client side CanUpdate handling

paul van bladel — Mon, 29 Apr 2013 07:43:45 +0000

Introduction

In the previous post, we covered the most technical part in this series on state driven security: the server side logic for state driven can-update handling. To top it all, we still need a client side experience for this. That’s the current post. If you grasped the logic behind the previous articles, the current one is very trivial and simple.

This post is the start of a series:

part 1 : introduction
part 2 : the big picture
part 3 : state transition security (server side)
part 4 : state transition security (client)
part 5 : state driven can do update behavior (server side)
part 6 : this post

The Silverlight client

Let’s first indicate clearly what we want to achive: when an entity (or an attached entity in the object graph) is in a functional state where it can not be edited, the controls should adapt accordingly. Following example illustrates the situation where an holiday request body can no longer be updated (except the state) and the attached “Holiday request management feedback sub entity can be edited.

The code for doing is, is pretty simple, just call the private method SetHolidayRequestVisibility in the HolidayRequestDetail_InitializeDataWorkspace method:

private void SetHolidayRequestVisibility(string stateValue)
        {
            bool isReadOnly = !StateManagement.CanUpdateEntityInState(CurrentHolidayRequest, OriginalValueOfRequestState);
            this.FindControl("Description").IsReadOnly = isReadOnly;
            this.FindControl("Requestor").IsReadOnly = isReadOnly;
            if (CurrentHolidayRequest.HolidayRequestManagementFeedback != null)
            {
                isReadOnly = !StateManagement.CanUpdateEntityInState(
                    CurrentHolidayRequest.HolidayRequestManagementFeedback,
                    OriginalValueOfRequestState);
                this.FindControl("CurrentHolidayRequest_HolidayRequestManagementFeedback").IsReadOnly = isReadOnly;
            }
        }

The reason why it’s so simple, is because the StateManagement class can be linked as a file reference into the Silverlight assembly. That’s a technique that -unfortunately- we can’t apply in the html5 client.

The html5 client

We are lucky, the html5 implementation of the above is quite similar to a recent post of Beth Massi Using LightSwitch ServerApplicationContext and WebAPI to Get User Permissions

We simply need to expose the StateManagement.CanUpdateEntityInState method via a web-api interface. I presume you can do this yourself

How can I get the infrastructure code?

Via nuget. Open the nuget management console:

Flexible CSV exports over web-api with server side MEF. (part 1)

paul van bladel — Wed, 24 Apr 2013 13:06:21 +0000

Introduction

Since the introduction of LightSwitch V3, the amount of plumbing options we have in LightSwitch increased drastically. Especially when using it in combination with proven technologies like web-api and the new ServerApplicationContext in LightSwitch V3.

Today, we’ll add another technology: the managed extensibility framework. Not just for the sake of the technology, but for solving a real live problem: flexible exports.

What do I mean with flexible exports

Let’s first clearly define that an export is not the same as a report. An export simply retrieves data from the server and presents it to the user in the form of a kind of tabular structure which can be opened by the user in Excel (the most portable format for this is CSV, comma separated value).

The most simple export is the one that available out of the box in LightSwitch. This export is ok for simple usage, but in most cases the user would like to have a richer set of potential export definitions she can select from.

So, wouldn’t it be nice that instead of a simple Customer export, the user could have some more options when she clicks the export button:

Obviously, we want to reuse the approach via web-api I documented over here: reporting via web-api.

In this post I want to focus on an elegant way to define the different export definitions.

It’s all about projection strategies

In order to come up with a good approach, let’s first focus on what different between the above (potentially over simplified) export definitions.

Basically, the three definitions are just variations on the applied “projection strategy”. A projection is a prominent “Linq” concept. When you do a select new (with is the core element in our web-api based exporting solution I referred to above) you are applying a projection.

An example can clarify:

    {
        public Expression> GetProjection()
        {
            return (Customer c) => new CustomerCSV1 { FullName = c.FirstName + " " + c.LastName };
        }
    }

The above projection goes together with following POCO class.

 public class CustomerCSV1
    {
        public string FullName { get; set; }
    }

So, our customer entity is projected into a new POCO type (CustomerCSV1) which massages the data into a structure with only a FullName field (which is a concatenation of FirstName and LastName). In mathematical terms the Customer class is the “Source” and the CustomerCSV1 class is the “domain” (the destination if you want). The data are projected from source to domain.

That’s easy. Another projection can incorporate the underlying orders of the customer:

public Expression> GetProjection()
        {
            return (Customer c) => new CustomerCSV3 { FullName= c.FirstName + " " + c.LastName, OrderCount = c.Orders.Count()};
        }

Based on following domain poco:

public class CustomerCSV3
    {
        public string FullName { get; set; }
        public int OrderCount { get; set; }
    }

It is clear that even the most flexible export solution can not avoid that the above projection strategy and the corresponding POCO have to be created in code. But our goal is that this is the only thing we need to do: new projection strategies should be resolved by the system automatically !

That’s why we need the Managed Extensibility framework.

Sometimes people compare MEF with an IOC (inversion of control) container, but that’s not completely accurate. MEF brings in a way imports and exports (euh… not data exports as above, but code functionality of course) together by means of attribute decoration. But, I said already too much, no MEF tutorial here. Use your browser.

Adding a new strategy to our CSV export machinery would look as follows:

  [Export(typeof(IProjection))]
  [ExportProjection( "First Name only")]

    public class CustomerFirstNameProjection : IProjection
    {
        public Expression> GetProjection()
        {
            return (Customer c) => new CustomerCSV2 { FirstName = c.FirstName };
        }
    }

As you can see we decorated the CustomerFirstNameProjection with two attributes:

[Export(typeof(IProjection))] : tells that we want to include this strategy in our export repository. By doing so, our export selection window is automatically updated with another export template !
[ExportProjection("First Name only")]: we want to provide the export strategy a meaningful name.

What’s next?

The implementation of the above. Be prepared for pretty technical code, but remember it’s infrastructure code, the goals is writing less code when using it !

State driven security in LightSwitch (part 5): let the state dictate what you can update

paul van bladel — Thu, 18 Apr 2013 18:47:07 +0000

Introduction

We have so far a decent way to protect state transitions and a comfortable client side implementation. Now, we will cover another important facet of state driven security: the ability to update entities based on the current state.

Why do we need some new base infrastructure for this?

It is tempting to think that we can use for this the standard LightSwitch Can_ methods like the one here for update:

 partial void HolidayRequests_CanUpdate(ref bool result)
        {

        }

What’s the problem? Well, … these set of methods is only suitable for course grained security. It can provide a go/no go for updating an entity as a whole, without referring to a particular row. Indeed, there is no current entity parameter in the above method.

Of course, we can still use these set of security methods, but not when it is about security related to the current state of an entity.

What do we need exactly?

We need a way to enforce that given a certain state (e.g. Approved) an entity (or any entity inside the object graph related to the entity monitored by the state property) can not be updated. Let’s extend our Validate method, with another one from our StateManagement class: the ValidateCanUpdateEntityGivenCurrentState method:

 partial void HolidayRequests_Validate(HolidayRequest entity, 
            EntitySetValidationResultsBuilder results)
        {
            StateManagement.ValidateCanUpdateEntityGivenCurrentState(
                entity,
                entity,
                s => s.HolidayStateCode,
                results);

            StateManagement.ValidateStateTransition(
                entity,
                s => s.HolidayStateCode, 
                this.DataWorkspace.ApplicationData.StateCodes, 
                results);
        }

The ValidateCanUpdateEntityGivenCurrentState is flexible enough to cope both with the situation where the state is included in the entity to validate or not.

public static void ValidateCanUpdateEntityGivenCurrentState(
            TEntityToValidate entityToValidate,
            TEntityContainingState entityContainingStateProperty,
            Expression> statePropertyLambda,
            EntitySetValidationResultsBuilder results, params IEntityProperty[] excludeProperties)
            where TEntityContainingState : IEntityObject
            where TEntityToValidate : IEntityObject
        {
            var stateProperty = entityContainingStateProperty.GetEntityTrackedProperty(statePropertyLambda);

            if (stateProperty.Value == null || entityToValidate.Details.EntityState == EntityState.Added) 
            {
                return;
            }
            var originalStateCode = stateProperty.OriginalValue as IStateCode;

            if (!entityToValidate.CanUpdateEntityInState(originalStateCode.StateValue))
            {
                if (entityToValidate.Equals(entityContainingStateProperty))
                {
                    // when the state field is part of the entity to validate, 
                    // the statefield and rowversion must be excluded from validation

                    var statePropToExclude
                        = entityContainingStateProperty.GetEntityTrackedProperty(statePropertyLambda);
                    var rowVersionPropToExclude
                        = entityContainingStateProperty.Details.Properties["RowVersion"];

                    IEntityProperty[] updatedExcludeProperties = new IEntityProperty[excludeProperties.Count() + 2];
                    for (int i = 0; i < excludeProperties.Count(); i++)
                    {
                        updatedExcludeProperties[i] = excludeProperties[i];
                    }
                    updatedExcludeProperties[excludeProperties.Count()] = statePropToExclude;
                    updatedExcludeProperties[excludeProperties.Count() + 1] = rowVersionPropToExclude;
                    entityToValidate.ValidateFieldsAreUnmodified(results, updatedExcludeProperties);
                }
                else
                {
                    entityToValidate.ValidateFieldsAreUnmodified(results, excludeProperties);

                }
            }
        }

We’ll again use the permission table to check if we have CanUpdate permission given the current state:

public static bool CanUpdateEntityInState(this IEntityObject entity, string currentState)
        {
            if (entity == null)
            {
                throw new ArgumentException("entity cannot be null");
            }
            string entityName = entity.Details.Name;
            string requiredPermission
                = string.Format(CanUpdateEntityPermissionFormat, entityName, currentState);

            return Application.Current.User.HasPermission("LightSwitchApplication:" + requiredPermission);
        }

Note, that the above method makes use of the CanUpdateEntityPermissionFormat:

        private static readonly string CanUpdateEntityPermissionFormat = "CanUpdate{0}InState{1}";

The Format allows to specify update conditions for any entity type involved in the state logic.

Eventually, we’ll call this:

public static void ValidateFieldsAreUnmodified(this IEntityObject entity,
           EntitySetValidationResultsBuilder results, params IEntityProperty[] excludeProperties)
        {
            foreach (var item in entity.Details.Properties.All().OfType())
            {
                if (item.IsChanged && !excludeProperties.Contains(item))
                {
                    results.AddPropertyError(string.Format("Field {0} may not be updated", item.Name), item);
                }
            }
        }

Basically, all props are entity are checked if there are changes. We have also the ability to excluded certain properties. Why do we need this? Well, in case you state field is present inside the entity you are checking for modifications, it should be possible to exclude this field from the modification check. Obviously, the “RowVersion” field should be excluded also.

For this reason it could make sense (and the ValidateCanUpdateEntityGivenCurrentState is ready for this) to store the state field in a dedicated entity which is bound as a 1 to 0..1 relationship to the entity on which the state is applied. By doing so, you can avoid the avoid the usage of the above ExcludeProperties.

The nice thing about the exclude properties is that they can be specified in a strongly typed manner (by means of a lambda expression).

We can also apply the same validation method the the entity attached to the HolidayRequest entity:

partial void HolidayRequestManagementFeedbacks_Validate(HolidayRequestManagementFeedback entity, EntitySetValidationResultsBuilder results)
        {
            StateManagement.ValidateCanUpdateEntityGivenCurrentState(
                entity, entity.HolidayRequest,
                s => s.HolidayStateCode,
                results);
        }

We simply tell the method that the state can be found in entity.HolidayRequest and that the field is s=>s.HolidayStateCode.

the whole infrastructure class so far

using Microsoft.LightSwitch;
using Microsoft.LightSwitch.Details;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Linq.Expressions;
using System.Reflection;

namespace LightSwitchApplication
{
    public interface IStateCode : IEntityObject
    {
        string StateValue { get; }
        bool IsInitialState { get; }
    }
    public static class PropertyExtensions
    {
        public static IEntityTrackedProperty GetEntityTrackedProperty(
           this TSource entity,
           Expression> propertyLambda) where TSource : IEntityObject
        {
            string fieldName = entity.GetEntityObjectPropertyName(propertyLambda);
            return entity.Details.Properties[fieldName] as IEntityTrackedProperty;
        }

        public static string GetEntityObjectPropertyName
          (this TSource source,
          Expression> propertyLambda) where TSource : IEntityObject
        {
            MemberExpression member = propertyLambda.Body as MemberExpression;
            if (member == null)
                throw new ArgumentException(string.Format(
                    "Expression '{0}' refers to a method, not a property.",
                    propertyLambda.ToString()));

            PropertyInfo propInfo = member.Member as PropertyInfo;
            if (propInfo == null)
                throw new ArgumentException(string.Format(
                    "Expression '{0}' refers to a field, not a property.",
                    propertyLambda.ToString()));

            return propInfo.Name;
        }
    }
    public static class StateManagement
    {
        private static readonly string StateTransitionPermissionFormat = "CanDoTransitionFrom{0}To{1}";
        private static readonly string CanUpdateEntityPermissionFormat = "CanUpdate{0}InState{1}";

        public static void ValidateCanUpdateEntityGivenCurrentState(
            TEntityToValidate entityToValidate,
            TEntityContainingState entityContainingStateProperty,
            Expression> statePropertyLambda,
            EntitySetValidationResultsBuilder results, params IEntityProperty[] excludeProperties)
            where TEntityContainingState : IEntityObject
            where TEntityToValidate : IEntityObject
        {
            var stateProperty = entityContainingStateProperty.GetEntityTrackedProperty(statePropertyLambda);

            if (stateProperty.Value == null || entityToValidate.Details.EntityState == EntityState.Added) 
            {
                return;
            }
            var originalStateCode = stateProperty.OriginalValue as IStateCode;

            if (!entityToValidate.CanUpdateEntityInState(originalStateCode.StateValue))
            {
                if (entityToValidate.Equals(entityContainingStateProperty))
                {
                    // when the state field is part of the entity to validate, 
                    // the statefield and rowversion must be excluded from validation

                    var statePropToExclude
                        = entityContainingStateProperty.GetEntityTrackedProperty(statePropertyLambda);
                    var rowVersionPropToExclude
                        = entityContainingStateProperty.Details.Properties["RowVersion"];

                    IEntityProperty[] updatedExcludeProperties = new IEntityProperty[excludeProperties.Count() + 2];
                    for (int i = 0; i < excludeProperties.Count(); i++)
                    {
                        updatedExcludeProperties[i] = excludeProperties[i];
                    }
                    updatedExcludeProperties[excludeProperties.Count()] = statePropToExclude;
                    updatedExcludeProperties[excludeProperties.Count() + 1] = rowVersionPropToExclude;
                    entityToValidate.ValidateFieldsAreUnmodified(results, updatedExcludeProperties);
                }
                else
                {
                    entityToValidate.ValidateFieldsAreUnmodified(results, excludeProperties);

                }
            }
        }

        public static void ValidateStateTransition(
            TSource entityContainingTheState,
            Expression> statePropertyLambda,
            T stateCodes,
            EntitySetValidationResultsBuilder results, bool ignoreReflexiveTransitions = true)
            where T : IEntitySet
            where TSource : IEntityObject
        {
            var stateProperty = entityContainingTheState.GetEntityTrackedProperty(statePropertyLambda);
            var requestedStateCode = stateProperty.Value as IStateCode;

            if (requestedStateCode == null || entityContainingTheState.Details.EntityState == EntityState.Added)
            {
                string initialStateValue = StateManagement.GetInitialStateValue(stateCodes);
                if (requestedStateCode == null || requestedStateCode.StateValue != initialStateValue)
                {
                    results.AddEntityError(string.Format("The initial state must be {0}", initialStateValue));
                }
            }
            else
            {
                var originalStateCode = stateProperty.OriginalValue as IStateCode;

                bool stateChanged = !(originalStateCode.StateValue == requestedStateCode.StateValue);
                if (stateChanged || ignoreReflexiveTransitions == false)
                {
                    bool transitionIsAllowed
                        = StateManagement.IsStateTransitionAllowed(originalStateCode.StateValue, requestedStateCode.StateValue);
                    if (!transitionIsAllowed)
                    {
                        results.AddEntityError(string.Format("transition not allowed from {0} to {1}",
                            originalStateCode.StateValue, requestedStateCode.StateValue));
                    }
                }
            }
        }

        public static bool CanUpdateEntityInState(this IEntityObject entity, string currentState)
        {
            if (entity == null)
            {
                throw new ArgumentException("entity cannot be null");
            }
            string entityName = entity.Details.Name;
            string requiredPermission
                = string.Format(CanUpdateEntityPermissionFormat, entityName, currentState);

            return Application.Current.User.HasPermission("LightSwitchApplication:" + requiredPermission);
        }

        public static void ValidateFieldsAreUnmodified(this IEntityObject entity,
           EntitySetValidationResultsBuilder results, params IEntityProperty[] excludeProperties)
        {
            foreach (var item in entity.Details.Properties.All().OfType())
            {
                if (item.IsChanged && !excludeProperties.Contains(item))
                {
                    results.AddPropertyError(string.Format("Field {0} may not be updated", item.Name), item);
                }
            }
        }

        public static List GetAllowedStatesFor(string currentState, T stateCodes)
            where T : IEntitySet
        {
            List allowedStates = new List();
            if (string.IsNullOrEmpty(currentState))
            {
                string initialStateValue = GetInitialStateValue(stateCodes);
                allowedStates.Add(initialStateValue);
            }
            else
            {
                allowedStates.Add(currentState);

                foreach (IStateCode item in stateCodes)
                {
                    string requestedState = item.StateValue;
                    if (IsStateTransitionAllowed(currentState, requestedState))
                    {
                        allowedStates.Add(requestedState);
                    }
                }
            }
            return allowedStates;
        }

        public static string GetInitialStateValue(T stateCodes) where T : IEntitySet
        {
            var stateList = new List();
            //no better way currently than using a temp collection

            foreach (IStateCode item in stateCodes)
            {
                stateList.Add(item);
            }

            var initialStateRecord =
               stateList.Where(s => s.IsInitialState == true).Single(); // there must be one IsInitialState=true

            return initialStateRecord.StateValue;
        }

        public static bool IsStateTransitionAllowed(string currentState, string requestedState)
        {
            string requiredPermission
                = string.Format(StateTransitionPermissionFormat, currentState, requestedState);

            bool transitionIsAllowed
                = Application.Current.User.HasPermission("LightSwitchApplication:" + requiredPermission);
            return transitionIsAllowed;
        }
    }
}

How do we define the permissions for the can do behavior?

What’s next?

A client side implementation for both the html client and the silverlight client for State driven CanUpdate behavior.

State driven security in LightSwitch (part 4): client side state transition convenience.

paul van bladel — Thu, 18 Apr 2013 18:29:45 +0000

Introduction

We have so far a security server side state transition implementation. Let’s take a look now how we can use this both in an Html client and a Silverlight Client. We’ll work step-by-step because that allows us to test also our server side security implementation.

The Html Client

Simple generate a browse screen and an Add/Edit screen and out-of-the-box you’ll get this when creating a new HolidayRequest.

When we would select as initial state “OpenForApproval”, we would get following error:

Simple but effective. Also when we change state from Draft to a state which should not be allowed, we’ll get an error:

Ok great to learn that our state transitions are nicely protected. Let’s do the same for the Siverlight Client.

The silverlight client

I presume you are familiar how to construct in the silverlight client some screen for our simple scenario. But let’s try to add some extra comfort. We are convinced now that our server side state transition logic is secure, we just checked it with the html client. So, would it not be more convenient for the user if the states would be pre-filtered depending on which transitions are allowed.

So, instead of :

we want:

Given the fact our original state is “Draft”, we can only do the transition to OpenForComment or stay in Draft.

This can be simply done by changing the datasource of the StateCode field to another dedicated query with following code:

 partial void GetAllowedStates_PreprocessQuery(string currentState, ref IQueryable query)
        {
            List allowedState = StateManagement.GetAllowedStatesFor(currentState, this.DataWorkspace.ApplicationData.StateCodes);
            query = query.Where(s => allowedState.Contains(s.StateValue));
        }

We make use here again of our StateManagement class:

 public static List GetAllowedStatesFor(string currentState, IEntitySet stateCodes)
        {
            List allowedState = new List();
            allowedState.Add(currentState);

            foreach (IStateCode item in stateCodes)
            {
                string requestedState = item.StateValue;
                if (IsStateTransitionAllowed(currentState, requestedState))
                {
                    allowedState.Add(requestedState);
                }
            }
            return allowedState;
        }

Under the hood, this we’ll simply analyse the state transition related permissions in our permission table. So, we nicely reuse the functionality of the state transition validation in our previous post ! Note, we rely in the GetAllowedStateFor method on the IStateCode interface. Since we enforce that the table containing the states implements this interface we can access strongly typed the StateValue property.

But, client side, there is an important caveat here ! It’s about the query parameter of the GetAllowedStates query. Let’s first take a look at our screen’s ViewModel:

The GetAllowedStates query has a parameter called currentState. It would be very tempting to directly bind this parameter to the StateValue of the CurrentHolidayRequest. Don’t do this, because that will give unwanted side-effects. The point is that we want that our state transitions happen in discrete steps, meaning that the state is only effectively changed when the entity is saved. If we bind the currentState parameter directly to the StateValue field of the HolidayRequest Screen object, we’ll see that the list of available states changes each time we take another value in the state dropdown!

We can avoid this by creating another string based property on our ViewModel: OriginalValueOfRequestState.

We’ll provide following code:

 partial void HolidayRequestDetail_InitializeDataWorkspace(List saveChangesTo)
        {
            CurrentHolidayRequest = this.DataWorkspace.ApplicationData.HolidayRequests_SingleOrDefault(HolidayRequestId);
            OriginalValueOfRequestState = CurrentHolidayRequest.StateCode.StateValue;
        }

So, we’ll capture first the original state value and we only update this value when the HolidayRequest is saved:

 partial void HolidayRequestDetail_Saved()
        {
            OriginalValueOfRequestState = CurrentHolidayRequest.StateCode.StateValue;
        }

A better html client user experience for state transitions

We want the same level of convenience (the pre-selected states) now in the html client. That’s pretty simple:

Connect the same query (GetAllowedStates) as in the silverlight client to the Holiday State Code:

And provide following code (many thanks to Huy Nguyen for the help on the forum):

myapp.AddEditHolidayRequest.created = function (screen) {
    screen.HolidayRequest.getHolidayStateCode().then(
        function completed(result) {
            screen.OriginalValueOfRequestState = result.StateValue;
        }
    );
};

myapp.AddEditHolidayRequest.AddManagementFeedback_execute = function (screen) {
    var mgtFeedback = new myapp.HolidayRequestManagementFeedback();
    screen.HolidayRequest.setHolidayRequestManagementFeedback(mgtFeedback);
    screen.showTab("ManagementFeedback");
};
myapp.AddEditHolidayRequest.AddManagementFeedback_canExecute = function (screen) {
    return !screen.HolidayRequest.HolidayRequestManagementFeedback;
};

What next?

In a next post, we’ll provide the necessary server side material to protect (make them read-only) entities based on the state of the entity of another entity in the object graph.

State driven security in LightSwitch (part 3): server side state transition security

paul van bladel — Wed, 17 Apr 2013 19:48:06 +0000

Introduction

This post of mainly about the server side. We want to come up with a nice piece of base infrastructure with which we can protect server side the state transition of a certain entity. The base infrastructure should be treatable as a black box and should be easily consumable and easy to setup inside a LightSwitch project where state matters.

Although what follows is all about the server side, I might improve the understanding to first see things on the client: we want that when a user makes a state transition which is not allowed, she get a nice error message:

The message is clear: the user tried to change state from draft directly to approved, which is not allowed. Obviously, we add later on the necessary functionality so that client side the user could not even try to do this transition.

Where do we want to validate the state transition?

Obviously server side, because that’s the place where we protect our assets. The best place to trigger this validation is in the Validate method of the entity which carries the state. In our example the state property is part of the entity which is monitored by the state the HolidayRequest entity.

 partial void HolidayRequests_Validate(HolidayRequest entity, 
            EntitySetValidationResultsBuilder results)
        {
            StateManagement.ValidateStateTransition(
                entity,
                s => s.HolidayStateCode, 
                this.DataWorkspace.ApplicationData.StateCodes, 
                results);
        }

That’s a very simple call into the black box. Let’s first inspect the method signature:

 public static void ValidateStateTransition(
            TSource entityContainingTheState,
            Expression> statePropertyLambda,
            T stateCodes,
            EntitySetValidationResultsBuilder results, bool ignoreReflexiveTransitions = true)
            where T : IEntitySet
            where TSource : IEntityObject
        {
}

The signature has some generic parameters, but luckily we don’t need to specify the generic types when calling the method (they are auto discovered)

In case you want to go away now, think again, this was the most difficult part. I’ll explain the internals of the ValidateStateTransition method now, but you don’t need to understand all details, you can use the method as a black box !

This simple method call is doing all the heavy lifting for us. Obviously it needs to know where the state property is stored and it needs to know the name of the field containing the state (we do this via a lamdba expression in such a way things are strongly typed !). It needs also to know where the list of potential states are. The method has a optional parameter “ignoreReflexiveTransitions”. A reflexive transition is a transition from state A to state A. Kind of null transition if you want. Being able to capture such a transition can be important in very specific cases, but for most cases you just want to ignore this transition (that’s why the default value is true).

Let’s take a close look now to the ValidateStateTransition method:

 public static void ValidateStateTransition(
            TSource entityContainingTheState,
            Expression> statePropertyLambda,
            T stateCodes,
            EntitySetValidationResultsBuilder results, bool ignoreReflexiveTransitions = true)
            where T : IEntitySet
            where TSource : IEntityObject
        {
            var stateProperty = entityContainingTheState.GetEntityTrackedProperty(statePropertyLambda);
            var requestedStateCode = stateProperty.Value as IStateCode;

            if (requestedStateCode == null || entityContainingTheState.Details.EntityState == EntityState.Added)
            {
                string initialStateValue = StateManagement.GetInitialStateValue(stateCodes);
                if (requestedStateCode == null || requestedStateCode.StateValue != initialStateValue)
                {
                    results.AddEntityError(string.Format("The initial state must be {0}", initialStateValue));
                }
            }
            else
            {
                var originalStateCode = stateProperty.OriginalValue as IStateCode;

                bool stateChanged = !(originalStateCode.StateValue == requestedStateCode.StateValue);
                if (stateChanged || ignoreReflexiveTransitions == false)
                {
                    bool transitionIsAllowed
                        = StateManagement.IsStateTransitionAllowed(originalStateCode.StateValue, requestedStateCode.StateValue);
                    if (!transitionIsAllowed)
                    {
                        results.AddEntityError(string.Format("transition not allowed from {0} to {1}",
                            originalStateCode.StateValue, requestedStateCode.StateValue));
                    }
                }
            }

        }

It’s clear that the ValidateStateTransition method needs as input the current state and the requested state, but what is the current state? This is of course the state currently in the database. The state mentioned in the entity is the requested state. We don’t need to do an additional database call to get the current state value. LightSwitch is doing this already for us. We can get the “original” value of each EntityTracked property by means of following extension method:

public static IEntityTrackedProperty GetEntityTrackedProperty(
           this TSource entity,
           Expression> propertyLambda) where TSource : IEntityObject
        {
            string fieldName = entity.GetEntityObjectPropertyName(propertyLambda);
            return entity.Details.Properties[fieldName] as IEntityTrackedProperty;
        }

I make use here of an other extension method, GetEntityObjectPropertyName, I documented in a previous post. So, the extension method returns us based on a lambda expression an IEntityTrackedProperty. We’ll need this to get access to the original value of the state field.

In a first block we’ll check if there is effectively a state in the entity and if we check in the case the entity itself in “create” mode, that the state is given the mandatory initial state which we can find in our StateCode table. (remember the field “IsInitialState” is part of our IStateCode interface).

For the rest, the logic of this method is very straightforward: we’ll check if the transition is allowed and if not, we’ll fill the ValidationResult object with a nice error message. Note also the logic for the reflexive transitions.

As explained earlier, we’ll use the build-in permission mechanism of LightSwitch to keep track of the allowed transitions:

The permissions follow a strict naming scheme. By doing so we can use it directly in code:

    private static readonly string StateTransitionPermissionFormat = "CanDoTransitionFrom{0}To{1}";

The current schema presumes that we only have one state aware entity in our app. Of course the format can be easily extended to support more state aware entities: “CanDo{0}TransitionFrom{1}To{2}”. where {0} can be replaced by the state aware entity (e.g. HolidayRequest).

Now we are close to the actual verification of the state transition, which is really as simple as possible but no simpler:

public static bool IsStateTransitionAllowed(string currentState, string requestedState)
        {
            string requiredPermission
                = string.Format(StateTransitionPermissionFormat, currentState, requestedState);

            bool transitionIsAllowed
                = Application.Current.User.HasPermission("LightSwitchApplication:" + requiredPermission);
            return transitionIsAllowed;
        }

The method for retrieving the InitialState goes as follows:

public static string GetInitialStateValue(T stateCodes) where T : IEntitySet
        {
            var stateList = new List();
            //no better way currently than using a temp collection

            foreach (IStateCode item in stateCodes)
            {
                stateList.Add(item);
            }

            var initialStateRecord =
               stateList.Where(s => s.IsInitialState == true).Single(); // there must be one IsInitialState=true

            return initialStateRecord.StateValue;
        }

Consume the permissions in a specific role

Let’s configure now, as an example the permissions for the Manager role. It’s always a good practice to limit the permissions of managers to the strictest mininum In our example they only get the permission to approve or reject a holiday request:

What’s the advantage of this approach?

It’s cool because there is no magic involved, it simply uses all goodness of LightSwitch, nothing more and nothing less.

Adding a new transition only boils down to adding a new entry in the permission table. Do you know that you even do not need to recompile the application when you would be need to add a new transition? This is since we don’t have any hard coded reference to our transitions inside the application. Simply add the the new permission directly in the database table. Of course when you don’t use the permission designer, the permission will not be available in the LightSwitch security screens, where you can compose a role by selecting the various permissions.

An alternative approach could be to add upfront all theoretically possible permissions, so the mathematical product set. In case you have 3 permissions (A,B,C) that would be

CanDoTransitionFromAToB
CanDoTransitionFromAToC
CanDoTransitionFromBToA
CanDoTransitionFromBToC
CanDoTransitionFromCToA
CanDoTransitionFromCToB

Of course for large state diagrams, this can become cumbersome, so I would simply stick to the first approach.

The most important advantage is that the call to the ValidateStateTransition method is a nice black box, but it is not really relying on a whole series of assumptions nor conventions.

The only code prerequisite is that that the field which carries the state must be an entity which implement IStateCode, that’s all.

Secondly we need of course the permission table setup and here we need to follow the naming convention of the state transition permissions we defined in code ( CanDoTransitionFrom{0}To{1}

What could still be improved?

The only magic strings we have now are in the permission table and they are functionally dependent on the values in our StateCode table. The permissions are inside the project model file (the .lsml file). I have done already some research on how to generate strongly typed material from the model file. See my post on strongly typed code values. In this approach I’m reading from the model file. In case we would like to improve this state transition permission approach, it could be interesting to write the permissions directly into the model file based on the information coming from a permission designer. Would be cool, but I’m quite reluctant to do so. I think that the model file is the domain of the LightSwitch product team, we should not touch it

What’s next?

We have now a secure server side framework method for the state transitions. How will we consume this client side and add some comfort so that the user can not select state transitions which are not allowed.