What Happens When You Create a Pick Activity

Using Events and Timeouts in BPEL Processes 14-7 Both operations have the same input message type and correlation is defined with initiate set to join. The expectation is that the processMessage1 invocation is invoked immediately and the BPEL process B instance is created, which should sleep for ten seconds. After five seconds, the invoking process should then post the processMessage2 invocation to BPEL process B and this invocation should go to the already existing instance instead of creating a new one since the correlation ID is the same and initiate is set to join. However, for each invocation, a new instance of BPEL process B is created and the result cannot be predicted. ■ If the processMessage2 operation branch finishes first, then the subsequent assign operation fails because the input variable from processMessage1 is assumed to be null for that instance. ■ If the processMessage1 operation branch finishes first, then the process returns callback data with only partial information does not include the input from processMessage2. In Oracle BPEL Process Manager’s implementation, either one of the two operations processMessage1 or processMessage2 creates a new instance. This is implemented so that database queries do not need to be made to see if there are already instances created. The workaround is to create two processes that are initiated by the two different operations.

14.3 Setting Timeouts for Request-Response Operations in Receive Activities

You can provide a timeout setting for request-response operations in receive activities. This provides an alternative to using the onMessage and onAlarm branches of a pick activity to specify a timeout duration for partner callbacks. The following sections provide an overview of this functionality: ■ Timeout settings relative from activity invocation ■ Timeout settings as an absolute date time ■ Timeout settings computed dynamically with an XPath expression ■ bpelx:timeout fault thrown during an activity timeout ■ Events added to the BPEL instance audit trail during an activity timeout ■ Recoverable timeout activities during a server restart

14.3.1 Timeout Settings Relative from When the Activity is Invoked

You can specify a timeout setting relative from when the activity is invoked. This setting is specified as a relative duration using the syntax shown in Example 14–2 . Example 14–2 Timeout Settings Relative from When the Activity is Invoked receive | bpelx:for=duration-expr Note: The timeout setting for request-response operations is not available in BPEL projects that support BPEL version 2.0. 14-8 Oracle Fusion Middleware Developers Guide for Oracle SOA Suite standard-elements receive This type uses the bpelx:for attribute to specify a static value or an XPath expression that must evaluate to an XML schema type duration. Only one of the bpelx:for or bpelx:until attributes is permitted for an activity. If the XPath expression evaluates to a negative duration, the timeout is ignored and an event is logged to the instance audit trail indicating that the duration value is invalid. Once a valid duration value is retrieved, the expiration date for the activity is set to the current node time or cluster time after this is available, plus the duration value. For example, the duration value bpelx:for=PT5M specifies that the activity expects an inbound message to arrive no later than five minutes after the activity has started execution. Timeout durations can only be specified on the following: ■ Midprocess receive activities ■ 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.2 Timeout Settings as an Absolute Date Time

You can specify a timeout setting as an absolute deadline for request-response receive activities. This type uses the syntax shown in Example 14–3 . Example 14–3 Timeout Settings as an Absolute Date Time receive bpelx:until=deadline-expr standard-elements receive The expected expiration time for the bpelx:until attribute must be at least two seconds ahead of the current time. Otherwise, the timer scheduling is ignored and skipped, just as if the timer was never specified. The bpelx:until attribute specifies a static value or an XPath expression that must evaluate to an XML schema type datetime or date. Only one of the bpelx:for or bpelx:until attributes is permitted for an activity. XPath version 1.0 is not XML schema-aware. Therefore, none of the built-in functions of XPath version 1.0 can create or manipulate dateTime or date values. However, it is possible to perform one of the following: ■ Write a constant literal that conforms to XML schema definitions and use that as a deadline value ■ Extract a field from a variable part of one of these types and use that as a deadline value XPath version 1.0 treats that literal as a string literal, but the result can be interpreted as a lexical representation of a dateTime or date value. 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 that activity.