FAQ: Why is My Custom Incident View So Slow?

FAQ: Why is My Custom Incident View So Slow?

  • Comments 5
  • Likes

This one comes up pretty often – a customer creates a new incident view and uses the Incident (advanced) combination class (aka “type projection) as the target for the view.  Then the performance of the view is really slow.  This blog post will explain why and what you can do to improve the performance of views.

If you need a refresher on type projections please see this blog post:

http://blogs.msdn.com/jakuboleksy/archive/2009/01/20/getting-started-with-type-projections.aspx

If you use the Incident (Advanced) type projection for your view you are able to query by all these relationships (below) and you can use them as columns in a view (so long as the relationship type max cardinality is 1 and the object you want is only one “hop” away from the incident).

image

So – that has pretty much anything you could ever want to query about or display related to an incident.  Perfect right?  No!!  While it is very flexible it also means that the UI is going to pull back all that related object data even if it is not going to be displayed in the view!  Action logs, related configuration items, billable time, etc. are not things that you can’t even display in the view.  This is why views targeted at Incident (Advanced) are slow – because they are bringing back all this data.

If you want a fast view you need to use a type projection that includes only those components you need to query by and to display in the view.  These are the type projections that we provide out of the box in SCSM 2010:

image

Incident (advanced) is intended to be used for the incident form only.  You really don’t want to use this for a view.

Incident (portal) is intended for use by the portal and only gets a limited set of data.  This is the list of components (or relationships) that the portal type projection has:

image

This is still too many for most purposes in a view.

Incident (typical) is a good choice for views because it includes the affected user and the assigned to user component which are commonly used in view criteria or view columns.

image

There is only one problem with using the Incident (typical) type projection.  It is in an unsealed MP for some reason so you can only use it if the view you are going to create is also going to be stored in the same MP (Service Manager Incident Management Configuration Library) as the type projection.  If you create your view anywhere under the out of the box Incident Management node then your view will be in that same MP and it will be fine.

image

If you try to use the Incident (typical) type projection in a view in a different unsealed MP you’ll get an error message like this:

clip_image002

If you create your view someplace else in the tree you’ll need to create your own folder in your own MP. At that point you can only use type projections which are in some other sealed MP (or in the same MP as your folders/views).

You can do that yourself by opening the XML and creating a type projection that looks like this:

        <TypeProjection ID="System.WorkItem.Incident.View.ProjectionType" Accessibility="Public" Type="CoreIncident!System.WorkItem.Incident">
          <Component Path="$Target/Path[Relationship='WorkItem!System.WorkItemAssignedToUser']$" Alias="AssignedUser" />
        </TypeProjection>

Make sure you do these things if you create your own type projection:

  1. Give your type projection a unique ID.
  2. Don’t forget to add a display string for your type projection.
  3. Make sure that you include a MP reference for ‘CoreIncident’ and ‘WorkItem’ (or change the CoreIncident and WorkItem aliases to match your aliases if you already have these MP reference in your MP):

 

      <Reference Alias="CoreIncident">
        <ID>System.WorkItem.Incident.Library</ID>
        <Version>7.0.5826.216</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>
      <Reference Alias="WorkItem">
        <ID>System.WorkItem.Library</ID>
        <Version>7.0.5826.216</Version>
        <PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
      </Reference>

Just to make things a little easier I’ve created an MP (attached) that you can just import that has a bunch of different type projections you can use.

Best practice:  Use the most “narrow” type projection that you can to get the data that you need to display and that let’s you specify the criteria you need.  Using just the incident class itself and not even using a type projection has the best performance.

If you import the .mp file attached there will be a lot more options to choose from:

image

I also included the .xml file in case you want to add some of your own or modify the ones that I provided.

Attachment: IncidentTypeProjections.zip
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment
  • Hi Travis,

    We have learned to create new ProjectionType. But how to add necessary columns in the view? That is I have created new ProjectionType and I try to adjust the view - columns necessary for me aren't present.

    Thanks.

  • Can you please share the typeprojection XML that you have created?

  • Has anyone tried the sample code in the IncidentTypeProjections.zip in 2012 RC please, and know if it works or has any issues?

  • Hello,

    To answer Antoni question, we are using the the sealed IncidentTypeProjections in 2012. Unfortunately we currently get the following error in a popup while looking at the views:-

    "An error osccurred while loading the items. The Full adapter threw an exception. See the FullUpdate property to see the exception"

    Not sure if this is a bug with 2012 or not but any advice would be welcome.

  • Is there an MP the same as above available, but for Service Requests in Service Manager 2012? This would be incredibly useful!