Tuesday, February 28, 2012

Applying the JRF to the weblogic cluster through WLST


Applying the JRF to the weblogic cluster through WLST

When we are creating the core weblogic cluster JRF is not applied by default, the below WLST script will help us to apply the JRF for the weblogic cluster.

import sys


print "@@@ Starting the script ..."

from java.util import *
from javax.management import *
from java.io import FileInputStream

#The directory of the domain configuration
#/app/oracle/products/11g/admin/domains
wlsDomain=os.environ["WLSDOMAIN"]
print "WLSDOMAIN="+wlsDomain

DOMAIN_PATH= wlsDomain + '/SOACoreDomain'
print 'reading domain from '+DOMAIN_PATH


readDomain(DOMAIN_PATH)

cd('/')
applyJRF('ClusterName', wlsDomain + '/SOACoreDomain')
print 'Successfully updated domain.'
updateDomain()
closeDomain()

exit()


Friday, February 24, 2012

Oracle SOA Suite 11g - Error retrieving NXSD encoding exception in MQ adapter

Oracle SOA Suite 11g - Error retrieving NXSD encoding exception in MQ adapter:

The following exception has been thrown whenever a composite enqueue the message to the Queue through the MQ Adapter.
MQSeriesAdapter PropagateOrderRequest:OrderRequest [ Enqueue_ptt::Enqueue(Request) ] Error retrieving NXSD encoding...>>
<11-Jan-2012 12:58:16 o'clock GMT> <Notice> <Stdout> <BEA-000000> <<11-Jan-2012 12:58:16 o'clock GMT> <Error> <oracle.soa.adapter> <BEA-000000> <MQSeriesAdapter CCRMOM_PropagateOrderRequest:OrderRequest [ Enqueue_ptt::Enqueue(Request) ]
java.lang.NullPointerException
This is a Runtime exception, even after receiving the above exception the messages are successfully enqueued.

The Oracle SOA Suite version in which the issue has been observed is 11.1.1.5.0

Solution to suppress this exception:

               We have applied the patch 13718139 as suggested by oracle and it resolved the issue.
               Download the patch from metalink by specifying the patch number as 13718139.


Saturday, February 18, 2012

Oracle SOA Suite 11g - Callback not reaching the calling service in a Clustered environment

Oracle SOA Suite 11g - Callback not reaching the calling service in a Clustered environment:


In Oracle SOA Suite 10g, we had a scenario like shown in the below diagram.

Process A


Process A calls Process B and waits for the call back; after receiving the call back; The Process A calls again the same Process B and waits for the second call back.
This flow is working fine in 10g but after migrating to 11g the second call back is not reaching the Process A.
In the SOA log file we could able to see the below error message -
an unhandled exception has been thrown in the Collaxa Cube systemr; exception reported is: "javax.persistence.PersistenceException: Exception [EclipseLink-4002] (Eclipse Persistence Services - 2.1.3.v20110304-r9073): org.eclipse.persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLIntegrityConstraintViolationException: ORA-00001: unique constraint (SOA_SOAINFRA.AT_PK) violated

Error Code: 1
Call: INSERT INTO AUDIT_TRAIL (CIKEY, COUNT_ID, NUM_OF_EVENTS, BLOCK_USIZE, CI_PARTITION_DATE, BLOCK_CSIZE, BLOCK, LOG) VALUES (?, ?, ?, ?, ?, ?, ?, ?)
bind => [851450, 5, 0, 118110, 2012-01-12 16:08:04.063, 5048, 3, [B@69157b01]
Query: InsertObjectQuery(com.collaxa.cube.persistence.dto.AuditTrail@494ca627)
at org.eclipse.persistence.internal.jpa.EntityManagerImpl.flush(EntityManagerImpl.java:744)
After the detail analysis and the Oracle SR, the root cause is “Audit Trail caching issue is causing the process not to get to complete due to the exception while doing the second call back”.
Let’s say in a Cluster with four nodes Process A first created on node 1 and carried on and called first call to Process B and dehydrates. Assume that second call hit a node other than node 1, let’s say node 4. Node 4 carries on doing the work and does the second call to Process B and dehydrates. If the second call back hits Node 1, rather than getting the latest audit trail from database, it’s using the cache and trying to update the audit trial with an id which node 4 already used. That’s throwing an exception and rolling back. For that reason the call back is not getting delivered.
As a temporary solution by switching of the audit trail for Process A, it doesn’t try to insert the data into audit trail and the transaction won’t get roll back and the call has reached successfully.
As a permanent solution, Oracle has provided the patch, the same can be download from the below path.
The issue identified in the SOA Suite version – 11.1.1.5.0


Sunday, February 5, 2012

Currently logged in user is not authorized to modify SOA metadata

Currently logged in user is not authorized to modify SOA metadata

We must have the SOADesigner application role to access Oracle SOA Suite Composer metadata. By default, all the users with Oracle Enterprise Manager Fusion Middleware Control administrator privileges have this role. If you log in to Oracle SOA Composer without this role, you see the following message:
"Currently logged in user is not authorized to modify SOA metadata".

For information about adding the SOADesigner application role to users without administrator privileges, see Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite and Oracle BPM Suite.
If we are adding the SOADesigner role to the user, the user can edit the DVM’s and the rules.I could not able to find out read only access for the SOAComposer application.


Friday, February 3, 2012

Creating JDBC Multi Data Source through WLST in weblogic server

Creating JDBC Multi Data Source through WLST in weblogic server

The below WLST script will help us to create the Multi Data Source in weblogic server.

CreateMultiDataSource.py

adminURL='t3://<<Admin Server Host>>:<<Port>>'
adminUserName='weblogic'
adminPassword='<<Password>>'
connect(adminUserName, adminPassword, adminURL)
edit()
startEdit()
jdbcSystemResource = create("MS1","JDBCSystemResource")
jdbcResource = jdbcSystemResource.getJDBCResource()
jdbcResource.setName("MS1")
dsParams = jdbcResource.getJDBCDataSourceParams()
jndiName='jdbc/MS1'
dsParams.setJNDINames([jndiName])
dsParams.setAlgorithmType('Failover')
dsParams.setDataSourceList('DS1,DS2')
dsParams.setFailoverRequestIfBusy(true)
jdbcSystemResource.addTarget(getMBean('Servers/AdminServer'))
print('MDS1 created successfully...')
save()
activate()
disconnect()

Before executing this script the member data sources(DS1,DS2) should be created.