Oracle OSB-SOA-BPEL Interview Question and Answer – Part 10

In this article, we will discuss interview question with their justification on Oracle OSB, SOA and BPEL

This is part-10 of Oracle OSB-SOA-BPEL interview question series

Q) What is Dehydration store ?

  • Dehydration store is the database where the instances get stored when it gets dehydrated by the process on the occurrence of non-idempotent activities and also stores the information on the long running processes

Q) What is dehydration storage table ?

  • Dehydration store is the database where BPEL engine stores all BPEL processes metadata and run time instance data. This data store is installed under db schema- ORABPEL
  • Meta data includes BPEL process descriptor (bpel.xml), human task modeling data etc…
  • Run time instance data includes process instance records, process activities execution data, invoke and call back xml messages etc.

Q) What is transient and durable BPEL ?
Q) What is Dehydration in Oracle BPEL ?

Transient process:

  • Oracle BPEL Server dehydrates the process instance only once at the end of the process
  • When a host crashes in the middle of running the process instance, the instances are not visible from Oracle BPEL Control

Durable process:

  • Oracle BPEL Server dehydrates the process instance in-flight at all mid-process breakpoint and non-idempotent activities, plus the end of the process
  • When the server crashes, this process instance appears in Oracle BPEL Control up to the last dehydration point (breakpoint activity) once the server restarts
  • If the server crashes before the process instance reaches the first mid-process breakpoint activity, the instance is not visible in Oracle BPEL Control after the server restarts

e.g.: Receive activity, OnMessage branch in a pick activity, OnAlarm branch in a pick activity & Wait activity

  • Dehydration can be forced in several ways
  • adding check points
  • by setting the idempotent property to false
  • adding mid receive activity – if the process needs to wait for an event

Below are the BPEL properties that determine how much data to be saved to the database during dehydration process

Q) What are the BPEL properties that determine how much data to be saved to the database during dehydration process ?

inMemoryOptimization:

  • Applicable only for TRANSIENT BPEL Process
  • When property inMemoryOptimization = true, then process maintained in memory until process completes
  • Dehydration doesn’t occurs for this kind of process

completionPersistLevel:

  • Controls what type of data is saved after process completion
  • Works only when property inMemoryOptimization = true
  • When completinPersistLevel = all, saves final variable, audit data, work_item data
  • When completinPersistLevel = instanceHeader, saves instance metadata

completionPersistPolicy:

  • Controls when to persist the instance
  • When property set to
  • Faulted – only faulted instances are saved
  • On – all the instances are saved
  • Off – nothing gets saved
  • Deferred – finished instances are saved
  • Server fails – some instances may be saved

The above three properties are used together. If used properly, this can reduce the database growth as well as increase the throughput.

Q) What is Idempotent ?

  • applicable to BPEL activities
  • When set to false, the BPEL process is dehydrated after this activity
  • If the server crashes after this, the activity is not executed as it is already recorded in the database as executed

Q) What do you mean by non-idempotent activity ?
Q) Which all activities is non-idempotent by default ?

  • All retriable activities are idempotent by default
  • If idempotent is set to be false then it is a start of new transaction and in other words a Dehydration point is created
  • Example: receive, pick, wait, checkpoint() are non-idempotent by default

Q) What is the use of work_item table ?

  • Stores activities created by an instance
  • All activities in a BPEL flow have a work_item table
  • This table includes the metadata for the activity (current state, label, and expiration date (used by wait activities))
  • When the engine needs to be restarted and instances recovered, pending flows are resumed by inspecting their unfinished work items

Q) Is it possible to use MS SQL Server as dehydration store with SOA Suite ? If yes how ?

  • Yes it is possible
  • To automatically maintain long-running asynchronous processes and their current state information in a database while they wait for asynchronous callbacks, you use a database as a dehydration store
  • 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
  • This feature increases both BPEL process reliability and scalability. You can also use it to support clustering and failover

Q) How can we clear the instances using dehydration database ?
Q) Purging Dehydration Store ?

There are several ways to purge large amounts of instances in SOA Suite 11g database – dehydration storage;

  1. By dropping the SOA Suite repository and next, to recreate it using RCU creation utility providing exactly the same credentials.
  2. By executing a set of existing database procedures delivered by Oracle (fixed in SOA Suite 11.1.1.3.0 PS2).
  3. By truncating several tables in BPEL SOAINFRA schema. (TRUNCATE TABLE CUBE_INSTANCE DROP storage)
  4. Perform maintenance to free up some space in database storage

Q) Difference between XA & Non-XA transaction ?

Non-XA (Local Transaction):

  • It involves only one resource
  • When you use Non-XA transaction then you can’t involve multiple resources (different databases, Queues, application servers etc), you can rollback or commit transaction for only one resource
  • There is not transaction manager for this transaction as we are dealing with only one resource at a time

XA (Global Transaction):

  • It involves more than one resource (different databases, queues, application servers) all participate in one transaction
  • It uses two-phase commit to ensure that all resources either all commit or rollback any particular transaction
  • When you have scenario like you need to connect to two different databases, JMS Queue and application server, in this case you will use XA transaction that means all resource participate in one transaction only

 Q) How do we handle transactions in BPEL ?

  • Property needs to be defined to start the new transaction/to continue with the same transactions
  • Property Name: Transaction and if this has value as required then the BPEL process will be continued in the same transaction where as if the value is defined as requiresnew then it will start the new transaction

Q) What is the default level of transaction in a composite <required | requiredNew> ?

  • default is required

 

Folks, it’s your turn to comment & suggest for improvement

Note: We have taken inputs from various folks and other weblog for making this comprehensive set of Oracle SOA-OSB interview & answers

 

Read Also:

 

Happy Coding !!
Happy Learning !!

Oracle OSB-SOA-BPEL Interview Question and Answer - Part 11
Oracle OSB-SOA-BPEL Interview Question and Answer - Part 9