Service Result Caching in OSB

Oracle Service Bus 11g provides built-in cache functionality that utilizes Oracle Coherence, support for many caching strategies.

Oracle Coherence Integration:-

Oracle Service Bus always had some mechanics of caching in order to provide XQuery and XML beans caching, in addition to object caching for Proxy and Business Services classes. But from 11g Release 1 onward, Oracle Service Bus offered an integrated solution for result caching with Oracle Coherence.

The result caching in Oracle Service Bus is available for Business Services. When you enable result caching, the Business Service will not reach the backend service and the response will come from the cache entry. This entry can expire and if the entry is expired, the next service call will indeed reach the backend service and update the cache entry.

 
Activating Cache for Business Service

To enable result caching for our Business Service follow these steps: Open any business service

Expand Advanced Settings and in Result Caching select Supported. Set the Cache Token Expression: fn:data($body/ser:getCustomer/arg0)

 

This will use the customer ID as our unique token for the cache entry. Also, set the Expiration Time for 10 minutes.

Click Last >> and Save to confirm the Business Service modifications. You can activate the change session.

Now test the proxy service

Now the result will show the results immediately, directly from a cache entry in the embedded Oracle Coherence Server running within Oracle Service Bus.  The cache Expiration Time (Time-to-Live) is set to 10 mins, so during this period your calls will not hit the backend Web service.

More complex cache tokens :-

Your desired cache token key may not be as straight forward as selecting the contents of a single, predictably placed node.

 It is worth noting that the Cache Token may be specified as any expression you like, using the XQuery functional programming language.

 XQuery has a rich syntax for constructing queries, including the use of many system libraries with common functions such as numeric operations and string manipulation.

Clear the cache explicitly:-

It might be that you can’t risk the cache becoming stale under certain circumstances. If that is the case, rather than using a time parameter to manage the lifetime of the cached responses, mark critical requests with an additional flag and select XQuery Expression in the expiration time options to test for the existence of this flag.

JCA FTP Adapter limitation in OSB

When we use FTPAdapter with OSB 11g (specifically 11.1.1.6 in our case), Then we can encountered below error in osb_server1.out log file: 

<BEA-000000> <onReject: The resource adapter 'FTP Adapter' requested handling of a malformed inbound message. However, the following activation property has not been defined: 'rejectedMessageHandlers'. Please define it and redeploy. Will use the default Rejection Directory file://jca/Get/rejectedMessages for now.>

We were stuck with the problem of handling large file (Specifically 5 MB file) with OSB. Which was continuously getting polled and deleted from the FTP server and OSB logs was showing the rejection handler error.

Solution:

The default properties in the JCA FTP Adapter limits files to 4MB when polling for inbound messages.

Reason is when the FTP Adapter is used as inbound to receive files from an FTP server, it is possible to limit the size of files by using the payloadSizeThreshold property.

E.g. when the following below endpoint property

<property name="payloadSizeThreshold" type="xs:string" many="false" override="may">50000</property>

then files that are larger than 50000 bytes will be rejected.

This is properly working for all files that are smaller than around 4 MB, but for files larger than that a so-called scalable DOM is created and in this case the payload threshold check is not performed.

To ensure that the payloadSizeThreshold is properly recognized for files of all sizes, ensure that the SupportsScalableDOM property for the FTP Adapter is set to false.

1. Edit the FTPAdapter and add the following property inside the JCA file:

<property name="SupportsScalableDOM" value="false"/>

But changing it and making JCA adapter to poll the large files can result into out of memory error as file size depend on various factor such as (System resources, Load on the server and memory) to process the large files.

ODI is the best tool for processing files having size in GB’s.

How Large payload being handled via oracle soa suite 11g

The following below are the option to handle the large payload reading in SOA suit 11g.

 1) Debatching

 2) Integration with ODI

 1) Debatching : We can configure file adaptor to process the data in batches, for example if we have 1000 records then we can limit it to read 300 records at a time by setting publish record in batches of 300 in file adaptor wizard configuration. Which will create multiple instance for configured batch at run time.

 2) Integration with ODI : Oracle Data Integrator can handle large volume of data, ODI uses mechanism called ELT ( Extract, Load and Transfer). If file goes more than 10MB or so then SOA 11g dealing of files completely depends on what hardware, memory and load handling capacity server have. Keeping in mind SOA process still need for communication to external parties, ODI can be used along with SOA. Below is the example to understand it better.

  a) SOA picks up file as attachment without parsing payload and place into ODI box.
  b) SOA deal with ODI box to process large file by invoking ODI job as webservice.
  c) ODI sends acknowledge back to SOA once file processing over by calling SOA as webservice.

At last debatching introduces multiple instance for one end to end exectuion, So it’s difficult to track and monitor the interface execution specially if want the file to execute in single transaction.

SOA and ODI together provide easy way of processing large volume of data.

Run Time behaviour of FTP/SFTP Protocol in OSB

1.      The proxy service polls the input directory at regular intervals. 

Note:

A new connection is created for each poll cycle.

2.      If the proxy service finds a file in the input directory, it renames the file with a .stage extension. This renaming ensures that the service does not pick up the same files during the next polling cycle.

The .stage file exists in the input directory until it is delivered. 

Note:

If the file cannot be retrieved from the input directory (due to network failure, for example), the .stage file is processed during a clean-up cycle. The clean-up cycle is performed every 15 minutes or after 15 polling cycles, whichever occurs later. If a .stage file exists during two consecutive clean-up cycles, it is processed again. 

3.      A JMS task is created for the message and added to the domain-wide JMS queue. 

4.      A domain-wide MDB receives the task and processes the message. 

Note:

The task uses a pooled connection for processing the message. If a connection is not available in the pool, a new connection is created. 

5.      The message is delivered to the pipeline and the .stage file is deleted. 

Note:

If an SFTP business service is configured, the service puts the message in the outbound directory through a pooled connection.

 

If the message is not delivered, the transport attempts to transfer it again and repeats the process up to a predefined number of attempts. If the message cannot be delivered, it is moved to the error directory.

No resources currently available in pool SOADataSource to allocate to applications error

Error stack-trace:

java.sql.SQLException: Internal error: Cannot obtain XAConnection weblogic.common.resourcepool.ResourceLimitException: No resources currently available in pool SOADataSource to allocate to applications, please increase the size of the pool and retry..
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResourceInternal(ResourcePoolImpl.java:577)
at weblogic.common.resourcepool.ResourcePoolImpl.reserveResource(ResourcePoolImpl.java:342)

Error Cause:

Weblogic server throws the below exception when there is not enough database connections in the pool to serve the incoming requests reporting increasing the connection pool count.

The above exception is due to there is not enough connections available in the pool to service the requests.
To identify which datasource / connection pool requires more connection do the following.

• Go to Weblogic Admin console
• Go to Environment -> Servers
• Select the server on which the connection pool needs to be monitored
• Go to Monitoring -> JDBC
• Customize the table to add the below two properties

1. ActiveConnectionsAverageCount
2. ActiveConnectionsCurrentCount

Page will list all the datasources/ connection pools targeted to that particular server and how many connections are waiting to get the connection. If more number of connections are waiting, that is not a good which will cause performance impact and also cause stuck threads on the server if the wait time is going to be beyond the thread stuck time.When any data source will not be responding then it's state will be overloaded.

Solution :- Increase the number of connections in the connection pool.

Steps:

• Go to WLS Console
• Select Services -> Datasources -> select the datasource you want to change the pool size
• Go to Configuration -> connection pool
• Change the Maximum Capacity to the count which is required for your environment.

Transaction timeout/JTA Timeout Setting at weblogic console

For the BPEL timeout set property SyncMaxWaitTime (value in seconds) in the SOA Suite console (Oracle Fusion Middleware Control): In the navigation menu on the left expand the “SOA” folder and select item “soa-infra (soa_server1)” just below it. Then in the top of the details screen on the right expand the drop down menu “SOA Infrastructure” and select “SOA Administration” -> “BPEL Properties” . The “BPEL Service Engine Properties” screen opens. Click on link “More BPEL Configuration Properties…” at the bottom of this screen. Now the “Application Defined MBeans: BPELConfig:bpel” screen opens and finally you can edit the setting SyncMaxWaitTime (scroll down, setting #32 in list).

Set timeouts in the soa EJB’s: Open the Weblogic console and click in the navigation menu on the left on “Deployments”. Expand “soa-infra” by clicking on [+] and expand node “EJBs” in the same way. Increase the “Transaction Timeout” (value in seconds) in the “Configuration” tab for the following EJB’s by clicking on them:

1. BPELEngineBean
2. BPELDeliveryBean
3. BPELActivityManagerBean
4. BPELServerManagerBean
5. BPELProcessManagerBean
6. BPELInstanceManagerBean
7. BPELFinderBean


Increase the JTA timeout in the Weblogic console by selecting “soa_domain” in the navigation menu (top item) on the left. Then select tab “Configuration” and subtab “JTA”. The first setting is the “Timeout Seconds” (value in seconds).

To solve “HeuristicMixedException” timeouts, set the “XA Transaction Timeout” of the soa jdbc connection to 0 seconds (means inherit) by expanding “Services” -> “JDBC” and select “Data Sources”. In the screen on the right select “SOADataSource” from the list and select tab “Configuration” and subtab “Transaction”. Enable setting “Use XA Datasource Interface” and setting “Set XA Transaction Timeout” and set setting “XA Transaction Timeout:” to 0 (inherit globale Weblogic transaction timeout).