Branches in flow, flowN, and forEach activities are executed serially in a single thread (that is, the Nth branch is executed only after N-1 execution has completed). Execution is not completely parallel. This is because the branches do not execute in concurrent threads in this mode. Instead, one thread starts executing a flow branch until it reaches a blocking activity (for example, an synchronous invoke). At this point, a new thread is created that starts executing the other branch, and the process continues. This creates the impression that the flow branches are executing in parallel. In this mode, however, if the flow branches do not define a blocking activity, the branches still execute serially.

This design is intended for several reasons:

• To prevent you from accidentally spawning too many threads and overloading the system, single threading is the default method. However, you can tune threads in other places, such as adapter polling threads, BPEL process service engine threads, and Oracle WebLogic Server work managers.

• The BPEL process specification does not provide a mechanism to ensure the thread safety of BPEL variables (that is, a lack of a synchronized qualifier such as in Java), which is necessary for true multithreaded programming.

• The implication of transaction rollbacks in one of the branches is undefined.

To achieve pseudo-parallelism, you can configure invoke activities to be nonblocking with the nonBlockingInvoke deployment descriptor property. When this property is set to true, the process manager creates a new thread to perform each branch's invoke activity in parallel.

For more information about the nonBlockingInvoke property, see How to Define Deployment Descriptor Properties in the Property Inspector.

1. In the Components window, expand BPEL Constructs > Structured Activities.
2. Drag a Flow activity into the designer.
3. Click the + sign to expand the flow activity, as shown in Figure 10-2.

   Figure 10-2 Flow Activity

   
   Description of "Figure 10-2 Flow Activity"

   The flow activity initially includes two branches, each with a box for functional elements. Populate these boxes as you do a scope activity, either by building a function or dragging activities into the boxes. You can add additional branches by highlighting the flow activity and clicking the Add Sequence icon. Figure 10-3 provides details.

   Figure 10-3 Add Sequence Icon

   
   Description of "Figure 10-3 Add Sequence Icon"
4. Drag and define additional activities on each side of the flow to invoke multiple services at the same time. Figure 10-4 provides details.

   Figure 10-4 Expanded Flow Activity

   
   Description of "Figure 10-4 Expanded Flow Activity"

   When complete, flow activity design can look as shown in Figure 10-5. This example shows the Retrieve_QuotesFromSuppliers flow activity. Two branches are defined for receiving bids: one for InternalWarehouseService and the other for PartnerSupplierMediator.

   Figure 10-5 Flow Activity After Design Completion

   
   Description of "Figure 10-5 Flow Activity After Design Completion"

A flow activity typically contains many sequence activities. Each sequence is performed in parallel. The following example shows the syntax for two sequences of the Retrieve_QuotesFromSuppliers flow activity in the OrderProcessor.bpel file after design completion. However, a flow activity can have many sequences. A flow activity can also contain other activities. In the following example, each sequence in the flow contains assign, invoke, and receive activities.

<flow name="Retrieve_QuotesFromSuppliers">
    <sequence name="Sequence_4">
        <assign name="Assign_InternalWarehouseRequest">
           <copy>
           <from>$inputVariable.gOrderInfoVariable/ns3:CardNum</from>
           <to>lInternalWarehouseInputVariable/ns4:ccnb</to>
         </copy>
        </assign>
        <invoke name="Invoke_InternalWarehouse"
            inputVariable="lInternalWarehouseInputVariable"
            partnerLink="InternalWarehouseService"
            portType="ns1:InternalWarehouseService"
            operation="process"/>
        <receive name="Receive_InternalWarehouse"
            createInstance="no"
            variable="lInternalWarehouseResponseVariable"
            partnerLink="InternalWarehouseService"
            portType="ns1:InternalWarehouseServiceCallback"
            operation="processResponse"/>
        <assign name="Assign_InterWHResponse">
            <bpelx:append>
                <bpelx:from variable="lInternalWarehouseResponseVariable"
                       part="payload"
                       query="/ns1:WarehouseResponse"/>
                <bpelx:to variable="gWarehouseQuotes"
                       query="/ns1:WarehouseList"/>
            </bpelx:append>
        </assign>
    </sequence>
    <sequence name="Sequence_4">
        <assign name="Assign_PartnerRequest">
            <copy>
                <from variable="gOrderInfoVariable"
                    query="/ns4:orderInfoVOSDO"/>
                <to variable="lPartnerSupplierInputVariable"
                    part="request" query="/ns4:orderInfoVOSDO"/>
            </copy>
        </assign>
        <invoke name="Invoke_PartnerSupplier"
            partnerLink="PartnerSupplierMediator"
            portType="ns15:execute_ptt" operation="execute"
            inputVariable="lPartnerSupplierInputVariable"/>
        <receive name="Receive_PartnerResponse"
            createInstance="no"
            variable="lPartnerResponseVariable"
            partnerLink="PartnerSupplierMediator"
            portType="ns15:callback_ptt" operation="callback"/>
            <assign name="Assign_PartnerWHResponse">
                <bpelx:append>
                    <bpelx:from variable="lPartnerResponseVariable"
                           part="callback"
                           query="/ns1:WarehouseResponse"/>
                           <bpelx:to variable="gWarehouseQuotes"
                           query="/ns1:WarehouseList"/>
                    </bpelx:append>
            </assign>
    </sequence>
</flow>

You can synchronize the execution of activities within a flow activity to ensure that certain activities only execute after other activities have completed. For example, assume you have an invoke activity, verifyFlight, that is executed in parallel with other invoke activities (verifyHotel, verifyCarRental, and scheduleFlight) when the flow activity begins. However, scheduling a flight is necessary only after verifying that a flight is available. Therefore, you can add a link between the verifyFlight and scheduleFlight invoke activities. Links provide a level of dependency indicating that the activity that is the target of the link (scheduleFlight) is only executed if the activity that is the source of the link (verifyFlight) has completed.

The following example provides details. The link name verifyFlight-To-scheduleFlight is assigned to the source verifyFlight and target scheduleFlight invoke activities. If the source verifyFlight completes execution, the target scheduleFlight is then executed.

<flow ...>
   <links>
      <link name="verifyFlight-To-scheduleFlight" />
   </links>
   <documentation>
      Verify the availability of a flight, hotel, and rental car in parallel
   </documentation>
   <invoke name="verifyFlight" ...>
      <sources>
         <source linkName="verifyFlight-To-scheduleFlight" />
      </sources>
   </invoke>
   <invoke name="verifyHotel" ... />
   <invoke name="verifyCarRental" ... />
   <invoke name="scheduleFlight" ...>
      <targets>
         <target linkName="verifyFlight-To-scheduleFlight" />
      </targets>
   </invoke>
</flow>

The preceding code provides an example of link syntax in BPEL version 2.0. The link syntax between BPEL version 1.1 and BPEL version 2.0 is slightly different.

• BPEL version 1.1 uses <target> and <source>.

• BPEL version 2.0 uses <targets> and <sources>.

Table 10-1 provides details.

<flow>
   <links>
     <link name="XtoY"/>
     <link name="CtoD"/>
   </links>
   <sequence name="X">
      <source linkName="XtoY"/>
      <invoke name="A" .../>
      <invoke name="B" .../>
   </sequence>
   <sequence name"Y">
      <target linkName="XtoY"/>
      <receive name="C" ...>
         <source linkName="CtoD"/>
      </receive>
      <invoke name="E" .../>
   </sequence>
   <invoke partnerLink="D" ...>
     <target linkName="CtoD"/>
   </invoke>
 </flow>

<flow>
      <links>
        <link name="AtoB"/>
      </links>
      <assign name="B">
        <targets>
          <target linkName="AtoB"/>
        </targets>
        <copy>
          <from>concat($output.payload,
            'B')</from>
          <to>$output.payload</to>
        </copy>
      </assign>
      <assign name="A">
        <sources>
          <source linkName="AtoB"/>
        </sources>
        <copy>
          <from>concat($output.payload,
           'A')</from>
          <to>$output.payload</to>
        </copy>
      </assign>
    </flow>

1. Create a flow activity. For information, see How to Create a Parallel Flow.
2. In the General tab of the Flow activity, click the Add icon.
3. Enter a name for the link, as shown in Figure 10-6.

   Figure 10-6 Link Name Creation

   
   Description of "Figure 10-6 Link Name Creation"
4. Click Apply, then OK.
5. Drag appropriate activities into the flow activity to define as the source with the same link name as defined in Step 3. The value of the link name of the source and target must be the same as the link name declared in the flow activity. For this example, an assign activity named A is defined as the source in Figure 10-7.

   Figure 10-7 Source Activity

   
   Description of "Figure 10-7 Source Activity"

   Each source activity can specify an optional Transition Condition as a safe guard for following the specified link. Click the row in this column to invoke the Browser icon for accessing the Expression Builder dialog for creating a condition. If the Transition Condition column is left blank, it is assumed to evaluate to true.

6. Define appropriate copy rules for the assign activity.
7. Click Apply, then OK.
8. Drag an additional activity into the flow activity to define as the target with the same link name as defined in Step 3. For this example, another assign activity named B is defined as the target in Figure 10-8.

   Figure 10-8 Target Activity

   
   Description of "Figure 10-8 Target Activity"
9. Define appropriate copy rules for the assign activity.
10. Click Apply, then OK.
11. Continue design of your BPEL process.

    When complete, design can appear similar to that shown in Figure 10-9.

    Figure 10-9 Three Flow Activities Synchronized with Links

    
    Description of "Figure 10-9 Three Flow Activities Synchronized with Links"

The following example shows the .bpel file after design is complete for three flow activities with links for synchronizing activity execution.

• Flow_1 shows a link between simple activities.

  Flow_1 includes a link named AtoB. The activity that is the target of the link, assign activity B, is only executed if the activity that is the source of the link, assign activity A, has completed.

• Flow_2 shows a link between simple activity and composite activity.

  Flow_2 also includes the link named AtoB. The activity that is the target of the link, assign activity B, is only executed if the activity that is the source of the link, scope activity scope1, has completed.

• Flow_3 shows a link between composite activities.

  Flow_3 also includes the link named AtoB. The activity that is the target of the link, sequence activity Sequence_1, is only executed if the activity that is the source of the link, scope activity scope2, has completed.

<!-- link between simple activities -->
<flow name=Flow_1>
      <links>
        <link name="AtoB"/>
      </links>
      <assign name="A">
        <sources>
          <source linkName="AtoB"/>
        </sources>
        <copy>
          <from>concat($output.payload, 'A')</from>
          <to>$output.payload</to>
        </copy>
      </assign>
      <assign name="B">
        <targets>
          <target linkName="AtoB"/>
        </targets>
        <copy>
          <from>concat($output.payload, 'B')</from>
          <to>$output.payload</to>
        </copy>
      </assign>
    </flow>

    <!-- link between simple activity and composite activity -->
    <flow name=Flow_2>
      <links>
        <link name="AtoB"/>
      </links>
      <scope name="scope1">
        <sources>
          <source linkName="AtoB"/>
        </sources>
        <assign name="A">
          <copy>
            <from>concat($output.payload, 'A')</from>
            <to>$output.payload</to>
          </copy>
        </assign>
      </scope>
      <assign name="B">
        <targets>
         <target linkName="AtoB"/>
        </targets>
        <copy>
          <from>concat($output.payload, 'B')</from>
          <to>$output.payload</to>
        </copy>
      </assign>
    </flow>

    <!-- link between composite activities -->
    <flow name=Flow_3>
      <links>
        <link name="AtoB"/>
      </links>
      <scope name="scope2">
        <sources>
          <source linkName="AtoB"/>
        </sources>
        <assign name="A">
          <copy>
            <from>concat($output.payload, 'A')</from>
            <to>$output.payload</to>
          </copy>
        </assign>
      </scope>
      <sequence name="Sequence_1>
        <targets>
          <target linkName="AtoB"/>
        </targets>
        <assign name="B">
          <copy>
            <from>concat($output.payload, 'B')</from>
            <to>$output.payload</to>
          </copy>
        </assign>
      </sequence>
    </flow>
  </sequence>

You can specify an optional join condition in target activities. The value of the join condition is a boolean expression. If a join condition is not specified, the join condition is the disjunction (that is, a logical OR operation) of the link status of all incoming links of this activity.

Oracle BPEL Designer does not provide design support for adding join conditions. To add a join condition, you must manually add the condition to the .bpel file in Source view in Oracle BPEL Designer.

The following provides an example of a join condition.

<flow>
   <links>
      <link name="linkStatus2"/>
   </links>
   <empty name="E2">
      <sources>
         <source linkName="linkStatus2">
            <transitionCondition>false()</transitionCondition>
         </source>
      </sources>
   </empty>
   <empty name="E2">
      <targets> 
         <joinCondition>bpws:getLinkStatus('linkStatus2')=true()</joinCondition>
         <target linkName="linkStatus2"/>
      </targets>
   </empty>
</flow>

You can use a forEach activity to process multiple sets of activities sequentially or in parallel. The forEach activity executes a contained (child) scope activity exactly N+1 times, where N equals a final counter value minus a starting counter value that you specify in the Counter Values tab of the For Each dialog. While other structured activities such as a flow activity can have any type of activity as its contained activity, the forEach activity can only include a scope activity.

When the forEach activity is started, the expressions you specify for the starting counter and final counter values are evaluated. Once the two values are returned, they remain constant for the lifecycle of the activity. Both expressions must return a value containing at least one character. If these expressions do not return valid values, a fault is thrown. If the starting counter value is greater than the final counter value, the contained scope activity is not performed and the forEach activity is considered complete.

During each iteration, the variable specified in the Counter Name field on the General tab is implicitly declared in the forEach activity's contained scope. During the first iteration of the scope, the counter variable is initialized with the starting counter value. The next iteration causes the counter variable to be initialized with the starting counter value, plus one. Each subsequent iteration increments the previously initialized counter variable value by one until the final iteration, where the counter is set to the final counter value. The counter variable is local to the enclosed scope activity. Although its value can be changed during an iteration, that value is lost after each iteration. Therefore, the counter variable value does not impact the value of the next iteration's counter.

The forEach activity supports the following looping iterations:

• Sequential (default)

  The forEach activity performs looping iterations sequentially N times over a given set of activities defined within a scope activity. As an example, the forEach activity iterates over an incoming purchase order message where the purchase order message consists of N order items. The enclosed scope activity must be executed N+1 times, with each instance starting only after the previous iteration has completed.

• Parallel

  All looping iterations are started at the same time and processed in parallel. Parallel iterations are useful in environments in which sets of independent data are processed or independent interaction with different partners is performed in parallel. To enable parallel looping, you select the Parallel Execution check box on the General tab. In these scenarios, execution of the N+1 instances of the contained scope activity occurs in parallel. Each copy of the scope activity has the same counter variable that you specify in the Counter Name field of the General tab declared in the same way as specified for a sequential forEach activity. Each instance's counter variable must be uniquely initialized in parallel with one of the integer values beginning with the starting counter value and proceeding up to and including the final counter value.

  Unlike a flow activity, the number of parallel branches is not known at design time with the forEach activity. The specified counter variable iterates through the number of parallel branches, controlled by the starting counter value and final counter value.

You can also specify a completion condition on the Completion tab. This condition enables the forEach activity to execute the condition and complete without executing or finishing all the branches specified. As an example, you send out parallel requests and a sufficient subset of the recipients have responded. A completion condition is optionally specified to prevent the following:

• Some children from executing (in the sequential case)

• To force early termination of some of the children (in the parallel case)

If you do not specify a completion condition, the forEach activity completes when the contained scope has completed.

If a premature termination occurs (due to a fault or the completion condition evaluating to true), then the N+1 requirement does not apply.

The following example shows the forEach activity syntax.

<forEach counterName="MyVariableName" parallel="yes|no"
   standard-attributes>
   standard-elements
   <startCounterValue expressionLanguage="anyURI"?>
      unsigned-integer-expression
   </startCounterValue>
   <finalCounterValue expressionLanguage="anyURI"?>
      unsigned-integer-expression
   </finalCounterValue>
   <completionCondition>?
      <branches expressionLanguage="anyURI"?
         successfulBranchesOnly="yes|no"?>?
         unsigned-integer-expression
      </branches>
   </completionCondition>
   <scope ..>...</scope>
</forEach>

In the flow activity, the BPEL code determines the number of parallel branches. However, often the number of branches required is different depending on the available information. The flowN activity creates multiple flows equal to the value of N, which is defined at runtime based on the data available and logic within the process. An index variable increments each time a new branch is created, until the index variable reaches the value of N.

The flowN activity performs activities on an arbitrary number of data elements. As the number of elements changes, the BPEL process service component adjusts accordingly.

The branches created by flowN perform the same activities, but use different data. Each branch uses the index variable to look up input variables. The index variable can be used in the XPath expression to acquire the data specific for that branch.

For example, suppose there is an array of data. The BPEL process service component uses a count function to determine the number of elements in the array. The process then sets N to be the number of elements. The index variable starts at a preset value (zero is the default), and flowN creates branches to retrieve each element of the array and perform activities using data contained in that element. These branches are generated and performed in parallel, using all the values between the initial index value and N. The flowN activity terminates when the index variable reaches the value of N. For example, if the array contains 3 elements, N is set to 3. Assuming the index variable begins at 1, the flowN activity creates three parallel branches with indexes 1, 2, and 3.

The flowN activity can use data from other sources as well, including data obtained from web services.

Figure 10-15 shows the runtime flow of a flowN activity in Oracle Enterprise Manager Fusion Middleware Control that looks up three hotels. This is different from the view, because instead of showing the BPEL process service component, it shows how the process has actually executed. In this case, there are three hotels, but the number of branches changes to match the number of hotels available.

Figure 10-15 Oracle Enterprise Manager Fusion Middleware Control View of the Execution of a flowN activity

Description of "Figure 10-15 Oracle Enterprise Manager Fusion Middleware Control View of the Execution of a flowN activity"