Process execution

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.

New processes

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.

// Ethnio survey code removed