This section provides information about the run-time behavior
of processes:
Process instances
Each time a process is initiated, the
AEM forms Server executes the process. Each execution of a process
is called a
process instance
. Process instances have a unique
identification and have their own process data associated with them.
For example, a process creates a credit card statement by retrieving
information from a database, merging it with a form, and printing
the statement to be mailed to a customer. The process is initiated
monthly for each customer. Each time the process is initiated, a
new process instance is created. The process data includes the information
that is retrieved from the database, which is different for each customer.
Process modifications
When you make changes to an activated process,
the changes affect all process instances that are associated with
it.
For example, you initiate several processes in the development
environment to test the process you are creating. You then make
a change to the properties of an operation on the process diagram.
When you save the changes, they affect all process instances that
have not yet progressed past that operation.
Process life cycle
When a process is initiated and the process instance is
created, a branch instance is created for the main branch of the
process. Subsequently, the operations that belong to the branch
are executed in series, according to the design of the process.
When the execution of an operation is complete, the routes that
begin at that operation are evaluated. The route evaluation determines
which operation is executed next. When all of the operations in
a branch are complete, the branch is complete.
If an error occurs when a route is being evaluated, the branch
to which the route belongs is stalled. If an error occurs when an
operation is executing, the operation is stalled. When a branch
or operation is stalled, you can take measures to fix the cause
of the error and use administration console to restart the branch or
operation.
Short-lived processes and long-lived processes
The
Type property of processes can be set to long-lived or short-lived.
In general, short-lived processes require less server resources
at run time than long-lived processes. Configure processes to be
short-lived when possible.
However, the value you specify affects how the process executes
and the data that it saves at run time. It also determines the type
of the main branch of the process and the type of branches that
you can add to the process diagram by using gateway elements. You
need to consider all of these factors when configuring the Type
of the process.
Note:
The value stored in the
id
node
of the process data model is always -1 for short-lived processes.
For long-lived processes, the value is an alphanumeric string. (See
Process data model
.)
Execution
The
amount of time that it takes to execute a process is a factor that
you need to consider when configuring the Type property:
-
Configure your process to be short-lived if it takes very
little time to execute (in the order of milliseconds). Short-lived
processes are executed in a single transaction (see
Transactions
).
Shorter execution times lower the risk of a system failure occurring
during the transaction.
-
Configure your process to be long-lived if one or more operations
requires a long time to execute. Each operation in a long-lived
process is executed in a separate transaction.
-
You need to configure your process to be long-lived if the
progression of the process depends on messaging from resources that
act independently (outside) of process execution (asynchronous execution).
For
example, processes that use the User service or event receivers
should be configured as long-lived:
-
The User service’s Assign Task operation is complete only
after a user submits the associated task using Workspace.
-
Event receivers and event start points wait for events to
be thrown before the process continues.
Client invocation
The Type property of the process affects how
client software interacts with the process instance:
-
When client software invokes short-lived process, the client
software waits until the process instance is complete before continuing
with its execution. When the process instance is complete, it returns
the process output data to the client immediately.
-
When client software invokes long-lived processes, the client
software continues its execution immediately as the process instance
is executing. The client software needs to retrieve the process
output data after the process is complete.
Data persistence
The Type property of the process determines
the process data that is saved in the database. If your process
passes data between operations, the data needs to be stored in the
database. Also, your organization’s policies may dictate that it
is important to keep a record of everything that occurred during
the process instance. In other cases, you may decide that saving
storage space is more important than keeping detailed records:
-
Configure the process to be long-lived if you need to pass
data between operations or if you want to keep a complete record
of the process instance.
-
Configure the process to be short-lived if no data is passed
between operations or you do not want to keep a record of the process
instance.
process type
|
Information stored
|
Long-lived
|
All process information is stored:
-
Process instance data
-
Branch instance data
-
Operation instance data
|
Short-lived
|
No process information is stored.
|
Note:
Because short-lived processes
do not store information in the database, fewer resources are required
at run time, causing them to execute more efficiently.
Branch types
Long-lived and short-lived processes support different
branch types:
-
Short-lived processes support only transactional
branches. The main branch in short-lived processes is a transactional
branch.
-
Long-lived process support asynchronous, synchronous, and
transactional branches.
Note:
You cannot add gateway
elements to short-lived processes. If you want to execute two or
more branches in parallel, you need to use a long-lived process.
Transaction Propagation
For short-lived processes, transaction propagation specifies
whether the process executes in its own transaction or whether it
executes in the transaction of the client software that initiated
the process. The following values can be specified for the transaction
propagation of a process:
-
Mandatory:
-
The process instance executes within the client's transaction.
If the client is not associated with a transaction, an exception
occurs.
-
Never:
-
An exception occurs if the client is running within a transaction.
If the client is not associated with a transaction, a transaction
is not created for running the process.
-
Not Supported:
-
The client’s transaction is suspended while the process instance
executes. When the process instance is complete, the client’s transaction
resumes. If the client is not associated with a transaction, a new
transaction is not created.
-
Required:
-
The process instance executes within the client's transaction.
If the client is not associated with a transaction, a new transaction
is created for running the process.
-
Requires new:
-
The client’s transaction is suspended. The process instance
is executed in a new transaction. When the process instance is complete,
the client’s transaction resumes. If the client is not associated
with a transaction, a new transaction is created for running the
process.
-
Supports:
-
The process instance executes within the client's transaction.
If the client is not associated with a transaction, a new transaction
is not created for running the process.
The Transaction Timeout
property of a process determines the amount of time that transactions
have to complete execution before timing out.
|
|
|