Page History

...

1. Avoid the Show all tasks option.
   If this option is unchecked, the worklist only shows tasks that are routed to the current user. This should limit the result set significantly. If you check this option, you should apply filters to limit the result set, as shown in the next steps.
2. 
    
   Set a filter on a column. This filter should configure the list to only show certain tasks. For example, an insurance application can be for a car insurance and a health insurance. As a knowledge worker may have a specialization on car insurances, it would be good to only present tasks to him/her that belong to car insurance applications. It is possible to filter on a column that is not shown to the user by using the Visible setting (above the filter). A list for health insurance tasks can be modeled on a different page.
3. You can let the end user help to refine the search. It is possible to use an attribute in a filter expression that was placed on the page for user input. You can use this to drastically reduce your search result. A good design here is that the attribute is initially placed on a page where the worklist is not visible (either its precondition is false, or it is on a different page), and only after the user supplied filter information to show the list. After the filtered list is shown, you could let the end user refine the search, by using a refresh on the attribute. In this way there is no moment in which an unfiltered list is displayed to the end user.
4. Distribute entries across multiple worklists. If you for example have three categories for tasks with low, medium and high priority, you can model that as three different worklists. A page is only loaded when all content on it has been loaded. Having 3 worklists on the same page means that the page is not displayed until the entries for the last worklist are retrieved. However placing the three worklists in different widgets results in the behavior that the content of the first worklist is shown as soon as it is ready, after which it is proceeded to loading the second widget, etc. With this behavior you can influence what the user sees first, and load more important worklists faster. By splitting up a worklists into multiple worklists you will also not encounter the problem of reaching the maximum retrieved entries as easily.
5. You can limit the number of the results coming from the database. This setting was introduced in version 9.4. This is a configurable runtime setting that will speed up the worklist for large result sets.

   In the properties file you can set the limit of the worklist and caselist by parameters.

   
   

   .

   Expand
   title Example Properties
   Java Setting the limit is done in Include Page DOC:_HomeFolder DOC:_HomeFolder . Code Block processengine.worklist.limit=x processengine.caselist.limit=x .Net Setting the limit is done in
   Include Page
   DOC:_PropertiesFileNet	DOC:_PropertiesFileNet

   Code Block
   <aquima> ... <properties> ... <property name="processengine.worklist.limit" value="x" /> <property name="processengine.caselist.limit" value="x" /> ... </properties> ... </aquima>

   You can configure the message that is displayed to the end user in the the message.properties (both Java and .Net)

   Code Block
   worklist.paging.limit.applied.feedback=Results are limited to the maximum of {0} caselist.paging.limit.applied.feedback=Results are limited to the maximum of {0}

   There is one disadvantage however, for versions 9.4 up to 9.8. The sorting and paging of the results is done after the results are retrieved, which means that your sorting might not be reliable.

   For example, you limit the retrieved results to 100.000 entries. However, 150.000 entries in the database match your search. You sort the 100.000 entries that were retrieved from the database on priority. The end user might think that he is performing the task with the highest priority, but this might not be true as the highest priority task could be among the 50.000 tasks that were not retrieved. The end user may also have the impression that there are fewer tasks in the system than actually present, as paging will show for example 10.000 pages of 10 tasks each.
   
   From version 9.9 and later this mechanism has been improved. From that version on, only one page of data is read from the database, and this one page is correctly sorted. There are two reasons why this setting is still useful. (1) When creating a styling for the pagination of the worklist that uses a dropdown box, then this dropdown box can become very large. When having for example 10.000 pages the browser might need to work very hard to create all the entries and possibly freeze or crash. (2) Chosing a page with a high page number takes longer than opening a page with a low page number. With this setting you can reduce the number of pages so that the end user can not choose such a high page number. We believe that there is no use case to go to pages with a very high number, as you would rather refine your search using the filters or use sorting.

6. Update to the latest version of Blueriq. Although this advice holds in general, we have made significant performance improvements in 9.9 and up. Updating to the latest version ensures that you can get the maximum out of your worklist, without the need to change how you model your application. We will be doing more performance improvements in the future as well.

...