The other day I was asked about default limit you may see in K2 workspace when accessing, for example, Process Instances report for particular process (K2 Workspace > Process Overview > Process Instances).
Here is the message about default limit which you may see when surpassed it (This report has been limited to 1000 rows):
Well the main difficulty for me was that in my test environments I don’t usually see that much process instances, so to reproduce and verify respective settings was kind of a problem for me. There is a section at help.k2.com which mentions briefly configuration setting we need to adjust but not exactly and without going into much of details – Custom Reports – Create Report Wizard. From there we may infer that the setting we need to adjust is “RowLimitRecordCount“, and the next thing is to change it and test. But like I said testing this may be difficult if you don’t have 1000+ process instances running in your environment (it could be that your test environment even doesn’t have any process deployed yet). And you don’t want to run 1000+ process instances by doing 1000+ mouse clicks, right? Let’s consider how to go about this problem first.
Luckily enough at help.k2.com you may find information on “Starting a K2 Process using the Windows Powershell” which is a good starting point for solving our little problem. So starting from that I created following PS script running number of process instances required for my test:
$i = 0
Do {
$i=$i+1
[System.Console]::WriteLine("Starting K2 process instance" + $i)
Add-Type -AssemblyName ('SourceCode.Workflow.Client, Version=4.0.0.0, Culture=neutral, PublicKeyToken=16a2c5aaaa1b130d')
$conn = New-Object -TypeName SourceCode.Workflow.Client.Connection
$conn.Open("localhost")
# Adjust line below by specifying your workflow name
$pi = $conn.CreateProcessInstance("Project_Name\Workflow_Name")
$conn.StartProcessInstance($pi)
}
# Adjust line below to create required number of instances
While ($i -lt 1000)
[System.Console]::WriteLine("Done: " + $i + " process instances started")
This code will run as much instances of a specified process as you specify in “While ($i -lt 1001)” line (lt is quite queer/unconventional operator which PS uses for “less than”). Another line you most likely have to edit is “$pi = $conn.CreateProcessInstance(“Project_NameWorkflow_Name”)” – I hope this is quite self-explanatory.
If you don’t have any workflows deployed then for this particular test all you need is just go to K2 studio and drop Default Client Event and next terminate it with Placeholder Event, then deploy this test workflow. Process with only Placeholder Event won’t suffice for this test as its instances will go into completion immediately and you won’t get multiple instances running simultaneously with such process.
Once you have large number of instances running you may see the message about the row limit mentioned in the beginning of this post and test change of “RowLimitRecordCount” value. Now it’s high time to adjust the RowLimitRecordCount value in web.config file located in <install drive>:\Program Files (x86)\K2 blackpearl\WorkSpace\Site. Based on its default (1000) value and description we saw at help.k2.com for it this should be the one we need. But quick test will show us that increasing it doesn’t work for described problem. OK, maybe we just forgot to perform IIS reset which is necessary for web application to pick up the settings? Nope, IIS reset is necessary but this doesn’t help us to increase this limit.
Next thing which we may look at is OOBReports.xml file in the same location as aforementioned web.config file. It also do contain RowLimitRecordCount value which is actually controls the returned rows limit for Process Instances report (and judging by its name of other OOB reports too). And yes IIS reset is required for this change to take an effect. You may easily make sure that the same setting in web.config file controls the limit for custom reports if you quickly create custom report (you may be unoriginal and simply create Process Instances reports using Report Designer) and test this. You will be able to see the same message on a slightly different custom report layout and verify that this limit is controlled by setting in web.config file:
Other interesting thing which may be adjusted by editing OOBReports.xml file is whether deleted process instances should be included in reports. With regards to this setting you may adjust global default value for “IncludeDeletedStatus“, and also enable or disable the users capability to adjust this setting via the User Interface by changing the”DisableUserSetting” to False or True.