Business Process and Data Transformation Language Reference
<flow>
[Back] [Next]
   
Server:docs2
Instance:LATEST
User:UnknownUser
 
-
Go to:
Search:    

Perform activities in a non-determinate order.
Synopsis
<flow>
  <sequence name="thread1">
    ...
  </sequence>
  <sequence name="thread2">
    ...
  </sequence>
  ...
</flow>
Details
Attribute or Element Description
name, disabled, xpos, ypos, xend, yend attributes See Common Attributes and Elements.”
<annotation> element
<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 the <assign> element in this book, 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.