Showing posts from March, 2015

SOA Dehydration Process

Oracle BPEL Process Manager uses the dehydration store database to maintain long-running asynchronous processes and their current state information in a database while they wait for asynchronous callbacks. Storing the process in a database preserves the process and prevents any loss of state or reliability if a system shuts down or a network problem occurs. There are two types of processes in Oracle BPEL Process Manager. These processes impact the dehydration store database in different ways. Transient  processes: this process type does not incur any intermediate dehydration points during process execution. If there are unhandled faults or there is system downtime during process execution, the instances of a transient process do not leave a trace in the system. Instances of transient processes cannot be saved in-flight (whether they complete normally or abnormally). Transient processes are typically short-lived, request-response style processes. Durable processes : this p

BPEL - CallBack Message Handling

BPEL engine maintains all Async call back messages into database table called dlv_message. Wecan see such all messages in BPEL console call-back manual recovery area.The query being used by bpel console is joined on dlv_message and work_item tables.This query simply picks up all call back messages which are undelivered and have not been modified with in certain threshold time. Call-back messages are processed in following steps BPEL engine assigns the call-back message to delivery service Delivery service saves the message into dlv_message table with state 'UNDELIVERED-0' Delivery service schedules a dispatcher thread to process message asynchronously Dispatcher thread enqueues message into JMS queue Message is picked up by MDB MDB delivers the message to actual BPEL process  waiting for call-back and changes state to 'HANDLED=2' So given above steps, there is always possibility that message is available in dlv_message table but MDB is failed in deliverin