Oracle BPEL Process Manager Request Flow and Recovery

5-16 Oracle Fusion Middleware High Availability Guide External Dependencies The BPEL engine system depends on the following components: ■ SOA Service Infrastructure database for BPEL process state persistence ■ MDS repository for BPEL process metadata store Both components must be available for the BPEL engine system to start and run properly.

5.3.1.2 Oracle BPEL Process Manager Startup and Shutdown Lifecycle

As illustrated in Figure 5–9 , when the Oracle SOA Service Infrastructure application starts, it initializes the BPEL engine and loads the composites from the MDS repository. If the composite contains any BPEL processes, it targets those individual components to the BPEL engine. Once the process is loaded, the system is available to receive requests. At runtime, the BPEL engine waits for requests from different channels, such as JMS, the database, and HTTP. Figure 5–9 Startup and Shutdown Lifecycle of Oracle BPEL PM A detailed startup and shutdown lifecycle is as follows: 1. Start SOA Server. 2. Start BPEL Engine. 3. Composites are loaded from MDS repository by SOA Service Infrastructure. 4. BPEL components are dispatched to the BPEL engine to be loaded. 5. Composite-binding components are activated. 6. The BPEL engine services requests. 7. The shutdown signal is received by SOA Service Infrastructure. 8. SOA Service Infrastructure starts undeploying loaded composites. 9. Composite-binding components are disabled. 10. BPEL components are dispatched to the BPEL engine to be unloaded. 11. The BPEL engine shuts down.

5.3.1.3 Oracle BPEL Process Manager Request Flow and Recovery

Recoverable activities are activities that have failed and can be recovered. For example, if you are using the file adapter to initiate an asynchronous BPEL process and your system crashes while the instance is processing, you can manually perform recovery when the server restarts to ensure that all message records are recovered. Access MDS and load Composites Start BPEL Engine Target BPEL Process to BPEL engine Wait for requests to components Place request in Dispatcher’s queue Process unit of work Configuring High Availability for Oracle Fusion Middleware SOA Suite 5-17 There are 2 types of BPEL Processes based on the invocation interface: ■ One-Way : Most commonly asynchronous fire-and-forget pattern. ■ Two-Way : Synchronous request-response pattern. The recovery semantics after a server failure are based on whether the process is invoked synchronously and asynchronously. The following describes the behavior based on invocation and process type: ■ Synchronous Invocation Request : For synchronous requests, an error is thrown back to the client in the case of a server failure. It is the clients responsibility to handle the error message and take appropriate action such as retrying the request. This holds true for both Transient and Durable processes. ■ Asynchronous Invocation Post : There are two types of asynchronous invocations - one that starts a new process and one that is a callback to an existing process. In the case of a callback, the engine after recognizing that it is a continue operation attempts to resolve the subscribing process, first by conversation ID, and then by a correlation set if defined. Messages associated with asynchronous requests are persisted to the dehydration store as part of the client call. If there is a failure prior to the persistence, the client receives an error message and has to handle the error in the same way as an error for a synchronous invocation. If the persistence is successful, the client call returns and further processing is done outside the context of the client call. In the case of a server failure, one-way processes that were invoked asynchronously can be restarted using Enterprise Manager. Note: In the case of durable processes, the message is persisted to the dehydration store at certain points. It is possible to recover the message from the dehydration store and replay the process using Enterprise Manager, however, the client cannot be notified of the response. Therefore, this is not a recommended option. It is preferable to handle all recovery from the client. 5-18 Oracle Fusion Middleware High Availability Guide Figure 5–10 Enterprise Manager BPEL Engine Recovery See the Oracle Fusion Middleware Administrator’s Guide for Oracle SOA Suite and the Oracle Fusion Middleware Developers Guide for Oracle SOA Suite for details on the synchronous and asynchronous models supported by BPEL engine.

5.3.1.4 Oracle BPEL Process Manager Configuration Artifacts