Another developer session that was packed from the beginning focused on the changes to the workflow functionality in SharePoint 2013. First when thinking about workflow in SharePoint you need to look at separate focused areas on how People, Content and App Business logic interact with the workflow.
Before we get into the plumbing of how workflow in SharePoint is different we must first talk about the main workflow designing tool SharePoint Designer. Most of the revolved around what you can now do in SPD which you could only do before in Visual Studio. Now 2013 workflows are stage centric and have specific transition sections which enable you to specify, based on conditions which stage you want to be processed next (Think GO TO “Stage Name”). Other new built in actions are looping, calling external HTTP web services and much more. The last neat item that was shown was a Design View which takes some of the power that you could do in Visio, and transitions it to SPD, where you can drag and drop actions and conditions on a design surface, bind them to your SharePoint connections and away you go.
Now for the architecture, first off it’s completely different than the way 2007 or 2010 workflows were processed. There is the new connection required to run these 2013 workflows called the Workflow Service Manager. This component is not directly shipped with the install of 2013 so it will need to be setup separately once your new farm is up and running. The nice part about this workflow manager is it ties into the new vision of SharePoint Apps which run all work outside of the SharePoint processes. This will have larger architecture considerations as you now also need to prepare if you want this workflow manager on a separate set of machines and connected through the workflow client which will need to be installed on your SharePoint servers to manage the communication and messaging.
Nice this workflow manager is treated as an “off box” service, all connectivity between SharePoint and the workflow manager is secured using OAuth and communicating using the REST endpoints available in 2013. By knowing this all authorization for your new 2013 workflows are treated just like SharePoint App authorization. This is important to note because of a new SPD step type called App Step which replaces the 2010 version of impersonation step. in 2010 the impersonation step acted on behalf of the last user how published the workflow but was using the service account to do the impersonation, now in 2013 the workflow app processes the impersonation and its rights are limited to only the areas that it needs access. When using this new App Step you will now start to see that a workflow will be noted as the creator or editor of items in SharePoint.
There are two main configuration models to follow to enable the 2013 workflow functionality: Collocated and Federated. Collocated is installing the workflow manager bits (and workflow manager client) directly on your SharePoint servers. The federated model is setting up separate servers and installing the workflow manager on those machines and only installing the workflow manager client on the SharePoint machines to enable the communication and messaging. Once the installation of the bits are completed (done via the Web Platform Installer) and the workflow cluster / farm is setup SharePoint needs to know how to communicate to the workflow environment, this is done by registering a workflow service application proxy and registering the workflow service through PowerShell. It is important to note that you can setup these connections using HTTP, but should ONLY be done in a development environment since OAuth tokens will be flying around for authorization.
Latest posts by Avtex (see all)
- CRM Success: Top Impacts to the Success of CRM Implementations - January 18, 2017
- Top 6 Things to Consider When Making the Transition to Microsoft Office 365 - January 18, 2017
- Exploring Journey Mapping and Its Role in Customer Experience - January 18, 2017