Anil's Blog is Best Viewed on GOOGLE CHROME

Friday, September 13, 2019

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


Wednesday, August 21, 2019

SOA Composite Sensors : Good Practice

In this article we will see how to stop a running SOA composite process. It is normal to stop from Enterprise Manager (http: // {hostname}: {port number} / em), but I thought this was not "user friendly". 

How can I use the API to identify the SOA composite instance ID? It is easiest to incorporate a composite sensor into the SCA composite. With a composite sensor, you can easily retrieve business data from a composite. You can query the composite with the data from this sensor. 

For example, you might want to create a composite sensor that outputs a primary key (such as orderId) for the composite you created. If you need to manipulate or query the composite, you can easily identify the instance ID using the sensor ID. 

For how to create a composite sensor ID, refer to the following document. 

https://docs.oracle.com/cd/E23943_01/dev.1111/e10224/sca_compsensors.htm#SOASE20703

Thanks,
Anil