Azure Service Bus

Download My PowerShell eBook for Free [US-EN]

I have been the author of this book which was written for Syncfusion, to increase their offer on the Succinctly series. Two more books are on stack to be released so wait for more news in the following weeks.


PowerShell Succinctly highlights some of the PowerShell programming model’s many benefits, specifically for .NET developers and system administrators. Author Rui Machado guides readers through time-saving methods that simplify code testing by eliminating the need to create a new application in Visual Studio. Also included are tips for using additional services, such as PowerGui, WMI, and SQL Server, to get the most out of PowerShell. Even if you don’t already use scripting languages to manage your machines, PowerShell Succinctly will show you just how easy it is to automate activities, work with databases, and interact with a variety of file types with this useful model.


Windows Azure EAI and EDI Labs Worshop – Routing Exercise [en-US]

Workshop Windows Azure EAI and EDI Labs – Release 2012

“Manage routing in the new Azure Service Bus EAI”

Study Case: In this tutorial we are going to assume that an enterprise wants to rout their XML format emails from their employees, using a bridge and azure queues as well as connection routing definition. When as email arrives the bridges filters it and using the receiver name decides in which queue it’s going to store the email (XML message). Using this example you can imagine a whole bunch of scenarios and try to implement them using this algorithm and example.

  1. Create a Service Bus project
  2. Create a Schema
  3. Design the Bridge
  4. Add Queues
  5. Configure the Bridge
  6. Enrich the Message
  7. Set the routing conditions
  8. Create the Queues
  9. Test the solution


1. Create a Service Bus project

Open Visual Studio and select -> New Project -> Visual C# -> Service Bus -> Enterprise Application Integration

2. Create a Schema

You can use my own example XSD (Schema) example or imagine your own scenario with your examples. My code is described below:

3. Designing the Bridge

In this step just drag-and-drop a one-way-bridge (you can find in it the visual studio tool box) which is going to be an entry point to our windows azure appfabric space. Just notice or change it to something more familiar, the Bridge relative path, which is going to be used to build a full path to this azure entry point.

In my case I changed it to “ReceptorEmails”.

4. Configure Bridge Configurations Namespace

Open the BridgeConfiguration.bcs file (locate it in de solution explorer) which is automatically created with the project and in its properties change the namespace value to your namespace, created in appfabric portal.

5. Add Queues

Add the bridge by drag-and-drop which one of them into your BridgeConfiguration.bcs file. Change the queues names to make the distinguish process easier. In my case I choose {Queue1 => “RuiMachado”, Queue2 => “SandroPereira”, Queue3 => “JoãoPinto”}.

Next step is connecting the bridge to each queue. This connector is where you are going to define the filter condition so that the bridge can decide to which queue route a message. To do this connection don´t drag and drop the connection because it’s not going to work (yes its true), you must click on the connection item in the toolbox and then click on the bridge send point and now without releasing your mouse button join this point with the one placed in the queues. Example:

6. Configure the Bridge

Now we are going to build our Bridge Definition, just double-click your bridge (in my case ReceptorEmails ) and you will see this visual configuration wizard:

Now click the plus (+) button (a Message Type Picker Wizard will pop up) in the top and define the format of your receive XML message (Schema).

Select the Schema you’re created in step 2. In my case I named it Email so my Schema is the one named Email (as I only created one it’s the only available). Click OK and close the bridge wizard.

7. Enrich the Message

In this step we are going to choose and define by which property in our Schema created in step 2 should the bridge route the messages. It’s similar to promote a node in BizTalk and use it as routing in your Receive Location, however in this tutorial you don´t need to promote any node because we will use the enrichment process.

To do this enrichment you just need to open your Schema and select the one that you want to use as a filter in the routing.

In my case I selected the NameReceiver element to be my routing filter so it’s the one you see selected. Now with your chosen element selected check the Instance XPath in the properties window.

Based on Xpath language which was created to optimize the selection of nodes in XML (Based on the XML tree), an Instance Xpath defines the Xpath expression to access that particular node (in this case the NameReceiver element).

Copy that Instance Xpath because we will use it to specify the filter node in the enrichment configuration.

You will have an expression like: /*[local-name()=’Email’ and namespace-uri()=’http://TesteRouting.Email’%5D/*%5Blocal-name()=’NameReceiver’ and namespace-uri()=”]

You don´t need to know what all that symbols mean however you want to know more about Xpath google it, there are lots of articles about it.

Now open de Bridge Wizard again (double-click your bridge in the BridgeConfiguration.bcs file). See step 6.

With your bridge wizard open click in the enrichment element (there are two options, before transformation or after, as we aren´t applying any transformation select the one before transformation).

To know if the Enrich is selected check if its color turned into blue as you can see above. Now with the Enrich selected go to its properties and click the square button with the ellipsis on it, at the right of Property Definitions:

A Property definition wizard will pop up.

Now click on the Add button and the configuration starts:

In the type element you need to specify the type of property we are going to use, among http, soap or ftp you will find a Xpath option, select it.

Next element to configure is Identifier; this one is for you to specify the Instance Xpath for your node that you copied before. Paste it there.

In the message type you need to specify what schema defines your XML message. In our case we just have one Schema configured (Email) so it’s the only one visible. Select it.

Now comes the Property configuration, in this part you will build the filter property based on the Schema node you identified with the Instance Xpath address. Give any name you want, try to choose a suggestive one. I chose “receptor”. In the Data Type define the type of property you are building, as in this case it’s a name I will select String but for example if you choose a DateTime you have a DateTime option.

Ok, the configuration is finished. You should have somehing like:

Click Ok and close the Bridge Wizard.

8. Set the routing conditions

Now it’s time to set the routing conditions based on this Property you just built in the enrichment process.

To do this click on a connector in your BridgeConfiguration.bcs file and on the properties windows click on Filter Condition.

You will see that a square button with an ellipsis on it will appear on the right of the Filter Condition property. Click on it. A wizard will pop up.

In this wizard we just need to define the filter based on the property created in the enrichment process. As we define that property name as “receptor” start writingiin the filter textbox “receptor=” and now choose the NameReceiver name that should be used to filter. Notice that this is the value that will come in the NameReceiver node in the received XML message. So the final expression filter in this first query will be “receptor=’Rui Machado’” because I want to say that every XML messages (Emails in XML) that arrive to Mr. Rui Machado will be routed to this queue. You shoul have something like:

Click OK and now right below Filter Condition in the properties windows you have the Messaging Protocol, select REST and the final result for this queue will be:

Now do this for each queue. In my case I got this:

Now save this changes as well as the whole project and Visual Studio. The Visual Studio part is complete.

9. Configuring the queues in azure

In this step you need create the Queues in the Azure AppFabric Portal, to do this you have two options, a visual one and a command prompt based one. I will show you how to do both.

Starting with the visual option, access to and sign in to your account. If you haven´t access the portal because I will do a small demo on how to have access to the appfabric azure portal. If you already have a appfabric azure namespace to use in this project ignore this 9.a step and jump to 9.b.

a. Accessing the portal and creating a namespace

When you access the appfabric portal for the first time you will be routed to a windows live id sing in page. If you don’t have windows live id, create one. Now with your windows live id email and password access the portal.

Once you sign in the portal will appear.

Now click on the appfabric button (The last button on the left-down area of the portal)

When the Appfabric page opens, select New Namespace on the left-up area of the portal:

Just give a name to your namespace, select the Service Bus checkbox on the left, click ok and your appfabric azure namespace is created.

Now that you have a namespace it’s time to create the queues.

b. Create queues in azure appfabric portal

In the Appfabric page expand the services menu item on the left and click Service Bus.

Now you can see your subscription in the body. Expand your subscription (or desired subscription if you have more than one) and click on the namespace in which you want to create the queues.

Now select the New Queue option in the header menu of the page.

A wizard pop up will appear. Just give the queue a name and a maximum queue size. Don´t worry with the other fields, leave them as they are.

Click ok and your first queue is created. Now do this for the other two queues (if you created 3 queues in your visual studio project as I made, otherwise, create one for each queue you have). In my case you can see the three queues with suggesting names.

If you don´t want to access your portal to create the queues (you will need anyway) or loose time with the visual creation process, download the file from , unzip it and open in Visual Studio the Samples -> Tools -> MessageReceiver project. Now built it in visual studio and close it.

Open you cmd.exe (Command Prompt) in windows.

Now using cmd go to the directory in wich MessageSender is built ( to change directory use the command cd Example:

cd Desktop\MessageReceiver\bin\debug )

Once in the folder run:

MessageReceiver.exe <Your namespace> <Issuer name> <Your issuer key> <Queue name> Create

This information can be found in your appfabric azure portal. Where?

<your namespace>

<issuer name> and <issuer key> , click on view (last option in the properties menu of appfabric portal)

A information menu will pop-up.

The <queue name> is the name you want to give to your queue.

When you collect all the info build the command based on that abstract example and run.

10. Test the solution

With the queues and the project created its time to test our application. To do this we will use another project provided in the Samples folder which is MessageSender. This Message Sender will send the XML files to the Bridge and MessageReceiver will allow us to read all the xml messages that a specific queue as. It’s our own command-prompt based Microsoft Outlook.

Start by generating an XML file based on the Schema created.

Once you have the XML or several XML files build the MessageSender, see how to do it in the 9.b step, cand open the cmd again.

To send messages use the following:

– Navigate in cmd to the folder where the MessageSender was built

– Run the following:

MessageSender.exe <Your namespace> <your issuer name> <Your issuer key> <Your endpoint> <Path to sample file> application/xml

See how to get this info in 9.b step. Once you have all the info run the command. If everything was correctly you shoul see this in your cmd (Hidden my issuer key):

Now you may want to read your message. To do this runs the following command (Similar to create queue but now we replace the keyword Create for Listen):

MessageReceiver.exe <Your namespace> <Issuer name> <Your issuer key> <Queue name> Create

As you can see when you send a message you send define any king of queue, you just send it to the bridge and it will route the message based on the node NameReceiver which was defined in the enrichment process. However to read messages you need to specify the queue from which you want to read.

When you execute this command you should have the following result (Don´t forget to navigate to the path in which you built the MessagReceiver):

You can now see the XML that you sent. One last note, this Listen command only works once, it’s like a Not Read email inbox. You can send a message, but when you Listen it, the queue deletes the message. Don´t forget this is only a beta version of EAI and EDI Labs.

Thats it, Thanks,

Rui Machado

Windows Azure EDI – Introdução ao Portal – [pt-BR]

Arquitectura do EDI

Troca de Mensagens Electronicas (TME), electronic data interchange (EDI) em inglês é um dos meis mais utilizados pelas organizações e entidades organizacionais para efectuarem trocas de dados electronicamente.

Para a gestão de todo este fluxo de dados utilizamos o portal do Windows Azure para o EDI, que pode ser encontrado em A explicação de como o mesmo está arquitectado vem a seguir.

Como funciona? EXEMPLO PRÁTICO

  1. Uma      mensagem EDI é recebida por um parceiro de trocas de dados, FABRIKAM. Para      receber mensagens EDI de parceiros de trocas, o Service Bus EAI and EDI      Labs suporta protocolos de transporte como FTP, AS2 e HTTP/S.
  2. O acordo      de trocas de dados do lado do receptor, desmonta a mensagem EDI para XML. Podemos      criar uma rota para enviar a mensagem desencriptada (agora em XML) para um      ponto-de-chegada do Service Bus Relay ou Service Bus Topic ou Queue ou      então uma Service Bus Bridge.
  3. Mensagens      em XML desencriptado podem então ser recebidas de um ponto-de-chegada para      um possivel futuro processamento à medida. Estes pontos-de-chegada do      Service Bus podem então ser processados por um processo local ou uma      instancia do Windows Azure Compute para um futuro processamento da      mensagem num WF ou WCF por exemplo.
  4. O lado do      processamento de envio do parceiro do acordo pode construir a mensagem XML      no formato EDI e enviá-la para o parceiro de troca de dados, CONTOSO. Para      enviar mensagens EDI para parceiros de troca de dados, o Service Bus EAI      and EDI Labs suporta os mesmos protocolos usados para receber mensagens      EDI.

Opções de navegação

PARTNERS – Seccção de gestão dos parceiros. Ao seleccionar esta opção temos a possibilidade criar e eliminar parceiros.

AGREEMENTS – Seccção de gestão dos acordos. Ao seleccionar esta opção podemos criar e eliminar acordos.

RESOURCES – Seccção onde podemos gerir todos os recursos existentes no nosso deployment space do windows azure. Podemos adicionar e remover schemas, mapas e certificados de segurança.

TRACKING – Secção onde pudemos consultar o histórico de trocas de mensagens EDI entre parceiros. Mostra entre outros, se teve sucesso, quem enviou e log details de todo o trajecto.

SETTINGS – Secção onde especificamos o namespace azure a utilizar bem como todas as informação referentes à entidade gestora do portal. Permite ainda gerir o provisionamento da infrastrutura EDI.


Creating a LOB Target with Windows Azure Service Bus EAI and EDI Labs – step-by-step [en-US]

Check it in Microsoft technet wiki:

What is a LOB target?

A LOB target is our local system business line (Line-Of-Business) and it´s respective operations, for example SQL Server can be viewed as a local LOB system and a  Select and Insert  it´soperations and is exposed to client applications (it is integrated in them). Specifically a LOB target controls the connection to the LOB system URI (mssql :/ / SQLBIZTALK: 1433 / / basededados), its operations (insert, select, update, delete …) and the connection credentials (username and password).
This LOB target can be used by multiple LOB systems and is stored in a  LOB relay. This LOB relay is as it was said the URL that allows the connection to the cloud (Azure) using the Service Bus Relays. It is also a repository of multiple LOB targets.

Creating the LOB target

The creation of a target LOB SQL assumes that you have the Windows Azure SDK EAI and EDI Labs installed and configured on your machine.
So the process starts by configuring a server in ServiceBus Connect Servers located in Server Explorer in Visual Studio:

By selecting Add Server a dialog box in which we have to specify only the path to the file ManagementService.svc, from the IIS Manager, appears.

The pathways normally used by IIS are:

If the Service Connect bus runtime be installed locally with the default settings:

If the Connect Service Bus runtime to be installed remotely with the default settings:

In my case the option would be https://localhost:8080/SBConnect/ManagementService.svc/  because im working locally.
With the address configured, we get the following expansion in ServiceBus Server in Visual Studio:

We can see that the server was filled with the LOB Types that are installed, using the LOB client libraries on the machine, remember that. NET framework 4 install SQL Server LOB type automatically.
We now start to configure the target SQL LOB. Clicking the right mouse button in SQL within SQL LOB Types  we select Add SQL Target.

Selecting the described option in the Visual Studio configuration wizard  to create the LOB Target opens:

We now follow the this set of steps:

1.Selet Next on the first image of the Wizard

2.Typpe in the data to access your SQL database that we want, providing the name server, the instance of SQL Server and the name of the database (Catalog). Leave the option Use Windows credentials credentials checked.

3. In the next window of the Wizard we specify the operations that we want to provide the system we want to achieve. In my case i will choose for example the insert operation into the database and to select from database.

4. We click Next and reach the page of runtime security, in which we define how the server will authenticate the target LOB when a message arrives from a client. The options are:

a. Fixed Username: Simplest form, using a username and password stored on the server.

b. Fixed Windows Credentials: Use Windows credentials stored on the server.

c. Custom SOAP Header: The client sends the username and password through a header of a SOAP message.

d. Message-Credential: The client sends the username and password through a security-WS (Web Services Security) header of the message.


Let’s choose the option Fixed Windows credential, providing the user name and password of the windows as well as the domain of the local network.

            5.Click Next, and reach the window where we have to specify the URL for sending LOB target, wich means the path to the location in the cloud where the messages will be sent.
We can select a URL to a LOB relay (Provides connectivity for our LOB targets using the Service Bus Connect) existing or create a new one, let’s choose the option to create new and we have to specify:                            

namespace: namespace name given to the portal created AppFabric azure                             

Issuer Name: name of the owner of the namespace azure

Issuer Key: key provided by the specified namespace for azure                             

Relay Path: path to lob relay that will store the LOB targets                             

Sub-path: this is the only field in which one can give any value (significant) , is where the LOB target is stored  and distinguishes this LOB target from other existing LOB in the relay.

The first three values can be found in the portal Azure AppFabric, located at the following address -> and in the following location:
In the portal page, we select the namespace we want to associate with the target LOB and click on view inside the groupbox Default Key, as we see in red.

Selecting view, we get the following dialog box where you can check the values you want, my issuer key is hidden (personal data) as expected.

Continuing the configuration of the target LOB, fill requested values:

6. Select Create and you will see a summary page:


Click on next and if all was corrrectly done, get a success window.

WARNING : One of the most common mistakes when setting a LOB target is using a namespace created in conventional Azure portal (Azure Platform), in which case the domain of our namespace would be instead of Namespace. as well as management edpoint URL would be  instead of, this change will cause an error AppFabric because it can not resolve the address of azure namespace and the following message will be displayed when we select Create in step 6:

With this final warning we finish the tutorial to create a LOB target and we are able to transmit messages via cloud for this SQL Server database.


Rui Pedro Machado