Sunday, May 6, 2012

Java code to Marshal/Unmarshal XML using JAXB

Java code to Marshal/Unmarshal XML using JAXB:

Unmarshalling:

JAXBContext jc =JAXBContext.newInstance("com.java.test");//add multiple packages seperated by ":" eg.com.java.test1:com.java.test2
Unmarshaller u = jc.createUnmarshaller();
JAXBElement obj =(JAXBElement)u.unmarshal(new File(inputXMLPath)); // ok

Marshalling

Marshaller marshaller = jc.createMarshaller();
marshaller.setProperty(Marshaller.JAXB_FORMATTED_OUTPUT,Boolean.TRUE);
String outXML = "Response.xml";
marshaller.marshal(obj,new FileOutputStream(outXML));

Thursday, May 3, 2012

java.lang.ArrayIndexOutOfBoundsException in DB Adapter – Oracle SOA Suite 11g


java.lang.ArrayIndexOutOfBoundsException in DB Adapter – Oracle SOA Suite 11g:

The DB Adapter insert were intermittently failing with the following exception in our Oracle SOA Suite environments. 

Exception occured during invocation of JCA binding: "JCA Binding execute of Reference operation 'update' failed due to: DBWriteInteractionSpec Execute Failed Exception. update failed. Descriptor name: [Update_Interfacebuffer.InterfaceBuffer].
Caused by java.lang.ArrayIndexOutOfBoundsException. Please see the logs for the full DBAdapter logging output prior to this exception. This exception is considered not retriable, likely due to a modelling mistake.

It is caused by using a non-synchronized class instead of a synchronized class. Read the Metalink Note 1332114.1 for more details about this.

Oracle suggested us to apply the below patch to resolve the issue.

Patch 11866793: DBADAPTER INSERT OPERATION IS FAILING INTERMITTENTLY WITH NPE

The issue is observed in the following versions 11.1.1.3.0, 11.1.1.4.0 and 11.1.1.5.0 and Fixed in the version 11.1.1.6.0.

The issue got resolved after applying the patch.

Wednesday, May 2, 2012

WLST script to reset data source password in weblogic server

WLST script to reset data source password in weblogic server


This tutorial explains the approach to reset the password of all the data sources in weblogic server. Sometime we may need to reset the password of all the data sources, the below WLST script can be used to achieve the same.

The reset through console takes more time, the below WLST script helps to reset the password quickly

WLST Script


ResetAllDataSourcePassword.py

adminIP = raw_input("Enter domain1.AdminIP:")
adminPort = raw_input("Enter domain1.AdminPort:")
adminPassword = raw_input("Enter adminPassword:")
DBPASSWORD= raw_input("Enter new DBPASSWORD:")
DOMAIN_PATH='C://Albin/SW/Oracle/Middleware/Oracle_Home/user_projects/domains/base_domain'
es = encrypt(DBPASSWORD,DOMAIN_PATH)
adminURL='t3://'+adminIP+':'+adminPort
adminUserName='weblogic'
connect(adminUserName, adminPassword, adminURL)
server='AdminServer'
cd('Servers/'+server)
target=cmo
edit()
startEdit()# SOADomain Datasource Configuration
cd('JDBCSystemResources')
allDS=cmo.getJDBCSystemResources()
for tmpDS in allDS:
    dsName=tmpDS.getName();
    print  'Changing the Password for DataSource ', dsName
    cd('/JDBCSystemResources/'+dsName+'/JDBCResource/'+dsName+'/JDBCDriverParams/'+dsName)
    set('PasswordEncrypted',es)
save()
activate()
disconnect()


Script

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

Before executing the script, change the configurations as required.

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



Now the data sources password reset to new value.

Monday, April 23, 2012

Increasing the performance of EM console in Oracle SOA Suite 11g - Part1

Increasing the performance of EM console in Oracle SOA Suite 11g - Part1

EM console is very slow when accessing to view the composite/component details or the instance details.
We can try to improve the performance by little by following the below steps.

1. Login to the Oracle SOA Suite 11g EM Console
2. Right Click on SOA-INFRA and go to SOA Administration->Common properties
3. Set the Data Display Options as shown below.
              Select the option “Disable fetching of instance and fault count metrics. Each metric can still be  retrieved on demand”.
Set the Duration Details to 1 hour (based on your requirement) as shown below.


This will enable to fetch the instance and fault count metrics based on the demand also the default search criteria will display the last one hour data, this will improve the performance of the em console.

Enable fmwctl discovery cache:

Logging into Enterprise Manager Fusion Middleware Control 11g (fmwctl) takes a long time.  Sometimes as long as 45-60 seconds.  This is often viewed as slow response time, performance or hanging issues, fmwctl discovery is always performed as part of login.  

For installations with thousands of targets, fmwctl discovery may take 45-60 seconds. This delay is expected because EM discovery mbeans need to be invoked for every target.
Solution is to cache the discovery results in the servlet context and use it for subsequent logins. This discovery result will be shared by all the fmwctl users. This will still require the entire discovery to be done at least once.

Follow the metalink note 1423893.1 to enable the discovery caching.

If the caching is enabled, fmwctl will use the cached discovery results and login to the em console will be fast.The default setting is "not use the cached results" 

Thursday, April 19, 2012

Audit Trail configurations in Oracle SOA Suite


Audit Trail configurations in Oracle SOA Suite:

Until 11.1.1.3,Oracle BPEL audit trails are saved to database in the same JTA transaction as the main transaction. The below are the some of the issues caused.
  • Latency of saving audit trail to database is included as part of the overall latency of the main business transaction.
  • When the main transaction is rolled back for whatever reason, the audit trail did not get saved, because audit trails are saved in the main transaction as well. Thus no trace of what had happened can be found on the BPEL Console (or EM Console in 11G).
Since Oracle SOA Suite 11.1.1.3, management of audit trail memory has been enhanced.

The properties to configure the audit trail:

auditStorePolicy

Use this flag to choose the audit store strategy
syncSingleWrite - would store audit data synchronously when it saves the cube instance, this is done as part of the cube instance transaction.
This is the default value. And the behavior is the same as in the 10.1.3.x version.
syncMultipleWrite - would store audit data synchronously using a separate local transaction.
By "synchronously" it means the BPEL service engine is saving the audit trail in the same thread as the main transaction. However, it is doing it in a "separate local transaction".

Because they are on the same thread, latency of saving audit trail is still included into overall latency of the main transaction.

However, because they are on separate transactions, you can configure BPEL engine (using AuditFlushByteThreshold and AuditFlushEventThreshold) to flush out the audit trail from memory to database periodically regardless how long the main transaction would take.
Moreover, having them on two separate transaction means the rollback of main transaction will NOT affect the audit trail transaction. That is, you will still see audit trail even if the main transaction rolls back.
async - would store the audit data asynchronously using an in-memory queue and pool of audit threads.
This is almost the same as "syncMultipleWrite", except that it is done not just in a separate transaction but also in a separate thread.

The pro is the audit trail latency is NOT directly included in the latency of main transaction (but because they still share the computing resources and database, the latency is still indirectly related).

The con is that because audit trails are being saved asynchronously, the audit trail may be out of sync from the main transaction (as the name 'async' implies).

AuditFlushByteThreshold and AuditFlushEventThreshold

When auditStorePolicy=syncMultipleWrite or auditStorePolicy=async, you use these two flags to control how often the engine should flush the audit events. These two properties do NOT apply to auditStorePolicy=syncSingleWrite.

auditFlushByteThreshold means after adding an event to the current batch, the engine would check if current batch byte size is greater than this value or not. if yes, then it would flush the current batch. The default value is 2048000 (byte), i.e. 2MB.

Similarly, auditFlushEventThreshold means this limit is reached; the engine would trigger the store call. The default value is 300 (event)

Both values need to be tuned based on the application and requirements.

AuditDetailThreshold

This is the maximum size (in bytes) an audit trail details string can be before it is stored separately from the audit trail. The default value is 50000 (byte). This is the same property as in 10.1.3.x.
AuditLevel.this is the same property in 10.1.3.x.

How to Configure

All the above properties can be configured via the SOA EM Console. The path is EM -> SOA ->SOA-INFR - > SOA Administration -> BPEL Properties -> More BPEL Configuration Properties