Skip to main content

<flow>

Perform activities in a non-determinate order.

Syntax

<flow>
   <sequence name="thread1">
     ...
   </sequence>
   <sequence name="thread2">
     ...
   </sequence>
   ...
</flow>

Attributes and Elements

name, disabled, xpos, ypos, xend, yend attributes
<sequence> element

Optional. Zero or more <sequence> elements contain whatever activities are needed for the <flow>. If no <sequence> elements are provided, no action is taken by the <flow>.

Description

The <flow> element specifies that each of the elements it contains are executed in a non-determinate order. A <flow> element contains one or more <sequence> elements, each of which is referred to as a thread.

When you are using the Business Process Designer and you add a <flow> element to the business process, a <sequence> element is automatically inserted inside the <flow>, as you can see by examining the generated BPL code.

If you need to temporarily disable one of the <sequence> elements within a <flow>, you can edit the generated BPL code by setting the disabled attribute of the corresponding <sequence> element.

The following abbreviated example shows the usage of the <flow> element. In this hand-coded BPL example, the developer has decided to use two parallel sequences inside the flow. Each is executed in a separate thread: thread1 and thread2.

<process>
  <flow>
    <sequence name="thread1">
      <call name="A" />
      <call name="B" />
    </sequence>
    <sequence name="thread2">
      <call name="C" />
      <call name="A" />
    </sequence>
  </flow>
  <call name="E" />
</process>

In this example, the <flow> element defines two threads, specified by <sequence> elements thread1 and thread2. The order in which the two threads are executed is indeterminate (though, of course, the <call> elements within the <sequence> elements are executed in sequential order).

If possible, the execution of threads is interlaced. For example, if the execution of one thread is suspended (say it is waiting for a response from a asynchronous call), then execution of one of the other threads proceeds (if possible).

Note that, strictly speaking, the threads within a <flow> element do not execute at the same time: this is because only one thread is given access to the business process execution context at a time, to preserve proper concurrency and data consistency.

Note:

For more information about the business process execution context, see <assign> , and see Developing BPL Processes.

The <flow> element waits for all of its threads to complete before it allows execution to continue. After both threads in the previous example are completed, execution continues and <call> element E is executed.

A thread within a <flow> element may contain additional, nested <flow> elements.

For information about using <sync> with <flow>, see documentation of the <sync> element.

FeedbackOpens in a new tab