Tuesday, October 15, 2013

Service bus management – here's a way

UPDATE: this post contains a lot of additional great suggestions
 
How to create a consistent DTAP environment, which standards to adhere to, what naming conventions to apply, how to document these….all questions….the answers….a little cloudy. In this post I show how I use the tool Service Bus Explorer to my advantage for some of these questions.
·         Goal: create a consistent environment for DTAP
·         Challenges
1.       Naming conventions on Windows Azure (sb / queues / topics etc)
2.       Isolation of environment and thus billing
3.       Repeatable steps / Configurable using a tool / xml configuration
 
#1: Naming conventions
Are they out there for Azure? This is a future subject for a WindowsAzure live chat session.
·         My #1 rule: make sure that the naming convention you think of are consistent
·         An example convention: <Customer><Project><Type><Artefact> (Contoso.Broker.Transform.FormatA2FormatB) would not translate well to an Azure queue or service bus due to the long name, so we need to split this up into smaller pieces, a way could be
1.       Create a subscription for the customer
2.       Start the entity name with the project
3.       The Azure Portal already takes care of separating the artefact types, so pre- postfixing it (sbbrokerorders / brokerqorderinqueue or brokerorderinqueue) would not improve or help in maintainability, this is up to you.
 
#2: Isolated billing
The only way to really isolate the billing, is to create several subscriptions. This is my recommendation anyway, as migrating subscriptions is something that you do through a support call and is thus out of your control in situations mentioned in my previous post
Dedicated service bus namespaces will show up in a different line in the exported bill as shown in the exported bill below

image

#3: Repeatable steps / configurable using a tool / xml configuration
My approach is shown in below and is applied on service bus namespaces and Queues. However, this is because the tool I’ve chosen is Service Bus Explorer, I’ve suggested this type of abilities to several vendors as they were open to feedback, so who know, this type of approach might become possible for all tools / portals.
Consider my list of service namespaces:
·         Sbprojecttest
·         Sbprojectdev

image
·         Download service bus explorer
There is a precompiled version already included in the release, you can also start visual studio and build this one.
 
image
 
·         Open the ServiceBusExporer.Exe.Config
Add the different namespaces you want to manage from ServiceBusExplorer as shown in the picture below.

 
image
·         Start Service Bus Explorer and connect to a service bus namespace (from the config)
image
·         Connect to the environment

image

·         Create the queues we would like to deploy consistently

image
·         Export the entities
image
·         View the exported settings
image
This is the first step, this config file is now exported as Xml. We can view all the settings and use a tool or program to manipulate this configuration file. We can add this configuration file into TFS etc.
·         Connect to a different service bus namespace (e.g. sbprojecttest)
We can see that at this point, there are no queues….
image
·         We will import the entities using the configuration file
image
·         The import will create the queues with the specified settings in the configuration file
image
 
·         In Azure, we now have 2 service bus namespaces, with a consistent configuration

image
image
 
Note: Yes, you can always use PowerShell. For my case, I wanted an approach I can easily explain to anyone capable of using a computer without installing anything. Additionally, you need to create these scripts yourself, as it is now, there are differences in On Premise Service Bus and Azure Service Bus, so that didn’t work for my scenario. Additionally, I only needed to retrieve the service bus namespace connectionstring and configure this in the Service Bus Explorer, and didn’t had to retrieve the publishsettings etc.
Note 2: Managing and Using the Queues should be separated (IMHO). By using a tool like Service Bus Explorer to create a consistent environment using config files or by using powershell. If your code creates a queue when it’s now there, shouldn’t an alarm go off? Aren’t the queues durable, and always available, I assume yes and like to monitor for this particular situation, as it’s probably a showstopper.
 
Note3: You can also create a dedicated subscription for DEV/TEST/ACC for each service bus namespace (depending how much you like to manage). For production it would be best to always create a dedicated subscription.

HTH,
Sander

Tuesday, October 08, 2013

Exposing an REST Endpoint (POST) which processes Xml

For my project I needed to expose an Endpoint, which accepts an HTTP Post with Xml as input/output. As I like to start small I’ve tried to start with a small test project. In this project, I wanted to learn how to expose an endpoint, how to set everything up and what options are there.

This, because there are a lot of resources on all sort of specific issues, but the ones I faced were scattered in several blogposts.

So for my project I developed a WCF Service, which was created using a WCF Webrole so that I can also publish it in Azure.

·         Create a new WCF Webrole

o   Create a new Cloud service

clip_image002

o   Create a new web role

clip_image004

o   Which should result in a similar structure

clip_image006

·         Configure the endpoint to use WCF-WebHTTP and allow a help page

At this point, you have a WCF Service, which is not yet exposed a WCF-WebHTTP endpoint. We can do this by:

o   simply changing the Web.Config

clip_image008

clip_image010

 

o   Add a method which accepts Xml and decorate it with the ‘WebInvoke’ attribute

clip_image012

 

·         View the help page

After deploying the webservice, we can navigate to the help page

clip_image014

·         Now we can view specific methods, and for each method the parameters are shown

I want to look into each specific option…

DataContract with CompositeType

This allows specifying a custom type, this is serialized into Xml and can be used and tested using the WCF Test client and is quite straightforward

clip_image016

We can use Fiddler to test this. Set the following:   Content-Type: text/xml

clip_image018

clip_image020

Primitive types

Primitive types, can be processed using supported formats out of the box, which are JSON / XML.

clip_image022

Format JSON supports sending plain data, we can do this using Fiddler, by setting Content-type: application/json

clip_image024

clip_image026

We see however, that the response is of the type XML format, so when using JSON, we need to explicitly set the response format.

We can also see that (although I’m not the single point of truth), the Format XML does not support sending plain data, format Xml uses a serializer, thus expects the input wrapped in an Xml string.

So a request must be submitted (according to the help page) as

clip_image028

A test using the xml format, using Fiddler, can be done by setting Content-type:  text/xml.

clip_image030

There is one option you can apply on the ServiceContract level, and that is, setting the XmlSerializerFormat.

clip_image032

This makes life a little bit easier….

clip_image034

However, this does not work….and I gave up…..for a day. My conclusions so far were:

·         Working with primitive types is not that simple L

·         Formats are limited (for my purpose) and I need to write a custom format

·         If such a simple approach already leads to this type of issues, how will I ever manage to process Xml

Xml Documents

The next day…i thought about my plan...All I wanted, was to start with the basics and build my way up, to send/receive Xml. I did this trying to start with primitive types and then use an XmlDocument etc. However, it didn’t worked as I wanted, so I thought…..let’s start from scratch, using XmlDocuments.

clip_image036

Using Fiddler to submit a request, using Content-Type: text/xml..

clip_image038

Response…bad request?

clip_image040

No….wrong code…you should always set the XmlSerializerFormat! (Unless using the Composite type!)

clip_image042

Victory!

clip_image043

 

So I learned 5 things:

·         The WebHTTP Help (<webHttp helpEnabled="true" />) is incredibly useful

·         WCF-WebHTTP works with primitive types using the XML format by default,this  implies the XmlSerializer, when you don’t want this, you need to implement your custom format

http://msdn.microsoft.com/en-us/library/ee476510.aspx

http://blogs.msdn.com/b/endpoint/archive/2010/02/01/returning-custom-formats-from-wcf-webhttp-services.aspx

·         Processing Xml can be done by creating a custom CompositeType, or by using an XmlDocument

·         The Content-Type is something you need to set right

·         As always, Fiddler is a great tool

 

HTH,

 

Sander