Optimizing Process API Usage
Designing a Process application for increased performance can significantly improve
application efficiency while enhancing the user experience. The following guidelines
provide general recommendations for optimizing Process application performance:
- Minimize round-trips to the Process Engine server
Performance improvements can be achieved by minimizing the number of Remote Procedure Calls
(RPCs) to the Process Engine. Methods that fetch data or cause some action to occur typically cause RPCs to the Process Engine server, whereas methods that get and set data are local to the object. Similarly, minimize logging on and logging off from the Process Engine.
- Minimize the amount of data transferred
Fetch the minimum amount of data necessary by retrieving only the data needed to process work.
Eliminate the return of unnecessary system or user fields, and cache static
data (such as user information, and queue names).
- Optimize queries
Minimize the amount of data returned for a query. Return only user fields (set query flags to avoid retrieving system fields and helper data), if possible. Use filters and indexes to further minimize the amount of data. Note that each element retrieved has a different cost, as follows:
- Roster element: the least amount of data.
- Queue element: less data transferred than a Step element (system fields describe the work item and its state).
- Step element: less data transferred than a work object.
- Work object: the most data transferred (contains all system fields and user fields).
- Cache data
Cache retrieved objects when possible.
- Partition for multiple queues
Create distributed queues with useful indexes and exposed fields.
- Optimize Roster, Queue, and Log usage
(See the following sections.)
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 PE 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"