Deployment over different environments

Use ORAMDS for all XSD / WSDL files on the project (oramds:...) in all composite.xml and wrappers in location tag. Doing that you will guarantee that you can deploy anywhere even when you don't have remote access to a environment. 

Also, in this way it is not necessary to change endpoints in composite.xml during compilation time (by script for instance) then use configuration plans.

Cheers!!

BPEL Transaction and Delivery Policies

BackgroundTransaction context between different BPEL services are controlled by mainly two properties/attributes.  Those are Delivery and Transaction attributes.  

Details

Case 1 : If BPEL Process is Async or one-way process then, Delivery policy attribute can have three values. Those are 1)- async.persit  2)- async.cache 3)- sync

meaning:

- async.persit: Delivery messages are persisted in the database in table dlv_message. With this setting, reliability is obtained with some performance impact on the database. When the client initiates a process instance, an invocation request is placed in an internal queue. Inside Oracle BPEL Server, a message-driven bean (MDB), WorkerBean, monitors the queue for invocation requests. When a message is dequeued, Oracle BPEL Server allocates a thread to process the message.

   

    required

   

              many="false">async.persist

- async.cache : Incoming delivery messages are kept only in the in-memory cache. If performance is preferred over reliability, this setting should be considered. Message are not dehydrated into dlv_message table. Rest all is same as async.persist.

   

    required

   

              many="false">async.cache

- sync : Directs Oracle BPEL Server to bypass the scheduling of messages in the invoke queue, and invokes the BPEL instance synchronously. In some cases this setting can improve database performance. So there is no role of invoke queue and worker bean here.

   

    required

   

              many="false">sync

Case 2: If BPEL Process is Sync process then, transaction context between client and bpel-process is controlled by "Transaction" Attribute. Values of these attributes are 1)- Required 2)- Requires New

meaning:

- Required : This makes the BPEL process execute as part of the calling transaction. If no calling transaction exists, it will create a new one.

bpel.config.transaction property is set to requiresNew:

   

    many="false" type="xs:string">required

- RequiresNew : This is the default value and makes the BPEL process execute as a separate transaction. Any existing transaction will be suspended.

bpel.config.transaction property is set to requiresNew:

     

     many="false" type="xs:string">requiresNew