We show you some Power BI functionality within Excel so that you can effectively visualize a Stack Rank when you have a long list of values. If you like the videos, subscribe to our YouTube channel.
You have a report where the need is to show multiple values for a given custom field. For example, you have a multi-value Project custom field for Impacted Business Organizations.
You want to see your values as a comma delimited list so that this can be used in an Excel pivot table or SSRS tablix report. You might need something like:
|Project||Impacted Business Orgs|
|Project XYZ||IT, HR, Operations|
When a Project text custom field with associated lookup table is made multi-value, a number of changes are made in the Reporting Database. First, the field is removed from the MSP_EpmProject_UserView as that view only supports single select Project text custom fields with associated lookup table. Second, a new Association View view is created which has the following naming convention: MSPCFPRJ_YourMultiValueCustomFieldName_AssociationView
MSP prefixes all Microsoft views, CF for Custom Field and PRJ for the Project entity. This association view contains a record for each of the multiple custom field values selected, linking the Project record to the lookup table values in the MSPLT_YourMultiValueCustomFieldLookUpTableName_UserView view. LT in this case, stands for lookup table, so there is a MSPLT view for each lookup table in the Reporting Database.
This mechanism was first documented in the Project Server 2007 Report Pack that I wrote and can be found here: http://msdn.microsoft.com/en-us/library/office/bb428828(v=office.12).aspx The Portfolio report also provides another way to utilize the multi-value field.
This query uses the XML functionality to build the concatenated string, based on a technique documented on StackOverflow here.
Once I modified the STUFF statement for specific use for Project Server, I wrapped it with an outer SELECT to combine it with all of the data from MSP_EpmProject_UserView. Note, if you have multiple multi-value fields, you will have to duplicate this inner piece in the parentheses for each field. The places to replace with your own field names are highlighted.
SELECT MSP_EpmProject_UserView.* , MVList.[YourMultiValueCustomFieldNameValues] FROM MSP_EpmProject_UserView INNER JOIN (SELECT MSP_EpmProject_UserView.ProjectUID ,ISNULL(STUFF((SELECT ', '+ MemberValue FROM [MSPLT_VP Lookup_UserView] INNER JOIN [MSPCFPRJ_YourMultiValueCustomFieldName_AssociationView] ON [MSPLT_YourMultiValueCustomFieldLookUpTableName_UserView].LookupMemberUID = [MSPCFPRJ_YourMultiValueCustomFieldName_AssociationView].LookupMemberUID WHERE [MSPCFPRJ_YourMultiValueCustomFieldName_AssociationView].EntityUID = MSP_EpmProject_UserView.ProjectUID FOR XML PATH(''), TYPE ).value('.','varchar(max)') ,1,2, ''),'')AS YourMultiValueCustomFieldNameValues FROM MSP_EpmProject_UserView GROUP BY ProjectUID ) MVList ON MSP_EpmProject_UserView.ProjectUID = MVList.ProjectUID
The output will yield a comma delimited list of values in the last column of the dataset. If you need that comma delimited list sorted, add an ORDER BY MemberValue statement right before the GROUP BY ProjectUID) MVList statement.
If you are planning to write reports over your Project Server data, you will need to know about the Reporting Database or RDB for short.
A Little History
In Project Server 2003, all of the data was typically in one database. Since this database was optimized to support Project Server transactions, reporting on that data could be a bit challenging. Also, there were potential performance concerns as a long running report could impact the performance of core operations.
In Project Server 2007 and continuing in Project Server 2010, a separate Reporting Database is maintained. This separation provides a database schema that is friendlier to report writers and it allows administrators to move the RDB to a separate database server if performance becomes a concern.
Project Server 2013 recombined the four databases into one physical database using four different schemas. This change makes Project Server 2013 easier to manage in a cloud infrastructure. If you upgrade from 2010 to 2013 and use the name of the reporting database as your database name, all of your reports will still work with no change.
In part 1, an overview will be presented and an overview of one key relationship within the RDB will be presented.
Ok, So What’s In It?
The Reporting Database is used as a staging area for OLAP Database creation and to provide project server data in an easier format to query. It contains data on the following major entities:
- Project Decision
- Task by Day
- Assignment by Day
- Resource by Day
- Timesheet and Administrative Time
- Other Supporting entities
It’s a bonanza of data for you to use. Here’s a simplified relationship diagram of the Reporting database core tables. I’ll use this as the basis for posts going forward and show you how to get some nice reports out of this data.
For your convenience, I’m hosting an online interactive copy of the RDB Field Picker.that comes in the Project Server 2010 SDK.
The P-T-A-R Principle
One of the key reporting relationships in the Reporting Database is that between Project – Task – Assignment – Resource (PTAR). This relationship constitutes the majority of Project Management centric reporting.
The Project entity contains the core information related to the Project plan. There is one record for each project on Project Server. This record includes:
- Any Project level custom fields
- Project rollup of work and costs
- Project start and end dates
- Project baselines
A complete Excel based field reference can be found in the Project Software Development Kit, found here: Download the Project 2010 SDK
The primary view for Project information in the RDB is MSP_EPMProject_UserView where ProjectUID is the primary identifier. In the diagram above, all of the other tables that are linked to Project are related to that table by the ProjectUID value. If you are writing queries which require Project information, your join should use the ProjectUID.
The Task entity contains task level information for each task in every project. The data is related to the task itself and not to a specific resource. This record includes:
- Start and End Dates
- Task Custom Fields
- Characteristics of the Task
Task characteristics are especially of interest when reporting over the data. These tend to follow the naming convention of TaskIs… For example, if I wanted a Milestone only report for a given project, I would select all task records where projectuid is equal to the Project’s UID and TaskIsMilestone is equal to 1. There are a number of these fields and I would suggest looking at the RDB Field Reference for more details.
The primary task view is MSP_EpmTask_UserView where TaskUID is the primary key. Though TaskUID is a Globally Unique Identifier (GUID), when working with other related tables/views, I still do my joins using both ProjectUID and TaskUID. The chances of duplicate GUID values are low but I don’t want to be that type of lucky with my project reporting.
The Assignment entity contains information specific for a given resource on a given task. Therefore, there will be a record for each resource for each task. The primary view is MSP_EpmAssignment_UserView where AssignmentUID is the primary identifier.
The Assignment record contains primarily:
- Custom Field values where rolldown was enabled.
As a consequence, the Assignments table is one of the largest in the RDB and in Project Server as a whole. As you need this data to derive the relationship between resources and the tasks to which they are assigned, play specific attention to query execution plans when creating new reports.
The Resource entity contains information related to a specific resource, be it a work, material, cost or budget resource. There is one record for each resource created in Project Server. The resource record contains:
- Resource Custom Fields
- Resource Characteristics
- Login Account information
- Organization information like Team, RBS
- Cost rates
- Timesheet Manager
Like the Tasks, the Resource view follows a similar naming convention of ResourceIs… to denote Resource characteristics. For example, if I only want to see active Resources, I would filter my records based on ResourceIsActive = 1. Especially for resources, you should add filtering on these fields to ensure you do not include team, generic and inactive resources in your reporting.
That covers the core aspects of these entities. In future posts, I’ll go into greater details as to how best to query against them as well as cover other relationships within the RDB.