How to add new properties to the workflow service configuration

February 5, 2015

While investigating an issue I encountered when running a SharePoint 2013 workflow, see blog post for details, some of the suggested fixes I found suggested adding a new property into the workflow configuration settings.

I had a look at the MSDN article on how to do this but when looking at the steps it seems to indicate you could only set existing values not add new ones, see figure 1 for a snippet from the MSDN article

 “For Name, specify a name of the configuration setting (See below for the list of valid settings.)”.

Figure 1

I had a look around on how to add new settings but I wasn’t able to find anything except from people adding rows directly into the “WorkflowServiceConfig” table in the “WFResourceManagementDB” database. Anyone who has used SharePoint knows that it is generally not supported to touch any SharePoint database without putting them into an unsupported state.

As it turns out I was able to resolve my issue by updating an existing property so I didn’t need to do this in the end. After I had worked out what property I needed to update, which I had done via the PowerShell command supplied in the MSDN article, I thought it would be a good idea to create a wrapper PowerShell function in a common PowerShell file I have. I have several helper methods in this common PowerShell file and I use it to avoid having to remember specific PowerShell commands.

I started to implement this helper function and was adding some error handling to see what would happen when a property name was supplied that didn’t exist. I ran the helper method with an invalid name and it completed without any errors. I was expecting some kind of error message so I was slightly confused at this. I changed the name and debugged through the PowerShell, I use PowerGUI when writing scripts and it has this feature. When the script got to call the “Set-WFServiceConfiguration” function it completed with no errors.

I opened up the workflow table where the settings are stored and to my surprise the two test values I had tried were in the table.

I thought it was a bit strange that Microsoft would allow you to update properties but not add them, however the wording on the MSDN article does clearly suggest the name has to be one of the existing values. Added to this all the articles I found people were directly adding rows into the database table.

I have included the function I wrote below, see figure 2, in case anyone finds it useful but as always with PowerShell always try this in an non-production environment first.

Function to add property
function Set-SP2013WorkflowSetting{
   [cmdletbinding()]
   Param(    
    [parameter(Mandatory=$true)][string]$workflowManagerURL,
    [parameter(Mandatory=$true)][string]$propertyName,    
    [parameter(Mandatory=$true)][string]$propertyValue)    
    
    Write-Host "Starting to update workflow manager property $propertyName" -ForegroundColor Green
    
    $existingValue = Get-WFServiceConfiguration -serviceUri $workflowManagerURL -Name $propertyName
    
    if($existingValue -eq $null)
    {
        Write-Host "Property $propertyName doesn't have a value which means it isn't in the settings DB table. Please confirm you want to add a new setting" -ForegroundColor Magenta
        $title = "Add Workflow Setting"
        $message = "Do you want to add a new workflow setting?"

        $yes = New-Object System.Management.Automation.Host.ChoiceDescription "&Yes", `
           "Add a new row into the settings table."

        $no = New-Object System.Management.Automation.Host.ChoiceDescription "&No", `
           "Doesn't add the new setting and exists the function."

        $options = [System.Management.Automation.Host.ChoiceDescription[]]($yes, $no)

        $result = $host.ui.PromptForChoice($title, $message, $options, 1)

        switch ($result)
        {
            0 {}
            1 {return}
        }
    }
    else
    {
        Write-Host "Poperty $propertyName has a value of $existingValue it will be changed to $propertyValue" -ForegroundColor Green
    }
    
    Set-WFServiceConfiguration -serviceUri $workflowManagerURL -Name $propertyName -Value $propertyValue
    
    Write-Host "Finished updating workflow manager property $propertyName" -ForegroundColor Green    
}

Figure 2

SharePoint 2013 Workflow Instance Size Error

January 6, 2015

While working on a recent project I got the chance to setup and use SharePoint 2013 workflows. This is a major step forward for the product and has a lot of benefits, however it does introduce a few complications.

As the workflows are now all stored and processed outside of SharePoint all communication is done via WCF services. This is great as it extracts the processing out of SharePoint and thus reduces the load on SharePoint.

The downside of this is it introduces additional areas where something can go wrong and this is what leads me onto the topic of this blog post.

The workflow I was working on was used to handle the approval of data on a SharePoint list item. In order for the workflow to move onto the next stage it required 5 groups of users to approve the data. The workflow had to wait until all 5 groups of users had completed and approved the data and once approved the workflow would move onto the next stage and send some emails.

The UI to handle the approval locked down the form so only users in certain groups could actually approve each section so in most cases a user would come in and approve 1 out of the 5 sections and this worked fine. There was also an admin group who could approve all 5 sections at one time. It was in this case where an error was being thrown by the workflow causing it to be terminated, see figure 1

image

Figure 1

When clicking on the workflow I could see the internal status was ‘Terminated’ and when clicking on the information icon I could see the error was “System.Activities.Statements.WorkflowTerminatedException: The workflow instance was too large to persist (over 5120 kilobytes). The maximum persistable workflow instance size is 5120 kilobytes.”, see figure 2.

image

Figure 2

For SharePoint errors this is actually reasonably detailed as it supplies a message explaining what the issue is instead of the usual something went wrong error. As this was my first real experience of SharePoint 2013 workflows I didn’t really know where to start debugging this so I had a Google around.

There are a few articles out there but nothing which matched what I was looking for. The closest I came was an article which suggested changing a server configuration property called ‘WorkflowServiceMaxActivityXamlSizeInBytes’.

I had a look into this and discovered this property can be updated by using a PowerShell command called ‘Set-WFServiceConfiguration’, see MSDN article. I tried to increase this value but unfortunately it didn’t seem to make any difference. I looked over the additional properties which can be set and I found one called ‘WorkflowServiceMaxInstanceSizeKB’ which seemed to match the error I was getting in terms of the description of the error but also the max value limit on the error message seemed to match the default value on the MSDN article. I tried changing this using the PowerShell command but again the workflow was still failing with the same error.

Given these properties were exposed so Microsoft obviously expected these might need to be changed in certain circumstances and the fact that the ‘WorkflowServiceMaxInstanceSizeKB’ property matched so closely to the error I was encountering I done some investigation into this and found there was another property called ‘WorkflowServiceMaxInstanceCompressedSizeKB’ which also had the same default value of 5120.

Unfortunately all articles referring to this were people adding a row directly into a table in one of the workflow databases. Anyone who knows SharePoint knows touching any SharePoint databases is not supported so I was reluctant to do this, however since it was a development environment I tried it but I still encountered the same error.

It wasn’t until I came across an article which was describing a slightly different error that on a I noticed down at the bottom of the article it said you have to restart the ‘Workflow Manager Backend’ windows service in order for settings changes to be picked up and after I done this the workflow started working.

I then had to do some testing to check which of the properties I had changed was the one which fixed the error and in my case it turns out I only needed the ‘WorkflowServiceMaxInstanceSizeKB’ property which could be set via PowerShell, see figure 3 for the exact script, so I didn’t have to worry about adding a value directly into the workflow database.

Set-WFServiceConfiguration -ServiceUri http://workflowmanagerurl:12291/ -Name “WorkflowServiceMaxInstanceSizeKB” -Value 30720

Figure 3

Overall the process of changing the workflow settings is very easy using the available PowerShell functions the key is to remember and re-start the ‘Workflow Manager Backend’ windows service to get these updated values picked up.


%d bloggers like this: