Tuning Process Portal searches

In non-federated IBM® BPM environments, you can optimize the number of retrieved results entries of your saved searches. You can also optimize your process searches by using the saved search acceleration tools.

Important: The following information applies to both Heritage Process Portal and Process Portal.

Optimize the number of loaded search result entries

You can optimize the number of retrieved results entries of your saved searches.

The number of entries that is returned for a saved search is controlled by the value of the process-search-engine-count-optimization property in the 99Local.xml file. Saved searches are optimized to process 500 result entries. The displayed pages of the result contain counts of up to 500 entries.

The process-search-engine-count-optimization property is also used to determine the displayed values for the task summary and task statistics counts (On Track, At Risk, Overdue) in the Process Portal Work and saved search dashboards. For example, with the default property value of 500, if Process Portal users have 600 tasks, the summary count shows 500+. The task statistics include only the first 500 tasks in the task list, so they might see the following counts for the task categories: 100+ On Track, 200+ At Risk, 200+ Overdue.

If you expect more than 500 records for a call, for example, if you are using the TWSearch object or saved search APIs, or if your Process Portal users usually have more than 500 tasks, you can increase this number.

To retrieve a different number of entries, complete the following steps
  1. Insert the following section into the 100custom.xml file: 
    <properties>
    <server merge="mergeChildren">
  <process-search-engine-count-optimization merge="replace">500</process-search-engine-count-optimization>
       </server>
</properties>
  2. Adjust the 500 value to meet your needs. The larger the value, the more memory and time is needed to retrieve the entries.
  3. Save the changes to the 100custom.xml file, and restart the server.

Optimize saved searches with business data variables

You can optimize your process searches by using the saved search acceleration tools.

For systems that have a large amount of business data and are used in searches (for example 10+), the Process Portal tasks and instance queries might operate slower than expected. When you use the save search acceleration tools to optimize your process searches, Process Portal searches that constrain on business data are faster.

Tip: You optimize a process search only on runtime or production systems. It is suggested that you do not optimize process searches on systems that are used for development, or for systems where changes happen frequently to deployed applications.
You use the following two search acceleration tools to optimize a process search:
  • SchemaGenerator tool - This tool generates two new tables: LSW_BPD_INSTANCE_VAR_NAMES (variables table), and LSW_BPD_INSTANCE_VARS_PIVOT (pivot table). It also generates the schema for each table.
  • DataLoad tool - This tool populates the variables table data from the BPD instances that are currently in progress.
The pivot and variables tables
The pivot and variables tables ensure that your query runs efficiently once your process search has been optimized. The tables present data in the following format, with each item in its own column:
  • The pivot table
    • Instance ID
    • Every searchable business data variable defined in all currently deployed BPDs
    • Every business data variable defined in LSW_BPD_INSTANCE_VARIABLES
  • The variables table
    • Variable name
    • Column name
    • Data type
Process search optimization overview
A process search optimization can consist of three unique processes:
  • Enabling an optimization
  • Disabling an optimization
  • Re-enabling an optimization
To enable process search optimization, you must run the optimization tools:

To disable optimization, complete the following steps:

  1. Shut down the server
  2. Remove the pivot and variables tables from your database.
  3. Restart the server.
To re-enable optimization, complete the following steps:
  1. Deploy all BPD updates.
  2. Stop the server.
  3. Remove the pivot and variables tables from your database.
  4. Rerun the SchemaGenerator and DataLoad tools.
  5. Restart the server.
System requirements and restrictions

The following requirements and restrictions apply:

  • You use this process only for production deployments, or for systems that simulate production deployments.
  • You must rerun the tools if you have deployed a new a BPD or updated an existing BPD (deploying a new BPD snapshot) that contains any searchable business data variables. You must also rerun the tools if you have deployed a modified BPD that has changes to its business data variable definitions (adding new variables, renaming any existing variable, modifying the type of any existing variable). When you rerun the tools, you rebuild the pivot table.
    Note: Business data is defined by making the Visible in Process Portal variable available on the BPD property sheet. See Making business data available in searches and views.
    Restriction: If you do not do rerun the optimization tools when a BPD has changed, your process searches will generate failures.

The following restrictions apply to a DB2 database:

  • The pivot table copies of all string values are truncated if they exceed 128 bytes.
  • The sizes of all unique business data variables, when added together, must be less than 32767 bytes. This means if all your business data variables were strings, you would be limited to 255. This restriction is on all unique business data variables defined across all of your deployed BPDs. For example, if you had three BPDs deployed that each had six business data variables, but one of them was defined in exactly the same way in all three BPDs, then you would have a total of 16 unique business data variables.

The following restrictions apply to an Oracle database:

  • When you query business data using the DB-based search, the search is typically accessed through the JavaScript API and several REST APIs. If you pass a decimal value or an empty string value to a process and the value is stored in a variable that is exposed to searches, the APIs may return a search result for Oracle that differs from the search result that is returned for other database products. This is generally only a problem when you are using both Oracle and another database product, such as DB2.
  • If you pass a decimal value that has zeros as fractions to a process and the decimal value is stored in a variable that is exposed to searches (such as the Visible in Process Portal variable), then the APIs return the value as it is formatted by the database. For example, if you pass a value of 150.00 to the process, the APIs would return a result of 150 for Oracle and a result of 150.00 for DB2. Any problems resulting from this discrepancy can generally be fixed at the application level. For example, in a Java application, you can use the java.text.NumberFormat or java.text.DecimalFormat class to help resolve the problems.
  • If you pass an empty string to a process and the empty string is stored in a variable that is exposed to searches (such as the Visible in Process Portal variable), then the APIs return a result of null for Oracle and a result of empty string for DB2.
Parent topic: Administering Process Portal