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.

Article to learn technologies fast

http://www.tutorialspoint.com/index.htm

Weblogic Monitoring Dashboard to monitor the resources

Monitoring dashboard is the new feature of latest weblogic server to view diagnostic data without doing additional setup.

This is the extension of the WLDF framework. The Monitoring Dashboard provides views and tools for graphically presenting diagnostic data about servers and applications running on them. The underlying functionality for generating, retrieving, and persisting diagnostic data is provided by the WebLogic Diagnostics Framework. The Monitoring Dashboard provides additional tools for presenting that data in charts and graphs.

The Monitoring dashboard can be launched from the home page of the Web logic administration console or pointing to the direct URL.

Direct URL to access the Monitoring Dashboard - http://:/console/dashboard

The different resources like JMS, JVM, JDBC and Thread Pools can be monitored here.

The diagnostic data can be captured for a particular resource in a particular time by using the start and stop functionality.

The user also can create the custom views; Custom views are available only to the user who created them. Custom views are automatically persisted for the user and are in effect only for that user account and only in the current domain.

Refer the below URL for more details about dashboard

http://docs.oracle.com/cd/E14571_01/web.1111/e13714/dashboard.htm

Dynamically changing log level with Weblogic, log4j, JMX and WLST

http://176.34.122.30/blog/2010/04/22/dynamically-changing-log-level-with-weblogic-log4j-jmx-and-wlst/

Soa Suite 11g - Starting Managed Servers with Auto Login

Searching for some way to start Weblogic Managed Servers easier, without the need to inform username and password manually, I found an Oracle Install Configuration document that describes how to do that:

• At <DOMAIN_HOME>/servers/<MANAGED_SERVER_NAME>/security (create this folder, if it not exists), create a file with the name “boot.properties”
• Inside this file, create two properties:
• username=<Weblogic Admin Username>
• password=<Weblogic Admin Password>

After that, just start the managed server as usually, with startManagedWeblogic script. The script will identify the Boot Identity File and the server will be started without asking for username and password.

This is a good way to allow developers to start and stop the managed servers without let him the credentials. The first time the managed server starts, data inside the file will be replaced by encrypted information.

WLST to change the property of a BPEL process

connect('userid','pwd','t3://host:port')

domainRuntime()

//Get the composite object in a variable

MbeanObject = ObjectName('Mbean')

params = ['endpointURI','http://test:11001']  

sign = ['java.lang.String','java.lang.String']

mbs.invoke(MbeanObject , 'setStringProperty', params, sign)

mbs.invoke(MbeanObject , "save", None, None)

disconnect()

exit()

Runtime changes to Oracle WS policy

The WSM policies will, indeed, refresh on their own without the need to unattach and reattach. The default time for this is automatic refreshing is rather long; 10 minutes.

However, the times can be changed by adding parameters to the Policy Accessors section in EM. 

You can do this by logging into EM, selecting the domain in use, and following the menu path: WebLogic Domain> Web Services > Platform Policy Configuration. From there, select the Policy Accessor tab, then click Add to add a property.

There are two properties that control this process:

1) cache.refresh.initial - The number of milliseconds to wait before initial cache refresh. The default is 600000 milliseconds (10 minutes).
2) cache.refresh.repeat - The number of milliseconds to wait between cache refreshes. The default is 600000 milliseconds (10 minutes).

You can add these parameters and/or change to different values to control the refresh process.

The information is documented in the Oracle Fusion Middleware Security and Administrator's Guide for Web Services, found at the following URL:
http://docs.oracle.com/cd/E23943_01/web.1111/b32511/managing.htm#autoId20

Oracle SOA 11g – Local optimization for webservice calls

The property “oracle.webservices.local.optimization” instructs Composite to make the webservice calls via SOAP stack or not.

By default the value for the property “oracle.webservices.local.optimization” is true. If the value is true and composite invokes any other webservice on the same server/domain, it avoids soap overhead and calls natively.

There may be a situation that you want to invoke the services via Soap Stack and changing the value of “oracle.webservices.local.optimization” property to false will help us to do that.

We can set this property in Composite.xml for a specific partner link only that partner link invocation always happens via soap stack.

Open the Composite.xml in JDev and add the property - oracle.webservices.local.optimization to the corresponding partnerlink binding.

When the local optimization is true, the policies attached to the partnerlinks are also bypassed

Setting Timeouts for Oracle SOA Suite 11g

The five timeout settings in Oracle SOA Suite 11g:

1. In the composite.xml of the composites calling the long running webservice and the composites calling these composites (and thus the whole chain of calling composites), set the webservice binding property for read timeout (and optional the connection timeout) in the reference declaration (value in milliseconds).                          

1. ?
2. 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).
    
3. 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:
   • BPELEngineBean
   • BPELDeliveryBean
   • BPELActivityManagerBean
   • BPELServerManagerBean
   • BPELProcessManagerBean
   • BPELInstanceManagerBean
   • BPELFinderBean
4. 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).
    
5. 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).

Programmatically determining BPEL manual recovery status

BPEL processes can go to manual recovery. The two most common issues are: 1) an issue on the invoke of the process (BPEL server Out of Memory error for example), and 2) an issue with the callback on an asynchronous BPEL process.

BPEL process manager has a nice UI for looking at and managing these, but what if we need to be alerted when a process goes into one of these states? Well, BPEL PM doesn't have that capability, so we need to write our own. Another useful thing might be to always clear the processes, especially those that are in manual recovery for callback. Typically in that situation the callback failed, most often because the original calling process is no longer around to receive the callback.

In the article, we use JAVA API for finding processes in both invoke and callback manual recovery. For both cases, it will be necessary to get a reference to the Locator object via the BPEL Java API.

Getting process manual recovery for inoke:

            String Buffer buf = new StringBuffer();

            WhereCondition where = new WhereCondition(buf.append(SQLDefs.IM_state).append( " = " ).append(IDeliveryConstants.STATE_UNRESOLVED ).toString() );

            IInvokeMetaData imd[] = locator.listInvokeMessages(where);

            String ids[] = new String[imd.length];
 
            // print out the partial process information
            // for processes in manual recovery status on invoke
            for (i = 0; i <>
            {
                 System.out.println("ConversationId=" +
                                     imd[i].getConversationId());
                 System.out.println("ProcessId=" +
                                    imd[i].getProcessId());
                 System.out.println("State=" + imd[i].getState());

                 ids[i] = imd[i].getConversationId();
            }

            // if we wanted to automatically recover these processes
            // we would uncomment the following line:
            // locator.lookupDomain().recoverInvokeMessages(ids);

For callbacks the code flow is the exact same. Instead of IInvokeMetaData, we get an array of ICallbackMetaData using the locator.listCallbackMessages(where) method. One other slight change is the where clause itself -- for callbacks the where clause should be built as:

WhereCondition where = new WhereCondition(buf.append(SQLDefs.DM_state).append( " = " ).append(
IDeliveryConstants.TYPE_callback_soap ).toString() );

The last change for callbacks is how they are recovered -- locator.lookupDomain.recoverCallbackMessages(ids)

Using the API's above you can see how we could build a custom notification process or an automatic or work flow based recovery method that does not involve the actual BPEL PM.

Oracle SOA 11g - Abort the running composite instances through JAVA API

The below code snippet will help us to abort the running instance of the particular composite, the filter condition can be changed accordingly to abort the running composite instances with different matching criteria.

try
{
String compositeName="GetDomainID";
Hashtable jndiProps = new Hashtable();
jndiProps.put(Context.PROVIDER_URL,"t3://soahost:soaport");
jndiProps.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory");
jndiProps.put(Context.SECURITY_PRINCIPAL,"weblogic");
jndiProps.put(Context.SECURITY_CREDENTIALS,"xxxxx");
jndiProps.put("dedicated.connection","true");
Locator locator = LocatorFactory.createLocator(jndiProps);
CompositeInstanceFilter filter =new CompositeInstanceFilter();
filter.setState(CompositeInstance.STATE_RUNNING);
filter.setCompositeName(compositeName);
// filter.setId("670002");
List compositeInstances = locator.getCompositeInstances(filter);
for(int i=0;i((CompositeInstance)compositeInstances.get(i)).abort();
}catch(Exception e)
{
e.printStackTrace();
}

Execution of this code will abort all the running instances of a specified composite.

Monitoring the JCA Adapter’s through WLST script – Oracle SOA 11g

Sometimes we may need to monitor the runtime performance of the JCA adapters, the monitoring is possible through EM console for limited details, the below WLST script will help us to monitor the required details of the JCA adapter (the scrip should be extended to monitor more details).

The below script can be used for monitoring only the DBAdapter’s and MQAdapter’s; the same can be extended to monitor other JCA Adapters (like FileAdapter) .

Before executing the script change the below condition according to your server name.

if server.getName().strip().startswith('S') | server.getName().strip().startswith('O')

The Adapters are only available in SOA and OSB servers so that I am filtering the other servers  based on the name(AdminServer or MS servers) .The exception will be thrown if we are trying to cd the MBean related to Adapters in others servers.

ResourceAdapterMonitor.py

def monitorDBAdapter(serverName):

    cd("ServerRuntimes/"+str(serverName)+"/ApplicationRuntimes/DbAdapter/ComponentRuntimes/DbAdapter/ConnectionPools")

    connectionPools = ls(returnMap='true')

    print '--------------------------------------------------------------------------------------'

    print 'DBAdapter Runtime details for '+ serverName

    print '                                                                                      '

    print '                                                                                      '

    print '--------------------------------------------------------------------------------------'

    print '%10s %13s %15s %18s' % ('Connection Pool', 'State', 'Current', 'Created')

    print '%10s %10s %24s %21s' % ('', '', 'Capacity', 'Connections')

    print '                                                                                      '

    print '--------------------------------------------------------------------------------------'

    for connectionPool in connectionPools:

       if connectionPool!='eis/DB/SOADemo':

          cd('/')

          cd("ServerRuntimes/"+str(serverName)+"/ApplicationRuntimes/DbAdapter/ComponentRuntimes/DbAdapter/ConnectionPools/"+str(connectionPool))

          print '%15s %15s %10s %20s' % (cmo.getName(), cmo.getState(), cmo.getCurrentCapacity(), cmo.getConnectionsCreatedTotalCount())

    print '                                                                                      '

    print '--------------------------------------------------------------------------------------'

def monitorMQAdapter(serverName):

    cd("ServerRuntimes/"+str(serverName)+"/ApplicationRuntimes/MQSeriesAdapter/ComponentRuntimes/MQSeriesAdapter/ConnectionPools")

    connectionPoolsMQ = ls(returnMap='true')

    print '--------------------------------------------------------------------------------------'

    print 'MQAdapter Runtime details for '+ serverName

    print '                                                                                      '

    print '                                                                                      '

    print '--------------------------------------------------------------------------------------'

    print '%15s %17s %15s %18s' % ('Connection Pool', 'State', 'Current', 'Created')

    print '%15s %15s %24s %21s' % ('', '', 'Capacity', 'Connections')

    print '                                                                                      '

    print '--------------------------------------------------------------------------------------'

    for connectionPoolMQ in connectionPoolsMQ:

          cd('/')

          cd("ServerRuntimes/"+str(serverName)+"/ApplicationRuntimes/MQSeriesAdapter/ComponentRuntimes/MQSeriesAdapter/ConnectionPools/")

          cd(connectionPoolMQ)

          print '%15s %20s %10s %20s' % (cmo.getName(), cmo.getState(), cmo.getCurrentCapacity(), cmo.getConnectionsCreatedTotalCount())

    print '                                                                                      '

    print '--------------------------------------------------------------------------------------'

def main():

      #connect(username, password, admurl)

      connect('weblogic','reuters123','t3://:)

      servers = cmo.getServers()

      domainRuntime()

      for server in servers:

         cd("/ServerLifeCycleRuntimes/" + server.getName())

         if cmo.getState() == 'RUNNING':  

            if server.getName().strip().startswith('S') | server.getName().strip().startswith('O') :

                 monitorDBAdapter(server.getName())

      for server in servers:

         cd('/')

         cd("/ServerLifeCycleRuntimes/" + server.getName())

         if cmo.getState() == 'RUNNING':  

            if server.getName().strip().startswith('S') | server.getName().strip().startswith('O') :

                 monitorMQAdapter(server.getName())   

      disconnect()

     

main()

Copy the script to the soa server and execute the below command

>   wlst.sh ResourceAdapterMonitor.py

O/P:

--------------------------------------------------------------------------------------

DBAdapter Runtime details for SOA1

--------------------------------------------------------------------------------------

Connection Pool         State         Current            Created

                                                    Capacity          Connections

--------------------------------------------------------------------------------------

  eis/DB/SOA             Running         22               1051

      eis/DB/Test           Running           2                  697

    eis/DB/Test1           Running           1                  130

--------------------------------------------------------------------------------------

----------------------------------------------------------------------------------------------------

MQAdapter Runtime details for SOA1

------------------------------------------------------------------------------------------------------

Connection Pool                                       State          Current            Created

                                                                                  Capacity           Connections

------------------------------------------------------------------------------------------------------

eis/MQ/MQAdapter                                 Running          0                    0

eis/MQ/MQSeriesAdapterRemote            Running          2                   84

-------------------------------------------------------------------------------------------------------