Timeout Settings Relative from When the Activity is Invoked

Using Events and Timeouts in BPEL Processes 14-9 Once a valid datetime or date value has been retrieved, the expiration date for the activity is set to the specified date. For example, the datetime value bpelx:until=2009-12-24T18:00+01:00 specifies that the activity expects an inbound message to arrive no later than Dec 24, 2009 6:00 pm UTC+1 after the activity has started execution. Timeout dates can only be specified on the following activities: ■ Midprocess receives ■ Receive activities that do not specify createInstance=true A receive activity can only time out after it has been instantiated, which is not the case with entry receive activities.

14.3.3 Timeout Settings Computed Dynamically with an XPath Expression

The timeout setting for request-response receive and onMessage branches of pick activities can be set using an XPath expression instead of entering a static duration or datetime value. In this case, the value of the expression must return either: ■ A string that can be interpreted as a static XML duration or datetime value ■ An XML schema duration or datetime type Example 14–4 shows the syntax for using XPath expressions. Example 14–4 Timeout Settings Computed Dynamically with an XPath Expression bpelx:for=bpws:getVariableDatainput, payload, tns:waitValuetns:for bpelx:until=bpws:getVariableDatainput, payload, tns:waitValuetns:until If the returned expression value cannot be interpreted as an XML schema duration or datetime type, an event is logged in the instance audit trail indicating that an invalid duration and datetime value was specified, and no activity expiration time can be set.

14.3.4 bpelx:timeout Fault Thrown During an Activity Timeout

If a valid XML schema duration or datetime value is returned from the bpelx:for or bpelx:until attribute, a bpelx:timeout fault is thrown from the timed-out activity. This fault can be caught by any catch or catchAll block and handled like a regular BPEL fault. The message of the fault is the name of the activity. In addition, an event is logged to the instance audit trail indicating that the activity has timed out because the expected callback message failed to be received before the timeout duration. If the activity receives a callback from the partner before the timeout period, no fault is thrown. If a callback is received while the activity is being timed out, the callback message is not delivered to the activity and it is marked as canceled in the delivery message table. If a timeout action is attempted at the same time that a callback Note: The timeout setting attribute does not apply to the onMessage branch of a pick activity because the same functionality currently exists with the onMessage and onAlarm branches of the pick activity. 14-10 Oracle Fusion Middleware Developers Guide for Oracle SOA Suite message is handled, the timeout action is ignored. As of 11g Release 1, instances are locked optimistically as opposed to pessimistic locking in Release 10g. Therefore, the second action in line is still performed. However, the instance version check fails upon dehydration of the instance. The bpelx:timeout fault can be thrown from a BPEL component if the component WSDL declares the fault on the operation. If the fault is not declared on the operation, the fault is converted into a FabricInvocationException, which is a runtime fault. This fault can be caught by any caller components including BPEL components, but the fault type is no longer bpelx:timeout however, the fault message string still indicates that the fault was originally a timeout fault.

14.3.5 Event Added to the BPEL Instance Audit Trail During an Activity Timeout

Once a bpelx:timeout fault is thrown from a timed-out activity, an event is logged to the instance audit trail indicating that the activity has timed out, as opposed to having received the expected callback message from its partner.

14.3.6 Recoverable Timeout Activities During a Server Restart Refresh Expiration Alarm Table

Activities that specify a valid timeout duration or datetime are likely implemented in a similar manner to wait and onAlarm activities with an expiration date for the underlying work item object. If the node that scheduled these activities with the scheduler goes down either through graceful shutdown or abrupt termination, all these activities must be rescheduled with the scheduler upon server restart. It is not possible to have a single node the master node in the cluster be responsible for rescheduling these activities upon node shutdown.

14.3.7 How to Set Timeouts for Request-Response Operations in Receive Activities

To set timeouts for request-response operations in receive activities: 1. In the SOA Composite Editor, double-click the version 1.1 BPEL process service component.

2. In the Component Palette, expand BPEL Constructs.

3. Drag a Receive activity into the designer.

4. Expand the activity.

5. Click the Timeout tab.

This tab enables you to set a timeout for request-response operations, as shown in Figure 14–6 .