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