(News) Workflow 1.0 Beta


Dropping the stealth cloak a little, it’s time for some personal news about what I’ve been up to for the last year and a bit. And the answer is? Testing what we are calling in our docs “Workflow 1.0 Beta” (name may change) which is Microsoft’s new Workflow hosting offering that works with WF. Here’s a few quick facts about this piece of software.

What is this?

“Workflow 1.0 Beta” is a separate piece of software being released alongside the Office 2013 Beta, but also a requirement for enabling some of Office’s Sharepoint Workflow features.

It is a ‘server’ application which stores, loads and executes declarative XAML workflow definitions, the same as WF4 XAML authored custom activities.

“Workflow 1.0 Beta” is also an Azure platform service running in the cloud, which will enable you to host long-running workflow in the cloud without requiring VM role subscriptions.

See also the longer, official answer.

Does it cost anything?

Currently nothing at all – it’s a free beta, and for the server product, it is also a separate install from Office. Disclaimer: pricing plans may change for future releases.

What are the supported platforms, prerequisites, and system requirements required to install the server product?

The answers are linked in the line above.

How is this different to hosting my own WF4 service using existing hosting technologies?

There are many differences.

One difference is that workflows now get hosted/installed on the server by publishing workflows to the server via REST-style HTTP calls. Of course there is also a user-friendly managed API for publishing workflows that wraps the HTTP if you’d rather just write simple code. As this is a multi-tenant workflow offering, you can also create multiple tenancies, and your own customers can use this same client API to upload their workflow definitions to their tenancy on your central server.

Another difference that will feel very different to existing WF4 customers is that workflows run in a sandboxed mode which disallows any potentially dangerous types and activities, sort of like running in partial trust, or as a restricted user.

This may feel like a severe limitation given how used we are to creating custom code activities. However, if you are running “Workflow 1.0 Beta” as an on-premise server, there are ways you can configure “Workflow 1.0 Beta” to allow your own custom code activities which I’ll hopefully get to posting some time soon, assuming people are interested!

 

Where can I get more information?

It’s all starting here! Workflow 1.0 Beta

http://msdn.microsoft.com/en-us/library/jj193528(v=azure.10

Further questions are welcome in the comments section!

Comments (6)

  1. Stephen Hardie says:

    Sounds very interesting. Will there be a Management UI for this as well?

  2. tilovell says:

    @Stephen you will definitely want to check out the Samples section!

    technet.microsoft.com/…/jj193482.aspx

    There are two related samples, the "Workflow Resource Browser" and the "Workflow Editor" samples, which can be used for high level tenant management or lower level activity editing and publishing.

  3. The left nav for technet appears to still be updating, but you can view this same content on MSDN here:

    msdn.microsoft.com/…/jj193528(v=azure.10)

    This is the same content, but the table of contents in the left nav is up to date and you can use that to help navigate the documentation.

  4. tilovell says:

    Thanks Steve, I'll update the links.

  5. Mike Nooney says:

    Does a Tenancy = a workflow Scope? It would also be interesting to hear more about how code activities can be enabled on premise.

  6. tilovell says:

    Hi Mike, yes, a workflow Scope is the way multi-tenancy concept is exposed in the API.