How To Identify Complexity of SharePoint 2013 or 2010 Workflow to fix errors while compilation

Senthil Kumaresan
 
SharePoint Consultant
January 20, 2014
 
Rate this article
 
Views
25916

SharePoint Declarative Workflows have certain limitations that are not well known to many people . Try this Poweshell script to identify the complexity of a SharePoint 2013 or SharePoint 2010 declarative workflow to fix the compilation error due to complexity of WorkFlow.

Too complex workflow does not compile and hence cannot be deployed. The complexity limit for a workflow is defined in SharePoint using a Web Application level numeric property called UserDefinedWorkflowMaximumComplexity and the Default value of the property is 7000 which is the maximum allowed limit for a single workflow to successfully run. This can be adjusted by the farm administrator by updating the property with PowerShell. And there is a ceiling limit of a workflow size which is 10000 restricted by the .Net Workflow Foundation compiler. If you develop a too complex workflow and try to compile it in SharePoint Designer then you might get the below error if your workflow exceeds the complexity limit

“Errors were found when compiling the workflow. The workflow files were saved but cannot be run. Unexpected error on server associating the workflow”

To know more about this, please check out the KB article 2557533

To fix the error you will have to redesign and break them into multiple workflows to achieve the business functionality.

How can I find the complexity of my workflow?

The complexity is based on the No. of Start Nodes plus the No. of ActivityBind Attributes found in the .XOML file of the workflow.

I have developed a Simple powershell script below which would count the no. of start nodes and the no. of ActivityBind Attributes from the .XOML file of the workflow.

Save the below script as Powershell file

 param(
     [string]$xomlfile = ""
 )
 $reader = [system.Xml.XmlReader]::Create($xomlfile)
 	[int]$nodecount = 0
 	if ($reader.MoveToContent() -eq "Element")
 	{
 		if ($reader.MoveToAttribute("x:Name"))
 		{
 			$wfclassname = $reader.Value
 			$reader.MoveToElement()
 		}
 	}
 
 	[System.Xml.XmlReader] $activityreader = $reader.ReadSubtree()
 
 	while ($activityreader.Read())
 	{
 		if ($activityreader.NodeType -eq "Element" -and $activityreader.IsStartElement())
 		{
 			$nodecount++
 			for ($i = 0; $i -lt$activityreader.AttributeCount; $i++)
 			{
 				$activityreader.MoveToAttribute($i)
 				if ($activityreader.NodeType -eq "Attribute" -and $activityreader.Value.ToUpperInvariant().Contains("ACTIVITYBIND"))
 				{
 					$nodecount++
 				}
 			}
 		}
 	}
 $nodecount
 

Run the Above Script by providing the .XOML file of your workflow for the xomlfile parameter

Ex.

.\GetSingleWFComplexity.ps1 –xomlfile c:\docsworkflow.xoml

The output would be numeric value which is the actual complexity of the workflow that you have developed.

If you had exceeded the pre-defined limits set by the farm administrator then you might try breaking the logic of the workflow into multiple workflows.

Category : SharePoint, Workflows

Author Info

Senthil Kumaresan
 
SharePoint Consultant
 
Rate this article
 
SharePoint Architect – Consulting on SharePoint Infrastructure, IT Governance and Apps Development. ...read more
 

Leave a comment