We are making a test drive of 3 NoSQL engines:

• Azure Table Storage: key – value
• Amazon SimpleDB: key – value
• MongoDB: document based

All of them do not support System.Decimal, therefore if you want to store currencies, exchange rates, large amounts with decimal digits, you’ll have to find a workaround. For the POC we have decided to go for double type, but during communications with real POS terminals ISO8583 protocol is used. In it amounts are divided in 2 separate parts:

• Amount: total amount with integer part followed by mantissa without separatore (i.e. 100,91 becomes 10091)
• MinorUnit: number of decimal digits (i.e. considering 100,91 it is 2)

Here follows a short summary table of types supported by the 3 engines:

Amazon has decided to use a simpler technical implementation for its NoSQL on the cloud, but this lead to some limitations: values are all stored as strings with a maximum size limited to 1024 bytes and comparison is lexicographic, therefore for SimpleDB 10 is before 2, so developers have to do some additional work (losing a bit of performance on application code) to handle numeric values: http://aws.amazon.com/articles/1232

Note: it’s always possible to implement an event handler to be called during reading/writing operation against NoSQL above, to be used to convert Decimal to string and viceversa.

Stay tuned for the next stop!

Now to figure out exactly where the problem was I used JustDecompile (since the good old Reflector is no longer free, I tried the beta of JustDecompile from Telerik) and I decompiled the CloudQueueMessage by Microsoft.WindowsAzure.StorageClient.dll and … surprise! In the constructor there’s a nice hard-coded limit to 8192 bytes in the MaxMessageSize property:

CloudQueueMessage.MaxMessageSize = (long) 8192;

How to solve the problem? By downloading the 1.6 SDK Azure where the client libraries have been updated with the new limits and the same dll decompiled now has:

CloudQueueMessage.MaxMessageSize = (long) 65536;

We’ll try everything a lot of things:

• Azure Table Storage – SimpleDB: as NoSQL to save and retrieve large amounts of data
• Blob Storage – S3 to store large sets of data
• Azure Queue – SQS: for communication between the different roles within the same region
• Azure SQL – MySql: for relational data on the cloud
• SQL Data Sync: to synchronize distributed databases cloud – OnPremise
• Bus Service – SNS + SQS: to use publish/subscribe pattern for data distribution between the region and OnPremise
• Traffic Manager: to automatically balance the client calls to the nearest Azure region
• MongoDB: there will be experiments to compare a NoSQL Document based like MongoDB with the key-value solutions offered by Microsoft and Amazon
• Other: MEF, AutoMapper, AppFabric, Caching, TPL

Let’s start the journey!

I was performing a simple query against Azure Table Storage using PartitionKey and RowKey in order to retrieve a specific entity in a specific table (i.e.: http://127.0.0.1:10002/devstoreaccount1/Spaceship(PartitionKey=’380′,RowKey=’1234′)).

During tests, the first scenario was where no entities with give PK and RK were present and I was using a simple query ending with FirstOrDefault operator like 

TableRepository.FindWhere(p => p.PartitionKey == entity.Spaceship.CountryCode.ToString() &&
        p.RowKey == entity.SerialNumber).FirstOrDefault();

and I was expecting null but in reality I started to get 404 error with detailed message below:

<error xmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
  <code>ResourceNotFound</code>
  <message xml:lang="en-US">The specified resource does not exist.</message>
</error>

After several hours struggling with various tests I discovered following Pearls of Azure Wisdom:

- Internet Explorer can’t be used to query directly table storage account, it does not return results at all, because

- You have to set IgnoreResourceNotFoundException = true in the TableServiceContext in order to receive null when an entity is not found instead of error 404

Clearly I have tried everything but without success

Solution:

• Take the file directly from Agile 5 Process Template from Microsoft (MSF for Agile Software Developmentv5.0 \ Windows SharePoint Services \ Shared Documents \ Project Management) and copy it to your Project Portal
• Open it and press Edit Workbook
• Go to the Team tab and select Configure -> Server Connection
• Press OK on the popup
• Select your project and press Connect
• Press List and select New Query Product Planning pressing OK
• Save and you have your file again!

Technology breaks any barrier!

The procedure below enables you to assign work items to groups or to their users.

In order to enable this you have to:

1. open work item type Bug in the specific project
   
2. modify Assigned To field adding ALLOWEDVALUES rule with the list of all TFS groups containing users that can receive a work item assignment. be sure to leave Exclude Groups unchecked
   
3. remove VALIDUSER rule, because this is responsible for not showing groups in the dropdown list of values for Assigned To field
4. save and close

Now if you open a new bug you’ll be able to assign it to groups or directly to their users

“Cannot find connection string for connection name ‘ApplicationServerWorkflowInstanceStoreConnectionString’”

Solution: After deep investigation we discovered that the issue was due to the fact that AppPool used to host the service was configured with Enable 32-bit applications flag set to true, therefore it was reading a different machine config file (for 32-bit apps), that is not changed by the AppFabric configuration wizard (Bug? By design? I’ll open a Connect ticket). Setting flag to false solved the issue!

Hope this helps