Business data alias cache configuration

Process variables that are configured to be available for search are given alias names and are cached in the business data alias cache. To improve performance, you can configure the cache to receive the business data aliases for only the snapshots that have associated instances instead of keeping the default setting that returns all the aliases for all the snapshot definitions.

You use the TWSearch API and REST Search API to look up the alias names or create saved searches with them. The list of alias names that is available to create saved searches or the aliases that are visible to these APIs are determined by what is contained in the business data alias cache. By default, the cache is populated at server start-up by a search on all processes for possible aliases.

The number of processes and snapshots in the repository affects how long it takes to initialize the cache because all processes are retrieved from the database. Depending on the size of the data or the speed of the database connection, the cache could take several minutes to load. While the cache is loading, other server functions must wait to access it. Building the cache also blocks server functions that try to update process models, which affects IBM® Process Designer. For example, when the cache building operation is running, some Process Admin Console pages might become unresponsive. This can result in a delay in saving data in Process Designer and you might receive a timeout error. To optimize performance or to improve the server start-up time, change the business data alias cache configuration to receive the business data aliases for only the aliases that have associated instances. Configuring the cache in this way eliminates the need to search all processes and only loads aliases used in existing process instance data.

To configure the cache, you can update the following configuration property values in the 100Custom.xml file:

use-business-aliases-for-process-instances

This property affects how the alias cache is loaded. You can build some saved searches from the complete list of aliases, and then switch to the instance-based list of aliases to get better performance.

false: If this property is set to its default value of false, all the processes are searched and the cache is loaded once with all the defined aliases in all snapshots. The cache is updated when new snapshots are deployed that contain new aliases. If there are many processes, searching all the processes can take a long time. You can shorten the time it takes to build the cache by deleting unneeded snapshots.
Restriction: Defining aliases in multiple snapshots with the same name but different simple types is not supported. This limitation can cause problems with the aliases for some features of the product.
true: Setting the property value to true returns the list of searchable business data aliases based on the aliases within existing process instances. The cache is reloaded at regular intervals and might not contain all aliases defined in all snapshots. The load time is much faster and is comparable to the time taken for a simple select query against the process instances.

<bdac-refresh-interval>[number of seconds]</bdac-refresh-interval>

This property specifies the length of time between automatic cache refreshes. However, it is effective only when the <use-business-aliases-for-process-instances> property value is set to true. The default value is 30 minutes (1800 seconds).

You might want to change the cache refresh interval when the number of instances in the system is small or when instances start and are deleted before the cache is refreshed. This property should have a shorter value in a Process Center than in a Process Server because Process Center instances tend to have fewer process instances running and the processes change much more frequently.

<init-bdac-on-startup>[boolean]</init-bdac-on-startup>

This property controls when the cache is initially loaded. The property is effective only when the <use-business-aliases-for-process-instances> property is set to false.

true: The default value is true, which means that the cache is initialized when the server starts.
false: When the value is set to false, the cache is initialized when it is first accessed. This generally means that the first user will experience a large delay.

Changing the configuration in the 100Custom.xml configuration file

Open the 100Custom.xml file for each application cluster member server, which is located in the following directory: dmgr_profile_root\config\cells\cellname\nodes\nodename\servers\servername\server_type\config\100Custom.xml.

Copy the following XML to 100Custom.xml under the <properties> tag.

<server>
     <portal merge="mergeChildren">
          <use-business-aliases-for-process-instances merge="replace">true</use-business-aliases-for-process-instances>
          <init-bdac-on-startup merge="replace">true</init-bdac-on-startup>
     </portal>
     <repository merge="mergeChildren">
          <bdac-refresh-interval merge="replace">1800</bdac-refresh-interval>
     </repository>
</server>

Make the changes to the property values as required and save the file.
Confirm that the changes are carried to the nodes by doing a full node synchronization and then restarting the application cluster.
Verify that the changes are correct in the TeamWorksConfiguration.running.xml file located here: node_profile_root\config\cells\cellname\nodes\nodename\servers\servername\server_type.
If you find an issue, then open the 100Custom.xml file in a browser to ensure that there are no special characters or syntax mistakes.