Over the last two months we’ve seen a LOT of updates and improvements to workflow development for SharePoint 2013. Recently Grace Kochavi from the SharePoint workflow team published a post on the Apps for Office & SharePoint Blog that talks about a bunch of the updates and then walks you through creating a workflow (SharePoint Workflow Development with Office Developer Tools for Visual Studio 2012). I don’t want to rehash what Grace said, but I do want to add a few things I ran into (including one big show stopper that isn’t in the current documentation that you MUST do in order to publish workflows within apps).
There are two things you need to do. You first need to update your platform which includes Service Bus, Workflow Manager and SharePoint 2013, then you need run an extra PowerShell statement script and finally you need to update your developer tools.
Update Your Platform
There are quite a few things you need to do here. You’re ultimately trying to update workflow within SharePoint 2013 which means updating the Workflow Manager 1.0 product and it’s dependencies.
Update the SharePoint Dependencies
Because workflow is handled by Workflow Manager 1.0 which is dependent on Service Bus 1.0, you need to install the two February CU’s for both Service Bus 1.0 & Workflow Manager 1.0:
- February 2013 Cumulative Update for Service Bus 1.0: KB2799752
- February 2013 Cumulative Update for Workflow Manager 1.0: KB2799754
Two words of warning when you install Workflow Manager 1.0.
- Ensure you are logged in as the same admin account you used to install Workflow Manager 1.0 the first time (I set the service account for WM as a local admin on the box so I was logged in as that).
- When you run the CU installer, for me and many others, you’ll see the installer seem to go away and appear complete. This isn’t the case… it is still working in the background, but it isn’t showing anything on the screen. Be patient and wait… after a few minutes (roughly 2-5 minutes for me) it will come back and say it succeeded.
To verify the installs completed correctly, you can check the file versions for both products.
- For Service Bus, look in
C:\Program Files\Service Bus\1.0for the
Microsoft.Cloud.ServiceBus.dll. This should be version 2.0.30207.2.
- For Workflow Manager, look in
C:\Program Files\Workflow Manager\1.0\Workflow\Artifactsfor the
Microsoft.Workflow.Service.dll(*not* the EXE). This is the DLL that runs the workflow backend service. It should be version 1.0.30207.2.
- Or you can look in the Add Remove Programs app, select View Installed Updates and find both Service Bus 1.0 & Workflow Manager 1.0:
Update SharePoint 2013 with the March 2013 Public Update
With the dependencies updated, the next thing you need to do is update SharePoint 2013. The update you need is the SharePoint 2013 March 2013 PU (PU vs. CU?). Both Todd Klindt and Wictor Wilen do a good job with guidance here (take note of the search and WAC stuff they talk about).
March 2013 Public Update for SharePoint 2013
SharePoint Foundation 2013: KB2768000
SharePoint Server 2013: KB2767999
Note you only need the server PU if you have server… it includes everything the SPF one has.
After applying the updates, you should rerun the workflow pairing PowerShell cmdlet (
Register-SPWorkflowService) with the
-Force flag set. This will do two things: it will add a new deployment group and also republish the updated SharePoint activities (updated in the March 2013 Public Update) to the Workflow Manager farm.
Special Note about Workflow Changes in the SharePoint 2013 March 2013 Public Update
The way workflows are deployed within apps has changed from SharePoint 2013 RTM to how they are deployed after this Public Update. In SharePoint 2013 RTM When a workflow was deployed in a SharePoint app, they were deployed using WSP’s. In the SharePoint 2013 March 2013 Public pdate they are now deployed using this thing called a deployment group (I’m sparing you the details, but it’s an internal thing to the app deployment that’s new in SharePoint 2013). The challenge is that this deployment group doesn’t exist after installing all the PU… it’s something you need to create.
The omission of this step is likely an oversight on the SharePoint 2013 March PU installation script or instructions. I’ve spoken to the product team who confirmed this needs to be done and will update the instructions accordingly.
If you don’t have this deployment group, you will get an error when you try to deploy an app that includes a workflow… specifically “There is no Workflow App Part registered”. This happens both in production as well as in development. You don’t get this error if you include the workflow in a farm or sandbox solution.
In order to create the deployment group you need to call
RegisterWorkflowLifecycleManagementEnvironment() on the Workflow Manager Service service app proxy in order to register a new Workflow Deployment Group provider that knows how to unpack & deploy workflows included in an app. So from a SharePoint Management Shell, run this script:
$WmsSap = Get-SPWorkflowServiceApplicationProxy $WmsSap.RegisterWorkflowLifecycleManagementEnvironment()
Note this is not necessary if you rerun the pairing PowerShell cmdlet like I state above as this is one of the things the pairing command does for you.
Update Your Developer Tools
Last but not least, make sure you update your SharePoint 2013 developer tools to the RTM tools! There are a ton of changes in the workflow development pieces in these tools, something I discuss more in this post.
You can install these RTM tools directly over the Preview 2 from the Web Platform Installer, or using this shortcut link: http://aka.ms/OfficeDevToolsForVS2012
Note that any workflows you created using the Preview 2 tools will need to be updated as there were quite a few changes & improvements to activities as well as the deployment and packaging process within apps. I discuss some of those things in this post. To make things easier, the workflow team provides a tool available through CodePlex that will help in updating your projects:
April 4, 2013
Fixed two typos from the original post: (1) PowerShell script referred to “Get-SPWorkflowApplicationProxy” when it should be “Get-SPWOrkflowServiceApplicationProxy” and (2) changed “Product Update” to “Public Update”
June 12, 2013
I added some extra notes about running the pairing PowerShell cmdlet after installing all the updates. Previously the post only mentioned the PowerShell cmdlet to add the new workflow deployment group. However you should run the pairing command instead. The reason for this is so the activities updated in the March 2013 Public Update are republished to the Workflow Manager farm.comments powered by Disqus