On February 28, 2013, Microsoft® published a video titled Overview of Workflow in SharePoint Server 2013. The presumed audience appears to be SharePoint administrators, developers, SQL Server administrators, developers, and network services developers.
This presentation will likely leave the viewer with a clear impression of a planned separate product path for the new Workflow Manager available for SharePoint 2013. As the narrator explains, ” . . . SharePoint 2013 is merely the first customer for Workflow Manager. There will be others.” (quoted from this video, a link is provided in this post to the entire video” Workflow Manager must be downloaded separately and ” . . . scales separately . . . ” (ibid) from SharePoint. It has its own content and configuration data, which is stored in a separate SQL Server database.
A third application has been built to work with SharePoint 2013 and Workflow Manager, a component called Service Bus, which, in turn we are told, has its own configuration data, stored in yet another SQL Server database. The method of communication between SharePoint 2013 and Workflow Manager runs over TCP/IP, “named pipes” (ibid).
But the same Workflow Engine included with SharePoint Server 2010 (automatically installed at the same time the server is implemented) is also included with SharePoint Server 2013. The narrator assures the audience workflows built with SharePoint Server 2010 will run fine with SharePoint Server 2013. They can be edited with SharePoint Designer 2013 as long as the workflow type is set to “SharePoint 2010 Workflow”. The narrator notes the option for “SharePoint 2013 Workflow” will not show up in SharePoint Designer 2013 if the Workflow Manager has not been separately installed.
The narrator acknowledges the possibility of confusion as users consider why two different workflow platforms were offered with SharePoint 2013. The answer, he explains, is important. In fact, Workflow Manager was built for Cloud characterized by “high density, multi-tenant environments” (ibid). We think this makes a lot of sense.
But users planning how to plan new workflows may want to stick with SharePoint Server 2010’s Workflow Engine as the supporting system. The narrator cautions the fact Workflow Manager is a separate application ” . . . is great for scalability, but the new platform lacks the deep integration with the SharePoint Object Model which was provided when workflow was baked right into SharePoint.
© Rehmani Consulting, Inc. & Ira Michael Blonder, 2013 All Rights Reserved