Business Process and Data Transformation Language Reference
Perform activities in a non-determinate order.
<flow> <sequence name="thread1"> ... </sequence> <sequence name="thread2"> ... </sequence> ... </flow>
|Attribute or Element
|name, disabled, xpos, ypos, xend, yend attributes
||See ““Common Attributes and Elements.””
||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.
<call name="A" />
<call name="B" />
<call name="C" />
<call name="A" />
<call name="E" />
In this example, the <flow> element defines two threads, specified by <sequence> elements thread1
. The order in which the two threads are executed is indeterminate (though, of course, the <call>
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>
Content Date/Time: 2019-10-14 06:57:37