Usually when you see product go from a beta (or in the case for the workflow tooling, Preview 2) to RTM or from RTM to one of the first updates (as in the case for Workflow and SharePoint’s cumulative updates) you usually don’t see much in the way of new features or big changes. To me it usually means you get performance tweaks, bug fixes and a lot of fit & finish. However as someone who spent a lot of time with workflow in the pre RTM days, I’m very happy with the changes and improvements to the tooling and platform with these three big updates:
- Workflow Manager February 2013 Cumulative Update
- SharePoint 2013 March 2013 Public Update
- Visual Studio 2012 SharePoint & Office 2013 Developer Tools RTM
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.
Let me go through a few of the updates that are important and made an impact on me.
Deployment Process
Prior to the SharePoint 2013 March PU, workflows were deployed to SharePoint using the WSP model. Workflows could be included both in solution packages (WSP’s) and in apps. Within apps they were still deployed in WSPs which are included within apps.
However in the SharePoint 2013 March PU, workflows are now given their own deployment model (called deployment groups within the extensibility model). You’ll notice this pretty quick when you go to create your first one using the RTM tools as you won’t see an elements.xml file within the workflow SharePoint Project Item (SPI).
There’s a little trick to this though. You might find yourself getting this nasty and incredibly annoying error when you try to test your workflow from Visual Studio 2012 if you’re including it within an app. The deployment error happens when Visual Studio tries to install the app. It fails with the message “There is no Workflow App Part registered”. The problem is that SharePoint doesn’t have the deployment group for the workflow registered.
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.
What you need to do is run a method on the Workflow Service Manager service application proxy and then you can deploy your workflows using an app. Use the following PowerShell to register the deployment group:
$WmsSap = Get-SPWorkflowServiceApplicationProxy
$WmsSap.RegisterWorkflowLifecycleManagementEnvironment()
Note: You need to do this in production… this isn’t just a development machine thing.
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.
No More Warnings in Activities
I got so many questions before the RTM of the developer tools about all the warnings you’d see in the designer but you could seemingly ignore them. No more… what the team did was change the workflow activity assembly references in the workflow source (XAML) to point to a new design-time proxy assembly instead of the actual SharePoint activities.
List & List Item Related Activity Improvements
If you didn’t do anything with workflow in the early developer tools… anything before the RTM tools… skip this section and move to the next section. Why? In the pre-RTM tools you frequently had to grab the IDs of the list and item that kicked off the workflow. Check out these new options in some popular activities… woot!!!
Workflow Forms
Another tremendous improvement is in the area of forms (although I have found two little documentation bugs in the templates). Let me first explain how this worked in pre-RTM tools.
Pre-RTM Workflow Developer Tools
In pre-RTM tools you only had a single template for an initiation form. It worked just fine. This template would only show up when you right-clicked the SPI that contained the workflow and selected Add » New Item because the Add New Item wizard knew the context was workflow so it showed workflow specific templates among others (the same is true in the RTM tools when adding an association form). This new form would be placed within the workflow SPI in your Visual Studio project. This meant the form would be placed in some super-secret document library that stored the workflow as well.
After adding the form you would find a comment that would tell you that you needed to modify the workflow’s element manifest file (element.xml) in order to let the workflow know there was an initiation form and the URL where it is located.
RTM Workflow Developer Tools
So how have things changed? First, the easy one… while we could create association forms in pre-RTM tools, it was a manual process and we had to write a lot of JavaScript because there was no template. However in the RTM tools we now have an association form project item template! This includes all the JavaScript that’s needed to create the task & history list if specified for the new association. You just need to add in the extra arguments as form fields, tweak the UI accordingly, and update the JavaScript to include the form values. I’ve got another post I’m working on for creating forms, including association forms.
Second, one of the challenges was collecting the form variables that were sent via a HTTP POST from the first step in creating a workflow association (the name, the template selected, if a task & history list was to be created or reused, how it starts, etc.). Because we’re limited to client-side script, we couldn’t get these values from an HTTP POST. In the latest tools the association form template includes a SharePoint server control that collects these values for you and writes them to the page as hidden form fields.
Third, with the change to the way how workflows are deployed to SharePoint when included in Apps (see deployment groups in the “Deployment Process” section above), we no longer have an element manifest file in a workflow SPI. Therefore, when you add a form to the workflow (initiation or association), the ASPX pages are placed in the Pages Module SPI within your app project. The way you associate these pages to the workflow is by selecting the workflow SPI and modifying the properties using the properties window, as shown below.
What’s a little strange is both the association and initiation form templates still include the ASP.NET comment telling you to uncomment the properties in the workflow element manifest file to point to the correct form URL. This isn’t necessary because (1) the Add New Item wizard updates the properties on the workflow SPI with the values and (2) there is no such thing as an element manifest file with the workflow SPI (see deployment groups in the “Deployment Process” section above).
April 4, 2013 10:30 AM
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 5:15 PM
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.