Mihai's Oracle SOA Solutions Blog

Consider following scenario : you want to force a BPEL to wait for maximum of 3 (180 seconds) minutes to get reply from a Partner Link.  You can set the following timeouts :
a) syncMaxWaitTime to 180;
b) for CubeEngineBean, CubeDeliveryBean and MessageBean to 240 (best is to set it 1-2 minutes more than the syncMaxWaitTime)
c) Global JTA Timeout to 300

As a general rule, you should have following relation between the timeout parameters:

 1. Setting the global transaction timeout on Weblogic domain level :

• Login to Weblogic console (http://host:port/console);
• Select Services > JTA from the left pane;
• Select JTA tab in the right pane;
• Change the parameter:
  Timeout Seconds  (specifies the time in which a transaction will timeout, if uncommitted);

All steps described above can be done by editing directly BEA_HOME\user_projects\domains\SOADomain\config\config.xml and changing the value in section:

<jta>
<timeout-seconds>300</timeout-seconds>
</jta>

2. Setting the transaction timeout for BPEL application in the deployment descriptor :

• Go to BEA_HOME\user_projects\apps\soaApps\BPELPM;
• Make a backup of ejb_ob_engine.jar (if anything goes wrong just put back the original ejb_ob_engine.jar);
• Open the ejb_ob_engine.jar (for example in WinZip) and edit weblogic-ejb-jar.xml ;
• Change the for the following MBeans : CubeEngineBean, CubeDeliveryBean and MessageBean;
  Save weblogic-ejb-jar.xml and repack the JAR (this is done automatically in WinZip);
• Go to Weblogic Console -> Deployments and Lock&Edit;
  
• Select BPELPM and Update it -> this will force a redeployment of the JARs;
  
• Click Activate Changes (at this steps there might be some errors in Weblogic Console
  but afternext there will be no problems);
  
•  Stop the SOA server and start it again;
  
• After SOA server is started go to Deployments section and check if BPELPM is "Active". If not just start it from here by selecting and and cliking on "Start -> Servicing all requests".

3. Setting syncMaxWaitTime:

• This property sets the maximum time the process result receiver waits for a result before returning;
• Can be changed via BPEL Console -> Manage BPEL Domain (10.1.3.3) / Configuration (10.1.3.4);
• Scroll down to find syncMaxWaitTime parameter. Change the parameter setting and click 'Apply' in lower right corner of the screen;
  

Related post about how to Set a Timeout for a WS invocation in BPEL

If you try to use use HTTP Basic Authentication headers to invoke a secured Web Service in BPEL 10.1.3.4

<property name="httpBasicHeaders">credentials</property>
<property name="httpBasicUsername">your_username</property>
<property name="httpBasicPassword">your_password</property>

You may encounter a NullPointerException error ONLY if you use ports 80 or 443 :

<Faulthttp://schemas.oracle.com/bpel/extensionhttp://schemas.xmlsoap.org/soap/envelope/>
<faultcode>null:bindingFault</faultcode>
<faultstring>business exception</faultstring>
<faultactor>cx-fault-actor</faultactor>
<detail>
<summary>com.collaxa.cube.ws.wsif.providers.http.WSIFOperation_HTTP@c54b88 : Could not invoke 'process'; nested exception is: java.lang.NullPointerException</summary>
<detail>java.lang.NullPointerException</detail>
</detail>
</Fault>

The simplest workaround is to try to host your web-service on ports other than 80 (http) /443 (https).

The issue is fixed in MLR 8 for 10.1.3.4 - patch number 8372150.

When calling Secured Web Service from BPEL there is an error received in logs and in Bpel Console :

The partner link properties in bpel.xml are all set correctly to use WSSE headers :

Error only occurs on 10.1.3.4 and on 10.1.3.3.1 MLR#14 or higher. Exact same BPEL process works fine on 10.1.3.3.0 and on 10.1.3.3.1 until MLR#13.

When passing the WS Security header through partnerlink the SOAP request can generate OASIS 2002 or OASIS 2004 compliant header. For this there was an aditional parameter introduced : wsseOASIS2004Compliant

Setting it to "false" (the default value in 10.1.3.4) generates OASIS 2002 compliant header :

and setting it to "true" generates OASIS 2004 compliant header :

Sometimes, when the a BPEL process have a lot of Wait and onAlarm activities (or there are many BPEL instances running that use Wait or onAlarm) then some of the Alarms may not fire.

The BPEL engine makes use of Quartz in numerous ways, mainly for expiration of wait and onAlarm activities, but also for:

• sending periodically "pings" to the dispatcher to flush out stranded messages
• enabling polling for custom activation agents
• scheduling execution of activities that need to be performed in the future (for example, mail receive activities).

In 10.1.x releases of BPEL, the number of Quartz threads can be tuned by changing the com.oracle.bpel.*.threadCount properties in ORACLE_HOME/bpel/domain/DOMAIN_NAME/config/resources-quartz.properties file.

BPEL uses Quartz to schedule expiration events for Wait and onAlarm activities, and the parameter that controls number of threads for this is com.oracle.bpel.expirationAgent.threadCount.

There is no specific formula for calculating it, as this is a parameter that would require some tuning to set it to the best value suitable for your environment. The default value is 10, and for start you can try to set it to 30 and test. If still the number is too low, you can try to further increase to 50 or a higher value. Be careful that setting it too high, will result in increased overhead, because too many threads are created.

Sample setting of expirationAgent in resources-quartz.properties:

# com.oracle.bpel.expirationAgent - schedules wait/onAlarm activities;
# this is the most heavily used agent in the system. If your flows
# typically have many wait/onAlarm activities and the total number of
# instances created is high, performance may suffer if the expiration agent
# thread count is not sufficient to handle the load. In worst-case not
# having enough threads to handle high incoming request counts may result
# in OutOfMemory errors as the number of scheduled tasks piles up.
#
com.oracle.bpel.expirationAgent.threadCount = 30

1. Given a process that invokes a Local or Remote WebService, we want to set a timeout of 10 seconds that the BPEL will wait for the answer. If no response is received within the specified timeout, we want to perform a series of activities (eg. WebService not available, end the BPEL process, etc). "WS_Call" is the Invoke operation on the WebService.


2. In the Sequence where "WS_Call" Invoke activity, add a Catch branch :

and set it's properties to catch a RemoteFault. We need to Catch a RemoteFault because this is the type of fault that the "timeout" we are setting in next step will throw when the timeout will expire:

In the Catch branch you can process the error : Terminate the process, insert a Reply/Response to return from the Bpel, make some Assign activity and then continue the Bpel, etc.


3. Set the property "timeout" for the PartnerLink to 10 seconds .
This specifies the number of Seconds to wait until expire. A remote fault is thrown if this happens.


and if the WebService is on the SAME host as the BPEL you also need to set the property "optSoapShortcut" to FALSE.
You need this to FALSE to force local SOAP request to go through SOAP instead of internal calls.

This final step can be directly configured in bpel.xml in partnerLinkBinding section:

Now if the WebService invocation takes more than 10 sec, it should throw a RemoteFault that will be catched in the Catch branch that we built.

The Outbound dynamic configuration is supported via JCA dynamic partnerlinks. There are 2 possible scenarios for this (which are described in detail in Oracle SOA tutorial 140.AdapterFramework\DynamicPartnerlinks) :

a) the dynamic part is the jca:address location attribute

<jca:address location="eis/ftp/anonymous">

The BPEL process can decide which JCA Connection Factory (JNDI entry) to use. The dynamically chosen JNDI name at runtime must already be defined in oc4j-ra.xml .

b) the dynamic part are the JCA connection properties:

<jca:address ManagedConnectionFactory="oracle.tip.adapter.ftp.FTPManagedConnectionFactory"
mcf.Host="my.server.com"
mcf.Port="21"
mcf.Username="anonymous"
mcf.Password="some_password"

where the dynamic attributes include Host, Port, Username and Password. Then attribute ManagedConnectionFactory is not changeable. This solution is independent of the existence of any oc4j-ra.xml defined connection factory locations.

For the Inbound synchronous read the solution is to use the synchronous read operations available for the adapter.