When creating a dynamic case management application, you want to show a AQ_WorkList to the knowledge worker in which he/she can see the available tasks. As end users do not like to wait for relevant information to load on the screen, this worklist needs to be able to retrieve the relevant information fast. Blueriq makes the worklist as fast as possible from a technical point of view, but there are guidelines for you as Business Engineer to choose settings that result in a better performance.
Although this page concerns the worklist, all advice also holds for both the AQ_CaseList and the AQ_TaskList. As these list automatically returns less results, it is less likely that you experience performance problems with it. |
When a dynamic case management solution has been in production for a significant amount of time, the number of cases and tasks that are present in the database can also grow increasingly, if more cases are created than closed. Think of long-running cases that take months or years to finish. End users want to experience the same performance with such a full database as with an empty database. An important factor for a performing worklist is the number of results that match your search. If you model a worklist that always returns all tasks, than this worklist will not perform with an increasingly large database. We advise to create a worklist that filters as many results as possible, in order to create a good experience for the end user. This article describes some pointers that help you achieve a good performance.
Show all tasks
option.Visible
setting (above the filter). A list for health insurance tasks can be modeled on a different page.In the properties file you can set the limit of the worklist and caselist by parameters.
Java Setting the limit is done in .
You can configure the message that is displayed to the end user in the message.properties (both Java and .Net)
|
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.
Blueriq provides a set of general-purpose indexes, but for large databases we recommend dropping the indexes that aren't used in your application, as well as adding any necessary indexes that result in better execution plans for the most frequently used queries. The queries generated by AQ_WorkList and AQ_CaseList can be monitored by setting the log level of org.hibernate.SQL
to DEBUG
. A few examples of indexes you might create depending on the configuration of your worklist and the usage patterns of your users are:
taskId
, name
) on the customFields
tablecaseId
, entityName
) on the instances
tableinstanceId
, attributeName
) on the instanceAttributes
tableinstanceAttributeId
, stringValue
) on the attributeValues
table (note: use the appropriate "value" column depending on the data types of the attributes shown in your worklistsCaseID
column and this is used for filtering (in Studio) or searching (by users on the frontend), you should create composite indexes which start with the caseID
column. For example, if your worklist has columns Case ID
, Task Name
and Priority
, there is a filter on the Case ID
column in the Studio model and the users often search on the Task Name
column, you should create the composite index (caseId
, name
) on the tasks
table.Keep in mind that query performance depends not only on the indexes but also on the data and the usage patterns of your users. Periodically monitor the execution plans of the worklist queries on real data and determine whether any changes to the execution plans occurred since the last check. Add indexes where appropriate in order to maintain good performance.
We also recommend that you monitor index fragmentation in production databases, as index fragmentation can lead to poor query performance. Your indexes become more fragmented the more data is inserted or deleted. Implement an index maintenance plan to reorganize or rebuild your indexes once the fragmentation level exceeds a set threshold.