IBM BPM, V8.0.1, All platforms > Get started with IBM BPM > Key concepts > BPEL processes and human tasks > BPEL processes overview > Transactional behavior of BPEL processes
Transactional behavior of microflows
Microflows are short-lived BPEL processes. They can run either in a transaction, or in an activity session as specified on the SCA component of the microflow. Microflows that are executed as part of a transaction are explained here.
Microflows are not interruptible. Therefore, a microflow cannot contain activities that wait for an external event, or for a user interaction, for example, human task activities.
Microflows are transient. The process instance state of a microflow is held in memory, and not stored in the runtime database. However, the state of a microflow instance can be persisted in the audit log or in Common Base Events.
The services inside the transaction boundary participate in the microflow transaction; those outside the boundary do not participate in the transaction.
Invoked services and microflow transactions
A microflow runs in one transaction. The services the microflow invokes can involve more than one transaction.
A service called through an invoke activity can either...
- participate in the transaction of the microflow
- run in its own transaction
...depending on...
- The interaction style used to call the service. Interaction style is determined by...
- The preferred style of the target SCA component or import
- Whether the operation is one-way or request-response
Style One-way Request-response Any Asynchronous invocation Synchronous invocation Synchronous Synchronous invocation Synchronous invocation Asynchronous Asynchronous invocation Synchronous invocation The invocation from a microflow of a request-response operation with a preferred interaction style of "asynchronous" is an example of an antipattern for service invocation. When the invoked service is a long-running process, the microflow transaction can time out before the long-running process completes, and a runtime error occurs.
- The SCA transaction qualifiers that are specified for the process and the service that is called:
- The suspendTransaction qualifier on the reference of the process component specifies whether the transaction context of the process is propagated to the services to be invoked.
- The joinTransaction qualifier on the service interface specifies whether a service participates in the transaction of its caller if a transaction is propagated.
Based on these settings, the following rules apply to the invoked service:
- Synchronous invocation
joinTransaction suspendTransaction = true suspendTransaction = false joinTransaction = true The service does not participate in the microflow transaction The service participates in the microflow transaction joinTransaction = false The service does not participate in the microflow transaction The service does not participate in the microflow transaction If a service participates in a microflow transaction, the changes that are made by the service to the transactional resources are persisted only if the microflow transaction commits. If a service does not participate in the microflow transaction, the changes that are made by the service to the transactional resources might be persisted even if the transaction is rolled back. You can use compensation to undo the changes made by the service.
- Asynchronous invocation
- The service always runs in its own transaction. To ensure that the sending of the asynchronous SCA message participates in the current navigation transaction, the asynchronousInvocation qualifier of the microflow must be set to commit.
Transactional behavior of BPEL processes
Related concepts:
Compensation handling in BPEL processes