Optimizing Process API Usage
This topic provides guidelines on optimizing your use of Process API classes
in order to improve your Process application's performance. Improving application
performance provides improved efficiency for users, improved efficiency of computing
resources, reduces downtime, and improves the overall ability to manage the
Process Engine.
Subtopics include:
General Guidelines on
Optimizing a Process Application
Designing a Process application for high performance can significantly improve
application efficiency while enhancing the user experience. The following guidelines
provide general guidance on optimizing Process application performance:
- Minimize round trips to the Process Engine server Performance
improvement 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 (users, queue names, and so on).
- Optimize queries Minimize the amount of data returned for
a query to just user fields (set query flags to avoid retrieving system fields
and helper data); use filters and indexes to further minimize the amount of
data. Note that each element retrieved has a different cost, as follows:
- Roster element has the least amount of data (no server-side de-blobbing
of the work item).
- Queue element less data transferred than a Step element (system
fields describe the work item and its state; no server-side de-blobbing
of the work item).
- Step element less data transferred than a work object (server-side
de-blobbing of the work item).
- Work object has the most data transferred (contains all system
fields and user fields; server-side de-blobbing of the work item).
- 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 Do not query through
the roster, disable unneeded logging options, etc. to maximize usage (see
below).
- Perform manual garbage collection Perform your garbage collection
manually as opposed to automatic garbage collection.
The following subsections provide details on these and additional guidelines
to improve application efficiency.
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 roster
are more costly for updates.
- Set an optimal buffer size on the query (roster-related). For example, consider
increasing the buffer size (the default is 50; the maximum is 200) to minimize
round trips to the Process Engine server.
- Do not query work objects through the roster, which 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 BLOB). 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, and possibly to lock, an object. Using the
flag also reduces lock contention.
- Set optimal buffer size on the query. For example, consider increasing the
buffer size (the default is 50; the maximum is 200) to minimize round trips
to the Process Engine server.
- Partition – if possible, use more than one queue.
Optimizing Log Usage
To optimize log usage:
- Partition – use different logs for different workflows.
- Disable any logging options that you do not need. Do not use this technique
in conjunction with Tracker, which can be impacted by it. Note that while
this improve performance, it also affects the Tracker
- Manage log records. Use the vwlog tool to maintain logs. Periodically
remove unused log records. (Use crontab or Windows scheduled tasks.)
- Save log information in text files.
Optimizing Queries
To optimize query usage:
- Set the appropriate query flags to only return user fields from Roster,
Queue, and Log queries; i.e., minimize the amount of return data by setting
the query flags QUERY_GET_NO_SYSTEM_FIELDS and/or QUERY_GET_NO_TRANSLATED_SYSTEM_FIELDS
in the queryFlags parameter of the createQuery() method to avoid retrieving
system fields and helper data from the work items returned from a search.
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 (the default is 50 items); for example:
vwQueue.setBufferSize(25)
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
for completeness, the following guidelines should be observed:
The result list from either of the Java API 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 Config 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 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 these methods have limitations for particular combinations
of input arguments, as follows:
- When the search type is NONE (return all records, ignoring search type and
search pattern), 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 SunOne 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 ot -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 a "not NONE"
option (i.e., 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 a "not NONE" option (i.e.,
ASCENDING or DESCENDING):
- 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 system will
log and display an error message reading: "VWServer Exception:
Unavailable critical extension. LDAP err = 0x0000000c"