Optimizing Process API Usage

Optimizing Roster Usage

All work items are tracked through the roster and multiple workflow definitions are contained in a roster. Note that only VWRosterElements and VWWorkObjects are retrieved from a Roster query.

To optimize roster usage:

• Expose only infrequently updated fields. Exposed data fields on rosters are more costly for updates.
• Set an optimal buffer size on the roster-related queries. For example, consider increasing the buffer size (default is 50, maximum is 200) to minimize round-trips to the Process Engine server.
• Do not query work objects through the roster. This causes the application to access the database twice instead of once.

Optimizing Queue Usage

All work for a particular step resides in a queue (the queue contains the actual work object data). A queue can potentially contain different types of work objects. When a queue is queried, VWWorkObjects, VWStepElements, and VWQueueElements are retrieved.

To optimize queue usage:

• Use the QUERY_LOCK_OBJECTS flag. This avoids the necessity of an additional RPC to check the lock status of an object (or to lock an object). Using the flag also reduces lock contention.
• Set an optimal buffer size on the query. For example, consider increasing the buffer size (default is 50, maximum is 200) to minimize round-trips to the Process Engine server.
• Partition, if possible, to use more than one queue.

Optimizing Log Usage

To optimize log usage:

• Partition to use different logs for different workflows.
• Disable any logging options that you do not need. Note that while this improve performance, it also affects the Tracker. Do not use this technique in conjunction with Tracker.
• Manage log records. Use the vwlog tool to maintain logs. Use operating system scheduling tools to periodically remove unused log records.
• Save log information in text files.

Optimizing Queries

To optimize query usage:

• Set the appropriate query flags to return onlyuser fields from Roster, Queue, and Log queries. For example, set the query flags QUERY_GET_NO_SYSTEM_FIELDS and/or QUERY_GET_NO_TRANSLATED_SYSTEM_FIELDS for the queryFlags parameter of VWQueue.createQuery() to avoid retrieving system fields and helper data from the work items returned. Note that helper methods on elements are not functional without translated system fields.
• Create indexes, and limit the number of indexes, to achieve more efficient queries with less data transmitted. Indexes should be unique.
• Use filters to get the ranges of elements for more efficient queries with less data transmitted. Use filters to limit elements retrieved to a specified range or to set a maximum number of objects to be retrieved for each fetch from the Process Engine server (default is 50 items).

Guidelines for Generating Pattern-Matched Lists of User and Group Names with LDAP Data Security

To optimize lists of user and group names in systems with LDAP Data Security, the following guidelines should be observed:

The result list from the VWSession methods findGroups() and findUsers() is determined by four input arguments: search pattern, search type, sort type, and buffer size. Whether one of these methods is invoked directly through a custom application or indirectly through a FileNet® Participant Selection Dialog (accessed through the Process Configuration Console, Tracker, Administrator, Designer, and the Sample Java™ Step Processor client utilities), the output list normally has the following characteristics:

• Contains names that match the search pattern according to the rules of the search type.
• Is ordered according to the sort order specified by sort type.
• Is transported from the Process Engine (internally) in chunks that contain the number of records specified by the buffer size argument.

The name lists produced by VWSession.findGroups() or VWSession.findUsers() have limitations depending on the particular combinations of input arguments, as follows:

• When the search type is NONE, the following special considerations apply to the other input values:
  • Search pattern is ignored, and a NULL search pattern is allowable.
  • The sort type is ignored, and a list sorted in ascending order is always returned.
• For the Sun Java System Directory Server, FileNet recommends you eliminate possible side effects of a security server buffer size limitation by setting the Process Engine Administrator user account size limit to -1 (no limit).
• When the search type is an input option other than NONE, the following special considerations apply to the other input value options and the resulting list of names, depending on whether the sort type is NONE or one of the other possible options (such as, ASCENDING or DESCENDING), as follows:
  • When the sort type is NONE:
    • The buffer size setting will be the maximum number of records that can be returned by the method call.
    • The actual number of records returned will be the lesser of the input buffer size and the directory server size limit.
  • When the sort type is an option other than NONE:
    • The buffer size setting will be the maximum number of records that can be returned by the method call.
    • A non-null search pattern is required, except when the search type is NONE. This is because the NONE search type ignores the search pattern.
    • The security database must contain an index for sorting. If the appropriate security database index does not exist, the Process Engine will log and display an error message similar to the following: VWServer Exception: Unavailable critical extension. LDAP err = 0x0000000c