Web Roles

Web roles run within IIS are designed to host web applications that provide services for clients over HTTP or HTTPS; therefore, a web role is where code is typically written for building a web application that resides when using cloud services. More than one web role can be created and run at a given time.

Worker Roles

A worker role runs on a separate thread from a web role and is typically used to run background business processes for a web role in order to provide a level of work for the application. The worker role is continuously being executed, for example, as a client executes specific functionality from a web application that is hosted within a web role; tasks can be generated that the worker role can handle asynchronously on a separate thread. When a worker role is added to a project within Visual Studio, the default WorkerRole class illustrated in Listing 12-1 is provided, which basically loops through every 10 seconds and writes “Working” within the compute emulator UI (which will be discussed later).

Listing 12-1.  Default WorkerRole Code

using System;
using System.Collections.Generic;
using System.Diagnostics;
using System.Linq;
using System.Net;
using System.Threading;
using Microsoft.WindowsAzure;
using Microsoft.WindowsAzure.Diagnostics;
using Microsoft.WindowsAzure.ServiceRuntime;
using Microsoft.WindowsAzure.StorageClient;

namespace WorkerRole1
{
    public class WorkerRole : RoleEntryPoint
    {
        public override void Run()
        {
            // This is a sample worker implementation. Replace with your logic.
            Trace.WriteLine("WorkerRole1 entry point called", "Information");

            while (true)
            {
                Thread.Sleep(10000);
                Trace.WriteLine("Working", "Information");
            }
        }

        public override bool OnStart()
        {
            // Set the maximum number of concurrent connections
            ServicePointManager.DefaultConnectionLimit = 12;

            // For information on handling configuration changes
            // see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId=166357.

            return base.OnStart();
        }
    }
}

Role Scalability

Each role is designed to be run either together or separately depending on the requirements of the software that is hosted; however, because they are essentially virtual machines at the core, the charge applies to each hour a role is running. There can also be more than one of each type of role running simultaneously, and each instance of the same type of role running would use the same code. The reason for running more than one role, either a web or worker role, is to provide better performance and high availability in the case of instance failure. Both web and worker roles provide the code and configuration for handling the different parts of software functionality.

Roles can also be configured to handle scalability defined from client utilization. The size of the VM can be changed based on the number of CPU cores, memory, and file system size dedicated to running a VM instance. Table 12-1 illustrates the different sizes that can be selected for scaling out cloud service roles.

Table Storage

Table storage is used for storing large amounts of data that can be organized in a tabular format, but the data stored does not need to be structured as relational data within a database like SQL Server. For instance, the other day my wife, who works in the education field, was asking me about storing student data within a spreadsheet. I was impressed at how well she had organized each column within the spreadsheet to represent a characteristic for the student data and thought how table storage would make a good candidate. Another example for using table storage is storing logging information that records an application’s performance. Although a case can be made to store logging data within a database, it might make more sense to hold large amounts of logging data within table storage. For one thing, it will help the application scale because there is less demand on the database; moreover, because space is plentiful, it can be a cheaper option as well.  

Initiating Queues in Web Roles

To illustrate how Azure queues can be used, I will demonstrate how to add a web role, which will serve as the web front-end for receiving pawned items from customers; this is somewhat similar to how a worker role was added earlier. A web role can be added to the project that was created for the worker role earlier. By right-clicking on the Roles folder in the Windows Azure Cloud Service project that was used to create the worker role earlier, a new web role can be added by selecting New Web Role Project (see Figure 12-11).

Selecting an ASP.Net web role as illustrated in Figure 12-12 will add a project (which is probably familiar when compared to a standard ASP.NET project).

Figure 12-13 shows the WebRole1 project that was added and all of the default pages and folders that are included.

In this scenario, the message queue will be stacked with messages that are created within the web application. To illustrate how messages are created, the code in Listing 12-4 is added to the Default.aspx web page as well as the appropriately named textboxes within the HTML to build customer information for pawned items.

Listing 12-4.  Initiating and Creating Messages for the Queue

using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Apress.Chapter12.DataModel;
using Microsoft.WindowsAzure;
using Microsoft.WindowsAzure.ServiceRuntime;
using Microsoft.WindowsAzure.StorageClient;

namespace WebRole1
{
    public partial class _Default : Page
    {
        private const string QueueName = "customerqueue";
        private CloudStorageAccount StorageAccount = null;
        private CloudQueue InitiateAzureQueue()
        {
            CloudQueue CustomerQueue = null;
            try
            {
                StorageAccount =
CloudStorageAccount.Parse(RoleEnvironment.GetConfigurationSettingValue("DataConnectionString"));
                var queueClient = StorageAccount.CreateCloudQueueClient();
                CustomerQueue =
                queueClient.GetQueueReference(QueueName);
                CustomerQueue.CreateIfNotExist();
            }
            catch (Exception ex)
            {
                throw ex;
            }
            return CustomerQueue;
        }
        protected void Page_Load(object sender, EventArgs e)
        {
        }
        protected void cmdSubmit_Click(object sender, EventArgs e)
        {
            try
            {
                var customer = new Customer()
                {
                    DOB = Convert.ToDateTime(txtDOB.Text),
                    DriversLicenseNumber = txtDriverLicense.Text,
                    FirstName = txtFirstName.Text,
                    LastName = txtLastName.Text,
                    OwnersSSN = txtSSN.Text,
                    CustomerPawns = new List<CustomerPawn>
                   {
                        new CustomerPawn()
                        {
                            PawnedItems = new List<PawnedItem>
                            {
                                new PawnedItem{
                                    ItemName = txtItemName.Text,
                                    PawnedAmount = Convert.ToDecimal(txtAmount.Text),
                                    ModelNumber = txtModelNumber.Text
                                }
                            }
                        }
                   }
                };

                var customerQueue = InitiateAzureQueue();
                var newMessage = new CloudQueueMessage(customer.ToJson());
                customerQueue.AddMessage(newMessage);
            }
            catch (Exception ex)
            {
                throw ex;
            }
        }
    }
}

While reviewing Listing 12-4, the first thing to mention is the following line of code:

StorageAccount =
   CloudStorageAccount.Parse(RoleEnvironment.GetConfigurationSettingValue("DataConnectionString"));

Note that DataConnectionString represents the setting used to indicate that development storage should be used. Development storage is provided with the Azure SDK that was installed earlier. It uses a local database simulating managed resources like queues, blobs, etc. The setting has to be created within ServiceConfiguration.Local.cscfg and ServiceConfiguration.Cloud.cscfg, as illustrated in Listing 12-5.

Listing 12-5.  Configuring Development Storage for Testing Azure Locally

<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration serviceName="Apress.Chapter12" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="1" osVersion="*" schemaVersion="2012-05.1.7">
  <Role name="WorkerRole1">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="DataConnectionString" value="UseDevelopmentStorage=true" />
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="" />
    </ConfigurationSettings>
  </Role>
  <Role name="WebRole1">
    <Instances count="1" />
    <ConfigurationSettings>
      <Setting name="DataConnectionString" value="UseDevelopmentStorage=true" />
      <Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
    </ConfigurationSettings>
  </Role>
</ServiceConfiguration

The rest of the code for setting up a queue in Listing 12-4 is pretty straightforward. The InitiateAzureQueue() function initiates a new queue called customerqueue, which allows messages to be added to a queue using an Azure storage account. In this case, the development storage is used locally to simulate how the queues function within Azure, but once this code is deployed to the cloud, a storage account must be created to host the queue within Azure. After the storage account is established, a CloudQueueClient object is created and used to reference to the customerqueue queue. If the queue does not exist, then it is created. After the queue is created, the CloudQueue object is returned and messages can be added to it.

Within the Page_Load event for the Default.aspx page, a new Customer object is instantiated and loaded with data that the customer wants to pawn. After the Customer object is loaded, the queue is initiated by calling InitiateAzureQueue, so a new CloudQueueMessage is created and added to the queue. The message that is queued consists of JSON, which is created by serializing the Customer object. The code in Listing 12-6 illustrates the code used for serializing a Customer object to JSON and deserializing JSON as string data back to a Customer object. Listing 12-6 uses code extensions, which allows the ToJson function to be called from any Customer object and is demonstrated in Listing 12-4. The FromJson function can be called from any string object and will be demonstrated later as the message from the queue is later read from a worker role. The magic of serialization and deserialization is handled by using the DataContractJsonSerializer.

Listing 12-6.  Serializing a Customer Object and Deserializing Back to an Object

using System;
using System.Collections.Generic;
using System.IO;
using System.Linq;
using System.Text;

using System.Runtime.Serialization;
using System.Runtime.Serialization.Json;

namespace Apress.Chapter12.DataModel
{
    public static class extCustomer
    {
        public static string ToJson(this Customer customer)
        {
            using (var ms = new MemoryStream())
            {
                DataContractJsonSerializer serializer = new DataContractJsonSerializer(typeof(Customer));
                serializer.WriteObject(ms, customer);
                ms.Position = 0;
                return new StreamReader(ms).ReadToEnd();
            }
        }

        public static object FromJson(this string Json)
        {
            DataContractJsonSerializer serializer = new DataContractJsonSerializer(typeof(Customer));
            var retCustomer =
                serializer.ReadObject(new MemoryStream(Encoding.Default.GetBytes(Json)));
            return retCustomer;
        }
    }
}

Consuming Queues within Worker Roles

Now that the queues have been created and messages can now be added to the queues, a worker role can be used to consume the message. Listing 12-7 illustrates some changes within the WorkerRole code compared to Listing 12-3. The WorkerRole code in Listing 12-7 is written to now process external data from a queue workflow and receive WF arguments based on the messages read from the queue. The first two lines of code look familiar because this is the same code used to initialize communication to an Azure queue. The last function in Listing 12-7, InitiateAzureQueue(), uses the same code that the web page code used in Listing 12-4 to initialize the queue. The code within the Run() method for processing a queue is important. After a customerQueue object is initialized by calling IntializeAzureQueue(), customerQueue.GetMessage() is called to retrieve customer data represented as JSON. If a message has not been added to the queue, then the processing thread goes idle for 10 seconds.

Making the processing thread go to sleep for a bit after checking for a message is good practice and reduces the number of transactions, which in return saves money on your monthly Azure bill. There is a common algorithm for measuring transaction efficiency called truncated exponential backoff. It times the rate for transactions within a process so that they are processed affectively. The message is then deserialized back into a Customer object so it can be added as a WF argument that a workflow can use as data for processing. After the workflow processes successfully while being hosted through the WorkflowInvoker, DeleteMessage is called so that the message is removed from the queue and a new message can be retrieved from the queue.

Listing 12-7.  Consuming Queues Using a WorkerRole

public class WorkerRole : RoleEntryPoint
    {
        private const string QueueName = "customerqueue";
        private CloudStorageAccount StorageAccount = null;

        public override void Run()
        {
            // This is a sample worker implementation. Replace with your logic.
            Trace.WriteLine("WorkerRole1 entry point called", "Information");

            Trace.WriteLine("Initiating storage account", "Information");
            StorageAccount =
CloudStorageAccount.Parse(RoleEnvironment.GetConfigurationSettingValue("DataConnectionString"));
           var customerQueue = InitiateAzureQueue();
             
            while (true)
            {
                try
                {

                    var wfData = customerQueue.GetMessage();
                    if (wfData == null)
                    {
                        Thread.Sleep(10000);
                        Trace.WriteLine("No message in queue! Waiting 10 seconds...", "Information");
                    }
                    else
                    {
                        try
                        {
                            var newCustomer = wfData.AsString.FromJson() as Customer;
                            var activity = new Apress.Chapter12.WF.ProcessPawnedItems();
                            var inargs =
                                new Dictionary<string, object> { { "argNewCustomer", newCustomer } };
                            WorkflowInvoker wfInvoker = new WorkflowInvoker(activity);
                            wfInvoker.Invoke(inargs);
                            customerQueue.DeleteMessage(wfData);
                            Trace.WriteLine("Processed Message!", "Information");

                        }
                        catch (Exception ex)
                        {
                            throw ex;
                        }
                    }
                }
                catch (Exception ex)
                {
                    Trace.WriteLine(ex.Message,"Exception");
                }
            }
        }

        public override bool OnStart()
        {
            // Set the maximum number of concurrent connections
            ServicePointManager.DefaultConnectionLimit = 12;

            // For information on handling configuration changes
            // see the MSDN topic at http://go.microsoft.com/fwlink/?LinkId=166357.

            return base.OnStart();
        }

        private CloudQueue InitiateAzureQueue()
        {
            CloudQueue CustomerQueue = null;
            try
            {
                var queueClient = StorageAccount.CreateCloudQueueClient();

                CustomerQueue =
                queueClient.GetQueueReference(QueueName);
                CustomerQueue.CreateIfNotExist();
            }
            catch (Exception ex)
            {
                throw ex;
            }
            return CustomerQueue;
        }

Now that a workflow can accept WF arguments built from the queue of new customers, let’s take a look at the workflow that will process customer orders within the pawn shop. Figure 12-14 illustrates a flowchart workflow that uses a custom WF activity that inherits from CodeActivity<result>. Listing 12-8 shows the code used for SaveCustomer activity.

Listing 12-8.  SaveCustomer Activity Code

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Activities;
using Apress.Chapter12.DataModel;

namespace Apress.Chapter12.WF
{
    public sealed class SaveCustomer : CodeActivity<bool>
    {
        public InArgument<Customer> NewCustomer { get; set; }

        protected override bool Execute(CodeActivityContext context)
        {
            bool retVal = false;
            try
            {
                var newCustomer = context.GetValue(this.NewCustomer);

                using (var pawning = new Pawning())
                {
                    pawning.Customers.Add(newCustomer);
                    pawning.SaveChanges();
                }
                retVal = true;
            }
            catch (Exception ex)
            {
                throw ex;
            }
            return retVal;
        }
    }
}

The code that actually adds a customer and pawned items is defined within a separate C# project, Apress.Chapter12.DataModel. It uses Entity Framework 4 and a Code First model for building the database and tables based on the entity classes defined to handling the data plumbing for SQL Server.

There are three entities used for defining a customer and items that the customer pawns. Customer.cs, illustrated in Listing 12-9, defines the properties that need to be captured for a customer.

Listing 12-9.  Customer.cs Class

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ComponentModel.DataAnnotations;
using System.Collections.ObjectModel;

namespace Apress.Chapter12.DataModel
{
    public class Customer
    {
        public Customer()
        {
            CustomerPawns = new Collection<CustomerPawn>();
        }
        [Key]
        public int CustomerId { get; set; }
        [Required]
        public string FirstName { get; set; }
        [Required]
        public string LastName { get; set; }
        [Required]
        public string OwnersSSN { get; set; }
        [Required]
        public string DriversLicenseNumber { get; set; }
        [Required]
        public DateTime DOB { get; set; }

        public virtual  ICollection<CustomerPawn> CustomerPawns { get; set; }
    }
}

PawnedItem.cs, illustrated in Listing 12-10, defines the properties needed to save information about the items that a customer is pawning.

Listing 12-10.  PawnedItem.cs Class

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ComponentModel.DataAnnotations;

namespace Apress.Chapter12.DataModel
{
    public class PawnedItem
    {
        public PawnedItem()
        {
            DatePawned = DateTime.Now;
        }
        [DatabaseGenerated(DatabaseGeneratedOption.Identity)]
        public int PawnedItemId { get; set; }
        [Key]
        public int CustomerPawnId { get; set; }
        [Required]
        public string ModelNumber { get; set; }
        [Required]
        public string ItemName { get; set; }
        public DateTime DatePawned { get; set; }
    }
}

CustomerPawn.cs, illustrated in Listing 12-11, defines the properties needed to bridge the relationship between the customer and the items that are being pawned.

Listing 12-11.  CustomerPawn.cs Class

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ComponentModel.DataAnnotations;
using System.Collections.ObjectModel;

namespace Apress.Chapter12.DataModel
{
    public class CustomerPawn
    {
        public CustomerPawn()
        {
            PawnedItems = new Collection<PawnedItem>();
        }

        [Key]
        public int CustomerPawnId { get; set; }
        [Required]
        public int CustomerId { get; set; }
        [Required]
        public virtual ICollection<PawnedItem> PawnedItems { get; set; }

    }
}

Listing 12-12 shows the code that Entity Framework uses to define the database tables and relationships between each of the tables.

Listing 12-12.  Pawning.cs Class

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data.Entity;

namespace Apress.Chapter12.DataModel
{
  public sealed class Pawning : DbContext
  {
     public DbSet<CustomerPawn> CustomerPawns { get; set; }
     public DbSet<PawnedItem> PawnedItems { get; set; }
     public DbSet<Customer> Customers { get; set; }

     protected override void OnModelCreating(DbModelBuilder modelBuilder)
     {
         modelBuilder.Entity<CustomerPawn>()
             .HasMany<PawnedItem>(ItemsPawned => ItemsPawned.PawnedItems);

         modelBuilder.Entity<PawnedItem>()
             .HasKey(p => new { p.CustomerPawnId, p.PawnedItemId });

         modelBuilder.Entity<Customer>()
             .HasMany<CustomerPawn>(pawnedItems => pawnedItems.CustomerPawns);
     }
  }
}

Now when the solution is run, customer data defined within a web role is queued and then processed out of the queue within the worker role. The worker role then sends the queued data to a workflow, which will process the information about the customer and the item being pawned.

Blob Storage Loaded from a Rehosted Designer

Chapter 10 demonstrated how to rehost the WF designer, so some of the code from Chapter 10 needs to be modified so that workflows built by the rehosted WF designer can be stored as blob storage within Azure instead of stored locally using the file system. The first step to using blob storage within an application is to reference Microsoft.WindowsAzure.StorageClient and System.Configuration within the project and then add the following using statements:

using Microsoft.WindowsAzure.StorageClient;
using Microsoft.WindowsAzure;
using System.Configuration;

The next step is to make sure that the SaveCustomer activity is provided within the rehosted activity toolbox. Instead of copying the code to the solution, references to the appropriate assemblies can be made instead by referencing

• Apress.Chapter12.DataModel
• Apress.Chapter12.WF
• EntityFramework

And then by adding a Window.Resources entry within the XAML markup called PawnShopAssembly.

<Window.Resources>
        <sys:String x:Key="WFAssembly">System.Activities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35</sys:String>
        <sys:String x:Key="PawnShopAssembly">Apress.Chapter12.WF, Version=1.0.0.0, Culture=neutral</sys:String>
    </Window.Resources>

Finally, you must add the SaveCustomer activity to the toolbox using the XAML markup.

<WFC:ToolboxItemWrapper  AssemblyName="{StaticResource PawnShopAssembly}">
                            <WFC:ToolboxItemWrapper.ToolName>
                                Apress.Chapter12.WF.SaveCustomer
                            </WFC:ToolboxItemWrapper.ToolName>
                        </WFC:ToolboxItemWrapper>

A default Customer WF argument can also be set as a default argument with the code in Listing 12-15. As a new workflow is initialized, it will already have an argument added as an InArgument so a new Customer object can be passed into the workflow.

Listing 12-15.  Setting a Default Customer Argument

private ActivityBuilder BuildBaseActivity()
        {
            try
            {
                ActivityBuilder builder = new ActivityBuilder
                {

                    Name = txtWorkflowName.Text!=string.Empty?txtWorkflowName.Text:txtWorkflowName.Text,
                    Implementation = new Flowchart(),
                    Properties =
                    {
                        new DynamicActivityProperty
                        {
                             Name = "argNewCustomer",
                             Type = typeof(InArgument<Apress.Chapter12.DataModel.Customer>),
                             Attributes =
                             {
                                 new RequiredArgumentAttribute(),
                             },
                             Value = new InArgument<Apress.Chapter12.DataModel.Customer>()
                        }
                    }
                };

                return builder;
            }
            catch (Exception)
            {

                throw;
            }
        }

At this point, the workflow author can take advantage of the SaveCustomer activity using a default Customer WF argument for the workflow. Saving the workflow requires initiating blob storage when the application starts by creating a global variable for holding the CloudBlobContainer object and setting it within the class’s constructor, RehostedWFThroughMarkup.

CloudBlobContainer _blobContainer = null;
         
public RehostedWFThroughMarkup()
{
   InitializeComponent();
   _blobContainer = InitiateBlobStorage();
}

The code in Listing 12-16 is used to initialize the blob storage. ConfigurationManager.AppSettings allows blob storage to be configured using a configuration file. In this case, an app.config file is used. The CreateContainerReference() call applies a unique name for the blob container, workflows, so that the blob container can be uniquely referenced. If the blob container of workflows does not exist, then it is created, setting public access to only clients with the right credentials.

Listing 12-16.  Initializing Blob Storage

private CloudBlobContainer InitiateBlobStorage()
        {
            CloudBlobContainer blobContainer = null;
            try
            {
                var StorageAccount =
                CloudStorageAccount.Parse(ConfigurationManager.AppSettings["DataConnectionString"]);

                var blobClient = StorageAccount.CreateCloudBlobClient();
                blobContainer = blobClient.GetContainerReference("workflows");

                blobClient.RetryPolicy = RetryPolicies.Retry(3, TimeSpan.FromSeconds(5));

                if (blobContainer.CreateIfNotExist())
                {
                    var permissions = new BlobContainerPermissions() { PublicAccess = BlobContainerPublicAccessType.Off };
                    blobContainer.SetPermissions(permissions);
                }

                return blobContainer;
            }
            catch (Exception ex)
            {
                throw ex;
            }
        }

The app.config file configures access to the blob storage account by specifying a connection string within the appSettings section of the file. The account key and name can be found within the Azure Portal.

<appSettings>
    <add key="DataConnectionString" value="DefaultEndpointsProtocol=https;AccountName=<AccountName>;AccountKey=<AccountKey>"/>
  </appSettings>

Finally, the code used to save the XAML file representing a workflow using the rehosted WF designer is illustrated in Listing 12-17. It is the same code from Chapter 10, except the code for saving the XAML file to the file system has been commented out and replaced with new code that allows the generated file to be saved within blob storage. A reference to the blob container is obtained and then the XAML representing the workflow is uploaded to blob storage.

Listing 12-17.  Saving Workflow XAML Markup in Blob Storage

private void cmdSave_Click(object sender, RoutedEventArgs e)
        {
            try
            {
                if (!string.IsNullOrWhiteSpace(txtWorkflowName.Text))
                {
                    if (_wd!=null)
                    {
                        _wd.Flush();
                        //if (_wd.Text.Length>0)
                        //{
                        //    var wfFile = Directory.GetCurrentDirectory() + WorkflowFolder + txtWorkflowName.Text + ".xaml";

                        //    if (!Directory.Exists(Directory.GetCurrentDirectory() + WorkflowFolder))
                        //        Directory.CreateDirectory(Directory.GetCurrentDirectory() + WorkflowFolder);
                        //    //else //Directory exists
                        //    //    File.OpenWrite(wfFile);
                             
                        //    _wd.Save(wfFile);
                        //}
                        var blobRef = _blobContainer.GetBlobReference(txtWorkflowName.Text + ".xaml");
                        blobRef.UploadText(_wd.Text);
                    }
                    else
                        MessageBox.Show("Please press 'Create' to build a new workflow!");
                }
                else
                {
                    MessageBox.Show("Please enter a workflow name!");
                }
            }
            catch (Exception ex)
            {
                throw ex;
            }
        }

Consuming Blob Storage within a Worker Role

Now that workflows are loaded within the blob storage, the worker role can easily consume them so they can be executed. Listing 12-18 illustrates in bold the code required to consume a workflow from blob storage. A blob reference is made to PawnShopWorkflow.xaml, which is the name of the workflow that is saved within the rehosted workflow designer. Then the workflow is downloaded into the MemoryStream object so it can be dynamically loaded as an Activity object and executed using WorkflowInvoker.

Listing 12-18.  Consuming Workflows from Blob Storage within a WorkerRole

public override void Run()
        {
            // This is a sample worker implementation. Replace with your logic.
            Trace.WriteLine("WorkerRole1 entry point called", "Information");

            Trace.WriteLine("Initiating storage account", "Information");
            StorageAccount =
CloudStorageAccount.Parse(RoleEnvironment.GetConfigurationSettingValue("DataConnectionString"));
            var customerQueue = InitiateAzureQueue();
             
            var blobContainer = InitiateBlobStorage();

            while (true)
            {
                try
                {

                    var wfData = customerQueue.GetMessage();
                    if (wfData == null)
                    {
                        Thread.Sleep(10000);
                        Trace.WriteLine("No message in queue! Waiting 10 seconds...", "Information");
                    }
                    else
                    {
                        try
                        {
                  var newBlob = blobContainer.GetBlobReference("PawnShopWorkflow.xaml");
                            var ms = new System.IO.MemoryStream();
                            newBlob.DownloadToStream(ms);
                            ms.Position = 0;
                             
                            var activity = ActivityXamlServices.Load(ms);

                            var newCustomer = wfData.AsString.FromJson() as Customer;
                            //var activity = new Apress.Chapter12.WF.ProcessPawnedItems();
                             
                            var inargs =
                                new Dictionary<string, object> { { "argNewCustomer", newCustomer } };
                            WorkflowInvoker wfInvoker = new WorkflowInvoker(activity);
                            wfInvoker.Invoke(inargs);
                            customerQueue.DeleteMessage(wfData);
                            Trace.WriteLine("Processed Message!", "Information");

                        }
                        catch (Exception ex)

Now, as the worker role reads a workflow serialized within blob storage, a workflow authored from the rehosted designer and created with the name PawnShopWorkflow, as illustrated in Figure 12-24, can be consumed. The new workflow is then downloaded from blob storage, so as new customer information is gathered through the web page, queued customer information is retrieved from within the worker role. The customer data is then executed within the workflow.

Now let’s pretend that local pawn shops have had a problem with items being pawned by customers under 21. The rules for processing new customers are handled through the workflow so the logic can be changed to make sure that only customers 21 and up can pawn items. Figure 12-25 shows that the workflow has been modified by adding an If activity to check if the date of birth passed in on the customer object indicates that the customer is 21 or over. I also added a new WF argument that will return a string to the workflow host. Assign activities were added to indicate to the workflow host when customers are old enough to pawn items and when they are too young. To handle the new WF argument called argResponse, the worker role code was modified for hosting the workflow (see Listing 12-19).

Listing 12-19.  Tracing the Returned WF Argument argResponse

try
       {
          var args = wfInvoker.Invoke(inargs);

          if (args["argResponse"]!=null)
             Trace.WriteLine(args["argResponse"]);
       }
       catch (Exception ex)
       {
          Trace.WriteLine(ex.Message, "Information");

       }

Figure 12-26 shows that when a customer under 21 tries to pawn an item, the feedback from the workflow saying “Customer is not 21” is traced within the worker role.

Cloud Persistence

Setting up WF persistence in Azure’s cloud is similar to how you do it on-premise or locally; however, there are some important differences. For instance, the update 4.0.1 for Microsoft .NET Framework 4 Runtime Update fixed the following issues:

• Sqlworkflowinstancestoreschema.sql used allow_page_locks, which is not a supported keyword in SQL Azure and would fail the installation. allow_page_locks is removed from the script via the update.
• When network issues happen or the connection was lost, there could be reliability issues because the retry logic was not customized for SQL Azure. To handle this, a new public property called MaxConnectionRetries is available within the SqlWorkflowInstanceStore class. It changes the number of reconnection attempts for connecting to SQL Server. By default, there are 3 attempts during 1 second intervals. The recommended attempts for SQL Azure are greater or equal to 15.

Since VS2012 is installed, 4.0.1 update is not required, and the scripts that are supplied with .NET 4.5 can be used. The first step is to create another database from the Azure Portal. This can also be done remotely by connecting to the Azure database server through SQL Management Studio. For a recap on creating a database in Azure, review Figure 12-15 from earlier in the chapter and review Chapter 8 for illustrations on running the supplied persistence scripts within SQL Management Studio. Remember that each script should be run in the following order:

1. SqlWorkflowInstanceStoreSchema.sql
2. SqlWorkflowInstanceStoreLogic.sql
3. SqlWorkflowInstanceStoreSchemaUpgrade.sql

Each of the scripts should not have any issues and should indicate that they completed successfully. After the scripts have run, refresh SQL Management Studio to validate that the database has been updated appropriately.

Hosting Workflow Services in Azure

Hosting services in Azure provides more flexibility around working with customers and greater visibility for services that are exposed within the cloud. Existing WCF services can easily be hosted within Azure. WF is ideal for building durable services using VS2012 and the latest release of Azure tools 1.7. This section will demonstrate how to set up a WCF service hosted in Azure that is long running and maintains state, because service logic is authored as a workflow. The scenario stems around making sure a pawn shop has legitimate customers by establishing an approval process. First, a customer will fill out an application to pawn an item. A pawnshop can then approve or deny the customer. If the customer is approved, then the workflow enters the customer information in SQL Server. The workflow in Figure 12-28 needs to be durable because the approval process can take a long period of time. Persistence will be used to make sure the workflow can handle running over the duration of time it takes to approve or reject a customer.

Although the workflow in Figure 12-28 will be hosted in Azure, Visual Studio makes the process smooth and easy. In fact, workflow services that were demonstrated in Chapter 11 could be moved easily to the cloud as well. Microsoft’s goal for using Azure is to build on the existing knowledge developers have of writing software. Therefore, to get started, we will build a new solution using the WCF Workflow Service Application template, as illustrated in Figure 12-29. Next, the Apress.Chapter12.DataModel project needs to be added, which was built earlier in the chapter.

The first operation, CreateCustomerApplication, uses a ReceiveAndSendReply and accepts a parameter called NewCustomer of type Customer. A string is sent back indicating that the customer application has been received (see Figure 12-30).

Correlation is established using the OwnersSSN property on the Customer object.

Next, a Receive activity is used to simply approve a customer application. The operation it creates is ApproveCustomer, which takes two parameters. Approval is a Boolean type parameter; SSN is a string and passes the social security number as a correlation token to the workflow so it can resume (see Figure 12-31).

The last part of the workflow uses an If activity that checks if the customer is approved to pawn items or rejected. If the customer application is approved, then the SaveCustomer activity used earlier in the chapter is used to save the customer and item the customer wants to pawn to SQL Server (see Figure 12-32).

Figure 12-33 illustrates the complete workflow that will be deployed to Azure but it still has to be configured to use the persistence store that was created in SQL Azure.

The workflow service project comes with a default web.config that can be modified for configuring persistence. Listing 12-22 shows the modified web.config for configuring WF persistence and setting up the connection string so customer data can be written to the Pawnshop database in SQL Server.

Listing 12-22.  Web.config Used to Configure Persistence

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <configSections>
    <!-- For more information on Entity Framework configuration, visit http://go.microsoft.com/fwlink/?LinkID=237468-->
    <section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=4.4.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
  </configSections>
  <connectionStrings>
    <add name="Pawning" providerName="System.Data.SqlClient" connectionString="Server=<ServerName>;Database=PawnShop;User ID=<UserId>;Password=<password>;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;" />
  </connectionStrings>
  <system.web>
    <compilation debug="true" strict="false" explicit="true" targetFramework="4.0"></compilation>
    <customErrors mode="Off"></customErrors>
  </system.web>
  <system.serviceModel>
    <behaviors>
      <serviceBehaviors>
        <behavior>
          <sqlWorkflowInstanceStore connectionString="Server=tcp:l1yab5tqj4.database.windows.net,1433;Database=WFAzurePersist;User ID=<UserId>;Password=<password>;Trusted_Connection=False;Encrypt=True;Connection Timeout=30;" hostLockRenewalPeriod="00:00:30" runnableInstancesDetectionPeriod="00:02:00" instanceCompletionAction="DeleteAll" instanceLockedExceptionAction="AggressiveRetry" instanceEncodingOption="GZip" />
          <workflowIdle timeToPersist="00:00:05" timeToUnload="00:00:30" />
          <!-- To avoid disclosing metadata information, set the values below to false before deployment -->
          <serviceMetadata httpGetEnabled="true" httpsGetEnabled="false" />
          <!-- To receive exception details in faults for debugging purposes, set the value below to true.  Set to false before deployment to avoid disclosing exception information -->
          <serviceDebug includeExceptionDetailInFaults="true" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
  </system.serviceModel>
  <system.webServer>
    <modules runAllManagedModulesForAllRequests="true" />
  </system.webServer>
  <entityFramework>
    <defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework" />
  </entityFramework>
</configuration>

Now that persistence has been configured, a web role will be used to host the workflow within Azure using IIS. The Azure tools for Visual Studio allows this very easily by right-clicking the workflow service project and selecting Add Windows Azure Cloud Service Project, as illustrated in Figure 12-34.

After the new Azure service project is added, it will now contain the workflow service project as an Azure web role. Opening ServiceDefinition.csdef will show that the role is indeed a web role, as illustrated in Listing 12-23. The workflow is now ready to be pushed to Azure.

Listing 12-23.  ServiceDefinition.csdef for the New Azure Project

<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="Apress.Chapter12.WF.Service.Azure" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2012-05.1.7">
  <WebRole name="Apress.Chapter12.WF.Service" vmsize="Small">
    <Sites>
      <Site name="Web">
        <Bindings>
          <Binding name="Endpoint1" endpointName="Endpoint1" />
        </Bindings>
      </Site>
    </Sites>
    <Endpoints>
      <InputEndpoint name="Endpoint1" protocol="http" port="80" />
    </Endpoints>
    <Imports>
      <Import moduleName="Diagnostics" />
    </Imports>
  </WebRole>
</ServiceDefinition>

Earlier in the chapter, Figure 12-18 illustrated how to set up Azure subscription so solutions can be deployed to Azure. Once the solution compiles, it is ready to be deployed by right-clicking on the new cloud project and then clicking on Publish, as illustrated in Figure 12-35.

After the publishing of the solution completes, the service can be checked to make sure it has been created correctly using Internet Explorer. Figure 12-36 shows how to go to the URL that Azure provides and add the workflow name and extension at the end of the URL. In this case, the workflow is named wfPawnService.xmlx, so the address is http://flowfocusservice.cloudapp.net/wfPawnService.xamlx (see Figure 12-36).

Reusing the web application that was created earlier in the chapter, it can simply be run locally in Visual Studio to interact with the new service. The first step is to add a service reference to the ASP.NET project created earlier. So far, ASP.NET has been used to handle messages from Azure and Service Bus queues, and now it will work directly with the workflow service hosted within Azure. After creating a service reference to the web project, the bold code in Listing 12-24 can be used to communicate with the service.

Listing 12-24.  Code for Submitting Customer Applications and Approving Them

protected void cmdSubmit_Click(object sender, EventArgs e)
        {
            var pawnService = new PawnSvc.PawnServiceClient();
             
            try
            {
                var customer = new Customer
                {
                    DOB = Convert.ToDateTime(txtDOB.Text),
                    DriversLicenseNumber = txtDriverLicense.Text,
                    FirstName = txtFirstName.Text,
                    LastName = txtLastName.Text,
                    OwnersSSN = txtSSN.Text,
                    CustomerPawns = new List<CustomerPawn>
                   {
                        new CustomerPawn()
                        {
                            PawnedItems = new List<PawnedItem>
                            {
                                new PawnedItem{
                                    ItemName = txtItemName.Text,
                                    PawnedAmount = Convert.ToDecimal(txtAmount.Text),
                                    ModelNumber = txtModelNumber.Text
                                }
                            }
                        }
                   }
                };

                 
                lblAppResults.Text = pawnService.CreateCustomerApplication(customer);
                //Setting up the Service Bus Queue
                //string connectionString = CloudConfigurationManager.GetSetting("Microsoft.ServiceBus.ConnectionString");
                //var client = QueueClient.CreateFromConnectionString(connectionString, "PawnQueue");
                //var brokerMessage = new BrokeredMessage(customer);
                //client.Send(brokerMessage);
                 
                //Setting up the Azure Queue
                //var customerQueue = InitiateAzureQueue();
                //var newMessage = new CloudQueueMessage(customer.ToJson());
                //customerQueue.AddMessage(newMessage);
            }
            catch (Exception ex)
            {
                throw ex;
            }
        }

        protected void cmdApprove_Click(object sender, EventArgs e)
        {
            try
            {
                var pawnService = new PawnSvc.PawnServiceClient();
                pawnService.ApproveCustomer(txtSSN.Text,chkApprove.Checked);
            }
            catch (Exception)
            {
                 
                throw;
            }
        }

Running the ASP.NET application locally, data can be submitted to the service based on the data the customer enters. Feedback from the service shows that the application was submitted based on the “Your application has been received” string returned and loaded into the label on the page (see Figure 12-37).

Opening SQL Management Studio and connecting to the SQL database hosted within Azure for persisting workflows shows that there is one persisted workflow instance. This customer application has been persisted, as illustrated in Figure 12-38. By clicking the Approve checkbox and then clicking the Approve button, the record in Figure 12-38 will disappear because the workflow has now completed.

Checking the tables that are in the Pawnshop database will now show that the records have been added from the workflow and that the data matches the data submitted in Figure 12-37 (see Figure 12-39).