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.

SAP IDoc Data With Japanese Kanji or Chinese Characters Overflows

Recently came across an issue while integrating SAP R3 (4.2) version with SOA 11g (11.1.1.4). When idocs are received by SAP Adapter from the SAP system containing Japanese Kanji/Chinese special characters, it was found that the data overflows on to next segments/xml tags and is distorted. This causes mapping issues as incorrect data is being mapped to. The root cause behind this behaviour is that SAP R/3(4.2) is a non-unicode system while SOA 11.1.1.4 is Unicode.

The issue is covered in below Oracle documentation as well
http://download.oracle.com/docs/cd/E14571_01/relnotes.1111/e10132/adapters_iway.htm#CIHBCICF

Here is the explanations provided by Oracle

"This issue only occurs on non-Unicode SAP MDMP environments, where one character can be two or more bytes. As an example of this issue, when using Japanese, the SAP field length is four characters. The English word "ball" fits correctly into the field because one character equals one byte. The Japanese word for ball in Shift-Jis encoding is three characters, but two bytes per character, so the last character is truncated and the last character appears in the next field. Since IDocs are positional delimited, this can cause errors in processing. This occurs because SAP uses character length, not byte length for all non-Unicode field lengths. There is no work around on this issue other than using Unicode or using shorter text in IDocs in DBCS."

None of the workaround suggested above were feasible options. So tried the below approach to fix this...

From SAP before sending the idoc, convert all Japanese strings to hexadecimal characters. Once SOA suite receives the idoc, the BPEL uses a java embed/custom XSLT function (java code) to convert the hexadecimal back to Japanese characters.There is lot of sample code available for doing these kind of hex to string conversion. Just make sure you are using the correct charset (like shift-jis for japanese kanji) while doing the conversion.
Now you should be able to see the idocs properly and use the converted japanese,chinese special characters correctly in your mappings.

SSO (SAML 1.1) Setup In SOA 11g

This post covers the steps required to configure SSO (SAML 1.1) with SOA 11g. Having Single Sign On(SSO) enabled helps the end users as they don't have to remember different username/password combinations for different applications. When tied with a LDAP provider (Like Microsoft Active Directory or Oracle Internet Directory), SSO helps in providing a robust authentication mechanism along with a seamless user experience.

SOA 11g and weblogic have made the SSO configuration very easy for administrators. Its all done on the Weblogic Admin console and doesnt require running any backend scripts or changing files on windows/linux. So lets take a look at some screenshots which show this easy setup.

Create a new Authentication provider (SAMLIdentity Asserter) and reorder to make sure it looks as below.

 Create a new Asserting party and specify properties as shown below

Create a new trusted certificate (same alias as above screenshot) and import the certifcate(.der) file.

      Finally under Managed Server -> Federation Services configure your SAML 1.1 Destination as shown
      below

That's it. Restart the Admin and Managed servers and you should be able to see the SSO redirection happening correctly. Basically whenever you hit your URL (bpm workspace in above screenshot) you should be redirected to your SSO site which should then pull up your user credentails from LDAP provider (lets says NT login) and authenticate you so that you dont have to login explicitly to your URL.

Incase you want to turn on Debug for SSO/SAML to troubleshoot issues with redirection or other errors, follow the below steps in your Weblogic Admin Console. Select Lock & Edit and click on your managed server and under the Debug tab, expand Weblogic->Security and select SAML and click on Enable and save. That's it. You should be able to see the Debug messages related to SSO/SAML in your Managed Server log file now.

Oracle WebTier (11g) Installation hangs

Oracle WebTier provides components like HTTP Server and WebCache which help in routing http requests from external users to the application server. It provides lot of flexibility to Oracle SOA Suite installations by having security, clustering, load balancing features built into it.

I have been using Oracle Webtier for most of my SOA 11g Cluster installations and the installation/configuration has been pretty straight forward. For a WebTier 11.1.1.4 installation basically install the 11.1.1.2 via Installer and apply the 11.1.1.4 patchset on top of it. This is followed by some post install configurations incase you want to setup cluster i.e adding load balancer (VIP) url in httpd.conf and mod_wls_ohs.conf files.

Tried to capture a few installation screenshots below:

Choose the installation type. Default is to Install and Configure in one shot.

Specify the admin server fully qualified domain host name. Eg. abc.mycompany.com

This is where the issue happened. Usually in all my previous installations the post install config step below was successful. But somehow on this specific server it was always getting stuck at 0% and I couldn't find any errors in the install log files for this weird behaviour.

After couple of attempts I decided to take an alternate route of Installing Webtier only (Choose the option Install Software- Do Not Configure) and configuring it in a later step by running (WT_HOME/bin/config.sh). This approach worked and I was able to continue with my installation after scratching my head for few hours.

LDAP Authentication (Active Directory) setup in SOA 11g

This is a short post explaining how to do AD (Active directory) setup in SOA 11g weblogic admin console. AD helps to authenticate users trying to access BPM Worklist or BPM Workspace.

In Weblogic Admin console go to Home >Security Realms >myrealm >Providers

Once done Click on New and provide Name (say ADProvider) and Type as ActiveDirectoryAuthenticator

You can Reorder the Authentication Providers and make sure ADProvider is the topmost one.

Provide the AD specific configuration details on below screen. You may get these details/credentials from your LDAP administrator.

Once all changes are done, save and Activate changes. Then restart the servers and test the LDAP authentication by logging into BPM Workspace or Worklist and ensure that only authenticated users are allowed to login.