Damir Dobric Posts

New WCF Bug fixes released in KB2805222

2013-06-18T08:35:42Z

In the .NET Framework 4.5, WCF introduces a new method named "Reflection Emit" that generates the XML Serialization assembly. This method enables scenarios where the client application cannot write a temporary serialization assembly to disk. In some cases, this may cause issues after you upgrade to the .NET Framework 4.5.
The ability to opt out of this new behavior and revert to the WCF 4 XML serialization is documented in the following KB article:

2748720

(http://support.microsoft.com/kb/2748720/ )

Serialization or deserialization failures when you run existing XML serialization code in WCF 4.5

In a .NET Framework 4.5-based application, you can use the following code as the workaround that is described in KB 2748720:

<configuration>    <system.xml.serialization>        <xmlSerializer useLegacySerializerGeneration="true"/></system.xml.serialization><configuration>

Assume that you also use the same application.config file or web.config file to target both the .NET Framework 4 and the .NET Framework 4.5. In this situation, you encounter an exception that indicates the <xmlserializer> element cannot be recognized under the <system.xml.serialization> attribute.
For applications that try to target the .NET Framework 4 and the .NET Framework 4.5, we recommend that you apply the following <appSetting> configuration to a replace the previous switch:

<appSettings>    <add key="System:Xml:Serialization:UseLegacySerializerGeneration" value="true"/></appSettings>

Notes

Both switches work in the .NET Framework 4.5. However, the <appSettings> switch will make sure that the app.config file or web.config file can be transferred between the .NET Framework 4.0 and the .NET Framework 4.5. If you apply both the switches, only the <appSettings> switch will be used.
When a .NET Framework 4.0 application uses the "UseLegacySerializerGeneration" configuration element, the application returns a configuration error.

This update also resolves the following issues after you upgrade to the .NET Framework 4.5.
Issue 1
When you deserialize simple arrays that are serialized as an XmlAttribute, the operation fails. Additionally, you receive the following error message:

System.XML.XmlException ‘EndElement’ is an invalid XmlNode Type.

After you upgrade to .NET Framework 4.5, IIS may return an HTTP400 - 'Bad Request' error.
Issue 2
Consider the following scenario:

A base class "A" and a derived class "B" try to serialize or deserialize an object of "B".
A virtual property is defined in "A" and is overridden by "B".

In this scenario, the serializer outputs the property that is defined in "A" instead of "B".

DOWNLOAD KB: http://support.microsoft.com/kb/2805222

Ordered Workflow Activation in (SharePoint) Workflow Manager

2013-06-11T18:18:00Z

Imaging you are receiving some events which have to be used to activate new workflow instance Wi of some workflow type W.
As long the workflow completes faster than new events arrives, successive workflow activation will execute ordered. That means for each event Ek, workflow instance Wk will be activated in the same order as events arrive. However, sometimes you expect ordered execution of workflows by design. That means next instance of the same workflow must not be started until the previous one has completed successfully.

Technical Design

Due asynchronous activation on Service Bus, you are not in control of activation of specific instance. So, to make asynchronous thing synchron is not easy task. This blog post describes one of more or less solutions which do not require any additional service or similar artifact.

To make this working, implement your workflow in XAML. Then create new workflow (see blue shape below) and paste all activities from your workflow in the new workflow (black frame on picture below).

The circle on top of the workflow is the part which you have to implement. That part of workflow will guarantee the ordered execution. We will pump activation messages in the Service Bus queue as they arrive and Workflow will execute them in the received sequence. Following picture shows more details. If the workflow instance ( the only running instance) fails during execution Service Bus will automatically retry failed message when workflow is resurrected.
This is because Workflow Manager receives messages by “Peek And Lock” . If the workflow fails the message will be abandoned 10 times. This means workflow can fail up to 10 times!! This is default behavior which can be changed by manipulating the topic.

How to create Workflow which receive notifications?

The blue shape on the picture above can be implemented as follows:

Notice following 3 activities:

BuildMatchAllFilter
Subscribe
ReceiveNotification

BuildMatchAllFilter is the activity which is usually used by publishing of the workflow. It defines the message which will activate the workflow.
Following code shows how this works:

                client.PublishWorkflow(wf.Name, wf.Name,
                new MatchAllSubscriptionFilter()
                    {
                        Matches =
                        {
                            {"RunWorkflow", “Ordered”}
                        }
                    });

The designer equivalent of the same code looks like shown below:

MatchFilter must first define the messages, which will activate it. The definition of this filter is then saved in the variable SubscriptionHandle.
As next Subscribe Activity must be configured.

When executed the SubscribeActivity practically creates the subscription on the Workflow Topic and appends the Rule defined by the filter.
Exact description of this is behind scope of this article, but Service Bus folks will understand what this could mean.

The last important activity in this scenario is ReceiveNotificationActivity. In the world of AppFabric this would be ReceiveActivity, which listens on SOAP messages.
in contrast to ReceiveActivity, ReceiveNotificationActivity listens for messages on the topic subscription.

By configuring of this activity, you can leave Properties empty if you work with filter and subscription handle as we do in this case.
To receive the message you have two options:

- To use filter or
- To use SubscriptionHandle

You cannot use both!

If you use Filter, then ReceiveNotificationActivity will receive message and immediately remove the subscription from topic. In workflow like our one when ReceiveNotification is inside of the loop is using of filter (as property of ReceiveNotification) no-go!
Why? Assume some client is sending lot of messages which have to be processed. This is exactly scenario which we are describing in this article. In this case, the message will be received and subscription removed.
As long the workflow activities are executing business logic after the message is received, all upcoming messages will not be delivered to subscription, because subscription does not exist at all (remember, it is removed after receive). Practically you will loose messages.
To fix this you have option to leave Filter property empty (like in picture below) and to set SubscriptionHandle. As long this handle instance exists, subscription exists and messages are delivered to it. hat mean they ill remain inthere as long the business logic is executing.

The logic which I used to approve this scenario looks like shown below:

I have counted and persisted all incoming messages in several scenarios to approve this. The best way to see this in action is to put Delay activity to slows down the processing logic while
activation messages are pumped in. Following code snippet shows how this work.
After all messages are sent, attach to Workflow Host process and investigate how all messages are processed.

            x = 1000;
            while (x > 0)
            {
                var res = client.PublishNotification(new WorkflowNotification()
                {
                    Properties =
                            {
                                { "RunWorkflow", "Ordered" }
                            },
                    Content = new Dictionary<string, object>()
                            {
                                { "Arg1", x.ToString() },
                                { "Arg2", new Random().Next() }
                            }
                });

                Trace.WriteLine(res);

                Thread.Sleep(0);

                x--;
            }

AppFabric Security groups at once

2013-06-06T17:02:00Z

When working with App Fabric you might be confused with security model. In this post I will try to describe all security at once.

Application Server Observers
This administrative role gives you full visibility into application persistence and monitoring data. Application Server Observers can:

Enumerate applications and services
View application and service configuration
View monitoring data
Examine persisted instances

Application Server Administrators
This administrative role gives you full control over application configuration, monitoring, and persistence. Application Server Administrators can execute all tasks that the Application Server Observers group can do, as well as the following tasks:

Suspend, resume, terminate, cancel, and delete persisted instances
Create and remove event sources and event collectors
View, purge, and archive monitoring data

Application Server Users (IIS_IUSRS)
The runtime role is used by IIS at run time to assign the identities of all its application pools hosting applications. This gives the services contained in the applications shared access to persistence databases and system services.
This role is used in instance store database only!

Monitoring

Following “diagram” shows securables of AppFabric Roles in monitoring database.

Peristence

Following “diagram” shows securables of AppFabric Roles in instance store (persistence) database.

Workflow Activation in (SharePoint) Workflow Manager

2013-06-06T06:00:00Z

If you want to implement the long running business process or in other words to automate the business process, the Windows Workflow Foundation is definitely great choice.
In addition you might probably want to use the host like AppFabric and Workflow Manager. Assuming that you are SharePoint guy or you simply do not want to use SPC activation (Web Services, Workflow Services and Co.) your way of choice will be Workflow Manager.

Create and Publish

In this case you will implement some workflow. Let’s take a look on following sample workflow:

This workflow check input argument value ‘Arg1’ of type string. If it is “stop” it will be terminated. Otherwise it will increment some counter, Assign the Msg-value and set the user status. All this is not for now simulation of some business logic.
To activate this workflow you have to do two things:

1. Publish the workflow
2. Start the workflow.

In a case of SharePoint you do not have to do these steps. SPS will create and publish the workflow for you. However if you want to do more advanced implementation, you will have to do it by yourself.
Following code snippets shows how to publish the workflow by using of few helper methods.

. . .

var client = rootClient.CreateChildScope("MyScope", "Host workflow which execute ordered workflows in sequence.");

client.Activities.PublishWorkflow(“WorkflowName”, “C:\\Temp\…\workflow.xaml”);

. . .

CreateChildScope will create the child scope under the scope defined by ScopePath property of WorkflowManagementClient instance.

public static WorkflowManagementClient CreateChildScope(this WorkflowManagementClient
         client, string scopeName, string comment)
        {
            var sD = new ScopeDescription()
                {
                    UserComments = string.Format(comment, scopeName)
                };

            return client.CurrentScope.PublishChildScope(scopeName, sD);
        }

One of very important steps in publishing process is translation of expressions. Unfortunately this is required as long .NET framework cannot
perform his on the fly, due missing compiler services, which will come soon.

   public static XElement Translate(string xamlFile)
        {
            string translatedWorkflowString = null;

            using (XamlReader xamlReader = new XamlXmlReader(xamlFile))
            {
                TranslationResults result = ExpressionTranslator.Translate(xamlReader);
                if (result.Errors.Count == 0)
                {
                    StringBuilder sb = new StringBuilder();
                    using (XmlWriter xmlWriter = XmlWriter.Create(sb,
                           new XmlWriterSettings { Indent = true, OmitXmlDeclaration = true }))
                    {
                        using (XamlXmlWriter writer =
                        new XamlXmlWriter(xmlWriter, result.Output.SchemaContext))
                        {
                            XamlServices.Transform(result.Output, writer);
                        }
                    }
                    translatedWorkflowString = sb.ToString();
                }
                else
                {
                    throw new InvalidOperationException("Translation errors");
                }
            }

            return XElement.Parse(translatedWorkflowString);
        }

Finally we can publish the workflow. In this step we will create the workflow on the fly (new WorkflowDescription). The body of this workflow will be
activity whose path is passed in argument xamlFilePath. Note that in this process we do not need any compiler. We simply take a XAML and publish it.
If your workflow references some custom types which are not a part of type system you will have to extend the trusted surface, before you publish the workflow

public static void PublishWorkflow(this WorkflowManagementClient client,
                                   string workflowName, string xamlFilePath)
        {
            // publish the activity description related with the workflow
            client.Activities.Publish(
                new ActivityDescription(Translate(xamlFilePath)) { Name = workflowName });

            // now, publish the workflow description
            WorkflowDescription description = new WorkflowDescription
            {
                Name = workflowName,
                ActivityPath = workflowName,
            };

            // publish!
            client.Workflows.Publish(description);
        }

Start/Activate

If you want to start this workflow, you need to send the activation message to Workflow Manager Front End service. The simplest way to start (activate) the workflow is to send call Start() method.

client.Workflows.Start(m_WorkflowName1);

However this does not give you any flexibility, like input arguments, configuration etc.
For example, let’s assume the workflow has argument: ‘myarg’ of type string.

In this case you would start the workflow as follows:

WorkflowStartParameters startParameters = new WorkflowStartParameters();

startParameters.Content.Add("myarg", "Value1");

string instanceId = client.Workflows.Start(m_WorkflowName1, startParameters);

Sometimes things are getting more complicated. Imagine you are receiving some data and have lot of different workflows which you want to activate based on data.
In his case you can inject the activation filter in workflow during publishing process.

   client.PublishWorkflow(workflowName, @"myworkflow.xaml",
                new MatchAllSubscriptionFilter()
                    {
                        Matches =
                        {
                            {"ActivationProp1Name", “Tenant1”}
                        }
                    });

This means the workflow will be activate if Service Bus receives the message with property ActivationProp1Name which has a value “Tenant1”.
To send this message (to start/activate this workflow) you can do following:

client.PublishNotification(new WorkflowNotification()
            {
                Properties =
                {
                    { "ActivationProp1Name", "Tenant1" }
                },
});

If you didn’t understand the power of this, take a look on next example which publishes lot of different workflows for different tenants.

foreach(var wf in Workflows)

client.PublishWorkflow(wf.Name, wf.Name,
                new MatchAllSubscriptionFilter()
                    {
                        Matches =
                        {
                            {"ActivationProp1Name", wf.Tenant}
                        }
                    });

service.Receive(string tenant){

PublishNotification(new WorkflowNotification()
            {
                Properties =
                {
                    { "ActivationProp1Name", tenant }
                },
             });
}

If the workflow expects input arguments, you can append them to activation message:

client.PublishNotification(new WorkflowNotification()
            {
                Properties =
                {
                    { "ActivationProp1Name", "Tenant1" }
                },
                Content = new Dictionary<string, object>()
                {
                    { "mayarg", “value1” },
                    { "myarg2", 123 },
                }
            });

POST https://sb17.daenet.lab:12290/myworkflow/$Workflows/Workflow1/$Start HTTP/1.1
User-Agent: Microsoft-WF/1.0.1
Accept: application/xml
Content-Type: application/xml
E2EActivity: i3SI8snqbEShZdcB8Tb7dg==
Authorization: Negotiate ******==
Host: sb17.daenet.lab:12290
Content-Length: 406
Expect: 100-continue

<WorkflowNotification xmlns="http://schemas.microsoft.com/workflow/2012/xaml/activities" xmlns:i="http://www.w3.org/2001/XMLSchema-instance"><Content i:type="a:ArrayOfKeyValueOfstringanyType" xmlns:a="http://schemas.microsoft.com/2003/10/Serialization/Arrays"><a:KeyValueOfstringanyType><a:Key>mayarg</a:Key><a:Value i:type="b:string" xmlns:b="http://www.w3.org/2001/XMLSchema">value1</a:Value></a:KeyValueOfstringanyType><a:KeyValueOfstringanyType><a:Key>myarg2</a:Key><a:Value i:type="b:int" xmlns:b="http://www.w3.org/2001/XMLSchema">123</a:Value></a:KeyValueOfstringanyType></Content><Properties xmlns:a="http://schemas.microsoft.com/2003/10/Serialization/Arrays"><a:KeyValueOfstringanyType><a:Key>ActivationProp1Name</a:Key><a:Value i:type="b:string" xmlns:b="http://www.w3.org/2001/XMLSchema">tenant1</a:Value></a:KeyValueOfstringanyType></Properties></WorkflowNotification>

The same data formatted as XML:

Messaging on Windows RT

2013-06-04T20:36:00Z

As probably known the cloud messaging platform in Windows Azure is based on Service Bus technology. Few months ago Microsoft has published the Windows Azure Toolkit for Windows 8 which provided the same API for Windows RT.
Unfortunately this library has been deprecated. The new WinRT library for Service Bus is now part of Windows Azure Mobile Services and can be downloaded here.
Note that the new so called messaging managed library is simplification around existing Service Bus SDK. Do not be surprised if you cannot find yourself in the new library. The good thing is hat If you are novice in this are you will feel relaxed. :)

API style is changed

In common version of Service Bus SDK (currently 2.1) you can do something like this:

var appuserCli = QueueClient.CreateFromConnectionString(“…”, “myQueue”, ReceiveMode.ReceiveAndDelete);

appuserCli.Send(new BrokeredMessage("abc"));

var m = appuserCli.Receive();

However the WinRT version is very different. For example WinRT version does not know anything about BrokeredMessage. There is now the new message simply called Message. The WCF guys and most old school guys will be probably disappointed with this, because Message is well known type from System.ServiceModel. But who cares? Most hobbyists who develop apps do not known what service model is (This is something behind WCF).

Another interesting thing that API style is shifting from commonly well known used style in .NET framework. For Example QueueClient is the class which provides operations to deal with Messaging Entities like Queue or Topic.
It looks like:

QueueClient.DoSomethingOn(Queue);
QueueClient.DoSomethingElseWith(BrokeredMessage);

The new API on WinRT looks different:

There is no QueueClient and similar things!!!
Message entities are no more entities. They are now active objects, similarly like in C++ era in he late 90-ties. Here is an example:

Queue.DoSomethingWith(Message);

To me, the number of types is reduces (it is simpler), but the API design is not the best one or not the common one at least in the .NET framework.

Queue queue = new Queue(m_QueueName, m_ConnStr);

await queue.SendAsync(new Message("bla"));

await queue.ReceiveAsync();

Serialization Defaults are different

The most interesting thing is that by default these two libraries are even not compatible with each other. Of course they are, bit take a look on following example and you will understand what I mean with incompatible.
In following example Desktop application sends the message which will be consumed by WinRT app. In this case WinRT app will fail with serialization error.

Desktop:

var appuserCli = QueueClient.CreateFromConnectionString(“…”, “myQueue”, ReceiveMode.ReceiveAndDelete);
appuserCli.Send(new BrokeredMessage("abc"));

WinRT

Queue queue = new Queue(m_QueueName, m_ConnStr);
var msg = await queue.ReceiveAsync();

Ok, then let’s try following:

WinRT

Queue queue = new Queue(m_QueueName, m_ConnStr);

await queue.SendAsync(new Message("bla"));

Desktop

var appuserCli = QueueClient.CreateFromConnectionString(“…”, “myQueue”, ReceiveMode.ReceiveAndDelete);

var m = appuserCli.Receive();

Now, Desktop application will fail with serialization error. So what is the point?
The Desktop SDK uses under the hub XmlObjectserializer to deal with messages. WinRT bits however use DataContractJsonSerializer. The result of this is messages send from different Windows Platform are differently formatted and not compatible.
To fix this, you new to provide the expected serializer.

If you are polite you should do it in the desktop application as follows:

var appuserCli = QueueClient.CreateFromConnectionString(“…”, “myQueue”, ReceiveMode.ReceiveAndDelete);

var msg = appuserCli.Receive();

var txt = msg.GetBody<string>(new DataContractJsonSerializer(typeof(string)));

Expression Translation Error when Publishing SharePoint Workflow

2013-05-30T08:15:00Z

When publishing the workflow with

client.PublishWorkflow(workflowName, "MyWorkflow.xaml");

you may notice ExpressionTranslation Errors. Usually these errors briefly explain the problem. Unfortunately there is one strange case, which is difficult to explain.
To understand this take a look on following picture:

Interestingly, you will probably in this case notice that you even don’t have this file. Why then, translator is training to load some not existing file?
The problem here is the name of the path. ..\\External Variables\\C# (not shown in the error message, because expression translator cannot read it).
C# is the part of path which cannot be used. To workaround this issue, copy your project to any more human readable path and all will work.

Please also note, sometimes some workflow on the same path do not have this issue. These are probably VB-Expression based workflows, which comes from version 4.0 of Workflow Foundation.
That means this problem will happen on WF 4.5 C# workflows only.

SmtpClient error

2013-05-23T08:46:00Z

When working with SMTP client, you might get following error:

The SMTP server requires a secure connection or the client was not authenticated. The server response was: 5.7.1 Client was not authenticated

There are lot of answers out there related this error, because it can be caused by many different things.

The code shown below shows how you should implement the client which sends the mail.

NetworkCredential cred = new NetworkCredential("DOMAIN\\user", "pwd");
SmtpClient client = new SmtpClient("smtpservername.com");
MailMessage msg = new MailMessage(
new MailAddress("from@abc.de"),
new MailAddress("to@abc.de"));
msg.Body = "Hello.";
client.UseDefaultCredentials = false;
client.Credentials = cred;
client.Send(msg);

Unfortunately, there is one more thin you should be aware of. You first have to set UseDefaultCredentials to false and then to set credentials.
If you do it apposite way as next example demonstrates, you will get exception shown above.

NetworkCredential cred = new NetworkCredential("DOMAIN\\user", "pwd");
SmtpClient client = new SmtpClient("smtpservername.com");
MailMessage msg = new MailMessage(
new MailAddress("from@abc.de"),
new MailAddress("to@abc.de"));
msg.Body = "Hello.";

client.Credentials = cred;
client.UseDefaultCredentials = false;

client.Send(msg);

Behind Service Bus Connection String

2013-05-21T06:14:00Z

When working with Service Bus, it is very useful to make a usage of Service Bus Connection String to create SB-entities.
For example, following line of code can be used to create the QueueClient instance which can be used to send and receive messages:

var client = QueueClient.CreateFromConnectionString(connStr, “queuname”);

Connection string looks usually like:

"Endpoint=sb://yournamespacename.servicebus.windows.net/;SharedSecretIssuer=bla;SharedSecretValue=**obfuscated..=";

Connection String is very useful, because many information like service bus namespace and all credentials are contained inside of that staring. This enables creation of for example QueueClient in a single line of code.
In general Connection String is consisted of a moniker (sb://..) which includes protocol and URI with namespace. This defines the Endpoints and/or StsEndpoints.
Additionally it contains a number of so called connection properties which describe credentials.

Following picture illustrates the code which extracts all these artifacts inside of Service Bus library.

What is new in Service Bus 2.0?

2013-05-01T09:30:03Z

This post should give you a quick overview of new features of Service Bus. Note that I didn’t describe the MessageBrowse Feature, because it is already well described by other SB team colleagues.

MessagePump

When receiving messages from queue, you have been responsible to implement some kind of listener which will receive messages and dispatch them to some message processor.
With Service Bus 2.0 you can give this responsibility away. SB v2 provides an event driven message receiver based on message pump implementation.
Following code snippet shows how easy you can receive messages now.

   client.OnMessage((msg) =>
            {
                Console.WriteLine("ThreadId: {0}, Message: {1}",

                Thread.CurrentThread.ManagedThreadId, msg.GetBody<string>());

                if (cnt == 10) // because we expect 10 messages.
                    return;
            },
                new OnMessageOptions()
                {
                    AutoComplete = true,
                    MaxConcurrentCalls = 5
                }
               );

OnMessageOptions can be used to specified the number of concurrently processing messages. If you want to process one by one message ( one thread only) specify value one here.
Independent on his value messages are always processed on another thread.

Last but not least in OnMessageOptions you set AutoComplete, if you want that message is completed after successful execution of callback.

Suspend and Resume Queue

The queues and topics can be now suspended and resumed. This can be achieved by manipulating the status of the queue:

// Summary:
    //     Enumerates the possible values for the status of a messaging entity.
    [DataContract(Name = "EntityStatus", Namespace = "http://schemas.microsoft.com/netservices/2010/10/servicebus/connect")]
    public enum EntityStatus
    {
        // Summary:
        //     The status of the messaging entity is active.
        [EnumMember]
        Active = 0,
        //
        // Summary:
        //     The status of the messaging entity is disabled.
        [EnumMember]
        Disabled = 1,
        //
        // Summary:
        //     Resuming the previous status of the messaging entity.
        [EnumMember]
        Restoring = 2,
        //
        // Summary:
        //     The sending status of the messaging entity is disabled.
        [EnumMember]
        SendDisabled = 3,
        //
        // Summary:
        //     The receiving status of the messaging entity is disabled.
        [EnumMember]
        ReceiveDisabled = 4,
    }

Following sample illustrates how this work:

        /// <summary>
        /// Suspend and Resume sample.
        /// </summary>
        private static void suspendResumeSamnple()
        {
            string qName = "hello/msgpump";

            var qDesc = prepareQueue(qName);

            var client = QueueClient.CreateFromConnectionString(m_ConnStr,
            qName, ReceiveMode.PeekLock);

            Console.WriteLine("Sending messages...");

            for (int i = 0; i < 10; i++)
            {
                client.Send(new BrokeredMessage("i = " + i.ToString() + ", payload = "
                + new Random().Next().ToString()));
            }

            int cnt = 10;

            client.OnMessage((msg) =>
            {
                Console.WriteLine("ThreadId: {0}, Message: {1}",
                Thread.CurrentThread.ManagedThreadId, msg.GetBody<string>());

                Thread.Sleep(1000);

                if (cnt == 10)
                    return;
            },
             new OnMessageOptions()
             {
                 AutoComplete = true
             }
            );

            // Wait to receive few messages.
            Thread.Sleep(2000);

            NamespaceManager namespaceManager =
            NamespaceManager.CreateFromConnectionString(m_ConnStr);

          // Suspend Queue
           qDesc.Status = EntityStatus.ReceiveDisabled;
            namespaceManager.UpdateQueue(qDesc);
            Console.WriteLine("Receive disabled!");

            Thread.Sleep(25000);

          // Resume Queue
            qDesc.Status = EntityStatus.Active;
            namespaceManager.UpdateQueue(qDesc);

            Console.WriteLine("Receive enabled...");

            Console.ReadLine();
        }

And finally, the picture below shows that receiving of messages is stopped for a while. Note that message pump might already has received a message in the moment of
disabling of receive operation. See blue underlined message. To resume the receiving (or any other suspended) operation just set the queue state to active again.

AutoDelete Queue on Idle

This features enables removal of queues which are not used for a while.
Following sample illustrate this. After sleep time (higher than specified delete on idle time) you can check if the queue exists.
If all works fine the queue will not exist. Note that specified time is not very exact. Do not expect that this time is exact like Swiss Watch.
The queue will not be deleted one second after specified time. I tried with idle of 5min and sleep of 6 and queue has not been deleted.

   private static void autodeletOnIdle()
        {
            var qDesc = prepareQueue("hello/autodelete");

            qDesc.AutoDeleteOnIdle = TimeSpan.FromMinutes(5);


            NamespaceManager namespaceManager = NamespaceManager.CreateFromConnectionString(m_ConnStr);

namespaceManager.UpdateQueue(qDesc);

Thread.Sleep(6 * 60000);

            if (namespaceManager.QueueExists("hello/autodelete"))
            {
                Console.WriteLine("Queue has been deleted");
            }
            else
            {
                Console.WriteLine("Queue has NOT been deleted!");
            }

            Console.ReadLine();
        }

The value supplied for TimeSpan of AutoDelete must be between 00:05:00 and 10675199.02:48:05.4775807.
All previously created queue (before version of SB 2.0) have the same default value like newly queues created queues. This value is the maximum allowed value 10675199.02:48:05.4775807, which is

more details about this in Haishi’s post.

Authorization Rules

One of really interesting improvements in V2 is support for ShareAccessSignature. The problem we usually have a related to sharing of keys and maintaining service identities in Access Control Service.
This is a task which I and most of you out there do not like. Now you can set permission on the queue/topic directly. The authorization is defined as list of rules and one rule would look like:

authorizationRule = ( KeyName, KeyValue, [AccessRule1, .., AccessRuleN]);

Programmatically authorization rule can be created as follows:

new SharedAccessAuthorizationRule("demouser1_can_Send", key1, new AccessRights[] { AccessRights.Send }));

The first argument is simply the name of the rule. For example: Rule1, ReadRule or transferAccountQueue.

The key must be 44 bytes long. I guess this is 256 bits base64 encoded. Otherwise you will get following error:

The remote server returned an error: (400) Bad Request. A SharedAccessAuthorizationRule only supports keys of size 44 bytes..

Anyhow, the be sure you can use a helper method to create the key:

string key1 = SharedAccessAuthorizationRule.GenerateRandomKey();

Then you have to append the list of rights:

// Summary:
    //     Specifies the possible access rights for a user.
    [DataContract(Name = "AccessRights", Namespace = "http://schemas.microsoft.com/netservices/2010/10/servicebus/connect")]
    public enum AccessRights
    {
        // Summary:
        //     The access right is Manage.
        [EnumMember]
        Manage = 0,
        //
        // Summary:
        //     The access right is Send.
        [EnumMember]
        Send = 1,
        //
        // Summary:
        //     The access right is Listen.
        [EnumMember]
        Listen = 2,
    }

After you setup permissions, participants can do following to access the entity:

var factory1 = MessagingFactory.Create(new Uri("sb://xyyyyy.servicebus.windows.net"),
TokenProvider.CreateSharedAccessSignatureTokenProvider("your rule key name", yourkey));

var clientDemoUser1 = factory1.CreateQueueClient(qName, ReceiveMode.PeekLock);

As long the keyName and key match all will work fine. Note that in this sample we didn’t use any credential from Access Control Service.

Following full sample illustrates how to deal with Shared Access Signatures.

private static void authorizationRulesSample()
        {
            NamespaceManager namespaceManager = NamespaceManager.CreateFromConnectionString(m_ConnStr);

            string qName = "hello/rule1q";

            string key1 = SharedAccessAuthorizationRule.GenerateRandomKey();
            string key2 = SharedAccessAuthorizationRule.GenerateRandomKey();

            if (namespaceManager.QueueExists(qName))
                namespaceManager.DeleteQueue(qName);

            QueueDescription qDesc1 = new QueueDescription(qName);

            qDesc1.Authorization.Add(new SharedAccessAuthorizationRule("demouser1_can_Send", key1, new AccessRights[] { AccessRights.Send }));

            qDesc1.Authorization.Add(new SharedAccessAuthorizationRule("demouser2_can_Listen", key2, new AccessRights[] { AccessRights.Listen }));

            //qDesc1.Authorization.Add(new SharedAccessAuthorizationRule("how_to_set_admin_perm", key3, new AccessRights[] { AccessRights.Manage, AccessRights.Listen, AccessRights.Send }));

            namespaceManager.CreateQueue(qDesc1);

            var factory1 = MessagingFactory.Create(new Uri("sb://frankfurt.servicebus.windows.net"), TokenProvider.CreateSharedAccessSignatureTokenProvider("demouser1_can_Send", key1));
            var factory2 = MessagingFactory.Create(new Uri("sb://frankfurt.servicebus.windows.net"), TokenProvider.CreateSharedAccessSignatureTokenProvider("demouser2_can_Listen", key2));

            var clientDemoUser1 = factory1.CreateQueueClient(qName, ReceiveMode.PeekLock);
            var clientDemoUser2 = factory2.CreateQueueClient(qName, ReceiveMode.PeekLock);

            clientDemoUser1.Send(new BrokeredMessage("abc"));

            try
            {
                // This one has not a right to send to queue.
                clientDemoUser2.Send(new BrokeredMessage("abc"));
           }
            catch (UnauthorizedAccessException)
            {

            }

            try
            {
                // This one has not a right to Listen on queue.
                var msg = clientDemoUser1.Receive();
            }
            catch (UnauthorizedAccessException)
            {

            }

            // This one can listen.
            var msg2 = clientDemoUser2.Receive();

            Console.ReadLine();
        }

More about this topic: http://haishibai.blogspot.de/2013/01/new-features-in-service-bus-preview_29.html

Task Based Api

Most of ServiceBus methods provides now async/await support. More about this feature:
http://blogs.msdn.com/b/windowsazure/archive/2013/04/11/task-based-apis-for-service-bus.aspx

(image copied from msdn – see URL above)

Video about SB v2 features:
http://channel9.msdn.com/Blogs/Subscribe/Whats-new-in-the-Service-Bus-NET-SDK-20

Sample for this solution:
http://code.msdn.microsoft.com/ServiceBus-V2-Features-6b29f2ca

Power of Windows Azure PaaS: State Share and Persistence in the cloud

2013-04-22T13:00:00Z

If you are experienced enterprise developer who targets the Microsoft platform, you have probably at least once in your have a requirement to share some state across different instance of an application.
But, if you are hobby developer or any other professional developer, who possible do not focus distributed systems, you will might find the term “State” in context of persistence a pure theory thing.
So who ever you are, let’s start with a simple theory thing.
Imaging you have in theory a trivial application (today I call such applications simply “apps”). Assume this is an app running on smart phone or any other mobile device. This app has a variable ‘A’ and value assigned to this variable ‘1’. This value is not the default value. It is rather the value which user has assigned at some point of time.

Now, imagine the application crashes and you start it again. The value of variable A is obviously lost. If you want to keep this value somewhere, so it can be loaded even if application crashes. We call that usually persistence. Depending on application and your skill, there are several ways to persists the value of an variable. For example you can use any kind of local cache, like a file system.

But what if your application has to survive the hardware damage? Or what if your application is consisted multiple clients which have to share the same value? In this case you will have to use some kind of database.
As long you are in control of your infrastructure (means application is deployed in your enterprise) you can use some database to persist the value. The good example of this is Workflow Foundation. Long running processes require by default the state persistence.
Unfortunately we have more often scenarios where applications are distributed across the web. In such cases the only sharing artifact between such applications is the cloud. Following picture shows how two apps (or applications) share their state through the cloud.

This is a nice theoretical case which is practically a horror to implement. I strongly believe that today we are implicitly preparing for dominance of devices in the web. In this hypothetical scenario both devices (see picture above) should act as services to be able to share their state. If you are distributed application or integration developer you know that connectivity us such scenarios is a big, big issue. Or simply, it is the fact, devices in the web have a private IP address and because of that they are not reachable by anybody. So if the microscope on the left cannot reach the smart-phone on the right, the state from left to right cannot be propagated and vice versa.

If this to theoretical to you, imagine just a service which is running distributed across cloud. This might be WCF service, Windows Service (running in SCM) or even Web Api based service. Whatever technology you peek, it does not matter. The only important thing is that you want run multiple instances of the service, but on two machines which are not in the same environment (if they are in the same environment even better). So that means, independent on a case, devices or services or both, we have the same requirement:

1. Sharing of the state between applications distributed in the web
2. Persisting of the state without database.

You believe or not, this problem can be solved by using Windows Azure Service Bus, which in this case plays a role of cloud artifact. To illustrate how this can work, take a look on following example.
This is a console application in C#. The state which should be shared and persisted across many applications is stared in variable State.

class Program{

public static WebState<string> State { get; set; }

static void Main(string[] args)
{

State = new WebState<string>(ConfigurationManager.AppSettings["SbConnStr"], "BusinessDomain", ConfigurationManager.AppSettings["Node"]);

           State.StateChanged += State_StateChanged;

            Console.WriteLine("I'm node with name: " + ConfigurationManager.AppSettings["Node"]);

Console.WriteLine("Running with state: {0}", State.Value);

           while (true)
            {
                State.Value = Console.ReadLine();
            }
        }

        static void State_StateChanged(object sender, WebStateEventArg<string> e)
        {
            Console.WriteLine("State changed by {0} at value: {1}", e.InstanceName, e.NewValue);
        }

}

As you see this variable is of type WebState, which is implemented by me. When you start this application, enter some text on the console. The text will be immediately persisted in the cloud after following line of code is executed:

State.Value = …

Now stop the application gracefully and start it again. You will notice that application write out the value which was as last one persisted. In fact event with one participant in the system you have achieved the persistence.
The magic behind this is implemented on top of Windows Azure Service Bus queues. Each time the value is changed, the WebState implementation receives the existing message from the queue and put back the new message in the queue which basically holds the serialized value of variable State, and so on. Because access to the queue is session based, Service Bus guaranties that no any other applications which shares this value, will access the queue in the same time. I don’t want to call this distributed transaction, but it behaves in persistence this scenario like it would be one. In fact the WebState class uses the Queue as a unit of storage. By reading and immediate writing back of the new value, it is guarantied that the queue holds one and only one message all the time.
Following picture illustrate this. Each time the value i changed the old value is stored in the queue as a message. The old value is received from queue and the new message with new value is sent to the queue. At the end the old one is completed, because PeekAndLock receive is used.When the new instance of the State is created (for example when application is started) the same cycle with receive/send is done. This is how multiple applications obtain there actual state.

Additionally the implementation of the WebState takes a care about state sharing. For this purpose there is a topic used to share state changes. All participants in this distributed system have to create a subscription on that topic.
In this case (see picture below) the new value is published as a message to the topic. After that all subscribers can receive the message with the new value. The publishing process additionally updates the new value in the persistence queue from previous example.

Because topic-subscriptions are used, the application which was not running for a while, will automatically receive all state changes which have happened in the mean time.

This examples shows how complex patterns can be implemented by using connectivity service in Windows Azure. I know that majority of people out there still think a..bout cloud as an old thing. There is also a group of people who thinks that cloud is unsafe think to keep the data. If you are one them them please rethink your thinking. The scenario and solution shown above is a new way of thinking and using cloud services. And the nice think here is that practically no real data is stored in the cloud.
As you see, the cloud is more than solely putting of some application online. :)

The code for this will be published soon.

Power of Windows Azure PaaS: Service Bus Sequence Counter

2013-04-21T15:40:21Z

If you are distributed application developer you will probably know how often thereby any participant in the system. is a requirement to implement a sequence counter which generates a next number and can be consumed by any participant in the system.
Long time ago as we have been implementing client server architectures, this was relatively easy to achieve by using of Database sequence numbering. In the last decade of services we moved the responsibility of the counter to the service later.
That means we implemented a dedicated service which plays a role of counter generator. As following picture shows two devices consume the Sequence Generator Service.

As long you are in control of the infrastructure and devices this is a valid solution. But what if your system is distributed across a cloud? In this case you can basically do the same way. You can create a service as a worker role (on of possibilities) and provision database (or use table storage) to store the current value of the counter.
However you can do it much simpler and even chipper way if you use Windows Azure Service Bus. Independent on lower costs, Service Bus provides notifications, high performance and even REST access. To demonstrate this I have implemented a prototype API on top of ServiceBus library. Following picture shows how architecture is slightly changed in a case of cloud counter, which I will call WebCounter later in tihs post.

In this case there is no explicite service which you have to build. In fact we will use the cloud as dependency. More precisely we will use for this scenario Windows Azure Service Bus.

The WebCounter Api should hide ServiceBus functionality. This is because not many developers have a good understanding of messaging and bus technology. Moreover hidden details are not necessarily simple in comparison to counter scenario.
My proposed implementation look like:

WebCounter counter = new WebCounter(config parameters);
var val = counter.GetNext();

Optionally you can reset the counter:

counter.ResetValue(7);

This is in term of API more or less all. It looks very trivial and you even don’t need any documentation to start using it. This is exactly the idea of this post, to show how useful scenarios can be built by leveraging of PaaS.

How does it work?

First of all, the WebCounter API have to create the queue, which will be used to hold the counter value. To do that the initialization has to be performed:

public WebCounter(string connStr, string contextName, string counterName)

connStr is Service Bus Connection string like
Endpoint=sb://xyzuvw.servicebus.windows.net/;SharedSecretIssuer=owner;SharedSecretValue=…obfuscated.="

contextName defines the business domain of the counter like ‘MyClinicalDevicesCounter’.

counterName defines the name of sub-context inside of business context like ‘BloothTestCounter’ or ‘RentgenScanCounter’.

Service Bus would see them like: Queue with name “MyClinicalDevicesCounter/BloothTestCounter” and “MyClinicalDevicesCounter/RentgenScanCounter”.

Internally the queue will be created like shown in following snippet:

private void createCounterQueue()
        {
            NamespaceManager namespaceManager = NamespaceManager.CreateFromConnectionString(m_ConnStr);
            QueueDescription desc = new QueueDescription(getQueueName());
            desc.RequiresSession = true;

            try
            {
                var qD = namespaceManager.CreateQueue(desc);
            }
            catch (Microsoft.ServiceBus.Messaging.MessagingEntityAlreadyExistsException)
            {

            }
        }

Notice that the queue is session queue. This means that transitionally one participant can access the queue only. Because the queue will be used to hold the last counter value we are not interested on ordered deliver of the message.
If the queue with the same name already exists, we will simply ignore the exception.

Now, let’s take a look how the counter value is generated. First we create the receiver session. The receiver will either return NULL-message (very first call) ovaluer the counter value.
Then we calculate the next value (0 if this is the first message or Value++). Right after receiving the message we will immediately write the new value in the queue. Because the session receiver is opened while writing the message,
no any other client in the web can start receiving of messages. While receiving is locked the client will write the new value and so on.

Unfortunately, every client in the web will in this scenario have a possibility to send the message to the queue. In this case vendors of such clients would theoretically have a possibility to compromise the system.
As long the queue name is possibly obfuscated, the message encrypted and client on devise safe, this could not be a big issue. Anyhow you should be aware of possible risks, at least.

Here is the code snippet which shows how counting can be implemented.

public long GetNext()
        {
            QueueClient client = QueueClient.CreateFromConnectionString(m_ConnStr, getQueueName(), ReceiveMode.PeekLock);

            while (true)
            {
                MessageSession sessionReceiver = null;

                try
                {
                    sessionReceiver = client.AcceptMessageSession(m_QueueName, TimeSpan.FromSeconds(10));

                    long cnt = 1;

                    var msg = sessionReceiver.Receive(TimeSpan.FromSeconds(10));
                    if (msg != null)
                    {
                        cnt = msg.GetBody<long>();
                        msg.Complete();
                    }
                    else
                    {

                    }

                    cnt++;
                    client.Send(createMessage(cnt));
                    return cnt;
                }
                catch (SessionCannotBeLockedException)
                {

                }
                catch (Exception ex2)
                {
                    throw;
                }
                finally
                {
                    if (sessionReceiver != null)
                        sessionReceiver.Close();
                }
            }
        }

Here is the more illustrated recap of WebCounter implementation:

Welcome to WinDays 2013

2013-04-21T14:06:16Z

I'm very happy that 01. Mai is on the front. This is my favorite Barbie Queue day.
But till than one more public conference only. WinDays is probably after Tech Ed the biggest developer conference in Europe.

Traditionally I will give few talks there. As always I will talk about things which publicly never been covered from perspective I usually do.
I’m ready for new year of more or less new fiscal strategies. This time my focus will be story about Devices and Service in context of cloud.
A good short introduction in upcoming content will be presented in my keynote.
Of course as MVP and VTSP I will focus Windows Azure Cloud and my personal expertise area around Distributed Systems, heavy architectures, Service Bus, Workflow Manager etc.

Here is short summary:

Devices and Service Intro

22.04.: Keynote
To be covered very common and useful scenarios for devices in the cloud. What can you do with Service Bus and why is Service Bus one of core PaaS components of Windows Azure.

How to build Services for Devices
24.04: Distributed Applications for Windows, Cloud & SharePoint (400)
srijeda15:05 - 15:50Coral 5

Runtime for Devices

24.04: Runtime 8 Fight-Club
srijeda18:20 - 19:05Coral 5

Deployment of AppxPackage failed

2013-04-19T20:52:00Z

When trying to deploy sideloaded apppackage you might get following error:

add-appxpackage : Deployment failed with HRESULT: 0x800B0109, A certificate chain processed, but terminated in a root
certificate which is not trusted by the trust provider. (Exception from HRESULT: 0x800B0109)
error 0x800B0109: The root certificate of the signature in the app package must be trusted.
NOTE: For additional information, look for [ActivityId] … in the Event Log or use
the command line Get-AppxLog -ActivityID …

If the certificate is properly set in you certificate hive (Current User) it will pass the signature test procedure for Authenticode. However it can happen that deployment process of the package with valid signature fails.
This sounds a strange, but testing signature validates that the signature (certificate) is digitally valid. If you want to deploy the signed packed the machine itself must trust this certificate. I do not want to speculate now about
theoretical and practical meaning of this. It is a fact and it gives us a bit more security sugar on top.

The solution for this is to define the certificate trust in (Local Computer) hive. To do this open certificates in MMC and move (install) the certificate in one of following two nodes:

- Trusted Root Certificates
- Trusted People

How to create a package: http://msdn.microsoft.com/en-us/library/windows/apps/hh975357.aspx
How to share the package: http://technet.microsoft.com/en-us/library/hh852635.aspx#SideloadingRequirements

How to add the user to Windows Azure Sql Server?

2013-04-16T19:09:00Z

When working with SQL Server in Windows Azure you can create very quickly the database. But if you have a big distributed team usually you will not want to give everybody the access to DB.
Unfortunately right now, there is no way to manage users in Management Portal or event to do that within SQL Management studio. At least not by using common UI. This post describes stepp by step how to create the user
by using T-SQL within SQL Management Studio.

Start SQM Management studio and connect with the admin user, which you will usually use in SQL Management Portal.
Once you are connected to your Windows Azure Database, select the master database, right mouse click and select new query.

This will open the new query wit connection to master database. Note that you have to open the SQL editor with master database!
Then type following in the query in the editor:

CREATE LOGIN yourusername WITH password=’YourPwd123‘;

This will create the new LOGIN in the master database.

Now execute following statement in the same editor:

CREATE USER yourusername FROM LOGIN yourusername ;
This statement will create the user from specified login in the master database.

After that we need the to select wanted database (as in previous step, but this time you will not select master database) and open the query window.
In that window enter same script as in previous step:

CREATE USER yourusername FROM LOGIN yourusername ;

This statement will create the user from specified login in your database.

At the end we need to append some roles to the user. They can be enlisted as follows:

For example if you want to add it in the role of owners do following:

EXEC sp_addrolemember 'db_owner', yourusername ;

Now you can use use DB in the cloud. I know that last few steps are not very common task of every developer. I have tried to keep them simple. T-SQL can look much worse, believe me.
An alternative to these steps was to setup completely new infrastructure which will publicly provide secure access to database. My steps have taken about 20 mins to provision and migrate one DB in the cloud.
To do all that On-Prem will take much, much more time.

Integration Styles – University of Applied Sciences Frankfurt am Main

2013-04-13T08:14:33Z

Announcing Agenda for April 15. 2013. The focus of the session will be “Introduction in Integration Styles”.