Troubleshooting
Problem
Custom attributes from Rational DOORS Next Generation (DNG) show as a different data type instead of their actual data type in Report Builder.
Symptom
When using the custom attribute in Report Builder, it appears differently depending on what DNG project area(s) are selected. For example, the custom attribute appears as a string instead of an enumeration.
Cause
This issue can occur when the custom attribute is not defined consistently across all DNG projects as explained in Why are custom attributes in Rational DOORS Next Generation (DNG) missing in Report Builder?
However, another cause is when the attribute is initially created incorrectly (e.g. as a string), deleted and then recreated afterwards (e.g. as an enumeration). DNG does not expose the deleted status of custom attribute via its API and so the Data Collection Component (DCC) Requirement Management job can never update the requirement once it has been created with the wrong data type and the DCC job has run.
This has been identified as a product defect under APAR PI68467 which is awaiting completion of Enhancement 109546: RM Reportable REST API should expose deleted custom attributes.
Resolving The Problem
NOTE: This procedure should only be done at the direction and with the assistance from IBM Support.
1. Identify the problematic custom attribute from DNG in the data warehouse. This is difficult to do since the custom attribute can be assigned to multiple artifact types. Queries like those below can be used to help identify the ID of the problematic custom attribute in the data warehouse since a new record is created each time that the attribute is re-created.
Show all custom attributes with the '[custom_attribute_name]' name from the project it was created in:
SELECT P.NAME, ra.*, r.*
FROM RICALM.VW_RQRMENT_ATTRDEF ra
INNER JOIN RICALM.VW_RQRMENT_TYPE R on ra.requirement_type_id =
r.requirement_type_id
INNER JOIN RIDW.VW_PROJECT P ON R.PROJECT_ID = P.PROJECT_ID
WHERE ra.NAME like '[custom_attribute_name]'
and p.project_id = [project_ID]
ORDER BY P.NAME, R.REQUIREMENT_TYPE_ID
Show all custom attributes named '[custom_attribute_name]' in the data warehouse:
SELECT P.NAME, ra.*, r.*
FROM RICALM.VW_RQRMENT_ATTRDEF ra
INNER JOIN RICALM.VW_RQRMENT_TYPE R on ra.requirement_type_id =
r.requirement_type_id
INNER JOIN RIDW.VW_PROJECT P ON R.PROJECT_ID = P.PROJECT_ID
WHERE ra.NAME like '[custom_attribute_name]'
ORDER BY P.NAME, R.REQUIREMENT_TYPE_ID
2. Manually mark the custom attribute that no longer exists as deleted in the data warehouse by using a query like the one below:
UPDATE RICALM.RQRMENT_ATTRDEF SET ISSOFTDELETED = 1 WHERE REQUIREMENT_ATTRDEF_ID = X
3. Rename the custom attribute that no longer exists in the data warehouse by using a query like the one below:
UPDATE RICALM.RQRMENT_ATTRDEF SET NAME = '[new_name_for_deleted_custom_attribute]' WHERE REQUIREMENT_ATTRDEF_ID = X
4. Refresh the JRS meta model as indicated in the How to refresh meta-model for the Data Source technote.
A fix has been developed for Report Builder starting in CLM 6.0.3 that will automatically ignore any custom attributes that have their ISSOFTDELETED value set to 1. This removes the need for steps 3 and 4 above if you modify the data warehouse manually and will also work for DCC when Enhancement 109546: RM Reportable REST API should expose deleted custom attributes has been completed and the deleted custom attributes are automatically marked as deleted in the data warehouse. For more information, see Defect 400074: CQPAR00193182: When building metadata, RB should hide soft deleted custom attributes.
Was this topic helpful?
Document Information
Modified date:
17 June 2018
UID
swg21990473