Download PDF (1.3 MB) - IBM Redbooks

Figure 3-2 shows an example of a good BPD design pattern.
Figure 3-2 Good BPD design pattern
3.1.3 Use conditional joins only when necessary
Simple joins use an “and” condition; all lines that head into the join must have an active token
for the tokens to continue forward.
By contrast, for conditional joins, all possible tokens must reach the join before they
proceed. Thus, if you have a conditional join with three incoming lines, but only two of them
currently have tokens (or might have tokens by looking upstream), then those two tokens
must arrive at the join to proceed. To determine this condition, the BPD engine must evaluate
all possible upstream paths to determine whether the tokens can arrive at the join. This
evaluation can be expensive for large, complex BPDs. Use this capability judiciously.
3.1.4 Guidelines for error handling
Avoid global error handling in a service, which can use an excessive amount of server
processor utilization and can even result in infinite loops in coaches.
When catching errors on an activity in a BPD, do not route the error back to the same activity.
Doing so causes the server to thrash between the BPD and service engine, using a large
amount of Process Server processor time and also database processing.
Chapter 3. Development best practices 25