Defensive Workflow Design Part 2 - SharePoint Topology

Blog Post created by aaron.labiosa@nintex.com Champion on Dec 1, 2014

Applicable to Versions of Nintex Workflow (Nintex Workflow 2013) and (Nintex Workflow 2010) and earlier.




Nintex Workflow solutions are deployed to SharePoint as Web Application scoped Solutions (Nintex Live being an exception). Nintex Workflow also makes use of the GAC (Global Assembly Cache) for its assemblies. When Nintex Solutions are deployed to the farm, only Web Application Servers install a copy of the Nintex Workflow assemblies into their GAC.


Every server that is running the Workflow Timer Service (Microsoft SharePoint Foundation Workflow Timer Service) is going to be in a pool of servers that can/will process Sharepoint and Nintex Workflows. SharePoint uses a round robin system to determine which server will process a given workflow instance. There is no feasible way to limit/reconfigure this functionality other than to turn the Workflow Timer Service off on a given server.


It is required that each server that is configured to run workflows (Microsoft SharePoint Foundation Workflow Timer Service) also be configured as a Web Application (Microsoft SharePoint Foundation Web Application Service) server. So that each workflow has access to Nintex Assemblies when needed.




Licensing Considerations

In Nintex Workflow 2013, the only Servers that need to be licensed are servers that will render the Nintex Workflow Designer (Typically servers that are in a load balanced pool):




In Nintex Workflow 2010, each server in the farm running the Workflow Timer Service needs to at least be licensed as an Application Server (No additional cost). Each Server that will render the Nintex Workflow Designer need to be licensed as a Front End Server.


More Information


Defensive Workflow Design Part 1 - Workflow History Lists

Defensive Workflow Design Part 3 - Separation of Concerns

Defensive Workflow Design Part 4 - Slow Down and Speed Up

Defensive Workflow Design Part 5 - Batching