Azure Service Bus EAI/EDI December 2011 CTP – New Mapper

In this blog post we are going to explore some of the new functoids that are available in the Azure Service Bus Mapper.

At first glance, the Mapper looks pretty similar to the BizTalk 2010 Mapper. Sure there are some different icons, perhaps some lipstick applied but conceptually we are dealing with the same thing right?


Wrong! It isn’t until we take a look at the toolbox that we discover this isn’t your Father’s mapper.


This post isn’t meant to be an exhaustive reference guide for the new mapper but here are some of the new functoids that stick out for me.


Functoid Section Functoid Name Description
Loop Operations MapEach Loop This functoid will loop over a repeating record from the source document and evaluate an operation at each iteration of the loop.  If the criteria of the operation is met then a record in the target document will be created.
Expressions Arithmetic Expression No we haven’t lost our Addition or Subtraction functionality!  Many functoids that you would have found in the BizTalk 2010 Mathematical Functoids section have been consolidated in the Arithmetic Expression operation.
Expressions Logical Expression Similar to the Arithmetic Expressions, these have now been consolidated and can be found within a single Expression including >, <, >=, <=, ==, !=, Logical Negation, Conditional ADD and Conditional OR
Expressions If-Then-Else A much anticipated operation! BizTalk developers have been wanting a If-Then-Else functoid in BizTalk for many years.  If a condition has been evaluated to True then we can provide a particular value.  Otherwise we can provide different value when the condition has not been satisfied.
List Operations All of them Complete new functionality provides us with the ability to manipulate Lists within a map.  Functionality includes creating a list, adding an item to the list, selecting a unique group, selecting a value, selecting entries, getting items, and ordering the list.  Wow!  Will be interesting to see how this progresses.
Date/Time Operations DateTime Reformat This one should be useful.  I am constantly re-formatting dates when integrating with SAP.  Usually this formatting winds up in a Helper assembly which tends to be overkill for what really needs to take place.
Misc Operations Data Lookup This one is interesting.  It allows us to access data from SQL Azure within a transform at runtime.
Misc Operations Generate ID This functoid will generate a GUID.  It is the equivalent of calling the GUID.NewGuid method in .Net.
Misc Operations Get Context Property Another useful operation!  This operation allows us to retrieve a value from context.  This is something that just isn’t possible in BizTalk.
What’s Missing?

I can’t take credit for discovering this, but while chatting with Mikael Håkansson he mentioned “hey – where is the scripting functoid?”  Perhaps this is just a limitation of the CTP but definitely something that needs to be addressed for RTM.  It is always nice to be able to fall back on a .Net helper assembly or custom XSLT.

While this post was not intended to be comprehensive, I hope it has highlighted some new opportunities that warrant some further investigation.  It is nice to see that Microsoft is evolving and maturing in this area of EAI.

Introduction to the Azure Service Bus EAI/EDI December 2011 CTP

The Azure team has recently reached a new milestone; delivering on Service Bus enhancements for the December 2011 CTP.  More specifically, this CTP provides Enterprise Application Integration (EAI) and Electronic Data Interchange (EDI) functionality.  Within the Microsoft stack, both EAI and EDI have historically been tackled by BizTalk.  With this CTP we are seeing an early glimpse into how Microsoft envisions these types of integration scenarios being addressed in a Platform as a Service (PaaS) based environment.

 What is included in this CTP?

There are 3 core areas to this release:

  1. Enterprise Application Integration: In Visual Studio, we will now have the ability to create Enterprise Application Integration and Transform projects. 
  2. Connectivity to On-premise LOB applications: Using this feature will allow us to bridge our on-premise world with the other trading partners using the Azure platform.  This is of particular interest to me.  My organization utilizes systems like SAP, Oracle and 3rd party work order management and GIS systems.  In our environment, these applications are not going anywhere near the cloud anytime soon.  But, we also do a lot of data exchange with external parties.  This creates an opportunity to bridge the gap using existing on-premise systems in conjunction with Azure.
  3. Electronic Data Interchange: We now have a Trading Partner Management portal that allows us to manage EDI message exchanges with our various business partners.  The Trading Partner Management Portal is available here.

What do I need to run the CTP?

  • The first thing you will need is the actual SDK (WindowsAzureServiceBusEAI-EDILabsSDK-x64.exe) which you can download here
  • A tool called Service Bus Connect (not to be confused with AppFabric Connect) enables us to bridge on-premise with Azure.  The setup msi can also be accessed from the same page as the SDK. Within this setup we have the ability to install the Service Bus Connect SDK(which includes the BizTalk Adapter Pack), Runtime and Management tools.  In order for the runtime to be installed, we need to have Windows Server AppFabric 1.0 installed.
  • Once we have the SDKs installed, we will have the ability to create ServiceBus projects in Visual Studio.


  • Since our applications will require resources from the Azure cloud, we need to create an account in the Azure CTP Labs environment.  To create a namespace in this environment, just follow these simple instructions.
  • Next, we need to register our account with the Windows Azure EDI Portal.


 Digging into the samples

For the purpose of this blog post I will describe some of what is going on in the first Getting Started sample called Order Processing.

When we open up the project and launch the BridgeConfiguration.bcs file we will discover a canvas with a couple shapes on it.  I have outlined, in black, a Bridge and I have highlighted, in Green, what is called a Route Destination.  So the scenario that has been built for us is one that will receive a typed xml message, transform it and then place it on a Service Bus Queue.


When we dig into the Xml One-Way Bridge shape, we will discover something that looks similar to a BizTalk Pipeline.  Within this “shape” we can add the various message types that are going to be involved in the bridge.  We can then provide the names of the maps that we want to execute.


Within our BridgeConfiguration.bcs “canvas” we need to provide our service namespace.  We can set this by click on the whitespace within the canvas and then populate the Service Namespace property.


We need to set this Service Namespace so that we know where to send the result of Xml One-Way bridge.  In this case we are sending it to a Service Bus Queue that resides within our namespace.


With our application configured we can build our application as we normally would.  In order to deploy, we simply right mouse click on solution, or project, and select Deploy.  We will once again be asked to provide our Service Bus credentials.


The deployment is quick, but then again we aren’t pushing too many artifacts to the Service Bus.

Within the SDK samples, Microsoft has provided us with MessageReceiver and MessageSender tools.  With the MessageReceiver tool, we can use it to create our Queue and receive a message.  The MessageSender tool is used to send the message to the Queue.

When we test our application we will be asked to provide an instance of our typed Xml message.  It will be sent to the Service Bus, transformed (twice) and then the result will be placed on a Queue.  We will then pull this message off of the queue and the result will be displayed in our Console.




So far is seems pretty cool and looks like this team is headed in the right direction.  Much like the AppFabric Apps CTP, there will be some gaps in the technology, and bugs, that have been delivered as this is still just a technical preview.  If you have any feedback for the Service Bus team or want some help troubleshooting a problem, a forum has been set up for this purpose.

I am definitely looking forward to digging into this technology further – especially in the area of connecting to on-premise LOB systems such as SAP.  Stay tuned for more posts on these topics.

Speaking at Prairie Dev Con West–March 2012

I have recently been informed that my session abstract has been accepted and I will be speaking at Prairie Dev Con West in March.  My session will focus on Microsoft’s Cloud based Middleware platform: Azure AppFabric.  In my session I will be discussing topics such as Service Bus,  AppFabric Queues/Subscriptions and bridging on-premise Line of Business systems with cloud based integration.

You can read more about the Prairie Dev Con West here and find more information about registration here.   Do note there is some early bird pricing in effect.



AppFabric Apps (June 2011 CTP)–Only 1 SQL Azure Instance at a time

I must have missed it in the release notes but when you have access to the AppFabric Apps CTP, you are only allowed on SQL Azure instance within this Labs environment.  When you first log into the Portal you will see a SQL Azure DB that has a name of LabsSqlDatabase.  The problem is that you can’t actually create another one here and if you do try to access this database you will not be able to connect to it using the Database Name LabsSqlDatabase.


What is a little confusing is when you are working within your Local Dev Fabric that you can specify any name you want in your SQL Azure cofig for your DatabaseName.  The problem is this name will not exist in the cloud if you want to access it after you have published your AppFabric Application.


The error message that you will receive will resemble the following:


So due to this current limitation (it is CTP  – I am ok with it), you need to use the database that was provisioned for you when you were granted access to the CTP Labs enviornment.  To do this you will need to get your connection string from the Labs Portal by clicking on LabsSqlDatabase then click on the View button below the Connection String label.  A dialog box will appear and you can copy your connection string by clicking the Copy to Clipboard button.


If we paste this value in notepad we will discover the following connection string.  The Data Source represents the name of the server (s) that our database will be running on.  Next we have an Initial Catalog value which is the actual name of our database that has been provisioned for us….not LabsSqlDatabase.  In my case, and I would imagine others, my Initial Catalog value is the same as my user id.  If have blacked out portions of these values for privacy reasons.image

If I now try to connect to this database either through SQL Management Studio or Database Manager Portal, using this initial catalog value for my Database Name,  I will have success.


At this point we are free to run any of our SQL scripts to generate tables, stored procedures or load data.


I hope this post will save some others some time as it did create some confusion for me.  Admittedly I sometimes dive right into things instead of thoroughly reviewing the documentation (what fun is that).  From what I gather, it is possible to hook up an AppFabric Application to an existing SQL Azure database that exists in the NON-LABS environment.  So if you really need to create multiple SQL Azure databases that is also an option.  Since I am just playing around with this stuff having a single SQL Azure instance works for me now that I understand the limitations of the Labs environment.

AppFabric Apps (June 2011 CTP) Accessing AppFabric Queue via REST

I recently watched an episode of AppFabric TV where they were discussing the REST API for Azure AppFabric.  I thought the ability to access the AppFabric Service Bus, and therefore other Azure AppFabric services like Queues, Topics and Subscriptions via REST was a pretty compelling scenario.  For example, if we take a look at the “Power Outage” scenario that I have been using to demonstrate some of the features of AppFabric Applications, it means that we can create a Windows Phone 7 (or Windows Phone 7.1/Mango Beta) application and dump messages into an AppFabric Queue securely via the AppFabric Service Bus.  Currently, the Windows Phone SDK does not allow for the managed, Service Bus bindings to be loaded on the phone so using the REST based API over HTTP is a viable option.

Below is a diagram that illustrates the solution that we are about to build.  We will have a Windows Phone 7.1 app that will push messages to an Azure AppFabric Queue.  (You will soon discover that I am not a Windows Phone developer.  If you were expecting to see some whiz bang new Mango features then this post is not for you.) 

The purpose of the mobile is to submit power outage information to an AppFabric Queue.  But before we can do this we need to retrieve a token from the Access Control Service and include this token in our AppFabric Queue message Header.  Once the message is in the Queue,  we will once again use a Code Service to retrieve messages that we will then insert into a SQL Azure table.



Building our Mobile Solution

One of the benefits of using AppFabric queues is the loose coupling between publishers and subscribers.  With this in mind, we can proceed with building a Windows Phone 7 application in its own solution.  For the purpose of this blog post I am going to use the latest mango beta sdk bits which are available here.


Since I have downloaded the latest 7.1 bits, I am going to target this phone version.



On our WP7 Canvas we are going to add a few controls:

  • TextBlock called lblAddress that has a Text property of Address
  • TextBox called txtAddress that has an empty Text Property
  • Button called btnSubmit that has a Content property of Submit
  • TextBlock called lblStatus that has an empty Text Property



Within the btnSubmit_Click event we are going to place our code that will communicate with the Access Control Service.

private void btnSubmit_Click(object sender, RoutedEventArgs e)

         //Build ACS and Service Bus Addresses
         string acsAddress = https + serviceNameSpace + acsSuffix ;
         string relyingPartyAddress = http + serviceNameSpace + serviceBusSuffix;
         string serviceAddress = https + serviceNameSpace + serviceBusSuffix;

         //Formulate Query String
         string postData = "wrap_scope=" + Uri.EscapeDataString(relyingPartyAddress) +
             "&wrap_name=" + Uri.EscapeDataString(issuerName) +
             "&wrap_password=" + Uri.EscapeDataString(issuerKey);
         WebClient acsWebClient = new WebClient();
         //Since Web/Http calls are all async in WP7, we need to register and event handler
         acsWebClient.UploadStringCompleted += new UploadStringCompletedEventHandler(acsWebClient_UploadStringCompleted);

         //instantiate Uri object with our acs URL so that we can provide in remote method call
         Uri acsUri = new Uri(acsAddress);



Since we are making an Asynchronous call to the ACS service, we need to implement  the   handling of the response from the ACS Service.

private void acsWebClient_UploadStringCompleted(object sender, UploadStringCompletedEventArgs e)
        if (e.Error != null)
            lblStatus.Text = "Error communicating with ACS";
            //store response since we will need to pull ACS token from it
            string response = e.Result;

            //update WP7 UI with status update
            lblStatus.Text = "Received positive response from ACS";
            //Sleep just for visual purposes

            //parsing the ACS token from response
            string[] tokenVariables = response.Split(‘&’);
            string[] tokenVariable = tokenVariables[0].Split(‘=’);
            string authorizationToken = Uri.UnescapeDataString(tokenVariable[1]);

           //Creating our Web client that will use to populate the Queue
            WebClient queueClient = new WebClient();

            //add our authorization token to our header
            queueClient.Headers["Authorization"] = "WRAP access_token=\"" + authorizationToken +"\"";
            queueClient.Headers[HttpRequestHeader.ContentType] = "text/plain";

            //capture textbox data
            string messageBody = txtAddress.Text;
            //assemble our queue address
            //For example: ""
            string sendAddress = https + serviceNameSpace + serviceBusSuffix + queueName + messages;

            //Register event handler
            queueClient.UploadStringCompleted += new UploadStringCompletedEventHandler(queueClient_UploadStringCompleted);

            Uri queueUri = new Uri(sendAddress);
            //Call method to populate queue
            queueClient.UploadStringAsync(queueUri, "POST", messageBody);



So at this point we have made a successful request to ACS and received a response that included our token.  We then registered an event handler as we will call the AppFabric Service Bus Queue using an Asynchronous call.  Finally we made a call to our Service Bus Queue.

We now need to process the response coming back from the AppFabric Service Bus Queue.

private void queueClient_UploadStringCompleted(object sender, UploadStringCompletedEventArgs e)
    //Update status to user.
    if (e.Error != null)
        lblStatus.Text = "Error sending message to Queue";
         lblStatus.Text = "Message successfully sent to Queue";


That concludes the code that is required to submit a message securely to the AppFabric Service Bus Queue using the Access Control Service to authenticate our request.

Building our Azure AppFabric Application

The first artifact that we are going to build is the AppFabric Service Bus Queue called QueueMobile.


Much like we have done in previous posts we need to provide an IssuerKey, IssuerName and Uri.


The next artifact that we need add is a SQL Azure Database.


Adding this artifact is only the beginning.  We still need to create our local database in our SQL Express instance.  So what I have done is manually created a Database called PowerOutage and a Table called Outages.


Within this table I have two very simple columns: ID and Address.


So the next question is how do I connect to this database.  If you navigate to the AppFabric Applications Manager which is found within the AppFabric Labs portal, we will see that a SQL Azure DB has been provisioned for us.


Part of this configuration includes our connection string for this Database.  We can access this connection string by clicking on the View button that is part of the Connection String panel.


I have covered up some of the core credential details that are part of my connection string for security reasons.  What I have decided to do though to make things a little more consistent is created a SQL Server account that has these same credentials in my local SQL Express.  This way when I provision to the cloud I only need to change my Data Source.


For the time being I am only interested my local development fabric so I need to update my connections string to use my local SQL Express version of the database.



With our Queue and Database now created and configured, we need to focus on our Code Service.  The purpose of this Code Service is to retrieve messages from our AppFabric Queue and insert them into our SQL Azure table.  We will call this Code Service CodeMobileQueue and then will click the OK button to proceed.


We now need to add references from our Code Service to both our AppFabric Queue and our SQL Azure Instance.  I always like to rename my references so that they have meaningful names.


Inside our Code Service, It is now time to start focusing on the plumbing of our solutions We need to be able to retrieve messages from the AppFabric Queue and insert them into our SQL Azure table.

public void Run(CancellationToken cancelToken)
           //Create reference to our Queue CLient
            QueueClient qClient = ServiceReferences.CreateQueueMobile();
          //Create reference to our SQL Azure Connection
            SqlConnection sConn =  ServiceReferences.CreateSqlQueueMobile();
            MessageReceiver mr = qClient.CreateReceiver();
            BrokeredMessage bm;
           Stream qStream;
           StreamReader sReader;
           string address;

            System.Diagnostics.Trace.TraceInformation("Entering Queue Retrieval " + System.DateTime.Now.ToString());

            while (!cancelToken.IsCancellationRequested)
                //Open Connection to the database
                while (mr.TryReceive(new TimeSpan(hours: 0, minutes: 30, seconds: 0), out bm))

                        //Note: we are using a Stream here instead of a String like in other examples
                        //the reason for this is that did not put the message on the wire using a
                        //BrokeredMessage(Binary Format) like in other examples.  We just put on raw text.
                        //The way to get around this is to use a Stream and then a StreamReader to pull the text out as a String
                        qStream = bm.GetBody<Stream>();
                        sReader = new StreamReader(qStream);
                        address = sReader.ReadToEnd();

                        //remove message from the Queue

                        System.Diagnostics.Trace.TraceInformation(string.Format("Message received: ID= {0}, Body= {1}", bm.MessageId, address));

                       //Insert Message from Queue and add it to a Database
                        SqlCommand cmd = sConn.CreateCommand();
                        cmd.Parameters.Add(new SqlParameter("@ID", SqlDbType.NVarChar));
                        cmd.Parameters["@ID"].Value = bm.MessageId;
                        cmd.Parameters.Add(new SqlParameter("@Address", SqlDbType.NVarChar));
                        cmd.Parameters["@Address"].Value = address;
                        cmd.CommandText = "Insert into Outages(ID,Address) Values (@ID,@Address)";
                        cmd.CommandType = CommandType.Text;
                        System.Diagnostics.Trace.TraceInformation("Record inserted into Database");
                    catch (Exception ex)
                        System.Diagnostics.Trace.TraceError("error occurred " + ex.ToString()); 

                // Add your code here
                Thread.Sleep(5 * 1000);



Testing Application

We are done with all the coding and configuration for our solution.  Once again I am going to run this application in the local Dev Fabric so I am going to go ahead and type CRTL + F5.  Once my Windows Azure Emulator has been started and our application has been deployed we can start our Windows Phone Project.

For the purpose of this blog post we are going to run our Windows Mobile solution in the provided emulator.  However, I have verified the application can be side-loaded on a WP7 device and the application does work properly.

We are now going to populate our Address text box with a value.  In this case I am going to provide 1 Microsoft Way  and click the Submit button.


Once we click the Submit button we can expect our first status message update indicating that we have received a positive response from ACS.


The next update we will have displayed is one that indicates our message has been successfully sent to our AppFabric Queue.


As outlined previously, our WP7 app will publish message to our AppFabric Queue, from there we will have our Code Service de-queue the message and then insert our record into a SQL Azure table.  So if we check our Outages table we will discover that a record has been added to our Database.





Overall I am pretty please with how this demo turned out.  I really like the ability to have a loosely coupled interface that a Mobile client can utilize.  What is also nice about using a RESTful interface is that we have a lot of flexibility when porting a solution like this over to other platforms.

Another aspect of this solution that I like is having a durable Queue in the cloud.  In this solution we had a code service de-queuing this message in the cloud.  However, I could also have some code written that is living on-premise that could retrieve these messages from the cloud and then send them to an LOB system like SAP.  Should we have a planned, or unplanned system outage on-premise, I know that all mobile clients can still talk to the Queue in the cloud.

AppFabric Apps (June 2011 CTP) Simple Service Bus Topics–Part 2

(…Continued from Part 1, if you have not read it please do so to understand the context of this post)


We want customers to be able to submit power outages to our fictitious power company located in the Redmond, Washington area. What is different this time around(from our Queue scenario) is that due to the growth in the Kirkland, Washington area we have subcontracted power line maintenance to another company. So we want our Redmond system to receive messages for the Redmond area and this other company to receive messages for Kirkland. The Redmond company should not see the Kirkland messages and vice versa.

Configuring Core Artifacts

The user interface for this application will once again be an ASP.Net Web Application.  We will add this Web Application by clicking on the Add New Service label which is found on the AppFabric Design View Canvas.


Next, we will want to provide an appropriate name for this Web App and click on the OK button.


We now need to create a Service Bus Topic and can do this by once again clicking on the Add New Service label which is found on the AppFabric Design View Canvas.


Much like we have had to do with other Service Bus artifacts, we need to provide our Service Bus IssuerKey, IssuerName and Uri.  For my URI, I have provided the following value:



Note: Notice the RequiresProvisioning property which is set to True.  When we deploy our AppFabric application the provisioning of our Topic will be taken care of without any additional work from our side. When we shutdown the Azure Compute Emulator, this Topic will be removed.

In many of the May AppFabric CTP examples out there people handle provisioning tasks by using the ServiceBusNamespaceClient  class.  No where in this code will we be directly using this class.  I would imagine that under the hood, the provisioning code is using this class.

Next, our Web application we need to add a reference to this newly created Topic.


I like to rename my references to provide a more descriptive title than the default Import1 value.



With our topic now setup we want to add two subscriptions.  The first subscription will be for our Redmond messages and the second subscription will be for our Kirkland subscription.






For each of these Subscriptions we need to once again provide  IssuerKey, IssuerName and Uri propertiesThe Uri property for subscriptions provides an interesting twist. The actual word “subscriptions” must be included between the name of your Topic and Subscription. The convention for these Uri are:





Much like in the Queue Blog Post we are going to use a Code Service to retrieve messages from our Topic via a Subscription.  We need once again click on the Add New Service label and select Code.



This Code Service will represent the Redmond Client and therefore we need to add a reference to the SimpleServiceBusSubscriptionRedmond Subscription.



The underlying core of our application should be set and we should be able to build our application.  If we look at the AppFabric Design View Canvas we should see the following:


Our Diagram View should look like this:



Update Web Application

At this point we have simply configured all of the artifacts that are required in our solution but we have not written any code so our application will not be very functional.  In the Source view of the Default.aspx  page we want to add a few controls:

  • Text Box for our Address
  • Text Box for our City
  • Button used to submit our form



In the code behind for Default.aspx we will want to add an event handler for the Button clicked event.

protected void btnSubmit_Click(object sender, EventArgs e)
    TopicClient tc = ServiceReferences.CreateSimpleServiceBusTopic();

    MessageSender ms = tc.CreateSender();

    BrokeredMessage bm = BrokeredMessage.CreateMessage(txtAddress.Text);
    bm.Properties[“OutageCity”] = txtCity.Text;


    txtAddress.Text = “”;
    txtCity.Text = “”;


Some lines of significance include:

TopicClient tc = ServiceReferences.CreateSimpleServiceBusTopic(); where we are creating an instance of our TopicClient.

The BrokeredMessage instantiation line includes our message body which is our address that is coming from our Address text box.

BrokeredMessage bm = BrokeredMessage.CreateMessage(txtAddress.Text);


You may also notice where we assign our City value to a property called OutageCity.  This property is kinda like a BizTalk Context property.  We are going to be able to route our message based upon this value.  We will later use this property when creating a Subscription Filter.

bm.Properties[“OutageCity”] = txtCity.Text;

Note: this code looks a little different than the May AppFabic CTP code that you have seen.  In the May CTP we had to worry about our Service Bus configuration for our namespace, Issuer owner and key.  We also had to create an instance of  a MessagingFactory object so that we could create a Topic Client.  I like the AppFabric Application approach better.  It is a little cleaner and all of our configuration info is handled in our Application model.


Update Code Service

We now need to update our Run method that exists within our Code Service.  As discussed in the Queue blog post, this method will continue to run until a cancellation request is received.  The purpose of this method is to retrieve messages from our Topic via our Redmond Subscription.

For the purpose of this demonstration we are simply going to log messages that have been retrieved  in our Trace viewer.

public void Run(CancellationToken cancelToken)

           System.Diagnostics.Trace.TraceInformation(“Entering Code Service Loop”);

           while (!cancelToken.IsCancellationRequested)

               SubscriptionClient subClient = ServiceReferences.CreateSimpleServiceBusSubscription();
               subClient.MessagingFactory.CreateSubscriptionClient(“SimpleServiceBusTopic”, “SimpleServiceBusSubscriptionRedmond”);

               MessageReceiver mr = subClient.CreateReceiver();
               BrokeredMessage bm;

               while (mr.TryReceive(new TimeSpan(hours: 0, minutes: 0, seconds: 5), out bm))
                   System.Diagnostics.Trace.TraceInformation(string.Format(“Message received: ID=   {0}, Body= {1}”, bm.MessageId, bm.GetBody<string>()));

               // Add your code here
               Thread.Sleep(5 * 1000);


Some lines of significance include:

Our line where we create a subscription client that will include the name of our Topic and our Subscription.

subClient.MessagingFactory.CreateSubscriptionClient(“SimpleServiceBusTopic”, “SimpleServiceBusSubscriptionRedmond”);

The next line is our while loop that will attempt to retrieve messages from this subscription.  If a message is retrieved it will be stored in a BrokeredMessage.

while (mr.TryReceive(new TimeSpan(hours: 0, minutes: 5, seconds: 0), out bm))

Creating a Kirkland client

Our Kirkland client is going to follow a different path than our Redmond client.  At this point everything that we have built exists in the Azure Cloud.  For our Kirkland client, it is going to reside on-premise.  Since our Topics and Subscriptions are provisioned in the cloud we can access them from within the cloud and on-premise.

For this example we will follow the path that many of the May CTP examples took.  It is a console application that is in a separate solution from this AppFabric Application.  In this application I have added references manually to the ServiceBus CTP assemblies.


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.ServiceBus;
using Microsoft.ServiceBus.Messaging;
using Microsoft.ServiceBus.Description;

namespace SimpleTopicOnPrem
    class Program
        static void Main(string[] args)

            Uri sbURI = ServiceBusEnvironment.CreateServiceUri(“sb”, “<your_namespace>”, string.Empty);
            string name = “owner”;
            string key = “<your_key>”;


            MessagingFactory factory = MessagingFactory.Create(sbURI, TransportClientCredentialBase.CreateSharedSecretCredential(name, key));

            SubscriptionClient subClient = factory.CreateSubscriptionClient(“SimpleServiceBusTopic”, “SimpleServiceBusSubscriptionKirkland”);

            //Next we create the MessageReceiver and receive a message.

            MessageReceiver mr = subClient.CreateReceiver();

            BrokeredMessage bm;

            while (mr.TryReceive(new TimeSpan(hours: 0, minutes: 5, seconds: 0), out bm))
                Console.WriteLine(string.Format(“Message received: ID= {0}, Body= {1}”, bm.MessageId, bm.GetBody<string>()));

            Console.WriteLine(“Done Reading From Queue”);


This code looks pretty similar to our Code Service with the exception of how we create a SubscriptionClient and that we need to deal with our credentials and URI in the application.


Testing the application

For the purpose of this blog post we are going to keep our AppFabric application in our Development Fabric.  We can provision and deploy our application by typing CRTL + F5.  We should see our web application launch.

Next we will want to start an instance of our Kirkland On Premise client by typing F5.  This means that both of our applications are up and running and ready to receive messages.

Since we have not added any filters on our Subscriptions both applications should receive a copy of any message that we submit. 


The first message that we will send will have an Address of Space Needle and a City of Seattle.



In our Trace logs and in our Console application we will discover that our message has been received by both clients.



At this point we have proved that our initial deployment has been successful and that we can broadcast this message to multiple clients.  But, this is not the end state that we desire.  Remember we want the Redmond client to only receive the Redmond messages and the Kirkland client to only receive the Kirkland messages.  In order to accomplish this behavior we need to add Subscription rules.

Unless I have missed something(and please let me know if I have), there is no way to specify our filter when we create our Subscription through the AppFabric Design Canvas.  The only way that I have seen how to do this is through code by using the ServiceBusNamespaceClient class.  So I could have written this code but opted for a different option.  The AppFabric Cat team recently released a tool called the Service Bus Explorer.  Within this tool, you can provide your credentials and then interrogate your Queues, Topics and Subscriptions.  You can read all about this tool and some more detailed information on their blog post.

Once I have connected to my namespace using the Service Bus Explorer, I want to navigate to my Redmond subscription and then delete the existing rule.  Basically this rule is saying that any messages should be retrieved using this subscription.


I then want to right mouse click on the Redmond Subscription and Add Rule.  I now need to provide a name for this rule (it can be anything) and a SQL Filter Expression.  In this case I am providing OutageCity=’Redmond’.


With my Subscription rule established for my Redmond Subscription lets submit another message.  This time we will provide an Address of 1 Microsoft Way and a City of Redmond.



So notice that both clients received this message.  The reason for this is that this message did match the Subscription rule (filter) for the Redmond Client.  Since we have not configured a Subscription rule (filter) for our Kirkland client it is still configured to receive all messages.


To prove that the Redmond Subscription is working, lets send in a message that will not match the Redmond rule.  This time only the Kirkland application should receive it if we make the city equal to Bellevue.



We will discover that the Subscription rule is working.  Our Redmond client did not receive this Bellevue message but our Kirkland client did since its Subscription rule is wide open.


So let’s create a Subscription rule for our Kirkland client.  We will head back to the Service Bus Explorer tool to do this.

Once again we will delete the Default Rule, this time for the Kirkland Subscription.  We will add a new Rule by right mouse clicking on the Kirkland Subscription and selecting Add Rule.  We will provide this rule with a Name of Kirkland and a SQL Filter Expression of OutageCity=’Kirkland’.


With our Subscription rule now in place, lets send in a message that only our Kirkland client will receive. 



Sure enough, our Redmond client did not receive a copy of this message since its Subscription rule didn’t match.  Our Kirkland client did receive this message since it did match our Subscription rule



Closing Notes:

  • You will lose any of these Subscription rules between deployments.  When you shutdown the Dev Fabric emulator, your Topic and Subscriptions will be removed.  When you deploy your application to the Local Dev fabric your Topic and Subscriptions will be deployed but your rules/filters will not return unless you configure them again.
  • Topics will push messages to Subscriptions no matter the Rule that you have in place.  But, clients will only retrieve messages that match the Subscription rule(s).
  • You can have multiple Subscription rules per Subscription.
  • It would be nice if we can provide our Subscription rules in our AppFabric Design view canvas.  This way they could be deployed with our Topic and Subscription(s).
  • Publishers instantiate TopicClient instances, Consumers instantiate Subscription Client instances.
  • Overall the technology is pretty cool.  Having true pub/sub in the cloud should open up many opportunities for organizations.

AppFabric Apps (June 2011 CTP) Simple Service Bus Topics–Part 1

In my last post we discussed using Azure AppFabric Queues as part of Azure AppFabric Applications.  In this post, we will discuss a couple of related Queue technologies called Topics and Subscriptions.  The purpose of this post will be to describe the conceptual behavior of Topics and Subscriptions and then in a follow up post actually dive into a detailed example of how we can use this technology. 

What is a Topic?

A Topic is much like a Queue in some ways.  It is a durable storage container that allows consuming clients to retrieve messages from.  Data within a Queue can be consumed by a single client.  Data within a topic can be consumed by multiple clients through an AppFabric Subscription.

What is a Subscription?

A Subscription is probably exactly what you think it is.  It is a client requesting a copy of a particular message that has been published to a Topic.  Subscriptions by default include all messages for a particular subscription but we can also specify a SQL 92 query which essentially allows us to “filter” messages that we are interested in.

Topics + Subscriptions = Pub/Sub

The combination of Topics and Subscriptions really allow for Pub/Sub in the cloud.  It provides the ability for a publisher to put a message in the cloud then have consuming client(s)  retrieve messages that are relevant.  When a publisher sends a message to the cloud, it is really sending it to a Topic and when a consuming client retrieves a message it is doing so through a Subscription.

Why is this important?

In my opinion, I think this is pretty cool technology.  Internet Pub/Sub messaging is something that is a relatively new concept in the Microsoft Stack.  The idea that you can perform this pub/sub in the cloud provides some unique opportunities in both Business to Business and Business to Consumer scenarios.  With Business to Business scenarios dealing with network firewalls to allow for communication to occur(between organizations) is usually not a fun adventure.   Also, providing the ability to scale usually provides challenges as well.  On the Business to Consumer side, our Topic messages are stored in a durable store and therefore support disconnected client scenarios provided we mark messages with a suitable time to live (TTL) parameter.


In the previous Queue post we had an example of a Power Outage application that allows customers with a power outage to report it through a mobile phone browser.  That example works great if we have a single consumer, but what if we have multiple consumers?  Enter Topics and Subscriptions.

This scenario is very similar.  We want customers to be able to submit power outages to our fictitious power company located in the Redmond, Washington area.  What is different this time around is that due to the growth in the Kirkland, Washington area we have subcontracted power line maintenance to another company.  So we want our Redmond system to receive messages for the Redmond area and this other company to receive messages for Kirkland.  The Redmond company should not see the Kirkland messages and vice versa.

To support this solution, we will create 1 Topic.  The Web application will submit messages to this Topic.  We will also register 2 Subscriptions on this topic and provide a filter expression that will ensure that our Redmond client receives messages for Redmond and a filter expression that ensures our Kirkland client receives messages for Kirkland.



Please see post 2 that will provide a step by step implementation of this solution.