Archive for November, 2011

When creating views in System Center Service Manager, displaying a property of a related object can be accomplished by targeting a combination class, a.k.a. type projection. The wizard that is used to build views in the SM console let you choose which of the related objects, e.g. the affected user of an incident, that you want to bind a column to in a view. This works for all relationships that are constrained to only allow the “source object” (e.g. an incident) to relate one “target object” (e.g. the affected user). The limitations are described in detail in this blog post: http://blogs.technet.com/b/servicemanager/archive/2011/04/06/faq-why-can-t-i-add-some-columns-that-i-want-to-views.aspx

As described in the blog post the reason why we’re not able to select objects that are related to the “source class” based on a one-to-many relationship is based on the complexity around providing features like sorting etc.

Now let’s say you’re ok with not being able to sort on a column like this and would find some kind of value in showing the display name of one of your affected configuration items in a view. Maybe the reason is that you want to know if the incidents listed in the view has defined affected configuration items or not? If so, then you could make use of a XAML (which is the language that WPF and Silverlight is based on) feature that lets you bind to one element in a collection using an index. The abstracts below shows how you force a view to show one of the related objects from a “one-to-many” relationship by data binding to an index of a collection of related objects.

The first section shows a type projection defined for the purpose of having a view showing the affected user and affected configuration items of an incident. The reason for creating this type projection instead of using e.g. the “Incident (Advanced)” type projection is only for performance reasons; always try to minimize the number of components used in a type projection used by your views. Since I only need the two I created a type projection that only contains the two.

Type Projection

<TypeProjection ID="Gridpro.Incident.TypeProjetion.AffectedItems" Accessibility="Public" Type="CoreIncident!System.WorkItem.Incident">
    <Component Path="$Target/Path[Relationship='WorkItem!System.WorkItemAffectedUser']$" Alias="AffectedUser" />
    <Component Path="$Target/Path[Relationship='WorkItem!System.WorkItemAboutConfigItem']$" Alias="AffectedConfigItems" />
</TypeProjection>

Next abstract comes from the input parameter of my view that tells Service Manager that I want to makes use of the type projection described above.

View – Item Source Query Parameter

<AdvancedListSupportClass.Parameters>
	<QueryParameter Parameter="TypeProjectionId" Value="$MPElement[Name='Gridpro.Incident.TypeProjetion.AffectedItems']$" />
</AdvancedListSupportClass.Parameters>

The final abstract shows how to make use of the index when binding to the affected configuration items. Notice the “[0]” written behind the type projection component alias AffectedConfigItems.

View – Column definition

<mux:Column Name="AffectedConfigItems" DisplayMemberBinding="{Binding Path=AffectedConfigItems[0].DisplayName}" Width="100" DisplayName="Header_AboutCI" Property="AffectedConfigItems[0].DisplayName" DataType="s:String" />

In the picture below you can see the example view provided in the following management pack: Gridpro.Examples.Views.zip

Indexed binding