Plan.xml Not Getting Updated Across Nodes In SOA 11g Cluster

Recently came across an issue in SOA 11g cluster environment related to Plan.xml.

After creating a data source in Weblogic Admin console, when you update the DB adapter from deployments section, at the "Save Deployment Plan Assistant" screen the data gets stored in the Plan.xml (MW_HOME/ORACLE_SOA1/soa/connectors directory). In a SOA 11g Cluster (lets say 2 node env.) this Plan.xml file gets created on both the nodes first time. However any subsequent updates on the adapter like creation of new datasources or updation to existing ones dont get saved to both nodes. Only the Plan.xml on node where admin server runs gets updated.

This would cause datasource errors/missing JNDI name errors when the environment is load balanced and requests are routed to the 2nd node.

This is more of a cluster configuration issue. The Plan.xml should be kept in a location that is shared storage for all cluster nodes. If this hasn't been done while setting up the cluster then every time adapter updation happens, the Plan.xml only gets updated on Admin server node. In that case the solution is to manually copy the Plan.xml from admin server node to other nodes and restart the managed servers.

Using DVMs in SOA 11g

DVM(Domain Value Maps) are static mappings between a source and target system which can be used in transformations. In SOA 10g, DVMs (.xml) could be imported into the ESB Console and during design time accessed via the lookupDVM XPath functions. I would like to cover the usage of DVMs in SOA 11g and how they can be extended/updated at runtime using SOA Composer.

Within Jdeveloper Right Click on your SOA Composite project and create a new DVM table

You can the use this DVM inside your XSL transformation using the lookupDVM function and finally deploy the code.

Modifying the DVM is equally easier. Just login to the SOA Composer (http://hostname:port/soa/composer)

You can edit the DVM after selecting it and once changes are done Save it and the Commit it. It should commit the changes to the MDS repository and make them available at runtime.

SOA 10g FTP Adapter Not Picking Files From FTP Server

This being my first post of 2012, I would like to wish all my readers a happy and prosperous new year. New year is time for resolutions :-) , apart from regular ones like "Will try to reduce weight" or "Try to keep my room clean" which never works out for me, I will definitely ensure that "I will share knowledge regularly".


New year, old issue. So decided to iron it out once and for all. SOA 10g FTP adapter wasn't picking files from remote FTP server after Jan 1st. Last file read was on Dec 31st. On further analysis found that the FTP adapter Control file had got corrupted.


The control file can be found under $OH/j2ee/home/fileftp/controlFiles/{processname~version}/xxxx/lastModifiedDate.txt


On checking the content of this file found below entry

#Sat Dec 31 23:21:55 CST 2011

lastModifiedTime=1356969420000

As you can see the lastModifiedTime shows as 1356969420000 (This is in milliseconds). This is Unix time or Epoch time and you can use the Epoch converter to convert it into corresponding timestamp.

http://www.epochconverter.com

After conversion it comes to:

GMT: Mon, 31 Dec 2012 15:57:00 GMT

This is where the problem lies. The lastModifiedTime has been set as 31st December 2012. As a result all files since Jan 1st 2012 are not being picked by FTP adapter because the adapter compares the timestamp on remote FTP server and only picks files which are greater than the lastModifiedTime.

What is epoch time?

The Unix epoch (or Unix time or POSIX time or Unix timestamp) is the number of seconds that have elapsed since January 1, 1970 (midnight UTC/GMT).

SOLUTION

Stop the SOA server, take backup of controlFiles directory, remove the control files and redeploy the code , Start SOA server. As a result new control file should come into picture and FTP process should pick files correctly.

Why the controlFile (lastModifiedDate.txt) got corrupted at first place during year change...that is something which I have to figure out. Looks like a bug with Oracle FTP adapter. Will update this post once I get a confirmation regarding same.

Rotating *.out files in SOA 11g Weblogic Server

A very common issue in SOA 11g servers (Weblogic) is the inability to rotate *.out file using out of the box tools or scripts. We can rotate *.err and *.log files but not *.out files . As a result the server keeps hitting the 100% space utilization issue as the *.out file keeps grows to Gigabytes if not monitored correctly.

By default Weblogic doesn't have options to rotate the *.out file, so if we are running on Linux boxes, we can add the following snippet under /etc/logrotate.conf file and append a function to handle *.out files

(location of logs directory)/*.out {

copytruncate

rotate 5

size=10M

}

Basically the above function rotates the .out file for 5 times,once each file reaches the 10MB size and then it truncates the file.
For eg. *.out -> *.out.1 -> *.out.2 -> *.out.3 -> *.out.4 ->*.out.5 and finally *.out.5 is truncated and made to 0 bytes.

To schedule the above cleanup you can write a cron job as per your desired schedule which would call “/usr/sbin/logrotate /etc/logrotate.conf” command.

That's it !! No more 100% space utilization alerts or server crashing due to space being full.

Fusion Applications : General Availability and In The Cloud

I know this is already there across the web now, but thought of mentioning this bit of Oracle news...

Oracle finally took the wraps off the Oracle Fusion Applications (next generation ERP solution) by making it generally available to customers during the Oracle Open World (OOW 2011) conference. They also announced that Oracle Fusion Application modules like HCM, CRM etc will be available in the cloud (SAAS offering).

Below diagram depicts a high level overview of what Oracle Fusion Applications is about...as can be seen below it is best of breed applications taking features from Oracle Ebusiness Suite, Peoplesoft, Siebel and JD Edwards along with number of other product acquisitions done by Oracle across industries and business functionalities. It has embedded analytics/BI across the UI which is empowered by technologies from Hyperion and it is built on top of Oracle Fusion Middleware stack which provides the webservices and security framework.

For more details on the cloud solutions visit http://cloud.oracle.com

If you are an Oracle Partner, you can visit http://www.oracle.com/partners/secure/campaign/eblasts/fusion-application-455396.html to get more in-depth details about Fusion Applications via the Fusion Learning Center.

SOA 11g: Weblogic Admin Server Down with Error "java.lang.NumberFormatException: null"

Weblogic Admin server isn't starting and below error is seen in log file:

<BEA-000386> Server subsystem failed. Reason: java.lang.NumberFormatException: null
java.lang.NumberFormatException: null
        at java.lang.Integer.parseInt(Integer.java:417)
        at java.lang.Integer.parseInt(Integer.java:499)
        at weblogic.ldap.EmbeddedLDAP.validateVDEDirectories(EmbeddedLDAP.java:1097)
        at weblogic.ldap.EmbeddedLDAP.start(EmbeddedLDAP.java:242)
        at weblogic.t3.srvr.SubsystemRequest.run(SubsystemRequest.java:64)
        at weblogic.work.ExecuteThread.execute(ExecuteThread.java:207)
        at weblogic.work.ExecuteThread.run(ExecuteThread.java:176)

This mostly happens when LDAP files are corrupted under the ../domain-name/server/AdminServer/data/ldap/ directory. A possible cause of corruption is when space on server is full. When the associated volume is full (100%) weblogic server will corrupt these files.

To fix the above error tried the below:

Remove the ../domain-name/server/AdminServer/data/ldap/conf/replicas.prop file and restart the Admin server. It should work now.

Using Out-of-the-box Purge Scripts In Oracle SOA 11.1.1.4

Purging the SOA Infra tables (aka dehyrdation store) is a very important task for SOA Suite administrators. In case you have production environments where transactional volume is high it can fill up your SOA Infra audit tables fast and if the data growth in tables is not controlled, it can lead to major performance issues or nightmares rather.

SOA 11.1.1.4 has 2 purging techniques available :
1. Either use the database partitioning concept where the SOA Infra tables are partitioned based on date range or other criteria and you can drop the partitions. This is faster way of doing and comes handy when you have to deal with huge volume of data. This however requires some advanced DBA skills to perform.

2. We also have some purge scripts available which can come handy. Oracle SOA Suite installations across versions have come with out-of-the-box purge scripts but most of these had performance issues. The 11.1.1.4(aka PS3) version of SOA Suite purge scripts have many performance improvements and are easy to use as well. This post explains the simple steps required to execute the purge scripts in your environment.

Step1: Connect to the DB with SQL*Plus as SYSDBA to grant privilages to the SOA Infra user (say DEV_SOAINFRA) that executes the scripts:

SQL> GRANT EXECUTE ON DBMS_LOCK TO DEV_SOAINFRA; 
SQL> GRANT CREATE ANY JOB TO DEV_SOAINFRA;

Step2: The Purge Scripts location is $RCU_HOME/rcu/integration/soainfra/sql/soa_purge/ Connect to the DB with SQL*Plus as the DEV_SOAINFRA user and load the scripts:

SQL> @soa_purge_scripts.sql

This should create some procedures, functions, types and packages under DEV_SOAINFRA schema.
Step3: Before running the purge check how many records there are to be purged using below SQL. Please note cube_instance is not the only table which gets purged, there are lot of child tables which get purged as well.

SQL> select state, count(*) from cube_instance group by state;

Step4: If you want to spool the PLSQL program's output to a log file then set serveroutput on. This would help you understand which are the tables getting purged and also what are the eligible records getting purged.

SQL> SET SERVEROUTPUT ON;
SQL> spool '/tmp/spool.log'

Then run the script mentioned in next step and once finished turn off the spooling.

SQL> spool off 

Step5: Please note there are 2 modes of running purge either loop purge or parallel purge. In loop purge it iterates through the set of eligible records and purges it. Parallel purge is similar to loop purge with additional flexibility of spawning parallel threads to do the purging (faster, multi threaded approach if dealing with huge number of records). Below is a sample of loop purge, for parallel purge the procedure name is delete_instance_in_parallel

SQL> DECLARE
max_creation_date timestamp;
min_creation_date timestamp;
retention_period timestamp;

BEGIN
min_creation_date := to_timestamp('2011-10-01','YYYY-MM-DD');
max_creation_date := to_timestamp('2011-10-05','YYYY-MM-DD');
retention_period := to_timestamp('2011-10-05','YYYY-MM-DD');

soa.delete_instances(
min_creation_date => min_creation_date,
max_creation_date => max_creation_date,
batch_size => 10000,
max_runtime => 60,
retention_period => retention_period,
purge_partitioned_component => false);

END;
/

You can then use the SQL in Step3 to check how many records were purged once the script completes and also open the spool.log to see the data purged from child tables.