SOA 12C Instance Auto Recovery

Instance Auto recovery is the functionality to recover the failed instances with in a stipulated time period. The Instances which are faulted and marked to be recovered can be recovered in a particular time.

At sometime it's a disadvantage if your instances are falling which might lead increase table spaces issue in soa-infra.

To overcome this, we need to change the recoveryConfig property as mentioned below:

STEPS

Login to Enterprise Manager and Go to SOA Administrator - BPEL Properties.

2. Click on 'More BPEL Configuration Properties'

3. Under RecoveryConfig --> RecurringScheduleConfig.

Update the MaxMessageRaiseSize to 0.

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

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

SOA - Change Logging Level for SOA 11g

This content has already been introduced in many entries, but I will keep it personally as many people still ask me.

1. Log in to Enterprise Manager Fusion Middleware Control.
   

   http: // {host name or IP}: {port number} / em

2. Open the SOA folder, right click on the soa_infra (soa_server1) folder and select Log> Log Customization.
   
   
3. Change the log level of the component you want to monitor. If necessary, you can change the log level of the parent package. If you set the parent log level to FINEST, a large amount of logs will be output, so it is not recommended.
4. A confirmation message will appear asking whether to apply the change. Set it to Yes before reflecting the change.
   

          Cheers!!

OSB - Using JSON with Oracle Service Bus REST Services

Two new Oracle Service Bus samples have been registered on the Oracle Technology Network site. The first sample project is osb-205-SimpleREST. This demonstrates how to fully implement a REST service in OSB. “Complete” means that the following HTTP methods are implemented using OSB.

• GET
• POST
• PUT
• DELETE
• HEAD
• OPTIONS

Another REST sample is now over. This is an osb-206-JSONREST project, which is an implementation sample for making OSB respond to JSON messages. JSON (JavaScript Object Notation) is often used in web browsers. Passing XML to a javascript client is not the only communication method. JSON is a popular method for exchanging data, especially for web developers. The reason for this is that JSON objects are easy to handle for javascript, but more infrastructure on the client side is needed to handle XML responses. 
For reasons of JSON characteristics, the osb-206-JSONREST sample targets HTTP methods GET and POST (both can be executed from a web browser). If you move a little, you can create a robust REST service for production environments and process XML and JSON payloads according to the HTTP Header Content-type. All OSB samples are uploaded to the SOA Suite sample site. The URL is as follows. Click the OSB section on the left side of the 

Official Oracle SOA Suite Samples 
https://www.oracle.com/downloads/samplecode/service-bus-downloads.html

page to see OSB samples. The site also provides samples of other components of the SOA Suite, so it's worth a look. 

SOA - DB Adapter performance issue having 1-N Relations Table

I faced the problem that it took a long time to execute select in DB Adapter. There were three tables that contained a large amount of data and contained many columns, and these tables were being handled by the DB Adapter.

The database side configured a primary key / foreign key relationship between the tables and recreated the DB Adapter, but the same problem occurred. The problem occurs when the user edits the SQL on the Define Selection Criteria page of the DB Adapter. Here are some ways to work around this problem:

Open -or-mappings.xml file
Find true </ batch-reading> and change true to false

Open the DB Adapter wizard again, go to the Define Selection Conditions page, and define the where clause.  Check the Return a single result set for both master and detail tables using outer join checkbox. This recreates the SQL.

Change the where clause of this new SQL statement. Be careful not to change before the From clause.

Click Finish to deploy the project.

Test the application.

For TopLink batch attribute reading (default is true),  if this is true and you edit "Selection Condition Definition" in the DB Adapter Wizard, you may scan the entire table with a one-to-many relationship .
To avoid this, batch loading was set to false.

Cheers!!