#317 BPM 11g Timeout Heuristics

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.

·        














      DB Adapter - QueryTimeout is the attribute you set here. This you can set at design time in JDev, or via em.

·         Binding Component – e.g. the web service you are calling - Connect and Read timeout attributes. 

       These can be set in em. 

Ok, once you have set all of these, see Mark Foster's excellent article for screenshots etc. You can then 

configure an appropriate fault policy bound to the reference(s) with various retry models optimized for the resource (e.g. accounts for different restart times etc.). This policy can then revert to human intervention if the retry does not succeed