Download PDF (1.3 MB) - IBM Redbooks

Batched inputs: Sending large objects as multiple small objects
If a large object must be processed, the solutions engineer must find a way to limit the
number of allocated large Java objects. The primary technique for limiting the number of
objects involves decomposing large BOs into smaller objects and submitting them
individually.
If the large objects are actually collections of small objects, the solution is to group the smaller
objects into conglomerate objects less than 1 MB in size. Several customer sites have
consolidated small objects in this way, producing good results. If temporal dependencies or
an all-or-nothing requirement for the individual objects exists, the solution becomes more
complex. Implementations at customer sites demonstrate that dealing with this complexity is
worth the effort as demonstrated by both increased performance and stability.
Certain WebSphere adapters (such as the Flat Files adapter) can be configured to use a
SplitBySize mode with a SplitCriteria set to the size of each individual object. In this case,
a large object is split in chunks (of a size specified by SplitCriteria) to reduce peak memory
usage.
Claim check pattern: Only a small portion of an input message is used
When the input BO is too large to be carried around in a system and that process or
mediation needs only a few attributes, you can use a pattern known as the claim check
pattern. Using the claim check pattern, as applied to a BO, involves the following steps:
1. Detach the data payload from the message.
2. Extract the required attributes into a smaller control BO.
3. Persist the larger data payload to a data store and store the “claim check” as a reference
in the control BO.
4. Process the smaller control BO, which has a smaller memory footprint.
5. When the solution needs the whole large payload again, check out the large payload from
the data store using the key.
6. Delete the large payload from the data store.
7. Merge the attributes in the control BO with the large payload, taking into account the
changed attributes in the control BO.
The claim check pattern requires custom code and snippets in the solution. A less
developer-intensive variant is to use custom data bindings to generate the control BO. This
approach is limited to certain export and import bindings. The full payload still must be
allocated in the JVM.
2.5.3 Data management
The use of document management functions, such as document attachments and the
integration capabilities of content that is stored in enterprise content management
repositories, might result in large objects. The capacity that is required for processing of
documents depends on the size of the Java heap and the load that is placed on that heap
(that is, the live set) by the current level of incoming work. The larger the heap, the larger the
data that can be successfully processed.
Document attachments and content integration artifacts are stored in the Process Server
database. Over time and depending on the size and amount of documents, the database
might grow in size. Completed process instances should be archived or deleted (see 4.13.7,
“Archiving completed process instances” on page 81 for more information).
20 IBM Business Process Manager V8.0 Performance Tuning and Best Practices