CLM Reports not populating in Insight - issue with Project
I've imported and configured all of the CLM 301 collateral in Insight 1011 and ran the ETLs. There is data in several tables, including RIODS.Requirement, RIODS.TestCase and RIODS.Project.
When I attempt to execute any reports, they all are prompting for a "project" but the selection box is empty, as if there were no projects loaded into the DW.
I opened the "Reporting Data Model (DW + CALM)" in Framework Manager. I test the Physical Metadata -> VW_Project and I get data returned. I then go and test Consolidate View -> Consolidate Tables -> Project and I get no data, zero rows. There seems to be a disconnect here.
I cannot run any reports because of the Project filter and the Project data not populating. There is data in my Project table as I have queried it in several ways. This is happening in both of my two deployments, so there is some commonality here.
I am not having this problem with the Requirement or TestCase data.
Has anyone experienced this behavior or knows what else I can check?
When I attempt to execute any reports, they all are prompting for a "project" but the selection box is empty, as if there were no projects loaded into the DW.
I opened the "Reporting Data Model (DW + CALM)" in Framework Manager. I test the Physical Metadata -> VW_Project and I get data returned. I then go and test Consolidate View -> Consolidate Tables -> Project and I get no data, zero rows. There seems to be a disconnect here.
I cannot run any reports because of the Project filter and the Project data not populating. There is data in my Project table as I have queried it in several ways. This is happening in both of my two deployments, so there is some commonality here.
I am not having this problem with the Requirement or TestCase data.
Has anyone experienced this behavior or knows what else I can check?
10 answers
Well, no, let me clarify. Once I made the change to '0', I tested the query in FM and I could see the projects. I then changed it back to '1' and went back and verified permissions. The goal here is to enable a security model, so disabling wouldnt really help :)
I think it a permissions thing, and it could be I do not have the right permissions somehow. I will keep digging around, but I'm pretty sure this is what this behavior is around - permissions.
You've gotten me on the right path, hopefully after some more investigation I can uncover. I am fairly new to CLM so it could be I am just missing something small.
I think it a permissions thing, and it could be I do not have the right permissions somehow. I will keep digging around, but I'm pretty sure this is what this behavior is around - permissions.
You've gotten me on the right path, hopefully after some more investigation I can uncover. I am fairly new to CLM so it could be I am just missing something small.
OK... one other thing to make sure is that you've run the JFS_ODS3.0 job (either DeltaLoad or FullLoad). This is what populates the PROJECT_RESOURCE_LOOKUP table that allows the security model to work. It will populate the relationships between the users and the projects to ensure that only authorized users can report against the projects. You'll want to look at the JFS_ReadAccess piece in particular, but running the job as a whole should do the trick.
Another thing to consider is that the name format of the user ('Resource') needs to match the same format your user security has in Insight. It does an exact String match, so if there is a mis-match you're out of luck. For example, if I'm "Jacqueline Albert" in RTC but "Jackie Albert" in Insight, it will think I don't have access even if the PROJECT_RESOURCE_LOOKUP table is populated. So if you're using the security model, you'll want to make sure that Insight is using the same data format in the Cognos authentication model.
If that doesn't work, I'm out of ideas :)
Another thing to consider is that the name format of the user ('Resource') needs to match the same format your user security has in Insight. It does an exact String match, so if there is a mis-match you're out of luck. For example, if I'm "Jacqueline Albert" in RTC but "Jackie Albert" in Insight, it will think I don't have access even if the PROJECT_RESOURCE_LOOKUP table is populated. So if you're using the security model, you'll want to make sure that Insight is using the same data format in the Cognos authentication model.
If that doesn't work, I'm out of ideas :)
Hi Jackie,
So the JFS_ReadAccess fact build is executing successfully and I have verified there is data in the PROJECT_RESOURCE_LOOKUP table as well as the PROJECT and RESOURCE tables. There are two rows that dont get accepted, but I do not think those are affecting this as the correct data is in the tables (my current users and projects).
As far as your second comment on the security match, I have only added the Jazz namespace security and disabled Cognos anonymous access. I do not have any other type of security set up on these two specific deployments. I login to Insight with my Jazz (CLM) credentials and get in just fine. But I have access to no data (Requirement, Test Case, or Project). I tried to query them in Report Studio and nothing is being displayed.
So I added Jazz authentication, disabled anonymous access, logged into Insight with my CLM credentials (user is a JazzAdmin) and I get in. The JazzAdmins group is also a member of the System Administrators Role in Cognos.
So the JFS_ReadAccess fact build is executing successfully and I have verified there is data in the PROJECT_RESOURCE_LOOKUP table as well as the PROJECT and RESOURCE tables. There are two rows that dont get accepted, but I do not think those are affecting this as the correct data is in the tables (my current users and projects).
As far as your second comment on the security match, I have only added the Jazz namespace security and disabled Cognos anonymous access. I do not have any other type of security set up on these two specific deployments. I login to Insight with my Jazz (CLM) credentials and get in just fine. But I have access to no data (Requirement, Test Case, or Project). I tried to query them in Report Studio and nothing is being displayed.
So I added Jazz authentication, disabled anonymous access, logged into Insight with my CLM credentials (user is a JazzAdmin) and I get in. The JazzAdmins group is also a member of the System Administrators Role in Cognos.
Hello.
The user that you log-on with (using the JTS authentication): is that
user a team member of projects? Are there public projects?
If both answers are yes, then still try to find your user's id in the
RESOURCE table and see if it is listed in the PROJECT_RESOURCE_LOOKUP
table.
Best regards,
Peter Haumer.
On 8/16/2011 11:38 AM, jazzyjazz wrote:
The user that you log-on with (using the JTS authentication): is that
user a team member of projects? Are there public projects?
If both answers are yes, then still try to find your user's id in the
RESOURCE table and see if it is listed in the PROJECT_RESOURCE_LOOKUP
table.
Best regards,
Peter Haumer.
On 8/16/2011 11:38 AM, jazzyjazz wrote:
Hi Jackie,
So the JFS_ReadAccess fact build is executing successfully and I have
verified there is data in the PROJECT_RESOURCE_LOOKUP table as well
as the PROJECT and RESOURCE tables. There are two rows that dont get
accepted, but I do not think those are affecting this as the correct
data is in the tables (my current users and projects).
As far as your second comment on the security match, I have only added
the Jazz namespace security and disabled Cognos anonymous access. I do
not have any other type of security set up on these two specific
deployments. I login to Insight with my Jazz (CLM) credentials and
get in just fine. But I have access to no data (Requirement, Test
Case, or Project). I tried to query them in Report Studio and nothing
is being displayed.
So I added Jazz authentication, disabled anonymous access, logged into
Insight with my CLM credentials (user is a JazzAdmin) and I get in.
The JazzAdmins group is also a member of the System Administrators
Role in Cognos.
Ok, I resolved the issue.
When I log into CLM, my display name is not an email address, but it is a full name (e.g. Marc Nehme). The Insight security model leverages the email address for the security check against this display name. So, I had to customize the view VW_PROJECT_RESOURCE_LOOKUP to assign FULL_NAME as the RESOURCE_NAME instead of REFERENCE_ID (email).
Now Insight will use the full name field (e.g. Marc Nehme) to perform the security check against the Jazz server (display name) and assign me the correct permissions. Before Insight was using the email address against the display name and the security check was failing, hence, I was seeing no data.
When I log into CLM, my display name is not an email address, but it is a full name (e.g. Marc Nehme). The Insight security model leverages the email address for the security check against this display name. So, I had to customize the view VW_PROJECT_RESOURCE_LOOKUP to assign FULL_NAME as the RESOURCE_NAME instead of REFERENCE_ID (email).
Now Insight will use the full name field (e.g. Marc Nehme) to perform the security check against the Jazz server (display name) and assign me the correct permissions. Before Insight was using the email address against the display name and the security check was failing, hence, I was seeing no data.
No, we do this on purpose. Insight uses the the email address unless you
either switched it off in the jazz_ns.xml file or you using an
unsupported older version than Insight 1.0.1.1.
The view uses the email, because Insight supports ETLs from multiple
JTS. If you have linked work items from an app registered with one JTS
to requirements on a server with another JTS then the security model
would not allow you to look at the requirements if you authenticated
with the work item's JTS. Hence, we assume that user have different
accounts, but use the same email for each and therefore match the
security checks against the email address and not account ids or names.
Think about IBM's internal self-host where we use bluepages and the
jazz.net servers where we use the jazz LDAP. With this solution you can
still report cross-server.
So, your problem had to something else. Is was not a bug in the view.
This is how it is designed. Also RRDI uses the same security model as we
support migration from RRDI to Insight.
On 8/16/2011 4:08 PM, jazzyjazz wrote:
either switched it off in the jazz_ns.xml file or you using an
unsupported older version than Insight 1.0.1.1.
The view uses the email, because Insight supports ETLs from multiple
JTS. If you have linked work items from an app registered with one JTS
to requirements on a server with another JTS then the security model
would not allow you to look at the requirements if you authenticated
with the work item's JTS. Hence, we assume that user have different
accounts, but use the same email for each and therefore match the
security checks against the email address and not account ids or names.
Think about IBM's internal self-host where we use bluepages and the
jazz.net servers where we use the jazz LDAP. With this solution you can
still report cross-server.
So, your problem had to something else. Is was not a bug in the view.
This is how it is designed. Also RRDI uses the same security model as we
support migration from RRDI to Insight.
On 8/16/2011 4:08 PM, jazzyjazz wrote:
Ok, I resolved the issue.
When I log into CLM, my display name is not an email address, but it
is a full name (e.g. Marc Nehme). The Insight security model
leverages the email address for the security check against this
display name. So, I had to customize the view
VW_PROJECT_RESOURCE_LOOKUP to assign FULL_NAME as the RESOURCE_NAME
instead of REFERENCE_ID (email).
Now Insight will use the full name field (e.g. Marc Nehme) to perform
the security check against the Jazz server (display name) and assign
me the correct permissions. Before Insight was using the email
address against the display name and the security check was failing,
hence, I was seeing no data.
Peter,
I tried this on a new deployment (Windows/Linux mix) and it worked without any additional configuration.
I went back and looked at my Windows only deployment (where I am having this issue) and realized I was not on THE latest code (just before GA) and I think some of the changes were made in the GA version, so this appears to be the reason.
The SetEmailAsUserName attribute was not returning in the version I was using, hence my issue. Though I did find a workaround, I'd prefer to run ofcourse the latest and supported way.
Thanks for your feedback.
I tried this on a new deployment (Windows/Linux mix) and it worked without any additional configuration.
I went back and looked at my Windows only deployment (where I am having this issue) and realized I was not on THE latest code (just before GA) and I think some of the changes were made in the GA version, so this appears to be the reason.
The SetEmailAsUserName attribute was not returning in the version I was using, hence my issue. Though I did find a workaround, I'd prefer to run ofcourse the latest and supported way.
Thanks for your feedback.