|
You add elements to a
branch by drawing routes from an operation, event, or activity to
the gateway or existing branch elements. Use the tools and methods you
use for other parts of the process diagram to add, remove, and change
the sequence of branch elements as required. (See
Drawing routes to link operations
.) You can add any number of elements
to a branch.
You can drag one end of the gateway element to
increase the distance between the two ends. Increasing the distance
creates space for multiple branches and elements.
You can modify the routes connected to the start and end of the
gateway using the methods used for regular routes. For example,
you can change which operation is executed first by dragging the
anchor for the first route in the branch to a different operation.
However, when you connect an element to the end of the gateway,
if no route connects the branch elements to the start of the gateway,
one is added automatically.
If you do not provide a final route to connect the branch to
the end of the gateway, one is added automatically the next time
you open the process.
To change which operation is executed first:
In the
branch, right-click the operation to execute first and select Set
Start Activity.
Validating routes used by gateway branches
When you add routes to gateway branches, an error icon
appears when you attempt to draw invalid routes. For example, you
cannot create a route that connects a branch activity to an element
outside its branch. Routes that connect elements in different branches
are also invalid.
Additional route validation information appears in the Validation
Report view. For example, a message appears in the Validation Report
view if a branch within a gateway is incomplete. (See
Validation reports
).
Operation and branch compatibility
Not all operations are compatible with all
branch types. Operation and branch compatibility may help you to
decide the type of branch that you should use in your process.
Note:
You use gateways to add additional branches
to a process.
|
Branch type
|
Compatible operations
|
|
Asynchronous
|
All operations
|
|
Synchronous
|
All operations
|
|
Transactional
|
Set Value, Stall, and Execute Script service
operations
|
Note:
The operations of the User, Wait Point, and
Execute Script services, as well as gateway elements, cause synchronous
branches to behave as asynchronous branches.
Transactions
A
transaction
is
a context in which one or more operations are executed. Generally,
the operations that are executed within a transaction are not committed
until all of the operations are executed successfully. If one operation in
a transaction fails to execute successfully, the transaction is
rolled back and the effects of any operations that were already
executed in that transaction are reversed.
In Transactional branches, the operations in a branch are executed
in a single transaction. In an Asynchronous or Synchronous branch,
each operation is executed in separate transactions.
Transactions and branches
Transactional
branches are useful when a common goal is dependent on the successful
execution of a series of operations. If an operation in a transactional branch
executes with errors, the branch is stalled. When the branch is
retried, the transaction for the branch is rolled back and the first
operation in the branch is executed again.
For information about the behavior of actions in Transactional
branches, see
Transactions and operations
.
Asynchronous and synchronous branches are useful when the failure
of one operation in the branch does not devalue the successful execution
of previous actions in the branch. If an operation in an Asynchronous
or Synchronous branch executes with errors, the branch is stalled.
When the branch is retried, only the failed operation is rolled
back and the operation is executed again.
Branch behavior when errors occur
The behavior of a branch when
a stalled branch or a stalled operation is retried is a factor to
consider when deciding which type of branch to use in your process.
For
all branch types, when a branch exception occurs, the branch is
stalled and, when an operation exception occurs, the operation for
which the exception occurred is stalled.
The following table
describes how the different branch types continue execution after
the forms workflow administrator retries the stalled branch
or operation.
|
Branch type
|
Behavior when a stalled branch or operation
is retried
|
|
Asynchronous
|
The process continues from the point in
the process where the exception occurred.
|
|
Synchronous
|
The process continues from the point in
the process where the exception occurred.
|
|
Transactional
|
The branch is rolled back, and the process
continues from the first operation in the branch.
|
Transactions and operations
Operations
are handled differently in transactions, depending on whether the operations
are transaction-aware and long-lived.
Transaction-aware operations
Operations that are transaction-aware will
participate in a transaction. When a Transactional branch is rolled
back, the operations in the branch that are transaction-aware are
returned to their original state before that branch was executed.
If
an operation is not transaction-aware and it is used in a Transactional
branch that stalls, the effects of the operation are not rolled
back when the branch is retried. The operations are executed a second
time. For example, if you use the Email operation in a Transactional
branch, each time the branch stalls and is retried, another email
is generated.
The only transaction-aware operation that Foundation
provides is the execute operation of the Set Value service. However,
your development team may create transaction-aware operations using
the AEM forms SDK.
Long-lived operations
Long-lived operations execute independently
of the branch to which they belong:
-
When a Transactional
branch is stalled and is retried, any long-lived operations in the
branch continue to run and are not rolled back.
-
If a computational error occurs during the execution of a
long-lived operation, the operation is stalled, but the branch is
not stalled even if the operation belongs to a Transactional branch.
None
of the operations that Foundation provides are long-lived. However,
your development team may create long-lived operations using the
AEM forms.
|
|
|
