Oracle Identity Analytics 11g – Flat-File Account Imports Fail after upgrade to PS1 (11.1.1.5)


Trevor Roskewich 29/02/2012

Customers that have upgraded to Oracle Identity Analytics 11g PS1 (11.1.1.5) may have noticed that flat-file account imports, previously successful, now error-out post-upgrade.

When you explore the rbacx.log, it will contain the following error:

20:59:09,251 ERROR [CSVAccountFileReader] —> Error occured file reading file:
java.lang.RuntimeException: Unable to import accounts
at com.vaau.rbacx.iam.file.csv.CSVAccountFileReader.importAccounts(CSVAccountFileReader.java:354)
at com.vaau.rbacx.iam.file.csv.CSVAccountFileReader.readCSVFileInternal(CSVAccountFileReader.java:168)
at com.vaau.rbacx.iam.file.csv.AbstractCSVFileReader.readInternal(AbstractCSVFileReader.java:85)
at com.vaau.rbacx.iam.file.support.AbstractFileReader.read(AbstractFileReader.java:160)
at com.vaau.rbacx.iam.file.support.AbstractFileReader.run(AbstractFileReader.java:82)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: java.lang.NullPointerException
at java.util.Date.getMillisOf(Date.java:939)
at java.util.Date.after(Date.java:912)
at com.vaau.rbacx.manager.AccountManagerImpl.hasAccountChanged(AccountManagerImpl.java:844)
at com.vaau.rbacx.manager.AccountManagerImpl.updateAccounts(AccountManagerImpl.java:716)
at com.vaau.rbacx.manager.AccountManagerImpl.createOrUpdateAccounts(AccountManagerImpl.java:158)
at com.vaau.rbacx.core.support.RbacxDataImporterImpl.importAccounts(RbacxDataImporterImpl.java:915)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:307)
at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:182)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:149)
at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:106)
at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:171)
at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at $Proxy136.importAccounts(Unknown Source)
at com.vaau.rbacx.iam.file.csv.CSVAccountFileReader.importAccounts(CSVAccountFileReader.java:310)
at com.vaau.rbacx.iam.file.csv.CSVAccountFileReader.readCSVFileInternal(CSVAccountFileReader.java:168)
at com.vaau.rbacx.iam.file.csv.AbstractCSVFileReader.readInternal(AbstractCSVFileReader.java:84)
at com.vaau.rbacx.iam.file.support.AbstractFileReader.read(AbstractFileReader.java:160)
at com.vaau.rbacx.iam.file.support.AbstractFileReader.run(AbstractFileReader.java:82)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
… 2 more

OIA 11.1.1.5 introduced a code fix to address Bug 12752492 – user risk summary is not recalculated when re-imported account.  The code provided new columns, including RISK_UPDATE_DATE, that have been added to most tables to support the fix, as noted in the database update script (i.e. migrate-rbacx-11.1.1.3.xto11.1.1.5.0-oracle.sql). The accounts table affected are noted in this alter statement:

alter table rbacxservice.accounts add risk_update_date timestamp;

Other tables such as attribute_value_metadata have the risk_update_date set to sysdate after the column is created in the script. However, this is not the case for the accounts table – meaning the value is left null by default. It appears that a globaluser update (i.e. user import from a provisioning system like Oracle Waveset) may also set the RISK_UPDATE_DATE on the accounts associated with the user to the sysdate of the import. However, orphaned accounts could remain null. The fix for Bug 12752492 attempts to compare the current time with the risk_update_date value in the database for an account being imported – a value of null results in the null pointer exception as noted in the log above.

This issue has been registered as a bug with Oracle. The following workaround appears to be working successfully.

Work Around

1. Analyze how many records are affected

Query the OIA database (i.e. using Oracle SQL developer) to determine the total number of records for the domain of the OIA resource for the failing import (substitute domainnameusedforimport with the appropriate value in the statements below).

select count (*) from accounts where domain = ‘domainnameusedforimport’;

Then, determine how many of these have a null risk_update_date:

select count (*) from accounts where risk_update_date is null and domain = ‘domainnameusedforimport’;

2. Update the null RISK_UPDATE_DATE values

The following statement can be executed to set the null values to the current system date. 

update accounts set risk_update_date = sysdate where risk_update_date is null and domain = ‘domainnameusedforimport’;

3. Verify the count for null RISK_UPDATE_DATE values is null is zero

Rerun select count (*) from accounts where risk_update_date is null and domain = ‘domainnameusedforimport’;

4. Commit the database change

5. Rerun the import

The file import should now complete successfully.

 

This workaround has yet to result in any ill consequences, but this entry will be updated with any new findings and progress on registered bug.

No Results