Based on several requests, I created a sample MP that has a class definition with a relationship to another class, a type projection, a view that uses the type projection and a specific form for managing objects of this class. It’s indeed a very simple MP, but it should clarify the relation between those different kinds of MP elements and when to use them.
So I created a class for a new Work Item type called “Service Request”. This class only has a few properties like “ID”, “Title” and “Implementer”. The Implementer of the Service Request is a User, means this is a relationship property to the user class. Most of the work was done by using the Service Manager Authoring Tool or direct XML editing. So you can read on even if you’re not a Visual Studio Pro :)
The end result looks something like this:
Lets take a look at the class definition first. The class specifies the properties “ID” and “Title”. The ID property is the key property and uses an auto incrementing value with the prefix “SR”. The title property is just a simple string. The class is the base for managing new Service Request objects.
For creating the relationship, a relationship type is created that relates the Service Request class to the System.User class. With this configuration it will be possible to add a User to a Service Request by using a user picker.
Next comes the Type Projection. It will be used to create a view and to target the form to manage Service Request objects. Because we only have a single relationship in the Service Request class, there is only one component. Without the Type Projection it would not be possible to display Service Request objects with all properties, because the Service Request implementer would not be selectable in the View. Also when creating a custom form, it would not be possible to put all needed controls on it – the Implementer could not be bound to a userpicker control.
Because the generic form does not allow the configuration of related objects (means it does not offer instance pickers), I created a very simple form for managing the Service Requests directly in the Authoring Tool. Check the form target, it’s the Type Projection I created before and that makes it possible to place a user picker on the form that is bound to the user class to select the Service Request Implementer.
Last but not least, let’s take a look at the view. The view is also targeted at the Type Projection, not at the class. This is because I want to be able to display Information about the implementor in the grid view. If I would choose the class as the target, I could only select direct properties of the Service Request class, but not the Service Request Implementer (User).
With all that together, you can display all information everywhere you need it. I hope this very simple example clarifies some things. If you take a look at the complete MP you will see that some things could be optimized, but as this is only an example, I did not invest too much time in cosmetics. But to learn, just import it in your SM Infrastructure and try to follow the configurations.
Download the MP here! Filename: itnetx.typeprojection.sample.xml.