Process Control Run-Time Considerations
This section outlines some of the run-time issues you must consider when you are invoking a Process control in your business process. When you are invoking a Process control from a parent business process, you are making a Java Remote Method Invocation (RMI) to the subprocess. The transfer of information is governed by RMI rules and not by serialization rules.
The topics covered in this section are:
Run-Time Rules for Process Controls in Stateless and Stateful Business Processes
The number of transactions contained in a business process determines whether the process is stateless or stateful. For more information, see Building Stateless and Stateful Processes. This section covers some of the run-time issues you should consider when using a Process control in stateless and stateful business processes.
The following rules govern the run-time operation of Process controls in stateless and stateful business processes:
- In a stateless business process, the invocation from the parent business process generically picks any stateless subprocess and can call any method from the Process control on the parent business process.
- In a stateful business process the first instantiation has to be a start method.
- In a stateful business process, the subprocess selected depends on the method specified by the Process control. A new process instance is created based on the method specified by the Process control and a new conversation ID is assigned to the process instance. You can specify the conversation ID. If you don't specify a conversation ID, the instance automatically generates its own conversation ID. For more information on conversations, see Designing Conversational Web Services. For more information on specifying the conversation ID, see "ProcessControl Interface" in com.bea.control Package.
- In a stateful business process, once a call is invoked and a converstaion ID generated, any further continue methods that are invoked, interact with the original conversation ID. You need to specify a new start method to invoke an interaction with a new conversation ID.
Run-Time Rules for Process Controls in Synchronous and Asynchronous Business Processes
Business processes can have both synchronous or asynchronous request methods. For more information, see Building Synchronous and Asynchronous Business Processes. This section covers some of the run-time issues you should consider when using a Process control in synchronous and asynchronous business processes.
The following rules govern the run-time operation of Process controls in synchronous and asynchronous business processes:
- A synchronous subprocess called through a Process control runs in the same transaction as its caller (parent) process. Synchronous subprocesses behave differently than asynchronous subprocesses, particularly when it comes to unhandled exceptions.
- When an error occurs in synchronous business processes, exceptions are raised. An unhandled exception in a subprocess causes the shared transaction to be marked as rollback only, which causes the subprocess and parent processes to roll back. This is the default behavior because it prevents a scenario in which one of the processes is rolled back, leaving the other process in an inconsistent or uncompensated state. You can override this default behavior by changing the value of the on sync failure property specified in the Property Editor of the subprocess. The available options are rollback and rethrow. The rethrow option returns an error to the parent process when an exception occurs. To override the default behavior, change the on sync failure property from rollback to rethrow.
- In asynchronous business processes, the transaction is never propagated to the subprocess. In other words, the subprocess runs in its own transaction. The parent business process uses Java Message Service (JMS) to drop the messages into a JMS queue. Once the parent process drops the message into the queue, it assumes that message delivery is successful. If an error occurs on the subprocess, the parent process is not informed of the error. For information on enhancing your business process so that you can detect failures, see "Asynchronous Subprocesses" in Building Synchronous and Asynchronous Business Processes.
- In asynchronous business processes, the parent business process continues to execute until the process finishes or until the process receives a callback from the subprocess. The callback is always associated with the process instance initially created by the parent business process.
- In a synchronous business process, once the parent process invokes a message request to the subprocess, through the Process control, it finishes.
- In an asynchronous business process, once the parent process invokes a message request to the subprocess, through the Process control, it continues to instantiate and make further requests to the subprocess. If the subprocess does not have time to respond to the request from the parent process before it receives a second request, the second request will be dropped and the subprocess won't receive it at all. For this reason, you should design the parent process so that is blocks and waits for a callback from the subprocess before taking further action. For an example of using an Event Choice node to perform this function, see "Asynchronous Subprocesses" in Building Synchronous and Asynchronous Business Processes.
- The com.bea.control JwsContext interface provides access to container services that support Web services (JWS files). For more information, see "com.bea.control JwsContext Interface" in com.bea.control Package. The setCallbackLocation() method is not supported for Process control callbacks.
Security
The Process control conforms to all standard security checks associated with Java Remote Method Invocation (RMI). SSI is not supported. For more security information, see Security.
Related Topics
Building Stateless and Stateful Business Processes
Building Synchronous and Asynchronous Business Processes
Security