Deployment plan file to replace the JCA Adapters properties – Oracle SOA 11g

We can create and edit a configuration plan file in which we can replace the following attributes and properties:

•  Any composite, service component, reference, service, and binding properties in the SOA composite application file (composite.xml)
• Attribute values for bindings (for example, the location for binding.ws)
• schemaLocation attribute of an import in a WSDL file
• location attribute of an include in a WSDL file
• schemaLocation attribute of an include, import, and redefine in an XSD file
• Any properties in JCA adapter files

The configuration plan does not alter XSLT artifacts in the SOA composite application. If you want to modify any XSL, do so in the XSLT Mapper. Using a configuration plan is not useful. For example, you cannot change references in XSL using the configuration plan file. Instead, they must be changed manually in the XSLT Mapper in Oracle JDeveloper when moving to and from test, development, and production environments.

Generate the Plan file:

The plan file can be generated through JDeveloper or through ANT script.

Generating Plan file through JDeveloper:

Right Click on Composite.xml and click on generate config Plan.

Change the generated plan file contents accordingly to replace the properties and attributes of the composites.

Change the wsdlAndSchema section accordingly to replace the WSDL location and the schemaLocation of the WSDL’s and XSD’s

  

     

         http://localhost:7001/

         http://10.15.23.24:8004/

     

  

By default the wsdlAndSchema section will include the jca files to replace the JCA file properties.

The default configuration as shown below is not replacing the jca properties after the deployment of the composite.

     

D://Files

  D://Files//Sample     

  

The same should be changed as shown below to replace the JCA adapter properties 

File Adapter properties:

     

        

            D://Files

            D://Files//Sample

        

     

      

        

            false

            true

        

     

     

  

MQ Adapter properties:

                                  

       

            S_Order_Queue

            P_Order_Queue

       

       

  

The same searchReplace can be used to replace all the JCA adapters’ properties.

The plan file can be attached through ant script during the deployment of the composite to the server.

                 target="deploy">
           
           
           
           
           
           
           
           
            
       

DB Adapter Message Throttling in Oracle SOA 11g

DB throttling is the mechanism to control the number of database records processed by the SOA engine in a particular interval through DB Adapter. 

Throttling also can be used to control the number of records send to the end systems. If the throttling is not defined, the end systems may flood with number of messages that will affect the functioning of the end systems. Throttling parameters should be configured based on the end systems capacity to process the incoming messages.

Until Oracle SOA 11.1.1.6.0 the message throttling will not work as we expect, all the messages matching the where condition of the polling sql are processed in the same polling interval.

As of Oracle Adapters release 11.1.1.6.0 we can set the inbound DBAdapter property RowsPerPollingInterval to control the throttling. It acts as a limit on the number of records which can be processed in one polling interval. The default value is unlimited.

The Patch 12881289 should be applied to enable this for SOA 11.1.1.5.0 and earlier versions.

The maximum rows processed per second are:

Number of active nodes in SOA cluster x NumberOfThreads x RowsPerPollingInterval / PollingInterval

MaxTransactionSize can be thought of as RowsPerDatabaseTransaction or DatabaseFetchSize that is how many records will be fetched to DB Adapter engine from the database for each transaction. It does not affect how many rows can be processed in one polling interval period.

The one exception is the following configuration:

-distributed polling checked, usesSkipLocking="false"

In this one case RowsPerPollingInterval will default to MaxTransactionSize instead of unlimited in case of RowsPerPollingInterval property is not specified in the jca file.

If RowsPerPollingInterval is set to lower than MaxTransactionSize or MaxRaiseSize, they will be effectively lowered toRowsPerPollingInterval that means the value RowsPerPollingInterval will considered for MaxTransactionSize and MaxRaiseSize.

There is no UI support to add the RowsPerPollingInterval property. We have to add the property manually to the db.jca file for the inbound polling service. Add it to the same section as the properties MaxRaiseSize, MaxTransactionSize, and PollingInterval, in any order.

Transaction Management In OSB

Much awaited transaction management feature in Oracle Service Bus (OSB) message flows has been incorporated in the latest Oracle Service Bus release (OSB 11g). Now every OSB proxy service comes with two additional configuration parameters (check boxes) “Transaction Required” and “Same Transaction for Response” to deal with the transaction requirements.

Transaction Required, selecting this option ensures OSB execute the proxy service message flow in the context of a transaction. If a global transaction already exists, the transport provider propagates it in the request. If no global transaction exists, the message flow run time starts a new transaction. If the message flow run time starts a new transaction, the transaction-context begins before the service configuration is validated or run (for example, security checking or WS-I validation), and before message flow execution, ensuring that all processing and execution occurs in the transaction context.

If the message flow run time starts a transaction, quality of service (QoS) is exactly-once. However, if Service Callouts or Publish actions have the outbound QoS parameter set to best-effort, OSB executes those actions outside of the transaction context. To have OSB execute those actions in the same request transaction context, QoS on those actions need to be set to exactly-once. The service maintains its original messaging pattern (synchronous, asynchronous, one-way) regardless of the setting on this option.

This configuration has a catch; On selecting this option OSB invokes the system error handler for all failed transactions. Failed transactions cannot be catch in a user-configured error handler. For synchronous patterns, a transaction-exception is returned through the response. For asynchronous patterns, where the transaction is designed to be committed in the request, the exception is sent back on the request thread. Note that in asynchronous patterns, an error in the response that occurs after transaction committal in the request does not affect the transaction.

Another transactional configuration parameter is Same Transaction for Response, If the transaction of the request thread need to be propagated to the response thread this option also needs to be selected. On selecting this option, the message pattern becomes synchronous automatically, regardless of the initial message pattern setting.

Some do and don't while implementing OSB transaction options.

Always define the transaction timeouts for global transactions. Before setting the transaction timeout make sure that the timeout is sufficient to complete the message flow.

For those business requirements where request required transaction committal before sending the response, such as in a one-way, asynchronous pattern do not select Same Transaction for Response option. Selecting Same Transaction for Response option will override the pattern to synchronous.

 For making non-business interactions call (such as logging/message tracking services call) within a transactional flows set QoS to best effort. This will make the services to call outside the transaction on an event of their failure the main transaction will not be affected.