Tuesday, April 29, 2014

Unable to get schema information for source - JDeveloper

Unable to get schema information for source - JDeveloper

I was getting the error "Unable to get schema information for source" while generating the XSL mapper file in the BPEL Transform activity through JDeveloper. The same error was coming while editing the existing mapper file in a transform activity with the same source variable.


But the component is getting deployed successfully and also the flows are working fine without any issue.

After the analysis i found that there is two schema's imported with the same name space into the wsdl and one of the them is used to create the message type for the source variable in the transformation.


Approaches to fix the issue

  •  Make sure the schema's are imported with different name space or create a consolidated schema and import the same 
  • Include the schema's that has the same names instead of importing them into the wsdl.



WLST script to set the XA Transaction timeout values for a data source in weblogic server

WLST script to set the XA Transaction timeout values for a data source in weblogic server


This tutorial explains the approach to set some of the important timeout properties for XA data sources in weblogic server through WLST script.

Set XA Transaction Timeout


Enables WebLogic Server to set a transaction branch timeout based on the value for XaTransactionTimeout.

When enabled, the WebLogic Server Transaction Manager calls XAResource.setTransactionTimeout() before calling XAResource.start, and passes either the XA Transaction Timeout value or the global transaction timeout.

XA Transaction Timeout


The number of seconds to set as the transaction branch timeout.
If set, this value is passed as the transaction timeout value in the XAResource.setTransactionTimeout() call on the XA resource manager, typically the JDBC driver.

When this value is set to 0, the WebLogic Server Transaction Manager passes the global WebLogic Server transaction timeout in seconds in the method.

If set, this value should be greater than or equal to the global WebLogic Server transaction timeout.


XA Retry Duration


Determines the duration in seconds for which the transaction manager will perform recover operations on the resource. A value of zero indicates that no retries will be performed.
XA Retry Interval

The number of seconds between XA retry operations if XARetryDurationSeconds is set to a positive value.

Please note the above configurations are only available to the data sources created with XA supported driver


WLST Script


The below wlst script set the required XA timeout properties

SetXATimeoutProperties.py
def setXATimeoutProperties():
   dsName='JDBC Data Source-0'
   edit()
   startEdit()
       
   server='AdminServer'
   cd("Servers/"+server)
   target=cmo
 
   print '========================================='
   print 'Setting the timeout properties for DataSource....'
   print '========================================='  
           
   cd('/JDBCSystemResources/'+dsName+'/JDBCResource/'+dsName+'/JDBCXAParams/'+dsName)
   cmo.setXaSetTransactionTimeout(true)cd('/JDBCSystemResources/'+dsName+'/JDBCResource/'+dsName+'/JDBCXAParams/'+dsName)
   cmo.setXaTransactionTimeout(3000)cd('/JDBCSystemResources/'+dsName+'/JDBCResource/'+dsName+'/JDBCXAParams/'+dsName)
   cmo.setXaRetryDurationSeconds(300)cd('/JDBCSystemResources/'+dsName+'/JDBCResource/'+dsName+'/JDBCXAParams/'+dsName)
   cmo.setXaRetryIntervalSeconds(60)save()
   activate()print 'Timeout settings for the datasource '+dsName+' has been completed'
 
 
def main():
     
    adminURL='t3://localhost:7001'
    adminUserName='weblogic'
    adminPassword='weblogic1'
    connect(adminUserName, adminPassword, adminURL)
    setXATimeoutProperties()
    disconnect()main()

Script

https://github.com/techforum-repo/youttubedata/blob/master/scripts/wlst/SetXATimeoutProperties.py

Before executing the script change the configuration values as required

Execute the script — <<Oracle_Home>>\oracle_common\common\bin\wlst.cmd SetXATimeoutProperties.py



Restart the server after successful execution. Now the XA configurations are enabled as required.



Monday, April 28, 2014

WLST script to set the JDBC Connection timeout properties in weblogic server

WLST script to set the JDBC Connection timeout properties in weblogic server


There are different timeout properties in JDBC connection, this tutorial explains the approach to set some of the important JDBC Connection timeout properties in weblogic server through WLST script.

Inactive Connection Timeout


The number of inactive seconds on a reserved connection before WebLogic Server reclaims the connection and releases it back into the connection pool.
You can use the Inactive Connection Timeout feature to reclaim leaked connections — connections that were not explicitly closed by the application.


Connection Reserve Timeout


The number of seconds after which a call to reserve a connection from the connection pool will timeout.
When set to 0, a call will never timeout.
When set to -1, a call will timeout immediately.


Statement Timeout


The time after which a statement currently being executed will time out.
A value of -1 disables this feature.
A value of 0 means that statements will not time out.


oracle.jdbc.ReadTimeout


The property oracle.jdbc.ReadTimeout helps to set read timeout while reading from the socket.

oracle.net.READ_TIMEOUT for jdbc versions < 10.1.0.5 oracle.jdbc.ReadTimeout for jdbc versions >=10.1.0.5


oracle.net.CONNECT_TIMEOUT


The property oracle.net.CONNECT_TIMEOUT helps to set the login time out in Oracle.
WLST Script

The below WLST script will help us to set the JDBC connection timeout properties

SetJDBCTimeoutProperties.py
def setJDBCTimeoutProperties():
   dsName='CRM6EAIReference'
   edit()
   startEdit()
       
   server='AdminServer'
   cd("Servers/"+server)
   target=cmo
 
   print '========================================='
   print 'Setting the timeout properties for DataSource....'
   print '========================================='  
           
   cd('/JDBCSystemResources/'+dsName+'/JDBCResource/'+dsName+'/JDBCDriverParams/'+dsName+'/Properties/'+dsName)
   #cmo.destroyProperty(getMBean('/JDBCSystemResources/'+dsName+'/JDBCResource/'+dsName+'/JDBCDriverParams/'+dsName+'/Properties/'+dsName+'/Properties/oracle.net.CONNECT_TIMEOUT'))
   cmo.createProperty('oracle.net.CONNECT_TIMEOUT')


Script

https://github.com/techforum-repo/youttubedata/blob/master/scripts/wlst/SetJDBCTimeoutProperties.py

Before executing the script, change the configurations as required.

Execute the script — <<Oracle_Home>>\oracle_common\common\bin\wlst.cmd SetJDBCTimeoutProperties.py



Restart the server after successful execution. Now the JDBC connection timeout properties are set to the datasource.



Under advanced section



Sunday, April 27, 2014

Purging the Oracle Service Bus(OSB) Alerts

Purging the Oracle Service Bus(OSB) Alerts

The History of  Alerts in OSB can be purged through OSB console.

Make sure you are purging the alerts regularly otherwise you may face some of the  the issues like
  • The server will take more time to start
  • The alert dashboard will become very slow.
Login to sbconsole and click on Operations-->Monitoring-->Dashboard
Click on Extended Alert History


Click on "Purge SLA Alerts History"




Saturday, April 26, 2014

A timeout occurred while interacting with sever. Limited information is available - Weblogic

A timeout occurred while interacting with sever. Limited information is available  - Weblogic 

We were getting the error "A timeout occurred while interacting with Server. Limited information is available" while accessing the Server Page from the admin console in clustered weblogic environment and the health of the server is shown as empty but the state is shown as running.
Login to the admin console and accessing the Server page also was taking more time
But the individual servers and the node managers are running fine in all the nodes.


The issue seems to be because of the delay in the communication between the node manager and the managed servers.

Steps to resolve the issue:

  • Stop all the managed servers from all the nodes.
  • Kill the node managers from all the nodes.
  • Stop the Admin server.
  • Start the node manager in all the nodes.
  • Start the Admin server.
  • Start all the managed server.