Here are some basic heuristics to defensively deal with timeouts in your BPM processes.
The basic rule is - follow the hierarchy
JTA Timeout > BPM EJB Transaction Timeout > resource timeout
We can look at this as referring to the 3 different technical levels involved -
JTA Timeout - set at weblogic engine, this is the Java Transaction timeout. You want to avoid this ever happening. It can be set at weblogic domain level (JTA tab) via the weblogic console - By default this is set to 30 seconds. You will have to increase this, as the BPM EJB Tx Timeout is set, per default, to 300 seconds.
BPM EJB Transaction Timeout - set at BPM engine level. These BPMXXX EJBs are listed under deployments in the weblogic console (Deployments --> soa-infra - EJBs) and the Tx Timeout can be set there.
Resource Timeout - e.g. the web service your BPM process is calling -
Each
resource may be unique from this perspective, so it may not be a case
of one size fits all. Some research may be needed here to work out what
one could term the “normal” response time. You want to avoid inefficient
use of the BPM engine – i.e. the engine waiting too long for a response
from a service, be it a web service or a DB adapter service. My rule of
thumb - add 30% to the "normal" time.
Read the complete article here.
For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.
Blog
Twitter
LinkedIn
Facebook
Wiki