Sharing a Workflow Manager 1.0 farm between multiple SharePoint 2013 farms

Tags: SharePoint 2013, Workflow Manager

SharePoint 2013 introduces a whole set of new and improved features. One of the things that is both new and vastly improved is the Workflow platform. Workflow is no longer a part of the SharePoint core infrastructure, but instead a separate server product. Even though ye olde Workflow platform, 2010 style, is still in the product for backwards compatibility. SharePoint 2013 leverages the Azure service called Workflow Manager 1.0. (Not the cloud version but a local on-premises installation).

The Workflow Manager 1.0 server application should be installed on a separate set of servers – not on the SharePoint servers (remember; just because you can doesn’t mean you should). This introduces for some organizations more investments in physical and virtual hardware. So, what happens if you have several farms? Do you need several Workflow farms? That can be expensive! Well, as always in the SharePoint world - It depends! If you come to the conclusion that you could use the same Workflow Farm and hardware for managing all your SharePoint Farms workflows then you can actually use the same Workflow Manager 1.0 farm. Usual disclaimers apply here – it’s all up to you and your organization to decide upon designing your workflow infrastructure for this scenario, remember this can make backup/restore and DR a bit problematic since now your farms are sharing the same workflow databases etc.

Let me show you a multi-tenant Workflow farm, how it works and how you do to set it up properly…

Workflow Service

Multi-tenancy in Workflow Manager 1.0

Azure Workflow Manager 1.0 is multi-tenant aware through Scopes. “A scope is a named and securable container for Activities, Workflows, Instances, configuration and child Scopes.” – that is directly stolen from the Workflow Manager documentation. Everything that runs inside Workflow manager belongs to a Scope. By default a Root Scope is created when you set up the Workflow Manager farm. You can see details about the Root Scope by navigating to the HTTP/HTTPS port of your farm. The URL should look something like this: http://wffarm.corp.local:12291 for HTTP and https://wffarm.corp.local:12290 for HTTPS.

Workflow Manager Root Scope

Connecting SharePoint 2013 to the Workflow Manager 1.0 farm

I’m not going to dive in to how to configure the Workflow Manager farm; it’s a wizard or PowerShell thingie and it’s very well documented – you can’t fail! Once you have the Workflow farm up and running you MUST install the Workflow Client 1.0 components on all the Web Server in your SharePoint 2013 farm (you can get the bits using the Web Platform Installer).

All you have to do then is to register the Workflow Manager 1.0 farm with the SharePoint 2013 farm using the Register-SPWorkflowService cmdlet. This will register the SharePoint 2013 farm with the Workflow Manager and vice versa and it will also create the Workflow Service Application Proxy in SharePoint.

You execute the cmdlet like below and pass in a URL to a site in your SharePoint 2013 farm (any site will do) and the URL to your Workflow Manager farm (if you’re using HTTP you also need to add the AllowOAuthHttp parameter).

Register-SPWorkflowService 
    -SPSite https://teams.corp.local 
    -WorkflowHostUri https://wffarm.corp.local:12290

Not only will this cmdlet do the things mentioned above, it will also create a new Scope in the Workflow Manager farm (under the Root Scope) called SharePoint. You can verify this by navigating to Workflow Manager URL and append /SharePoint, like this: https://wffarm.corp.local:12290/SharePoint. In the XML returned you can see the URL to the SharePoint 2013 metadata endpoint (https://teams.corp.local/_layouts/15/metadata/json/1) under the SecurityConfigurations element. Now, that was one SharePoint 2013 farm connected to the Workflow Manager farm.

So, let’s jump on over to our second SharePoint 2013 farm, that we now decided should use the same Workflow farm! If we run the same cmdlet in that farm (using a different SPSite parameter URL of course) we get a nice error that says “An existing scope named “SharePoint” already exists in the workflow server”.

An existing scope named 'SharePoint' already exists in the workflow server

You see, this scope is already taken by some other farm (the one we previously connected)! The clever one might think that oh, I’ll just use the Force parameter of that cmdlet and override this. Well, if you’re that smart then you will hijack that Scope from the other farm. The Scope will be recreated and the other farm will have a non-functional Workflow Service (the security configuration will now point to the SharePoint farm that hijacked the Scope).

Note: the Force flag might be useful if you really want to re-create the Workflow connection using the same Scope name.

Instead you should use the ScopeName parameter of the Register-SPWorkflowService cmdlet. That parameter will create a new Scope in the Workflow farm, and with that create an isolated container for this new SharePoint farm. So on our second farm we run this PowerShell cmdlet:

Register-SPWorkflowService 
    -SPSite https://farmb.corp.local 
    -WorkflowHostUri https://wffarm.corp.local:12290
    -ScopeName FarmB

Once this command is issued your Workflow Manager farm will have two child Scopes under the Root Scope; SharePoint (the first farm we connected) and FarmB (the second one with the ScopeName parameter). You can verify the second scope by browsing the the Workflow farm and append the Scope name to the URL, like this: https://wffarm.corp.local:12290/FarmB.

Now you have two SharePoint 2013 farms using the same Workflow Manger 1.0 farm, and each SharePoint farms workflows are isolated using the Scopes in Workflow Manager. Cool!

Summary

I’ve just shown you how easy it actually is to share a Workflow Manager 1.0 farm between several instances of SharePoint 2013 farms. Now it’s up to you to decide on weather this is an appropriate way for your organization to build your infrastructure or not. Remember to plan your resources and your DR strategy!

No Comments

  • Craig said

    Hi,
    Just wondering if you see any issue with hosting Workflow Manager and Office Web Apps 2013 on the same server?

    Thanks

  • Ravi said

    Hi,
    I have got the idea ho to setup the workflow manager. One thing I want to know is that by using workflow manager can I create a workflow which will continue functioning across sites? My requirement is that we need to develop a workflow which will copy the document from one site in one web app to another web app step by step.

    Your suggestions will really help me to work on it. Thanks in Advance.

  • Tarcisio said

    Hi Wictor!

    Thanks for your good tips :D

    I just have one question - when you talk about to not deploy Workflow Manager together with SharePoint Server - is it a limitation or recommendation?
    I'm asking about because it's not the first time I'm in trouble when deploying WFManager on SharePoint Servers - a lot of toubleshooting required (token errors, auth errors, time-out errors, certificate errors, etc). And it didn't happened (at least to me) when used dedicated servers for WFManager...
    As I can understand, for Microsoft it's a possibility:

    http://technet.microsoft.com/en-us/library/jj658588.aspx#section4

    "... Workflow Manager is installed on a server that is part of the SharePoint 2013 farm. Communication takes place by using HTTP."

    And now?
    Thanks for your time!

  • George Chiu said

    I just tried to use the -ScopeName parameter with Register-SpWorkflowService cmdlet for the 2nd SharePoint farm and got the error "An scope named "SharePoint" has already been registered". My 2nd SharePoint 2013 farm is with Dec. 2013 CU.

  • George Chiu said

    Update: -Force parameter needs to be specified along with -ScopeName. Reference: http://msdn.microsoft.com/en-us/library/office/dn411563(v=office.15).aspx

  • Wictor said

    @George: The default scope name is called "SharePoint" (that is if you run it w/o the ScopeName parameter). So if you need to run with Force you are already having that scope in use.

Comments have been disabled for this content.

AWS Tracker

About Wictor...

Wictor Wilén is a Director and SharePoint Architect working at Connecta AB. Wictor has achieved the Microsoft Certified Architect (MCA) - SharePoint 2010, Microsoft Certified Solutions Master (MCSM) - SharePoint  and Microsoft Certified Master (MCM) - SharePoint 2010 certifications. He has also been awarded Microsoft Most Valuable Professional (MVP) for four consecutive years.

And a word from our sponsors...

SharePoint 2010 Web Parts in Action