Lately I was working on Microsoft Cloud Workflow services, and with some good new things you always get some limitations too…

At present the Cloud workflow comes with some basic activities and using then we can create some workflows, call Service Bus, make Http Requests., control access to them, and define some rules and some more…..

And yes you will get good scaling, management without investing into hardware, you also get a portal for management of workflow instances and if you don’t want to go to portal always you can always use the workflow API to manage them.

But some features I didn’t like…

·         Unlike a typical workflow whose instance is created when ever a request comes, in .NET workflow service we have to do some sequence of steps before making a call…surprised, YES?

o    Create an instance of workflow either through portal or using API

o    Explicitly start it.. and now off course you can call it. But here is one more trick. When you create an instance you get an instance Id, and the url to which you have to send a request depends on several things and one of them is the instance id.

o    So for you the Request url is always dynamic as it depends on workflow instance id which is a GUID.

o    The Request URL looks like this

http://workflow.windows.net/workflowsHttp/<UserName>/workflows/<WorkflowTypeName>/instances/<InstanceId>/<ActivityName>

·         The activities which are presently there are fairly limited.

·         And if you are using CloudXPathRead and CloudXPathUpdate activities in your workflow make sure that the request you pass them should have correct type i.e “"text/xml"” otherwise the data will be Binary in WF and your WF will crash.

·         One more feature which I would love to see is to have a local deployment server, so that we can debug these, unlike at present we have to always deploy them in the cloud and we cannot debug themL.

·         And the last thing which is really important if you are planning to call cloud workflow from your Azure applications. You cannot create workflow instance and start them as the assembly which has these API cannot be called from Partial trust, and your Azure applications always run under that .. a big hindrance which Microsoft should really look into.