I'm trying to upgrade CA PPM from version 184.108.40.2066 to 220.127.116.111. When the install process gets to the data warehouse attributes bootstrap it returns the following error:
4/11/16 5:37 PM (ExecTask) Total time: 0H:0M:2S
4/11/16 5:37 PM (ExecTask) Bootstrapping ODF...
4/11/16 5:37 PM (ExecTask) Heap Size: 3092m, PermGen Size: 1024m
4/11/16 5:37 PM (ExecTask) Capturing metrics in: D:\PPM_Clarity\Clarity/logs/bootstrap.xml
4/11/16 5:37 PM (ExecTask) Loading registered objects for custom attribute bootstrap...
4/11/16 5:39 PM (ExecTask) Loading registered objects for object mappings bootstrap...
4/11/16 5:40 PM (ExecTask) Loading registered objects to bootstrap...
4/11/16 5:40 PM (ExecTask) Loading registered objects for view bootstrap...
4/11/16 5:41 PM (ExecTask) Loading registered objects for object action bootstrap...
4/11/16 5:41 PM (ExecTask) Loading registered objects for data warehouse attributes bootstrap...
4/11/16 5:41 PM (ExecTask) Exception in thread "main" java.lang.NullPointerException
4/11/16 5:41 PM (ExecTask) at com.ca.clarity.object.datawarehouse.DataWareHouseAttributeProcessor.populateMetaColumns(DataWareHouseAttributeProcessor.java:445)
4/11/16 5:41 PM (ExecTask) at com.ca.clarity.object.datawarehouse.DataWareHouseAttributeProcessor.populateMetaColumns(DataWareHouseAttributeProcessor.java:353)
4/11/16 5:41 PM (ExecTask) at com.ca.clarity.object.datawarehouse.DataWareHouseAttributeProcessor.processDwAttributes(DataWareHouseAttributeProcessor.java:115)
4/11/16 5:41 PM (ExecTask) at com.niku.odf.object.Bootstrap.processDwAttributes(Bootstrap.java:2783)
4/11/16 5:41 PM (ExecTask) at com.niku.odf.object.Bootstrap.main(Bootstrap.java:1321)
4/11/16 5:41 PM (ExecTask) at com.niku.odf.object.Bootstrap.main(Bootstrap.java:1075)
4/11/16 5:41 PM (ExecTask) Total bootstrap time: 0H:3M:44.652S
4/11/16 5:41 PM (ExecTask) Bootstrap time breakdown:
I've <lso attached the install.log.
I've tried to find this problem in the forums but didnt find any useful tips.
Has anyone encountered the same problem?
Thanks in advance,
The only thing I can really determine from here is that the null pointer occurred at a time it was trying to ascertain if an attribute's associated lookup was a dynamic query or static list, which it couldn't do because an earlier check in the cache for the attribute's lookup type did not produce a result/match. I might suspect this to happen if a lookup is known to be bad or problematic, or even deleted and no longer existing.
Unfortunately the errors will not reveal which object or attribute or lookup is in question, as the responses it gives are too generic, and the operation is currently being performed against all objects and attributes at the time of error.
If you're not aware of any lookups or attributes that might have that as an issue, then I think it likely you would need to open a ticket with support to take a closer look into your data.
Actually that makes a lot of sense since I can see that i have one lookup that is throwing an error: LOOKUP_USER_ACTIVE_SEC.
Do you know what is the query that is being executed to determine the lookups?
After a little more digging I can see that the problem is in the Resource object and in the datawarehouse. The results of the queries run by the installer for this particular object are either no lines or '0'.
There seems to be a problem that unables the lookups attached to the resource object to migrate to the datawarehouse. Do you agree with me? Do you have any idea of what might be the problem?
Queries run by the installer at the time of error (They either return no lines or '0' (the number)):
declare @p1 int
exec sp_prepexec @p1 output,N'@P1 nvarchar(4000)',N'select internal_name
where object_name = @P1
and is_dw_enabled = 1
and is_custom = 1',N'resource'
exec sp_prepexec @p1 output,N'@P1 int,@P2 nvarchar(4000)',N'select * from DWH_META_COLUMNS
where is_custom = @P1 and UPPER(object_code) = UPPER(@P2 )',0,N'resource'
exec sp_prepexec @p1 output,N'@P1 nvarchar(4000),@P2 nvarchar(4000)',N'select count(1) dw_table_exists
UPPER(dwh_table_name) = UPPER(@P1 ) and UPPER(src_table_name) = UPPER(@P2 )',N'dwh_lkp_employment_type',N'DWH_LOOKUPS_V'
declare @p2 numeric(38,0)
exec CMN_ID_SP N'DWH_META_TABLES',@p2 output,1000,NULL
exec sp_prepexec @p1 output,N'@P1 nvarchar(4000),@P2 nvarchar(4000)',N'select count(1) lookup_col_exists
from cmn_attributes ca,
where UPPER(ca.table_name) = ''CMN_LIST_OF_VALUES''
and UPPER(lov.LOOKUP_TYPE_CODE) = UPPER(@P1 )
and UPPER(COLUMN_NAME) = UPPER(@P2 )',N'LOOKUP_SEC_RESMGR',N'last_updated_date'
UPPER(dwh_table_name) = UPPER(@P1 ) and UPPER(src_table_name) = UPPER(@P2 )',N'dwh_res_resource',N'dwh_res_resource_v'
I've since been able to upgrade to CA PPM 14.1 and continue the upgrade up to 14.3 with success.
In order to do that, I've done the followig:
1. Revert back to 13.3 and inspect the problematic Lookup. In my case LOOKUP_USER_ACTIVE_SEC lookup. Every time I tried to inspect it in the frontend, an error was returned. Since it's a system lookup I had to change the IS_SYSTEM flag in the database from "2" to "0". This allowed me to change it via frontend.
2. I then copied the lookup definition from production manually.
3. Checked any more lookups for any errors. None were found
4. Upgraded to 14.1 again. This time with sucess
5. Log in to the system and navigated in the frontend and the same time checked for errors in the log.
6. After a while and since no errors occured I upgraded directly to 14.3 with sucess .
Thanks for all the help, and specially nick_darlington .