Available for download here, you’ll find the first step in taking a-Expense to Windows Azure. Highlights of this release are:

1. Use of SQL Azure as the backend store for application entities (e.g. expense reports)
2. Uses Azure storage for user profile information (the “Reimbursement method” user preference)
3. Application no longer queries AD for user attributes needed in the application (Cost Center and employee’s Manager, the expense default approver). These are received as claims in the security token issued by Adatum’s STS.
4. Authentication is now claims based.  
5. Logging and tracing are now done through Windows Azure infrastructure.
6. Deployment to Windows Azure is automated.

#1 is straight forward thanks to SQL Azure relatively high fidelity with SQL Server.

For #2, we used the providers included in the Windows Azure training kit (with a few modifications/simplifications). The main challenge here is to initially migrate the data from the “on premises” SQL Server to Azure storage.

#3 is relatively simple by using WIF. The main changes are in the UserRepository class where instead of calling the (Simulated)LDAPProvider, we simply inspect the claims collection in the current principal:

#4 requires “claims enabling” a-Expense. Look inside the web.config for all extra config sections added by WIF:

It also requires a valid “Issuer” of claims. We have included a “Simulated” Issuer that creates the token we need. You’ll find this as part of the solution:

And of course in the application configuration:

We are also using a WIF configuration that is “web farm friendly”. Check the global.asax file for details. Here’s a note on the Claims Guide hat talks about it:

#5 is also rather simple. Because we are using EntLib blocks, we just defined the right trace listener:

The complement to this is a new class in the project (WebRole) where all the initialization happens:

#6 is just a bunch of PowerShell scripts. We are using the Azure CmdLets built by Ryan’s team which are great! These hide us all the underlying details of the Windows Azure Management API.

Some lessons learned

1. Request information to Azure Mgmt API is case sensitive. We spent quite some time with a silly bug that was just misspelling “aExpense” (it should have been “aexpense”). You don’t get a very insightful error message (“Invalid request”).
2. As expected, it is a good practice to polish as much as possible on the local development environment before uploading the application to the cloud. You can also test portions online and on-premises (for example: your website can run on the dev fabric, and connect to SQL Azure). We are still working on the details and recommendations.
3. “Deployment stuck”: sometimes there’s something wrong in the package that prevents the app to start. For example, a missing assembly. The symptom is that the deployment never starts and no errors are reported. This is because the startup of the app fails before diagnostics is initialized.
4. Use of the API for deployments also allows us to share access to our Windows Azure environment without sharing the (single) LiveID account. Remember the API is protected with a set of certificates that can be individually distributed and revoked.